WORKCONTROL FERRAMENTA DE APOIO AO ATENDIMENTO A CLIENTES UTILIZANDO TÉCNICA DE RACIOCÍNIO BASEADO EM CASOS

Transcrição

1 UNIVERSIDADE REGIONAL DE BLUMENAU CENTRO DE CIÊNCIAS EXATAS E NATURAIS CURSO DE SISTEMAS DE INFORMAÇÃO BACHARELADO WORKCONTROL FERRAMENTA DE APOIO AO ATENDIMENTO A CLIENTES UTILIZANDO TÉCNICA DE RACIOCÍNIO BASEADO EM CASOS MATEUS VIEL BLUMENAU /1-16

2 MATEUS VIEL WORKCONTROL FERRAMENTA DE APOIO AO ATENDIMENTO A CLIENTES UTILIZANDO TÉCNICA DE RACIOCÍNIO BASEADO EM CASOS Trabalho de Conclusão de Curso submetido à Universidade Regional de Blumenau para a obtenção dos créditos na disciplina Trabalho de Conclusão de Curso II do curso de Sistemas de Informação Bacharelado. Cláudio Ratke, Mestre - Orientador BLUMENAU /1-16

3 WORKCONTROL FERRAMENTA DE APOIO AO ATENDIMENTO A CLIENTES UTILIZANDO TÉCNICA DE RACIOCÍNIO BASEADO EM CASOS. Por MATEUS VIEL Trabalho aprovado para obtenção dos créditos na disciplina de Trabalho de Conclusão de Curso II, pela banca examinadora formada por: Presidente: Membro: Membro: Prof. Cláudio Ratke, Mestre Orientador, FURB Prof. Wilson Pedro Carli, Mestre FURB Prof. Francisco Adell Péricas, Mestre FURB Blumenau, 09 de novembro de 2010

4 Dedico este trabalho a meus pais e a minha namorada, que em todo tempo me incentivaram com o apoio necessário para o desenvolvimento deste.

5 AGRADECIMENTOS Primeiramente a Deus, por proporcionar-me força e dar-me luz para seguir em frente. Aos meus pais, por incentivar, apoiar e possibilitar toda essa caminhada. Ao meu orientador, Cláudio Ratke, por ter acreditado na conclusão deste trabalho. Aos meus amigos, pela ajuda direta e indiretamente. A todos os professores do curso de Sistemas de Informação da FURB, pela motivação e dedicação quanto ao longo do curso.

6 A mente que se abre a uma nova idéia jamais voltara ao seu tamanho original. Albert Einstein

7 RESUMO Este trabalho tem por objetivo apresentar uma ferramenta de apoio a Help Desk, agilizando o atendimento a clientes, bem como simplificando a resolução de eventuais problemas e facilitando o serviço do atendente, apresentando sugestões similares através da técnica de similaridade do raciocínio baseado em casos (RBC) que já venham a ter ocorrido. Esta ferramenta foi aplicada com êxito em um projeto piloto na área de atendimento ao cliente em uma empresa situada no Vale do Itajaí, tendo por resultado o aumento no número de chamados atendidos, diminuindo o tempo de resolução de chamados em determinado período. Palavras-chave: Help Desk; Similaridade; Raciocínio Baseado em Casos.

8 ABSTRACT This work have the objetive to develop a tool to support Help Desk, speeding up service to customers and simplifying the resolution of any problems and facilitating attendance job, presenting similar suggestions through the technique of similarity-based reasoning (CBR) that may already have occurred. This tool was successfully implemented on a pilot project in a company s attendance situated in Itajaí Valley, resulting in an increase in number of calls attended, reducing the time resolution of calls in certain period. Keyword: Help-Desk; RBC, Similarity; Case-based Reasoning.

9 LISTA DE ILUSTRAÇÕES Figura 1 Modelo de Referência de Processos de TI Figura 2 Modelo de organização do conhecimento Figura 3 Conjunto das melhores práticas para a definição dos processos necessários ao funcionamento de uma área de TI Figura 4 Posicionamento dos Processos da ITIL Figura 5 Definição do Processo de Aprendizado Quadro 1 - Fórmula de Similaridade Quadro 2 Base de Casos Quadro 3 Caso de entrada Quadro 4 Resultados Obtidos Quadro 5 Comparação entre casos Quadro 6 Requisitos funcionais Quadro 7 Requisitos não funcionais Figura 6 Diagrama de caso de uso Figura 7 Entidade e Relacionamento Figura 8 Login do sistema Figura 9 Menu principal Figura 10 Cadastro de usuário Figura 11 Cadastro de cliente Figura 12 Cadastro de incidentes Figura 13 Cadastro de estado Figura 14 Cadastro de cidade Figura 15 - Cadastro de sinônimos Figura 16 - Cadastro de conexão Figura 17 Cadastro de erro conhecido Figura 18 Busca solução para incidente ou problema Figura 19 Consulta Sinônimos Figura 20 Consulta de Erros Conhecidos Figura 21 Cadastro de Similaridade Quadro 8 Descrição do caso de uso login... 62

10 Quadro 9 Descrição do caso de uso manter cliente Quadro 10 Descrição do caso de uso manter estado Quadro 11 Descrição do caso de uso manter cidade Quadro 12 Descrição do caso de uso manter sistema Quadro 13 Descrição do caso de uso manter módulo Quadro 14 Descrição do caso de uso manter versão Quadro 15 Descrição do caso de uso manter sinônimo Quadro 16 Descrição do caso de uso manter percentuais de similaridade Quadro 17 Descrição do caso de uso manter erro conhecido Quadro 18 Descrição do caso de uso manter usuário Quadro 19 Descrição do caso de uso manter incidente Quadro 20 Descrição do caso de uso manter problema Quadro 21 Descrição do caso de uso consulta de similaridade Quadro 22 Descrição do caso de uso manter conexão remota Quadro 23 Descrição do caso de uso emitir relatório de atendimento Quadro 24 Descrição do caso de uso emitir relatório de horas por cliente

11 LISTA DE SIGLAS CCTA Central Communications and Telecon Agency FAQ Frequently Asked Questions FTA Fault Tree Analysis GC Gestão do Conhecimento IA Inteligência Artificial ITIL Information Technology Infrastructure Library MOP Pacotes de Organização de Memória MER Modelo de Entidade e Relacionamento OGC Office Government Commerce OLA Nível Operacional RBC Raciocínio Baseado em Casos SLA Nível de Serviços TI Tecnologia da Informação UML Unified Modeling Language

12 SUMÁRIO 1 INTRODUÇÃO OBJETIVOS DO TRABALHO ESTRUTURA DO TRABALHO FUNDAMENTAÇÃO TEÓRICA HELP DESK Central de Serviços INFORMAÇÃO / CONHECIMENTO GESTÃO DO CONHECIMENTO CONHECIMENTO NAS ORGANIZAÇÕES ITIL Gerenciamento de Processos Modelo de Referência e a ITIL Detalhamento dos Processos da ITIL Gerenciamento de Configurações Gerenciamento de Incidentes Gerenciamento de Problemas Gerenciamento de Mudanças Gerenciamento de Liberação Gerenciamento do Nível de Serviços Gerenciamento de Capacidade Gerenciamento de Disponibilidade Gerenciamento da Continuidade dos Serviços de TI Gerenciamento Financeiro RACIOCÍNIO BASEADO EM CASOS Histórico Definição de Raciocínio Baseado em Casos O Caso Arquitetura Memória de Casos Representação de Casos Indexação dos Casos... 30

13 2.6.8 Recuperação dos Casos Similaridade Vizinho mais Próximo Seleção do Caso Mais Relevante Reutilização dos Casos Aprendizagem SISTEMA ATUAL TRABALHOS CORRELATOS DESENVOLVIMENTO DA FERRAMENTA REQUISITOS PRINCIPAIS DO PROBLEMA A SER TRABALHADO ESPECIFICAÇÃO Requisitos Funcionais Requisitos Não Funcionais Diagrama de Casos de Uso Modelo de Entidade e Relacionamento MER IMPLEMENTAÇÃO Técnicas e Ferramentas Utilizadas Operacionalidade da Implementação Formulário de entrada do sistema Tela Principal Menu Cadastro Menu Consulta Menu Configurações RESULTADOS E DISCUSSÃO CONCLUSÕES EXTENSÕES REFERÊNCIAS BIBLIOGRÁFICAS APÊNDICE A Especificações dos casos de uso APÊNDICE B Dicionário de Dados... 73

14 13 1 INTRODUÇÃO A cada dia mais o conhecimento vem se tornando o principal diferencial perante a concorrência, tanto no mercado de trabalho como entre as organizações. Conhecimento é um recurso intangível que reside essencialmente na cabeça das pessoas (DACONTA; OBRST; SMITH, 2003). Gerir o conhecimento de forma correta, nada mais é do que agregar valor a informação e de compartilhar, sendo o conjunto de procedimentos estabelecido para desenvolver e controlar todo tipo de conhecimento essencial para a organização atingir seus objetivos, o objetivo vem apoiar o processo de decisão. A Gestão do Conhecimento (GC) tem por objetivo obter o conhecimento que se encontra na organização e disponibilizar para a mesma (ZABOT; SILVA, 2002). De acordo com Wangenheim e Wangenheim (2003), uma das técnicas utilizadas para a GC nos últimos anos é o Raciocínio Baseado em Casos (RBC), tecnologia usada para o desenvolvimento de Sistemas Baseado em Conhecimento. O processo de similaridade, mostra ao usuário casos registrados na base de dados, semelhantes ao caso de entrada. A maioria dos departamentos de Tecnologia da Informação (TI) tem por função atender incidentes. Com a baixa qualidade do atendimento o incidente volta a acontecer, ocupando novamente o tempo do atendente. Pela falta de importância e urgência de outros atendimentos, a equipe de suporte quase nunca resolve o problema definitivamente. Uma forma de reduzir a quantidade de incidentes é evitar a sua recorrência, gerenciando os atendimentos com causas não identificadas, analisando e solucionando para que os mesmos não voltem a acontecer (BON, 2005). A empresa indata Sistemas Ltda possui uma equipe de atendimento ao cliente, porém o conhecimento adquirido em resoluções de ocorrências ainda não faz parte do patrimônio estrutural, pois seus colaboradores guardam seu conhecimento para si mesmos, trazendo uma deficiência para a empresa. Apesar de existirem diversas formas de gerenciar tal conhecimento, como a Gestão de problemas do Information Technology Infrastructure Library (ITIL), várias empresas de desenvolvimento de software mantém uma equipe técnica de atendimento ao cliente responsável por restaurar o serviço o mais rápido possível, porém a mesma não se preocupa em tomar medidas que evitem que a falha aconteça novamente. Levando em consideração a situação em que a empresa indata Sistemas se encontra, constata-se que cada vez mais o aumento de conhecimento dentro da instituição vem se

15 14 tornando necessário para que seu atendimento seja rápido e de qualidade, por consequência obtemos o aumento da produtividade. Com objetivo de melhorar a qualidade de seus serviços, pretende-se desenvolver um aplicativo de apoio Service Desk e Gestão de Problemas utilizando GC, o mesmo será o ponto de partida para a criação da base de conhecimento RBC. A abordagem a ITIL proposta nesse trabalho tem por objetivo padronizar o atendimento ao cliente, bem como diminuir os riscos de erros. A abordagem ao RBC, também proposto nesse trabalho, tem por objetivo auxiliar o usuário a consultar atendimentos já feitos, originando-se de casos semelhantes. Hoje, todo conhecimento adquirido em atendimentos resolvidos com sucesso é arquivado por meio de planilhas eletrônicas, papéis ou mantida de forma tácita. 1.1 OBJETIVOS DO TRABALHO O objetivo deste trabalho é apresentar o desenvolvimento de uma ferramenta que auxilie no processo de atendimento ao cliente. Os objetivos específicos do trabalho são: a) registrar o atendimento e organizar o conhecimento para auxiliar o atendimento ao cliente; b) apresentar relatório para acompanhamento de incidentes e problemas; c) permitir a busca por atendimentos semelhantes ao atual; d) permitir a emissão de um relatório de atendimentos por cliente. 1.2 ESTRUTURA DO TRABALHO O trabalho está dividido em quatro capítulos. No primeiro capítulo apresenta-se a introdução do trabalho, os objetivos e a estrutura do trabalho. No segundo capítulo apresenta-se a fundamentação teórica, inicialmente apresenta-se o conceito sobre Help Desk, em seguida todo embasamento teórico que permite compreender

16 15 os aspectos de ITIL, o qual é necessário à construção do modelo proposto, juntamente com a Tecnologia da Informação, usando RBC. Também se apresenta o Sistema Atual, necessário para compreender a área de Help Desk da indata Sistemas atualmente. No terceiro capítulo, é apresentado o desenvolvimento do trabalho, bem como requisitos principais do problema a ser trabalhado, especificações, implementação, resultados, discussão e todos os recursos tecnológicos utilizados para a implementação da ferramenta. No quarto capítulo é apresentada a conclusão, bem como as extensões do trabalho.

17 16 2 FUNDAMENTAÇÃO TEÓRICA Esta sessão aborda assuntos à serem apresentados nas seções a seguir, tais como o Help Desk, Informação/Conhecimento, Gestão do Conhecimento, Raciocínio Baseado em Casos, ITIL, além dos trabalhos correlatos. 2.1 HELP DESK Help Desk é um termo da linguagem inglesa que designa o serviço de apoio ao usuário de informática, telefonia e tecnologias de informação, fornecendo suporte e resolução de problemas técnicos. O serviço de Help Desk pode ser disponibilizado tanto pessoalmente, quanto por telefone, , conexão remota entre outros meios de comunicação. Segundo O brien (2003) as organizações estão cada vez mais buscando novas técnicas para ajudar no atendimento ao cliente, criando grupos chamados de centro de informações, formados por pessoas capacitadas que através do serviço de Help Desk interagem com o cliente para auxiliá-lo no dia-a-dia. Os atendentes de Help Desk muitas vezes dispõem de vários meios de comunicação para auxiliar o cliente, como softwares de conexão remota, chat, tutoriais e vídeos tutoriais, assim, facilitando e simplificando o atendimento. Com a evolução do Help Desk, surgiu o Service Desk, que possui qualidade e abrangências maiores. A Central de Serviços (Service Desk) é, com freqüência, um local em que as pessoas trabalham sob pressão, subestimando a sua importância e a necessidade de competências e habilidades específicas em elevado nível, o que pode afetar de maneira negativa a capacidade de a área de TI fornecer serviços de TI, percebidos pelos seus usuários como sendo de qualidade. ITIL traz boas práticas que podem ser usadas pela equipe de suporte, um eficiente setor de Help Desk vem a trazer um forte diferencial para a empresa alcançar seus objetivos no século XXI. Esse diferencial tem por finalidade a redução de trabalho por parte do setor de Help Desk, aumentando a produtividade da empresa (INFORMATION TECHNOLOGY GOVERNANCE INSTITUTE, 2008).

18 Central de Serviços A função da Central de Serviços interage principalmente como o processo de Gerenciamento de Incidentes, executando, inclusive, parte das atividades deste processo, pelo atendimento às chamadas originadas de erros percebidos pelos usuários na interação com os serviços de TI, que, após uma análise, poderão se constituir em incidentes, classificação dos incidentes e suporte técnico de primeiro nível. Além dos processos de Gerenciamento de Incidentes, a Central de Serviços interage com o processo de Gerenciamento de Comunicação, responsável pela disponibilização dos meios de divulgação das notificações originadas na Central de Serviços e de informá-la sobre notificações vindas de outros processos e partes da organização. Fonte: adaptado de Magalhães e Pinheiro(2007). Figura 1 Modelo de Referência de Processos de TI

19 INFORMAÇÃO / CONHECIMENTO Para Stair e Reynolds (2002), o conhecimento significa aplicar um conjunto de regras, procedimentos e relações a um conjunto de dados para que este atinja um valor informacional. Essa visão de Stair, demonstra o valor do conhecimento como ferramenta da construção da informação. Davenport (2000) define conhecimento como a informação mais valiosa e, conseqüentemente, mais difícil de gerenciar. A influência humana na transformação da informação em conhecimento é valiosa, precisamente porque alguém deu à informação um contexto, um significado, uma interpretação: alguém refletiu sobre o conhecimento, acrescentou a ele sua própria sabedoria, considerou suas implicações mais amplas. Conhecimento pode ser considerado como ponto chave para o crescimento empresarial. Conhecimento é o resultado da interpretação da informação e de sua utilização para gerar novas idéias, resolver problemas ou tomar decisões. Conhecimento pode ser descrito como tudo que é usado para agir e criar novas informações. Segundo Davenport (2000), é notável a dificuldade de definir o termo informação isoladamente, e reitera que as tentativas de fazê-lo por meio da distinção entre dado e conhecimento são nitidamente imprecisas. Dados são simplesmente observações sobre o estado do mundo, conhecimento é a informação mais valiosa, visto que exige: análise, síntese, reflexão e contextualização. Valorizando a Informação, a inteligência e o conhecimento como recurso estratégico, e fonte de vantagens competitivas sustentáveis, os executivos das organizações poderão alcançar estratégias organizacionais eficazes e o sucesso empresarial. De acordo com Bon (2005), utilizando ITIL mais precisamente o processo de Gerenciamento de Problemas, que tem por função analisar problemas não solucionados e resolvê-los de forma que não voltem a acontecer, o mesmo tem por maior preocupação registrar os erros conhecidos, bem como suas soluções, com isto é possível fazer uma melhor GC, fazendo com que até 80% dos incidentes sejam resolvidos no primeiro nível de suporte.

20 GESTÃO DO CONHECIMENTO A GC é compreendida como um conjunto de tarefas, umas dependentes das outras, responsáveis por criar, disseminar, armazenar e utilizar de forma coerente o conhecimento nas organizações (ANGELONI, 2002). O objetivo de GC, é obter o conhecimento que se encontra na organização, representá-lo de forma acessível e coerente, estabelecer o seu compartilhamento dentre a organização. Isso implica em disponibilizar a organização para utilizar de forma inteligente o conhecimento já pertencente a ela. Apontada como um novo vetor da administração moderna, a GC é muito mais um modo de ser do que um recurso que se pode comprar. A GC é muito mais algo que se constrói com trabalho, coerência e dedicação (FIGUEIREDO, 2005). Segundo Terra (2000), as empresas que trabalham com conhecimento seriam aquelas que criam novos conhecimentos, disseminam-nos por toda a organização e, rapidamente, os incorporam em novas tecnologias e produtos. Nonaka e Takeuchi (1997) afirmam que não basta para uma empresa simplesmente ser uma organização que aprende. Ela precisa ser capaz de criar conhecimento para desenvolver soluções inovadoras, caso pretenda superar a condição de mera sobrevivência ou adaptabilidade em um ambiente que lhe é cada vez mais incerto e desafiador. A GC é definida como o conjunto de atividades voltadas para a promoção do conhecimento organizacional, possibilitando que as organizações e seus colaboradores possam sempre se utilizar das melhores informações e dos melhores conhecimentos disponíveis, com vistas ao alcance dos objetivos organizacionais e maximização da competitividade (ALVARENGA NETO, 2002). 2.4 CONHECIMENTO NAS ORGANIZAÇÕES Segundo Terra (2008), o recurso conhecimento vem aumentando aceleradamente para o desempenho empresarial. A gestão do conhecimento vai muito além do investimento em tecnologia ou gestão de inovação. Em Sveiby (1998) é definido como conhecimento nas organizações, redes geradas por fluxos de processos constantes de transformação de informações em conhecimento.

21 20 A figura 2 apresenta o modelo de organização do conhecimento segundo Sveiby. Fonte: adaptado de Sveyby (1998, p.68). Figura 2 Modelo de organização do conhecimento 2.5 ITIL A ITIL foi formada no final da década de 1980 pelo Central Communications and Telecon Agency (CCTA), atual Office Government Commerce (OGC), como um esforço para disciplinar e permitir a comparação entre as propostas dos diversos proponentes a prestadores de serviços de TI para o governo britânico (MANSUR, 2009). Durante a década de 1990, as práticas reunidas na ITIL passaram a ser adotadas pelas organizações européias privadas, uma vez que a ITIL foi concebida como um padrão aberto, sobretudo pelo grande enfoque em qualidade, garantindo pela definição de processos e a proposição de melhores práticas para o Gerenciamento dos Serviços de TI. A ITIL é composta por um conjunto das melhores práticas para a definição dos processos necessários ao funcionamento de uma área de TI, conforme mostra a figura 2, com a meta de permitir o máximo de alinhamento entre área de TI e as demais áreas de negócio, de modo a garantir a geração de valor à organização (VERNEY, 2007).

22 21 Fonte: adaptado Magalhães e Pinheiro(2007). Figura 3 Conjunto das melhores práticas para a definição dos processos necessários ao funcionamento de uma área de TI. A ITIL não define os processos a serem utilizados na área de TI, a mesma expõe as melhores práticas que podem ser utilizadas para essa definição. A adoção da ITIL não obriga a uma nova maneira de pensar e agir, essa adoção fornece uma base para onde colocar os processos já existentes Gerenciamento de Processos O Gerenciamento de Serviços de TI baseia-se em processos. Um processo pode se tornar bastante complexo, dependendo da organização em que ele se encontra, sendo que para cada processo existe um método de gerenciamento específico. Os objetivos do gerenciamento de processos são:

23 22 a) aumentar a qualidade dos serviços; b) aumentar a previsibilidade do comportamento; c) diminuir o custo alocado. Fonte: adaptado de Magalhães e Pinheiro(2007). Figura 4 Posicionamento dos Processos da ITIL Modelo de Referência e a ITIL Para obter um modelo de referencia é necessária a identificação de todos os setores da área de TI que deles participam. O trabalho com os processos identificados constitui-se em uma novidade para muitas organizações e, portanto, para muitas áreas de TI. Ao definir quais as atividades do processo, que entradas são necessárias e quais resultados podem ser obtidos, é possível aumentar a eficiência e eficácia do trabalho Detalhamento dos Processos da ITIL Em seguida será descrito os processos da ITIL, apresentados na figura 3.

24 Gerenciamento de Configurações O processo de Gerenciamento de Configuração é o responsável pela criação da base de dados de gerenciamento de configuração, a qual é constituída pelos detalhes dos itens de configuração empregados para o aprovisionamento e o gerenciamento dos serviços de TI. Um item de configuração é um componente que faz parte ou está diretamente relacionado com a infra-estrutura de TI Gerenciamento de Incidentes De acordo com Vernay (2007), o Gerenciamento de Incidentes tem como foco principal, restabelecer o serviço o mais rápido possível, minimizando o impacto negativo. Uma solução de contorno ou reparo rápido faz com que o usuário volte a trabalhar de modo alternativo. É importante que o Gerenciamento de Incidentes seja informado de quaisquer mudanças. O mesmo pode ser responsável pelo encaminhamento do incidente a uma equipe especializada, como pode provir o alto nível de serviço, possibilitando a resolução de grande parte dos incidentes reportados durante o período do atendimento Gerenciamento de Problemas O Gerenciamento de Problema é responsável pela resolução definitiva e prevenção das falhas por trás dos incidentes que afetam o funcionamento normal dos serviços de TI. Alguns benefícios podem ser citados de acordo com Lisboa(2010): a) aumento de produtividade do usuário devido à redução do tempo de queda dos serviços de TI; b) foco pró-ativo ao invés de reativo; c) melhor relação entre cliente e provedor de serviço de TI, graças a uma maior qualidade da sua entrega e suporte.

25 Gerenciamento de Mudanças Segundo Lisboa (2010), o processo de Gerenciamento de Mudanças tem por objetivo assegurar que todas as mudanças necessárias serão efetuadas conforme planejado e autorizado, assegurando que exista uma razão para efetuar a mudança, identificando os itens de configuração envolvidos. É de suma importância a execução de testes sobre o procedimento de mudança, e existência de um plano de recuperação de serviço, caso algum imprevisto venha acontecer Gerenciamento de Liberação De acordo com Dorow (2009a), o Gerenciamento de Liberação é responsável pela introdução no ambiente de produção de um conjunto de itens de configuração novos e ou que sofreram alterações, os quais já passaram por devidos testes em conjunto. O mesmo também tem por função o gerenciamento de atividades relacionadas com tal liberação Gerenciamento do Nível de Serviços O Gerenciamento do Nível de Serviços tem por objetivo assegurar que os serviços de TI, dentro dos níveis de serviços acordados, serão entregues quando e onde as áreas usuárias o definirem. Este processo depende de todos os demais processos de entrega de serviços. Freqüentemente o responsável pelo Gerenciamento do Nível de Serviço é o próprio gerente da área de TI, tendo em vista a importância para a imagem da área de TI perante a organização (SOUSA, 2007) Gerenciamento de Capacidade Segundo afirmação de Dorow (2009b), o Gerenciamento de Capacidade é responsável pelo alinhamento entre tempo, volume e custo apropriados dos recursos de infra-estrutura de TI necessários ao atendimento das demandas do negócio em termos de serviços de TI.

26 25 O processo Gerenciamento de Capacidade pode ser divido nos seguintes subprocessos: a) monitoramento do desempenho; b) monitoramento da carga de trabalho/demanda; c) dimensionamento da aplicação; d) projeto de recursos; e) projeto de demanda; f) estabelecimento de modelos Gerenciamento de Disponibilidade De acordo com Dorow (2009c), o Gerenciamento de Disponibilidade visa estabelecer os níveis de disponibilidade dos serviços de TI, que permita ao negócio atingir seus objetivos. A disponibilidade é, em geral, calculada com base em um modelo que considera a disponibilidade média e os impactos decorrentes dos pontos de falha mapeados com a utilização da técnica Fault Tree Analysis (FTA). É de responsabilidade do Gerenciamento de Disponibilidade, também a gestão de serviços de terceiros, de forma a garantir a disponibilidade dos serviços desejados, através de Contratos de Nível de Serviços (SLA) e contratos de Nível Operacional (OLA) Gerenciamento da Continuidade dos Serviços de TI O Gerenciamento da Continuidade de Serviços tem por função planejar, cobrir e recuperar-se de uma crise nos serviços de TI, garantindo que a organização volte o mais rápido possível a operar e a atender seus clientes finais, após a ocorrência de um desastre (BON, 2005). O Gerenciamento de Continuidade se preocupa com a habilidade de uma empresa em continuar proporcionando um nível de serviço de TI acordado e pré-determinado, para suportar os requerimentos mínimos do negócio. Dessa forma o Gerenciamento de Continuidade de Serviços de TI pode trazer os seguintes benefícios: a) melhor gerenciamento de riscos; b) credibilidade organizacional;

27 26 c) vantagem competitiva; d) recuperação dos serviços de TI de uma forma controlada; e) interrupção mínima do negócio Gerenciamento Financeiro Segundo Lima (2010), o processo de Gerenciamento Financeiro tem por objetivo determinar o custo de todos os serviços de TI, demonstrando para a organização e possibilitando o entendimento no processo de tomada de decisão. Após, é possível estabelecer o mecanismo que viabilizam a cobrança dos serviços de TI de seus clientes. 2.6 RACIOCÍNIO BASEADO EM CASOS Sistemas especialistas são aplicativos capazes de auxiliar na resolução de problemas ou fornecer conselhos. Esses sistemas capturam resoluções de problemas de especialistas do domínio, e as aplicam em casos específicos, de maneira seletiva. O conhecimento adquirido dos especialistas precisa representar a experiência obtida pelo mesmo, experiências que possibilitam concentrarem-se nas causas mais prováveis de um problema e adaptarem respostas para problemas específicos. De acordo com Carvalho (1996) toda capacidade das pessoas de adquirir conhecimento está ligado à memória humana. Ao tentar entender determinada situação, o ser humano mesmo que inconscientemente, tenta assimilar a situação atual a alguma da presenciada antes, que possa auxiliar na tomada de decisão para encontrar a melhor solução para o caso. RBC é uma técnica que tem por propósito resolver problemas atuais usando soluções anteriores, extraindo o conhecimento a partir de casos ou experiências. São identificadas as principais características dos casos apresentados, a fim de devolver uma melhor solução. Após essa solução o caso é armazenado para futuras consultas. Segundo Wangenheim e Wangenheim (2003), RBC é um enfoque para a solução de problemas e para aprendizado baseado em experiências passadas. RBC resolve problemas ao recuperar e adaptar experiências passadas chamadas casos armazenadas em uma base de casos. Um novo

28 27 problema é resolvido com base na adaptação de soluções de problemas similares já conhecidas. Um dos objetivos do RBC é o desenvolvimento de aplicativos que demonstram o funcionamento do raciocínio humano e que manifestam o comportamento intelectual através da realização de uma determinada atividade ou tarefa (CARVALHO, 1996) Histórico RBC iniciou na Inteligência Artificial com os trabalhos de Schank e Abelson sobre Memória Dinâmica e no modelo cognitivo de uma função central de lembranças de situações passadas e de padrões de situações (WANGENHEIM e WANGENHEIM, 2003). A Memória Dinâmica tem origem na tentativa de se criar modelos cognitivos da solução de problemas e do aprendizado de situações com base em memórias episódicas, criada por Shank em 1982, esses estudos mostraram que a compreensão da linguagem está diretamente relacionada com a informação em memória (KOSLOSKY, 1999). Mesmo que a teoria de RBC possa ser aplicada em diversas áreas, foram sem dúvida os trabalhos de Schank e Abelson, nos anos de 1980, que produziram o modelo cognitivo de RBC e as principais aplicações baseadas nesse modelo. O primeiro sistema que pode ser chamado de um raciocinador baseado em casos foi o sistema CYRUS, desenvolvido por Kolonder (1993) na Yale University (KOSLOSKY, 1999). CYRUS é um sistema de perguntas e respostas que integra o conhecimento obtido da descrição de várias viagens e reuniões do ex-secretário de estado dos Estados Unidos, Cyrus Vance. O sistema é baseado no modelo de memória dinâmica e na teoria dos POMs, na resolução de problemas e na aprendizagem de novos casos Definição de Raciocínio Baseado em Casos RBC é uma ferramenta da Inteligência Artificial (IA), que utiliza de experiências passadas para resolver problemas atuais. Um problema novo é resolvido buscando um caso similar, e reutilizando-o para resolução do caso atual. RBC retém cada novo caso resolvido, dispondo o mesmo para a resolução de problemas futuros (PLAZA; AAMODT, 1994). Segundo Leake (1996), o entendimento das técnicas de RBC está implícito em assumir

29 28 alguns princípios da natureza do mundo: a) regularidade: O mundo é na maioria das vezes regular, as ações executadas nas mesmas condições tendem a ter os mesmos ou similares resultados. Conseqüentemente, soluções para problemas similares são utilizáveis para o início da resolução de outro; b) tipicalidade: os tipos de problemas tendem a repetir; as razões para as experiências são provavelmente as mesmas para as futuras ocorrências; c) consistência: Pequenas mudanças ocorridas no mundo requerem apenas pequenas mudanças na maneira como nós interpretamos o mundo, e conseqüentemente, pequenas mudanças nas soluções de novos problemas; d) facilidade de adaptação: As coisas não se repetem exatamente da mesma maneira; as diferenças tendem a ser pequenas e pequenas diferenças são fáceis para compensar. A construção de um sistema RBC é constituída pelas seguintes fases: a) seleção das informações que farão parte da base de casos; b) definição dos atributos que serão relevantes para a solução do problema; c) definição dos índices que serão utilizados para a recuperação dos casos; d) definição dos métodos de recuperação dos casos, conforme similaridade com novo caso; e) definição da forma de adaptação dos casos recuperados para a solução do novo caso; f) definição do processo de aprendizado. Na figura 5 é apresentado a definição do processo de aprendizado. Fonte: adaptado de Wangenheim e Wangenheim (2003) Figura 5 Definição do Processo de Aprendizado

30 O Caso O caso é definido pela abstração de uma experiência descrita através de atributos devidamente contextualizados. Os mesmos atributos devem não somente expor o conteúdo da experiência, como também o contexto em que ela se passou (SILVA, 1997). De acordo com Abel (1996), caso é o conjunto de informações que representam o conhecimento associado a uma determinada situação. É tornado explicito como determinado caso foi executado e que estratégias foram utilizadas para chegar ao objetivo Arquitetura A arquitetura de um sistema RBC é composta por três itens principais, citados a seguir: a) memória de casos de domínio; b) mecanismos de pesquisa; c) descrição dos casos com índices que diferenciam os casos. Antes de iniciar a construção de um sistema que utiliza RBC devem-se identificar atributos ou características que possam representar o problema. Após é definido como será feita a seleção de um caso similar a este, e finalmente, como este caso escolhido será adaptado para se adequar as necessidades do novo problema. Se a solução encontrada não for perfeita, deve ser possível haver um reparo da solução proposta Memória de Casos Segundo Carvalho (1996), a principal fonte de conhecimento de um modelo RBC é a memória de casos. Essa memória é formada por experiências vividas por especialistas na resolução de problemas. Cada caso é a representação de uma experiência. Os casos devem representar as experiências de forma a possibilitar que sejam recuperadas quando necessário. De acordo com Abel (1996), existem dois modelos de organização de casos, o de memória dinâmica e o de categoria de exemplares. O modelo de memória dinâmica é composto por Pacotes de Organização de Memória (MOP). Estes representam conhecimento sobre classes de eventos de duas formas:

31 30 a) instâncias: representam casos, eventos ou objetos; b) abstrações: representam versões generalizadas de instâncias ou de outras abstrações. O modelo de categoria de exemplares considera que os casos do mundo real podem ser vistos como exemplares de acontecimentos passados. Cada caso é associado a uma categoria e suas feições tem importância para enquadrá-lo ou não na categoria. Para que um novo caso seja armazenado, é feito uma busca por um caso semelhante na memória de casos. Se houver diferenças pequenas entre os dois casos, apenas um é armazenado ou é feita uma combinação entre os dois Representação de Casos Um caso é uma parte contextualizada de um problema que representa uma experiência onde se podem tirar boas lições no futuro. Determinar o que é um caso, é o primeiro problema na modelagem do RBC (WEBER, 1997). O conteúdo de cada caso depende do domínio de aplicação específico e do seu objetivo. Para determinar o que deve ser representado pelos casos, deve-se levar em conta a funcionalidade da informação e a facilidade de aquisição da informação (WANGENHEIN, WANGENHEIN, 2003). Um caso é composto tipicamente pelos seguintes componentes principais: a) problema: que descreve o estado do mundo quando o caso ocorreu; b) solução: que postula uma solução derivada para o problema. A solução pode também ser uma ação, um plano, ou uma informação útil ao usuário. A descrição do problema descreve o problema que foi resolvido ou a situação que foi compreendida Indexação dos Casos Wangenheim e Wangenheim (2003) afirmam que para encontrar casos similares na base de casos para um problema dado, temos de definir quais atributos usaremos para realizar a comparação entre um caso passado e o caso atual. Os índices de um caso são combinações de seus atributos mais importantes, que

32 31 permitem distingui-lo de outros e identificar casos úteis para uma dada descrição de problema. Dois aspectos devem ser enfocados ao tratar os índices, o primeiro é definir o vocabulário e o segundo é como estes índices vão ser valorados. O sucesso do vocabulário de índices é determinado pelo conhecimento do domínio que o especialista possui, portanto, este processo pode ser considerado uma representação do conhecimento (WANGENHEIM; WANGENHEIM, 2003). Segundo Weber (1997), o que realmente interessa na indexação é o seguinte: em função da tarefa, definir um índice, é definir sobre qual dimensão (ões) a (s) experiência (s) serão comparadas sob o enfoque do especialista Recuperação dos Casos O objetivo da recuperação de casos é encontrar um caso ou um pequeno conjunto de casos na base de casos que contenha uma solução útil para o problema ou situação atual (WANGENHEIN; WANGENHEIN, 2003). A recuperação é feita usando características do novo caso que são relevantes na solução de um problema. A partir de um novo problema a ser resolvido, a recuperação de um caso parte da identificação das características desse problema, fazendo uma busca na memória de casos e, então seleciona a solução mais adequada, através de algoritmos que estabelecem a similaridade (KOLOSKY, 1999). Segundo Wangenheim e Wangenheim (2003), o processo de recuperação de casos pode ser formalmente descrito por meio de um conjunto de sub tarefas que devem ser realizadas pelo sistema RBC: a) assessoramento da situação objetivando a formulação de uma consulta representada por um conjunto de descritores relevantes da situação ou problema atuais; b) casamento, objetivando a identificação de um conjunto de casos suficientemente similares à consulta; c) seleção, que escolhe o melhor casamento ou casamentos com base no conjunto de casos selecionado.

33 Similaridade Segundo Wangenheim e Wangenheim (2003), o objetivo do RBC é a reutilização de soluções conhecidas no contexto de um problema novo, de solução ainda desconhecida. Em função disso, a determinação de exemplos de casos adequados, que não precisam necessariamente ser idênticos à situação atual, é um dos problemas centrais desta técnica da Inteligência Artificial. Para Burkhard (1998 apud WANGENHEIM; WANGENHEIM, 2003), as seguintes premissas devem ser atendidas para determinar a similaridade de um caso em um sistema de RBC: a) a similaridade entre a questão atual e o caso implica utilidade; b) a similaridade é baseada em fatos a priori; c) como casos podem ser mais ou menos úteis em relação a uma questão, a similaridade precisa prover uma medida. A similaridade entre o caso atual (caso de entrada) e um determinado caso incluso na base de casos é determinada para cada atributo. Esta medida deve ser multiplicada por um fator peso. A somatória desses atributos é calculada e permite estabelecer a medida de similaridade entre os casos da base de casos e o da atual (KOSLOSKY, 1999). O que faz um caso ser similar ao outro, depende do domínio do conhecimento da aplicação. Quando a recuperação é do tipo que busca a similaridade diretamente, comparando os índices, uma função que mede a similaridade é usada (SILVA, 1997) Vizinho mais Próximo O método do vizinho mais próximo baseia-se em comparar o caso atual com casos armazenados no banco de dados. Para que seja feita a comparação é atribuído um peso a cada uma das feições que serão utilizadas na recuperação. Primeiramente é preciso identificar os atributos para a solução do problema, ou caso de entrada. Tais atributos devem ser representados de forma que seja possível determinar a medida de distância entre o caso atual e o caso existente na base de casos (ABEL, 1996). A similaridade pode ser obtida pela formula conforme quadro 1.

34 33 Quadro 1 - Fórmula de Similaridade Na formula temos as seguintes variáveis: a) T é o novo caso; b) S são os casos existentes na base de casos; c) n é o numero de atributos; d) i é um atributo individual; e) f é a função de similaridade para o atributo i os casos T e S; f) w é o peso do atributo i. Usados pela maioria das ferramentas de RBC, os algoritmos similares de nearest neighbour são utilizados para o cálculo de similaridade. Similaridade são geralmente normalizadas em uma faixa entre 0 e 1, onde 0 representa a dissimilaridade total e 1 a total similaridade (WANGENHEIM; WANGENHEIM, 2003). Caso A Caso B Caso C Caso D Atributo 1 Raciocínio Métricas Similaridade Inteligente Atributo 2 Métricas Inteligente Métricas Prototipagem Atributo 3 Casos Computador Análise Robótica Atributo 4 Baseado Casos Programa Inteligente Quadro 2 Base de Casos Recuperando o(s) caso(s) que tenham similaridade ao caso de entrada descrito no quadro 2. Caso de Entrada Atributo 1 Métricas Atributo 2 Inteligente Atributo 3 Computador Atributo 4 Baseado Quadro 3 Caso de entrada

35 34 Aplicando a fórmula, descrita acima, sobre a base de casos inicial e atribuindo um (1) para atributos coincidentes e zero (0) para não coincidentes, tem-se os resultados contidos no quadro 4. Caso A Caso B Caso C Caso D Atributo Atributo Atributo Atributo Quadro 4 Resultados Obtidos Considerando os atributos com peso(y) igual a um (1), a comparação entre os casos será conforme o quadro 5. Similaridade (CasoNovo, Caso A) = x 1 = 1 x 1 = 0, Similaridade (CasoNovo, Caso B) = x 1 = 3 x 1 = 0, Similaridade (CasoNovo, Caso C) = x 1 = 0 x 1 = 0,0 4 4 Similaridade (CasoNovo, Caso D) = x 1 = 0 x 1 = 0,0 4 4 Quadro 5 Comparação entre casos Com estes resultados, temos o Caso B sendo o mais semelhante, pois é o que mais se aproxima de um (1) Seleção do Caso Mais Relevante De acordo com Lee (1998), a seleção do caso que mais se assemelha ao caso atual destaca o fim da recuperação. O caso selecionado será o caso cuja solução será sugerida para solução do problema.

36 35 Segundo Carvalho (1996), o primeiro passo é assimilar o caso atual com os casos armazenados na base de casos, e descartas os casos que diferem em características que são úteis em realizar as metas do novo caso e em satisfazer as suas restrições. A seleção do caso ideal pode ser feito através de regras, heurísticas e inclusive com a participação do usuário, que pode tanto realizar a escolha como também contribuir com novas informações que proporcionam ao sistema variáveis suficientes para a sua decisão Reutilização dos Casos Uma vez que um caso é recuperado da base de casos, sendo ele adequado, a solução sugerida por esse caso é o objetivo de uma tentativa de reutilização para a solução do problema atual. Durante este passo, dá-se uma reutilização de conhecimento de solução de problemas por meio da transferência de conhecimento do caso anterior, conhecido, para o caso atual, ainda não solucionado. As técnicas utilizadas na reutilização de casos tentam resolver os problemas envolvidos na adaptação de casos como quais aspectos devem ser adaptados, quais alterações devem ser feitas para que a adaptação seja satisfeita (WANGENHEIM; WANGENHEIM, 2003). Koslosky (1999) afirma que, mesmo podendo utilizar a adaptação de várias formas e em varias situações, ela não se torna essencial para sistemas RBC, sendo que muitos deles não implementam a adaptação. Esses sistemas recuperam o caso que possui a maior similaridade e disponibilizam a solução para que o usuário possa reutilizar, deixando livre para proceder com a adaptação Aprendizagem A aprendizagem em sistemas de RBC pode ser empregada ao nível dos casos e da base de casos. As bases de casos podem ser estendidas por processos incrementais de aprendizagem se a tarefa e o projeto do sistema permitirem. A partir de um pequeno conjunto de casos semente (Leake, 1996), a base de casos pode crescer com novos casos. A aprendizagem tem por função incorporar novas informações relativas à resolução de um novo problema. Este processo corresponde à aprendizagem de um sistema RBC, sendo

37 36 disparado pelas tarefas de avaliação e adaptação de soluções (KOSLOSKY, 1999). 2.7 SISTEMA ATUAL Nesta seção, através de entrevista com os responsáveis pela empresa, é apresentado um breve histórico da empresa indata Sistemas Ltda., e seu produto insig. Por fim, é apresentado o processo atual de atendimento ao cliente, a área de Help Desk insig. A empresa indata Sistemas Ltda. surgiu em 1998, com o objetivo de trazer ao mercado um software inovador na área de gestão empresarial. Desde a sua fundação até os dias de hoje, a empresa indata Sistemas vem aprimorando e comercializando o insig. O Sistema insig é composto por módulos independentes, os quais podem ter funções limitadas por usuários ou grupo de usuários. O mesmo pode ser adquirido em partes, fazendo assim com que seja personalizado conforme a necessidade de cada cliente, possibilitando que sejam adicionado ou desativado suas funcionalidades a qualquer momento, sem a necessidade de uma nova instalação. A área de Help Desk da empresa indata Sistemas conta com profissionais especialistas em sua função, sendo que muitas vezes o mesmo profissional atua em diferentes áreas para suprir a demanda. Atualmente o processo de atendimento inicia-se com uma ligação, contato via MSN, e- mail ou Skype, aonde o cliente relata suas dúvidas ao consultor que o atende no momento. Caso o consultor seja responsável pela área aonde se origina a dúvida ou problema, o mesmo continua o atendimento em busca da solução, caso não seja, o atendimento é remetido ao setor responsável. Caso o atendente tenha recordação de um atendimento semelhante, é feito uma busca em seus registros para verificar se o caso já foi registrado, caso tenha lembrança de um atendimento semelhante feito por outro consultor, o mesmo é consultado sobre a solução, que muitas vezes não é encontrada. Existem casos em que o atendente necessita de ajuda do especialista. Se o especialista estiver reservado em outro atendimento, o atendente aguarda sua liberação para então repassar o novo atendimento. Isso faz com que a resolução demore e seja sempre necessária a presença do especialista. Com uma base de casos, muitos desses problemas seriam resolvidos pelo próprio atendente.

38 37 Um novo sistema proposto no capítulo seguinte vem por sua vez possibilitar o registro de todo e qualquer conhecimento, formal ou informal em local seguro e compartilhado com os demais colaboradores. Atualmente esse tipo de conhecimento é registrado em arquivos eletrônicos ou anotações em papel, ficando a critério do próprio atendente a disseminação das informações e registro do atendimento. Devido ao número de atendimentos diários, a confiança bem como a qualidade destes registros, tendem a ser baixa. 2.8 TRABALHOS CORRELATOS Alguns trabalhos correlatos a este foram analisados. Branco (2004) apresentou um trabalho de conclusão de curso na Universidade Regional de Blumenau com o objetivo de desenvolver um protótipo de sistema para GC aplicado a uma empresa do setor de fios da região do Vale do Itajaí. Na monografia de Vieira (2004) o mesmo apresentou um trabalho de conclusão de curso na Universidade Federal de Santa Catarina com o objetivo de desenvolver um protótipo de Sistema de Controle de Suporte Técnico Utilizando Web Service na Imprensa Oficial do Estado de Santa Catarina utilizando tecnologia Java, banco de dados Mysql, JSDK e JWSDP. Dalmarco (2005) apresentou um trabalho de conclusão de curso na Universidade Regional de Blumenau, com o objetivo de desenvolver um protótipo de sistema para auxiliar na definição do Diagnostico Cinesiológico Funcional utilizando Raciocínio Baseado em Casos e tecnologia Borland Delphi, ODBC, Mysql, HTML e PHP.

39 38 3 DESENVOLVIMENTO DA FERRAMENTA Conforme os objetivos do trabalho proposto, foi desenvolvido um software para gestão do conhecimento utilizando RBC, voltado a área de Help Desk da empresa indata Sistemas Ltda. A ferramenta auxilia aos atendentes de Help Desk no compartilhamento do conhecimento, este será útil para a resolução de problemas encontrados no Sistema insig. 3.1 REQUISITOS PRINCIPAIS DO PROBLEMA A SER TRABALHADO A ferramenta tem por finalidade auxiliar o usuário na resolução de eventuais incidentes ou problemas decorrentes ao software, compartilhando o conhecimento de cada usuário no decorrer do dia a dia. Foi utilizada no desenvolvimento do software a técnica de RBC do Vizinho mais Próximo (Nearest Neighbour). 3.2 ESPECIFICAÇÃO No desenvolvimento deste trabalho, foram utilizadas algumas técnicas e ferramentas com a finalidade de especificar, facilitar e desenvolver o software. Para especificação foi utilizada a linguagem Unified Modeling Language (UML), atualmente uma das linguagens mais populares para projeto de desenvolvimento de software. Na criação dos diagramas foram utilizadas as seguintes ferramentas: a) para o diagrama de entidade e relacionamento foi utilizado a ferramenta MySql WorkBench; b) para criação dos diagramas de UML foi utilizado a ferramenta Enterprise Architect 7.1. Os requisitos podem ser classificados como Requisitos Funcionais (RF) e Requisitos Não Funcionais (RNF). Os RF definem quais as funcionalidades o sistema deve possuir em determinada ação. Os RNF definem restrições que o software terá sobre sua usabilidade, bem como navegabilidade, segurança e hardware.

40 Requisitos Funcionais O Quadro 6 apresenta os requisitos funcionais previstos para o sistema e sua rastreabilidade, ou seja, vinculação com os casos de uso associados. Requisitos Funcionais Caso de Uso RF01: O sistema deverá permitir ao administrador manter clientes. UC01 RF02: O sistema deverá permitir ao administrador manter usuários. UC02 RF03: O sistema deverá permitir ao administrador manter estados. UC03 RF04: O sistema deverá permitir ao administrador manter cidades. UC04 RF05: O sistema deverá permitir ao administrador manter sistemas. UC11 RF06: O sistema deverá permitir ao administrador manter módulos. UC12 RF07: O sistema deverá permitir ao administrador manter versões. UC13 RF08: O sistema deverá permitir ao usuário manter conexão remota. UC05 RF09: O sistema deverá permitir ao usuário manter incidente. UC06 RF10: O sistema deverá permitir ao usuário a consulta por incidentes UC09 semelhantes ao atual. RF11: O sistema deverá permitir ao administrador/especialista manter UC07 problema. RF12: O sistema deverá permitir ao administrador/especialista manter os UC08 percentuais de similaridade para cada palavra semelhante. RF13: O sistema deverá permitir ao especialista manter erro conhecido. UC10 RF13: O sistema deverá permitir ao administrador/especialista a emissão de UC16 um relatório de quantidade de atendimentos por cliente. RF14: O sistema deverá permitir ao administrador alterar os percentuais de UC14 similaridade referente a cada índice do sistema. RF15: O sistema deverá permitir ao administrador a emissão de um UC15 relatório de horas de atendimento por cliente. Quadro 6 Requisitos funcionais Requisitos Não Funcionais O Quadro 7 lista os requisitos não funcionais previstos para o sistema.

41 40 Requisitos Não Funcionais RNF01: O sistema deve ser compatível com o banco de dados MYSQL. RNF02: O sistema deverá ser desenvolvido usando a linguagem Java. RNF03: O sistema deverá ser instalado em um hardware com no mínimo: processador 1.0 GHz, 512 MB de memória RAM, placa de vídeo 16MB 800x600 16bits, 2GB de espaço em disco. Quadro 7 Requisitos não funcionais Diagrama de Casos de Uso Segundo Souza e Lima-Cardoso (2007), um Use-Case (UC) demonstra uma funcionalidade do software. O objetivo deste diagrama é disponibilizar para a equipe de desenvolvimento a visualização das exigências funcionais que o software deve possuir, levando em consideração o relacionamento entre pessoas que interagem com os programas e processos essenciais. Esta subseção apresenta o diagrama de casos de uso da ferramenta, sendo que o detalhamento dos principais casos de uso é descritos no Apêndice A. Na figura 6, tem-se o diagrama de casos de uso.

42 41 Figura 6 Diagrama de caso de uso Modelo de Entidade e Relacionamento MER Na figura 7 se apresenta o modelo de entidade e relacionamento que serão persistidas no banco de dados.

43 42 Figura 7 Entidade e Relacionamento A seguir é apresentado uma breve descrição das entidades utilizadas para o desenvolvimento do sistema: a) cadcliente: entidade responsável por armazenar informações referente aos clientes do sistema; b) cadcidade: entidade responsável por armazenar informações referente as cidades cadastradas no sistema; c) cadestado: entidade responsável por armazenar informações referente aos estados

44 43 cadastrados no sistema; d) cadusuario: entidade responsável por armazenar informações referente aos usuarios cadastrados no sistema; e) cadincidentes: entidade responsável por armazenar informações referente aos incidentes cadastrados no sistema; f) cadsistema: entidade responsável por armazenar informações referente aos sistemas cadastrados no software WorkControl; g) cadproblema: entidade responsável por armazenar informações referente aos problemas cadastrados no sistema; h) cadpalavrachave: entidade responsável por armazenar informações referente as palavras chaves cadastradas em incidentes, problemas ou problemas conhecidos no sistema; i) cadmodulo: entidade responsável por armazenar informações referente aos módulos cadastrados no sistema; j) cadsimilaridade: entidade responsável por armazenar informações referente ao peso de cada índice de similaridade cadastrados no sistema; k) cadversao: entidade responsável por armazenar informações referente as versões cadastradas no sistema; l) cadproblemasconhecidos: entidade responsável por armazenar informações referente aos problemas conhecidos cadastrados no sistema; m) movproblemasconhecidos: entidade responsável por armazenar informações referente a solução e descrição dos problemas e incidentes cadastrados no sistema; n) cadsinonimos: entidade responsável por armazenar informações referente aos sinônimos do sistema. o) cadconexao: entidade responsável por armazenar informações referente as conexões estabelecidas com o cliente. p) movtramite: entidade responsável por armazenar as informações referente a alterações feitas em determinado incidente ou problema. 3.3 IMPLEMENTAÇÃO A seguir são mostradas as técnicas e ferramentas utilizadas e a operacionalidade da

45 44 implementação Técnicas e Ferramentas Utilizadas Para implementação do sistema foi utilizada a ferramenta NetBeans 6.0, a mesma auxilia na criação de programas utilizando a linguagem JAVA, na qual foram desenvolvidas as telas bem como sua programação. Para o armazenamento de dados fora utilizado o banco de dados MySQL versão , gerenciado pela ferramenta MySQL Adminstrator na versão disponibilizado gratuitamente no website da empresa Sun Operacionalidade da Implementação Nesta sub-seção será apresentado a seqüência de operações e telas para cada tipo de usuário, para conseguir manusear corretamente o software WorkControl. Também serão dispostos trechos de códigos fonte de algumas rotinas do sistema Formulário de entrada do sistema. o sistema. Na tela apresentada na figura 8, o usuário deve informar seu login e senha para acessar

46 45 Figura 8 Login do sistema. Informando o login e senha, o usuário clica em logar. O sistema irá verificar a existência do cadastro de usuário, caso o mesmo não existir ou o usuário estiver informando login e senha inválidos, o sistema irá apresentar a mensagem: Usuário ou senha inválidos, ou cadastro inexistente!. Após acontecer a validação do usuário e senha a tela principal será exibida Tela Principal Na figura 9 é possível ver a tela principal, aonde o usuário administrador verá todos os menus disponíveis. Figura 9 Menu principal

47 Menu Cadastro Ao acessar o item de menu Cadastro, será disposto ao administrador todas as telas de cadastro do WorkControl. A figura 10 demonstra a tela de cadastro de usuários, nesta tela é possível definir se o usuário será administrador, atendente ou especialista. Após ser inserido o usuário, a mensagem Cadastro inserido com sucesso! será mostrada pelo sistema. Figura 10 Cadastro de usuário No menu cadastro o usuário pode efetuar o cadastro de um novo cliente, conforme mostra a figura 11. No cadastro do cliente são inseridas todas as informações para contato, bem como identificação do mesmo.

48 47 Figura 11 Cadastro de cliente Para todos os usuários é possível cadastrar um Incidente, conforme mostra a figura 9. No cadastro do incidente é possível inserir o tipo de incidente (Erro, Melhoria, Sugestão ou Dúvida), bem como a prioridade do mesmo (Alto, Médio, Baixo). Após cadastrar o incidente, na parte inferior da tela, existe a possibilidade de buscar uma solução para o incidente recém cadastrado, utilizando o botão Buscar Solução, conforme mostra a figura 12.

49 48 Figura 12 Cadastro de incidentes figura 13. O administrador também possui a opção de cadastro de estados no sistema, conforme a

50 49 Figura 13 Cadastro de estado O administrador também possui a opção de cadastro de cidades, conforme a figura 14. Figura 14 Cadastro de cidade O administrador tanto quanto o especialista possuem a opção de cadastro de sinônimos, de acordo com a figura 15.

51 50 Figura 15 - Cadastro de sinônimos O usuário também possui a opção de cadastrar uma conexão remota, descrevendo o tipo de conexão estabelecida com o cliente, conforme a figura 16. Figura 16 - Cadastro de conexão O administrador ou o especialista possuem permissão para efetuar o cadastro de erros conhecidos, conforme a figura 17.

52 51 Figura 17 Cadastro de erro conhecido Menu Consulta No menu Consulta está disponível a consulta de Cliente, Estado, Cidade, Incidentes, Problemas, Erros Conhecidos, Atendentes, Sinônimos, Conexões, Sistemas, Módulos e Versões. Na tela de consulta de Incidentes ou Problemas, é possível alterar determinado incidente ou problema e em seguida pesquisar um caso semelhante, resolvido anteriormente. A mesma pesquisa também é disponível na tela de cadastro de incidentes ou problemas.

53 52 Figura 18 Busca solução para incidente ou problema A busca pelo caso semelhante é feita através da recuperação dos valores determinados como índices e/ou palavras chaves para os casos, em seguida os mesmos são comparados com o caso atual, para que seja possível estabelecer a similaridade. Os pesos de cada índice definidos na tela de configurações como mostra a figura 21, também é levado em consideração para o cálculo de similaridade, bem como os sinônimos cadastrados caso houver. A procura pelo caso similar é obtida pela pesquisa da descrição do atendimento juntamente com as palavras chaves e índices, a função utilizada para pesquisa é listada no fragmento de código da figura 19, aonde é feito a pesquisa pelo texto e seus sinônimos correspondentes. Exemplificando: Se o texto de procura for Erro Financeiro (variável descrição na figura 20) o retorno da consulta será todos os textos sinônimos como por exemplo: Falha Financeiro, Erro Finanças, etc.. conforme a tabela de cadastro de sinônimos.

54 53 Figura 19 Consulta Sinônimos Após estabelecer um grau de similaridade, os casos semelhantes são listados para que o usuário interaja com os mesmos, utilizando para possíveis soluções. O método utilizado para consulta de similaridade é o do vizinho mais próximo, nesse momento são listados os casos com índice que mais se aproxima de 1.0, sendo essas possíveis soluções. O administrador ou o especialista tem a opção de alterar, cancelar ou cadastrar um erro conhecido usando a tela de consulta de erros conhecidos, conforme mostra a figura 20. Figura 20 Consulta de Erros Conhecidos

55 Menu Configurações O administrador do sistema tem possibilidade de definir o percentual equivalente a cada índice de similaridade. A soma dos percentuais inseridos na tela deve ser de 100%, sendo que o usuário deve inserir um valor para cada índice. Após gravar os percentuais na tela a seguinte mensagem será mostrada para o usuário: Similaridade inserida com sucesso!. A figura 20 mostra a tela de Cadastro de Similaridade. Figura 21 Cadastro de Similaridade 3.4 RESULTADOS E DISCUSSÃO Com a conclusão deste trabalho conseguiu-se agilizar as tarefas diárias desenvolvidas pelo setor de Help Desk da empresa indata Sistemas Ltda. Sendo assim, tornou-se possível através desta ferramenta compartilhar o conhecimento gerado no dia-a-dia pela equipe de Help Desk. Além do beneficio à automatização do processo de atendimento, utilizando a ferramenta são evitadas possíveis perdas de informações, bem como possibilita o acompanhamento desde o cadastro do incidente até seu fechamento. Com a automatização do processo, deixando de ser usadas planilhas Excel, aumenta-se a segurança e a facilidade de compartilhamento de informações, fazendo com que todos os usuários sigam um padrão para registro de informações, assim o retrabalho passou a diminuir, já que muitos incidentes são resolvidos com a ajuda de soluções anteriores ou erros