Área de Sistemas de Informação por Lucas Bortoluzzi Ademir ...siaibib01.univali.br/pdf/Lucas...
93
UNIVERSIDADE DO VALE DO ITAJAÍ CENTRO DE CIÊNCIAS TECNOLÓGICAS DA TERRA E DO MAR CURSO DE CIÊNCIA DA COMPUTAÇÃO UM SISTEMA DE APOIO AO GERENCIAMENTO DE INCIDENTES DE TI BASEADO NA RECOMENDAÇÃO ITIL Área de Sistemas de Informação por Lucas Bortoluzzi Ademir Goulart Orientador Itajaí (SC), junho de 2007
Transcript of Área de Sistemas de Informação por Lucas Bortoluzzi Ademir ...siaibib01.univali.br/pdf/Lucas...
UNIVERSIDADE DO VALE DO ITAJAÍ CENTRO DE CIÊNCIAS TECNOLÓGICAS DA TERRA E DO MAR
CURSO DE CIÊNCIA DA COMPUTAÇÃO
UM SISTEMA DE APOIO AO GERENCIAMENTO DE INCIDENTES DE TI BASEADO NA RECOMENDAÇÃO ITIL
Área de Sistemas de Informação
por
Lucas Bortoluzzi
Ademir Goulart Orientador
Itajaí (SC), junho de 2007
UNIVERSIDADE DO VALE DO ITAJAÍ CENTRO DE CIÊNCIAS TECNOLÓGICAS DA TERRA E DO MAR
CURSO DE CIÊNCIA DA COMPUTAÇÃO
UM SISTEMA DE APOIO AO GERENCIAMENTO DE INCIDENTES DE TI BASEADO NA RECOMENDAÇÃO ITIL
Área de Sistemas de Informação
por
Lucas Bortoluzzi 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: Ademir Goulart
Itajaí (SC), junho de 2007
ii
SUMÁRIOLISTA DE ABREVIATURAS IV
LISTA DE FIGURAS.................................................................................v
RESUMO....................................................................................................vi ABSTRACT...............................................................................................vii 1 INTRODUÇÃO......................................................................................1 1.1 PROBLEMATIZAÇÃO ..................................................................................... 1 1.1.1 Formulação do Problema................................................................................. 1 1.1.2 Solução Proposta ............................................................................................... 3 1.2 OBJETIVOS ........................................................................................................ 4 1.2.1 Objetivo Geral ................................................................................................... 4 1.2.2 Objetivos Específicos ........................................................................................ 4 1.3 METODOLOGIA................................................................................................ 5 1.4 ESTRUTURA DO TRABALHO ....................................................................... 6
2 FUNDAMENTAÇÃO TEÓRICA ........................................................7 2.1 GERENCIAMENTO DE SERVIÇOS DE TI .................................................. 7 2.1.1 Organizações e a Tecnologia da Informação.................................................. 7 2.1.2 O Gerenciamento de Serviços de Tecnologia da Informação....................... 9 2.1.3 IT Infrastructure Library: ITIL ................................................................... 15 2.1.4 Escopo do Trabalho ........................................................................................ 19 2.1.5 Considerações .................................................................................................. 25 2.2 SISTEMAS WEB............................................................................................... 26 2.2.1 Introdução........................................................................................................ 26 2.2.2 Arquitetura de Sistemas Web........................................................................ 26 2.2.3 Considerações .................................................................................................. 34
3 DESENVOLVIMENTO ......................................................................36 3.1 REQUISITOS .................................................................................................... 36 3.1.1 Funcionais ........................................................................................................ 36 3.1.2 Não-Funcionais................................................................................................ 38 3.2 REGRAS DE NEGÓCIO.................................................................................. 39 3.3 CASOS DE USO ................................................................................................ 42 3.4 DIAGRAMA DE CLASSES............................................................................. 52 3.5 DIAGRAMA DE BANCO DE DADOS........................................................... 54 3.6 CODIFICAÇÃO DA APLICAÇÃO................................................................ 55 3.6.1 Criação da base de dados ............................................................................... 56 3.6.2 Criação dos scripts PHP................................................................................. 57 3.7 TESTES E RESULTADOS .............................................................................. 60 3.7.1 Cenário 1.......................................................................................................... 60 3.7.2 Cenário 2.......................................................................................................... 61 3.8 DOCUMENTAÇÃO DA APLICAÇÃO ......................................................... 72
iii
4 CONCLUSÕES ....................................................................................73
REFERÊNCIAS BIBLIOGRÁFICAS ...................................................75
A SAGI - MANUAL DE UTILIZAÇÃO DO USUÁRIO ....................79 A.1 INTRODUÇÃO ................................................................................................. 79 A.1.1 O SAGI............................................................................................................. 79 A.2 UTILIZAÇÃO DO SISTEMA ......................................................................... 79 A.2.1 Abrir um chamado.......................................................................................... 80 A.2.2 Visualizar o histórico de um chamado.......................................................... 82 A.2.3 Avaliar um chamado....................................................................................... 83
iv
LISTA DE ABREVIATURAS
AI Acquisition & Implementation CERN Centre Europeen de Recherche Nucleaire CI Configuration Item COBIT Control Objectives for Information and Related Technology COSO Committee of Sponsoring Organizations of the Treadway Commission CSS Cascading Style Sheets DOM Document Object Model DS Delivery & Support EFQM European Foundation for Quality Management ERP Enterprise Resource Planning HTML Hyper Text Markup Language HTTP Hyper Text Transfer Protocol IEC International Electrotechnical Commission ISO International Organization for Standardization ITIL Information Technology Infrastructure Library MIME Multiporpouse Internet Mail Extension MO Monitoring NCSA National Center for Supercomputing Applications PO Planning & Organization SGBD Sistema Gerenciador de Banco de Dados SLA Service Level Agreement SQL Structured Query Language TCC Trabalho de Conclusão de Curso TI Tecnologia da Informação UML Unified Modeling Language URI Universal Resources Identifier W3C World Wide Web Consortium
v
LISTA DE FIGURAS
Figura 1. O Modelo da Cadeia Serviço-Rentabilidade ........................................................................2 Figura 2. Transição da Era TI para Era Rede.......................................................................................8 Figura 3. Metodologias de gerenciamento de TI................................................................................10 Figura 4. O COBIT definido em quatro domínios de processo. ........................................................12 Figura 5. Diagrama de Quebra-cabeças do ITIL................................................................................16 Figura 6. Processos do ITIL ...............................................................................................................19 Figura 7. O ciclo de vida de um incidente..........................................................................................21 Figura 8. Suporte de primeiro, segundo e terceiro nível. ...................................................................23 Figura 9. Principais Componentes de um Sistema Web.....................................................................27 Figura 10. Transação HTTP. ..............................................................................................................28 Figura 11. Exemplo de código HTML e apresentação do documento...............................................30 Figura 12. Exemplo de código e apresentação em PHP.....................................................................33 Figura 13. Diagrama de classes da aplicação .....................................................................................52 Figura 14. Diagrama do banco de dados ............................................................................................55 Figura 15. Script de criação da tabela chamado.................................................................................56 Figura 16. Descrição da tabela “chamado” fornecida pelo SGBD ....................................................57 Figura 17. Trecho do método cadastrar() ...........................................................................................58 Figura 18. Trecho do método executar_alteracao() ...........................................................................59 Figura 19. Trecho do método procurar() ............................................................................................59 Figura 20. Validação do caso de uso 11: Avaliar atendimento..........................................................61 Figura 21. Validação do caso de uso 1: Registrar chamado...............................................................61 Figura 22. Validação do caso de uso 2: Registrar/categorizar chamado............................................62 Figura 23. Validação do caso de uso 3: Iniciar atendimento .............................................................63 Figura 24. Validação do caso de uso 4: Registrar atividade ..............................................................64 Figura 25. Validação do caso de uso 5: Encaminhar chamado..........................................................65 Figura 26. Validação do caso de uso 6: Fechar e reabrir chamados ..................................................65 Figura 27. Validação do caso de uso 7: Prorrogar chamado..............................................................66 Figura 28. Validação do caso de uso 8: Cancelar chamado ...............................................................67 Figura 29. Validação do caso de uso 9: Abrir sub-chamado..............................................................68 Figura 30. Validação do caso de uso 10: Informar estágio para cliente.............................................69 Figura 31. Validação do caso de uso 12: Cadastro de usuário ...........................................................70 Figura 32. Validação do caso de uso 13: Cadastro de tipos de atividades .........................................70 Figura 33. Validação do caso de uso 14: Cadastro de ativo de TI .....................................................71 Figura 34. Validação do caso de uso 15: Cadastro de SLA ...............................................................72 Figura 35. Tela de login do sistema ...................................................................................................80 Figura 36. Opção “Abrir Chamado” ..................................................................................................80 Figura 37. Descrição do incidente......................................................................................................81 Figura 38. Tela de abertura de chamado ............................................................................................81 Figura 39. Opção “Histórico de chamado” ........................................................................................82 Figura 40. Lista de chamados para visualização de histórico ............................................................83 Figura 41. Opção “Avaliar chamado” ................................................................................................83 Figura 42. Lista de chamados para avaliação.....................................................................................84 Figura 43. Detalhes do chamado cadastrado para avaliação ..............................................................84 Figura 44. Tela de avaliação de um chamado ....................................................................................85
vi
RESUMO
BORTOLUZZI, Lucas. Um sistema de apoio ao gerenciamento de incidentes de TI baseado na recomendação ITIL. Itajaí, 2007. 85 p. 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í, 2007. As organizações em todo o mundo visam aperfeiçoar a forma de realização dos seus negócios, buscando aumentar eficiência e eficácia ao mesmo tempo em que reduzem seus custos. A Tecnologia da Informação exerce papel fundamental neste processo, uma vez que esta área possui uma forte inter-relação com os processos de negócios. O correto gerenciamento dos serviços de TI permite ampliar a eficiência e efetividade das novas tecnologias. O presente trabalho analisa as tendências de gestão de TI, qualifica e delimita o ITIL como o modelo a ser seguido nas questões de gerenciamento de serviços. Em seguida, aborda a teoria de sistemas web como plataforma de referência a esta solução. Finalmente, demonstra o desenvolvimento do Sistema de Apoio ao Gerenciamento de Incidentes de TI Baseado na Recomendação ITIL, com o objetivo de aperfeiçoar os processos de atendimento aos clientes e usuários, aumentando a qualidade dos serviços prestados, fornecendo uma maior transparência, confiança e agilidade para setores responsáveis por administrar as tecnologias da informação. Palavras-chave: Sistemas de Informação. Gerenciamento de Incidentes de TI. Melhores Práticas do ITIL.
vii
ABSTRACT
Organizations all around the world are aiming to improve the way their businesses are done, seeking to increase their efficiency and effectiveness, beyond reducing its costs. The Information Technology has a basic role in this process, once this sector has a strong inter-relationship with the business process. The right IT services management allows increasing the efficiency and effectiveness of the new technologies. This paper analyzes the IT government trends, qualifies and delimits the ITIL as a model to be followed in the service management area. After that, it approaches the theory of the Web systems as a reference platform to this solution. Finally, this paper presents the creation of the IT incident management support system based on the ITIL best practices, with the objective of perfecting the client and user support, raising the quality of the given services, supplying better transparency, confidence and agility to the responsible sectors for managing the Information Technologies. Keywords: Information Systems. IT Incident Management. ITIL best practices.
1 INTRODUÇÃO
As pessoas são os recursos chave para qualquer organização. As pessoas devem atuar
integradas aos processos de negócio. A informação e a tecnologia da informação têm papel
fundamental em promover a interação e colaboração humana para alcançar a meta comum
(AMBOUJ GOYAL, 2003). Nesta simbiose, se faz necessário a formação de uma cultura digital
que depende de uma operação tecnológica ininterrupta, de qualidade e segura.
A existência de um departamento ou diretoria de tecnologia da informação em uma
organização, tem como premissa o amadurecimento do pensamento executivo que busca agregar
valor ao negócio por meio das tecnologias da informação. Esta unidade funcional desenvolve
objetivos de controle e prestação de contas que permitem o domínio da complexidade da tecnologia
e facilitam o controle da qualificação profissional da equipe técnica, a administração de serviços de
suporte ao usuário e a gestão do conhecimento.
No desdobramento da necessidade de aplicação das tecnologias de informação está o
aumento progressivo da complexidade da tecnologia, o descompasso da preparação dos técnicos em
gerenciá-la, e a dificuldade de absorção dos usuários do potencial das ferramentas em mãos
(CABRAL; THIVES JR, 2005). Comumente os usuários deste recurso precisam de suporte, pois
normalmente as atividades diárias dos seus funcionários incluem novos processos, requerendo
novas tecnologias. Assim sendo, um pensamento diferenciado na gestão de TI deve ser
desenvolvido.
1.1 PROBLEMATIZAÇÃO
1.1.1 Formulação do Problema
A simples existência de uma área de TI não a torna uma solução em si. Sua gestão vai além
das atividades de suporte aos usuários, e passa a incorporar pensamentos gerais da administração
como controles de custos, contratos, ativos físicos e humanos. Como fator crítico de sucesso, a área
de TI deve aprimorar-se constantemente nas suas formas de atendimento para satisfação dos
clientes internos e externos da organização.
Muitos setores de suporte estão sob pressão para melhorar o serviço e reduzir custos. Eles
tendem a trabalhar como uma coleção perdida de equipes dispersas, desperdiçando grandes
2
quantidades de tempo apagando incêndios e, geralmente, mantendo “suas cabeças acima da água”
(BERKHOUT et. al., 2000). Existem várias situações e cenários, e entre eles é comum encontrar:
• Mecanismos de suporte não-estruturados;
• Baixa confiança e percepção do cliente;
• Recursos de suporte sub-gerenciados;
• Falta de foco, entre outros.
Em uma visão ampla, a problematização do gerenciamento de serviços de TI (Seção 2.1.2 )
tem relação com as preocupações existentes nos modelos de qualidade (Figura 1) que buscam tornar
as organizações mais eficientes e eficazes, gerenciando seus processos de forma sistêmica. Isso
garante que nada importante seja esquecido e que todos estejam conscientes sobre quem é
responsável para fazer o que, quando, como, por que e onde.
Figura 1. O Modelo da Cadeia Serviço-Rentabilidade
Fonte: Adaptado de: BERKHOUT et. al., 2000.
Um Sistema de Gestão da Qualidade é a estrutura organizacional, responsabilidades,
procedimentos, processos e recursos necessários para o desenvolvimento do gerenciamento da
qualidade. Dá ênfase à prevenção de problemas, ao invés da sua correção. O seu foco é a definição
e documentação de processos, a sua implementação e a garantia da sua eficácia para atingir os
resultados esperados. Deve desenvolver mecanismos que auxiliem na sobrevivência da organização
3
e possibilitem sua permanente e contínua evolução. É o processo de definição, implantação e
avaliação de políticas da qualidade.
Neste contexto, a biblioteca de infra-estrutura da tecnologia da informação (ITIL) constitui
referência para um modelo de qualidade e auditoria de forte relacionamento com sistemas de
qualidade como o ISO9000 e o framework de qualidade total da Fundação Européia para Gerência
de Qualidade (EFQM). O ITIL estabelece regras para os processos de gerenciamento de serviços de
TI viabilizando um caminho rápido para a certificação ISO (BERKHOUT et. al., 2000).
O foco do ITIL (Seção 2.1.3 ) é prover serviços de alta qualidade com um foco particular no
relacionamento com os clientes. Isso significa que a organização de TI deve prover tudo o que for
combinado com os clientes, o que implica em um forte relacionamento entre a organização de TI,
seus clientes e parceiros.
No Brasil, a adoção do ITIL tem sido progressiva ao longo dos últimos anos. Em pesquisa
recente, surge o indicativo de que 60% de grandes empresas nacionais já contam com profissionais
certificados em seu quadro de colaboradores (BRUNISE E CAMANHO & CONSULTORES,
2006).
1.1.2 Solução Proposta
O modelo ITIL prevê a existência de tecnologia para apoiar a própria gestão da tecnologia
da informação. Este trabalho demonstra o desenvolvimento de um sistema de apoio ao
gerenciamento de incidentes de TI baseado nas recomendações do ITIL.
Uma vez que todo o cenário descrito está dentro da área de TI, e o desenvolvimento de tal
aplicação está no escopo das habilidades de análise, projeto, desenvolvimento e validação de
software de um bacharel em Ciência da Computação, justifica-se então o desenvolvimento deste
projeto como um trabalho de Conclusão de Curso.
Assim nasce a solução proposta de disponibilizar uma aplicação que contemple o processo
de gerenciamento de serviços de TI em um ambiente com ponto único de contato, viabilizando a
solução de problemas rapidamente e que esteja alinhado com as necessidades da organização.
Este tipo de aplicação possui inúmeras funções. É importante o controle do tempo de
atendimento ao cliente, para análises de nível de serviço. A aplicação torna possível a tomada de
4
decisões pró-ativas para redução do número de falhas recorrentes, e possui mecanismos de
qualidade como uma central de feedback para análise da percepção dos clientes com relação ao
atendimento.
Esta ampla coleção de possibilidades necessita de delimitação (Seção 2.1.4 ). Em particular,
esta aplicação busca atender ao gerenciamento dos serviços providos por setores de TI de médias e
pequenas empresas que não possuem porém necessitam de uma ferramenta para o acompanhamento
de chamados de suporte, padronizando o atendimento ao cliente e aumentando a efetividade do
processo. Esta ferramenta apóia a tomada de decisões referentes ao suporte, mas não deve ser
confundida como um software Enterprise Resource Planning (ERP) e tem sua estrutura própria, não
sendo requisito sua integração a outros softwares já existentes.
Finalmente, os conceitos que serão empregados no solução proposta, ao serem baseados na
metodologia ITIL, tem uma base sólida e eficaz para a sua modelagem (Seção 3.1.1 ).
1.2 OBJETIVOS
1.2.1 Objetivo Geral
O objetivo geral deste projeto de pesquisa é desenvolver um sistema de apoio ao
gerenciamento de serviços de TI. Esta aplicação deverá empregar tecnologia web e considerar as
recomendações de gerenciamento de serviços do ITIL.
1.2.2 Objetivos Específicos
Os objetivos deste trabalho são:
• Realizar levantamento bibliográfico para compreender as questões envolvidas no suporte
a serviços de tecnologia da informação, contextualizando o ITIL e sua relevância como
framework nas organizações mundiais;
• Estudar o modelo de Suporte a Serviço do ITIL, em sua totalidade, para delimitar o
escopo da aplicação proposta;
• Estabelecer o conjunto de tecnologias e linguagens de desenvolvimento de aplicações
web como ferramental para a construção da aplicação;
5
• Especificar um modelo conceitual, utilizando como referência a linguagem UML
(Unified Modeling Language), de forma a relacionar os Casos de Uso, entidades e
comportamento da aplicação;
• Construir os programas da aplicação;
• Testar e validar a aplicação em observância ao escopo de Suporte a Serviço do ITIL,
previamente definido;
• Documentar os resultados obtidos.
1.3 Metodologia
O conhecimento científico direciona-se às formas de pensamento e observação
concretizadas em estratégias que o pesquisador utiliza para o desvendamento de fenômenos. A
exigência da definição dos problemas que se objetiva solucionar desvenda formas, métodos e
processos de ação. É a busca da verdade ou certeza que o fato encerra (BARROS;
LEHFELD, 2000).
Métodos científicos são as formas mais seguras inventadas pelo homem para controlar o
movimento das coisas que cerceiam um fato e montar formas de compreensão adequadas de
fenômenos (BUNGE, 1974).
Os estudos realizados seguem o conceito de trabalho científico que reduz sua abordagem a
um único assunto, um único problema, com tratamento específico. É um trabalho monográfico que
busca aplicar diretrizes metodológicas amplamente aceitas na comunidade científica (SEVERINO,
2002), com ênfase nas etapas de:
1. Determinação do tema-problema-tese do trabalho: Nesta etapa foi escolhido e
determinado o assunto sobre o qual versa este trabalho e está constituído na pré-proposta
entregue no início dos trabalhos;
2. Levantamento da bibliografia: Estabelecido e determinado o tema do trabalho, foi
realizado um levantamento da documentação existente sobre o assunto;
3. Leitura e documentação: Nesta etapa foi realizada a pesquisa propriamente dita;
4. Construção lógica: As idéias da pesquisa foram estruturadas conforme as exigências
racionais da sistematização própria do trabalho;
6
5. Construção do texto e articulação dos parágrafos: Foi desenvolvido o texto em
parágrafos individuais, cada qual com idéia diferente sendo exposta;
6. Conclusão: Na conclusão, resume-se ou sintetiza-se o que se conseguiu.
1.4 Estrutura do trabalho
O Capítulo 1 introduz os conceitos fundamentais ao desenvolvimento deste trabalho.
Caracteriza-se a organização como estrutura orgânica da sociedade, onde a tecnologia é peça
fundamental para sua sobrevivência, e expõe o problema do gerenciamento de serviços de TI que
tem como resposta a aplicação de práticas baseadas em modelos de qualidade. O objetivo do
trabalho é, desta forma, apresentado.
O Capítulo 2 detalha as duas colunas que sustentam o referencial teórico deste trabalho. De
um lado, aborda os modelos de qualidade e auditoria existentes, qualificando e delimitando o ITIL
como a escolha do padrão a ser seguido. De outro lado, apresenta uma visão sobre sistemas web,
qualificando e delimitando as tecnologias necessárias ao desenvolvimento da aplicação proposta.
O Capítulo 3 extrai os requisitos funcionais e não-funcionais associados ao modelo ITIL e
aos sistemas web, respectivamente. Casos de uso são apresentados para melhor compreensão da
dinâmica da aplicação. Após isso é demonstrado o desenvolvimento da aplicação, seus testes e
resultados, assim como uma breve documentação do sistema.
O Capítulo 4 enseja as considerações finais, onde são abordados os resultados obtidos, assim
como sugestões para trabalhos futuros.
2 FUNDAMENTAÇÃO TEÓRICA
Este capítulo apresenta o corpo teórico de referência utilizado para a elaboração do Projeto
de Trabalho de Conclusão de Curso. A proposta constitui no desenvolvimento de uma aplicação
web para apoio a estruturas organizacionais de gerenciamento de serviços de TI. Este tema requer a
busca de fundamentação teórica em duas frentes:
1. Estudo do Gerenciamento de Serviços de TI (Seção 2.1): Obter o domínio dos
conhecimentos necessários para especificação e codificação do sistema com base na
metodologia ITIL;
2. Estudo de Desenvolvimento de Sistemas Web (Seção 2.2): Conhecer os fundamentos
destes sistemas para basear a aplicação na Internet.
2.1 GERENCIAMENTO DE SERVIÇOS DE TI
O gerenciamento de serviços de Tecnologia da Informação entra no contexto deste trabalho
na forma de um levantamento de práticas recomendadas e/ou padrões internacionais, seguida por
uma análise e delimitação de escopo para determinação dos requisitos funcionais do sistema a ser
desenvolvido.
2.1.1 Organizações e a Tecnologia da Informação
O aumento da competitividade, desmassificação continuada, maiores exigências de
desempenho, globalização, e liberalização são exemplos das imensas mudanças que muitas
organizações estão enfrentando nos dias de hoje. As empresas são forçadas a se reorganizar
continuamente e organicamente, ao passo que seu modelo funcional hierárquico se torna flexível e
altamente adaptável na produção de respostas às necessidades de seus clientes. Para lidar com estes
desafios, a Tecnologia da Informação é o elemento fundamental não apenas para reforçar a
efetividade e eficiência operacional, mas também para criar uma cadeia dinâmica nos
relacionamentos entre os fornecedores, produção, serviços, clientes e intervenientes (MUTSAERS;
ZEE; GIERTZ, 1998).
A administração das organizações deve ser orientada à melhoria do desempenho com a
aplicação estratégica das inovadoras tecnologias da informação. A preocupação com a redução de
8
custos torna-se insuficiente, e faz parceria com a busca da eficiência dos recursos humanos e a
racionalização e simplificação de processos (TACHIZAWA; ANDRADE, 2003).
No desdobramento da necessidade de aplicação das tecnologias de informação está o
aumento progressivo da complexidade da tecnologia, o descompasso da preparação dos técnicos em
gerenciá-la, e a dificuldade de absorção dos membros da organização sobre o potencial das novas
ferramentas em mãos (CABRAL; THIVES JR, 2005).
Em 1973, Nolan produziu a primeira iniciativa para contextualizar a mudança na maturidade
dos processos de gestão e produção de tecnologia por meio da análise da evolução dos sistemas de
informação (ROCHA; VASCONCELOS, 2004). Entende-se que os sistemas de informação
representam um dos principais ativos das tecnologias da informação e da comunicação, com
significativo desenvolvimento na transição das organizações de uma base industrial para a idade da
informação (Figura 2).
Figura 2. Transição da Era TI para Era Rede
Fonte: Adaptado de: MUTSAERS; ZEE; GIERTZ (1998).
Estudos posteriores, decorrentes e paralelos ao trabalho de Nolan formaram um arcabouço
teórico de conceitos como: os Seis Estágios de Maturidade de Nolan (NOLAN, 1979); as Curvas de
9
Aprendizagem de Tecnologia de McFarlan (MCFARLAN et al. 1982, 1983); as Sete Curvas “S” de
Galliers e Sutherland (GALLIERS; SUTHERLAND,1991), e as Três Eras de Maturidade de
Mutsaers (MUTSAERS; ZEE; GIERTZ, 1998). Neste contexto, é seguro dizer que a gestão da
tecnologia da informação deve ser considerada como de importância crítica à sobrevivência da
informação na era da informação (MUTSAERS; ZEE; GIERTZ, 1998). O desenvolvimento de uma
infra-estrutura de TI (e.g., plataforma baseada em pessoas, instalações, tecnologias, sistemas, e
dados) poderosa e flexível torna-se um pré-requisito para as organizações fazerem negócios
(ROCKART et. al., 1999).
2.1.2 O Gerenciamento de Serviços de Tecnologia da Informação
O avanço na maturidade dos processos de administração das tecnologias da informação
alavancou o surgimento de inúmeros modelos orientados à formação de estruturas de
relacionamentos e processos que direcionam, controlam, e equilibram as iniciativas organizacionais
em TI (3RD ED. COBIT STEERING COMMITTEE AND THE IT GOVERNACE INSTITUTE,
2000).
Atualmente existem diversos padrões e coleções de melhores práticas que descrevem como
deve ser feita a função de governança de TI nas organizações. Além das organizações de
estandardização internacionais, muitas organizações privadas têm publicado guias de orientação
como o ITIL (Information Technology Infrastructure Library), COBIT (Control Objectives for
Information and related Technology), ISO/IECs (International Organization for Standardization /
International Electrotechnical Commission), TickIT, COSO (Committee of Sponsoring
Organizations of the Treadway Commission) entre outros (IT GOVERNACE INSTITUTE, 2004).
10
Figura 3. Metodologias de gerenciamento de TI.
ITIL
O ITIL é a referência de contexto deste trabalho (Seção 2.1.3 ). O modelo ITIL reconhece a
dependência progressiva das organizações em seus processos de TI para satisfazer seus objetivos e
alcançar suas necessidades de negócios. Esta situação requer qualidade nos serviços de TI –
qualidade que seja combinada com as necessidades de negócio e com os requisitos das pessoas na
medida em que eles crescem (BERKHOUT et. al., 2000).
Essa otimização proporciona muitos benefícios: Automatização do gerenciamento dos
recursos, das aplicações e dos processos de TI. Reduzindo custos e a complexidade do ambiente, e
estimulando a interoperabilidade para melhorar a efetividade e a eficiência. Isso fornece a
flexibilidade para um ambiente operacional sob demanda, tanto para gerenciar a TI mais
dinamicamente quanto para criar capacidades de negócios mais ágeis com uma tecnologia flexível
(IBM CORPORATION, 2005).
O ITIL provê um conjunto de melhores práticas compreensíveis, consistentes e coerentes
para a governança de processos de TI, promovendo uma aproximação de qualidade para alcançar
efetividade e eficiência nos negócios com o uso de sistemas de informação (BERKHOUT et. al.,
2000).
11
Sendo um framework, o ITIL descreve os contornos de como organizar a gerência de
serviços de TI. O seu modelo apresenta os objetivos, atividades gerais, entradas e saídas de
processos, que podem ser incorporados dentro das organizações de TI. O ITIL não dita cada ação
que deve ser tomada no dia-a-dia, pois isso se diferencia de organização para organização. Ao
invés, o ITIL se foca nas melhores práticas que podem ser utilizadas em diferentes maneiras de
acordo com as necessidades da corporação (BERKHOUT et. al., 2000).
COBIT
Do ponto de vista do COBIT, a governança de uma corporação (i.e. o sistema quais as
corporações são governadas e controladas), e a governança de TI (i.e. a maneira qual a TI da
corporação é governada e controlada) são processos altamente interdependentes. A governança da
organização torna-se inadequada sem uma governança TI, e vice-versa (3RD ED. COBIT
STEERING COMMITTEE AND THE IT GOVERNACE INSTITUTE, 2000).
O modelo COBIT se propõe a alcançar as múltiplas necessidades de governança em TI
criando uma ponte entre os riscos de negócios, necessidades de controle e assuntos técnicos através
de seus 34 objetivos de controle de alto-nível, um para cada processo de TI, agrupados em 4
domínios abrangentes (Figura 4): planejamento e organização (PO), aquisição e implementação
(AI), entrega e suporte (DS), e monitoramento (MO). Esta estrutura contempla todos os fatores da
informação e da tecnologia que a suporta. Através do mapeamento desses 34 objetivos de controle,
pode-se assegurar que um sistema de controle adequado está em funcionamento para a gestão de um
ambiente de TI (3RD ED. COBIT STEERING COMMITTEE AND THE IT GOVERNACE
INSTITUTE, 2000).
Em resumo, com a necessidade de melhor gestão dos recursos de tecnologia da informação,
o modelo COBIT – que cumpre este objetivo, tem sido atentamente observado por empresas
nacionais e globais, com destaque para a possibilidade de facilitar o alinhamento de TI ao negócio
proporcionado por meio do alinhamento estratégico entre os objetivos de negócio (corporativo) e os
objetivos de uso da tecnologia da informação (CABRAL; THIVES JR, 2005).
12
Figura 4. O COBIT definido em quatro domínios de processo.
Fonte: Adaptado de: 3RD ED. COBIT STEERING COMMITTEE AND THE IT GOVERNACE
INSTITUTE (2000).
ISO/IEC 17799:2000
O padrão internacional ISO/IEC 17799:2000 é publicado pela ISO e pela IEC que juntaram
esforços para uma realizar uma comissão técnica. Ela fornece informações para o grupo de pessoas
13
responsáveis pela implementação da segurança da informação da organização. Ele pode ser visto
como base para o desenvolvimento dos padrões de segurança e práticas de gerenciamento. Para
melhorar a confiança da segurança da informação entre os processos da corporação, ele apresenta
10 seções, cada uma contendo 36 objetivos e 137 controles (IT GOVERNACE INSTITUTE, 2004).
A ISO/IEC 17799:2000 estabelece um guia de princípios gerais para iniciar, instalar, manter
e aperfeiçoar o gerenciamento da segurança da informação em uma organização. As suas metas
fornecem um guia geral para os objetivos mais comumente aceitos de gerência de segurança da
informação (INTERNATIONAL ORGANIZATION FOR STANDARDIZATION, 2004).
Eles baseiam-se em requerimentos legais como a proteção dos dados pessoais, da
informação interna e os direitos intelectuais. Algumas melhores práticas também mencionadas são:
Política da segurança da informação; as distribuições de responsabilidades pela segurança; e a
gerência continuidade dos negócios (IT GOVERNACE INSTITUTE, 2004).
Por se focar apenas em questões de segurança, a ISO/IEC 17799:2000 não contempla todo o
escopo das tarefas de governança de TI, porém seu nível de detalhamento é comparável com o
COBIT (IT GOVERNACE INSTITUTE, 2004).
ISO/IEC TR 13335
O padrão internacional ISO/IEC TR 13335 é uma série de cinco documentos publicados pela
ISO, que representa as melhores práticas para o gerenciamento de segurança de TI. Seus capítulos
em ordem são (KEMPNICH, 2005):
• Parte 1: Conceitos de modelos para segurança de TI;
• Parte 2: Gerenciando e planejando segurança de TI;
• Parte 3: Técnicas para o gerenciamento de segurança de TI;
• Parte 4: Seleção de meios de proteção;
• Parte 5: Guia de gerenciamento em segurança de rede.
Este padrão é aplicável em todos os tipos de organizações e é explicitamente voltado para a
alta gerência e aos gerentes de segurança da informação, enquanto suas outras quatro partes
dirigem-se as pessoas responsáveis pela implementação das medidas de segurança (IT
GOVERNACE INSTITUTE, 2004).
14
ISO/IEC 15408:1999
Existe ainda outro padrão internacional voltado para segurança, a ISO/IEC 15408:1999. Por
sua vez, este foi criado para definir critérios base para acompanhamento da evolução da segurança
da TI, focando-se em segurança de sistemas e produtos (IT GOVERNACE INSTITUTE, 2004).
Ele se apresenta dividido em três partes: Introdução e o modelo geral; requerimentos de
segurança funcional; e requerimentos de garantia de segurança, e deve ser utilizadas para definir as
medidas de segurança de TI apropriadas e para o acompanhamento dos requisitos de segurança da
corporação (INTERNATIONAL ORGANIZATION FOR STANDARDIZATION, 1999).
TickIT
O TickIT é um plano para a avaliação e certificação do sistema de gerenciamento de
qualidade de software de uma corporação. Ele é voltado para as organizações onde o
desenvolvimento de software agrega valor aos seus produtos ou serviços, também sendo relevante
para a alta gerência, pessoal operacional e autoridades de certificação. O TickIT é focado em três
públicos-alvos: Clientes (como o cliente pode influenciar na qualidade do produto), fornecedores
(melhoramento da efetividade de seus sistemas de gerencia de qualidade) e auditores (como
melhorar os procedimentos definidos no TickIT) (IT GOVERNACE INSTITUTE, 2004).
Ele pode ser usado para ajudar o desenvolvimento de todos os tipos de software, como
sistemas operacionais, sistemas embarcados ou para escritório. O padrão é baseado na ISO 9000-3
(padrões de gerenciamento da qualidade e garantia da qualidade – parte três do guia de aplicação da
ISO 9001:1994 para o desenvolvimento, fornecimento, instalação e gerenciamento de softwares de
computadores), e inclui informações no guia trazendo mais direção para clientes, fornecedores e
auditores. Também contém requerimentos claros para auditores que devem ser alcançados pelo
pessoal a ser certificado (IT GOVERNACE INSTITUTE, 2004).
Através deste guia, os desenvolvedores de software são encorajados a pensar na qualidade
interna do processo de desenvolvimento de software, a alcançar objetivos de qualidade e a dar
continuidade ao sistema de gerenciamento de qualidade (BSI GROUP, 2001).
COSO
Para o COSO, a receita da organização é maximizada quando a administração cria
estratégias e objetivos para descobrir um balanço ótimo entre crescimento, retorno dos objetivos e
15
riscos relacionados, efetividade e eficiência, e na distribuição de recursos na busca dos objetivos da
corporação (COMMITTEE OF SPONSORING ORGANIZATIONS OF THE TREADWAY
COMMISSION, 2004).
O guia apresenta a existência de cinco componentes que formam o controle interno. A
maneira que eles se inter-relacionam e interagem e como eles influenciam os objetivos da
organização é o sistema de controle interno, que por sua vez é individual para uma organização, ou
seja, duas organizações não podem possuir o mesmo sistema. Ele depende do tamanho da
organização, o ramo e até mesmo na cultura e na filosofia de governança (COMMITTEE OF
SPONSORING ORGANIZATIONS OF THE TREADWAY COMMISSION, 2004).
O seu objetivo consiste no melhoramento das formas de controle dos processos das
corporações através da definição de um sistema de controle integrado. Ele possibilita os altos
executivos a criar controles de seus processos internos para assegurar a realização de suas missões e
dos objetivos de lucro para o gerenciamento de riscos. (IT GOVERNACE INSTITUTE, 2004).
2.1.3 IT Infrastructure Library: ITIL
O ITIL está dividido em cinco macro-processos de gerenciamento (
Figura 5), apresentado nos cinco livros: Deliver IT Services (BARTLETT et. al., 2000),
Support IT Services (BERKHOUT et. al., 2000), Application Management (BARON, 2000), ICT
Infrastructure Management (GRAHAM et. al., 2000) e Business Perspective: the IS view on
delivering services to the business (OFFICE OF GOVERNMENT COMMERCE, 2004).
16
Figura 5. Diagrama de Quebra-cabeças do ITIL
Fonte: Retirado de: BERKHOUT (2000).
Estes macro-processos abordam temas que se sobrepõem e se completam, e não existem
limites estritos de demarcação, onde os conceitos abordados se aglomeram e se expandem sem uma
divisão explícita de propriedade. É exatamente onde os domínios dos processos se sobrepõem ou
onde as linhas de demarcação não podem ser claramente desenhadas que muitos problemas de
gestão aparecem. Não é possível evitar que todos estes problemas aconteçam, mas é possível alertar
e preparar-se para conviver com eles (BERKOUT et. al., 2000).
O livro Service Support tem foco em assegurar que o usuário tenha acesso aos serviços
apropriados para suportar as funções de negócios (BERKHOUT et. al, 2000). Este livro possui
relação com este trabalho em razão de tratar de questões associadas ao gerenciamento de serviços .
Os assuntos discutidos nesse livro são:
• Service Desk: É a única função prevista no gerenciamento de serviços de TI pelo ITIL, e
tem profissionais com responsabilidades de relacionamento diário com os usuários,
equipe de TI e com contratos terceirizados. É o ponto focal de toda articulação dos
processos do ITIL. Esta função é de interesse direto ao escopo do trabalho (ver Seção
2.1.4 );
17
• Gerenciamento de incidentes: seu objetivo principal é restaurar os serviços de TI de
falhas, da maneira mais rápida possível, diminuindo os impactos nas operações do
negócio. Este processo é de interesse direto ao escopo do trabalho (ver Seção 2.1.4 );
• Gerenciamento de problemas: minimiza os diversos impactos de incidentes nos negócios
que são causados por erros provenientes da infra-estrutura de TI;
• Gerenciamento de configuração: fornece um modelo lógico da infra-estrutura ou de um
serviço através da identificação, controle, manutenção e verificação da configuração dos
ativos existentes;
• Gerenciamento de mudanças: assegura que métodos e procedimentos padronizados
sejam usados para o tratamento eficiente e imediato de todas as mudanças de TI,
diminuindo os impactos na qualidade dos serviços causados por incidentes relacionados
a estas mudanças;
• Gerenciamento de liberação: garante que todos os aspectos técnicos e não técnicos
envolvidos na liberação de um novo software ou hardware sejam considerados juntos.
O livro Service Delivery foca os requerimentos de negócios de serviços do fornecedor para
prover suporte adequado às pessoas que usufruem do serviço (cliente) (BARTLETT et al., 2000).
Para prover o suporte necessário, o livro cobre os seguintes tópicos:
• Gerenciamento do relacionamento com o cliente: estabelece uma função para tratar as
questões de relacionamento com o cliente que contrata os serviços de TI;
• Gerenciamento da capacidade: responsável por assegurar que a capacidade da infra-
estrutura de TI seja compatível com as permanentes mudanças de maneira eficaz e
eficiente;
• Gerenciamento financeiro dos serviços de TI: tem como objetivo prover uma economia
de custos efetiva dos ativos e recursos de TI usados para o fornecimento dos serviços de
TI;
• Gerenciamento da disponibilidade: tem como preocupação o design, a implementação, a
dimensão e o gerenciamento da disponibilidade de infra-estrutura de TI para assegurar
que os objetivos do negócio acordados sejam sempre alcançados;
18
• Gerenciamento de nível de serviço: determina e monitora o nível dos serviços de TI
necessários para suportar os negócios da empresa;
• Gerenciamento da continuidade dos serviços de TI: assegura-se que a infra-estrutura de
TI possa ser recuperada em caso de falha dentro de um período de tempo pré-
estabelecido.
O livro ICT Infrastructure Management inclui (GRAHAM et. al., 2000):
• Design e planejamento: prover caminhos estratégicos para o desenvolvimento e
instalação de uma infra-estrutura onde o negócio de empresa é TI (ICT), satisfazendo as
atuais e futuras necessidades do negócio;
• Posicionamento estratégico: cria ou modifica uma solução ICT feita para um ou mais
fatores técnicos, e assegura que os serviços de suporte estejam prontos para tornar a
nova ou modificada infra-estrutura totalmente funcional;
• Operações: assegura uma fundação estável e segura quais os serviços ICT são providos
através do monitoramento e controle da tecnologia;
• Suporte técnico: fornece um suporte com experiência sempre disponível para servir
como base para os serviços prestados pelo ICT.
O livro Business Perspective (OFFICE OF GOVERNMENT COMMERCE, 2004) cobre o
âmbito dos assuntos relacionados com o entendimento e o melhoramento das provisões dos serviços
de TI, como uma parte integral de um negócio completo que necessita de qualidade de governança.
Esses assuntos incluem gerenciamento da continuidade dos negócios; parcerias e terceirização;
sobrevivência a mudanças; e transformação das práticas de negócios através de mudanças radicais.
Por último, o livro Applications Management (BARON et. al., 2000) cobre o ciclo de vida
do desenvolvimento de software expandindo os assuntos abordados em Software Lifecycle Support
e Testing of IT Services. O gerenciamento de aplicações expande os assuntos de mudança de
negócios com ênfase nas definições claras dos requerimentos e da implementação de uma solução
que contemple as necessidades de negócios.
19
2.1.4 Escopo do Trabalho
O escopo deste trabalho se refere ao desenvolvimento de um sistema de apoio ao
gerenciamento de serviços de TI limitado aos requisitos do processo de gerenciamento de
incidentes do ITIL. Este processo faz parte do livro Service Support (BERKHOUT et. al., 2000),
e foi escolhido por ser um processo base necessário ao melhor desenvolvimento dos demais
processos.
Figura 6. Processos do ITIL
Fonte: Adaptado de: BERKHOUT et. al. (2000).
Desta forma, para um melhor entendimento do processo de gerenciamento de incidentes, a
função do Service Desk necessita primeiramente ser conceituada.
Conceitos Utilizados: Service Desk
Para o Service Desk, o fator mais importante a ser considerado é o contato com o usuário.
Segundo BERKHOUT et. al., (2000), o Service Desk deve prover um ponto único de contato do
serviços de TI para o usuário. Este contato não requer necessariamente ser realizado por telefone. A
Internet e o e-mail são meios de contato extremamente úteis e eficazes no dia-a-dia de um Service
Desk.
20
O relacionamento com o usuário no Service Desk é fundamental, requerendo desta forma
que a organização mantenha informações únicas e detalhadas sobre cada um. Dentre essas
informações, destacamos: nome do cliente/usuário; código de identificação; número de série do
computador/equipamento que o cliente/usuário possui; correio eletrônico; telefone; endereço.
A cada contato realizado por um cliente, deve-se criar um incidente associado, que equivale
a um número de protocolo para rastrear o atendimento. Este incidente deve ser acompanhado pelo
Service Desk até a sua conclusão. As informações provenientes dos registros associados a cada
incidente podem ser extraídas e usadas como medidores de eficiência e eficácia para o
gerenciamento do nível de serviço prestado pelo setor. O método de solução do incidente também
deve ser guardado para consultas posteriores, por mais simples que se pareça a sua solução.
Os incidentes que não podem ser resolvidos prontamente pelos atendentes devem ser
encaminhados para o pessoal de suporte de segundo nível, ou para o pessoal de suporte terceirizado
para análise e solução. Deve-se ter cuidado com o tempo despendido no telefone pelo atendente na
solução do problema, uma vez que os postos telefônicos do atendimento são limitados e devem
permanecer disponíveis.
Para o melhor funcionamento do Service Desk, seus atendentes devem ter nível de
autoridade suficiente para dar voz de comando aos atendentes de segundo nível, visto que não
devem ocorrer quebras na hierarquia da prestação de serviços. Também é necessário que o setor de
segundo nível esteja ciente dos acordos de nível de serviços que eles devem ser aptos a prestar.
As reclamações também devem ser guardadas. Caso um cliente reclame que um serviço está
com defeito durante uma semana inteira, então estes registros são necessários para que a
credibilidade do Service Desk não seja afetada erroneamente.
Conceitos Utilizados: Gerenciamento de Incidentes
O Service Desk é responsável por monitorar o processo de solução de todos os incidentes
reportados. Um efeito disto é que todos os incidentes pertencem ao Service Desk. Este processo é
em sua maior parte reativo. Para o Service Desk ter a habilidade de reagir eficiente e eficazmente
aos incidentes, cria-se uma demanda por um método formal de trabalho, que deve ser assistido por
sistema que realize o gerenciamento de incidentes (BERKHOUT et. al., 2000).
21
No âmbito do gerenciamento de incidentes, o incidente deve ser resolvido ou remediado o
mais rápido possível, para que o impacto do serviço faltante para o cliente não seja demasiado.
Após a solução da causa do problema e a restauração do serviço previamente acordado, o incidente
é fechado.
A Figura 7 ilustra mais detalhadamente o ciclo de vida de um incidente.
Figura 7. O ciclo de vida de um incidente
Fonte: Retirado de: BERKHOUT et. al. (2000).
Detecção e registro do Incidente
Dentro do ciclo de vida do incidente, o primeiro passo a ser adotado é a detecção e o registro
do incidente. Os dados obtidos através do Service Desk servem de base para o processo de
gerenciamento de incidentes. Sintomas, dados de diagnóstico básicos e informações sobre o item de
configuração (CI) são algumas das informações devem compor os registros da detecção do
22
incidente. Neste processo, o ponto chave é a coleta de informações realizada pelo Service Desk, que
sempre deve estar ciente de todos os incidentes ocorridos na organização.
Classificação inicial e suporte
As informações do incidente levantadas anteriormente são agora utilizadas pelo processo de
classificação e suporte inicial. O processo de classificação identifica qual é o incidente e a sua ação
de solução para o problema. A combinação bem sucedida de razão e solução provê uma solução
bem sucedida que não necessita outras ações de investigação.
Este é um processo delicado, uma vez que ele tem o poder de acelerar e minimizar os
recursos de suporte utilizados na solução de um incidente, reduzindo custos e aumentando a
eficiência do Service Desk.
A classificação final do incidente pode variar daquela reportada primeiramente pelo cliente.
Isso se deve ao fato que os clientes têm apenas a visão de reportar os sintomas de um incidente, e
não a sua causa-raiz.
Durante o seu ciclo de vida, o incidente deve ser alterado conforme a sua situação, e um
registro de todas as ações tomadas devem ser guardados. Isto se torna especialmente importante
para manter o cliente informado sobre o progresso do incidente.
Para o processo de atendimento a incidentes ser mais eficiente, ele é dividido em níveis de
atendimento. Um incidente simples pode ser solucionado rapidamente por telefone pelo suporte de
primeiro nível. Soluções mais complexas exigem o uso de equipes de especialistas, que são
encontrados nos níveis seguintes. O fluxo desse processo é ilustrado na
Figura 8.
23
Figura 8. Suporte de primeiro, segundo e terceiro nível.
Fonte: Retirado de: BERKHOUT et. al. (2000).
A priorização dos incidentes para atendimento é outro fator chave do gerenciamento de
incidentes. Ele deve ser definido pelo impacto que pode ser causado nos negócios da organização e
pela urgência que a solução é necessária.
Investigação e diagnóstico
Esta atividade visa prover meios para que o cliente consiga continuar com as suas tarefas,
mesmo que através de um serviço degradado, diminuindo o impacto do incidente nos negócios. Isso
fornece mais tempo para investigar e planejar uma solução estruturada.
24
A atividade de investigação e diagnose pode se tornar um processo interativo, uma vez que
ele pode se iniciar com um grupo de especialistas, e envolver grupos de suporte terceirizados, e de
diferentes fornecedores. Caso a solução do incidente perdure mais de um turno de trabalho, ela pode
continuar com o novo turno. Isso requer uma abordagem rigorosa e disciplinada, e um registro
compreensivo de ações tomadas com os resultados correspondentes.
Resolução e recuperação
Através dos detalhes do incidente atualizados fornecidos pelo processo de Investigação e
diagnose e qualquer solução semelhante, o processo de Solução e Recuperação deve resolver o
incidente ou tomar ações de recuperação. Este processo deve solucionar o incidente, gerar detalhes
de recuperação e atualizar os detalhes do incidente.
Após uma solução efetiva, o processo de recuperação pode ser realizado e ações de
recuperação podem ser executadas. Isso geralmente é realizado por uma equipe de especialistas de
segundo ou terceiro nível. O sistema que realiza o gerenciamento dos incidentes deve permitir o
registro dos eventos e das ações durante a atividade de solução e recuperação.
Fechamento do incidente
Quando o incidente é resolvido, o Service Desk deve garantir que todas as informações
sejam gravadas. Detalhes como a ação tomada para resolver o incidente devem ser concisas e
compreensivas, e a ação/solução deve estar de acordo com o usuário.
Posse, monitoramento, rastreamento e comunicação
O Service Desk é responsável por coordenar a solução de todos os incidentes não
solucionados, seja qual for a sua fonte inicial.
Para isso, o Service Desk deve monitorar regularmente o status e o progresso da solução e
dos acordos de nível de serviço de todos os incidentes ativos. Também deve verificar os incidentes
que são movidos entre diferentes grupos de suporte especialistas, pois isso pode ser um indicativo
de incerteza, ou de uma possível disputa entre o grupo de suporte. Deve ser dada prioridade ao
monitoramento de incidentes com um alto nível de impacto para os negócios.
Seguir esse procedimento deve ajudar a garantir que cada incidente seja resolvido em
espaços de tempo pré-acordados, ou no mínimo de tempo possível. Para grandes Serice Desks, deve
25
se considerar a criação de um grupo especialmente para o monitoramento e perseguição dos
incidentes.
No caso de um incidente não atingir um progresso satisfatório, o Service Desk deve agir de
acordo com procedimentos de escalonamento pré-definidos. Estes procedimentos devem ser
acordados por todo o grupo de suporte.
Para julgar o desempenho do processo de gerenciamento de incidentes, aferições e metas
devem ser traçadas. As seguintes métricas são exemplos para medição da eficiência e eficácia do
processo de gerenciamento de incidentes (BERKHOUT et. al., 2000):
• Número total de incidentes;
• Tempo médio de solução;
• Cumprimento de SLA;
• Custo médio por incidente;
• Efetividade do Service Desk;
• Efetividade do atendimento remoto.
2.1.5 Considerações
A solução ao problema do gerenciamento de serviços de TI tem evoluído ao longo dos anos,
migrando de processos empíricos de tentativa e erro, rumo a modelos documentados que
consolidam melhores práticas, como o COBIT, ITIL, COSO, dentre outros.
O ITIL tem se tornado uma referência forte praticada por inúmeras empresas, incluindo
capacitação e certificação de profissionais em diversos níveis de maturidade. Este trabalho tem
como principal objetivo o desenvolvimento de uma aplicação que incorpore as recomendações do
processo de gerenciamento de incidentes feitas no livro Service Support (ver Seção 2.1.4 ).
Esta aplicação, que contempla requisitos funcionais do ITIL, foi desenvolvida com base na
tecnologia web. Os aspectos teóricos desta tecnologia, bem como sua delimitação prática por meio
de requisitos não funcionais, são abordados na Seção 2.2.
26
2.2 SISTEMAS WEB
2.2.1 Introdução
Este capítulo discorre sobre sistemas web e tecnologias agregadas. Projetos de sistemas web
necessitam ter definição clara sobre sua arquitetura, detalhando a forma de uso do protocolo HTTP
(Hyper Text Transfer Protocol), as linguagens de apresentação HTML (Hyper Text Markup
Language) e CSS (Cascading Style Sheets), linguagens de programação no lado cliente (e.g., cliente
dinâmico por javascript), linguagens de programação no lado servidor (e.g., tecnologia de ativação
PHP), e linguagens de programação de banco de dados (e.g., SGBD relacional MySQL).
2.2.2 Arquitetura de Sistemas Web
Para melhor compreender o funcionamento de um sistema web, é importante analisar as
diferentes tecnologias que o compõem, e sua forma de relacionamento (Figura 9).
27
Serv idor Web
SGBD Relacional
Tecnologia de Ativ ação
Serv iço de arquiv os
Serv iço HTTP Serv idor
Micro Computador Cliente
Serv iço HTTP Cliente
Interpretador WebCliente Dinâmico
Camada de Transporte
Figura 9. Principais Componentes de um Sistema Web
O lado cliente compreende os elementos do interpretador HTML e do serviço HTTP cliente
(i.e., user agent, ver Protocolo HTTP, Seção 2.2.2.1), que juntos definem a função do navegador
web, comumente conhecido como browser. Opcionalmente, o navegador pode ter sua função
estendida para se tornar um cliente dinâmico por meio de linguagem de programação específica
(e.g., javascript, visual basic ou flash).
O lado servidor compreende os elementos do serviço HTTP servidor (i.e., origin server, ver
Protocolo HTTP, Seção 2.2.2.1), que frequentemente acessa o serviço de arquivos do sistema
operacional e casualmente aciona tecnologias de ativação para processamento de scripts. Sistemas
web têm sua maior parte construída na forma de tecnologias de ativação que acessam banco de
dados para criar aplicações de negócio.
28
2.2.2.1 Serviço HTTP
Na arquitetura de sistemas web, o protocolo HTTP define a linguagem comum com a qual as
tecnologias do lado cliente vão se comunicar com as tecnologias do lado servidor. Em cada lado,
existe uma tecnologia que implementa o protocolo por meio de um serviço (i.e., serviço HTTP
servidor e serviço HTTP cliente, conforme ilustrado na Figura 9).
O protocolo HTTP funciona por meio de troca de mensagens do tipo requisição e resposta.
A maioria das comunicações é iniciada por um agente usuário (UA) e consiste de uma requisição
aplicável em algum recurso em um servidor de origem (O). No caso mais simples, isto pode ser
feito em uma única conexão (v). A Figura 10 ilustra este conceito (NETWORK WORKING
GROUP, 1999).
Figura 10. Transação HTTP.
Fonte: NETWORK WORKING GROUP (1999).
Em requisições HTTP, o cliente envia, através de uma conexão com o servidor, uma
requisição contendo o método de requisição, URI (Universal Resources Identifier), e a versão do
protocolo, seguido por uma mensagem do tipo MIME com modificadores da requisição, informação
do cliente, e possivelmente um corpo de conteúdo (NETWORK WORKING GROUP, 1999).
UA
OCONNECT
REQUEST
RESPONSE
DISCONNECT
29
Em respostas HTTP, o servidor responde, pela mesma conexão, com uma status line,
incluindo a versão do protocolo da mensagem e um código de erro ou sucesso, seguido por uma
mensagem do tipo MIME contendo informações do servidor, meta informação da entidade, e
possivelmente o corpo da entidade (NETWORK WORKING GROUP, 1999).
Existem diversas tecnologias que implementam o protocolo HTTP. No lado cliente,
implementando a função de solicitante, podemos citar as aplicações Internet Explorer, FireFox,
Opera e Konqueror dentre outros. No lado servidor, implementando a função de respondente,
podemos citar os serviços Apache HTTPD, Tomcat, Microsoft Internet Information Services (IIS),
Xitami, Oracle Internet Application Server (IAS), dentre outros. Em todos estes casos, o protocolo
HTTP é parte integrante do software, que adicionalmente pode desempenhar outras funções.
2.2.2.2 Interpretador Web
Um interpretador web compreende as tecnologias que interpretam e renderizam documentos
da world wide web em informações visuais. Estes interpretadores implementam padrões como
HTML, DOM (Document Object Model) e CSS, além de acionar os clientes dinâmicos quando um
script embutido deve ser processado.
HTML
HTML é a linguagem base utilizada por sistemas web para publicar informação, com
distribuição global, sendo universalmente aceita. Ela foi originalmente desenvolvida por Tim
Berners-Lee durante seu trabalho no CERN, e popularizado pelo navegador Mosaic desenvolvido
na NCSA. Na década de 90 o HTML explodiu com o crescimento da web. Até o presente já foi
estendido inúmeras vezes, tendo como versão raiz oficial a especificação do W3C versão 4.01
(RAGGETT et. al., 1999).
HTML é a linguagem mãe de apresentação da informação para todos os computadores, que
permite:
• Publicar documentos com cabeçalhos, textos, tabelas, fotos, entre outros;
• Recuperar informação através de links de hipertextos, com o simples clique de um
botão;
30
• Projetar formulários para conduzir transações com serviços remotos, para uso na
busca de mais informações;
• Incluir planilhas, vídeos-clipe, sons e outras aplicações como parte de seu próprio
documento.
A Figura 11 ilustra um exemplo de documento HTML.
Figura 11. Exemplo de código HTML e apresentação do documento.
É consenso que os documentos HTML devem funcionar corretamente em diferentes
arquiteturas e plataformas. Ao passo que isso acontece, custos de provedores de conteúdo
diminuem, visto que eles necessitam desenvolver apenas uma versão do documento. Caso contrário
existe um risco inerente que a web se tornará um mundo proprietário de formatos incompatíveis, e
finalmente diminuindo o potencial comercial da web (RAGGETT et. al., 1999).
A visão de desenvolvimento do HTML é que todos os tipos de dispositivos diferentes que
acessam a Internet possam utilizar as informações contidas na web (e.g., Computadores com
diferentes resoluções de gráficos e profundidade de cores, celulares, computadores de mão,
dispositivos com banda larga ou não, entre outros).
A versão 4.01 do HTML foi projetada com a ajuda de especialistas na área da
internacionalização, para que os documentos pudessem ser escritos em qualquer idioma e pudessem
ser facilmente transportados para qualquer lugar do mundo. Isto foi realizado com a incorporação
da RFC2070, que trata da internacionalização do HTML. Outro passo importante foi a adoção da
ISO/IEC 10646, padrão referente à representação de caracteres internacionais, direção de texto,
pontuação e outros (RAGGETT et. al., 1999).
31
Como a comunidade web cresce e seus membros se diversificam em suas habilidades, é
crucial que as tecnologias subjacentes sejam apropriadas para suas necessidades específicas. O
HTML também oferece suporte para que os sistemas web sejam acessíveis pelas pessoas com
limitações físicas.
Style sheets simplificam o design de sistemas web, e livram o HTML da responsabilidade de
apresentação, provendo controle sobre a apresentação de documentos tanto para o autor quanto para
o usuário. Informações sobre estilo podem ser especificadas para elementos individuais ou para
grupos de elementos, e podem se encontrar especificados em um documento HTML ou em uma
tabela de estilos externa. Os mecanismos de associação de estilos em um documento são
independentes do padrão de estilos utilizado.
CSS
O Cascading Style Sheets é um padrão para design de sistemas web introduzido pelo W3C,
que permite aos autores atribuir “estilo” a documentos estruturados, fornecendo um mecanismo
para o controle da aparência de documentos HTML. Cada navegador possui conjuntos pré-definidos
de estilos, próprios, para apresentação de conteúdo – com CSS, a apresentação torna-se única para
todos os navegadores. Ao permitir a separação entre CONTEÚDO (HTML) e ESTILO (CSS), o
CSS facilita a manutenção e autoria de sistemas web (LIE; BOS, 1999).
2.2.2.3 Clientes Dinâmicos
Scripts que são executados quando um documento web é carregado podem ter a capacidade
de modificar o conteúdo do documento dinamicamente. Esta habilidade em alterar o documento, de
forma dinâmica, depende da própria linguagem de script utilizada e permite a implementação do
conceito de “Cliente Dinâmico”.
DHTML e JavaScript
O DHTML, ou HTML Dinâmico, usa como referência a linguagem Javascript, trazendo
dinâmica aos sistemas web no lado cliente através de trechos de código embutidos no HTML.
A tecnologia de scripts mais comum nos navegadores nos dias de hoje é o javascript. A
javascript, é a implementação de uma linguagem de script que tem suas raízes na linguagem de
programação java. A javascript tinha a pretensão de ser mais fácil de aprender e usar do que o java;
os primeiros usuários da javascript estariam principalmente interessados em melhorar as interfaces
32
com o usuário e poderiam ter mais de um ambiente de criação do que um de programação. A
javascript vem incorporada em páginas HTML; portanto, precisa coexistir no documento, como
qualquer outro elemento do documento (NETSCAPE COMMUNICATIONS CORPORATION,
1999).
O Document Object Model (DOM), a fonte principal de objetos para javascript, coloca uma
interface de objeto tanto no documento HTML quanto no navegador. O javascript pode interagir
com o navegador para carregar uma nova página, examinar o histórico do navegador – paginas web
carregadas anteriormente – ou interagir com páginas de quadros vizinhos (APPARAO, 1998).
2.2.2.4 Tecnologia de Ativação
Tradicionalmente, sistemas web têm sua ênfase de programação no lado servidor, onde são
alocadas a maior parte das regras de negócio, mecanismos de segurança e armazenamento de
informação em ambiente estruturado (e.g., SGBD relacionais).
O termo tecnologia de ativação surge para denominar as tecnologias que são “ativadas” pelo
próprio serviço HTTP no lado servidor, que por definição interna associa determinados documentos
a motores de processamento. Um exemplo destas tecnologias são os motores PHP, comumente
associados a documentos com extensão “.php”.
PHP
O PHP (um acrônimo recursivo para "PHP: PHP Hypertext Preprocessor") é uma linguagem
de script Open Source de uso geral, muito utilizada e especialmente guarnecida para o
desenvolvimento de aplicações Web embútivel dentro do HTML
(BAKKEN et al., 2004).
Apresentar itens de informação, ou dados, acontece o tempo todo em praticamente todas as
páginas dinâmicas da web. Existem diversas formas de apresentação destes itens. No entanto, a
apresentação de listas e/ou detalhes são formas que generalizam boa parte das interfaces.
Apresentar itens em detalhe significa tornar disponível ao usuário todos os atributos ou
colunas de informação associados a uma determinada unidade de informação, ou entidade. Listas de
itens mostram um número de entidades, sendo apresentadas normalmente na forma de uma
tabulação, com alguns atributos identificados como colunas (BAKKEN et al., 2004).
33
O cadastro de itens, ou a “entrada de informações”, é o que torna simples websites em
sistemas web. Na web, o cadastro de itens é especificado através de formulários (BAKKEN et al.,
2004).
O processamento de formulários produz uma saída que reflete as expectativas do contexto
onde os dados são coletados
Podemos definir três tipos de estado para situação de cadastro de registros:
• Formulário em branco, com os campos inicializados com valores padrão;
• Formulário preenchido, a partir de um cadastro existente ou a partir de um erro no
preenchimento, inconsistências, ou falhas no servidor;
• Formulário aceito (após submissão), incluindo uma indicação de sucesso.
A Figura 11 ilustra um exemplo de documento HTML.
A Figura 12 ilustra um exemplo de código PHP embutido em um documento HTML.
Figura 12. Exemplo de código e apresentação em PHP.
2.2.2.5 SGBD Relacional
Uma base de dados é uma coleção estruturada de dados. Ela pode variar de uma simples lista
de compras a uma galeria de fotos ou uma grande quantidade de informações de uma corporação.
Para adicionar, acessar e processar os dados armazenados em uma base de dados computacional é
necessário um sistema que gerencie todos estes dados. Desde que os computadores são muito bons
em tratar grandes massas de dados, os sistemas gerenciadores de banco de dados atuam um papel
34
principal na computação, como aplicações stand-alone ou como parte de outros sistemas (MYSQL
AB, 2006).
MySQL
Atualmente existem vários tipos de banco de dados, cada um com suas aplicações
específicas. Para este trabalho foi escolhido o banco de dados MySQL, por ser um sistema
gerenciador de banco de dados relacional. Uma base de dados relacional armazena os dados em
tabelas separadas, ao invés de colocá-las em uma grande área de dados única. Isso aumenta o
desempenho e a flexibilidade do banco de dados.
O MySQL também é open-source. Isso significa que qualquer pessoa tem a possibilidade de
usar e até mesmo modificar este software. Qualquer um pode pegar o software na Internet e utiliza-
lo sem pagar nada por isso. Também é possível pegar o código-fonte, estudá-lo e alterá-lo de acordo
com qualquer necessidade específica. Sua licença de uso é GLP (GNU General Public License), o
que define o que pode e o que não pode ser feito com o software em diferentes situações. Ainda é
possível adquirir uma licença de uso do MySQL como uma aplicação comercial da empresa
MySQL AB (MYSQL AB, 2006).
Por ser originariamente desenvolvido para trabalhar com grandes massas de dados mais
rapidamente que as outras aplicações existentes, ele tem sido utilizado em ambientes de produção
com altas demandas por vários anos com sucesso. Apesar de o MySQL estar em constante
desenvolvimento, ele oferece um grande conjunto de funções ricas e úteis. Sua segurança,
desempenho e conectividade o fazem altamente recomendável para o acesso de base de dados
através da Internet (MYSQL AB, 2006).
2.2.3 Considerações
O termo sistemas web compreende um amplo conjunto de tecnologias, que desempenham
papéis tanto no lado servidor, quanto no lado cliente, criando um novo paradigma de
desenvolvimento de software em contraposição aos modelos tradicionais de standalone
(i.e., aplicação isolada) e cliente-servidor (i.e., aplicações transacionais síncronas de duas camadas).
Sistemas web são construídos na filosofia das aplicações distribuídas em escala para
múltiplos usuários, com arquitetura transacional assíncrona e com potencial para múltiplas
camadas. Para o desenvolvimento de sistemas com esta natureza, é necessário um planejamento
35
adequado para identificar as tecnologias a serem utilizadas, além da abordagem de uso de cada uma
delas.
A Seção 2.2 conceituou sistemas web para delimitar e relacionar as tecnologias a serem
empregadas na solução proposta. Ainda antes, a Seção 2.1, aborda o tema de Gerenciamento de
Serviços de TI, mais especificamente a função Service Desk e o processo de Gerenciamento de
Incidentes de TI do ITIL.
Por sua vez, a função Service Desk trata do problema do atendimento, sugerindo um ponto
central de contato para administrar questões de clientes e/ou usuários, resolvendo os problemas de
inexistência de abordagem estruturada ou de registros, a baixa confiança dos clientes no serviço
prestado, entre outros.
Já o processo de Gerenciamento de Incidentes de TI discorre sobre o sintoma dos problemas,
e retrata que o desafio numa situação de incidente é restaurar os serviços o mais rápido possível.
Juntos, a seção 2.1 qualifica e delimita o ITIL como framework para este projeto, e em conjunto
com a Seção 2.2 este trabalho conclui toda a sua fundamentação teórica necessária para elaboração
da aplicação.
3 DESENVOLVIMENTO
Este capítulo apresenta o corpo conceitual utilizado como referência para a construção da
aplicação do Projeto de Trabalho de Conclusão de Curso. Constitui-se na apresentação dos artefatos
conceituais necessários ao desenvolvimento da aplicação proposta, assim como na apresentação dos
testes e das dificuldades encontradas na construção da aplicação.
O modelo conceitual apresenta importantes grupos de artefatos:
1. Requisitos: Compreende os critérios que devem ser atendidos pela aplicação em um
nível mais detalhado. Em fase posterior, estes critérios (ou requisitos) foram utilizados
para teste e validação entre a proposta (conceitual) e os resultados obtidos (aplicação).
2. Regras de Negócio: As regras de negócio têm por objetivo detalhar necessidades
referentes aos requisitos do sistema, e não restringem as funcionalidades da aplicação.
3. Casos de Uso: Identifica as principais situações de uso da aplicação, fornecendo uma
percepção da dinâmica e das formas de uso do sistema nos diversos papéis de usuários.
4. Diagrama de classes: Representa a estrutura e as relações das classes que servem de
modelo para objetos. Define todas as classes necessárias para a codificação da aplicação.
5. Diagrama do banco de dados: Documenta a modelagem do banco de dados necessário
para a gravação dos dados da aplicação.
Complementarmente, encerra-se o presente Capítulo com as propostas de trabalhos futuros
relacionados a este projeto.
3.1 REQUISITOS
3.1.1 Funcionais
Requisitos Extraídos do ITIL
O modelo de qualidade ITIL para gerenciamento de serviços de TI é divido em cinco livros.
Este trabalho está delimitado para o livro Service Support, especificamente nas questões de Service
Desk e Incident Management (Seção 2.1.4 ). É desta função e deste processo que são extraídos os
requisitos funcionais da aplicação proposta.
37
Service Desk
O Service Desk é uma função de uma área de gerenciamento de serviços. O estudo das
regras definidas neste capítulo do ITIL Service Support auxilia a identificar os atores envolvidos e
os principais casos de uso.
RF1. O sistema deverá permitir o cadastro de usuários.
RF2. O sistema deverá permitir a um atendente o cadastro e cancelamento de incidentes.
RF3. O sistema deverá permitir o cadastro de atividades de um incidente.
RF4. O sistema deverá permitir o cadastro de tipos de atividades.
Gerenciamento de incidentes: Detecção e registro do incidente
RF5. O sistema deverá permitir a um cliente o cadastro de incidentes.
RF6. O sistema deverá permitir o envio de e-mail com o código de identificação do
incidente para o cliente.
RF7. O sistema deverá permitir que um atendente de Help Desk visualize todos os
incidentes organizados por estágio.
Gerenciamento de incidentes: Classificação inicial e suporte
RF8. O sistema deverá possibilitar a classificação do tipo de incidentes.
RF9. O sistema deverá permitir o cadastro de classes de ativos de TI.
RF10. O sistema deverá permitir o encaminhamento de um incidente.
RF11. O sistema deverá permitir a associação de um incidente a uma classe de ativos de TI.
RF12. O sistema deverá permitir classificação da severidade de incidentes.
RF13. O sistema deverá disponibilizar o histórico de um chamado através de seu código
identificador.
RF14. O sistema deverá permitir a abertura e fechamento de sub-chamados.
RF15. O sistema deverá possibilitar a prorrogação do tempo acordado com o cliente para a
resolução do incidente.
38
Gerenciamento de incidentes: Investigação e diagnóstico
As ações de investigação e diagnóstico são empíricas do atendente proprietário do incidente.
Estas ações acionam recursos definidos em outros processos do ITIL (e.g., Gerenciamento de
problemas). Fica estabelecido que as ações desta etapa podem ser representadas exclusivamente
pelo registro de atividades no incidente, não necessitando a descrição de requisitos funcionais
específicos.
Gerenciamento de incidentes: Resolução e recuperação
As ações de resolução e recuperação são empíricas do atendente proprietário do incidente.
Estas ações requerem contato com o usuário, e acionam recursos definidos em outros processos do
ITIL (e.g., Gerenciamento de problemas). Fica estabelecido que as ações desta etapa podem ser
representadas exclusivamente pelo registro de atividades no incidente, não necessitando a descrição
de requisitos funcionais específicos.
Gerenciamento de incidentes: Fechamento do Incidente
RF16. O sistema deverá possibilitar o fechamento de um incidente.
RF17. O sistema deverá possibilitar que o cliente avalie o atendimento do incidente após o
seu fechamento.
Gerenciamento de incidentes: Posse, monitoramento, rastreamento e comunicação
RF18. O sistema deverá permitir o cadastro de um SLA.
RF19. A cada mudança de situação de um incidente o sistema deverá informar o cliente via
e-mail.
RF20. O sistema deverá permitir que um atendente compare um incidente com a SLA que
lhe for compatível.
3.1.2 Não-Funcionais
O software será desenvolvido para a web usando a tecnologia PHP e o Sistema de
Gerenciamento de Banco de Dados MySQL, pois ambos são tecnologias livres, sem custo direto
associado e amplamente empregados.
RNF1. O sistema deve ser desenvolvido para a plataforma web (implementação).
39
RNF2. O sistema deve ser compatível com as especificações da W3C de HTML, Javascript
e DOM (conformidade).
RNF3. As páginas web não devem levar mais do que 15 segundos para serem carregadas em
uma conexão de Internet compatível com 128Kbps de transferência (em situações
normais de uso), exceto no caso de geração de relatórios (desempenho).
RNF4. O sistema não deve utilizar a técnica de pop-up (usabilidade).
RNF5. A persistência de login de usuário deverá ser armazenada no servidor (segurança).
RNF6. O servidor de páginas deverá ser o HTTPD Apache e sua versão deve ser a 2.2
(software).
RNF7. A tecnologia de ativação no lado servidor deve ser a linguagem de scripts PHP e a
sua versão deve ser a 5.1.4 (software).
RNF8. O sistema gerenciador de banco de dados utilizado deverá ser o MySQL versão 5.0
(software).
3.2 REGRAS DE NEGÓCIO
Cada regra de negócio está associada a um requisito funcional, perfazendo as necessidades
de cada um, suplementando os atributos e conformidades necessárias para o desenvolvimento da
aplicação.
Service Desk
RN1. A aplicação deverá ter quatro atores: atendente de primeiro nível, atendente de nível
“n”, cliente (que contrata os serviços), supervisor do Help Desk.
RN2. Os usuários do sistema deverão utilizar login e senha para autenticação.
RN3. O cliente contrata serviços de TI para seu grupo de usuários, que registram incidentes
dentro dos acordos previamente estabelecidos entre o cliente e a área de TI.
RN4. Os atributos de um usuário são: nome, nome de apresentação, tratamento, código de
pessoa, nome da empresa, nome do setor, cargo, telefone, e-mail, endereço, nome de
usuário, senha.
40
RN5. No caso de um usuário atendente, deverá possuir ainda: cliente associado, ativo(s) de
TI que utiliza, indicação VIP, e anotações associadas, equipe e sub-equipe a que
pertence (células).
RN6. As anotações associadas a um atendente devem ser feitas pela equipe de
atendimento.
RN7. Todo o incidente deverá possuir um código único que o identificará.
RN8. Todo o incidente deverá ter um usuário solicitante (reclamante).
RN9. Um incidente possuirá os seguintes estágios: em rascunho, aguardando atendimento,
em atendimento, pendente, concluído e cancelado.
RN10. As atividades deverão pertencer a um único atendente.
RN11. Uma atividade deverá conter data e hora de início, data e hora de finalização,
duração (tempo efetivo de atendimento) e tipo de atividade.
Gerenciamento de incidentes: Detecção e registro do incidente
RN12. Um incidente cadastrado por um cliente deverá receber o status de rascunho.
RN13. Quando um incidente for iniciado por um cliente deverá ser solicitada apenas a
descrição do pedido em texto corrido.
RN14. A data de cadastro de um incidente passa a ser a data de registro oficial do incidente.
RN15. Quando a abertura de um incidente não for realizada por um cliente, o sistema deverá
possibilitar fácil acesso à coleta de dados iniciais e classificação do incidente.
RN16. O cliente deverá receber por e-mail o código de identificação do incidente para
possíveis acompanhamentos.
RN17. Um incidente cadastrado por um cliente deverá estar imediatamente visível para os
atendentes de Help Desk.
Gerenciamento de incidentes: Classificação inicial e suporte
41
RN18. Um incidente pode ser classificado em relato de falha ou em solicitação de serviço.
RN19. O tempo decorrido do cadastro do incidente até o início do atendimento é chamado
de tempo de respostas que servirá de métricas de desempenho.
RN20. Toda a classe de ativos de TI deverá possui um conjunto de acordos de nível de
serviço previamente definidos.
RN21. A severidade de um incidente poderá ser: 1. crítica; 2. alta; 3. média; 4. baixa; 5.
muito baixa.
RN22. O atendimento inicial será realizado por um atendente de Help Desk, onde será
classificado o tipo e a severidade de um incidente, que por sua vez deverá constar em
seu histórico.
Gerenciamento de incidentes: Fechamento do chamado
RN23. As informações sobre o fechamento do chamado, detalhes sobre a solução do
problema, centro de custo e a satisfação do usuário devem ser gravados.
RN24. No fechamento de um chamado (relato de falha) deve-se garantir que a sua
classificação esteja de acordo com a causa-raiz do problema.
RN25. O cliente deverá ter a opção de indicar se o atendimento foi: ótimo; bom; satisfatório;
ruim ou péssimo.
RN26. Todos os incidentes que não tiverem sua satisfação respondida pelo cliente deverão
ser classificados como: satisfatório.
Gerenciamento de incidentes: Posse, monitoramento, rastreamento e comunicação
RN27. Um SLA é identificada por severidade, tipo de incidente e classe de ativo de TI.
RN28. Os atributos de um SLA são: tempo de resposta, tempo de solução, controle de
estouro de tempo de solução e notificação de gerência da TI.
RN29. O controle de estouro de tempo de solução e notificação de gerência da TI é dado por
uma porcentagem do tempo de solução.
42
3.3 CASOS DE USO
A aplicação será utilizada para registro, monitoramento, controle de propriedade,
rastreamento e comunicação do processo de gerenciamento de incidentes. Para tanto, foram
mapeados alguns casos de uso a serem utilizados na execução das atividades previstas para esse
processo. São eles:
1. Registrar chamado;
2. Registrar/categorizar chamado;
3. Iniciar atendimento;
4. Registrar atividade;
5. Encaminhar chamado;
6. Fechar e reabrir chamados;
7. Prorrogar chamado;
8. Cancelar chamado;
9. Abrir sub-chamado;
10. Informar estágio para cliente;
11. Avaliar atendimento;
12. Cadastro de usuário;
13. Cadastro de tipos de atividades;
14. Cadastro de ativo de TI;
15. Cadastro de SLA.
Essencialmente, a operação dos chamados ocorrerá com base em duas telas principais: tela
de detalhamento de incidente e tela de registro de atividade.
Registrar chamado
Um incidente pode ser registrado por cliente diretamente no sistema, para isto o cliente
deverá acessar o sistema e descrever em texto corrido a solicitação do serviço. Este chamado deverá
receber o estágio “em rascunho”.
43
Ao finalizar a abertura do chamado o cliente deverá receber por e-mail o número do
chamado que deverá ser único para identificação.
Este caso de uso contempla os requisitos funcionais: 05 e 06; e as regras de negócio: 07, 08,
12, 13 e 14.
Registrar/categorizar chamado
Para o início do processo de atendimento a um incidente, é necessário primeiramente que
exista um registro de evento, ou chamado. Esta ação é de responsabilidade de um atendente de Help
Desk, que deverá preencher o formulário de descrição do incidente na tela de abertura de chamado
do sistema.
Os campos do formulário, na ordem recomendada de preenchimento, são:
Cliente: Identifica o nível superior de uma unidade organizacional ao qual a pessoa de
contato está vinculada.
o Contato: Identifica a pessoa que está registrando o incidente. Apenas colaboradores
da instituição constam nesta base.
o Localidade: Identifica a localização geográfica do solicitante (contato). Para os
atendimentos em campo, sinaliza o local onde o atendimento deve ser realizado.
o Título do chamado: Sintetiza a descrição do incidente;
o Descrição: Contém uma descrição em maior detalhe do incidente, que deve permitir
a correta avaliação do tipo de atendimento que deve ser feito e a severidade com a
qual o atendimento deve ser tratado;
o Tipo: Identifica o fluxo de atendimento que será utilizado para o tratamento do
incidente. Existem dois tipos de chamado:
o Solicitação de Serviço: É uma requisição do usuário para que um serviço seja
realizado, resultando em atividades novas ou adicionais à operação padrão;
o Relato de Falha: Relata um evento que não é parte da operação padrão de um
produto ou serviço de TI que causa, ou que pode causar uma interrupção ou redução
na qualidade daquele serviço;
44
o Categorias 1º, 2º e 3º nível: Associa o incidente a um produto ou serviço de TI. Nos
casos de relato de falha onde o incidente é encaminhado para um grupo mais
especializado, pode ser necessária a reclassificação do incidente durante as
atividades de diagnóstico e solução de problema;
o Severidade: Define o quão expresso deve ser o atendimento ao chamado aberto,
formando uma relação entre o serviço realizado versus o acordo de prazo para aquele
serviço (SLA). Este é um dos campos mais importantes na abertura de um chamado
porque afeta os indicadores de qualidade de atendimento e os prazos de atendimento
informados ao usuário.
Em momento algum durante a coleta de informações sobre o incidente, o atendente deverá
prestar suporte ou iniciar o atendimento ao usuário.
Com o fim do preenchimento do formulário de registro de incidente, o chamado deve ser
salvo utilizando o botão “Confirmar”. Com a descrição do chamado completa, o passo seguinte é
uma tomada de decisão de fluxo de atendimento baseado no fato do chamado ser uma requisição,
ou não.
Este caso de uso contempla os requisitos funcionais: 02, 06, 08, 13 e 20; e as regras de
negócio: 07, 08, 09, 14 e 15.
Iniciar Atendimento
Os registros de atividade necessitam que o atendimento ao incidente já tenha sido iniciado.
O atendente pode efetivar esta situação com um “clique” no botão “Iniciar atendimento”. É
importante notar que:
1. O início do atendimento deve ser feito apenas quando o atendente estiver disponível e
possa, efetivamente, começar a realizar atividades associadas ao incidente;
2. O início do atendimento está associado ao incidente, e não ao registro da atividade. É,
portanto, um momento único no ciclo de vida de um incidente;
O indicador de tempo de resposta (TR) é calculado na diferença entre o momento do início
do atendimento e o registro do incidente (e.g., criação do chamado).
45
Este caso de uso contempla os requisitos funcionais: 07, 11 e 12; e as regras de negócio: 09,
17, 18, 19 e 22.
Registrar Atividade
O registro de atividade é uma ação realizada por membros do Help Desk ou de um atendente
de nível “n”. A informação registrada sobre a atividade deve ser sucinta, porém clara o suficiente
para permitir o rastreamento do incidente desde sua causa original até a solução provida no
fechamento do chamado.
O registro de atividade é também uma fonte de informação para o usuário que registrou o
incidente. A composição do histórico de registros de um incidente deve produzir um relato
completo do ocorrido, sem a necessidade de coleta externa de dados de apoio. Este relatório é
evidência para auditorias, e deve ser compreensível mesmo após uma leitura futura ao fechamento
do chamado.
Com o atendimento iniciado, é necessário preencher os campos do formulário de registro de
atividade, na seguinte ordem recomendada:
1. Equipe: Identifica a equipe associada ao atendente definido pelo campo Responsável.
2. Responsável: Registra o nome do atendente realizando o registro da atividade. Vem com
valor inicial já ajustado ao nome do atendente, e deve ser utilizado apenas na situação de
encaminhamento de chamado. Em outras palavras, para registro de uma atividade não é
necessário ser preenchido.
o Descrição: Relata detalhadamente a atividade que foi realizada. Deve permitir a
completa interpretação do que foi executado no contexto das outras atividades
realizadas e do atendimento ao usuário solicitante. Também serve como informação
para auditorias futuras;
o Data inicial e data final: É uma estimativa de quando a atividade foi iniciada, e
terminada. Sugere-se que sejam utilizados múltiplos de 10 minutos no
preenchimento deste campo;
o Duração: Este campo é calculado automaticamente após o preenchimento das datas
inicial e final, desta forma não requerendo preenchimento. Contudo, quando
46
múltiplas atividades são executadas ao mesmo tempo, este campo deve ser corrigido
com o rateio do tempo por proporção do esforço em cada atividade;
o Tipo de acompanhamento: Identifica o tipo de atividade realizada no chamado,
categorizando a forma de intervenção ao incidente. Existem tipos diferentes de
acompanhamento:
� Atendimento por Telefone: Aplica-se nas situações em que o contato com o
usuário é realizado por telefone. Os atendimentos por telefone não são
exclusivos de atendentes de Help Desk, podendo ser utilizados por todos os
diferentes níveis de suporte;
� Atendimento Remoto: Aplica-se nas situações em que o suporte utiliza uma
ferramenta sem a necessidade de contato presencial. Atendimentos por
telefone que utilizam uma ferramenta de atendimento remoto devem ser
classificados como atendimento remoto;
� Atendimento no Local: É utilizado por técnicos que necessitam se deslocar
ao local para realizar o atendimento.
o Registro: Aplica-se às situações em que não existe contato com o usuário solicitante,
como atividades internas e serviços em bancadas, a citar.
Existem atividades especiais que implicam em alterações no estado do chamado. São elas:
encaminhar chamado; fechar e reabrir chamados; suspender e reativar chamados; prorrogar
chamado; cancelar chamado; abrir sub-chamado; e alterar categoria.
Este caso de uso contempla o requisito funcional: 03; e as regras de negócio: 09, 10 e 11.
Encaminhar chamado
Encaminhar um chamado significa transferir a responsabilidade de atendimento ao incidente
para outro técnico.
O encaminhamento de um chamado é feito por meio da alteração do campo Responsável
para o novo atendente. O campo Descrição deve obrigatoriamente estar preenchido antes do
encaminhamento.
47
Em situações em que a severidade do incidente é crítica ou alta, é imperativo o contato
prévio com o técnico que receberá o chamado. Neste caso, o campo descrição deve sinalizar que
ocorreu um contato prévio.
Quando é de conhecimento do técnico que seu papel no atendimento ao incidente ainda não
se encerrou, porém este necessita de uma intervenção ou ajuda de outro técnico, deve-se utilizar a
opção de abertura de sub-chamado em contraposição ao encaminhamento (ver Abrir Sub-
Chamado).
Este caso de uso contempla o requisito funcional: 10.
Fechar e reabrir chamado
Fechar um chamado implica em declarar que o atendimento ao incidente se encerrou.
Nenhuma ação adicional ao tratamento daquele incidente deve ser realizada. É importante notar
que:
1. O usuário será alertado por e-mail de que o atendimento ao incidente se encerrou;
2. O indicador de tempo de solução (TS) é calculado na diferença entre o momento do
fechamento do chamado e o registro do incidente (e.g., criação do chamado).
3. O atendimento será considerado dentro do prazo, caso o tempo de solução (TS) esteja de
acordo com o nível de serviço (SLA) definido para aquela severidade;
O fechamento de um chamado é realizado no menu Ações | Fechar, ou com o botão Fechar.
Esta opção abre um formulário para preenchimento de detalhes sobre o fechamento do chamado, a
ser comunicado ao usuário.
Este caso de uso contempla o requisito funcional: 16; e as regras de negócio: 09, 23 e 24.
Prorrogar Chamado
Em situações em que a previsão de término do atendimento possui prazo inviável ou
expirado, o chamado obrigatoriamente deve ser prorrogado. É importante notar que:
1. O usuário será alertado por e-mail de que o atendimento ao incidente foi prorrogado,
incluindo o motivo que o levou à prorrogação;
48
2. Para os chamados com severidade crítica ou alta, o usuário deverá ser contatado por
telefone para negociar o novo prazo. Neste caso, um registro de atendimento telefônico
também deve ser obrigatoriamente incluído;
3. O tempo de solução (TS) não é afetado para chamados prorrogados. Em outras palavras,
o chamado será contabilizado como atendido fora do prazo nos indicadores de
desempenho.
A prorrogação de um chamado é feita por meio do botão prorrogar no detalhamento do
chamado. A aplicação ignora as informações do campo Descrição.
Os motivos para prorrogação de um chamado são:
• Atrasos na pauta de trabalho: ocorrem em situações internas associadas aos grupos de
trabalho de tecnologia da informação, motivada por momentos de excesso de carga de
trabalho, exceções ao fluxo padrão de atendimento (e.g., acidentes de trabalho), dentre
outros;
• Atrasos de setor: em razão de atrasos de outro setor, a prorrogação necessita ser aplicada
para atualizar o prazo de término do atendimento. Esta prorrogação possivelmente é
registrada em seqüência a uma suspensão;
• Atrasos de fornecedor: em razão de atrasos de fornecedor, a prorrogação necessita ser
aplicada para atualizar o prazo de término do atendimento. Esta prorrogação
possivelmente é registrada em seqüência a uma suspensão.
Outras informações sobre o motivo da prorrogação, ou negociação de prazo, podem ser
incluídas por meio de registro de atividade depois do chamado prorrogado.
Caso o usuário solicitante apresente reclamação de que o chamado, de fato, não tratou o
incidente corretamente, este chamado deve ser reaberto para que novas atividades sejam incluídas
no tratamento do incidente.
A reabertura de um chamado é realizada na escolha da opção Re-abrir no detalhamento do
chamado, estando apenas disponível aos chamados fechados. Um chamado reaberto retorna ao
estado “Aguardando atendimento”, e, portanto necessita ter seu atendimento reiniciado por meio do
botão Iniciar atendimento.
49
Existem situações para alguns chamados do tipo solicitação de serviço que implicam no
registro de um pedido de mudança (RFC) que será atendido por outros meios, que não os utilizados
pelo tratamento de incidentes. São exemplos:
• Melhorias em um sistema de informação, onde um pedido entra na fila de requisitos a
serem atendidos em versão futura;
• Troca de computador, que não tem previsão de atendimento imediato, mas que depende
de remanejamento futuro.
Nestes casos, o incidente é encerrado comunicando o usuário a forma alternativa de
acompanhamento da situação do seu pedido, sabendo que não receberá atendimento no curto prazo,
ou com prazo determinado.
Este caso de uso contempla o requisito funcional: 15.
Cancelar chamado
O cancelamento de um chamado é necessário em situações de registro indevido de um
incidente. Exemplos destas situações são:
• Chamado duplicado;
• Solicitações de serviços não contemplados na lista de serviços de Tecnologia da
Informação (e.g., conserto de lâmpada, etc.);
• Incapacidade de localização do usuário solicitante e/ou impossibilidade de determinação
da ação a ser realizada;
• Desistência de uma solicitação de serviço, cujo atendimento ainda não foi iniciado.
É importante notar que:
• Um atendente pode cancelar um chamado mesmo antes do início de seu atendimento;
• Atividades realizadas para chamados duplicados devem ser registradas no chamado
original, com a respectiva contabilização do tempo utilizado para atender e identificar a
situação de chamado em duplicidade;
50
A ação de cancelar chamado é acionada no botão Cancelar no detalhamento do chamado.
Uma caixa de diálogo surgirá para confirmar a operação de cancelamento. O campo Descrição deve
obrigatoriamente estar preenchido antes do cancelamento do chamado, contemplando com detalhes
a situação que caracteriza os motivos de cancelamento.
Este caso de uso contempla o requisito funcional: 02; e a regra de negócio: 09.
Abrir sub-chamado
A abertura de sub-chamados é utilizada para o registro de múltiplas atividades no
atendimento a um incidente. Esta forma de controle permite a realização de atividades em paralelo
ou de atividades interdependentes. Exemplos destas situações são:
• Distribuição de tarefas entre equipes especializadas, que necessitam se coordenar para
atingir um resultado comum;
• Dependência entre dois técnicos, tal que um técnico apenas poderá dar prosseguimento
ao atendimento após a realização de uma tarefa por outro colega do setor.
É importante notar que a abertura de sub-chamados permite o registro de atividades que
ocorrem em categorias de produto/serviço diferentes.
A abertura de sub-chamado estabelece uma relação pai-filho, tal que o chamado pai só
poderá ser fechado após o fechamento de todos os chamados filhos.
A ação de abrir sub-chamado é acionada na listagem de sub-chamados no detalhamento de
um chamado.
Este caso de uso contempla o requisito funcional: 14.
Informa estágio para cliente
O cliente deve ser informado a cada mudança de estágio de seu chamado, inclusive na
finalização para que o mesmo possa avaliá-lo. Para isto o sistema deverá enviar e-mail para o
cliente com informações básicas do chamado.
Neste e-mail deverá conter um link para que o cliente possa acessar o histórico do chamado.
51
Este caso de uso contempla o requisito funcional: 19; e as regras de negócio: 09 e 16; e
deverá ser executado após a execução dos casos de uso: 0Registrar/categorizar chamado, Registrar
Atividade, Fechar e reabrir chamado e Cancelar chamado.
Avaliar atendimento
Após o término de atendimento de um chamado o cliente poderá avaliar o atendimento
através de um link enviado por e-mail. Estas avaliações poderão servir como métricas de
desempenho da equipe de atendimento.
Este caso de uso contempla o requisito funcional: 19; e as regras de negócio: 09 e 16.
Cadastro de usuário
Para que os atendentes de primeiro nível, atendentes de nível “n”, clientes e outros
supervisores de Help Desk tenham acesso à aplicação, eles devem possuir um cadastro no sistema.
Este caso de uso contempla o requisito funcional: 01; e as regras de negócio: 01, 02, 03, 04,
05 e 06.
Cadastro de tipos de atividades
Os tipos de atividades serão considerados como cadastro do tipo basilar (i.e., que serve de
base para identificação das equipes de atendimento).
Este caso de uso contempla o requisito funcional: 04.
Cadastro de ativos de TI
O cadastro de ativos de TI servirá para criar uma base de ativos de TI, melhorando o seu
controle e gerência.
Este caso de uso contempla o requisito funcional: 09; e a regra de negócio: 20.
Cadastro de SLA
As SLA’s serão utilizadas para controlar o nível e a qualidade dos serviço prestado pela TI.
Através delas que o tempo de atendimento e o tempo de solução máximos são definidos.
Este caso de uso contempla o requisito funcional: 18; e as regras de negócio: 21, 27, 28 e 29.
52
3.4 DIAGRAMA DE CLASSES
Um diagrama de classes lista todos os conceitos do domínio que são implementados na
aplicação. Ele define e representa a estrutura do sistema. Para a definição das regras da aplicação,
foi modelado o diagrama de classes retratado na figura 13:
Figura 13. Diagrama de classes da aplicação
53
Este diagrama detalha as 27 classes empregadas na aplicação. O diagrama foi modelado de
acordo com os requisitos e regras de negócios abordados nas seções anteriores.
Para atender a estes requisitos, todas as principais classes (usuário, equipe, sub_equipe,
tipo_atividade, ativo, ativo_cat, ativo_sub_cat, ativo_sla, sla, e tipo atividade) necessárias para
contemplar os casos de uso, possuem os métodos novo(), cadastrar(), detalhe(), alterar(),
executar_alteracao(), excluir() e procurar().
Estes métodos são utilizados para fins de cadastro, detalhamento e listagem de seus
atributos.
Especificamente para fim de cadastro, são utilizados os seguintes métodos:
• novo(): apresenta um formulário HTML para a inserção de dados;
• cadastrar(): realiza a validação dos dados inseridos, e os grava no banco de dados.
No detalhamento dos atributos armazenados no banco de dados, são processados os métodos
descritos abaixo:
• detalhe(): busca e apresenta os atributos em forma de tabelas HTML;
• alterar(): mostra os atributos da classe em forma de um formulário HTML, onde os
mesmos podem ser modificados para alteração;
• executar_alteracao(): realiza a validação dos dados inseridos, e os altera no banco de
dados;
• excluir(): remove os dados do banco de dados.
Para a listagem das informações já cadastradas, é executado o método procurar(), que realiza
uma busca no banco de dados e apresenta as informações recuperadas para o usuário da aplicação.
54
A classe chamado, que tem papel principal no sistema, além dos métodos supracitados,
apresenta ainda os métodos abrir(), iniciar_atendimento(), historico(), fechados(),
selecionar_usuario(), encaminhar(), avaliar() e associar_atividade().
Estes métodos têm as seguintes funcionalidades:
• abrir(): apresenta um formulário HTML para a inserção de dados (semelhante ao
método novo() das outras classes);
• iniciar_atendimento(): realiza todas funções relacionadas ao atendimento,
contemplando todo o ciclo de vida do chamado;
• historico(): apresenta o histórico do chamado em tabelas HTML;
• fechados(): busca e apresenta os chamados com status concluído e cancelado, para
possível reabertura e posterior atendimento;
• encaminhar(): encaminha o chamado de um atendente para outro atendente do setor;
• avaliar(): possibilita ao usuário a avaliação do atendimento de um chamado;
• associar_atividade(): inicia atividades relacionadas ao atendimento de um chamado.
O restante das classes não apresenta métodos, e estão associadas às classes principais por
compartilhar seus atributos entre si.
3.5 DIAGRAMA DE BANCO DE DADOS
O diagrama de banco de dados detalha a maneira que o banco foi modelado, as entidades
envolvidas e os seus relacionamentos.
Para esta aplicação, chegou-se ao mostrado na figura 14:
55
Figura 14. Diagrama do banco de dados
Este diagrama apresenta 27 entidades, seus atributos e relacionamentos, que são
responsáveis por armazenar todas as informações utilizadas pela aplicação.
Estas entidades são: anotacoes, atendente, atividades_chamado, ativo_sla, ativos1, ativos2,
ativos3, ativos_atendente, avaliacoes, chamado, chamado_cancelado, chamado_encaminhado,
chamado_pendente, clientes_atendente, empresas, equipes, setores_empresa, severidades_sla, sla,
status, sub_chamado, sub_equipe, tipos_atividade, tipos_incidente, tipos_usuario, tratamentos e
usuário.
3.6 CODIFICAÇÃO DA APLICAÇÃO
A etapa de codificação da aplicação foi dividida em duas partes: criação da base de dados e
programação dos casos de uso.
56
3.6.1 Criação da base de dados
A base de dados da aplicação foi criada de acordo com o diagrama apresentado na seção
anterior. Para ilustrar esta criação, é mostrado na figura 15 o exemplo da criação da tabela
“chamado” em linguagem SQL:
Figura 15. Script de criação da tabela chamado
Neste exemplo, a linha 1 mostrada na figura corresponde a um comentário, e é descartada
pelo SGBD. Na linha dois, é iniciada a criação da tabela, com a declaração “create table”. Em
seguida, no intervalo de linhas 3 até 18 são especificados os atributos da tabela.
Estes atributos podem ser verificados através do comando “desc” do SGBD. A saída deste
comando é representada através da figura 16:
57
Figura 16. Descrição da tabela “chamado” fornecida pelo SGBD
Verificados todos os atributos da tabela, ela pode começar a ser utilizada.
Durante a concepção da base de dados da aplicação, este processo foi realizado para a
criação de cada uma das 27 tabelas que compõe a base de dados, a fim de evitar possíveis erros
futuros da aplicação.
3.6.2 Criação dos scripts PHP
Com base no projeto da aplicação e no banco de dados criado, iniciou-se a fase de criação
dos scripts PHP que compõem a aplicação.
A programação de todas as classes que possuem seus métodos definidos no diagrama de
classes foi realizada de maneira que seus códigos pudessem ser reutilizados com apenas pequenas
alterações. Nesta programação optou-se pela sua codificação dividindo-os em três arquivos, sendo
as classes separadas por meio de diretórios. Estes arquivos são:
• cad.php: Possui os métodos novo() e cadastrar();
58
• det.php: É composto pelos métodos detalhe(), alterar(), executar_alteracao() e
excluir();
• lst.php: Método procurar().
A classe “chamado” ainda possui os seguintes arquivos:
• associa_atividade.php: Formado pelo método associar_atividade();
• avaliar.php: Método avaliar();
• encaminha.php: Método encaminhar();
• usuario_sel.php: Método selecionar_usuario().
Ainda na classe chamado, o arquivo cad.php possui os métodos iniciar_atendimento(),
historico() e fechados().
Como exemplo do arquivo cad.php, a figura 17 mostra um trecho do código do método
cadastrar() da classe tipo_atividade:
Figura 17. Trecho do método cadastrar()
59
Na linha 40 da imagem acima, a variável recebe a SQL, que é executada na linha 41. O
intervalo de lindas 41 à 51 mostram que caso seja realizada a SQL com sucesso, o usuário será
redirecionado para o script det.php da classe, ou caso contrário, receberá uma mensagem de erro.
O exemplo de um arquivo det.php é mostrado na figura 18, referente ao método
executar_alteracao() da classe usuario:
Figura 18. Trecho do método executar_alteracao()
A linha 388 deste script verifica se o usuário que está sofrendo a alteração é um atendente.
Caso positivo, ele atualiza o atributo vip da classe, e posteriormente recupera do banco de dados o
atributo cod_atendente da classe atendente.
No caso de um arquivo lst.php, apresenta-se a figura 19 como exemplo do método
procurar() da classe tipo_atividade:
Figura 19. Trecho do método procurar()
Este trecho do script realiza uma busca no banco de dados referente aos tipos de atividade
cadastrados, e para cada tipo de atividade encontrado, ele alimenta a variável “dados”.
60
Durante a construção da aplicação, notou-se que as descrições dos casos de uso não eram
condizentes com a realidade da área de atendimento de clientes. Em alguns casos, a aplicação foi
adaptada para uma melhor praticidade em seu uso no dia-a-dia deste setor. Como estas mudanças
não exerceram um impacto muito grande no projeto, o mesmo não foi modificado por não ter
perdido a sua essência.
Estes tipos de mudança são normais, e são suportadas pelo ITIL, uma vez que o ITIL apenas
fornece as melhores práticas, e até mesmo sugere que mudanças sejam realizadas para adaptar as
melhores práticas ao setor já existente, sem causar grandes impactos no funcionamento do setor.
Com a fase de codificação realizada, passou-se então para a etapa de testes e validação das
use-cases.
3.7 TESTES E RESULTADOS
Para a validação da aplicação, após a etapa de codificação, um teste geral foi realizado para
garantir que em nenhuma circunstância a aplicação apresentasse problemas. Dois cenários foram
utilizados para a realização destes testes:
• Cenário 1: Utilizando-se da visão do usuário que abre e avalia chamados; e
• Cenário 2: Visão do atendente, contemplando todas as funções restantes da
aplicação.
3.7.1 Cenário 1
No primeiro cenário, não foram encontrados erros, uma vez que durante a etapa de
codificação, a cada novo método codificado, vários testes eram realizados para garantir a eficácia
do mesmo.
3.7.1.1 Caso de uso 11: Avaliar atendimento
O foco deste teste foi a validação do caso de uso 11, que se refere à avaliação de um
chamado por parte do usuário solicitante.
Após o usuário autenticar-se no sistema e escolher o chamado desejado, ele é levado para a
página mostrada na figura 20:
61
Figura 20. Validação do caso de uso 11: Avaliar atendimento
Selecionada a opção de avaliação desejada, a aplicação realiza o método avaliar(), que insere
a informação sobre a avaliação do chamado na base de dados. Uma vez que a avaliação de um
chamado tem como pré-requisito a abertura e conclusão do mesmo, e os métodos testados foram
bem sucedidos, considerou-se então o caso de uso 11 como válido.
3.7.2 Cenário 2
O segundo cenário, mais extenso e complexo, resultou em alguns erros da aplicação. Estes
erros foram corrigidos e testados novamente. Os novos resultados estão detalhados nas seções
abaixo:
3.7.2.1 Caso de uso 1: Registrar chamado:
O foco deste teste consiste no registro de um chamado por parte de um atendente, que
solicita as informações sobre o incidente ao usuário e as cadastra na base de dados do sistema. O
resultado do teste está ilustrado pela figura 21:
Figura 21. Validação do caso de uso 1: Registrar chamado
62
Uma vez cadastrado, o chamado já pode ser categorizado.
3.7.2.2 Caso de uso 2: Registrar/categorizar chamado
O foco deste teste é o caso de uso 2, onde o atendente categoriza o chamado recém aberto.
Esta categorização é realizada através dos campos “Severidade do incidente, Tipo do
incidente e Classe do ativo”. Este teste está ilustrado pela figura 22:
Figura 22. Validação do caso de uso 2: Registrar/categorizar chamado
O chamado então é registrado, com suas novas informações sobre a sua categoria, e seu
fluxo de atendimento pode ser iniciado.
3.7.2.3 Caso de uso 3: Iniciar atendimento
O escopo deste teste é tornar possível a um atendente o início do atendimento ao usuário, e o
cálculo do tempo de resposta para o acompanhamento da SLA associada.
Com o chamado registrado e categorizado, o atendente então tem a possibilidade de iniciar o
atendimento. Isso pode ser realizado através do acionamento do botão iniciar atendimento, no
detalhe do chamado, que leva o atendente à tela mostrada na figura 23:
63
Figura 23. Validação do caso de uso 3: Iniciar atendimento
Confirmada a inserção dos dados, os mesmos são gravados na base de dados, e o atendente
pode iniciar o registro de atividades relacionadas ao chamado.
3.7.2.4 Caso de uso 4: Registrar atividade
O objetivo deste teste é a associação de uma atividade a um chamado que esteja em
atendimento.
A atividade pode se associada a partir do momento que o status “em atendimento” é gravado
na base de dados e o atendente é encaminhado para a tela de detalhamento do chamado. Nesta tela
existe um botão denominado “Iniciar atividade”, qual acionado, leva o atendente para a tela de
cadastro de atividades, mostrada na figura 24:
64
Figura 24. Validação do caso de uso 4: Registrar atividade
A atividade então é registrada e associada ao chamado em atendimento. A aplicação trata
automaticamente de associar a atividade ao atendente que a iniciou, e também as datas de início e
término da atividade, para possíveis consultas futuras.
3.7.2.5 Caso de uso 5: Encaminhar chamado
A função deste teste é garantir que um chamado encaminhado seja efetivamente transferido
para outro atendente do setor, previamente cadastrado no sistema.
Para encaminhar um chamado a outro atendente, na opção “Encaminhar chamado” do
sistema, a aplicação traz uma lista dos chamados abertos de responsabilidade do atendente em
questão. Depois de selecionado o chamado, a aplicação traz uma breve descrição do mesmo para
confirmação, e então mostra uma lista dos atendentes registrados, para que o chamado seja
efetivamente encaminhado. A figura 25 mostra esta tela da aplicação:
65
Figura 25. Validação do caso de uso 5: Encaminhar chamado
Uma vez encaminhado, o chamado passa a ser de responsabilidade do novo atendente, e um
registro dessa operação é gravado na base de dados.
3.7.2.6 Fechar e reabrir chamados
O escopo deste teste é realizar o fechamento de um chamado.
Após o atendimento de um chamado ser concluído, o mesmo deve ser fechado e suas
informações armazenadas na base de dados para futuras referências. Este chamado ainda pode ser
reaberto caso o mesmo problema persista. Na figura 26 é mostrada uma tela do sistema onde o
chamado é fechado, sua descrição é informada e seu tempo de solução é calculado:
Figura 26. Validação do caso de uso 6: Fechar e reabrir chamados
66
Com o fechamento do chamado, o seu ciclo de vida é terminado.
3.7.2.7 Caso de uso 7: Prorrogar chamado
O foco deste teste é realizar o prorrogamento de um chamado.
Um chamado que esteja aberto no sistema pode ser prorrogado. Para isso, basta que o
atendente selecione o chamado na aplicação, selecione o status “Pendente” e descreva o motivo
para este status. A figura 27 apresenta os detalhes de um chamado prorrogado (pendente):
Figura 27. Validação do caso de uso 7: Prorrogar chamado
O chamado ficará com o status “prorrogado” até que a sua pendência seja resolvida.
3.7.2.8 Caso de uso 8: Cancelar chamado
Este teste visa cancelar um chamado.
Um chamado pode ser cancelado, e um motivo deve ser fornecido para descrever o objetivo
desta operação. Para cancelar um chamado, após o mesmo estar aberto, ele deve ser marcado com o
status “Cancelado”, e então o atendente deve fornecer a descrição do motivo. A figura 28 ilustra
este caso de uso:
67
Figura 28. Validação do caso de uso 8: Cancelar chamado
Após realizada esta operação, a aplicação irá gravar os dados do chamado na base de dados
para futuras conferencias.
3.7.2.9 Caso de uso 9: Abrir sub-chamado
O objetivo deste teste é realizar a abertura de um sub-chamado referente a um chamado pai.
Para abrir um sub-chamado, o atendente deve ir à opção “Abrir sub-chamado” da aplicação
e escolher o código de seu chamado pai. Este procedimento é ilustrado pela figura 29:
68
Figura 29. Validação do caso de uso 9: Abrir sub-chamado
Selecionando o chamado mestre, o procedimento a ser seguido é o mesmo de abertura de um
chamado comum. Após o procedimento realizado, os dados são armazenados na base de dados.
3.7.2.10 Caso de uso 10: Informar estágio para cliente
O foco deste teste é verificar se o cliente recebe as informações necessárias referente aos
seus chamados.
O cliente deve ser informado de tudo o que estiver acontecendo em relação ao seu chamado.
A cada alteração de seu chamado, um e-mail é enviado para o cliente, atualizando-o sobre seu
status. Como exemplo deste teste, a figura 30 exibe o conteúdo do e-mail enviado para o cliente
informando-o sobre o início do atendimento de seu chamado:
69
Figura 30. Validação do caso de uso 10: Informar estágio para cliente
Quando o cliente for informado que seu chamado está concluído, ele terá a opção de avaliar
o atendimento de seu chamado.
3.7.2.11 Caso de uso 12: Cadastro de usuário
O foco deste teste é verificar o cadastro de um novo usuário.
O cadastro do usuário consiste na inserção de seus dados de acordo com os requisitos
contemplados com este caso de uso. A imagem figura 31 ilustra o teste de cadastro de um atendente
de segundo nível:
70
Figura 31. Validação do caso de uso 12: Cadastro de usuário
Enviando estes dados, será cadastrado um atendente na base de dados, com as informações
inseridas no formulário HTML.
3.7.2.12 Caso de uso 13: Cadastro de tipos de atividades
O objetivo deste teste é o cadastro de um tipo de atividade, que é usada em conjunto com a
associação de atividades relacionadas a um chamado.
O cadastro de atividades é simples, pois contempla apenas os atributos da classe
tipo_atividade. São eles: cod_tipo_atividade e nome_tipo_atividade. A imagem figura 32 demonstra
um tipo de atividade recém cadastrado:
Figura 32. Validação do caso de uso 13: Cadastro de tipos de atividades
71
Cadastrado o tipo de atividade, ela poderá então ser utilizada para associação de atividades
de um chamado.
3.7.2.13 Caso de uso 14: Cadastro de ativo de TI
Este teste contempla o cadastro de um ativo de TI, que compõe a base de ativos da
aplicação.
Um ativo cadastrado poderá ser utilizado para a definição de uma SLA utilizada na
aplicação. A imagem figura 33 apresenta um ativo recém cadastrado:
Figura 33. Validação do caso de uso 14: Cadastro de ativo de TI
Ainda contemplam este caso de uso, o cadastro de categorias e sub-categorias de ativos de
TI. Na figura 33 usada para ilustrar este teste, como categoria de ativo está sendo mostrada a opção
“Hardware”, previamente cadastrada, assim como a sub-categoria “Desktop”, também recém
cadastrada.
3.7.2.14 Caso de uso 15: Cadastro de SLA
O foco deste teste é o cadastro de uma SLA.
Estas SLAs são utilizadas pela aplicação para o controle de tempo do atendimento de um
chamado. Nesta imagem figura 34 é mostrado o formulário de cadastro de uma SLA, onde os dados
serão cadastrados na base de dados.
72
Figura 34. Validação do caso de uso 15: Cadastro de SLA
Após a inserção destes dados na base de dados da aplicação, eles estarão prontos para a sua
utilização. Todos os testes apresentados nessa seção foram bem sucedidos. Isso mostra que todos os
casos de usos projetados para esta aplicação estão contemplados na codificação do sistema. E isto
posto, considera-se então esta aplicação validada.
3.8 DOCUMENTAÇÃO DA APLICAÇÃO
A aplicação construída neste projeto de TCC foi concebida de maneira que torne o seu uso
extremamente simples. Isto porque ela foi baseada em cadastro, listagem e detalhamento de
informações, tornando-a muito intuitiva.
Para a sua documentação foi criado um manual de uso, em anexo a este documento, com
foco no usuário do Service Desk, que abre chamados, avalia o atendimento prestado e confere o
histórico de seus chamados.
Para os analistas de suporte do setor de Help Desk, denominados nesta aplicação como
“atendentes”, pressupõe-se que os mesmos já possuam o conhecimento suficiente para o seu uso, e
como documentação, sugere-se os livros e artigos citados na seção de referências bibliográficas,
assim como este presente documento.
4 CONCLUSÕES
A abordagem deste trabalho de conclusão de concurso, em sua etapa inicial (i.e., TCC I),
constituiu essencialmente a caracterização de um tema de trabalho, no caso o gerenciamento de
incidentes de TI baseado no ITIL, e a análise, especificação e desenvolvimento de um sistema como
prova de conceito e contextualização dos estudos no âmbito de um Curso de Ciência da
Computação.
O levantamento bibliográfico sobre as temáticas do ITIL e das tecnologias web no Capítulo
2 permitiu a extração dos requisitos funcionais e não-funcionais, bem como a especificação dos
principais casos de uso da aplicação proposta. Estes artefatos foram objetos essenciais ao
desenvolvimento das atividades de construção e teste da solução em sua etapa final (i.e., TCC II).
Quanto aos objetivos específicos apresentados na Seção 1.2.2 , evidenciam-se as atividades
realizadas por meio dos Capítulos 2 e 3 deste trabalho.
A Seção 2.1 abordou o levantamento bibliográfico suficiente para compreender as questões
envolvidas no suporte aos serviços de tecnologia da informação, contextualizando o ITIL e a sua
relevância como framework nas organizações mundiais.
Em particular, as Seções 2.1.3 e 2.1.4 documentaram o estudo do modelo de Suporte a
Serviço do ITIL em sua totalidade, com delimitação de escopo para a aplicação proposta.
A Seção 2.2 estabelece o conjunto de tecnologias e linguagens de desenvolvimento de
aplicações web como ferramental para a construção da aplicação.
O Capítulo 3 apresentou o desenvolvimento da solução proposta, incluindo um modelo
conceitual, utilizando como referência a linguagem UML, de forma a relacionar os Casos de Uso,
entidades e comportamento da aplicação. Diagramas de classe e de banco de dados são
apresentados como referência para a sua codificação.
A Seção 3.6 então aborda a codificação da Solução proposta, detalhando com exemplos de
código a estrutura do sistema desenvolvido.
Finalmente, a Seção 3.7 detalhou os testes e resultados obtidos com a aplicação,
contemplando testes específicos para cada caso de uso descrito por este projeto e em observância ao
74
escopo de gerenciamento de incidentes do ITIL previamente definido, validando seus objetivos
alcançados.
Estes resultados constituem implementação suficiente para alçar as atividades previstas para
este trabalho de conclusão de curso, que construiu os programas da aplicação, os testou e validou.
Como trabalhos futuros, é sugerido o desenvolvimento de novas aplicações que abranjam os
outros elementos do suporte a serviços do ITIL. Tais aplicações poderiam contemplar os processos
de gerenciamento de problemas, gerenciamento de configuração, gerenciamento de mudanças e o
gerenciamento de liberação. Contudo, um tema ainda mais diretamente ligado a este trabalho
poderia ser o aprimoramento de sua usabilidade, com o desenvolvimento de melhorias e facilidades
em sua interface.
REFERÊNCIAS BIBLIOGRÁFICAS
3RD ED. COBIT STEERING COMMITTEE AND THE IT GOVERNACE INSTITUTE. COBIT Executive Summary. Estados Unidos, 2000. Disponível em <http://www.isaca.org/cobit.htm>. Acesso em: 07 de julho de 2005.
ALBRIGHT, P. et al. Implementing service and support management processes: a practical guide. Van Haren Publishing: Zeewolde, 2005. ISBN 90-77212-43-4.
AMBOUJ GOYAL. General Manager Lótus. In:IBM on demand. 2003, São Paulo.
APPARAO, V. et al. DOM Level 1 Specification. Estados Unidos, 1998. Disponível em: <http://www.w3.org/TR/REC-DOM-Level-1>. Acesso em 10 de janeiro de 2006.
BAKKEN, Stig Sæther et. al. Manual do PHP. Estados Unidos, 2004. Disponível em <http://www.php.net/manual/pt_BR/>. Acesso em: 29 de março de 2006.
BARON, Anthony. et al. Application Management: ITIL – The key to Managing IT Services. The Stationary Office for OGC. Noruega, 2000. CD-ROM. ISBN 0113308663.
BARROS, Aidil Jesus da Silveira; LEHFELD, Neide Aparecida de Souza. Fundamentos de Metodologia Científica. São Paulo: Makron Books, 2000.
BARTLETT, John. et al. Service Delivery: ITIL – The key to Managing IT Services. The Stationary Office for OGC. Noruega, 2000. CD-ROM. ISBN 0113300174.
BERKHOUT, Michiel. et al. Service Support: ITIL – The key to Managing IT Services. The Stationary Office for OGC. Noruega, 2000. CD-ROM. ISBN 0113300158.
BRUNISE E CAMANHO & CONSULTORES. COBIT, ITIL e Gestão de TI. In: V Command Center Meeting. São Paulo, 2006.
BSI GROUP. The TickIT Guide. Estados Unidos, 2005. Disponível em <http://www.tickit.org/overview.pdf>. Acesso em 02 de novembro de 2005.
BUNGE, Mário. Teoria e realidade. São Paulo: Perspectiva, 1974.
CABRAL, R. B.; THIVES JR, Juarez Jonas. Do núcleo de informática à tecnologia da informação: a governança de TI em um estudo de caso. In: XVI Encontro Nacional dos Cursos de Graduação em Administração. Belo Horizonte, 2005.
COMMITTEE OF SPONSORING ORGANIZATIONS OF THE TREADWAY COMMISSION. Enterprise Risk Management — Integrated Framework. Estados Unidos, 2004. Disponível em: <http://www.coso.org/publications.htm>. Acesso em: 24 de outubro de 2005.
GALLIERS, R. e SUTHERLAND, A. Information systems management and strategy formulation: the ´stages of growth´ model revisited. Journal of Information Systems, Vol. 1, nº 2, pp. 89-94, 1991.
76
GRAHAM, Paul et al. ICT Infrastructure Management: ITIL – The key to Managing IT Services. The Stationary Office for OGC. Noruega, 2000. CD-ROM. ISBN 0113308655.
IBM CORPORATION. Optimizing IT: Building a foundation for On Demand Business. Estados Unidos, 2005. Disponível em <http://www.itpapers.com/abstract.aspx?scid=1119&docid=148816>. Acesso em 20 de outubro de 2005.
INTERNATIONAL ORGANIZATION FOR STANDARDIZATION. ISO/IEC 15408:1999 Information technology — Security techniques — Evaluation criteria for IT security. Estados Unidos, 1999. Disponível em: < http://www.iso.org/iso/en/CatalogueDetailPage.CatalogueDetail?CSNUMBER=40612&ICS1=35&ICS2=40&ICS3=>. Acesso em 20 de outubro de 2005.
______. ISO/IEC 17799:2005 Information technology - Security techniques - Code of practice for information security management. Estados Unidos, 2004. Disponível em: <http://www.iso.org/iso/en/prods-services/popstds/informationsecurity.html>. Acesso em 20 de outubro de 2005.
IT GOVERNACE INSTITUTE. COBIT Mapping. Estados Unidos, 2004. Disponível em <http://www.isaca.org/cobit.htm>. Acesso em: 07 de julho de 2005.
KEMPNICH, J. Information Security Standards: The Australian Business Perspective. Austrália, 2005. Disponível em <www.ewa-australia.com/whitepapers/standards-whitepaper.pdf>. Acesso em: 22 de abril de 2006.
LIE, H. W. BOS, Bert. CSS Level 1 Specification. Estados Unidos, 1999. Disponível em: <http://www.w3.org/TR/1999/REC-CSS1-19990111>. Acesso em: 22 de abril de 2006.
McFARLAN, F. e McKENNEY, J. The information archipelago - maps and bridges. Harvard Business Review, Vol. 60, nº 5, pp. 109-119, 1982.
McFARLAN, F., McKENNEY, J. e PYBURN, P. The information archipelago - plotting a course. Harvard Business Review, Vol. 61, nº 1, pp. 145-156, 1983.
MUTSAERS, Ernest-Jan; ZEE, Han van der; GIERTZ, Henrik. The Evolution of Information Technology. Information Management and Computer Security. Vol. 6, No. 3, pp. 115-126, 1998. ISSN 0968-5227.
MYSQL AB. MySQL Reference Manual. Estados Unidos, 2006. Disponível em: <http://downloads.mysql.com/docs/refman-5.1-en.a4.pdf>. Acesso em: 22 de abril de 2006.
NETSCAPE COMMUNICATIONS CORPORATION. JavaScript Resources. Estados Unidos, 1999. Disponível em: <http://devedge.netscape.com/central/javascript/>. Acesso em: 10 de janeiro de 2006.
NETWORK WORKING GROUP. HTTP 1.1 Specification. Estados Unidos, 1999. Disponível em: <http://www.w3.org/Protocols/>. Acesso em: 10 de janeiro de 2006.
NOLAN, R. Managing the computer resource: a stage hypothesis. Communications of the ACM, Vol. 16, nº 7, pp. 399-405, 1973.
77
NOLAN, R. Managing the crisis in data processing. Harvard Business Review, Vol. 57, nº 2, pp. 115-126, 1979.
OFFICE OF GOVERNMENT COMMERCE. Business Perspective: the IS view on delivering services to the business. Londres: Stationary Office, 2004. CD-ROM. ISBN 0113308949.
PROJECT MANAGEMENT INSTITUTE, BRAZIL MINAS GERAIS CHAPTER. Tradução Livre do PMBOK 2000. Brasil, 2002. Disponível em: <http://www.prodepa.psi.br/sqp/pdf/Cap%C3%ADtulo%2003%20-%20Os%20Processos%20da%20Ger%C3%AAncia%20de%20Projetos.pdf>. Acesso em 20 de janeiro de 2006.
RAGGETT, D., Le HORS A., JACOBS, I. HTML 4.01 Specification. Estados Unidos, 1999. Disponível em: <http://www.w3.org/TR/1999/REC-html401-19991224>. Acesso em: 10 de janeiro de 2006.
ROCHA, Álvaro e VASCONCELOS, José. Os Modelos de Maturidade na Gestão de Sistemas de Informação. Revista da Faculdade de Ciência e Tecnologia da Universidade Fernando Pessoa, Nº. 1, Ano 2004, pp. 93-107. ISSN: 1646-0499.
ROCKART, J. F. et al. Reconceptualizing IT. Estados Unidos, 1999. Disponível em <http://web.mit.edu/cisr/working%20papers/cisrwp302.pdf>. Acesso em 25 de outubro de 2005.
SEVERINO, Antonio Joaquim. Metodologia do trabalho científico. São Paulo: Cortez, 2002. ISBN 85-249-0050-4.
TACHIZAWA, Takeshy; ANDRADE, Rui Otávio Bernardes. Tecnologias da Informação Aplicadas às Instituições de Ensino e às Universidades Corporativas. São Paulo: Atlas, 2003.
APÊNDICES
A SAGI - MANUAL DE UTILIZAÇÃO DO USUÁRIO
Para a documentação do sistema, este apêndice apresenta o manual de utilização do usuário
do Sistema de Apoio ao Gerenciamento de TI Baseado na recomendação ITIL.
A.1 INTRODUÇÃO
O presente manual tem como objetivo apresentar o Sistema de apoio ao gerenciamento de
incidentes de TI baseado na recomendação ITIL, também denominado como SAGI, e demonstrar de
forma fácil o seu meio de utilização.
Este documento descreve o SAGI, os procedimentos para seu uso e se destina aos usuários
de tecnologia que necessitam de suporte técnico da área de TI.
A.1.1 O SAGI
O SAGI (Sistema de Apoio ao Gerenciamento de Incidentes de TI Baseado na
Recomendação ITIL) é uma aplicação web que permite a abertura de chamados técnicos de TI. Ele
pode ser utilizado em situações que seja necessário o suporte técnico para solução de incidentes.
O uso do SAGI é simples, e requer apenas alguns poucos procedimentos para a requisição
de um chamado técnico de suporte.
Para um melhor acompanhamento de chamados, tanto ativos quanto concluídos, o sistema
fornece uma opção que apresenta de forma simples o histórico de um chamado, de suas atividades
relacionadas, e seu status.
O SAGI também provê uma interface onde se pode avaliar a qualidade do atendimento
prestado relativo a um chamado técnico concluído.
A.2 UTILIZAÇÃO DO SISTEMA
Para o uso do SAGI, é necessário estar cadastrado no sistema e possuir seu nome de usuário
e senha em mãos. Em caso de dúvidas, deve-se efetuar um contato com o setor de Help Desk.
Para acessar o sistema, deve-se efetuar o login, digitando seu nome de usuário e senha,
como apresentado na figura 35:
80
Figura 35. Tela de login do sistema
Após realizar este procedimento, serão mostrada uma tela de boas-vindas, e as opções do
sistema se tornarão disponíveis.
Deve-se notar que, para acessar qualquer função do sistema, se deve realizar o login, como
descrito no procedimento acima.
A.2.1 Abrir um chamado
O procedimento para a abertura de um chamado técnico é simples, e está descrito abaixo
passo a passo:
1. Escolher a primeira opção, “Abrir chamado”:
Figura 36. Opção “Abrir Chamado”
2. Na tela seguinte deverá ser informada uma descrição sucinta do incidente no campo
“Descrição do incidente”:
81
Figura 37. Descrição do incidente
3. Os campos “Severidade do incidente” e “Tipo do incidente” são utilizados pelos
atendentes para fins de classificação do chamado. Eles não são obrigatórios, e podem
ser deixados com as opções padrão.
4. Após inseridas as informações sobre o incidente, deve-se selecionar o botão
“Confirma alterações”, para que o chamado seja processado e enviado para os
analistas de suporte de plantão.
Figura 38. Tela de abertura de chamado
82
5. Caso exista mais um chamado a ser aberto, este procedimento pode ser realizado
novamente, voltando-se ao passo nº. 1.
A.2.2 Visualizar o histórico de um chamado
O histórico de um chamado pode ser visualizado a qualquer momento, para fins de
acompanhamento. O procedimento abaixo mostra como realizar esta operação.
1. Selecione a opção “Histórico de chamado”:
Figura 39. Opção “Histórico de chamado”
2. Em seguida será apresentada uma lista de todos os chamados cadastrados. Deve-se
então selecionar o chamado desejado para visualizar o seu histórico. Opcionalmente,
é possível procurar pelo chamado informando o seu identificador no campo
“Procurar Chamado”:
83
Figura 40. Lista de chamados para visualização de histórico
3. Caso seja necessário visualizar o histórico de outro chamado, deve-se repetir este
procedimento a partir do passo nº. 1.
A.2.3 Avaliar um chamado
Cada chamado concluído pode ser avaliado para fins de métricas de qualidade de
atendimento.
O procedimento para avaliar um chamado é descrito abaixo:
1. Selecionar a terceira opção, “Avaliar chamado”:
Figura 41. Opção “Avaliar chamado”
84
2. Uma lista dos chamados disponíveis para avaliação será mostrada conforme a figura
42 abaixo. Deve-se então selecionar o chamado desejado para sua avaliação.
Opcionalmente, é possível procurar pelo chamado informando o seu identificador no
campo “Procurar Chamado”:
Figura 42. Lista de chamados para avaliação
3. Será apresentado pelo sistema um breve detalhamento sobre o chamado selecionado,
para propósitos de simples conferência. Deve-se então selecionar o botão “Avaliar
chamado”.
Figura 43. Detalhes do chamado cadastrado para avaliação
85
4. Para a avaliação do chamado, uma lista de opções será fornecida, e uma destas
opções deverá ser selecionada de acordo com o nível de satisfação em relação ao
atendimento prestado.
Figura 44. Tela de avaliação de um chamado
5. Selecionada a opção desejada, deve-se então selecionar o botão “Avaliar”, que irá
gravar a avaliação do chamado no sistema.
Sempre que houver alguma dúvida em relação ao uso do sistema, deve-se entrar em contato
com o setor de Help Desk.
