universidade do vale do itajaÍ centro de …siaibib01.univali.br/pdf/eloildo vieira.pdf · mvc...
TRANSCRIPT
UNIVERSIDADE DO VALE DO ITAJAÍ CENTRO DE CIÊNCIAS TECNOLÓGICAS DA TERRA E DO MAR
CURSO DE CIÊNCIA DA COMPUTAÇÃO
ATENDEX – SISTEMA DE ATENDIMENTO AO CLIENTE
Área de Sistemas de Informação
por
Eloildo Vieira
Luis Carlos Martins, Esp.
Orientador
Itajaí (SC), maio 2012.
UNIVERSIDADE DO VALE DO ITAJAÍ CENTRO DE CIÊNCIAS TECNOLÓGICAS DA TERRA E DO MAR
CURSO DE CIÊNCIA DA COMPUTAÇÃO
ATENDEX – SISTEMA DE ATENDIMENTO AO CLIENTE
Área de Sistemas de Informação
por
Eloildo Vieira
Relatório apresentado à Banca Examinadora do Trabalho de Conclusão do Curso de Ciência da Computação para análise e aprovação. Orientador: Luis Carlos Martins, Esp.
Itajaí (SC), maio 2012.
ii
RESUMO
VIEIRA, Eloildo. ATENDEX –Sistema de atendimento ao cliente. Itajaí, 2011. 48 f. Trabalho de Conclusão de Curso (Graduação em Ciência da Computação) – Centro de Ciências Tecnológicas da Terra e do Mar, Universidade do Vale do Itajaí, Itajaí, 2011. As empresas de todos os setores estão cada vez mais dependentes de informações para a tomada de decisão, ou mesmo apenas para armazená-las para uma posterior consulta. Os setores da indústria e comércio entre outros, têm cada vez mais utilizado a tecnologia da informação para gerenciar o seu negócio. Atualmente a maioria das organizações utiliza sistemas informatizados para a automação de suas tarefas diárias. Os sistemas de ERP (Enterprise Resource Planning), que integram todos os processos de uma empresa, como vendas, compras, financeiro, entre outros, passaram a fazer parte do negócio, e não há como executar suas funções sem eles. Quando por algum motivo deixam de funcionar, o serviço de atendimento ao cliente ou Service Desk é chamado. Porém com tantas ferramentas para facilitar as tarefas dos usuários, a sobrecarga de informação e complexidade dos negócios tem tornado difícil o trabalho dos analistas de suporte. Muitas empresas procuram adotar técnicas de qualidade aos seus Service Desk para auxiliarem na solução de incidentes, mas não conseguem contabilizar custos nem desempenho nos atendimentos. Nesse contexto, o objetivo deste trabalho foi desenvolver um sistema de gerenciamento de informação para Service Desk baseado nas boas práticas da Information Technology Infrastructure Library (ITIL), visando melhorar a eficiência e a eficácia na resolução de incidentes, e também a relação entre cliente e suporte. O sistema foi implementado em linguagem de programação PHP, utilizando o framework Zend e a biblioteca Javascipt JQUERY conectado ao banco de dados Firebird 2.0 via web.
Palavras-chave: Gerenciamento de Incidentes, ITIL, Service Desk.
iii
ABSTRACT
Title: “ATENDEX - System customer service”.
The companies of all areas are more and more reliant on information for the decision taking, or
else, just store them. The industry and commerce, among others, have been intensively using I.T.
(Information Technology) for business administration. Actually, most companies use softwares to
ease their daily tasks. The ERP systems (Enterprise Resource Planning) link all the processes in the
company, such as sales, purchases, finance, etc., are now part of the business intelligence, and it´s
not possible to operate without them. When for some reason they stop working, the Help Desk is
then activated. Although the great number of tools available to help out the final user, the overload
of information and complexity in the business core, it has become hard for the support analysts to
develop good solutions. Many companies have been investing in the improvement of the quality of
their Help Desk to better solve problems but they cannot measure the costs and neither the
performance in the assistance. Facing this scenario, the objective here was to develop a
management system for the Help Desk based on good practices in the Information Technology
Infrastructure Library (ITIL), with the aim to improve the efficiency and the results in problem
solving, also, the relation between client and Help Desk. The system was implemented in the
programming language PHP using the Zend Framework and jQuery library Javascipt connected to
Firebird 2.0 database via web.
Keywords: Incident Management, ITIL, Service Desk
iv
LISTA DE FIGURAS
Figura 1 - Tipos de Sistemas de Informação ...................................................................................... 17 Figura 2 - Atribuições do Service Desk .............................................................................................. 18 Figura 3 - Relacionamento entre Processos do ITIL .......................................................................... 19 Figura 4 - Posicionamento dos Processos da ITIL ............................................................................. 20 Figura 5 - Evolução até a implementação da solução ........................................................................ 22 Figura 6 - Exemplo de processo de Gerenciamento de Incidente ...................................................... 23 Figura 7 - Escalonamento ................................................................................................................... 25 Figura 8 - Integração Incidente x Problema ....................................................................................... 26 Figura 9 - Ciclo de Vida de um problema .......................................................................................... 29 Figura 10 - Tela de registro de atendimento ...................................................................................... 33 Figura 11 - Tela de pesquisa atendimentos ........................................................................................ 33 Figura 12 - Tela Principal MySuite. ................................................................................................... 34 Figura 13 - Tela Principal do Webhelpdesk ....................................................................................... 35 Figura 14 - Dashboard Milldesk......................................................................................................... 36 Figura 15 - Exemplo de Código PHP ................................................................................................. 38 Figura 16 - Situação atual ................................................................................................................... 43 Figura 17 - Situação proposta ............................................................................................................. 44 Figura 18 - Fluxo suporte nível 1 ....................................................................................................... 45 Figura 19 - Fluxo suporte nível 2 ....................................................................................................... 46 Figura 20 – Fluxo suporte nível 3 ...................................................................................................... 46 Figura 21 - Diagrama de Casos de Uso Cenário Geral ...................................................................... 49 Figura 22 - Diagrama de Classes ........................................................................................................ 57 Figura 23 - Diagrama de Banco de Dados ......................................................................................... 59 Figura 24 - Script de criação da tabela atendimento .......................................................................... 60 Figura 25 - Tabela atendimento gerada no SGBD Firebird ............................................................... 61 Figura 26 - Código abrir atendimento ................................................................................................ 62 Figura 27 - Script PHP registro no banco de dados ........................................................................... 62 Figura 28 - Tela de login .................................................................................................................... 63 Figura 29 - Abertura de atendimento ................................................................................................. 64 Figura 30 - Registro de diálogos ........................................................................................................ 65 Figura 31 - Pesquisa base de conhecimento ....................................................................................... 66 Figura 32 - Registrar tarefas ............................................................................................................... 66 Figura 33 - Reset ................................................................................................................................ 67 Figura 34 - Cadastrar técnico ............................................................................................................. 68 Figura 35 - Cadastro de cliente .......................................................................................................... 69 Figura 36 - Relatório de atendimentos ............................................................................................... 69
v
LISTA DE TABELAS
Tabela 1 - Indicadores de Estado ....................................................................................................... 24 Tabela 2 - Resumo dos recursos analisados nos sistemas similares .................................................. 37 Tabela 3 - Caso de Uso nº 01 ............................................................................................................. 50 Tabela 4 - Caso de Uso nº 02 ............................................................................................................. 50 Tabela 5 - Caso de Uso nº 03 ............................................................................................................. 50 Tabela 6 - Caso de Uso nº 04 ............................................................................................................. 50 Tabela 7 - Caso de Uso nº 05 ............................................................................................................. 51 Tabela 8 - Caso de Uso nº 06 ............................................................................................................. 51 Tabela 9 - Caso de Uso nº 07 ............................................................................................................. 51 Tabela 10 - Caso de Uso nº 08 ........................................................................................................... 52 Tabela 11 - Caso de Uso nº 09 ........................................................................................................... 52 Tabela 12 - Caso de Uso nº 10 ........................................................................................................... 52 Tabela 13 - Caso de Uso nº 11 ........................................................................................................... 53 Tabela 14 - Teste de banco de dados .................................................................................................. 70 Tabela 15 - Teste funcional ................................................................................................................ 71 Tabela 16 - Teste de interface do usuário .......................................................................................... 71 Tabela 17 - Teste de desempenho ...................................................................................................... 72 Tabela 18 - Teste de carga .................................................................................................................. 72 Tabela 19 - Teste de segurança .......................................................................................................... 72
vi
LISTA DE ABREVIATURAS
BDEC Banco de Dados de Erros Conhecidos CRM Customer Relationship Management CSS Cascading Style Sheets ERP Enterprise Resource Planning GI Gerenciamento de Incidentes GP Gerenciamento de Problema HTTP Hyper-Text Transfer Protocol ITIL Information Technology Infrastructure Library JDBC Java Database Connectivity MD5 Message-Digest algorithm 5 MVC Model-view-controller ODBC Open Database Conectivity OLEDB Object Linking and Embedding, Database PHP Hypertext Preprocessor PSQL Procedural Structured Query Language PUC Ponto Único de Contato SD Sistema Desktop SGBD Sistema de Gerenciamento de Banco de Dados SI Sistemas de Informação SLA Service Level Agreement SPOC Single Point of Contact SSL Secure Sockets Layer TTC Trabalho Técnico-científico de Conclusão de Curso TI Tecnologia da Informação UDF User Defined Functions UML Unified Modeling Language UNIVALI Universidade do Vale do Itajaí
vii
SUMÁRIO
RESUMO ............................................................................................................................................ ii
ABSTRACT ...................................................................................................................................... iii
LISTA DE FIGURAS ....................................................................................................................... iv
LISTA DE TABELAS ........................................................................................................................ v
LISTA DE ABREVIATURAS ......................................................................................................... vi
1 INTRODUÇÃO ............................................................................................................................. 9 1.1 PROBLEMATIZAÇÃO ..................................................................................................................... 10 1.1.1 Formulação do Problema .......................................................................................................... 10 1.1.2 Solução Proposta ....................................................................................................................... 11 1.2 OBJETIVOS ................................................................................................................................... 12 1.2.1 Objetivo Geral ........................................................................................................................... 12 1.2.2 Objetivos Específicos ............................................................................................................... 12 1.3 METODOLOGIA ............................................................................................................................. 12 1.4 ESTRUTURA DO TRABALHO .......................................................................................................... 13
2 FUNDAMENTAÇÃO TEÓRICA .............................................................................................. 14 2.1 EXPEDE INFORMÁTICA ................................................................................................................. 14 2.1.1 Estrutura Organizacional .......................................................................................................... 15 2.1.2 Clientes ..................................................................................................................................... 15 2.1.3 Help Desk ................................................................................................................................. 15 2.2 SISTEMAS DE INFORMAÇÃO .......................................................................................................... 16 2.3 SERVICE DESK E HELP DESK ........................................................................................................ 17 2.4 BASE DE DADOS DO CONHECIMENTO ........................................................................................... 18 2.5 ITIL ............................................................................................................................................. 19 2.5.1 Gerenciamento de Processos .................................................................................................... 20 2.5.1.1 Gerenciamento de Incidentes ............................................................................................... 21 2.5.1.2 Gerenciamento de Problemas ............................................................................................... 25 2.5.1.2.1 Ciclo de Vida ................................................................................................................... 28 2.6 OBRIGAÇÃO FISCAL ..................................................................................................................... 29 2.6.1 Obrigação de Emitir Cupom Fiscal .......................................................................................... 29 2.7 SISTEMAS ANALISADOS ................................................................................................................ 31 2.7.1 Atendex ..................................................................................................................................... 32 2.7.2 MySuite ..................................................................................................................................... 34 2.7.3 Webhelpdesk ............................................................................................................................. 34 2.7.4 Milldesk .................................................................................................................................... 35 2.7.5 Resumo dos sistemas similares ................................................................................................. 36 2.8 TECNOLOGIAS UTILIZADAS NO PROJETO ....................................................................................... 37 2.8.1 PHP ........................................................................................................................................... 37 2.8.2 Zend Framework ....................................................................................................................... 38 2.8.3 JQuery ....................................................................................................................................... 39 2.8.4 SGBD Firebird .......................................................................................................................... 39 2.8.5 Apache 2 ................................................................................................................................... 40
viii
3 DESENVOLVIMENTO .............................................................................................................. 42 3.1 ANÁLISE DE REQUISITOS .............................................................................................................. 42 3.1.1 Informações Sobre o Sistema ................................................................................................... 42 3.1.2 Situação Atual ........................................................................................................................... 43 3.1.3 Situação Proposta ...................................................................................................................... 44 3.2 REQUISITOS FUNCIONAIS ............................................................................................................. 47 3.2.1 Requisitos não Funcionais ........................................................................................................ 48 3.3 DIAGRAMA DE CASOS DE USO ..................................................................................................... 49 3.4 DIAGRAMA DE CLASSES ............................................................................................................... 57 3.5 DIAGRAMA DE BANCO DE DADOS ................................................................................................ 59 3.6 IMPLEMENTAÇÃO ......................................................................................................................... 60 3.6.1 Ferramentas utilizadas .............................................................................................................. 60 3.6.2 Criação da base de dados .......................................................................................................... 60 3.6.3 Criação dos scripts PHP ............................................................................................................ 61 3.7 INTERFACE, TESTES E RESULTADOS ............................................................................................. 63 3.7.1 Avaliação da abertura de atendimento ...................................................................................... 64 3.7.2 Plano de testes ........................................................................................................................... 70 3.7.3 Validação e implantação do sistema ......................................................................................... 73
4 CONSIDERAÇÕES FINAIS ...................................................................................................... 74
9
1 INTRODUÇÃO
Segundo O'Brien (2007), as empresas sempre necessitaram de sistemas de informação para
processar e organizar os dados gerados pela administração de seus negócios.
[...] nos últimos anos de aplicação prática dos recursos de TIC (Tecnologia da Informação e Comunicação) no ambiente empresarial foram repletos de inovações. Essas mudanças não afetaram apenas o setor tecnológico, mas também os próprios ambientes empresariais que usufruem deste tipo de tecnologia como meio, chegando até, em algumas situações, a definir o próprio modelo de negócios. (SILVA, 2011, p. 1).
O objetivo de um sistema de informação para uma empresa é fornecer soluções
organizacionais e gerenciais, melhorando processos, tornando-se, assim, uma ferramenta estratégica
para superar os desafios apresentados. Esses sistemas transformam dados brutos em informações
úteis por meio de três atividades básicas: entrada, processamento e saída (LAUDON; LAUDON,
2004, p. 31).
As fornecedoras dessas soluções precisam auxiliar as empresas em seus negócios, facilitando
suas tarefas diárias, respondendo questões, tirando dúvidas ou resolvendo problemas de TI
(Tecnologia da Informação), isto é, prestando suporte técnico especializado para a continuidade das
operações das empresas contratantes. Em fornecedoras com estrutura organizacional mais definida,
geralmente, estas atividades são desempenhadas por um setor denominado Help Desk, utilizando
sistemas de atendimento ao cliente.
Este tipo de software tem a função de auxiliar a equipe de suporte para coordenar e solucionar os incidentes que ocorrem com os usuários, assegurando que os chamados gerados por estes incidentes não sejam perdidos, esquecidos ou negligenciados. Este tipo de sistema constitui em um mecanismo computacional facilitador da informação (CAVALARI; COSTA, apud PRIGOL, 2007 p. 11).
A Expede Informática, empresa de desenvolvimento de software ERP (Enterprise Resource
Planning ou Sistema Integrado de Gestão Empresarial), vem procurando prestar um melhor
atendimento a seus clientes. Para isso a Expede tem a disposição de seus clientes um setor de
atendimento ao cliente ou Help Desk, que utiliza um sistema desenvolvido pela própria empresa,
denominado Atendex.
Este sistema de atendimento, atualmente, não tem suprido satisfatoriamente as necessidades
de informações dos usuários, pois o volume de informações aumentou grandemente e a recuperação
das mesmas para utilização em solução de problemas similares não tem acontecido, principalmente
por não haver nenhum vínculo ou palavra-chave que se possa pesquisar.
10
A empresa Expede, através de seus sócios, pretende fazer um melhor acompanhamento dos
atendimentos, e como o sistema atual não possui recursos de medidas e custos nos atendimentos,
optou-se pelo desenvolvimento de um novo sistema de atendimento. Esta necessidade visa atender,
também, o planejamento estratégico da empresa no aspecto de melhoria dos serviços prestados e
controle da produtividade de seus colaboradores.
Para sobreviver, as empresas precisam descobrir maneiras de fornecer aos clientes mais valor e serviço a custo mais baixo. Muitas acreditam que a solução esteja no melhoramento dos processos do negócio para interagir com clientes e para produzir e entregar produtos ou serviços (LAUDON; LAUDON, 2004, p. 53).
Este trabalho objetivou o desenvolvimento de um sistema para auxiliar o setor de Help Desk
no atendimento ao cliente, e que no futuro ele venha fazer parte de um conjunto sistemas que têm
como objetivo bom relacionamento com o cliente, também conhecido como CRM (Customer
Relationship Management).
1.1 Problematização
1.1.1 Formulação do Problema
As empresas do segmento de comércio (atacadistas e varejistas) dependem cada vez mais da
Tecnologia da Informação para dar suporte aos seus negócios e cumprirem as obrigações fiscais. A
ocorrência de problemas técnicos pode acarretar na perda de faturamento e de clientes, afetando a
sustentabilidade financeira e a credibilidade de uma empresa.
Dentre as obrigações fiscais, a legislação determina as empresas deste segmento a contratar
empresas fornecedoras de sistemas de informação que estejam homologados para fazer a integração
com o equipamento denominado Emissor de Cupom Fiscal (ECF).
As empresas fornecedoras de sistemas de informação precisam manter uma equipe
especializada em suporte técnico para prestar atendimento presencial e remoto em caso de
problemas e atualizações do sistema. Trata-se de um setor ou departamento da empresa denominado
Help Desk ou Service Desk.
A Expede Informática, empresa situada na cidade de Porto Belo/SC, atua na locação de
sistemas de informação ERP com emissão de cupom fiscal e nota fiscal eletrônica. Atende seus
clientes por meio de um setor de suporte técnico, responsável pela instalação e manutenção de seus
sistemas, e também pelo treinamento necessário para uma boa utilização dos mesmos.
11
Os atendimentos podem ser feitos por meio de telefone, correio eletrônico, skype, acesso
remoto, ou quando necessário, é feito um deslocamento até o cliente.
Para registro de informações e acompanhamento aos chamados, a Expede utiliza um sistema
denominado Atendex, o qual não tem atendido satisfatoriamente seus usuários (técnicos), pois as
informações registradas raramente são recuperadas para utilização ou comparação com problemas
registrados anteriormente; não existe um controle do tempo despendido pelo usuário para a
resolução de um problema, nem do número de vezes que este ocorreu; existe ainda um problema
quanto à criação das tabelas no Firebird, foram utilizados charset incorreto que não está associado a
ele nenhuma collation, o que inviabiliza a pesquisa tipo case-insensitive, ou seja, dificulta a
pesquisa por informações no banco, referentes à acentuação ou nasalização das palavras.
Também não há separação entre problemas nos sistemas e dúvidas dos usuários; durante o
registro de um chamado não há como acessar registros de chamados antigos sem fechar a tela de
registro atual, entre outras funcionalidades não contempladas no atual sistema.
Os diretores da Expede Informática têm manifestado a necessidade de acompanhar melhor o
departamento de suporte para obter informações sobre os tipos de problemas que mais acontecem e
a atuação dos técnicos no atendimento aos clientes, mas com as deficiências do sistema não têm
sido possível esse acompanhamento.
O sistema foi desenvolvido sem o devido planejamento e documentação, por diversos
programadores que trabalharam na empresa. O código-fonte não segue padrões de qualidade e é de
difícil manutenção. Esta realidade reforçou a intenção dos diretores no desenvolvimento de um
novo sistema para o setor de suporte técnico.
1.1.2 Solução Proposta
Com base nas necessidades da Expede Informática, propôs-se neste trabalho, desenvolver
um sistema de suporte técnico ao cliente, em substituição ao sistema atual, que contenha um
registro mais aprimorado dos atendimentos e das soluções aos problemas relatados, além de
fornecer informações gerenciais que auxiliem os diretores nos processos de tomada de decisão.
Aplicou-se os conceitos de Gerenciamento de Incidentes do ITIL tanto no processo de
desenvolvimento do sistema quanto no processo de atendimento do setor de suporte técnico da
Expede.
12
Ainda que existam soluções de software comerciais para atendimento ao cliente, o sistema
implementado difere em alguns aspectos, principalmente quanto à forma de integração entre os
sistemas desktop e abertura de chamados.
Do ponto de vista da formação profissional em Ciência da Computação, este trabalho também
permitiu aplicar os conhecimentos adquiridos durante o curso, como sistemas de informações,
banco de dados e engenharia de software.
1.2 Objetivos
1.2.1 Objetivo Geral
O objetivo geral deste trabalho foi desenvolver um novo sistema de informação para auxiliar
o suporte aos clientes da empresa Expede, utilizando os conceitos do Gerenciamento de Incidentes
do ITIL.
1.2.2 Objetivos Específicos
Os objetivos específicos deste trabalho de pesquisa foram:
• Estudar o sistema atual e soluções similares;
• Identificar as necessidades de melhorias e novos requisitos;
• Pesquisar os conceitos e tecnologias para a implementação do sistema;
• Analisar o projeto do sistema proposto;
• Implementar o módulo atendimento ao cliente;
• Testar e validar a implementação do sistema;
• Documentar o desenvolvimento e os resultados do sistema.
1.3 Metodologia
Para realização deste trabalho foram realizadas entrevistas com dois usuários do sistema atual,
e também foram submetidos questionários para a apuração de algumas necessidades faltantes no
sistema atual.
13
Também foram avaliados a forma como os dados estão armazenados nas tabelas e a forma
como são apresentados aos usuários. Três soluções similares foram avaliadas para aproveitar os
benefícios de cada um deles e se possível aplicá-los em nosso estudo.
No escopo do desenvolvimento de software, não é possível afirmar que haja um único modo válido de construir uma solução, ou que seja melhor que todos os outros, sob quaisquer condições. Assim, metodologias diversas podem estabelecer seqüências diversas de desenvolvimento, bem como levar a resultados diferentes.
[...] Certamente, há caminhos de desenvolvimento que levam a resultados satisfatórios [...]. Uma metodologia adequada é aquela que permite levar a um resultado satisfatório. (SILVA, 2009).
Para a modelagem do projeto proposto, optou-se por utilizar as metodologias de análise e
projeto orientados a objetos com a notação da UML.
Em função da aderência à proposta de trabalho, foram descritos os conceitos de
Gerenciamento de Processos do ITIL na fundamentação teórica e aplicadas as recomendações para
a melhoria do processo de atendimento dos clientes da Expede, refletindo na melhor especificação
dos requisitos na fase de projeto do novo sistema de informação.
1.4 Estrutura do Trabalho
O trabalho está divido em três capítulos: o Capítulo 1 aborda de maneira sucinta os conceitos
básicos aplicados atualmente nos serviços de suporte a TI.
No Capítulo 2 os conceitos são mais aprofundados e os que serão aplicados ao projeto são
colocados em foco. Soluções similares também são avaliadas.
O Capítulo 3 apresenta a desenvolvimento, construído utilizando a UML, contendo os
requisitos funcionais e não funcionais, o Diagrama de Casos de Uso e o Diagrama de Classes.
14
2 FUNDAMENTAÇÃO TEÓRICA
Este capítulo contém os conceitos que envolvem a elaboração de um projeto para
desenvolvimento de um sistema de suporte aos serviços de TI para a empresa Expede Informática,
mais especificamente, ligado ao processo de Gerenciamento de Incidentes do ITIL. Inicialmente,
será descrita de maneira resumida a empresa Expede Informática.
2.1 Expede Informática
Fundada em 1996 e situada na cidade de Porto Belo/SC, a Expede Informática é uma empresa
de desenvolvimento de software para empresas de comércio varejista e atacadista.
Os sistemas desenvolvidos pela Expede Informática são fornecidos em forma de licença de
uso com pagamento de mensalidade, e o serviço de suporte ao cliente faz parte do contrato com o
cliente.
Os principais softwares desenvolvidos pela Expede são:
• X-Way: Utilizado geralmente em empresas de comércio varejista, tais como loja de
calçados, loja de roupas, seu foco está na venda direta ao consumidor final e na
emissão de cupom fiscal, sendo que este está homologado para utilização em PAF-
ECF (Programa Aplicativo Fiscal – Emissor de Cupom Fiscal), possui módulos para
gestão financeira básica, entrada de mercadorias através de nota fiscal eletrônica,
controle de estoque entre outras funcionalidades de um sistema ERP;
• Next: Geralmente utilizado por empresas atacadistas como Distribuidoras, também
utilizado em empresas importadoras, possui os mesmos módulos do X-Way, porém
não está certificado para PAF-ECF, está focado na emissão de nota fiscal eletrônica;
• X-Life: Sistema desenvolvido para uso em restaurantes está homologado para efetuar
comunicação com PAF-ECF, possui um módulo de tele-entrada que conecta o telefone
à placa de som do computador para identificar as chamadas, e também um módulo
para utilização em equipamentos touche screen.
15
2.1.1 Estrutura Organizacional
Com 14 funcionários divididos nos setores de financeiro, vendas, desenvolvimento e suporte,
a Expede possui três sócios, sendo responsáveis pelos seguintes setores: um no financeiro, outro
para vendas e o terceiro para a área técnica (desenvolvimento e suporte), sendo que o sócio do setor
financeiro atua ainda sobre os outros setores fazendo um acompanhamento geral da empresa.
O setor de desenvolvimento possui seis funcionários, dois deles, trabalham apenas meio
período e um atua no desenvolvimento de novas aplicações para web; os demais trabalham na
criação de novas funções e manutenção dos sistemas atuais.
O setor de vendas conta com dois funcionários para aquisição de novos clientes, sendo que
um ainda pode atuar na instalação dos sistemas e no treinamento de clientes.
O setor de suporte técnico conta com quatro funcionários para fazer instalação, treinamento e
passar orientações dos sistemas aos clientes. Existe ainda um funcionário apenas para a manutenção
interna dos equipamentos da empresa.
2.1.2 Clientes
Conforme Cristiano Giovani Techio (2011), sócio da empresa Expede Informática e
responsável pelo setor de suporte técnico, os clientes da Expede, são em sua maioria empresas de
comércio varejista e atacadistas e geralmente estão situados na região do Vale do Itajaí, alguns no
Oeste Catarinense e em outras regiões do Brasil.
A empresa possui atualmente cerca de 500 (quinhentos) clientes ativos, sendo que 60% destes
são empresas de comércio varejista e atacadista.
2.1.3 Help Desk
O setor de suporte técnico ou Help Desk, registra mensalmente cerca de 500 (quinhentos)
chamados de diversas empresas, que podem ser dúvidas de clientes, falhas nos sistemas, reset
remoto, ou falhas nos equipamentos.
• Dúvidas: podem ser desde como cadastrar um cliente até como vender produtos que
possuem substituição tributária.
16
• Falhas: podem incluir problemas de travamentos de cupons nos ECFs, até diferenças
no estoque dos produtos.
• Reset Remoto: para que o sistema continue funcionando, estes recebem um número
de dias para funcionar até determinada data, mesmo que o sistema não seja utilizado,
ao final desta data, para continuar funcionando o cliente precisa fazer um reset remoto
e carregar novos créditos ao sistema, para isso o cliente entra em contato com o
suporte e através de um código renova os créditos.
• Falhas nos equipamentos: muitas vezes, o cliente não consegue detectar que o
problema está no equipamento, um exemplo são os ECF´s, quando o equipamento
apresenta problemas, é necessário entrar em contato para que seja feito um diagnóstico
através de programas específicos do fabricante, só então, se constatado problemas é
informado ao cliente para que entre em contato com o fabricante ou representante
técnico para efetuar reparos; problemas com certificados digitais, por se tratar de uma
tecnologia nova para a maioria dos clientes, ainda existem muitas dúvidas sobre sua
utilização, como efetuar backup do certificado, quando adquirir um certificado novo
etc.; outras falhas em equipamentos também podem ser diagnosticadas pelo suporte,
mas estes são geralmente encaminhados para técnicos de hardware específicos.
Faz parte ainda das responsabilidades do Help Desk, instalar, configurar, passar treinamento,
esclarecer dúvidas, detectar problemas, solucioná-los ou repassá-las aos responsáveis pela solução.
Os contatos com os clientes são efetuados através de telefone, skype ou e-mail, e para
atendimento são utilizadas ferramentas de acesso remoto como UltraVNC, Radmin, Remote
Desktop e TeamViewer dependendo do cliente, e quando necessário é feito um deslocamento de um
técnico até a empresa do cliente.
2.2 Sistemas de Informação
Antes de abordar o assunto principal, convém apresentar uma definição de Sistema de
Informação, e segundo Kenneth e Jane Laudon.
Um sistema de informação pode ser definido tecnicamente como um conjunto de componentes inter-relacionados que coleta, (ou recupera), processa, armazena e distribuem informações destinadas a apoiar a tomada de decisões a coordenação e o controle de uma organização. (LAUDON; LAUDON, 2004, p. 7)
17
Atualmente, com a necessidade cada vez maior de se ter a informação em maior velocidade, e
com maior confiabilidade, o uso dos sistemas informatizados são essenciais, e uma boa organização
destes sistemas também.
Segundo O'Brien (2007), em um negócio podemos classificar os sistemas de informação de
vários modos diferentes, e como exemplo temos os sistemas operacionais e gerenciais, classificados
desta forma para enfatizar seus objetivos.
“Os sistemas de nível operacional dão suporte aos gerentes operacionais, acompanhando
atividades e transações elementares da organização” (LAUDON; LAUDON, 2004, p. 39).
A Figura 1 mostra a classificação dos sistemas de informação, segundo O’BRIEN (2007).
2.3 Service Desk e Help Desk
Help Desk - A palavra é um termo inglês, que se descreve como serviço de apoio ao usuário. O Help Desk é uma área especializada na resolução de problemas, e suporte técnico a equipamentos de informática e telecomunicações, seja por telefone ou acesso remoto, com o objetivo de auxiliar e resolver problemas que os usuários possam ter. O objetivo maior do Help Desk é fornecer aos usuários um ponto único de contato (SPOC - Single Point Of Contact), essencial para a comunicação entre os usuários e os profissionais da TI. (FERREIRA, 2008).
Service Desk é a evolução do Help Desk, é maior em qualidade e abrangência. Ele centraliza
as necessidades de uma empresa em um único ponto (PUC – Ponto Único de Acesso), registrando
entrada e saída de pedidos de suporte e manutenção, para ter um maior controle sobre o que foi
feito. (LIBERATO, 2009).
Figura 1 - Tipos de Sistemas de Informação Fonte: O’BRIEN (2007).
18
A missão principal do Service Desk é restabelecer a operação normal dos serviços dos
usuários o mais rápido possível, minimizando o impacto nos negócios causados por erros de TI.
Para a resolução de um problema um chamado pode passar por vários níveis de atendimento até que
este seja resolvido. Na Figura 2 observa-se as principais atribuições do Service Desk.
Figura 2 - Atribuições do Service Desk Fonte: P2HE Processos & TI
2.4 Base de Dados do Conhecimento
Um dos propósitos do desenvolvimento de um novo sistema para o atendimento dos clientes
da empresa Expede é registrar de maneira mais formal as soluções encontradas pelos técnicos nas
diversas situações de problemas relatados. Trata-se de uma abordagem relacionada com a gestão do
conhecimento organizacional.
Segundo Davenport e Prusak (apud STRAUSS, 2004, p. 23), existem três tipos básicos de repositório de conhecimento: conhecimento externo, conhecimento interno e estruturado e conhecimento interno informal. O conhecimento interno e estruturado – memorandos, relatórios e artigos - pode ser facilmente armazenado e recuperado. Já conhecimentos mais informais são armazenados, por exemplo, um banco de dados de discussão, onde os participantes registram suas experiências em um assunto e reagem aos comentários dos outros. Quase sempre quando se deseja extrair conhecimento tácito dos funcionários, as organizações recorrem às listas eletrônicas de discussão.
[...] o conhecimento, dentro da base de dados, deve ser classificado por categorias e palavras-chave, além de contar com um glossário para auxiliar a navegação do usuário pelo
19
sistema, através de termos familiares a ele estas bases de dados devem estar conectadas entre si, pois conforme TERRA (apud STRAUSS, 2004), o problema em grandes organizações não é quantidade ou a profundidade das bases de dados, mas sim sua conexão.
2.5 ITIL
A ITIL (Information Technology Infrastructure Library) é um framework composto por boas
práticas para serem aplicados aos serviços de TI, fornecendo orientações que visam à melhoria
contínua da qualidade envolvendo pessoas, processos e tecnologia, alinhando a TI ao negócio, de
modo a agregar valor à organização. (MAGALHÃES; PINHEIRO, 2007).
Entre seus benefícios, destacam-se: qualidade de serviço, melhoria no cumprimento de prazos
de entrega, resolução de serviços e segurança.
A ITIL busca prover serviços de alta qualidade, com foco no relacionamento com os clientes, trazendo algumas mudanças significativas como: faz com que o negócio foque no valor e não no custo; nos faz pensar em toda a cadeia que envolve a prestação de serviços e não em uma visão fragmentada; e internamente transfere o olhar para processos e pessoas, e não apenas na tecnologia. (Fragata, Marques; Romero, 2006)
Figura 3 - Relacionamento entre Processos do ITIL Fonte: MAGALHÃES; PINHEIRO (2007).
A Figura 3 mostra, segundo a ITIL, os processos necessários ao funcionamento de uma área
de TI, para permitir o máximo de alinhamento entre as áreas de TI e as demais áreas de negócio de
modo a garantir a geração de valor à organização.
É importante ressaltar que este trabalho ficou delimitado à área de suporte a serviços da ITIL.
20
2.5.1 Gerenciamento de Processos
A Gerência dos Serviços de Tecnologia da Informação (TI) é formada por um conjunto de
processos que não podem ser visto isoladamente, pois estão inter-relacionados. Estes processos
necessitam ser coordenados para obtenção de um mesmo objetivo.
Um Gerente é designado para acompanhar os processos do Serviço de TI, pois estes podem se
tornar complexo, para cada um destes processos, existe um modelo de gerenciamento particular.
Objetivos do Gerenciamento de Processos (MAGALHÃES; PINHEIRO, 2007, p. 65):
• Aumentar a qualidade dos serviços;
• Aumentar a previsibilidade do comportamento;
• Diminuir o custo alocado.
Os processos de suporte aos serviços de TI podem ser classificados como: Operacionais,
Táticos e Estratégicos, conforme mostra a Figura 4.
Figura 4 - Posicionamento dos Processos da ITIL Fonte: MAGALHÃES; PINHEIRO (2007).
Os processos responsáveis pelo suporte aos serviços de TI são de nível operacional.
O Modelo de referência de processos da ITIL possui duas áreas fundamentais para sua
organização: Suporte ao Serviço e Entrega do Serviço.
Este trabalho foca-se no modelo de Suporte ao Serviço, onde se concentram tarefas de
execução diária, necessárias para manutenção dos serviços de TI já entregues e em utilização pela
organização, alguns citados a seguir.
21
2.5.1.1 Gerenciamento de Incidentes
Seu objetivo é tratar e resolver os incidentes observados no serviço de TI no menor prazo
possível, minimizando o impacto causado ao negócio do cliente.
Para isso, em alguns casos é necessário utilizar soluções como o workaround (solução de
contorno), uma forma de resolver o problema de maneira provisória, até que uma definitiva seja
encontrada.
Para um melhor entendimento a definição de alguns conceitos se faz necessária.
Um incidente é definido como qualquer evento que não faz parte da operação normal de um
serviço e que cause, ou possa causar uma interrupção do serviço ou a redução da sua qualidade.
Desta forma, a Gestão de Incidentes visa restaurar o serviço no menor tempo possível para
minimizar os impactos para o negócio e garantir a disponibilidade e os melhores níveis de serviço
possíveis. (SANTOS, 2010).
Initial support team – também chamada de Suporte de Primeiro Nível, é a equipe responsável
pelo atendimento inicial de solicitação de serviço do cliente, também responsável por identificar e
diagnosticar o problema, e resolver se existir uma solução conhecida registrada.
Solicitação de serviço – trata-se de uma requisição de serviço, sejam por problemas ou
apenas dúvidas.
Erro conhecido – Ocorre quando é utilizada uma solução provisória (workaround), ou pode
ser um registro de uma solução definitiva.
Estado – Posição em que o incidente se encontra.
Carga de trabalho – É o tempo e o esforço dispensado durante cada atividade do processo de
resolução do incidente.
22
Um fator relevante, para o bom entendimento é o escalonamento e a interação do incidente
com os demais processos, realizado durante seu atendimento, método utilizado para obtenção de
resultados em menor período de tempo. A Figura 5 ilustra seu funcionamento.
Figura 5 - Evolução até a implementação da solução Fonte: MAGALHÃES; PINHEIRO (2007).
Descrição do processo
O início do processo de Gerenciamento de Incidentes acontece quando há uma solicitação de
um serviço, ou através de um evento gerado pelo sistema que monitora e gerencia as atividades dos
sistemas.
Neste primeiro momento, são registrado dados básicos sobre o atendimento, mas que são
importantes para entendimento, e construção de um histórico.
Segundo Magalhães e Pinheiro (2007, p. 136), a equipe de Gerenciamento de Incidentes,
atendimento de primeiro nível é responsável por:
• Análise das chamadas, detecção e registro dos incidentes.
• Classificação de todos os incidentes.
• Suporte de primeiro nível.
• Pesquisa da causa.
• Diagnóstico da solução.
• Resolução e recuperação dos serviços de TI.
• Encerramento do incidente.
23
Na Figura 6, o fluxograma que demonstra os passos para resolução de um incidente.
Figura 6 - Exemplo de processo de Gerenciamento de Incidente Fonte: MAGALHÃES; PINHEIRO (2007).
O analista de suporte do primeiro nível pesquisa no BDEC (Banco de Dados de Erros
Conhecidos) por erros já registrados. Se já existir a solução, efetua-se o procedimento recomendado
no registro da solução (workaround ou solução definitiva). Para o atendimento de primeiro nível é o
fim do procedimento sob sua responsabilidade.
Caso o incidente não esteja registrado ou não possua uma solução registrada, o incidente
deverá ser escalonado para o segundo nível de suporte, neste nível é feito um acompanhamento
detalhado, incluindo os IC’s (itens de configuração), começa então, a pesquisa para a resolução do
incidente. Caso não seja encontrada uma solução adequada, passa-se para o terceiro nível, onde o
processo é reiniciado.
Através da avaliação detalhada das informações registradas, uma das atividades do processo, ocorrerá à classificação e suporte inicial onde o incidente será categorizado (hardware/software/requisição/segurança...) e sua prioridade será definida, levando em consideração o impacto sobre o negócio do serviço e urgência com que o incidente deve ser solucionado. Ao final, o analista deve informar o Service Desk o qual contacta o usuário a fim de verificar se a solução foi satisfatória e eficaz, obtida resposta positiva o processo se encerra e o incidente pode ser fechado. (SILVA;LIRA, 2011).
Durante o processo mostrado na Figura 6, um incidente pode assumir vários estados,
conforme Tabela 1.
24
Tabela 1 - Indicadores de Estado
Estado Descrição
Novo Estado do incidente ao ser registrado Aceito O incidente é denominado de “aceito” após sua primeira análise e
classificação quanto sua prioridade. Programado O estado de “programado” indica que o incidente aguarda
atendimento, já foi aceito e espera a definição de um analista para execução de atendimento técnico.
Atribuído Incidente repassado a um técnico responsável. Em andamento O incidente neste estado significa que sua investigação e diagnostico
já foram iniciados. Em espera O incidente neste estado significa que sua investigação e diagnostico
foram suspensos. Resolvido Foi implementado workaround ou permanent fix e aplicado ao
incidente. Serviço de TI afetado foi solucionado. Encerrado A equipe do Service Desk contacta o usuário, informa que o serviço
foi solucionado e obtém a confirmação da restauração do serviço de TI.
Para um melhor entendimento por parte da equipe é necessário manter a padronização quanto
aos estados e seus significados. (MAGALHÃES; PINHEIRO, 2007).
Ainda segundo Magalhães e Pinheiro (2007, p. 138), são responsabilidades do Gerente de
Incidentes:
• Gerenciar o processo de atendimento de incidentes de modo a mantê-lo eficiente e
eficaz.
• Produzir informações gerenciais que permitam a organização tomar decisões em
relação aos incidentes com os serviços de TI.
• Gerenciar o trabalho das diversas equipes de suporte técnico.
• Monitorar a efetividade do processo de Gerenciamento de Incidentes, recomendando
ações para garantir a melhoria contínua do atendimento aos incidentes.
• Desenvolver e manter o sistema de suporte ao processo de Gerenciamento de
Incidentes.
Quanto ao escalonamento, existem dois tipos: o funcional e o hierárquico.
No escalonamento funcional os incidentes são encaminhados para os membros da equipe com
conhecimento mais específico sobre o assunto do problema. Se a equipe que cuida de operações não
possuir conhecimento sobre a aplicação, poderá passar o atendimento para a equipe de aplicações.
25
Quando existir necessidade de decisão ou envolver custos é feito um escalonamento hierárquico. A
Figura 7 mostra os tipos de escalonamento.
Figura 7 - Escalonamento Fonte: SEZANOWITCH (2011).
2.5.1.2 Gerenciamento de Problemas
Um problema é definido como a causa desconhecida de um ou mais incidentes. O objetivo da Gestão de Incidentes é minimizar os impactos dos incidentes para o negócio, causados por erros na infraestrutura, e prevenir a recorrência de incidentes relacionados a estes erros. Para atingir seu objetivo, a Gestão de Problemas procura descobrir a causa-raiz dos incidentes e promover as ações necessárias para corrigir a situação. (SANTOS, 2010).
Este processo tem como finalidade assegurar que as falhas sejam corrigidas e que ocorrências
futuras de um mesmo incidente sejam minimizadas, ou eliminadas.
Quando incidentes começam a ocorrer repetidas vezes, e uma solução definitiva não é
encontrada por parte da equipe de suporte, a imagem da empresa perante o cliente fica abalada, e
acaba aumentando os custos de trabalho da equipe (MAGALHÃES; PINHEIRO, 2007, p. 65).
Tudo neste processo tem como objetivo localizar erros conhecidos, identificar soluções
alternativas, levantar as soluções de alteração se necessário, corrigir e testar para certificar que o
problema não mais existe.
Também faz parte de sua tarefa, identificar o problema e corrigi-lo antes que eles venham a
ocorrer em outros clientes.
Os Processos de Gerenciamento de Problema e de Gerenciamento de Incidentes estão
fortemente interligados, pois um trabalho bem feito pelo Gerenciamento de Incidentes pode facilitar
significativamente o trabalho do Gerenciamento de Problema.
A classificação correta pode fazer com que um incidente
seja rapidamente corrigido e enviado para atualização no cliente, des
Gerenciamento de Incidentes.
A Figura 8 ilustra a relação do processo de Gerenciamento de Problema com o processo de
Gerenciamento de Incidente.
Um incidente difere de um problema porque enquanto a Gerência de Incidentes tenta resolver
o problema o mais rápido possível, usando todos os seus recursos, a Gerência de Problemas vai à
raiz do problema, buscando uma solução defin
Figura Fonte:
O Gerenciamento de Incidentes, após prover soluções de contorno para o problema, entrega
para o Gerenciamento de Problemas o qual com o problema já identificado, verifica se existe uma
solução de contorno registrada com as informações
Identificador: associar ao problema um único identificador;
Categoria: para identificar onde ocorreu o problema;
Severidade: para poder quantificar o impacto que o problema causou no cliente;
Prioridade: ordem para identificar quais prob
Resumo do Problema:
26
A classificação correta pode fazer com que um incidente que esteja ocorrendo regularmente
seja rapidamente corrigido e enviado para atualização no cliente, desta vez facilitando o trabalho do
ilustra a relação do processo de Gerenciamento de Problema com o processo de
Um incidente difere de um problema porque enquanto a Gerência de Incidentes tenta resolver
o problema o mais rápido possível, usando todos os seus recursos, a Gerência de Problemas vai à
raiz do problema, buscando uma solução definitiva para o problema. (SANTOS
Figura 8 - Integração Incidente x Problema Fonte: MAGALHÃES; PINHEIRO (2007).
O Gerenciamento de Incidentes, após prover soluções de contorno para o problema, entrega
para o Gerenciamento de Problemas o qual com o problema já identificado, verifica se existe uma
solução de contorno registrada com as informações a seguir:
ssociar ao problema um único identificador;
ara identificar onde ocorreu o problema;
ara poder quantificar o impacto que o problema causou no cliente;
rdem para identificar quais problemas serão resolvidos prime
: descrição simplificada, breve e clara sobre o problema encontrado;
que esteja ocorrendo regularmente
ta vez facilitando o trabalho do
ilustra a relação do processo de Gerenciamento de Problema com o processo de
Um incidente difere de um problema porque enquanto a Gerência de Incidentes tenta resolver
o problema o mais rápido possível, usando todos os seus recursos, a Gerência de Problemas vai à
SANTOS, et. al., 2008).
O Gerenciamento de Incidentes, após prover soluções de contorno para o problema, entrega-o
para o Gerenciamento de Problemas o qual com o problema já identificado, verifica se existe uma
ara poder quantificar o impacto que o problema causou no cliente;
lemas serão resolvidos primeiro;
escrição simplificada, breve e clara sobre o problema encontrado;
27
Descrição: neste item há um espaço para um melhor detalhamento, com informações para que
a Gerência de Problema possa localizar, e replicá-lo se for necessário;
Comunicado por: quem registrou o problema, caso necessário de maiores detalhes saber
quem fez um primeiro contato;
Responsável: quem tem a responsabilidade de resolver o problema;
Estado: situação em que o problema se encontra (aberto, pendente, etc.);
Solução de contorno: a descrição da solução de contorno pode ajudar ao Gerenciamento de
Problemas solucionar o problema mais rapidamente;
Número de solicitações: numero de vezes que o incidente foi relatado;
Resolução: solução definitiva para o problema.
É também a Gerência de Problema que aconselha e Gerenciamento de Incidentes sobre a
melhor forma de contornar um incidente.
A grande maioria dos departamentos de suporte passam o dia sob pressão, apagando incêndio,
por causa do grande volume de chamados, e devido à falta de tempo a equipe acaba resolvendo-o de
forma provisória, e não foca na resolução definitiva do problema. (MAGALHÃES; PINHEIRO,
2007).
Uma forma de reduzir a quantidade de incidentes é evitando que ele volte a acontecer. Este
processo tem também função de registrar os erros conhecidos e suas soluções de contorno, fazendo
com que a maioria dos incidentes sejam resolvidos ainda no 1º nível.
O Gerenciamento de Problemas na ITIL tem quatro atividades primárias:
1. Controle de Erro Conhecidos
Controle de erros abrange os processos associados à realização de Erros Conhecidos até que
sejam eliminados pela implementação bem sucedida de uma mudança sob o controle do
Gerenciamento de Mudanças processo. O objetivo do controle de erro é estar ciente dos erros, para
monitorá-los e eliminá-los quando viável e de custo justificável.
Este processo tem como missão minimizar a interrupção nos serviços de TI através da
organização dos recursos para solucionar problemas de acordo com as necessidades de negócio,
prevenindo a recorrência dos mesmos e registrando informações que melhorem a maneira pela qual
28
a organização de TI trata os problemas, resultando em níveis mais altos de disponibilidade e
produtividade. (PEREIRA, 2007).
Alguns dos principais objetivos são:
• Minimizar os efeitos adversos nos negócios;
• Tratar incidentes e problemas causados por erros na infraestrutura;
• Prevenir proativamente a ocorrência dos incidentes, problemas e erros;
• Reduzir o número geral de incidentes.
2. Suporte ao Atendimento de Incidentes Graves
O Processo de Gerenciamento de Incidentes necessita de apoio para resolução de problemas
classificados como graves, esta é a parte do Gerenciamento de Problemas que garante auxílio ao
Gerenciamento de Incidentes.
3. Prevenção Proativa de Problema
Deve garantir que novos incidentes ou problemas com infraestrutura de TI não venham a
ocorrer.
• Identificação e Tendência
Por meio da análise de incidentes reportados pelos usuários dos serviços de TI, esta atividade
é responsável por identificar problemas que tendem a ocorrer, antes de ocorrerem. Faz-se necessário
associar a experiência profissional dos analistas da equipe de suporte aos serviços de TI, para
determinar a existência de um problema na infraestrutura.
4. Revisão Pós-Implementação
Esta atividade é responsável pelo acompanhamento e validação do resultado da mudança
implementada pelo Gerenciamento de Mudança, somente após esta validação poderá dar por
encerrado os problemas a este referente.
2.5.1.2.1 Ciclo de Vida
Qualquer membro da equipe de Gerenciamento de Problemas poderá fazer o registro e a
identificação de um problema.
29
O responsável irá diagnosticar o problema e resolvê-lo, ou ainda transferir a responsabilidade
para outra pessoa apta a resolvê-lo.
“Caso a causa do problema tenha sido encontrada e corrigida, modifica-se a situação do registro do problema para Resolvido, registrando-se também como este foi resolvido e a configuração que será liberada para verificação. Se o responsável por resolver o problema não conseguir reproduzi-lo, ele cancela o registro do problema.” (MAGALHÃES; PINHEIRO, 2007, p. 157).
A Figura 9, mostra o ciclo de vida de um problema.
Figura 9 - Ciclo de Vida de um problema Fonte: MAGALHÃES; PINHEIRO (2007).
A implementação da Gestão de Problemas resulta na melhora na qualidade dos serviços, redução no volume de incidentes, visto que a causa-raiz dos mesmos é tratada, evitando que os mesmos voltem a ocorrer, aumenta a produtividade do usuário e da equipe de suporte e proporciona melhores taxas de resolução na primeira tentativa pelo Service Desk através da disponibilização de Soluções Definitivas e Soluções de Contorno nos bancos de dados de conhecimento.
Geralmente, a Gestão de Problemas não é um processo bem definido nas áreas de TI, visto que dificilmente profissionais são alocados para executar exclusivamente estas atividades, mas é freqüentemente um dos processos do ITIL que proporciona os melhores retornos. (SANTOS, 2010).
2.6 Obrigação Fiscal
2.6.1 Obrigação de Emitir Cupom Fiscal
Por meio de Decreto Lei, em 1997 o governo Federal, tornou obrigatório que determinadas
empresas passassem a fazer uso de equipamento emissor de cupom fiscal, alterando
significativamente a forma como eram gerados os documentos fiscais, conforme citado a seguir.
30
Art. 61. As empresas que exercem a atividade de venda ou revenda de bens a varejo e as empresas prestadoras de serviços estão obrigadas ao uso de equipamento Emissor de Cupom Fiscal - ECF.
§ 1º Para efeito de comprovação de custos e despesas operacionais, no âmbito da legislação do imposto de renda e da contribuição social sobre o lucro líquido, os documentos emitidos pelo ECF devem conter, em relação à pessoa física ou jurídica compradora, no mínimo:
a) a sua identificação, mediante a indicação do número de inscrição no Cadastro de Pessoas Físicas - CPF, se pessoa física, ou no Cadastro Geral de Contribuintes - CGC, se pessoa jurídica, ambos do Ministério da Fazenda;
b) a descrição dos bens ou serviços objeto da operação, ainda que resumida ou por códigos;
c) a data e o valor da operação.
§ 2º Qualquer outro meio de emissão de nota fiscal, inclusive o manual, somente poderá ser utilizado com autorização específica da unidade da Secretaria de Estado da Fazenda, com jurisdição sobre o domicílio fiscal da empresa interessada.
Art. 62. A utilização, no recinto de atendimento ao público, de equipamento que possibilite o registro ou o processamento de dados relativos a operações com mercadorias ou com a prestação de serviços somente será admitida quando estiver autorizada, pela unidade da Secretaria de Estado da Fazenda, com jurisdição sobre o domicílio fiscal da empresa, a integrar o ECF.(Lei Federal 9.532 Art. 61, 1997).
A obrigação fiscal obrigou várias empresas a contratar empresas de software que fornecessem
sistemas adequados à legislação, para evitar multas e também receber os benefícios que lei oferece
aqueles que estão de acordo.
Logo depois, por meio do ato Cotepe 06/08, e por meio do convênio ICMS 15 de abril de
2008 que dispõe sobre normas e procedimentos relativos à análise de Programa Aplicativo Fiscal
(PAF-ECF), o governo padronizou a forma com que os aplicativos se comunicavam com o ECF-IF,
estes documentos são de abrangência nacional e todas as empresas de desenvolvimento de sistemas
devem atendê-los.
O convênio ICMS 15/08 estabelece o seguinte:
Cláusula primeira: Este convênio estabelece normas e procedimentos relativos à análise funcional de Programa Aplicativo Fiscal (PAF-ECF) destinado a enviar comandos de funcionamento ao equipamento Emissor de Cupom Fiscal.
Cláusula segunda: O PAF-ECF somente poderá ser autorizado para uso nas unidades federadas, após a emissão de Laudo de Análise Funcional de PAF-ECF, em conformidade com as disposições deste convênio, e a publicação do despacho a que se refere à cláusula décima.
31
Cláusula décima: A Secretaria Executiva do CONFAZ, mediante solicitação da empresa desenvolvedora, publicará despacho, conforme modelo constante no Anexo II, comunicando o registro do Laudo de Análise Funcional de PAF-ECF.
§ 1º Após a publicação do despacho a empresa desenvolvedora deve observar os procedimentos estabelecidos pela unidade federada para apresentação do laudo, cadastro, credenciamento ou registro do PAF-ECF.
No entanto, para estar de acordo com a lei, a empresa de software precisa homologar seus
sistemas em instituições apontadas pelo governo, isso quer dizer que os softwares desenvolvidos
precisam passar por um teste para verificar se estão em conformidade com a legislação.
Cada vez que a lei federal ou estadual que dispõe sobre este assunto é alterada, o software que
emite cupom fiscal precisa ser novamente homologado junto ao órgão competente, ou ainda sempre
que o software sofrer alteração.
Após cada homologação uma nova versão é registrada no fisco de cada estado em que a
empresa comercializa seus SD’s, e pela lei é preciso substituir pela nova versão todas as bases
instaladas, passível de multa caso isso não seja feito.
Mas, como saber que versão está em qual cliente, se estas informações não estiverem
disponíveis ou registradas, e qual foi atualizado e qual não foi?
Se antes se podia protelar o investimento em novas tecnologias e procurar obter o máximo de retorno com o aplicativo comercial já desenvolvido, agora há a necessidade de investimento no curto prazo para homologar o PAF-ECF e manter o negócio em funcionamento. (LUIZE, 2008).
O objetivo desta seção foi evidenciar a legislação que obriga as empresas a contratar sistemas
homologados e que tenham suporte técnico especializado por parte das empresas fornecedoras.
A seguir, serão descritos os sistemas similares estudados, como forma de identificar as
funcionalidades existentes e a aderência com a proposta de desenvolvimento de um novo sistema
para a empresa Expede.
2.7 Sistemas analisados
Além do sistema utilizado atualmente pela empresa Expede, foram analisados outros três
sistemas similares, através de versões de demonstração fornecidas pelas empresas desenvolvedoras,
32
com o objetivo entender melhor suas formas de utilização, e a possibilidade de adotar algumas delas
tecnologias utilizadas no projeto do novo sistema.
2.7.1 Atendex
O sistema de atendimento utilizado atualmente pela Expede Informática, denominado
Atenndex, é executado em ambiente Web e foi desenvolvido em linguagem PHP, banco de dados
Firebird 1.5, e logo depois portado para o Firebird 2.0, as tabelas foram criadas utilizando o charset
incorreto, que são os tipos de caracteres aceitos durante a manipulação dos dados.
O sistema não utiliza nenhum dos termos usados na área de Service Desk, pois em seu
desenvolvimento não foi aplicado nenhuma metodologia ou padrão de processo, também não foi
feito nenhuma comparação com sistemas existentes na época, foi desenvolvido unicamente para
registro de informações básicas feitas com o cliente, como problemas encontrados em seus SD´s e
diálogos realizados entre usuário e cliente, e que mais tarde recebeu outras funções.
O sistema permite registrar os atendimentos e diálogos, permite também pesquisar por
atendimentos, estejam eles concluídos, abertos, agendados, transferidos para outro usuário, ou
agendado.
Permite reabrir os atendimentos já concluídos, permite também efetuar resets, não permite
registrar as versões dos sistemas SD’s, nem calcular o custo despendido em um atendimento.
Não executa corretamente no navegador Opera, pois algumas funções foram implementadas
unicamente para o Internet Explorer. O sistema está instalado em um servidor Linux.
A Figura 10 mostra a tela de registro do atendimento do sistema Atendex.
33
Figura 10 - Tela de registro de atendimento Fonte: Atendex
Na Figura 11 pode-se observar a lista de atendimentos. Por questões de privacidade, foram
omitidos os clientes.
Figura 11 - Tela de pesquisa atendimentos Fonte: Atendex
34
2.7.2 MySuite
A empresa brasileira Brazip desenvolveu um software para Help Desk com bons recursos,
alguns como a comunicação entre usuários substitui o uso de outros comunicadores como skype ou
msn.
Possui, ainda, várias ferramentas para atender diferentes necessidades: uma fila de espera;
gestor de conhecimento; organização de mensagens trocadas entre clientes e empresa de serviços de
TI; transferência do atendimento a outro operador e possibilita acompanhar seu andamento.
O sistema funciona via Web e uma demonstração pode ser acessada no endereço
www.mysuite.com.br.
A Figura 12 mostra a tela principal do sistema mySuite.
Figura 12 - Tela Principal MySuite. Fonte: mySuite.
2.7.3 Webhelpdesk
O sistema Webhelpdesk possui um painel de instrumentos com os gráficos estatísticos de
prioridade, status e os tickets abertos, facilitando a tomada de decisão, bem como favorecendo um
melhor acompanhamento dos atendimentos.
35
Apesar de estar em inglês, é muito intuitivo, e de fácil utilização, ainda existe a
possibilidade de transformar e-mails enviados em atendimentos.
Possui o roteamento inteligente de atendimentos, isto é, quando é aberto um chamado o
sistema procura por operadores que possuem melhor habilidade para atendê-lo, e ainda utiliza
balanceamento de carga de trabalho, ou seja, procura operadores que estejam com número menor de
atendimentos ou que estes atendimentos não sejam de alta prioridade.
Existe ainda a possibilidade de armazenar os equipamentos do cliente por usuário, exportar
para Pdf ou Xls. A Figura 13 mostra a tela principal do Webhelpdesk.
Figura 13 - Tela Principal do Webhelpdesk Fonte: Webhelpdesk
2.7.4 Milldesk
O sistema Milldesk foi desenvolvido totalmente para operar via web, junto as melhores
práticas do ITIL para proporcionar maior produtividade e eficiência.
Nele é possível registrar os contratos e modelos de SLA (Service Level Agreement), e ainda
gerar um relatório que pode ser enviado ao cliente com as informações e resultados para
acompanhamento e análise, verificando, assim, se o contrato realmente está sendo cumprido.
36
O sistema de relatórios e interação com o cliente é bem abrangente e visando comunicar ao
cliente que o acordo está sendo cumprido.
Algo que chama atenção é a diferenciação entre incidentes e “how-to”, como fazer, que pode
mostrar quando há necessidade de treinamento, e também identificar quando existe rotatividade de
pessoal em um departamento.
Possui um dashboard com um resumo das situações dos chamados, quantos abertos, quantos
em análise, mostra também as prioridades dos chamados, e também a distribuição de chamados por
técnicos.
O dashboard, na Figura 14, mostra um resumo dos SLA’s para acompanhar se os chamados
estão sendo atendidos dentro do prazo acordado.
O sistema ainda possui uma tela de configurações para se adequar o máximo possível ao seu
negócio.
Figura 14 - Dashboard Milldesk Fonte: Milldesk
2.7.5 Resumo dos sistemas similares
Os softwares foram analisados tendo como foco a utilização do ponto de vista do operador.
37
A Tabela 2 mostra um resumo de recursos dos sistemas analisados.
Tabela 2 - Resumo dos recursos analisados nos sistemas similares
Outros recursos analisados Webhelpdesk MySuite Milldesk
Aplicação Web Sim Sim Sim
Base de conhecimento Sim Sim Sim
Relatórios Gráficos Sim Sim Sim
Utiliza modelo ITIL Desconhecido Desconhecido Sim
Notificações por e-mail Sim Não Sim
Nos sistemas analisados encontraram-se bons recursos, porém nenhum destes sistemas atende
completamente a forma de trabalho da Expede, principalmente pelo fato que se deseja integrar a
abertura de chamados dos sistemas desktop com o novo sistema, recursos como base de
conhecimento, notificação por e-mail e relatórios gráficos, poderão ser implementados no projeto.
A seção a seguir detalha as tecnologias que serão utilizadas para a implementação do novo
sistema de atendimento ao cliente.
2.8 Tecnologias utilizadas no projeto
2.8.1 PHP
A linguagem PHP foi criada em 1994 por Rasmus Lerdorf, que a utilizava para monitorar o
acesso ao seu currículo na internet. No início era um conjunto de scripts, mas como a ferramenta foi
crescendo em funcionalidade, Rasmus acabou reescrevendo-a em linguagem C e dando o nome de
PHP/FI (Personal Home Pages/Forms Interpreter). (DALL´OGLIO, 2009).
A segunda versão foi lançada em 1997, até então 1% dos sites na internet já utilizavam a
linguagem.
Atualmente, o PHP (agora um acrônimo recursivo para PHP: Hypertext Preprocessor) é uma
linguagem de script opensource de uso geral, que pode ser embutida dentro do HTML.
38
O que identifica um código PHP de um Javascript, é que ele é executado no servidor, gerando
um código HTML que é enviado para o cliente.
A Figura 15 mostra o exemplo de código em linguagem PHP.
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
<title>Exemplo</title>
</head>
<body>
<?php
echo "Olá, Eu sou um script PHP!";
?>
</body>
</html>
Figura 15 - Exemplo de Código PHP
PHP é uma linguagem de fácil aprendizado, porém com recursos avançados e que permite
implementação seguindo as premissas da orientação a objeto.
2.8.2 Zend Framework
Framework é “um conjunto coeso de interfaces e classes que colaboram para fornecer
serviços para a parte básica e constante de um subsistema lógico” (Craig Larman apud Lisboa, 2009
p. 21). Em outras palavras, framework é mais que uma biblioteca de classes, pois se concentra no
reaproveitamento e padronização de código.
O ZF (Zend Framework) é muito robusto, desenvolvido em PHP, orientado a objeto, trabalha
com o conceito de camadas MVC (Model, View, Controller), e pode se conectar com diversos
bancos de dados.
Criada com o objetivo de auxiliar o programador nas melhores práticas de desenvolvimento
de software, aumentando assim a produtividade. É um framework gratuito, e de código aberto, que
pode ser modificado conforme a necessidade do programador.
O ZF, não depende de IDE, pode ser integrada ao NetBeans ou Eclipse, ou ainda utilizar o
Delphi for PHP, e para desenvolvimento pode ser usado até mesmo o bloco de notas do Windows.
39
2.8.3 JQuery
JQuery é uma biblioteca Javascript disponibilizada como software livre e sob licença MIT ou
GPL (GNU General Public Licence), podendo desenvolver projetos tanto pessoais como
comerciais.
Esta biblioteca foi escrita para tornar a implementação de códigos Javascript menos
dispendiosa, com ela poderá criar ótimos efeitos sem ser um profundo conhecedor de Javascript.
Esta biblioteca também adiciona interatividade e dinamismo às páginas web, simplifica
tarefas específicas de Javascript, adiciona efeitos e animações, alterar conteúdos, acessar e
manipular a DOM (Document Object Model), entre outros.
“JQuery foi criada com a preocupação de ser uma biblioteca em conformidade com os
padrões Web, ou seja compatível com qualquer sistema operacional e navegador, além de oferecer
suporte total para as CSS 3 (Cascading Style Sheets).” (SILVA, 2009, p. 28). Isto significa que
pode-se desenvolver scripts sem se preocupar em implementar uma versão para cada navegador,
pois o JQuery fará isso sozinho.
2.8.4 SGBD Firebird
Derivado do código do Borland Interbase 6.0 tem código aberto e não possui licença dupla,
isso significa que usá-lo comercialmente ou não, não tem que pagar nada. Trata-se de um produto
muito robusto, eficiente e estável.
Os principais recursos do Firebird são (CANTU, 2010):
• Suporte total a Stored Procedures e Triggers;
• Transações compatíveis com ACID;
• Integridade Referencial;
• Multi Generational Architecture;
• Consome poucos recursos de processamento;
• Linguagem nativa para Stored Procedures e Triggers (PSQL);
• Suporte para Funções Externas (UDFs);
• Praticamente não necessita de DBAs especializados;
• Quase nenhuma configuração - instale e já comece a usar!;
40
• Grande comunidade de usuários e vários lugares para se obter suporte gratuito;
• Versão embedded do SGBD - perfeita para criação de catálogos em CDROM, aplicações
"demo" ou standalone;
• Careful writes - recuperação rápida, dispensa o uso de log de transações;
• Diversas formas de acesso ao banco de dados: nativo/API, dbExpress, ODBC, OLEDB,
.Net provider, JDBC nativo tipo 4, Python module, PHP, Perl, etc.;
• Suporte nativo para os maiores sistemas operacionais, incluindo Windows, Linux, Solaris,
MacOS;
• Backups incrementais;
• Builds de 64bits disponíveis;
• Total controle de cursores em PSQL;
• Tabelas de Monitoramento ;
• Triggers de conexão e transação;
• Tabelas temporárias;
• TraceAPI - saiba o que está acontecendo no servidor.
O Firebird possui quatro versões: a Embedded, já citada, uma versão stand alone, para usar
em catálogos, ou demonstração não precisa instalar; a Classic, recomendada para uso em máquinas
com mais de um processador, pois inicia um processo independente para cada conexão; a
SuperServer, utiliza thread para gerenciar cada conexão e usa um mesmo cache para as conexões; e
a SuperClassic, que cria threads em um único processo mas utiliza um cache independente para
cada conexão.
O Firebird também é usado com grandes bancos de dados e considerável número de
conexões.
2.8.5 Apache 2
Um servidor Apache é um computador que processas solicitações HTTP (Hyper-Text
Transfer Protocol).
Como servidor Web, o Apache é o mais conhecido e usado. Por causa de seu excelente
desempenho, segurança, compatibilidade com diversas plataformas e todos os seus recursos.
Além de estar disponível para diversas plataformas com Windows, Linux, Unix, ainda é
possível instalá-lo em máquinas e sistemas operacionais antigos.
41
O servidor Apache é capaz de executar códigos de linguagens como Perl, PHP, ASP e outras.
Segundo (ALECRIM, 2006), destaca-se algumas características do Apache:
• Suporte a autorização de acesso podendo ser especificadas restrições de acesso
separadamente para cada endereço/arquivo/diretório acessado no servidor;
• Autenticação requerendo um nome de usuário e senha válidos para acesso a alguma
página/sub-diretório/arquivo (suportando criptografia via Crypto e MD5);
• Negociação de conteúdo, permitindo a exibição da página Web no idioma requisitado pelo
Cliente Navegador;
• Suporte a tipos mime;
• Personalização de logs;
• Mensagens de erro;
• Suporte a virtual hosting (é possível servir 2 ou mais páginas com endereços/ portas
diferentes através do mesmo processo ou usar mais de um processo para controlar mais de
um endereço);
• Suporte a IP virtual hosting;
• Suporte a name virtual hosting;
• Suporte a servidor Proxy ftp e http, com limite de acesso, caching (todas flexivelmente
configuráveis);
• Suporte a proxy e redirecionamentos baseados em URLs para endereços Internos;
• Suporte a criptografia via SSL, Certificados digitais.
42
3 DESENVOLVIMENTO
Neste capítulo é apresentado uma descrição das particularidades técnicas do sistema, o
modelo conceitual e físico dos dados, bem como seu objetivo e funcionamento, os testes, e as
dificuldades encontradas durante sua implementação.
3.1 Análise de Requisitos
Os requisitos listados a seguir foram selecionados com base na análise do sistema atual,
entrevistas com os usuários, o Gerente de Suporte e o Diretor da área técnica, também se procurou
adequando-los ao Gerenciamento de Incidentes do ITIL.
3.1.1 Informações Sobre o Sistema
O principal objetivo deste sistema é auxiliar os técnicos da empresa Expede Informática a
melhorar o desempenho e a qualidade no atendimento ao cliente. Para isso faz-se uso das técnicas
recomendadas pelo ITIL no Gerenciamento de Incidentes.
A recuperação das informações se dará dentro de uma base de conhecimento gerada pelos
diálogos dos próprios atendimentos aberto pelos usuários ou pelos sistemas desktop e interligados
através de palavras-chave.
Os diálogos dos atendimentos registrados pelos usuários recebem um status de: diálogo,
solução ou conhecimento, sendo que este último só poderá ser atribuído pelo gerente do setor de
suporte técnico.
Quando o status registrado for diálogo ele permanecerá apenas para registro, mas quando
contiver o status de solução, o gerente de suporte será avisado automaticamente, pelo próprio
sistema de atendimento, da existência de uma solução, para este seja classificado como
conhecimento e venha fazer parte da base de dados de conhecimento. Assim, o gerente de suporte
irá validar as informações registradas mudando seu status para conhecimento ou se concluir que a
solução não é válida este retornará seu status para diálogo.
43
3.1.2 Situação Atual
Na situação atual não existe distinção entre problemas reais e apenas dúvidas dos clientes; nos
incidentes abertos, quando este não possui uma solução conhecida, ao ser transferido para o
programador é colocado no final da fila, pois também não há possibilidade de priorizar o
atendimento.
No fluxograma mostrado na Figura 16 é visto a situação atual de abertura e fechamento de um
atendimento.
Figura 16 - Situação atual
44
3.1.3 Situação Proposta
Conforme os problemas enfrentados pelo setor de atendimento ao cliente, pretende-se adotar a
forma de atendimento mostrada na Figura 17, sendo que o cliente é previamente cadastrado pelo
administrador logo após o fechamento do contrato de locação de software.
O escalonamento do serviço foi estruturado conforme recomendação do ITIL, de forma a
distribuir melhor as tarefas do setor de help desk.
Aumento da acessibilidade por possuir um ponto único de contato, o suporte está sempre
disponível, possibilidade de classificação e priorização são algumas vantagens adquiridas com a
situação proposta.
Figura 17 - Situação proposta
45
Além de funcionar como ponto central de contato entre os clientes, o suporte nível 1 também
tem como objetivo classificar e priorizar o atendimento, gerenciando os incidentes até seu
encerramento. Conforme fluxo na Figura 18.
Figura 18 - Fluxo suporte nível 1
46
A Figura 19 ilustra o suporte nível 2 o qual não é interrompido por chamadas de usuários,
aumentando assim sua produtividade na busca por soluções para os atendimentos.
Figura 19 - Fluxo suporte nível 2
O suporte nível 3 também tem como função analisar a causa dos incidentes. Fluxo mostrado
na Figura 20.
Figura 20 – Fluxo suporte nível 3
47
Os técnicos de suporte usuários do sistema poderão possuir o perfil de administrador, obtendo
funcionalidades como cadastro de clientes, registro de diagnósticos na base de conhecimento,
cadastro de prioridades, registro de usuários e relatórios gerenciais, tais funcionalidades não estão
disponíveis para usuários sem este perfil.
3.2 Requisitos Funcionais
Requisitos funcionais são aqueles que descrevem a ação que cada entrada deverá atender, ou
seja, o que será feito pelo sistema. (LIMA, 2005).
A seguir estão listados os requisitos funcionais que o módulo do sistema de atendimento ao
cliente deverá atender, alguns deles seguindo as recomendações de atividades do ITIL, e também
alguns relacionamentos conforme Figura 6 - Exemplo de processo de Gerenciamento de Incidente
RF01: O sistema deve permitir ao técnico logar-se no sistema;
Atividades do ITIL - Detecção e registro de chamados
RF02: O sistema deve permitir ao técnico abrir um atendimento;
RF03: O sistema deve permitir selecionar o tipo do atendimento;
RF04: O sistema deve permitir priorizar os atendimentos;
RF05: O sistema deve permitir cadastrar a pessoa de contato do atendimento.
Atividades do ITIL - Pesquisa da solução
RF06: O sistema deve permitir ao técnico pesquisar atendimentos semelhantes;
RF07: O sistema deve permitir ao gerente adicionar dados à base de dados de conhecimento.
Atividades do ITIL - Classificação e suporte
RF08: O sistema deve permitir ao técnico efetuar modificações em um atendimento;
RF09: O sistema deve permitir ao técnico agendar o atendimento;
RF10: O sistema deve permitir ao técnico registrar os diálogos nos atendimentos;
RF11: O sistema deve permitir ao técnico registrar diagnóstico da solução no atendimento.
Atividades do ITIL - Pesquisa da Causa
RF12: O sistema deve permitir visualizar histórico dos atendimentos;
48
Atividades do ITIL - Escalonamento
RF13: O sistema deve permitir transferir um atendimento para outro técnico.
Funcionalidades não classificadas em atividades do ITIL
RF14: O sistema deve permitir transformar o atendimento em uma tarefa;
RF15: O sistema deve permitir aos SD’s abrirem atendimentos;
RF16: O sistema deve permitir visualizar os diálogos dos atendimentos;
RF17: O sistema deve permitir ao técnico efetuar resets;
RF18: O sistema deve permitir aos SD’s efetuarem reset;
RF19: O sistema deve permitir ver os resets efetuados;
RF20: O sistema deve mostrar os atendimentos em aberto;
RF21: O sistema deve permitir associar arquivos externos ao atendimento;
RF22: O sistema deve permitir associar arquivos externos ao cliente;
RF23: O sistema deve permitir contabilizar o tempo dedicado ao atendimento;
RF24: O sistema deve permitir avisar dos atendimentos agendados.
Atividades do ITIL - Encerramento do incidente
RF25: O sistema deve permitir ao técnico fechar ou cancelar um atendimento.
Outros requisitos
RF26: O sistema deve permitir ao gerente cadastrar novos técnicos.
RF27: O sistema deve permitir imprimir os atendimentos.
3.2.1 Requisitos não Funcionais
Requisitos não funcionais são aqueles que expressam como o sistema deve ser feito.
A seguir, foram listados os principais requisitos não funcionais.
RNF01: O Sistema deverá rodar em SO Linux;
RNF02: O Sistema deverá acessar base de dados Firebird 2.0 ou superior;
RNF03: O Sistema deverá ser acessado pelos navegadores web Internet Explorer, Mozilla
Firefox e Google Chrome;
RNF04: O Sistema deverá ser desenvolvido na linguagem PHP.
49
3.3 Diagrama de Casos de Uso
O Diagrama de Casos de Uso corresponde ao diagrama que modela a dinâmica do sistema
(em relação aos quatro pontos de vista) no mais alto nível de abstração proporcionado pela UML
(SILVA, 2009).
Com base nos requisitos funcionais, a Figura 18 mostra o Diagrama de Casos de Uso –
Cenário do Geral. As Tabelas 3 a 13 apresentam o detalhamento dos Casos de Uso.
Figura 21 - Diagrama de Casos de Uso Cenário Geral
50
Tabela 3 - Caso de Uso nº 01
Nome Logar no sistema Cenário Principal
1. Informa código de usuário e senha 2. Entra no sistema
Tabela 4 - Caso de Uso nº 02
Nome Cadastrar Atendimento Cenário Principal
1. Seleciona cliente 2. Abre o atendimento 3. Registra problema/dúvida 4. Registra diálogos
Cenário Alternativo Editar
1. Pesquisa atendimento aberto 2. Seleciona o atendimento 3. Edita problema/dúvida 4. Cadastra novo diálogo
Transferir 1. Pesquisa o atendimento 2. Seleciona o atendimento 3. Transfere para outro usuário
Tabela 5 - Caso de Uso nº 03
Nome Registrar Diálogos Cenário Principal
1. Seleciona atendimento 2. Digita informações pertinentes ao incidente 3. Retorna solução
Tabela 6 - Caso de Uso nº 04
Nome Consultar Soluções Cenário Principal
3. Seleciona atendimento 4. Pesquisa situações similares 5. Retorna solução
51
Cenário Alternativo 1. Acessa base de dados de conhecimento 2. Pesquisa situações similares 3. Solução não encontrada
Tabela 7 - Caso de Uso nº 05
Nome Registrar Tarefa Cenário Principal
1. Seleciona atendimento 2. Seleciona usuário responsável 3. Registra tarefa
Tabela 8 - Caso de Uso nº 06
Nome Efetuar Reset Cenário Principal
1. Seleciona cliente 2. Seleciona efetuar reset 3. Informa complemento e contador atual 4. Gera reset
Tabela 9 - Caso de Uso nº 07
Nome Cadastro de usuário Cenário Principal
1. Seleciona cadastro de usuário 2. Escolhe adicionar usuário 3. Cadastra usuário 4. Registra senha provisória
Cenário Alternativo Editar
1. Seleciona cadastro de usuário 2. Escolher editar usuário 3. Edita usuário
Excluir 1. Seleciona cadastro de usuário 2. Escolher excluir usuário 3. Confirma exclusão
52
Tabela 10 - Caso de Uso nº 08
Nome Cadastro de Cliente Cenário Principal
1. Seleciona cadastro de cliente 2. Escolhe adicionar cliente 3. Cadastra cliente 5. Registra senha provisória
Cenário Alternativo Editar
1. Seleciona cadastro de cliente 2. Escolher editar cliente 3. Edita cliente
Desativar 1. Seleciona cadastro de cliente 2. Escolher desativar cliente 3. Confirma desativação
Desativar 1. Seleciona cadastro de cliente 2. Escolher desativar cliente 3. Confirma desativação
Tabela 11 - Caso de Uso nº 09
Nome Cadastra Base de Dados de Conhecimento Cenário Principal
1. Pesquisa diálogos de atendimentos 2. Seleciona diálogos com status classificados como solução 3. Confirma validade da solução 4. Altera status para conhecimento ou reclassifica como diálogo
Cenário Alternativo Editar
1. Pesquisar base de dados de conhecimento 2. Seleciona diálogos com status de conhecimento 3. Edita dados ou status 4. Confirma alteração
Tabela 12 - Caso de Uso nº 10
Nome Visualiza Relatórios Cenário Principal
1. Gerente seleciona relatórios
53
2. Sistema mostra graficamente os dados atuais 3. O gerente filtra dados por período 4. O gerente imprime relatórios
Tabela 13 - Caso de Uso nº 11
Nome Fechar e Cancelar Atendimentos Cenário Principal Fechar
1. Pesquisa o atendimento 2. Seleciona o atendimento 3. Edita o atendimento 4. Conclui o atendimento
Cancelar 1. Pesquisa o atendimento 2. Seleciona o atendimento 3. Edita o atendimento 4. Escolhe cancelar 5. Informa o motivo
A seguir são descritos os procedimentos nos casos de uso.
Logar-se no sistema (UC01)
Para utilizar o sistema e ter acesso as informações, primeiro é preciso ser cadastrado pelo
gerente de suporte e possuir login e senha.
Abrir atendimentos (UC02)
Um atendimento só pode ser aberto pelo técnico de suporte quando este recebe uma
comunicação através de ligações telefônicas com o cliente, ou através de mensagens instantâneas
pelo skype, ou ainda através dos Sistemas Desktops, quando estes apresentarem falhas, enviando
automaticamente a mensagem de erro para o sistema de suporte.
Para abertura do atendimento, o técnico de suporte deve primeiro selecionar o cliente, depois
ele poderá acessar o registro do incidente, seguindo a ordem de preenchimento:
Colocar um título que sintetize a descrição do incidente.
Selecionar a prioridade do atendimento, este é campo que define o acordo do nível de serviço,
ou seja, determina o tempo máximo para a resolução do incidente.
54
Categoria do incidente, indica o tratamento que o atendimento irá receber, podendo serem
eles de 3 tipos:
Dúvida, falha ou solicitação de serviço.
Sistema, associa o incidente a um dos SD’s desenvolvidos pela empresa Expede.
Contato, identifica a pessoa que relatou o incidente, se não estiver na base de dados, o técnico
de suporte poderá cadastrá-lo.
Descrição, contém um detalhamento do incidente ocorrido, permitindo assim uma melhor
análise para definição do tratamento a ser tomado.
O setor de suporte técnico da Expede Informática, presta serviço exclusivo para clientes de
seus sistemas, e somente para falhas ou dúvidas ocorridas com estes.
Registrar diálogos (UC03)
O registro de diálogos nada mais é do que a interação do técnico de suporte com o sistema de
atendimento, com o objetivo de solucionar o incidente ocorrido em um determinado atendimento
aberto.
Após selecionar o atendimento, o técnico de suporte deverá selecionar o contato e entrar com
as informações no campo diálogo, se a solução ou situação de contorno, já tiver sido encontrada, o
técnico deverá entrar em contato com o cliente solicitante, ou pessoa de contato, resolvendo o
incidente e registrando no diálogo do atendimento.
Uma solução poderá ser pesquisada utilizando a base de conhecimento registrada e associada
ao diálogo do atendimento.
Se necessário, poderá se anexar arquivos ao atendimento.
Consultar soluções (UC04)
Após a abertura de um atendimento, o técnico de suporte poderá pesquisar no histórico de
atendimentos para verificar se existe uma solução para um incidente similar.
Registrar tarefas (UC05)
O registro de tarefas ocorre quando um incidente não pode ser solucionado pelo técnico de
suporte sem ajuda do departamento de desenvolvimento, neste caso, o técnico deverá transformar o
atendimento em uma tarefa que será enviada para o Gerenciamento de Problemas.
55
Esta tarefa poderá retornar ao Gerenciamento de Incidentes como atendimento, quando o
departamento de desenvolvimento tiver encontrado uma solução para o incidente.
Efetuar resets (UC06)
O reset é uma forma de liberação de créditos para os SD’s, que são locados, ele é efetuado
automaticamente sempre que o número de créditos disponíveis neles for menor que sete dias.
Quando um reset é efetuado com sucesso, é registrado no sistema de suporte como um
atendimento e um diálogo, contendo as informações do número de créditos liberados.
Um reset pode ser feito por um técnico de suporte, se o cliente entrar em contato e pedir
liberação de créditos.
Após selecionar o cliente na opção reset, fornecer contador atual, e complemento para receber
o código de reset.
Cadastrar técnico (UC07)
Para que os técnicos de suporte possam acessar o sistema é necessário que um gerente ou
supervisor faça o cadastro dos mesmos no sistema.
Cadastrar cliente (UC08)
Para que seja aberto um atendimento, é necessário ter o cliente previamente cadastrado no
sistema, o que é feito por um gerente ou supervisor.
Cadastrar base de conhecimento (UC09)
A base de conhecimento é registrada utilizando as informações adicionadas nos diálogos
pelos técnicos de suporte, que são analisadas pelo gerente e marcadas para fazerem ou não, parte da
base de conhecimento.
Visualizar relatórios (UC10)
Os relatórios são gerados com base nos atendimentos de cada técnico de suporte, podem ser
visualizados no dia, ou por um determinado período.
Fechar atendimento (UC11)
Entende-se como fechamento de um atendimento, estando ele como concluído, e a solução
para o incidente implementada no cliente.
56
Um atendimento poderá ser reaberto se por ventura a solução implementada para resolução do
incidente se mostra ineficaz. Este processo poder ser feito por qualquer técnico de suporte,
assumindo para si a responsabilidade pelo atendimento.
Cancelar atendimento (UC11)
Um atendimento poder ser cancelado quando este não for de competência do serviço prestado
pelo setor de suporte técnico da empresa Expede, tais como: problemas de rede ou de hardware.
Um atendimento duplicado também pode gerar cancelamento.
57
3.4 Diagrama de Classes
“O diagrama de classes é o modelo fundamental de uma especificação orientada a objetos.
Produz a descrição mais próxima da estrutura do código de um programa, mostra o conjunto de
classes com seus atributos e métodos e os relacionamentos entre classes.” (SILVA, 2009).
A Figura 22 mostra o Diagrama de Classes do sistema proposto, módulo de atendimento ao
cliente.
Figura 22 - Diagrama de Classes
58
O Diagrama de Classes representa a estrutura do sistema que foi implementado. As principais
classes foram modeladas conforme os requisitos especificados nas seções anteriores.
A seguir são citados os principais métodos para uma melhor compreensão das funcionalidades
do sistema:
Adicionar: possui duas funcionalidades, a de inserir um novo registro, e a de editá-lo.
Excluir: remove os registros do banco de dados.
Desativar: é um método que não remove do banco de dados, mas coloca uma marcação no
registro para que não apareça mais nas listagens dos métodos listar.
A classe Atendimento, possui um papel fundamental na operação do sistema, seus métodos
possuem as seguintes funcionalidades:
Abrir: este método dá início ao atendimento, através de um formulário faz-se a inserção dos
dados, e este mesmo método faz o registro no banco de dados e encaminha para o método diálogo
onde será feito a complementação do atendimento.
Agendar: em determinados casos um atendimento precisa ser agendado para outro dia ou
horário, neste caso se fará uso do método agendar, o qual modificará a prioridade do atendimento
para que se encaixe no agendamento.
Transferir: permite transferir para outro técnico o atendimento.
Reset: permite registrar um atendimento contendo informações de reset.
AdicionarAnexos: quando for necessário algum documento ou imagem para complementar
instruções, poderá adicionar como anexos ao atendimento.
RemoverAnexos: permite remover do banco de dados anexos do atendimento.
Listar: o método listar, encontrado na maioria das classes tem como objetivo mostrar em
formato HTML os registros gravados no banco de dados, podendo estas listagens fazerem uso ou
não de filtros de pesquisa.
59
3.5 Diagrama de Banco de Dados
O diagrama de banco de dados é importante para a organização durante o desenvolvimento do
sistema, pois detalha qual o conteúdo de cada campo, e quais tabelas estão interligadas. Para este
sistema chegou-se ao modelo da Figura 23.
Figura 23 - Diagrama de Banco de Dados
60
3.6 Implementação
Nesta etapa são mostradas as técnicas, linguagens e ferramentas utilizadas e a
operacionalidade da implementação.
3.6.1 Ferramentas utilizadas
Para a implementação do sistema foi utilizado do NetBeans IDE 6.9RC2 para Windows e o
NetBeans IDE 6.9 para Linux, que é um ambiente de desenvolvimento integrado disponível para
Windows, Mac, Linux e Solaris, e permite aos desenvolvedores criarem rapidamente aplicações
desktops e móveis para plataformas como Java, C/C++, PHP, Groovy, Ruby on Rails e muito mais.
3.6.2 Criação da base de dados
A criação da base de dados do sistema foi de acordo com o diagrama apresentado na seção
anterior, segue o exemplo na Figura 24, a criação da tabela atendimento em linguagem SQL.
Figura 24 - Script de criação da tabela atendimento
As duas primeiras linhas do script marcam a tabela de caracteres case-insensitive para o
Brasil, o que significa dizer que palavras como José, JOSE, JoSé, podem ser ordenadas e
comparadas dentro do SGBD não levando em conta se ele é maiúsculo ou minúsculo.
61
A terceira linha do script cria um generator para ser utilizado como auto-incremento em um
campo da tabela, já que o SGBD Firebird não possui campo auto-incremento. Da quarta linha em
diante está a criação da tabela propriamente dita.
Com base no script SQL da Figura 24, foi gerado a tabela atendimento, e mostrado na Figura
25. Para cada uma das tabelas representadas no diagrama de banco de dados, foi executado um
script semelhante.
Figura 25 - Tabela atendimento gerada no SGBD Firebird
3.6.3 Criação dos scripts PHP
Para a criação do sistema foi utilizando o Zend Framework, um framework PHP, para que os
códigos gerados pudessem ser reutilizados com pequenas alterações, e utilizou-se o formato MVC
(Model, View, Controller), o que permite uma programação modular e faz com que o sistema fique
mais leve e independente.
A forma modular permite com que os desenvolvedores e designers possam trabalhar
simultaneamente.
A Figura 26 ilustra o exemplo de código PHP de controle para a abertura de um atendimento.
62
Figura 26 - Código abrir atendimento
Na linha 20 está a declaração do método abrir, o qual é complementado pela palavra Action
por causa do Zend Framework.
O acesso ao formulário está declarado na linha 25, enquanto que a comunicação com o banco
de dados é carregada na linha 27, e na linha 35 a gravação definitiva do registro no banco de dados.
Figura 27 - Script PHP registro no banco de dados
63
3.7 Interface, Testes e Resultados.
Neste capítulo será apresentado a interface do sistema, bem como os testes e resultados
obtidos durante sua utilização pelos técnicos de suporte da Expede Informática.
Durante o desenvolvimento, vários erros foram encontrados e corrigidos, foi aplicado um
método de desenvolvimento e testes, onde cada código liberado é colocado para uso.
A Figura 28 mostra a tela de login do sistema, por meio dela é possível ter acesso as funções
do sistema.
Figura 28 - Tela de login
64
3.7.1 Avaliação da abertura de atendimento.
1) Abrir atendimento
Para abrir um novo atendimento é necessário primeiro selecionar o cliente, que passa a estar
ativo durante todo o tempo que o sistema estiver aberto.
Após a seleção do cliente o técnico solicita informações sobre o incidente para o cliente e
registra no sistema, conforme ilustrado pela Figura 29.
Figura 29 - Abertura de atendimento
Durante a abertura do atendimento o técnico deve classificar e categorizar o mesmo, isto é
realizado selecionando a prioridade e a categoria do incidente.
Nenhum erro foi encontrado durante este teste.
2) Registrar diálogos
Após a gravação do atendimento, este é direcionado para a inclusão dos diálogos, conforme a
Figura 30, onde são registradas informações sobre procedimentos executados no equipamento do
cliente, ou apenas conversas através de ligações telefônicas ou mensageiro instantâneo.
Ainda durante o registro de diálogos, pode
prioridade conforme análise do técnico de suporte.
atendimento, que não estava funcionando, porém após o relato o problema foi corrigido.
Figura 30 - Registro de diálogos
3) Consultar soluções
Caso o técnico de suporte não conheça a solução para o incidente do
pesquisar em um banco de dados com históricos de atendimentos similares
resultado de uma pesquisa na
lançará no diálogo do atendimento
65
Ainda durante o registro de diálogos, pode-se reclassificar o atendimento, ou alterar sua
prioridade conforme análise do técnico de suporte. Foi deteectado erro na
, que não estava funcionando, porém após o relato o problema foi corrigido.
Registro de diálogos
Caso o técnico de suporte não conheça a solução para o incidente do
pesquisar em um banco de dados com históricos de atendimentos similares
na qual o técnico poderá selecionar o registro de interesse e o sistema
lançará no diálogo do atendimento.
se reclassificar o atendimento, ou alterar sua
Foi deteectado erro na reclassificação do
, que não estava funcionando, porém após o relato o problema foi corrigido.
Caso o técnico de suporte não conheça a solução para o incidente do atendimento, este poderá
pesquisar em um banco de dados com históricos de atendimentos similares. A Figura 31, ilustra o
qual o técnico poderá selecionar o registro de interesse e o sistema
Figura 31 - Pesquisa base de conhecimento
4) Registrar tarefas
O registro de uma tarefa ocorre quando há necessidade de envolver
Problemas e aguardar por uma solução. Quando um atendimento é transformado em tarefa, ele só
retornará a ser atendimento quando a solução desenvolvida pelo Gerenciamento de Problemas
estiver pronta.
Neste caso, o Gerenciamento de Problemas transferirá para o gerente do Gerenciamento de
Incidentes o atendimento já aberto, e este transferirá para o técnico responsável pela conclusão do
mesmo. Esta função pode ser observada na
Figura 32 - Registrar tarefas
66
Pesquisa base de conhecimento
O registro de uma tarefa ocorre quando há necessidade de envolver
Problemas e aguardar por uma solução. Quando um atendimento é transformado em tarefa, ele só
retornará a ser atendimento quando a solução desenvolvida pelo Gerenciamento de Problemas
o Gerenciamento de Problemas transferirá para o gerente do Gerenciamento de
Incidentes o atendimento já aberto, e este transferirá para o técnico responsável pela conclusão do
mesmo. Esta função pode ser observada na Figura 32.
Registrar tarefas
O registro de uma tarefa ocorre quando há necessidade de envolver o Gerenciamento de
Problemas e aguardar por uma solução. Quando um atendimento é transformado em tarefa, ele só
retornará a ser atendimento quando a solução desenvolvida pelo Gerenciamento de Problemas
o Gerenciamento de Problemas transferirá para o gerente do Gerenciamento de
Incidentes o atendimento já aberto, e este transferirá para o técnico responsável pela conclusão do
67
5) Efetuar reset
O reset é a geração de um código que contém informações de número de dias para ser
registrado nos SD’s. Para que estes continuem funcionando, ele precisa ser gerado todos os meses.
Quando um cliente entra em contato e solicita um reset, ele deve informar os seguintes dados
que serão usados para calcular o código de reset: número de série do sistema; contador atual
(número de vezes que o reset foi efetuado naquele equipamento) e complemento (número aleatório
gerado pelo SD). A Figura 33 ilustra o cadastro destes dados para geração do código, Alguns erros
foram encontrados e corrigidos.
Figura 33 - Reset
68
6) Cadastrar técnico
Para utilização do sistema de atendimento o técnico precisa possuir um cadastro no Atendex.
A Figura 34 ilustra o cadastro de um técnico. Nenhum erro foi encontrado durante este teste.
Figura 34 - Cadastrar técnico
7) Cadastrar cliente
O durante o registro do cliente não foi encontrado erros, mas algumas sugestões como a
formatação automática do CPF ou CNPJ, foram anotadas e posteriormente será implementado no
sistema. A Figura 35 mostra o cadastro de um cliente sendo registrado.
Figura 35 - Cadastro de cliente
8) Visualizar relatório
Os relatórios de atendimentos estão disponíveis apenas para
Com eles o gerente poderá selecionar atendimentos por cliente, por técnico, data e hora de abertura,
selecionar os atendimentos concluídos, agendados transferidos, em aberto ou todos eles juntos. A
Figura 36 ilustra os resultados de uma pesquisa de atendimentos.
Figura 36 - Relatório de atendimentos
69
Cadastro de cliente
Visualizar relatórios
Os relatórios de atendimentos estão disponíveis apenas para o gerente do suporte técnico
Com eles o gerente poderá selecionar atendimentos por cliente, por técnico, data e hora de abertura,
selecionar os atendimentos concluídos, agendados transferidos, em aberto ou todos eles juntos. A
os resultados de uma pesquisa de atendimentos.
Relatório de atendimentos
o gerente do suporte técnico.
Com eles o gerente poderá selecionar atendimentos por cliente, por técnico, data e hora de abertura,
selecionar os atendimentos concluídos, agendados transferidos, em aberto ou todos eles juntos. A
70
3.7.2 Plano de testes
O objetivo deste plano de teste é listar os requisitos que serão testados descrevendo os
métodos a ser empregados para testar os processos envolvidos na utilização do sistema Atendex,
localizando erros visando obter um sistema com um nível menor de falhas.
Estarão envolvidos neste processo, o desenvolvedor, o supervisor técnico ou administrador e
o técnico de suporte. Os testes serão efetuados pelos envolvidos dentro do contexto específico de
cada um.
A seguir, serão descritas as atividades de cada tipo de teste previsto, o objetivo, a técnica e os
critérios de finalização (Tabelas 14 a 19).
Teste de banco de dados
• Verificar se as informações sobre clientes, usuários, diagnósticos, atendimentos,
diálogos, contatos e prioridades podem ser inseridas ou modificadas no banco de
dados.
• Verificar se as informações obtidas no banco de dados consistem com as informações
reais sobre clientes, usuários, diagnósticos, atendimentos, diálogos, contatos e
prioridades.
• Verificar se as informações registradas podem ser consultadas.
Tabela 14 - Teste de banco de dados
Objetivo do Teste: Confirmar a integridade dos dados, garantido funcionamento adequado sem inconsistência.
Técnica: Executar os métodos de acesso ao banco de dados informando dados válidos e inválidos. Verificar se os dados informados estão de acordo com as ações executadas.
Critério de finalização: Todos os métodos de acesso ao banco de dados funcionam como planejado sem corrupção dos dados.
Teste funcional
• Verificar se é possível acessar o sistema utilizando usuário e senha.
• Verificar se o sistema identifica perfil de usuário.
• Verificar se os atendimentos estão sendo abertos.
• Verificar se os diálogos estão sendo registrados.
71
• Verificar se os atendimentos estão sendo priorizados.
• Verificar registro dos contatos.
• Verificar registro agendamento, transferência, conclusão e cancelamento dos
atendimentos.
• Verificar registro de resets.
• Verificar associação de arquivos aos atendimentos.
• Verificar contabilização do tempo dos atendimentos.
• Verificar registro de atendimentos pelos SD´s.
Tabela 15 - Teste funcional
Objetivo do Teste: Confirmar que as funcionalidades dos sistemas estão de acordo com os especificados nos casos de uso.
Técnica: Executar as funcionalidades seguindo o fluxo principal mostrado no caso de uso, informando dados válidos e inválidos, aguardando resultados esperados para os dados válidos e mensagens de erro para os dados inválidos.
Critério de finalização: Executar todos os testes planejados.
Teste de ciclo de negócio
• Verificar se os campos obrigatórios estão sendo preenchido nos formulários.
• Verificar se os cálculos dos relatórios estão sendo executados corretamente.
Teste de interface do usuário
• Verificar se as telas não causam confusão ao usuário.
• Verificar se os dados solicitados nos formulários são aceitos nos campos.
Tabela 16 - Teste de interface do usuário
Objetivo do Teste: Verificar a navegação entre os campos e menus estão de acordo com os requisitos. Técnica: Selecionar campos e abrir menus para verificar a navegação e o direcionamento de
cada janela. Critério de finalização: Verificar se o usuário consegue utilizar o sistema sem treinamento e considerá-lo
agradável.
Teste de desempenho
• Verificar o tempo de resposta das operações de inserção, edição e consulta no banco
de dados.
72
Tabela 17 - Teste de desempenho
Objetivo do Teste: Verificar a performance do sistema nas condições normais de trabalho e em condições do pior caso previsto.
Técnica: Executar scripts para registro de informações automaticamente simulando a utilização de vários usuários.
Critério de finalização: Avaliação dos resultados obtidos após a conclusão dos scripts.
Teste de carga
• Verificar o tempo de resposta do sistema com 3 usuários conectados.
• Verificar o tempo de resposta do sistema com 5 usuários conectados.
Tabela 18 - Teste de carga
Objetivo do Teste: Verificar o funcionamento do sistema sobre condições de sobrecarga. Técnica: Executar scripts para registro de informações automaticamente simulando a utilização
de vários usuários, utilizando alteração, inserção, consulta exaustivamente. Critério de finalização: O sistema deverá suportar pelo menos uma sobrecarga.
Teste de stress
• Verificar o comportamento do sistema quando são realizadas várias operações de
inserção e consulta ao banco de dados.
Teste de falha e recuperação
• Verificar a recuperação das informações quando há perda de comunicação com
servidor.
Teste de segurança
• Verificar se somente o usuário administrador possui acesso ao cadastro de clientes.
• Verificar se somente usuários cadastrados pode utilizar o sistema.
Tabela 19 - Teste de segurança
Objetivo do Teste: Verificar se somente aqueles usuários com permissão possuem acesso ao sistema, e se as funcionalidades estão de acordo com seus perfis.
Técnica: Logar-se com diferentes perfis de usuários, e tentar logar-se sem permissão. Critério de finalização: O comportamento do sistema deverá estar de acordo com o perfil de cada usuário, e
usuários sem permissão não poderão utilizar-se de suas funcionalidades.
73
3.7.3 Validação e implantação do sistema
Após a realização dos testes, e feitas eventuais correções, um documento será elaborado para
a validação do sistema, este será assinado pelo responsável técnico do setor de suporte. A partir
deste documento se fará um planejamento para a implantação do sistema na empresa.
4 CONSIDERAÇÕES FINAIS
Os objetivos deste Trabalho Técnico-científico de Conclusão de Curso foram atigindos,
porém, o sistema como opção de substituição ao atual Atendex utilizado pela empresa Expede
Informática ainda necessita de ajustes para atingir a plenitude para sua aplicação na empresa, bem
como a ampliação de seu escopo para atender o gerenciamento de problemas.
O conhecimento sobre as boas práticas recomendadas pelo ITIL, contidas capítulo 2 deste
documento, possibilitou uma visão diferente do setor de suporte técnico da Expede e sua
responsabilidade sobre os resultados. Foi por meio deste conhecimento que grande parte dos
requisitos do sistema foram definidos.
O estudo de conceitos de sistemas de informação, diferenciação de Help Desk e Service Desk
e o Gerenciamento de Processos do ITIL foram importantes para alinhar a proposta de solução do
desenvolvimento do novo sistema de atendimento para a Expede Informática.
Ainda sobre a fundamentação teórica, foi importante evidenciar que a legislação fiscal atual
exige que empresas que fornecem sistemas que fazem comunicação com ECF’s, caso do sistema X-
Way da Expede Informática, e que a mesma presta serviços de suporte, seja homologado junto a
órgãos credenciados pelo governo para esta finalidade.
A pesquisa e análise de sistema similares possibilitou conhecer as funcionalidades existentes
em outros produtos e auxiliou na melhor definição dos requisitos funcionais e não funcionais do
novo sistema.
A opção por utilizar as tecnologias como Apache, PHP, Zend Framework, JQuery e Firebird
foi principalmente por serem opensources, reforçado pelo fato de todas estas tecnologias já estarem
instaladas nos servidores da Expede Informática.
No decorrer do desenvolvimento deste projeto, constatou-se a importância da adoção de boas
práticas e da necessidade de aprimoramento do processo de atendimento por parte da empresa
Expede Informática. Com base no estudo e na aplicação das recomendações do Gerenciamento de
Processos do ITIL especificamente o Gerenciamento de Incidentes, haverá melhor escalonamento e
resolução dos incidentes, restabelecendo de maneira mais rápida as operações das empresas
clientes, respeitando o prazo acordado em contrato de nível de serviço. Uma vez alcançada essa
melhoria no processo de atendimento por meio do novo sistema, pode-se concluir que o presente
trabalho terá contribuído para aumentar a satisfação dos clientes e dos colaboradores, melhorar a
gestão organizacional e ajudar na captação de novos clientes.
O capítulo 3 apresentou a implementação do sistema proposto. Muitas dificuldades foram
encontradas nesta etapa do trabalho, pois mesmo utilizando-se de uma linguagem de programação
conhecida pelo acadêmico, a opção por usar um framework obrigou-o a reaprender a forma de
programar em orientação a objetos, seguindo a recomendação de desenvolvimento em camadas. O
benefício do uso de um framework é justamente o reaproveitamento do código, porém para que isso
pudesse acontecer necessitaria de um amadurecimento de sua utilização.
A implementação seguiu os requisitos identificados na fase de análise e projeto, bem como as
recomendações do ITIL para gerenciamento de incidentes.
Atingidos os objetivos propostos neste trabalho, pretende-se dar continuidade no
desenvolvimento do sistema para abranger as recomendações do ITIL no que se refere ao processo
de gerenciamento de problemas.
REFERÊNCIAS BIBLIOGRÁFICAS
ALECRIM, Emerson. Conhecendo o Servidor Apache (HTTP Server Project). Maio de 2006. Disponível em: <http://www.infowester.com/servapach.php/>. Acesso em: 13 nov. 2011.
ATENDEX – Sistema de Atendimento ao Cliente. Disponível em: <http://www.expede.com.br/login> Acesso em: 21 nov. 2011.
BRASIL, Lei Federal 9.532 (97-12-10).
CANTU, Carlos H. Conheça o Firebird em 2 minutos. Fevereiro 2010. Disponível em: <http://www.firebirdnews.org/docs/fb2min_ptbr.html>. Acesso em: 12 nov. 2011.
COHEN, Roberto. Implantação de Help Desk e Service Desk. São Paulo: Novatec Editora, 2008.
DALL´OGLIO, Pablo. PHP Programando com Orientação a Objetos. 2ª ed. São Paulo: Novatec Editora, 2009.
FERREIRA, Tharso de Souza. Sistema de Help Desk Baseado em RBC, 2008. Trabalho de Conclusão de Curso (Graduação em Ciência da Computação) – Faculdade de Ciência da Computação – Universidade do Vale do Itajai, Itajai, 2008.
FRAGATA, Abel; MARQUES, Cleber; ROMERO, Guilherme. Falando em IT. 2006. Disponível em: <http://www.abelfragata.com.br/conteudo.html>. Acesso em: 16 out. 2011.
LAUDON, Kenneth C; LAUDON Jane P. Sistemas de Informação Gerenciais: Administrando a empresa digital. 5ª ed. São Paulo: Pearson Prentice Hall, 2004.
LEI Nº 9.532, DE 10 DE DEZEMBRO DE 1997. Disponível em: <https://www.planalto.gov.br/ccivil_03/leis/l9532.htm>. Acesso em: 23 ago. 2011.
LIBERATO, Taiz. Tecnologia em Gerenciamento de Redes. 2009. Disponível em: <http://www.webartigos.com/artigos/help-desk/20064/>. Acesso em: 13 nov. 2011.
LIMA, Adilson da Silva. UML 2.0: do requisito à solução. São Paulo: Érica, 2005.
LISBOA, Flávio Gomes da Silva. Zend Framework componentes poderosos para PHP. São Paulo: Novatec Editora, 2009.
LUIZE, Luis A. PAF-ECF O que é isso? 2008. Disponível em: <http://partners.bematech.com.br/bemacast/2008/06/paf-ecf-o-que-e-isso/>. Acesso em: 23 out. 2011.
MAGALHÃES, Ivan Luizio; PINHEIRO, Walfrido Brito. Gerenciamento de Serviços de TI na Prática: Uma abordagem com base na ITIL. São Paulo: Novatec Editora, 2007.
MILLDESK. Disponível em: <http://www.milldesk.com/flex/milldesk/demo.html> Acesso em: 19 nov. 2011.
MYSUITE. Disponível em: <http http://www.brazip.com.br/mysuite/paginas/produto.php> Acesso em: 19 nov. 2011.
O'BRIEN, James A; MARAKAS, George M. Administração de Sistemas de Informação: uma introdução. 13ª ed. São Paulo: McGraw-Hill, 2007.
P2HE Processos & TI. Disponível em: <http://www.p2he.com.br/serv_service_desk.asp> Acesso em: 21 nov. 2011.
PEREIRA, Felipe Luiz. CPITIL: Uma Aplicação de Apoio ao Gerenciamento de Problemas Baseado na Recomendação ITIL. Trabalho de Conclusão de Curso (Graduação em Ciência da Computação) – Faculdade de Ciência da Computação – Universidade do Vale do Itajai, Itajai, 2007.
PRIGOL, Cristian Paulo Sistema de Help Desk e Controle de Chamados Baseados em Workflow. Trabalho de Conclusão de Curso (Graduação Sistemas de Informação) – Faculdade de Sistemas de Informação – Universidade Regional de Blumenau, Blumenau, 2007.
SANTOS, Adelmo Leandro; et. al. Estudo na Qualidade de Serviços de TI em um Contact Center Bancário, Aplicando as boas práticas ITIL V2. 2010. Trabalho de Conclusão de Curso (Graduação em Sistemas de Informação) – Faculdade Sumaré –Instituto Sumaré de Educação Superior, 2008.
SANTOS, Paulo. Características do Suporte e Gestões de TI. 2010. Disponível em: <http://pauloprojects.blogspot.com/>. Acesso em: 15 nov. 2011.
SEZANOWITCH Robinson L. Gerenciamento de Incidentes. 2011. Disponível em: <http://www.robinson.luis.nom.br/web/index.php?option=com_content&view=article&id=179:gerenciamento-de-incidentes&catid=99:itil-v2&Itemid=118>. Acesso em: 10 nov. 2011.
SILVA, Larissa R; LIRA Aquino Da. Gerenciamento de Incidentes, segundo a ITIL. Disponível em: <http://www.sucesumt.org.br/mtdigital/anais/files/GerenciamentodeIncidentessegundoaITIL.pdf>. Acesso em: 10 out. 2011.
SILVA, Leandro Santiago da; LIMA, Rafael Sá; PIRES, Theo Carlos Flexa Ribeiro. Gestão de Service Desk baseado no modelo ITIL: proposta de implementação no Tribunal Regional do Trabalho da 8ª Região. Disponível em: <http://www.leandrosantiago.com.br/>. Acesso em: 15 nov. 2011.
SILVA, Maurício Samy. JQuery: A Biblioteca do Programador Javascript. São Paulo: Novatec, 2008.
SILVA, Ricardo Pereira E. Como Modelar com UML 2. Florianópolis: Visual Books, 2009.
STAIR, Ralph M; REYNOLDS, George W. Princípios de Sistemas de Informação: uma abordagem gerencial. 6ª ed. São Paulo: Cengage Learning, 2008.
STRAUSS, Leandro. Portal do Conhecimento Tecnológico na Secretaria da Receita Federal. Trabalho de Conclusão de Curso (Graduação em Ciência da Computação) – Faculdade de Ciência da Computação – Universidade do Vale do Itajai, Itajai, 2004.
WEBHELPDESK. Disponível em: < http://www.webhelpdesk.com/demo.html> Acesso em: 19 nov. 2011.