UNIVERSIDADE DO SUL DE SANTA CATARINA JANDERSON COSTA SISTEMA DE HELP DESK UTILIZANDO RACIOCÍNIO BASEADO EM CASOS

Transcrição

1 UNIVERSIDADE DO SUL DE SANTA CATARINA JANDERSON COSTA SISTEMA DE HELP DESK UTILIZANDO RACIOCÍNIO BASEADO EM CASOS Palhoça 2011

2 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

3 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 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

4 À minha mãe Elizete, a responsável pela minha formação e que sempre esteve presente nos momentos decisivos de minha vida.

5 AGRADECIMENTOS Sul de Santa Catarina. 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

6 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.

7 LISTA DE ILUSTRAÇÕES Figura 1 - Engenharia do Conhecimento Figura 2 - Componentes dos Sistemas Especialistas Figura 3 - Exemplo simplificado de caso Figura 4 - Ciclo do Raciocínio Baseado em Casos Figura 5 - Recuperação de casos Figura 6 - Fluxograma: Revisão do caso recuperado Figura 7 - Fluxograma: Proposta da solução Figura 8 - Atores Figura 9 - Diagrama de Casos de Uso (Solicitante) Figura 10 - Diagrama de Casos de Uso (Suporte) Figura 11 - Diagrama de Casos de Uso (Analista RBC) Figura 12 - Diagrama de Casos de Uso (Administrador) Figura 13 - Modelo conceitual da estrutura de classes do sistema Figura 14 - Diagrama de classes Figura 15 - Diagrama Entidade-Relacionamento Figura 16 - Tecnologias e ferramentas utilizadas Figura 17 - Cadastro de conta de acesso Figura 18 - Autoatendimento Figura 19 - Resposta do caso similar Figura 20 - Postar dúvida Figura 21 - Formulário para envio de dúvidas Figura 22 - Lista de questões Figura 23 - Formulário de edição de questões Figura 24 - Salvando uma questão como FAQ Figura 25 - Retenção de caso Figura 26 - Central de chamados Figura 27 - Formulário de edição de chamados Figura 28 - Histórico de interações do chamado Figura 29 - Lista de perguntas frequentes Figura 30 - Pesquisa avançada de chamados

8 Figura 31 - Central de usuários Figura 32 - Tela inicial da base de conhecimento Figura 33 - FAQ (Base de Conhecimento) Figura 34 - Formulário de edição de FAQs Figura 35 - Lista de questões (Base de Conhecimento) Figura 36 - Dicionário de sinônimos Figura 37 - Lista de termos ignorados Figura 38 - Campos globais Figura 39 - Teste de recuperação de casos similares Figura 40 - Casos similares recuperados Figura 41 - Relatório para análise de casos similares

9 LISTA DE GRÁFICOS Gráfico 1 - Resultado da pesquisa para a pergunta 1 do questionário Gráfico 2 - Resultado da pesquisa para a pergunta 2 do questionário Gráfico 3 - Resultado da pesquisa para a pergunta 3 do questionário Gráfico 4 - Resultado da pesquisa para a pergunta 4 do questionário Gráfico 5 - Resultado da pesquisa para a pergunta 5 do questionário Gráfico 6 - Resultado da pesquisa para a pergunta 6 do questionário Gráfico 7 - Análise dos resultados para as perguntas 1, 2, 3, 5 e 6 do questionário Gráfico 8 - Análise dos resultados para a pergunta 4 do questionário

10 LISTA DE TABELAS Tabela 1 - Pesos dos termos da consulta Tabela 2 - Pesos dos termos dos documentos Tabela 3 - Relatório para análise de casos similares

11 LISTA DE QUADROS Quadro 1 - Sistemas Convencionais x Sistemas Baseados em Conhecimento Quadro 2 - Mapa das técnicas de RBC utilizadas Quadro 3 - Requisitos Funcionais Quadro 4 - Requisitos Não Funcionais Quadro 5 - Regras de Negócio Quadro 6 - Casos de Uso Quadro 7 - Perguntas do questionário da pesquisa Quadro 8 - Lista de FAQs Quadro 9 - Requisitos Funcionais Descrição Quadro 10 - Requisitos Não Funcionais Descrição Quadro 11 - Regras de Negócio Descrição Quadro 12 - Casos de Uso Descrição

12 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

13 TIC - Tecnologia da Informação e Comunicação UML - Unified Modeling Language

14 SUMÁRIO 1 INTRODUÇÃO PROBLEMA OBJETIVOS Objetivo Geral Objetivos Específicos JUSTIFICATIVA ESTRUTURA DA MONOGRAFIA REVISÃO BIBLIOGRÁFICA HELP DESK Autoatendimento Importância da Base de Conhecimento O Software de Help Desk SISTEMAS ESPECIALISTAS Introdução Componentes dos Sistemas Especialistas Arquitetura dos Sistemas Especialistas A Base de Conhecimento O Motor de Inferência A Interface com o Usuário Sistemas Convencionais X Sistemas Baseados em Conhecimento RACIOCÍNIO BASEADO EM CASOS Representação do Conhecimento Ciclo do RBC Recuperação Reutilização e Adaptação Adaptação Nula Revisão Retenção Raciocínio Baseado em Casos Textual Recuperação em RBC Textual... 47

15 Modelos de Recuperação de Informação Modelo Booleano Modelo Probabilístico Modelo Vetorial Exemplos de Aplicações RBC Mapa das Técnicas de RBC Utilizadas CONSIDERAÇÕES MÉTODO CARACTERIZAÇÃO DO TIPO DE PESQUISA ETAPAS PROPOSTA DA SOLUÇÃO DELIMITAÇÕES DO PROJETO Requisitos do Sistema Base de Conhecimento MODELAGEM INTRODUÇÃO UML ESPECIFICAÇÃO DO SISTEMA Requisitos Funcionais Requisitos Não Funcionais Regras de Negócio Atores Casos de Uso Diagrama de Casos de Uso do Solicitante Diagrama de Casos de Uso do Suporte Diagrama de Casos de Uso do Analista RBC Diagrama de Casos de Uso do Administrador Diagrama de Classes Modelagem de Dados Diagrama Entidade-Relacionamento DESENVOLVIMENTO TECNOLOGIAS E FERRAMENTAS UTILIZADAS... 85

16 5.1.1.NET Framework ASP.NET C# IIS (Internet Information Services) SQL Server SQL Server Management Studio Express Visual Studio jquery HISTÓRICO DO DESENVOLVIMENTO APRESENTAÇÃO DO SISTEMA Primeiro Acesso Busca da Solução e Retenção de Novos Casos Autoatendimento Resposta Postar Dúvida Lista de Questões Retenção de Casos Central de Chamados FAQ Pesquisa Avançada Central de Usuários Base de Conhecimento FAQ Questões Dicionário de Sinônimos Lista de Termos Ignorados Campos Globais AVALIAÇÃO Avaliação do Processo de Recuperação de Casos Similares Avaliação Geral do Recurso de Autoatendimento Coleta de Dados Resultados da Pesquisa

17 6 CONCLUSÕES E TRABALHOS FUTUROS REFERÊNCIAS APÊNDICE A - LISTA DE PERGUNTAS FREQUENTES APÊNDICE B - REQUISITOS FUNCIONAIS APÊNDICE C - REQUISITOS NÃO FUNCIONAIS APÊNDICE D - REGRAS DE NEGÓCIO APÊNDICE E - CASOS DE USO APÊNDICE F - CLASSES DO MOTOR DE BUSCA APÊNDICE G - QUESTIONÁRIO DA PESQUISA

18 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 . 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

19 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 e- mail, 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.

20 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 acesso a internet,

21 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 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).

22 Objetivos Específicos São objetivos específicos deste trabalho: 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. 1.3 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

23 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.

24 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;

25 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) 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 ? 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;

26 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 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);

27 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 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).

28 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 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).

29 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 Estratégias, Regras do domínio Engenheiro do Conhecimento Sistema Especialista Figura 1 - Engenharia do Conhecimento Fonte: Elaboração do autor, 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

30 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) 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.

31 30 Entrevistas Testa Engenheiro do Conhecimento Constrói, Testa Sistema Especialista Usa Usuário final Figura 2 - Componentes dos Sistemas Especialistas Fonte: Elaboração do autor, A Figura 2 ilustra o diagrama de componentes do SE que apresenta as interações existentes entre cada um 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 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

32 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).

33 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) 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).

34 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;

35 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 Estrutura de dados Dados e Relações entre dados Tipicamente usa algoritmos determinísticos Conhecimento embutido no código do programa Sistemas Baseados em Conhecimento Representação do conhecimento Conceitos, Relações entre conceitos e Regras Busca heurística Conhecimento representado explicitamente e 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).

36 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:

37 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) 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).

38 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.

39 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 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.

40 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

41 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, , 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, 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 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

42 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 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).

43 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.

44 43 Figura 6 - Fluxograma: Revisão do caso recuperado Fonte: Elaboração do autor, 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 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

45 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.

46 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 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 Para serem relevantes, as páginas devem incluir a disponibilidade dessas ferramentas.

47 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;

48 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 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.

49 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 ? b) Como envio por 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).

50 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 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) Modelo Probabilístico

51 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) 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

52 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 w i,j associado ao par (k i, d j ) é positivo e não binário, onde k i é um termo de índice e d j um documento. Além disso, os termos de índices na consulta também são ponderados. Seja w i,q um peso associado ao par [k i, q], onde w i,q 0. Então, o vetor da consulta q é definido como q = (w 1,q, w 2,q,, w t,q ) onde t é o número total de termos de índices no sistema. O vetor do documento d j é representado por d j = (w 1,j,w 2,j,,w t,j ). No modelo vetorial são utilizados os fatores: tf factor, que calcula a quantidade de vezes que o termo k i aparece no documento d j, (fornecendo uma medida de quão bem k i descreve d j ), e o idf factor (inverse document frequency) que mede o inverso da frequência do termo k i 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 n i o número de documentos que o índice k i aparece. Seja freq i,j a frequência bruta do termo k i no documento d j (isto é, o número de vezes que o termo k i é mencionado no texto do documento d j ). Então, a frequência normalizada f i,j do termo k i 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 k i não aparece no documento d j, então f i,j = 0. Além disso, seja idf i a frequência inversa do documento para k i dada por:

53 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 d j 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 d j e q através da equação mostrada a seguir (OLIVEIRA, 2005 apud FERRAZ, 2011). Onde d j e q são as normas do vetor do documento e do vetor da consulta respectivamente. Sendo assim, a similaridade sim(d j,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 k i indexadores: Como mudar a resolução da tela? k 1 k 2 k 3 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

54 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 w ij de um termo k i em um dado documento d j, o algoritmo de RI quantifica as frequências f i,j e n i de k i em d j varrendo todos os documentos e buscando de forma direta o termo indexado k i do documento q da consulta. Caso as frequências f i,j ou n i de um termo sejam iguais a 0, ou seja, se um dado termo k i da consulta não aparece no documento d j 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 t i da consulta q, teríamos seguintes valores fictícios conforme a Tabela 1. Tabela 1 - Pesos dos termos da consulta Termos (t i ) Pesos (w i ) t 1 alterar 0.3 t 2 resolucao 0.7 t 3 tela 0.5 Fonte: Elaboração do autor, 2011.

55 54 Neste caso as frequências f i,j de cada termo são calculadas sobre o próprio documento da consulta q. Considerando também os documentos fictícios d 1 e d 2 indexados pelos termos t i, teríamos os seguintes pesos conforme tabela a seguir. Tabela 2 - Pesos dos termos dos documentos Termos (t i ) Pesos (w i ) de d 1 Pesos (w i ) de d 2 t 1 alterar t 2 resolucao t 3 tela Fonte: Elaboração do autor, Conforme a Tabela 2, os pesos com valor igual a 0 representam a inexistência do termo indexador t i no documento d j. Calculando-se a similaridade de cada documento d j em relação a consulta q teríamos: ( q) ( ) ( ) ( ) ( ) ( ) ( ) ( q) ( ) ( ) ( ) ( ) ( ) ( ) De acordo com os resultados obtidos, conclui-se que o documento d 2 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;

56 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 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

57 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) 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 Raciocínio Baseado em Casos Representação do conhecimento Técnica/Tipo/Modelo Textual Contexto Levemente Textual Documento = Caso

58 57 Ciclo RBC 1 Recuperação Recuperação de Informação Pré-processamento de Texto Recurso de Pesquisa Sequencial Modelo Vetorial Eliminação de Stopwords Dicionário de Sinônimos 2 Reutilização/Adaptação Adaptação Nula 3 Revisão Manual Retenção Manual 4 Retenção de Solução de Problemas / Retenção de Documentos Quadro 2 - Mapa das técnicas de RBC utilizadas Fonte: Elaboração do autor, 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.

59 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.

60 ETAPAS seguintes etapas: O processo de pesquisa e elaboração deste trabalho organiza-se de acordo com as 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.

61 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 ? 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 Busca da Solução e Retenção de Novos Casos).

62 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.

63 Figura 7 - Fluxograma: Proposta da solução Fonte: Elaboração do autor,

64 63 A Figura 7 mostrada apresenta o fluxo do processo de autoatendimento e retenção de novos casos. 3.4 DELIMITAÇÕES DO PROJETO 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 , Relatórios Gerenciais e Manual de Ajuda 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).

65 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).

66 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.

67 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 RF02 RF03 RF04 RF05 RF06 RF07 RF08 RF09 RF10 RF11 RF12 RF13 RF14 RF15 RF16 RF17 RF18 RF19 RF20 Identificação do usuário corrente Criação de conta de acesso Gerenciamento de chamados Criação/Edição/Visualização de chamados Histórico de interações do chamado Anexos do chamado Motor de busca Envio de dúvidas FAQ Pesquisa avançada de chamados Gerenciamento de usuários Perfis de usuário Criação/Edição de contas de usuário Gerenciamento de FAQs Criação/Edição de FAQs Gerenciamento de Questões Edição de questões Gerenciamento do dicionário de sinônimos Gerenciamento da lista de termos ignorados Gerenciamento dos campos globais Quadro 3 - Requisitos Funcionais Fonte: Elaboração do autor, 2011.

68 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 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, A descrição detalhada de cada requisito pode ser verificada no apêndice C.

69 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 RN02 RN03 RN04 RN05 RN06 RN07 RN08 Acesso ao sistema Controle de acesso Forma de atendimento Pesquisa avançada de chamados Gerenciamento de chamados Gerenciamento de contas de usuários Gerenciamento da base de conhecimento Gerenciamento das configurações Quadro 5 - Regras de Negócio Fonte: Elaboração do autor, A descrição detalhada de cada regra pode ser verificada no apêndice D.

70 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.

71 70 uc Atores Solicitante Suporte Administrador Analista RBC Figura 8 - Atores Fonte: Elaboração do autor, A Figura 8 identifica os atores do sistema através da notação gráfica UML 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).

72 71 Para o sistema proposto, foram identificados 34 casos de uso principais como é listado no quadro a seguir. Índice Título CU01 CU02 CU03 CU04 CU05 CU06 CU07 CU08 CU09 CU10 CU11 CU12 CU13 CU14 CU15 CU16 CU17 CU18 CU19 CU20 CU21 CU22 CU23 CU24 CU25 CU26 CU27 CU28 CU29 Criar conta de acesso Criar chamado Visualizar chamado Editar chamado Excluir chamado Inserir anexo Excluir anexo Pesquisar chamados Pesquisar FAQs Visualizar FAQ Pesquisar casos similares Visualizar caso similar Postar dúvida Editar questão Salvar questão como FAQ Excluir questão Criar caso Editar caso Excluir caso Inserir palavra Editar palavra Excluir palavra Inserir sinônimo Editar sinônimo Excluir sinônimo Inserir termo ignorado Editar termo ignorado Excluir termo ignorado Criar conta de usuário

73 72 CU30 CU31 CU32 CU33 CU34 Editar conta de usuário Excluir conta de usuário Inserir opção em campo global Editar opção em campo global Excluir opção em campo global Quadro 6 - Casos de Uso Fonte: Elaboração do autor, A descrição detalhada de cada caso de uso pode ser verificada no apêndice E 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.

74 73 uc Solicitante CU13 - Postar dúv ida «extend» CU11 - Pesquisar casos similares «extend» CU12 - Visualiar caso similar CU02 - Criar chamado CU07 - Excluir anexo «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 «extend» CU10 - Visualizar FAQ Figura 9 - Diagrama de Casos de Uso (Solicitante) Fonte: Elaboração do autor, 2011.

75 Diagrama de Casos de Uso do Suporte do diagrama a seguir. Os principais casos de uso relacionados ao ator Suporte são apresentados através uc Suporte CU30 - Editar conta de usuário CU31 - Excluir conta de usuário «extend» CU29 - Criar conta de usuário CU05 - Excluir chamado CU02 - Criar chamado «extend» CU06 - Inserir anexo Suporte «extend» CU03 - Visualizar chamado CU04 - Editar chamado «extend» «extend» CU08 - Pesquisar chamados Figura 10 - Diagrama de Casos de Uso (Suporte) Fonte: Elaboração do autor, 2011.

76 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» CU18 - Editar caso CU16 - Excluir questão «extend» CU17 - Criar caso CU19 - Excluir caso Analista RBC CU20 - Inserir palav ra CU21 - Editar palav ra «extend» CU22 - Excluir palav ra CU23 - Inserir sinônimo CU24 - Editar sinônimo «extend» CU25 - Excluir sinônimo CU26 - Inserir termo ignorado CU27 - Editar termo ignorado «extend» CU28 - Excluir termo ignorado Figura 11 - Diagrama de Casos de Uso (Analista RBC) Fonte: Elaboração do autor, 2011.

77 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, 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.

78 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.

79 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, 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.

80 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)

81 80 Controle de Acesso Motor de Busca (Continua na próxima página)

82 81 Acesso a Dados Figura 14 - Diagrama de classes Fonte: Elaboração do autor, É 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.

83 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) 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.

84 83 FAQ ID Q uestion C ategory _ID A nsw er Questions ID Q uestion Description Status DictionaryWords ID Word FAQCategories ID C ategory StopWords ID Word DictionarySynonyms ID Word_ID Sy nony m Users ID F ullname UserName Phone Mail Department_ID IsSupport IsC BRA naly st IsA dministrator Departments ID Department Requests ID Title DescriptionHistory DeadlineDate ResolutionDate C reated Modified IsDone Requestor_ID C ategory _ID Priority _ID Sponsor_ID Status_ID RequestCategories ID C ategory Attachments ID Request_ID F ilename C ontentty pe Data Priorities ID Priority Status ID Status Figura 15 - Diagrama Entidade-Relacionamento Fonte: Elaboração do autor, 2011.

85 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.

86 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.

87 86 Figura 16 - Tecnologias e ferramentas utilizadas Fonte: Elaboração do autor, A Figura 16 ilustra as marcas das tecnologias e ferramentas utilizadas na solução, das quais serão brevemente apresentadas a seguir 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

88 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 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) 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 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.

89 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) 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 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).

90 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) 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 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).

91 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 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

92 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.

93 92 apêndice F. As classes que implementam o motor de busca podem ser verificadas no 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 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.

94 93 Figura 17 - Cadastro de conta de acesso Fonte: Elaboração do autor, 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 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.

95 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, 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.

96 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, caso específico. A tela mostrada na Figura 19 é utilizada para visualizar a resposta/solução de um 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.

97 96 Figura 20 - Postar dúvida Fonte: Elaboração do autor, 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.

98 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 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, 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.

99 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, 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 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).

100 99 Figura 24 - Salvando uma questão como FAQ Fonte: Elaboração do autor, 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.

101 100 Figura 25 - Retenção de caso Fonte: Elaboração do autor, Por fim, elaborada e revisada a nova FAQ, esta poderá ser salva, representando assim mais um caso da base de conhecimento 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).

102 101 Figura 26 - Central de chamados Fonte: Elaboração do autor, 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.

103 102 Figura 27 - Formulário de edição de chamados Fonte: Elaboração do autor, 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).

104 103 Figura 28 - Histórico de interações do chamado Fonte: Elaboração do autor, 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 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.

105 104 Figura 29 - Lista de perguntas frequentes Fonte: Elaboração do autor, 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 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.

106 105 Figura 30 - Pesquisa avançada de chamados Fonte: Elaboração do autor, 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 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

107 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, 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.

108 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, A Base de Conhecimento é um recurso que está disponível somente aos usuários com perfil de Analista RBC e Administrador.

109 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, 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.

110 109 Figura 34 - Formulário de edição de FAQs Fonte: Elaboração do autor, 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 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.

111 110 Figura 35 - Lista de questões (Base de Conhecimento) Fonte: Elaboração do autor, 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 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.

112 111 Figura 36 - Dicionário de sinônimos Fonte: Elaboração do autor, 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 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.

113 112 Figura 37 - Lista de termos ignorados Fonte: Elaboração do autor, É 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 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.

114 113 Figura 38 - Campos globais Fonte: Elaboração do autor, 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.

115 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 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, Após iniciar a busca, o sistema retorna os seguintes casos, classificados por ordem de similaridade:

116 115 Figura 40 - Casos similares recuperados Fonte: Elaboração do autor, 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 ? 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;

117 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, 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:

118 117 Tabela 3 - Relatório para análise de casos similares Nº Documentos Termos Freq. Max. Freq. 1 Como apagar o 1 histórico da internet 1 e os arquivos 1 temporários do 2 Internet Explorer? 2 Como remover uma conta de ? 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? Fonte: Elaboração do autor, apagar historico internet arquivo temporario internet explorer remover conta tenho acesso rede local conectar internet posso tornar internet explorer navegador padrao salvar arquivo anexo mensagem outlook ,5 0,5 0, Freq. Norml. Freq. Inv. 1,079 1,38 0,477 0,778 1,079 1,38 0,477 0,778 1,079 1,38 0,477 0,778 1,079 1,38 0,477 0,778 1,079 1,38 0,477 0,778 Peso 0,54 0,69 0,24 0,78 1, , , ,47 0 Sim. 0,954 0,546 0,394 0,394 0,242 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.

119 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 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 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.

120 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? 2 Você acredita que sistemas tutoriais de autoatendimento reduzem a dependência dos usuários com o setor de Help Desk? 3 Você acredita que sistemas tutoriais de autoatendimento reduzem significativamente o número de registros de incidentes (abertura de chamados)? 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) Concordo fortemente b) Concordo c) Indiferente d) Discordo e) Não sei opinar a) Concordo fortemente b) Concordo c) Indiferente d) Discordo e) Não sei opinar a) Concordo fortemente b) Concordo c) Indiferente d) Discordo e) Não sei opinar 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

121 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? 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) Concordo fortemente b) Concordo c) Indiferente d) Discordo e) Não sei opinar a) Concordo fortemente b) Concordo c) Indiferente d) Discordo e) Não sei opinar Quadro 7 - Perguntas do questionário da pesquisa Fonte: Elaboração do autor, 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 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.

122 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 Discordo Indiferente % Concordo 60% Concordo fortemente 30% Gráfico 1 - Resultado da pesquisa para a pergunta 1 do questionário Fonte: Elaboração do autor, 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 Gráfico 2 - Resultado da pesquisa para a pergunta 2 do questionário Fonte: Elaboração do autor, 2011.

123 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 Discordo Indiferente 10% 10% 0% Concordo 70% Concordo fortemente 10% Gráfico 3 - Resultado da pesquisa para a pergunta 3 do questionário Fonte: Elaboração do autor, 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:

124 123 Abrir um chamado e esperar o atendimento Utilizar o autoatendimento eventualmente 0% 10% Utilizar o autoatendimento sempre que possível 40% Utilizar o autoatendimento 50% Gráfico 4 - Resultado da pesquisa para a pergunta 4 do questionário Fonte: Elaboração do autor, 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 Discordo Indiferente 0% 0% 10% Concordo 50% Concordo fortemente 40% Gráfico 5 - Resultado da pesquisa para a pergunta 5 do questionário Fonte: Elaboração do autor, 2011.

125 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 Discordo Indiferente Concordo 20% Concordo fortemente 80% Gráfico 6 - Resultado da pesquisa para a pergunta 6 do questionário Fonte: Elaboração do autor, 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..

126 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:

127 126 4% 4% 4% 32% Concordo fortemente (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, 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 Utilizar o autoatendimento eventualmente 0% 10% Utilizar o autoatendimento sempre que possível 40% Utilizar o autoatendimento 50% Gráfico 8 - Análise dos resultados para a pergunta 4 do questionário Fonte: Elaboração do autor,