universidade do vale do itajaÍ centro de …siaibib01.univali.br/pdf/felipe luiz pereira.pdf ·...
TRANSCRIPT
UNIVERSIDADE DO VALE DO ITAJAÍ CENTRO DE CIÊNCIAS TECNOLÓGICAS DA TERRA E DO MAR
CURSO DE CIÊNCIA DA COMPUTAÇÃO
CPITIL: UMA APLICAÇÃO DE APOIO AO GERENCIAMENTO DE PROBLEMAS BASEADO NA RECOMENDAÇÃO ITIL
Área de Sistemas de Informação
por
Felipe Luiz Pereira
Carlos Henrique Bughi, Bel. 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
CPITIL: UMA APLICAÇÃO DE APOIO AO GERENCIAMENTO DE PROBLEMAS BASEADO NA RECOMENDAÇÃO ITIL
Área de Sistemas de Informação
por
Felipe Luiz Pereira 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: Carlos Henrique Bughi, Bel.
Itajaí (SC), junho de 2007
AGRADECIMENTOS
Agradeço primeiramente a Deus por me dar a atitude de ser quem eu sou, e proporcionar o prazer de ter ao meu lado todos aqueles que fizeram e fazem parte desta caminhada que é a minha vida.
Aos meus pais, Fernando José Pereira e Márcia Marisa Pereira, que com amor e disciplina me fizeram a pessoa que sou, e me ensinaram os valores a serem seguidos e conquistados.
A minha irmã, Fernanda, que sempre esteve comigo em cada passo dado, e sempre me motivou a ser um batalhador, me tornando assim sua imagem semelhança.
Ao meu orientador, Carlos Henrique Bughi, pelo incentivo, cobranças, discordâncias, discussões, esclarecimentos, motivação, apoio para realização deste projeto e principalmente pela amizade.
Ao meu co-orientador, o orientador no primeiro momento, Rodrigo Cabral, por me mostrar o caminho a seguir e dar suporte até o final desta caminhada.
Ao grande amigo e professor, Rafael Medeiros Sperb, que com sua enorme estima, muitas vezes auxiliou no desenvolvimento deste e de outros projetos na minha carreira acadêmica e profissional.
Ao amigo Tadeu Eduardo Granemann, pelas aulas do curso denominado: Aprendendo Symfony em oito horas. Pelas contribuições com idéias e sugestões de desenvolvimento e principalmente pela insistente frase: “por que você não faz mais isso?”.
Ao LCA (Laboratório de Computação Aplicada), na figura dos amigos de trabalho, que se propuseram sempre a ajudar, e apoiar esta jornada.
Aos demais familiares (em especial meu cunhado, Ramon), que estão sempre dispostos a ajudar no que for preciso.
Aos amigos que contribuíram em alguma maneira para a realização deste trabalho, mesmo que a ajuda fosse: “não convidar para àquela festa, e deixá-lo em casa estudando”.
Por fim, todos os amigos, professores, avaliadores, que de alguma forma contribuíram com idéias, críticas e sugestões.
ii
SUMÁRIO
1 INTRODUÇÃO........................................................................................ 1
1.1 PROBLEMATIZAÇÃO ....................................................................................... 2
1.1.1 Formulação do problema .................................................................................. 2 1.1.2 Solução proposta ................................................................................................ 3 1.2 OBJETIVOS .......................................................................................................... 6 1.2.1 Objetivo geral ..................................................................................................... 6 1.2.2 Objetivos específicos .......................................................................................... 6 1.3 METODOLOGIA ................................................................................................. 7 1.4 ESTRUTURA DO TRABALHO ......................................................................... 8
2 FUNDAMENTAÇÃO TEÓRICA .......................................................... 9
2.1 GERENCIAMENTO DE SERVIÇOS DE TI .................................................... 9
2.1.1 Introdução ........................................................................................................... 9 2.1.2 Organizações e a tecnologia da informação ..................................................... 9
2.1.3 O gerenciamento de serviços de tecnologia da informação .......................... 10
2.1.4 IT Infrastructure Library: ITIL ............. ........................................................ 13 2.1.5 Service Desk ...................................................................................................... 17 2.1.6 Incidentes versus problemas ........................................................................... 18 2.1.7 Gerenciamento de problemas .......................................................................... 19 2.1.8 Análise das melhores práticas ......................................................................... 26 2.1.9 Escopo do trabalho ........................................................................................... 32 2.1.10 Considerações ................................................................................................. 35 2.2 GESTÃO DO CONHECIMENTO .................................................................... 36
2.2.1 Introdução ......................................................................................................... 36 2.2.2 Capital Intelectual ............................................................................................ 36 2.2.3 Conhecimento Organizacional ........................................................................ 37
2.2.4 Criação/Codificação do Conhecimento .......................................................... 38
2.2.5 TI e Gestão do Conhecimento ......................................................................... 39 2.2.6 Considerações ................................................................................................... 39 2.3 SISTEMAS WEB ................................................................................................ 40 2.3.1 Introdução ......................................................................................................... 40 2.3.2 Arquitetura de sistemas Web .......................................................................... 40 2.3.3 Programação em três camadas ....................................................................... 47
2.3.4 Considerações ................................................................................................... 49
3 PROJETO .............................................................................................. 50
3.1 REQUISITOS ...................................................................................................... 51 3.1.1 Funcionais ......................................................................................................... 51 3.1.2 Não-funcionais .................................................................................................. 53 3.2 REGRAS DE NEGÓCIO ................................................................................... 53
3.3 CASOS DE USO .................................................................................................. 55
iii
3.4 DIAGRAMA DE CLASSE ................................................................................. 59
4 DESENVOLVIMENTO ........................................................................ 60
4.1 MODELAGEM DE ENTIDADE E RELACIONAMENTO ........ .................. 60 4.2 CRIAÇÃO DA BASE DE DADOS .................................................................... 63
4.2.1 PgAdmin III ...................................................................................................... 63 4.2.2 Padrão de nomenclaturas ................................................................................ 64 4.3 FRAMEWORK DE DESENVOLVIMENTO .................................................. 64
4.3.1 Framework Symfony........................................................................................ 65 4.4 SISTEMA ............................................................................................................. 68 4.5 DIFICULDADES ENCONTRADAS ................................................................ 69
4.6 TESTES E VALIDAÇÃO .................................................................................. 70
5 RESULTADOS E DISCUSSÕES ........................................................ 71
5.1 PREPARAÇÃO DO AMBIENTE ..................................................................... 71
5.1.1 Cadastro de Usuário (dados basilares) ........................................................... 71
5.1.2 Cadastro de Incidentes (dados basilares) ....................................................... 72
5.2 UTILIZAÇÃO ..................................................................................................... 73 5.2.1 Cadastro de Problemas .................................................................................... 74 5.2.2 Cadastro de Erros ............................................................................................ 76 5.2.3 Informações gerenciais .................................................................................... 77 5.3 RESULTADOS .................................................................................................... 79 5.3.1 FAQ .................................................................................................................... 79 5.3.2 Ficha de Conhecimento .................................................................................... 81
6 TRABALHOS FUTUROS .................................................................... 83
7 CONCLUSÕES ...................................................................................... 84
REFERÊNCIAS BIBLIOGRÁFICAS ................................................... 86
A. ENTREVISTA COM COLABORADORES E CLIENTES DE TI ix
B. DOCUMENTO DE ESPECIFICAÇÃO DE REQUISITOS E CASOS DE USO ......................................................................................... x
C. SCRIPT DE CRIAÇÃO DA BASE DE DADOS .............................. xii D. DEPOIMENTO DO USUÁRIO TESTER DA SISTEMA ............ xvii
iv
LISTA DE ABREVIATURAS
AJAX Asynchronous Javascript and XML ASP Active Server Pages CERN Centre Europeen de Recherche Nucleaire CFML ColdFusion CMDB Configuration Management Database COBIT Control Objectives for Information and Related Technology COSO Committee of Sponsoring Organizations of the Treadway Commission CIs Itens de Configuração CQ Controle de Qualidade CSS Cascading Style Sheets DTI Departamento de Tecnologia da Informação DOM Document Object Model EFQM European Foundation for Quality Management FAQ Frequently Asked Question(s) GP Gerenciamento de Problemas GI Gerenciamento de Incidentes GM Gerenciamento de Mudanças HTML Hyper Text Markup Language HTTP Hyper Text Transfer Protocol IAS Oracle Internet Application Server ICT Information and Communication Technology IIS Microsoft Internet Information Services ITIL Information Technology Infrastructure Library JSP Java Sever Pages KPIs Keys Performance Indicator LCA Laboratório de Computação Aplicada MER Modelo de Entidade e Relacionamentos MIME Multipurpose Internet Mail Extension NCSA National Center for Supercomputing Applications OSI Open Systems Interconnection PgSQL Banco de Dados PostgreSQL PHP PHP Hypertext Processor PREPS Programa Nacional de Rastreamento de Embarcações Pesqueiras por
Satélite RFC Request for Changes SGDB 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 WWW World Wide Web XML Extensible Markup Language XSLT Extendible Stylesheet Language Transformations
v
LISTA DE FIGURAS
Figura 1. O Modelo da Cadeia Serviço-Rentabilidade. ....................................................................... 3 Figura 2. Modelo de processo do Service Support. .............................................................................. 5 Figura 3. Processos da ISO 20.000. ................................................................................................... 12
Figura 4. Relação ITIL vs ISO 20.000. .............................................................................................. 13 Figura 5. Diagrama de quebra-cabeças do ITIL. ................................................................................ 14 Figura 6. Ciclo de vida de um incidente. ............................................................................................ 20
Figura 7. Controle de problemas. ....................................................................................................... 21
Figura 8. Fluxo de identificação de problema. ................................................................................... 22
Figura 9. Diagrama de Causa e Efeito. ............................................................................................... 24
Figura 10. Controle de Erros. ............................................................................................................. 25
Figura 11. Ficha de conhecimento da Knowledge Base da Microsoft. .............................................. 27
Figura 12. FAQ da KBase da Red Hat. .............................................................................................. 28
Figura 13. Erro conhecido da Apple. ................................................................................................. 29
Figura 14. Integração entre Service Desk, GI, GP (CP e CE) e GM. ................................................. 34 Figura 15. Níveis do conhecimento.................................................................................................... 38
Figura 16. Arquitetura de hardware de um sistema Web. .................................................................. 41 Figura 17. Transação HTTP. .............................................................................................................. 42
Figura 18. Exemplo de um script PHP. .............................................................................................. 44
Figura 19. Compatibilidade entre MVC e UML. ............................................................................... 48 Figura 20. Caso de Uso do módulo de cadastro e fechamento de Problemas/Erros. ......................... 56
Figura 21. Casos de Uso do módulo de visualização de conhecimento. ............................................ 58 Figura 22. Diagrama de Classe Conceitual da Aplicação. ................................................................. 59 Figura 23. Screenshot da área de trabalho do DBDesigner4. ............................................................. 61
Figura 24. MER da aplicação. ............................................................................................................ 62
Figura 25. Interface do PgAdmin III. ................................................................................................. 63
Figura 26. Estrutura de utilização do PROPEL. ................................................................................. 65 Figura 27. Exemplo de código, gerado pelo Symfony, da camada de modelo. ................................. 66
Figura 28. Exemplo de código da camada de controle. ..................................................................... 67 Figura 29. Exemplo de código da camada de visão. .......................................................................... 68 Figura 30. Código da tabela.class.php. ............................................................................................... 69
Figura 31. Exemplo de validação de campos pelo framework. .......................................................... 70 Figura 32. Tela de listagem de usuários. ............................................................................................ 72
Figura 33. Tela de detalhamento de incidentes. ................................................................................. 73 Figura 34. Tela de cadastro de problemas. ......................................................................................... 75
Figura 35. Tela de cadastro de erros. ................................................................................................. 77
Figura 36. Relatório de RFCs por período ......................................................................................... 78
Figura 37. Tela de visualização das FAQs. ........................................................................................ 80
Figura 38. Ficha de conhecimento gerada pelo CPItil. ...................................................................... 82
vi
LISTA DE TABELAS
Tabela 1. Divisões do livro Deliver IT Services. ................................................................................ 15
Tabela 2. Divisões do livro ICT Infrastructure Management. ........................................................... 16 Tabela 3. Divisões do livro Service Suport. ....................................................................................... 17
Tabela 4. Comparação entre as soluções analisadas. ......................................................................... 30 Tabela 5. Fases da construção do conhecimento organizacional. ...................................................... 39 Tabela 6. Tabela para ranque de apresentação das fichas de conhecimento. ..................................... 55
vii
RESUMO
PEREIRA, Felipe Luiz. CPItil: uma aplicação de apoio ao gerenciamento de problemas baseado na recomendação ITIL. Itajaí, 2006. 156 pp. 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í, 2006. O departamento de Tecnologia de Informação (TI) vem se tornando parte do negócio das organizações, e não mais um departamento de colaboração e operacionalização das tarefas. Nesse âmbito, o aumento progressivo da complexidade da tecnologia, o descompasso da preparação dos técnicos em gerenciá-la, e a dificuldade que os usuários têm em absorver o potencial das ferramentas em mãos têm tornado árdua a tarefa de entrega de serviços de suporte e atendimento. Pensando nisso, muitas empresas estão empregando técnicas e modelos de qualidade, a fim de proporcionar um melhor relacionamento entre a TI e os seus clientes. O objetivo do presente trabalho consiste em analisar as tendências de gestão de TI e delimitar o modelo ITIL (conjunto das melhores práticas de TI) para o tema proposto, seguido do projeto e desenvolvimento de uma aplicação para um estudo de caso. Tal aplicação, desenvolvida em plataforma Web e utilizando, como base, apenas softwares open source (Apache, PHP, PostgreSQL e Symfony), foi testada e validada no ambiente do Laboratório de Computação Aplicada para auxílio ao suporte a usuários, instalação, desenvolvimento e manutenção do Sistema de Informação do Programa Nacional de Rastreamento de Embarcações Pesqueiras por Satélite (PREPS). Essa validação identificou melhora no atendimento, aumento do conhecimento explícito organizacional e reconhecimento e confiança dos clientes, fatores estes que elevam a indicação do ITIL como modelo a ser seguido na gestão de processos de entrega de serviços, mais especificamente na Gerência de Problemas de TI. Palavras-chave: Sistemas de Informação. Gerenciamento de Problemas de TI. Melhores Práticas do ITIL.
viii
ABSTRACT
The Information Technology (IT) department has become part of organizations' business, and not only a department for collaborating and operating tasks. Within this scope, the progressive increase of the technology's complexity, the irregularity in preparing technicians to manage it, and the difficulty that users find in absorbing their tools' potential have turned the delivery of assistance services into a hard task. With this in mind, many companies are using quality techniques and models, in order to provide best relationships between the IT and its clients. The objective of this paper consisted in analysing the tendencies of IT management and delimiting the ITIL (set of IT best practices) for the proposed subject, followed by the project and development of an application for a case study. This application, which was developed in a Web platform based only on open source softwares (Apache, PHP, PostgreSQL and Symfony), was tested and validated in the Laboratório de Computação Aplicada (Applied Computation Laboratory), to help the users support, the installation, the development, and the maintenance of the Information System of Programa Nacional de Rastreamento de Embarcações Pesqueiras por Satélite - PREPS (National Program for Tracking Fishing Vessels by Satellite). This validation identified improvement of the assistance, increase of the organizational explicit knowledge, and recognition and confidence from the clients. These factors elevate the indication of the ITIL as the model to be followed when administrating the delivery of services, more specifically in the Management of IT Problems. Keywords: Information Systems. Problems Management. Best ITIL practices.
1 INTRODUÇÃO
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). Nessa simbiose, se
faz necessária a formação de uma cultura digital que depende de uma operação tecnológica
ininterrupta, de qualidade e segura.
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 que os usuários têm em absorver o potencial das ferramentas em mãos
(CABRAL; THIVES JR, 2005).
Na busca do auxílio aos colaboradores de uma instituição no uso da tecnologia, cria-se a
necessidade de um departamento que seja tutor do conhecimento necessário para a
operacionalização diária das atividades. A área de Tecnologia de Informação deve não só
operacionalizar as atividades, mas também agregar valor ao negócio por meio de novas técnicas
(BERKHOUT et. al., 2000).
A utilização da Tecnologia da Informação (TI) auxilia no planejamento e produção de
serviços com agilidade, qualidade e controle de processos nas instituições, fazendo, do
conhecimento adquirido, um bem organizacional.
O desafio apresentado às organizações, pela realidade atual, está no ganho da produtividade
empresarial, através de uma administração voltada à melhoria do desempenho com a aplicação das
inovadoras tecnologias da informação. A preocupação com a redução de 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).
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 (BERKHOUT et. al., 2000).
2
1.1 PROBLEMATIZAÇÃO
1.1.1 Formulação do problema
A entrega de serviços de TI aos seus clientes (interno/externo) é uma importante tarefa a ser
executada por este tipo de departamento. A não-sistematização destas tarefas impulsiona o cliente a
desconfiança (e.g., preconceito, descrédito) de que este setor não está apto a prestar este serviço.
A simples existência de uma área de TI expectadora dos acontecimentos, desprovida de
conhecimento não se torna uma solução de qualidade. Entre os desafios dos setores de tecnologia,
devem estar o mapeamento pró-ativo dos problemas a serem enfrentados, a fim de desenvolver uma
gestão sistemática e evolutiva, não apenas atendendo reativamente as solicitações dos demais
colaboradores, os ditos clientes internos (BERKHOUT et. al., 2000).
O atendimento a incidentes, ou seja, resolução de fatos que interrompem a operação normal
do negócio é uma tarefa comumente reativa, causando assim a insatisfação dos clientes internos e
externos, desmoralizando a área de TI, e o expondo como mero expectador de acontecimentos.
O estudo dos problemas permite a definição de estratégias e a produção de mudanças na
infra-estrutura de TI e deve ser formalizado como um processo integrador das várias competências
existentes em um setor de tecnologia da informação.
Entende-se, como "problema", um estado da infra-estrutura e serviços de tecnologia da
informação que deve ser corrigido, levando-a a uma situação de maior confiabilidade (BERKHOUT
et. al., 2000). Enquanto os problemas não são tratados devidamente, eles produzem incidentes.
Quando um problema é adequadamente diagnosticado e contém uma solução paliativa, ele
se torna um erro conhecido. Com essa documentação, a possibilidade de solucionar incidentes no
primeiro nível aumenta, ou seja, a primeira pessoa que atende um chamado tem mais chances de
conseguir resolvê-lo (ibidem).
A ênfase na prevenção dos problemas ao invés de sua correção agrega qualidade aos
serviços internos, gerando uma maior rentabilidade do negócio através da motivação dos clientes
internos (Figura 1).
3
I
n
v
e
s
t
i
m
e
n
t
o
Qualidade
Interna
de Serviços
Satisfação
do
Empregado
Valor para
os Clientes
Satisfação
do Cliente
Fidelização
do Cliente
Aumento do
Faturamento
Maior
Rentabilidade
Retenção
do
Empregado
Produtividade
do
Empregado
Figura 1. O Modelo da Cadeia Serviço-Rentabilidade.
Fonte: Adaptado de Berkhout et. al. (2000).
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).
Prover serviços de alta qualidade com um foco particular no relacionamento com os clientes,
conscientizando que a área de TI deve firmar tudo que foi acordado entre seus colaboradores,
clientes internos, externos e parceiros. Este é o foco da biblioteca ITIL abordada neste Trabalho de
Conclusão de Curso (TCC).
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
Auxiliar a equipe de suporte e atendimento da área de TI, a fim de suportar com qualidade a
entrega de serviços é parte do modelo ITIL, este TCC, propõe o desenvolvimento de uma aplicação
Web de apoio ao gerenciamento de problemas de TI baseado nas recomendações deste modelo.
4
O desenvolvimento de tal aplicação está no escopo das habilidades de análise de requisitos,
análise de negócio, gerência de projeto, desenvolvimento, teste e validação de software de um
bacharel em Ciência da Computação. Portanto, justifica-se o desenvolvimento deste como um TCC.
A aplicação tem o intuito de apoiar o atendimento provido por setores de TI, conjugada ou
não com uma ferramenta de gestão de incidentes (integração não será requisito) em médias e
pequenas empresas que não possuam e necessitem de uma ferramenta para o auxílio à resolução de
chamados de suporte, agilizando o atendimento (através de identificação da solução) ao cliente e
aumentando a qualidade do processo.
Em uma visão gerencial, a aplicação auxiliará nos itens abaixo:
• Tomada de decisões pró-ativas para antecipação de incidentes;
• Controle de problemas;
• Controle de erros;
• Assistência a incidentes mais comuns;
• Checagem do seu próprio procedimento através das Keys Performance Indicator (KPIs)
recomendadas pelo ITIL; e
• Integração com as demais gerências: Incidentes e Mudanças.
Os conceitos que serão empregados na aplicação de auxílio a análise de problemas serão
baseados na metodologia ITIL, visto que ela se estabeleceu como padrão de facto em ambientes de
TI do mundo todo (BERKHOUT et. al., 2000). Sendo assim, essa aplicação terá, por base a
Configuration Management Database (CMDB) e os processos definidos conforme a Figura 2.
5
Figura 2. Modelo de processo do Service Support.
Fonte: Adaptado de Lloyd et. al. (2000).
O desenvolvimento dessa aplicação será em plataforma Web através a tecnologia PHP
Hipertext Preprocessor (PHP), utilizando o framework Symfony e o Sistema de Gerenciamento de
Banco de Dados PostgreSQL (PgSQL). Visto que sua base será toda em tecnologia Open Source e
buscar-se-á, assim, o corte de custos para o desenvolvimento e a interoperabilidade no quesito da
descontinuidade dos projetos-bases para futuras versões da aplicação em questão.
6
1.2 OBJETIVOS
1.2.1 Objetivo geral
O objetivo geral deste projeto de pesquisa é desenvolver uma aplicação de apoio ao
gerenciamento de problemas por estruturas de Service Desk baseada em tecnologia Web. Essa
aplicação deverá considerar as recomendações de gerenciamento de serviços do ITIL.
1.2.2 Objetivos específicos
Os objetivos específicos deste projeto de pesquisa 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, focando na gerência de problemas, para
delimitar o escopo da aplicação proposta;
• Estudar os princípios de Gestão de Conhecimento, para estabelecer as necessidades de
dados que possibilitem o crescimento do conhecimento organizacional com a utilização
da ferramenta;
• Pesquisar e analisar soluções de software similares e empresas que utilizam esse
conceito, tabulando os principais requisitos identificados e comparando-os à solução
proposta;
• Estabelecer o conjunto de ferramentas e linguagens de desenvolvimento de aplicações,
para a construção da aplicação;
• Especificar um modelo conceitual, utilizando como referência a linguagem UML, de
forma a relacionar os requisitos funcionais, não-funcionais, regras de negócios, atores
envolvidos, casos de uso, protótipos de telas, classes de domínio e comportamento da
aplicação;
• Desenvolver a aplicação proposta;
• Efetuar testes de validação da aplicação; e
• Documentar os resultados obtidos.
7
1.3 METODOLOGIA
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).
Um trabalho de monografia é um estudo realizado acerca de um determinado assunto, com
conceitos técnico-científicos sobre um único problema. É esse tipo de trabalho que visa à aplicação
de diretrizes metodológicas a ser reconhecida na comunidade acadêmica científica (SEVERINO,
2002).
A este Trabalho de Conclusão de Curso foi aplicado ênfase nas seguintes etapas:
1. Determinação do tema - problema-tese do trabalho: Escolha do tema e objetivos a serem
alcançados descritos no documento de Pré-Proposta, realizado em etapa preliminar e
julgado, por dois membros indicados do corpo docente, apto a ser desenvolvido como
Trabalho de Conclusão do Curso de Ciência da Computação;
2. Levantamento da bibliografia: Após estabelecido e determinado o tema do trabalho, foi
realizado um levantamento bibliográfico nos mais variados acervos (e.g., CDs, Internet,
livros, artigos, cases), à busca de palavras-chave condizentes com o conteúdo desejado;
3. Leitura e documentação: Nesta etapa, foi realizada a pesquisa e filtro no material
encontrado conforme a relevância da publicação;
4. Construção lógica: As idéias da pesquisa foram estruturadas conforme as exigências
racionais da sistematização própria do trabalho;
5. Construção do texto e articulação dos parágrafos: Foi desenvolvido o texto, organizado
em capítulos de diferentes ênfases com parágrafos individuais, cada qual com uma idéia
distinta sendo exposta;
6. Projeto e desenvolvimento: Confeccionada a documentação alicerce para a construção
da aplicação e o desenvolvimento da mesma baseada no levantamento bibliográfico; e
7. Conclusão: Realizada uma crítica sobre os resultados obtidos da utilização do framework
ITIL e da ferramenta proposta, assim como discussões sobre a possibilidade de trabalhos
futuros derivados ou integrados a esta monografia.
8
1.4 ESTRUTURA DO TRABALHO
O Capítulo 1 introduz o modelo do negócio que cerca a aplicação, focando a necessidade da
Tecnologia da Informação na era atual das organizações. Assim, pretende-se conceituar os
parâmetros que serão apresentados durante o desenvolvimento do projeto e como estes são
alvejados na busca da qualidade de entrega de serviços de suporte a usuários. Dessa forma, define-
se os objetivos a serem alcançados pela aplicação proposta.
O Capítulo 2 é dividido em duas vertentes: negócio e tecnologia. Na primeira vertente, faz-
se o referencial teórico que delimita o escopo da aplicação dentro do framework ITIL, evidenciando
as necessidades de um modelo a ser seguido pelo Departamento de Tecnologia da Informação e
explanando o porquê da escolha do ITIL. Na segunda parte, apresenta-se as tecnologias envolvidas
no desenvolvimento de uma aplicação Web e os desafios de tal desenvolvimento para o âmbito de
um cientista da computação.
O Capítulo 3 é uma abordagem sucinta da documentação em UML (Unified Modeling
Language), mostrando os principais artefatos para a modelagem desse sistema Web que possibilite a
compreensão mútua entre o que é solicitado pelo cliente, e como isso deve ser desenvolvido pelo
programador do projeto.
O Capítulo 4 possibilita a compreensão da etapa de desenvolvimento, explanando a forma
de execução, atividades e ferramentas utilizadas nesta fase (e.g., framework, linguagem de
programação, manutenção de banco de dados).
O Capítulo 5 apresenta os resultados obtidos na fase de teste e aplicação da ferramenta.
Relatando as dificuldades encontradas, casos de sucesso e insucesso do uso da aplicação e
justificando a necessidade da ferramenta de apoio a tal gerência estudada.
O Capítulo 6 refere-se a trabalhos futuros que possam ampliar e/ou complementar tarefas e
atividades do tema proposto e a possível integração da aplicação com outras que tenham relação aos
processos do ITIL.
2 FUNDAMENTAÇÃO TEÓRICA
A fundamentação teórica deste projeto deverá dar suporte a três vertentes, a primeira
evidenciando os fatores do negócio da aplicação, e a segunda, os fatores tecnológicos envolvidos
para a construção da aplicação proposta. Elas são respectivamente:
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 da aplicação com base na
metodologia ITIL;
2. Gestão do Conhecimento (Seção 2.2): Estudar os princípios de gestão do conhecimento
para estabelecer necessidades de dados que possibilitem o crescimento do conhecimento
organizacional com a utilização da ferramenta.
3. Estudo de Desenvolvimento de Sistemas Web (Seção 2.3): Conhecer os fundamentos
desses sistemas para basear a aplicação na Internet, fazendo uso de diferenciais na forma
de desenvolvimento, com vistas ao aproveitamento da especificação UML.
2.1 GERENCIAMENTO DE SERVIÇOS DE TI
2.1.1 Introdução
O alvo desta seção é o Gerenciamento de Serviços de TI, com a contextualização do escopo
do trabalho, vinculado ao tema de análise e busca dos problemas enfrentados pelos departamentos
de Tecnologia da Informação.
Foi realizado um levantamento bibliográfico, das práticas recomendadas e/ou padrões
internacionais existentes, buscando entender a melhor forma de catalogar e tratar estes problemas,
contextualizando a integração da Tecnologia da Informação e as organizações modernas.
2.1.2 Organizações e a tecnologia da informação
Pela realidade atual, o desafio apresentado às organizações está no ganho da produtividade
empresarial, através de uma administração voltada à melhoria do desempenho, com a aplicação das
inovadoras tecnologias da informação. A preocupação com a redução de custos torna-se insuficiente
e faz parceria com a busca à eficiência dos recursos humanos e a racionalização e simplificação de
processos (TACHIZAWA; ANDRADE, 2003).
10
A existência de uma área 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 da tecnologia, visando à capacitação e qualificação dos colaboradores e proporcionando
sistemas de informações capazes de auxiliar na detecção, classificação e resolução dos problemas
enfrentados.
A Tecnologia da Informação é essencial e indispensável, se utilizada de forma correta e for
suportada por serviços de qualidade. Para isso, faz-se necessário o apoio de uma equipe de
profissionais que possuam maior domínio da tecnologia.
Entretanto, apenas a existência de uma área de Tecnologia da Informação (TI) não a torna
uma solução completa. Uma ferramenta que possibilite a fácil adaptação entre colaboradores,
negócio, infra-estrutura disposta e clientes faz-se necessária a todo o momento, caso contrário
necessitar-se-ia de treinamento e especialização de cada membro da equipe de suporte.
Outro fator que deve ser levado em consideração, dentre os desafios dos setores de
tecnologia, é o mapeamento pró-ativo dos problemas a serem enfrentados, a fim de desenvolver
uma gestão sistemática e evolutiva e não apenas "manter os colaboradores do TI com suas cabeças
acima d’água" (BERKHOUT et. al., 2000).
O conhecimento utilizado pela equipe de apoio à tecnologia deve ser administrado e
compartilhado, minimizando assim o impacto dos problemas a serem enfrentados por meio de ações
rápidas de detecção e resolução da equipe de TI.
2.1.3 O gerenciamento de serviços de tecnologia da informação
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 que os usuários têm para absorver o potencial das ferramentas em mãos
(CABRAL; THIVES JR, 2005).
O gerenciamento dos serviços prestados pela equipe de suporte a TI é o alicerce da
construção do conhecimento para solução de problemas. É através desse gerenciamento, que
poderão ser mapeados os problemas enfrentados.
11
O gerenciamento de serviços pode ser feito em dois modos, em nível estratégico e
tático/operacional, dentro dessas duas linhas, podemos citar alguns modelos internacionalmente
conhecidos: ITIL (Information Technology Infrastructure Library), COBIT (Control Objectives for
Information and related Technology), COSO (Committee of Sponsoring Organizations of the
Treadway Commission), entre outros (IT GOVERNACE INSTITUTE, 2004).
ITIL
O ITIL define "o que deve ser feito", ficando a cargo das organizações a definição de "como
será feito" (ESPILDORA, Francisco, 2004). Este framework apresenta um conjunto de melhores
práticas compreensíveis, consistentes e coerentes para a governança de processos de TI, mas não
dita ações que devem ser tomadas no dia-a-dia, pois isso se diferencia de organização para
organização (BERKHOUT et. al., 2000).
Pelo fato do ITIL ser alvo deste trabalho, o mesmo será estudado na Seção 2.1.4.
COBIT
Em resumo, com a necessidade de melhor gestão dos recursos de tecnologia da informação,
o modelo COBIT, que cumpre esse 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).
Do ponto de vista do COBIT, a governança de uma corporação (i.e., o sistema através do
qual as corporações são governadas e controladas) e a governança de TI (i.e., a maneira com a 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 de TI e vice-versa (3RD ED.
COBIT STEERING COMMITTEE AND THE IT GOVERNANCE INSTITUTE, 2000).
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
riscos relacionados, efetividade e eficiência, e distribuição de recursos na busca dos objetivos da
corporação (COMMITTEE OF SPONSORING ORGANIZATIONS OF THE TREADWAY
COMMISSION, 2004).
12
ISO 20.000
A ISO 20.000 é o primeiro padrão internacionalmente reconhecido para gerenciamentos de
serviços de TI, introduzindo uma cultura de serviços que inclui metodologias de entrega e suporte a
serviços (MAGALHÃES, 2007).
Os principais objetivos deste padrão é possibilitar que empresas/unidades/departamentos,
certifiquem seus processos associados a (ibidem) (Figura 3):
• Foco de entrega de serviços a clientes;
• Alinhamento da TI ao negócio;
• Implementações de acordo de nível (SLA); e
• Qualidade dos serviços em ênfase de processos.
Figura 3. Processos da ISO 20.000.
Adaptado de: Magalhães (2007).
O ITIL oferece certificações para profissionais da área de TI, enquanto a ISO 20.000
certifica organizações, então se diz que o primeiro passo para a obtenção da certificação ISO é a
total aplicação do modelo ITIL.
Na Figura 4 é possível verificar a semelhança/relação dos processos do ITIL com os
processos da ISO 20.000.
13
Figura 4. Relação ITIL vs ISO 20.000.
Retirado de: Magalhães (2007).
2.1.4 IT Infrastructure Library: ITIL
A aplicação da ciência da gerência da TI, desmantelada em processos realizados nas
organizações, abrangendo toda a operação de TI, descrita em um conjunto de livros, na forma de
um framework (Figura 5).
14
Figura 5. Diagrama de quebra-cabeças do ITIL.
Fonte: Adaptado de Berkhout et. al. (2000).
Esse modelo é agrupador de cinco macros processos divididos em livros: Entrega de Serviço
(Deliver IT Services), Perspectiva de Negócios (Business Perspective), Gerenciamento de
Aplicações (Application Management), Gerenciamento de Infra-Estrutura (ICT Infrastructure
Management) e Suporte de Serviços (Support IT Services), estes cinco se sobrepondo e
completando, sem limites ou divisões explícitas (BERKHOUT et. al., 2000).
O livro Entrega de Serviços, escrito por BARLETT et. al. em 2000, foca os requisitos de
negócios do fornecedor para o cliente (pessoas que são atendidas pelo serviços prestados). Para
descrever tal suporte, o livro é dividido conforme descrito na Tabela 1.
15
Tabela 1. Divisões do livro Deliver IT Services.
Capítulo Descrição 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
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
Fonte: Adaptado de Barlett et. al. (2006).
O livro Perspectiva de Negócios (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.
O livro Gerenciamento de Aplicações (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 (ibidem).
O livro Gerenciamento de Infra-Estrutura inclui (GRAHAM et. al., 2000) os capítulos
descritos na Tabela 2.
16
Tabela 2. Divisões do livro ICT Infrastructure Management.
Capítulo Descrição Design e planejamento Prover caminhos estratégicos para o desenvolvimento e
instalação de uma infra-estrutura em que 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 Garante uma fundação estável e segura das 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
Fonte: Adaptado de Graham et. al. (2000).
O livro Suporte de Serviço 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 (Tabela 3):
17
Tabela 3. Divisões do livro Service Suport.
Capítulo Descriçã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. Esta função será estudada em detalhes na Seção 2.1.5.
Gerenciamento de incidentes (GI)
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 e será estudado na Seção 2.1.6.
Gerenciamento de problemas (GP)
Seu objetivo é diminuir o impacto, quantidade e recorrência dos incidentes. Esse processo é o alvo central desse trabalho de conclusão de curso e será estudado na Seção 2.1.7.
Gerenciamento de configuração (GC)
A gerência da configuração fornece um modelo lógico da infra-estrutura ou um serviço identificando, controlando, mantendo e verificando as versões dos artigos da configuração (CIs) na existência.
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 processo sejam considerados juntos.
Fonte: Adaptado de Berkhout et. al. (2000).
2.1.5 Service Desk
O Service Desk é o ponto de relação entre o departamento de TI e os seus usuários. É o
ponto focal de toda articulação dos processos do ITIL, que deve buscar a disponibilidade com
qualidade dos serviços providos pela área de TI (BERKHOUT et. al., 2000).
É o Service Desk que deve comunicar aos usuários o andamento das suas solicitações,
escalonar os incidentes, informar mudanças, identificar oportunidades de negócios e potencializar a
satisfação do usuário (ibidem).
Esta função do ITIL é a principal responsável pela construção de todo o conhecimento
necessário para controle dos problemas (foco do TCC), pois esta função irá fazer o
acompanhamento de todos os incidentes e irá identificar quando um incidente é fruto de um
problema (Seção 2.1.6).
18
A função Service Desk é ramificada para os atendentes de TI. Desde o Help Desk,
responsável pelo primeiro atendimento até o especialista de uma determinada aplicação, passando
pelos atendentes de segundo, terceiro níveis, são funções do Service Desk.
O acompanhamento de incidentes e problemas reportado por um cliente a um Service Desk
de primeira linha, deve ser acompanhado pelo mesmo até sua finalização, passando a imagem de
compromisso e personalização (BERKHOUT et. al., 2000).
2.1.6 Incidentes versus problemas
Incidente é qualquer evento que não é parte da operação padrão de um serviço e que causa,
ou pode causar uma interrupção ou redução na qualidade daquele serviço. Um problema é uma
causa desconhecida por trás da ocorrência de um ou mais incidentes (BERKHOUT et. al., 2000).
A Gerência de Incidentes (GI) tem como foco resolver rapidamente evento que impossibilite
o desempenho das tarefas, mantendo assim os acordos firmados de agilidade de serviço.
A Gerência de Problemas (GP) deve evidenciar a causa raiz deste problema evitando assim
os incidentes. O tempo para resolução de problemas é de importância secundária, ocasionando um
maior tempo de parada, mas prevenindo a reincidência (BERKHOUT et. al., 2000).
Ao queimar a fonte de um computador, a GI deve rapidamente identificar os acordos com o
cliente e decidir por efetuar a troca da fonte ou disponibilizar um computador de backup. No caso a
GP pode identificar que a raiz do problema seja uma oscilação na rede elétrica, logo, deve
documentar e solicitar mudanças para que o problema seja finalizado.
O atendente de suporte pode desempenhar as duas tarefas, porém deve sempre estar atento
para não alterar as diretrizes do papel que estiver executando, pois as duas tarefas são importantes,
porém possuem focos opostos.
Embora com diferentes focos de serviços a serem prestados, há uma sinergia necessária
entre as gerências, pois é indispensável a grande carga informacional sobre incidentes para a melhor
identificação dos problemas.
19
2.1.7 Gerenciamento de problemas
O objetivo do GP é minimizar os impactos adversos dos incidentes e problemas no negócio
da instituição, causados por erros dentro da infra-estrutura de TI, impedindo e prevenindo a
recorrência de incidentes relacionados a esses erros (BERKHOUT et. al., 2000).
Controle de problemas, controle de erros e gerenciamento pró-ativos de problemas são
responsabilidades do GP, o qual define “problemas” como a causa de um ou mais incidentes, e
“erros conhecidos” como problemas que foram diagnosticados e possuem soluções paliativas
(ibidem).
Poucos incidentes relatados ao Service Desk são desconhecidos ou misteriosos para a equipe
de atendimento (segundo e terceiro nível); é possível que muitos desses incidentes já tenham sido
resolvidos (ibidem).
A documentação desses problemas, em que já foi identificado workaround, possibilita que
os funcionários de primeiro nível, durante a investigação e o diagnóstico (Figura 6), apliquem as
soluções indicadas.
O GP possibilita à organização, um aumento continuado de qualidade na infra-estrutura de
TI, soluções permanentes para os problemas, um volume de incidentes reduzidos, um número de
atendimento de primeiro nível elevado e um ganho de conhecimento para a organização.
Em um nível elevado de maturidade, um Departamento de TI deve ser portador de todo
conhecimento do negócio da organização, com isto poderá agregar valor e qualidade na prestação
do serviço para o cliente final.
A não-implementação do GP pode fazer com que os funcionários do departamento de TI
sejam expectadores dos acontecimentos, trabalhando apenas reativamente, desmotivando os demais
colaboradores da instituição e levando o departamento ao descrédito.
20
Figura 6. Ciclo de vida de um incidente.
Fonte: Adaptado de Berkhout et. al. (2000).
Controle de problemas
O objetivo do controle de problemas é identificar, classificar, diagnosticar e requisitar
mudanças (Figura 7) para a causa-raiz de um incidente, documentando passo a passo todas essas
tarefas, para que a equipe de atendimento possa solucionar outros incidentes similares de forma
mais eficiente.
21
Figura 7. Controle de problemas.
Fonte: Adaptado de Berkhout et. al. (2000).
Identificação e registro
Muitos problemas são identificados por pessoas de fora da equipe de gerência de problemas.
De qualquer maneira, todos os problemas devem ser notificados e registrados através dos processos
do Gerenciamento de Problemas (BERKHOUT et. al., 2000).
Por definição, uma determinada empresa, pode escolher não aplicar muitos esforços para um
determinado tipo de problemas, levando em consideração a simplicidade dos incidentes gerados, do
impacto ou possibilidade baixa de retorno, então um único registro deste problema é inserido em
uma base de dados, e nele amarrado todos os incidentes equivalentes.
22
Figura 8. Fluxo de identificação de problema.
Fonte: Adaptado de Berkhout et. al. (2000).
Os registros de problemas devem ser gravados em uma base de dados (Figura 8), de
preferência na CMDB (Configuration Management Database), e não precisam estar ligados
diretamente a um cliente (BERKHOUT et. al., 2000), pois os dados devem se referir aos Itens de
Configuração.
23
Durante o atendimento de um incidente pode haver a identificação de um problema, que
deverá ser apenas documentado (foco de GI vs foco de GP), com uma rápida classificação, porém
quanto melhor esta documentação, melhor a sinergia entre as gerências.
Classificação
A dificuldade de classificação se dá pela visualização do impacto em curto prazo, e não em
longo prazo, como deve ser feita (BERKHOUT et. al., 2000). Durante essa classificação, deve-se
identificar os CIs (e.g. software, hardware, dentre outros), urgência e prioridade, fatores estes
determinantes dos recursos que serão utilizados para resolução/documentação deste problema. Uma
boa fonte para a classificação de problemas é o atendimento feito pela gerência de incidentes, que
por sua vez já havia classificado o incidente durante a sua abertura.
Investigação e diagnóstico
A investigação e diagnóstico de um problema podem retardar o fechamento de um incidente
(BERKHOUT et. al., 2000). Por isso, deve-se buscar o maior nível de detalhamento durante o
atendimento do incidente, para uma posterior análise que deverá diagnosticar o problema.
Cada instituição deve encontrar uma forma que melhor se adapte para investigação e
diagnóstico de um problema, muitas vezes aplicando teorias de Qualidade Total. O ITIL,
comportando-se como um framework e não como uma seqüência de passos, deixa aberto à
utilização de qualquer técnica.
O Diagrama de Ishikawa (Figura 9) é uma ferramenta gráfica utilizada pela Administração
para o Gerenciamento e o Controle da Qualidade (CQ) em processos diversos. Originalmente
proposto pelo engenheiro químico Kaoru Ishikawa em 1943 e aperfeiçoado nos anos seguintes, é
também conhecido como diagrama causa-efeito, diagrama espinha-de-peixe, diagrama 4M,
diagrama 5M e diagrama 6M (GALUCH, 2002).
24
Figura 9. Diagrama de Causa e Efeito.
Fonte: Adaptado de Berkhout et. al. (2000).
Essa ferramenta permite estruturar hierarquicamente as causas de determinado problema,
bem como seus efeitos sobre a qualidade ou incidentes relacionados.
Controle de erros
Um erro conhecido é um problema que foi diagnosticado com sucesso e possui uma solução
paliativa (BERKHOUT et. al., 2000), e o controle dos erros tem como objetivo documentar e
solicitar as mudanças necessárias (Figura 10) para minimizar a reincidência desses acontecimentos.
Não é obrigatoriedade que todos os erros sejam resolvidos. Uma empresa pode optar por
deixar que um erro conhecido permaneça ativo, quando, por exemplo, os recursos necessários para
a resolução sejam demasiadamente caros, e o impacto dos incidentes causados sejam pequenos.
Identificação e registro
Há duas fontes de erros: o ambiente de produção (e.g. um problema que se torna um erro) e
o ambiente de desenvolvimento (e.g. uma nova implementação). O GP deve identificar e gravar
esses erros, de forma a sustentar a navegabilidade no sentido: Incidente, Problema, Erro Conhecido,
Solicitação de Mudança e Liberações (BERKHOUT et. al., 2000).
25
Figura 10. Controle de Erros.
Fonte: Adaptado de Berkhout et. al. (2000).
Avaliando erros
Caso necessário, a equipe de controle de erros completa a Requisição de Mudança (RFC –
Request for changes) criada pela equipe de controle de problemas. É nesse ponto que são
verificados a urgência e o impacto do erro.
O desenvolvimento e teste das ações requeridas são responsabilidades da Gerência de
Mudanças (GM). Também é a GM que escolhe o momento mais oportuno para a liberação das
mudanças. Em casos extremos, cabe à GP a autorização e execução das ações.
Registro de resolução
Todo erro solucionado deve conter um registro no banco de dados do GP (BERKHOUT et.
al., 2000), facilitando a investigação e resolução de futuros incidentes.
Realizando o fechamento de um problema/erro
Após uma realização de mudanças efetuada com sucesso (Figura 10), um erro conhecido é
encerrado juntamente com os seus problemas associados. No caso em que existir incidentes
26
pendentes, estes deverão ser classificados como “Pendência Pós-Mudança” até que se tenha certeza
de que a requisição foi bem atendida (BERKHOUT et. al., 2000).
Controle pró-ativo de problemas
A gerência de problemas deve atuar também de forma pró-ativa, analisando as tendências
identificadas na base de incidentes, resolvendo erros conhecidos e obtendo dados de
software/hardware de monitoração (BERKHOUT et. al., 2000).
De tempos em tempos, uma análise deverá ser feita na base da gerência de incidentes,
buscando identificar tendências de incidentes, como por exemplo muitos clientes solicitando
suporte para utilização de uma determinada aplicação. Um GP pró-ativo pode identificar então a
necessidade de treinamento ou de adaptação da aplicação.
Resolver erros conhecidos para que a solução paliativa não tenha de ser constantemente
utilizada também é tarefa de pró-atividade do GP. Essa necessidade pode ser identificada,
analisando quantas vezes um workaround foi utilizado (BERKHOUT et. al., 2000).
E por fim, utilização de softwares/hardwares de monitoramento, para identificar problemas
inerentes, por exemplo, um HardDisk de um determinado servidor está próximo de sua capacidade
total de armazenamento, o GP deve solicitar mudanças antes que ocorram incidentes de cliente que
desejam armazenar informação e não estão conseguindo.
2.1.8 Análise das melhores práticas
Uma tarefa importante de um Trabalho de Conclusão de Curso (TCC) é analisar e
documentar soluções similares, procurando extrair um modelo de aplicação geral a partir de casos
particulares.
Esta análise de melhores práticas serve para avaliar na prática os conceitos estudados no
levantamento bibliográfico e também como fonte de requisitos do sistema a ser proposto no
Capítulo 3.
Para este TCC, escolheu-se três organizações de visibilidade internacional, que utilizam
práticas similares as conceituadas pelo framework ITIL: Microsoft, RedHat e Apple.
27
Após a apresentação das soluções empregada por estas organizações, resume-se em uma
tabela comparativa adicionando uma coluna com o que será proporcionado pela aplicação alvo
deste TCC.
Microsoft
A MICROSOFT CORPORATION, maior e mais conhecida produtora de software do
mundo, utiliza suas fichas de conhecimento em seu website para prover aos seus usuários
informações sobre seus produtos. Nessa fichas de conhecimento (Figura 11) podem-se encontrar
alguns dos itens mencionados do ITIL.
Figura 11. Ficha de conhecimento da Knowledge Base da Microsoft.
Fonte: MICROSOFT CORPORATION (2006).
Um dos itens que merecem destaque nas fichas de conhecimento da Microsoft é o
“softwares não afetados”, com este, usuário podem identificar que a resposta para erros em
determinado programa não é relacionada por aquela ficha de conhecimento em específico.
RED HAT
A RED HAT, empresa que comercializa o Red Hat Linux, disponibiliza um sub-website
com o título de KnowleadgeBase, um portal que através de questões e respostas, estrutura os
workarounds de problemas enfrentados nas distribuições de seu sistema operacional.
28
Figura 12. FAQ da KBase da Red Hat.
Fonte: RED HAT, INC (2006).
Neste portal os usuários podem encontrar resolução de erros conhecidos através de uma
estrutura de perguntas e respostas (i.e., FAQ - Frequently Asked Question(s)), o que facilita a busca
quando se encontra a exata pergunta que está se procurando (Figura 12).
Todas as fichas apresentadas pela organização, solicitam no rodapé da página um feedback
do usuário. Esse retorno é importante tanto para o ranqueamento (i.e., evidenciar a ficha mais do
que outras de assuntos similares) da ficha nas pesquisas quanto para possíveis revisões da mesma.
APPLE
A APPLE COMPUTER INC, marca do segundo microcomputador a entrar no mercado,
atualmente atua como fabricante de computadores, produtora de softwares, dispositivos eletrônicos
de consumo, entre outros, possui um portal denominado AppleCare KnowledgeBase (Figura 13).
29
Figura 13. Erro conhecido da Apple.
Fonte: APPLE COMPUTER, INC (2006).
No rodapé das fichas de conhecimento de um erro conhecido da Apple, é disposta a data em
que este erro foi identificado e a data de atualização, indicando as revisões feitas periodicamente.
Considerações
De fato o termo 'base de conhecimento' está se tornando comum entre as organizações
prestadoras de entrega de serviço. A base de conhecimento, do inglês knowledge base, é a
formalização de regras, fatos e outras representações sobre o negócio de uma organização (ICH
ARCHITECTURE RESOURCE CENTER, 2006). Estruturar o conhecimento para que auxilie da
melhor maneira o atendimento aos clientes é um grande desafio das aplicações de apoio à tomada
de decisões.
Dentre as soluções analisadas nesta seção, foram verificados apenas os resultados atingidos.
Estes resultados foram planilhados na Tabela 4, e confrontados com o framework ITIL.
30
Tabela 4. Comparação entre as soluções analisadas.
Função Microsoft RedHat Apple TCC
Sintomas � �
Causa � �
Resolução � � � �
Mais informações
� � �
Afeta � �
Não afeta �
Keywords � � �
Multi-línguas � �
Feedback do usuário
� � � �
Pergunta (issue) � �
Data de última revisão
� � � �
Número da revisão
�
No Apêndice A, está o modelo e as entrevistas executadas com atendentes de Help Desk.
Dentre os entrevistados, incluem-se clientes e atendentes de empresas que executam entrega de
serviço de TI. Alguns dos entrevistados trabalham em empresas que possuem software de auxílio:
Qualitor (funcionários da UNIVALI) e i-Controle (funcionários da Prefeitura Municipal de Itajaí).
O alvo das entrevistas é avaliar a solução utilizada pelos entrevistados e identificar os pontos
de relevância que devem estar disponíveis na aplicação alvo deste TCC (Tabela 4). Para os
entrevistados que não utilizam nenhum software de auxílio à entrega de serviço, procurou-se
identificar quais as suas necessidades.
Para um maior entendimento da Tabela 4 segue a descrição dos itens:
31
Sintomas
Os sintomas indicam os principais incidentes gerados ao reincidir o problema, no caso das
soluções estudadas, as questões estão ligadas a acontecimentos de software (e.g., arquivo fecha após
muito tempo aberto, cliente web não conecta).
Causa
A causa de um problema é o evento que está ocasionando os incidentes, a causa raiz (e.g., os
usuários estão com dificuldade de imprimir em impressora remota, a causa pode ser: falta de
treinamento, rede oscilante, impressora com problema).
Resolução
Os procedimentos que devem ser tomados para tentar solucionar o problema (e.g.,
computador não possui endereço IP, passos a serem seguidos: clica em iniciar > executar, cmd,
enter, ipconfig, ...).
Mais informações
Informações adicionais que podem servir para obtenção de conhecimento no âmbito do
problema (e.g., problemas de configuração de compartilhamento de rede, no item maiores
informações pode-se adicionar a diferença dos protocolos de compartilhamento e os problemas que
podem causar).
Afeta
Conjunto de CIs (i.e., itens de configuração, ativos de TI) que são afetados pelo problema
(e.g., um vírus é um problema que afeta software A, B e C, e comunicação do tipo X e Y).
Não-afeta
Conjunto de CIs, similares aos afetados, que não sofrem paralisação ou perda de qualidade
com o problema em questão (e.g., software D e C, e comunicação do tipo R e F).
Keywords
Conjunto de palavras chaves que relacionam rapidamente o problema (e.g., rede, rj45,
cabeamento estruturado).
32
Multi-línguas
Suporte a múltiplos idiomas nas fichas de conhecimento (e.g., Inglês, Português, Alemão).
Feed-back do usuário
Utilização da opinião do utilizador (i.e., relacionamento com o cliente). As fichas de
conhecimento devem possuir um espaço para que o usuário informe se o conteúdo foi realmente
esclarecedor de suas dúvidas, isso possibilita as revisões e renovações das fichas de conhecimento.
Pergunta (issue)
A pergunta é utilizada para confeccionar mecanismos de Frequently Asked Question(s),
onde é disponibilizado uma lista dos problemas mais comuns (i.e., os que mais geram incidentes e
que a equipe de Gerenciamento de Problemas não julga necessário resolve-lo), indicando-os através
de perguntas (e.g., Como configurar a impressora Epson R200?).
Data de última revisão
Data de última revisão da ficha de conhecimento, técnica utilizada para indicar o
envelhecimento (ou o inverso) dos valores da ficha. Indica quão atualizado está as informações
citadas.
Número da revisão
Número de vezes que foi alterada a ficha de conhecimento.
2.1.9 Escopo do trabalho
O escopo deste Trabalho de Conclusão de Curso, refere-se à modelagem, documentação e
implementação de uma aplicação de apoio ao gerenciamento de serviços de TI, limitando-se aos
requisitos do processo de gerenciamento de problemas do livro Service Support (BERKHOUT
et. al., 2000).
A escolha desse processo se dá pela relevância da aplicação de técnicas de Gerenciamento
de Problemas (GP) para a melhoria da qualidade dos serviços prestados pelo Departamento de TI.
Para o melhor entendimento do escopo deste projeto, conceituam-se as entradas e saídas do
GP segundo o modelo do ITIL. Em seguida, posiciona-se a aplicação no âmbito de uma
organização e por fim as métricas de desempenho do GP.
33
Entradas necessárias para o GP
As entradas para o Gerenciamento de Problemas são: (i) detalhamento dos incidentes
(Gerenciamento de Incidentes); (ii) detalhe de configurações do CIs (CMDB); e (iii) solução de
contorno identificada no atendimento dos incidentes (BERKHOUT et. al., 2000).
Os incidentes são gerados por problemas (ibidem), e através dos incidentes é que a gerência
reativa dos problemas pode identificar, documentar e resolver os problemas enfrentados na
organização.
Muitos problemas surgem da má configuração dos CIs (e.g., configuração de switchs,
desenvolvimento de sistemas, entre outros). Através do detalhamento desses itens, uma gerência de
problemas pró-ativa pode identificar incidentes inerentes de acontecimento.
Por fim, a sinergia entre as gerências, poupando energias e recursos, utilizando as soluções
paliativas para a resolução de incidentes, na documentação dos problemas tornando-os erros
conhecidos com workarounds sistematizados para a organização.
Legado da gerência de problemas
Os resultados do processo de gerência de problemas, além da revisão constante do seu
próprio processo, são: (i) erros conhecidos; (ii) solicitações de mudanças (i.e., request for change);
e (iii) resoluções/atualização de problemas (BERKHOUT et. al., 2000).
Os erros conhecidos são grandes ferramentas para a equipe de atendimento de primeiro
nível, possibilitando resolver incidentes já em primeira instância. Isto aumenta a confiança dos
clientes do departamento de TI.
Atualização de problemas, solicitações de mudanças e resoluções de problemas, são as
principais tarefas do GP, é através dessas tarefas que gera-se o aumento de qualidade dos serviços
de TI.
Posicionando o GP na organização
Muitas vezes, os problemas são identificados pela gerência de incidentes e reportados à
gerência de problemas. É função do GP prestar um suporte aos atendentes, buscando diminuir o
número de incidentes ou fixar soluções paliativas para agilizar o atendimento.
34
Na Figura 14, podemos identificar a ligação do GP com as demais gerências e visualizar o
fluxo de informações e solicitação geradas.
O GI consulta os Erros Conhecidos para solucionar problemas reincidentes, caso seja um
problema “novo”, é reportado para o GP. O Controle de Problema por sua vez deve analisar se há
uma nova medida paliativa (e.g. medida de contorno executada pela GI) a ser executada
transformando o problema em erro conhecido.
Figura 14. Integração entre Service Desk, GI, GP (CP e CE) e GM.
Fonte: Adaptado de Berkhout et. al. (2000).
O Controle de Erro deve avaliar se o problema possui impacto no negócio (i.e., impacto dos
incidentes gerados é muito pequeno), caso possua, deve ser solicitada uma mudança, caso contrário,
permanece na base de erros conhecidos.
35
Keys Performance Indicator
As Keys Performance Indicator (KPIs) são indicadores de performance da equipe de
Gerenciamento de Problemas (GP), com essas informações é possível avaliar se o esforço feito pelo
GP está sendo válido ou não para a empresa onde está sendo aplicado. O ITIL indica algumas KPIs,
dentre elas (BERKHOUT et. al. 2000):
• Número de problemas por status, serviços, impacto e classificação;
• Número e impacto dos incidentes durante a operação do processo;
• Percentual de esforço reativo versus pró-ativo;
• Esforço, custo e tempo dos diagnósticos;
• Número de requisições de mudança geradas pelo processo de controle de erros; e
• Tempo para solução de problemas x tempo estimado.
Considerações sobre o escopo do trabalho
Buscar-se-á então descrever uma aplicação, que possibilite catalogar e documentar os
problemas, erros conhecidos, e ações pró-ativas do departamento de TI de uma organização.
Esta aplicação deverá dar suporte a todo o ciclo de vida de um problema/erro (i.e., incidente,
problema, erro conhecido, solicitação de mudança, liberação), e possibilitar a retirada de
informações gerenciais (KPIs).
Possibilitar que o próprio cliente execute pesquisas sobre os erros mais freqüentes, pode
frear o crescimento de incidentes, desafogando a GI e possibilitando uma melhor documentação dos
novos chamados, logo, a investigação e diagnóstico dos problemas melhoram (privilegiando-se
desta documentação) e aumenta a qualidade do serviço prestado.
2.1.10 Considerações
Apesar da consciência, e constante avanço ao longo dos anos na procura de modelos que
suporte processos bem documentados de entrega de serviço, como os consolidados modelos COSO,
COBIT e ITIL, a maioria dos setores de Tecnologia da Informação das empresas apenas mantêm “a
cabeça de seus colaboradores acima d'água”.
36
Isso mostra a realidade na frase de Michiel Berkhout: “entre os desafios dos setores de
tecnologia, devem estar o mapeamento pró-ativo dos problemas a serem enfrentados, a fim de
desenvolver uma gestão sistemática e evolutiva, não apenas atendendo reativamente as solicitações
dos demais colaboradores da instituição, os ditos clientes internos” (BERKHOUT et. al., 2000).
Acredita-se que dificilmente é possível encontrar departamentos de TI com medidas pró-
ativas visando à qualidade na entrega de serviços suportados por aplicações que contemplem os
requisitos funcionais de modelos de qualidade.
Este trabalho tem como objetivo o desenvolvimento de uma aplicação web que contemple o
modelo ITIL de Gerenciamento de Problemas que busque agregar valor ao negócio da instituição e
qualidade no serviço prestado pela área de TI.
Os requisitos não funcionais que darão suporte à aplicação serão avaliados de acordo com o
levantamento bibliográfico feito na Seção 2.3, e descritos juntamente com o Capítulo 3 do projeto
deste Trabalho de Conclusão de Curso.
2.2 GESTÃO DO CONHECIMENTO
2.2.1 Introdução
Esta seção descreve o desafio de estruturar o conhecimento dos colaboradores em uma base
de dados, a fim de permitir o ganho do conhecimento organizacional.
A gestão do conhecimento envolve, com sistematização e transparência, uma troca crescente
de conhecimentos, entre as pessoas nas organizações, agregando valor aos processos de trabalho
(MATTA, 2002 appud STRAUSS, 2004).
2.2.2 Capital Intelectual
O Capital Intelectual é todo o conhecimento consolidado dentre os colaboradores de uma
organização, e possui três vertentes: capital humano, capital estrutural e capital do cliente
(STEWART, 1998).
37
Capital humano
O capital humano são os conhecimentos e as competências dos indivíduos da organização,
mas é necessário que este conhecimento seja desenvolvido e manipulado por todos os colaboradores
(STRAUSS, 2004).
Esse conhecimento cresce à medida que se desenvolvem idéias criativas através do
entendimento dos colaboradores: quanto mais os colaboradores tem conhecimento sobre o negócio
da empresa, maior o capital humano desta (STEWART, 1998).
Capital estrutural
O capital estrutural é a sinergia entre o conhecimento dos colaboradores, ou seja, é a
utilização do capital humano para gerar valor ao negócio da organização. São conhecimentos e
competências coletivas (STRAUSS, 2004).
Capital do Cliente
O capital do cliente é o valor adquirido nas relações com os clientes, e é neste ponto onde o
capital intelectual da empresa torna-se um diferencial financeiro (ibidem).
2.2.3 Conhecimento Organizacional
O conhecimento organizacional é advindo da capacidade da organização em identificar seu
capital intelectual e seus ativos intangíveis (i.e., conhecimentos que a organização consegue agrupar
em função de seus funcionários e colaboradores, sendo conhecido também como capital
intelectual).
Os conceitos e características do conhecimento organizacional são (Figura 15): dados,
informações, conhecimento e experiência/sabedoria (STRAUSS, 2004).
38
Figura 15. Níveis do conhecimento.
Retirado de: Strauss (2004), Figura 2.
Os dados e informações são de fácil estruturação e armazenamento, e a TI já os trata
eficazmente. Já o conhecimento, por suas características, é de difícil estruturação, pois está na
cabeça das pessoas (DAVENPORT; PRUSAK, 1998).
2.2.4 Criação/Codificação do Conhecimento
A criação do conhecimento organizacional é uma interação contínua e dinâmica entre o
conhecimento tácito (i.e., o conhecimento tácito é pessoal, específico ao contexto) e o
conhecimento explícito (i.e., aquele transmissível em linguagem formal e sistemática, que pode ser
codificado) (NONAKA; TAKEUCHI, 1997).
Para ser utilizado pela organização como um todo, o conhecimento compartilhado deve se
tornar explícito. O conhecimento tácito do indivíduo é a base da criação do conhecimento
organizacional, e é ampliado para toda organização através dos quatro modos de conversão, o que
os autores chamam de "espiral do conhecimento" (STRAUSS, 2004).
A construção do conhecimento organizacional apresenta cinco fases conforme Tabela 5
(NONAKA; TAKEUCHI, 1997):
39
Tabela 5. Fases da construção do conhecimento organizacional.
Fase Descrição Compartilhamento do conhecimento tácito
Com a socialização o conhecimento tácito criado pelo indivíduo é compartilhado com todos.
Criação de conceitos A externalização (i.e., processo articulado de transformação do conhecimento tácito subjetivo em conhecimento explícito) ajuda na criação de novos conceitos obtidos na fase anterior. Nesta fase os conhecimentos tácitos que o grupo obteve na fase anterior são convertidos em conhecimento explícito na forma de conceitos e modelos
Justificação de conceitos
A organização decide se os conceitos criados na fase anterior têm validade ou utilidade para ela ou para a sociedade.
Construção de um arquétipo
O conceito já justificado é convertido em algo tangível, concreto. Pode ser um protótipo de um produto ou um modelo de procedimentos operacionais
Difusão interativa do conhecimento
O conceito criado, justificado e transformado num modelo passará por novos ciclos de criação, tornando possível a revitalização do conhecimento e evitando o seu envelhecimento.
Fonte: Adaptado de Strauss (2004).
Já a codificação, para ser bem sucedida na organização, deve: decidir a que objetivos o
conhecimento codificado irá servir, ser capaz de identificar o conhecimento em suas várias formas,
avaliá-lo segundo sua utilidade e adequação à sistematização e identificar um meio apropriado para
codificar e distribuí-la (STRAUSS, 2004).
2.2.5 TI e Gestão do Conhecimento
Embora a gestão do conhecimento seja muito mais que tecnologia aplicada, a sua utilização
torna muito mais explícita a recuperação dos dados.
A capacidade de interligar as pessoas e armazenar grandes massas de dados faz dos
computadores uma ótima ferramenta para compartilhar e transferir o conhecimento (DAVENPORT;
PRUSAK, 1998).
2.2.6 Considerações
A aquisição do conhecimento organizacional é uma tarefa muito árdua quando não
conscientizada entre os produtores de conhecimento, ou seja, os colaboradores.
40
Uma aplicação de apoio, com o intuito de auxiliar no atendimento dos clientes, deve
possibilitar a transferência de conhecimento e a transformação do conhecimento tácito em explícito,
através da confecção de manual (i.e., neste caso, as ficha de conhecimento).
2.3 SISTEMAS WEB
2.3.1 Introdução
Esta seção descreve o desafio deste Trabalho de Conclusão de Curso para um futuro
cientista da computação: procurar um fator tecnológico de destaque que seja merecedor de uma
pesquisa científica e que contribua para a comunidade computacional.
O desenvolvimento de um sistema Web é por si só um desafio que agrega várias tecnologias,
as quais serão detalhadas na Seção 2.3.2, mostrando padrões e tendências mundialmente
conhecidas.
A UML, forma proposta para documentação da aplicação, recomenda o desenvolvimento do
software em três camadas, mas normalmente a programação de um sistema Web utilizando PHP
(forma proposta neste trabalho) tende a ser estruturada através de um conjunto de pequenos scripts,
que por sua vez resolvem pequenas tarefas. Na Seção 2.3.3, será fundamentada a necessidade de
organização da programação em três camadas (Modelo, Visão e Controle).
2.3.2 Arquitetura de sistemas Web
Sistemas Web são sistemas que “rodam” em um servidor e são acessados, via um navegador
web, por um cliente. O maior diferencial é a facilidade de acesso, isto é, o sistema pode ser acessado
igualmente em qualquer lugar do mundo via WWW (World Wide Web).
41
Figura 16. Arquitetura de hardware de um sistema Web.
Para efetuar essa transação entre o cliente e o servidor, existe uma gama de soluções, que se
tornaram padrão de fato na Internet. Nas seções seguintes será mostrado cada um dessas soluções e
a sua importância para este trabalho.
Protocolo
O HTTP (HyperText Transfer Protocol) é um protocolo da camada de aplicação do modelo
OSI (Open Systems Interconnection) que define como dois programas devem interagir para troca de
mensagens pela WWW (NETWORK WORKING GROUP, 1999).
O lado cliente da aplicação envia requisições HTTP, a um servidor que deve
necessariamente estar aguardando uma solicitação. Esta requisição deverá conter: método de
requisição, Universal Resources Identifier (URI), a versão do protocolo, seguido por uma
mensagem do tipo Multiporpouse Internet Mail Extension (MIME) com modificadores da
requisição, informação do cliente, e possivelmente um corpo de conteúdo (NETWORK WORKING
GROUP, 1999).
42
Figura 17. Transação HTTP.
Fonte: WORLD WIDE WEB CONSORTIUM (2006).
O lado do servidor que estava aguardando por uma conexão, utiliza esta mesma conexão,
com um 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 (ibidem).
Servidor
O lado servidor é responsável pela aceitação das requisições, processamento das solicitações
e entrega das informações através de um serviço HTTP (um serviço que implementa o protocolo
HTTP).
Dentre os programas conhecidos como servidores, podemos citar os principais: Apache
HTTPD, Tomcat, Microsoft Internet Information Services (IIS), Xitami, Oracle Internet Application
Server (IAS).
Os programas citados acima por si só não são responsáveis por todas as interações
necessárias para a execução de um sistema Web no lado servidor, pois além de interagir com o
sistema operacional, lendo e escrevendo arquivos, precisam possibilitar a integração com uma
tecnologia de ativação que dará suporte à dinamicidade necessária.
43
Apache HTTPD
Para execução deste projeto, foi escolhido o Apache, o mais conhecido dos servidores da
Internet, responsável pela hospedagem de mais de 50% dos sites existentes na WWW. É uma
aplicação de domínio público, ou seja, um software livre, que foi desenvolvido a partir de 1995 e
perdura até hoje com auxílio de desenvolvedores do mundo todo (Apache Software Foundation,
2006).
Tecnologia de ativação
A tecnologia de ativação, conhecida por esse nome por ser um item ativado apenas quando
solicitado pelo serviço HTTP, é responsável pela grande parte da programação dos sistemas Web. É
nesse ambiente onde ficam as regras de negócio e por onde é feito o acesso ao banco de dados.
Atualmente existem inúmeras tecnologias de ativação para sistemas Web, dentre as quais se
pode citar: PHP HiperText Processor (PHP), acrônimo recursivo, Java Server Pages (JSP), Active
Server Pages (ASP) e ColdFusion (CFML).
A tecnologia de ativação é interpretada ou executada (quando compilada) no lado servidor,
impossibilitando o usuário de ter acesso ao código fonte que rege os negócios da aplicação. Apenas
o código utilizado para a construção da camada de visão será percebido pelo usuário (Seção 0).
PHP
O PHP é uma tecnologia de ativação de código fonte aberto, amplamente utilizada no
mundo inteiro, que mistura uma linguagem de programação com o HTML (BAKKEN et. al., 2004),
isto é, uma linguagem em que se pode misturar camadas de visão com a programação do negócio,
uma prática não muito elegante, porém muito adotada, o que faz o PHP ser uma das tecnologias de
ativação mais popular do mundo.
44
Figura 18. Exemplo de um script PHP.
Fonte: Bakken (2006).
O PHP tem suporte nativo de acesso a inúmeros bancos de dados, assim como suporte a
tecnologias que se tornaram tendência em sistemas Web (e.g., XML, DOM, SOAP).
Banco de dados
Banco de dados são estruturas organizadas a fim de armazenar informações, desde uma
simples lista de itens de supermercado, até milhões de registros de um banco internacional com
informações georreferenciadas das transações dos seus clientes.
Como as massas de dados são especialidades dos computadores, os bancos de dados
desempenham tarefa fundamental desde a entrada da era informatizada (MYSQL AB, 2006).
Pode-se citar alguns bancos de dados existentes no mercado: Oracle, Microsoft SQLServer,
MySQL, FireBird, PostgreSQL, cada um deles com seus prós e contras e tipos de licenças.
PostgreSQL
Para o desenvolvimento deste trabalho, optou-se pelo PostgreSQL, por ser um banco de
dados open source capaz de trabalhar com grandes volumes de dados e por ser suportado
nativamente pelo PHP.
PostgreSQL é um banco de dados relacional projetado para suportar grandes cargas de dados
e desenvolvido na Universidade da Califórnia pelo departamento de Ciência da Computação.
45
Dentre as suas funcionalidades e compatibilidades, pode-se citar (POSTGRESQL GLOBAL
DEVELOPMENT GROUP, 2006):
• Consultas complexas (e.g. sub-selects, joins, alter join) – compatível com SQL-92;
• Integridade relacional (e.g. foreign keys) e transacional (e.g. commit e rollbacks);
• Triggers / Procedures / Functions (i.e., programação dentro do banco de dados);
• Views;
• Controle de concorrência;
• Criação de tipos de dados (e.g. dados espaciais); e
• Outros itens indispensáveis de um bom banco de dados.
Cliente
Um cliente web, também conhecido como navegador, é um software que interpreta e
renderiza documentos fornecidos pelo servidor em informações visuais. Esses interpretadores
implementam padrões como HTML, Document Object Model (DOM) e CSS, além de acionar os
clientes dinâmicos quando um script embutido deve ser processado.
Dentre esses softwares, dois deles dominam o mercado: Microsoft Internet Explorer (96%) e
o FireFox (2%). Ambos implementam os padrões definidos pela World Wide Web Consortium
(W3C). Na minoria estão outros softwares como: Opera, Konqueror, Mozilla e assim por diante.
Os navegadores são responsáveis pelo envio de informações para o servidor através de
formulários, tornando possível a adição de informações nos sistemas web.
Cliente dinâmico
Um cliente dinâmico é a capacidade que os softwares-cliente têm de executar códigos
móveis, isto é, um algoritmo de uma determinada linguagem é embutido em um arquivo no
servidor, recebido e executado pelo cliente.
A tecnologia de scripts mais comum nos navegadores nos dias de hoje é o Javascript,
inicialmente chamada de LiveScript, tinha como principal funcionalidade a validação de formulários
ainda na máquina cliente, visto que o tempo despendido para envio de um formulário para sua
46
validação no lado servidor era muito grande (NETSCAPE COMMUNICATIONS
CORPORATION, 1999). Por questões de marketing com a chegada do Java passou-se a chamar-se
Javascript, porém não possui nenhuma ligação com o Java.
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 – páginas Web
carregadas anteriormente – ou interagir com páginas de quadros vizinhos (APPARAO, 1998).
O Asynchronous Javascript and XML (AJAX) tem se tornado uma tendência nas aplicações
Web, por se tratar de uma forma assíncrona do navegador interagir com o lado do servidor, ou seja,
não é necessário recarregar toda a aplicação, para verificar se há uma nova mudança no conteúdo.
O AJAX é a união de algumas tecnologias: intercâmbio (XML e XSLT), apresentação
(HTML e CSS), interação dinâmica (DOM) e recuperação assíncrona de dados (XMLHttpRequest)
(NETSCAPE COMMUNICATIONS CORPORATION, 1999).
Apresentação
Como citado anteriormente os navegadores implementam padrões para visualização das
aplicações Web. Dentre eles, os mais importantes da camada de apresentação são respectivamente
HTML e CSS.
HTML e CSS
Desenvolvido originalmente por Tim Berners-Lee durante seu trabalho no Centre Europeen
de Recherche Nucleaire (CERN) e popularizado pelo navegador Mosaic desenvolvido na National
Center for Supercomputing Applications (NCSA), o HTML explodiu com o crescimento da Web na
década de 90. 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; HORS; JACOBS, 1999).
A busca incessante por um padrão compreendido por todos os navegadores é indiscutível.
Caso contrário, existe um risco inerente de que a Web se torne um mundo proprietário de formatos
incompatíveis, diminuindo o potencial comercial (ibidem).
O HTML possibilita algumas das principais funções das aplicações Web, pois é com ele que
um navegador é capaz de:
47
• Renderizar formulários para submissão de dados;
• Renderizar listagem de apresentação de dados;
• Renderizar tabelas;
• Renderizar apresentação de gráficos (tabelas e imagens); e
• Ligar páginas umas com as outras através de um único clique.
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
facilmente transportados para qualquer lugar do mundo. Isso 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; HORS; JACOBS, 1999).
O HTML possibilita ainda a inclusão digital, proporcionando apresentação por forma de
áudio, sem comprometer a apresentação visual.
O design de uma página pode ser simplificado quando se utiliza os Styles Sheets, livrando o
HTML da responsabilidade visual da aplicação Web. Os Styles Sheets podem ser adicionados junto
ao corpo do HTML ou em folhas de estilos separadas, dividindo assim mais uma vez o conteúdo da
apresentação, o CSS facilita a manutenção e autoria de sistemas Web (LIE; BOS, 1999).
2.3.3 Programação em três camadas
Inicialmente concebido para utilização na Plataforma Smalltalk na década de 70, hoje é um
dos padrões mais utilizados e de grande relevância na área de engenharia de software. Um padrão
de arquitetura de aplicações que visa separar a lógica de negócios (M), da interface do usuário (V) e
do fluxo da aplicação (C), permitindo que a mesma lógica de negócios possa ser acessada e
visualizada por várias interfaces.
A camada de visão (V) representa as relações entre os atores (mundo externo) e o sistema,
esses objetos traduzem os eventos gerados por um ator em eventos relevantes ao sistema.
48
A camada de controle (C) representa a lógica do caso do uso e coordena as outras classes,
utilizada para separar as classes de interface das classes da lógica do negócio. Também é
responsável pela lógica de execução correspondente a um caso de uso.
A camada de domínio (M) são classes básicas do negócio, esta camada que gerencia as
informações que o sistema necessita para fornecer a funcionalidade requerida. Nelas são
encapsuladas o conhecimento do negócio. Na maioria das vezes, classes da entidade (i.e., domínio),
são as classes persistentes que podem ser usadas para gerar diretamente o esquema da base de
dados.
Figura 19. Compatibilidade entre MVC e UML.
A implementação de MVC é completamente voltada à programação Orientada a Objeto, e
totalmente compatível com a UML (Figura 19). Pode-se citar alguns framework (i.e., aplicação
semi-completa reutilizável que, quando especializada, produz aplicações personalizadas) que
implementam o MVC: Jakarta Struts, JavaServer Faces, Symfony, entre outros.
SYMFONY
Symfony é a junção de vários projetos de software livre formando um framework para
construção de aplicações web completo para PHP5, orientado a objetos e baseado no modelo MVC,
que permite a separação das regras do negócio, da camada de controle e da apresentação final para o
49
usuário em uma aplicação web (POTENCIER et. al., 2006), conforme proposto para a
implementação desta aplicação do TCC.
2.3.4 Considerações
As aplicações web são compostas por uma grande quantidade de artefatos e soluções, muitas
destas já se tornaram um padrão de fato na internet, outras ‘caminham’ a tornar-se. Cada vez mais a
assincronidade das aplicações tendem a aumentar, e juntamente com o suporte a múltiplos usuários,
arquitetura transacional assíncrona e com potencial para múltiplas camadas, estigmatizar um
modelo diferente do convencional de desenvolvimento standalone (i.e., aplicações isoladas).
Assim como o ITIL, todos os softwares escolhidos para dar suporte à aplicação deste TCC,
são de domínio público, não gerando custo de produção e licenciamento da aplicação e aumentando
a futura interoperabilidade e continuidade da aplicação. Outro fator que contribui com a
continuidade é a programação em 3 camadas, possibilitando uma melhor definição de projeto e
divisão de trabalho.
3 PROJETO
Nesta etapa do projeto, confecciona-se o documento de modelagem de negócio, que tem o
objetivo de mapear as tarefas e atividades a serem atendidas por um software. Assim, entende-se
por tarefas o resultado final que se deseja alcançar com a utilização de um sistema (o que deve ser
feito), e por atividades, os meios necessários para a realização de uma tarefa (como deve ser feito).
As principais tarefas e atividades levantadas pela análise serão dispostas neste capítulo. As
demais serão itens do DOCUMENTO DE ESPECIFICAÇÃO DE REQUISITOS E CASOS DE
USO (Apêndice B).
A modelagem será desenvolvida segundo a notação UML, com artefatos que possibilitam
que o cliente tenha entendimento de como será implementado o software e, ao mesmo tempo,
auxiliam a equipe de desenvolvimento a compreender o que deverá ser feito. Os artefatos gerados
nesta etapa são:
1. Requisitos: os requisitos são orações dissertativas que indicam funções e comportamento
do sistema a ser desenvolvido (tarefas). Essas orações devem ser curtas, claras e
objetivas, possibilitando que, após a implementação do sistema, possa ser avaliado o
cumprimento de cada requisito separadamente;
2. Regras de negócio: as regras de negócio têm por objetivo detalhar necessidades
referentes aos requisitos do sistema (atividades). Exemplo: "O CPF do usuário deverá
ser digitado sem a utilização de pontos e traços";
3. Casos de Uso: este modelo é a descrição operacional de como o sistema será utilizado.
Ele descreve as atividades de maneira clara, utilizando um vocabulário através do qual o
usuário do sistema e a equipe de desenvolvimento possam facilmente entender os fluxos
(CANTOR, 1998). Cada Caso de Uso deve ter ao menos um ator envolvido que interaja
com o sistema, buscando um resultado observável de valor. Para dar sustentação gráfica
dos Casos de Uso, serão utilizados protótipos de tela; e
4. Diagrama de Classe: o diagrama representa coisas do mundo real, e não componentes de
software, ou seja, não são modelos de projeto de software. Cria e relaciona termos os
quais formam um vocabulário que ajuda na comunicação entre os Desenvolvedores e
Clientes (usuários) (COSTA NETO, 2006).
51
Após a modelagem UML, será reavaliado o cronograma do TCC II apresentado na pré-
proposta deste Trabalho de Conclusão de Curso, encerrando assim o presente capítulo.
3.1 REQUISITOS
3.1.1 Funcionais
Requisitos extraídos do ITIL
O modelo ITIL para gerenciamento de serviços de TI é divido em cinco livros. Este trabalho
está delimitado para o livro Service Support, com ênfase no Gerenciamento de Problemas (Seção
2.1.4). É deste Capítulo que serão extraídos os requisitos funcionais.
Service Desk
O Service Desk e seus derivados (e.g. Help Desk, Call Center, entre outros) são a função
definida neste capítulo do ITIL Service Support no ambiente em que será empregada uma aplicação
para gerenciamento de problema. O Service Desk será com certeza a fonte da interação humana com
a aplicação.
• O sistema deverá permitir o cadastro de usuários por tipo de atuação.
Gerenciamento de problemas (controle de problemas): identificação e registro
• O sistema deverá permitir o cadastro de problemas; e
• O sistema deverá permitir o cadastro/edição das palavras-chave de um problema.
Gerenciamento de problemas (controle de problemas): classificação
• O sistema deverá permitir a classificação, definição de prioridade e urgência de um
problema; e
• O sistema deverá permitir o cadastro de categoria de um problema;
Gerenciamento de problemas (controle de problemas): investigação e diagnóstico
• O sistema deverá permitir o cadastro do diagnóstico de um problema; e
• O sistema deverá permitir o cadastro de possíveis causas de um problema.
52
Gerenciamento de problemas (controle de erros): identificação e registro
• O sistema deverá permitir o cadastro de um erro conhecido; e
• O sistema deverá permitir o cadastro/edição das palavras-chave de um erro.
Gerenciamento de problemas (controle de erros): avaliando erros
• O sistema deverá permitir o cadastro de anotações de um erro.
Gerenciamento de problemas (controle de erros): registro de resolução
• O sistema deverá permitir o cadastro de um workaround de um erro.
Gerenciamento de problemas (controle de erros): fechamento de problema/erro
• O sistema deverá permitir o fechamento de um erro conhecido e seu problema atribuído; e
• O sistema deverá permitir a geração/impressão de uma solicitação de mudança.
Gerenciamento de problemas: gerência pró-ativa
• O sistema deverá disponibilizar uma lista de erros freqüentes (FAQ).
Gerenciamento de problemas (métricas e gerenciamento):
• O sistema deverá disponibilizar uma listagem dos problemas cadastrados;
• O sistema deverá disponibilizar uma listagem dos erros cadastrados;
• O sistema deverá permitir a geração de relatórios com o número de problemas resolvidos
por período;
• O sistema deverá permitir a geração de relatórios com o número de incidentes por problema;
• O sistema deverá permitir a geração de relatórios com a média de tempo gasto para cada
etapa de um problema/erro;
• O sistema deverá permitir a geração de relatórios com a listagem de RFC por período; e
• O sistema deverá permitir a geração de relatórios com o tempo médio de resolução dos
problemas versus o tempo médio previsto para resolução dos mesmos.
53
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.
Essas ações ativam recursos definidos em outros processos do ITIL (e.g. Gerenciamento de
problemas). Fica estabelecido que as ações dessa etapa podem ser representadas exclusivamente
pelo registro de atividades no incidente, não necessitando da descrição de requisitos funcionais
específicos (BERKHOUT et. al., 2000).
• O sistema deverá permitir a consulta de problemas e erros conhecidos.
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.
Essas 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 dessa etapa podem ser
representadas exclusivamente pelo registro de atividades no incidente, não necessitando da
descrição de requisitos funcionais específicos (BERKHOUT et. al., 2000).
• O sistema deverá permitir a atualização de problemas, tornando-os erros conhecidos;
• O sistema deverá permitir a atualização de problemas, cadastrando um novo código de
incidente a eles ligado, indicando assim a reincidência do problema; e
• O sistema deverá permitir a atualização de erros conhecidos, cadastrando um novo código
de incidente a eles ligado, indicando assim a reincidência do erro.
3.1.2 Não-funcionais
Os requisitos não-funcionais definem comportamentos do sistema. Exemplo: "O sistema
deverá ser desenvolvido conforme padrão W3C". Esses requisitos podem ainda ser divididos em
seções: usabilidade, desempenho, segurança, implementação, conformidade, entre outros, e assim
estarão dispostos no Apêndice B.
3.2 REGRAS DE NEGÓCIO
Cada regra de negócio deverá estar associada a um requisito funcional, perfazendo as
necessidades e suplementando os atributos e conformidades necessárias para a realização das
atividades.
54
Service Desk
• As opções de cadastro, edição e tarefas deverão ser feitas por tipo de usuário;
• Um usuário poderá ter mais de um tipo;
• Os usuários utilizarão um par de login e senha para autenticação no sistema; e
• Os logins de usuários deverão ter no mínimo seis caracteres.
Gerenciamento de problemas (controle de problemas): identificação e registro
• As palavras-chave (keywords) deverão possuir índice de importância definidas pelo usuário.
Gerenciamento de problemas (controle de problemas): classificação
• As prioridades de um problema deverão possuir uma escala de horas para resolução; e
• As categorias de problema deverão ter até cinco níveis hierárquicos;
Gerenciamento de problemas (controle de problemas): investigação e diagnóstico
• As causas de um problema deverão ter até cinco níveis hierárquicos.
Gerenciamento de problemas (controle de erros): identificação e registro
• Um erro conhecido deverá ter no mínimo um problema associado;
• As palavras-chave (keywords) deverão possuir índice de importância definido pelo usuário.
Gerenciamento de problemas (controle de erros): avaliando erros
• Todo o escalonamento de um erro deve ser alertado por e-mail.
Gerenciamento de problemas (controle de erros): registro de resolução
• Todo erro deverá possuir uma solução paliativa cadastrada.
Gerenciamento de problemas (controle de erros): fechamento de problema/erro
• O sistema deverá atualizar a classificação dos incidentes ligados a um problema resolvido
para “Pendência Pós-Mudança (PPM)”; e
• A solicitação de mudança deverá conter a descrição do problema/erro.
55
Gerenciamento de problemas: gerência pró-ativa
• A lista de erros freqüentes deverá ser disposta também aos usuários/clientes.
Gerenciamento de problemas (métricas e gerenciamento):
• A listagem de problemas deverá ser ordenada por ordem de status e prioridade.
Gerenciamento de incidentes: investigação e diagnóstico
• A consulta de erros deverá ser ranqueada de acordo com a Tabela 6 ou poderá ter sua
configuração alterada pelo administrador do sistema.
Tabela 6. Tabela para ranque de apresentação das fichas de conhecimento.
Itens Pontos
Título 5 Pontos
Palavras-chave 4 Pontos + 0.3 * Índice da palavra
Descrição de abertura 3 Pontos
Frase interrogativa 3 Pontos
Software afetado 2 Pontos
Software não afetado -1 Pontos
Ranque (feedback dos usuários) Ranque * 0.3 Pontos
Demais itens 1 Ponto
O ranque das fichas de conhecimento deverá ser calculado durante a utilização do módulo
de pesquisa. O termo indicado pelo usuário na caixa de pesquisa deverá ser confrontado com cada
um dos itens da primeira coluna da Tabela 6. Após todas as comparações, as fichas de
conhecimento com maior ‘ranque’ (i.e., hint de pesquisa, semelhança com dados sobre
problemas/erros) serão apresentadas ao usuário.
3.3 CASOS DE USO
A aplicação proposta será utilizada para registro, monitoramento, controle de propriedade,
revisão, análise de desempenho da equipe e revisão do processo de Gerenciamento de Problemas.
Nesta seção serão apresentados somente os mais importantes deles, os demais estarão no Apêndice
B.
56
Para apresentação nesta Seção julga-se necessário apenas os Casos de Uso que envolvem a
abertura e fechamento de problemas/erro e a visualização da ficha de conhecimento gerada por um
erro conhecido.
• Cadastro de Problemas (Figura 20);
• Cadastro de Erros (Figura 20);
• Fechamento de um problema/erro (Figura 20); e
• Detalhamento de Erros (Figura 21).
Figura 20. Caso de Uso do módulo de cadastro e fechamento de Problemas/Erros.
UC1.01 – Cadastro de Problema
Pré-requisito: Um usuário Help Desk, ou superior, deverá estar autenticado no sistema.
Pós-condição: Um novo problema será cadastrado na base de dados.
Tarefa: O usuário poderá descrever um problema com informações textuais, palavras chaves
(keywords), possíveis causas e CIs afetados. Através deste cadastro os atendentes de nível superior,
poderão realizar o devido fichamento do problema e realizar medidas para transformá-lo num erro
conhecido.
57
UC1.02 – Cadastro de Erros
Pré-requisito: Um usuário Atendente de Nível N, ou superior, deverá estar autenticado no
sistema. A solução paliativa de um problema deverá ter sido encontrada.
Pós-condição: Um problema passará a ter uma solução paliativa e conseqüentemente tornar-
se um erro conhecido.
Tarefa: O usuário deverá identificar o problema a e ser “solucionado paliativamente”. Após
isso deverá informar a solução, revisar a classificação, palavras chaves (keywords), CIs que afeta,
causas, e liberá-lo para visualização como erro conhecido.
Essa tarefa precede a tarefa de solicitação de mudança (RFC), uma vez que todas as RFCs
devem ter um erro conhecido associado.
UC1.07 – Fechamento de um erro / problema
Pré-requisito: Um usuário Atendente de Nível N, ou superior, deverá estar autenticado no
sistema. Uma RFC terá sido cadastrada e liberada.
Pós-condição: Um erro conhecido deixar de existir.
Tarefa: O usuário deverá identificar a solicitação de mudança e marcá-la como entregue. O
sistema deverá finalizar o erro conhecido, o problema, e alterar o status dos incidentes associados
para “Pendência Pós-Mudança”.
58
Figura 21. Casos de Uso do módulo de visualização de conhecimento.
UC2.03 – Buscar por problemas / erros
Pré-condição: ter acesso ao sistema. Esta tarefa pode ser efetuada também por clientes,
então, não é necessário estar autenticado para executá-la.
Pós-condição: uma lista de fichas de conhecimento sobre problemas e erros será visualizada.
E, conseqüentemente, uma ficha de conhecimento.
Tarefa: O usuário deverá indicar no campo de pesquisa uma “frase de pesquisa” (pode ser
apenas uma palavra). O sistema deverá listar as fichas de conhecimento conforme ranque
apresentado na RN5.01. O usuário poderá clicar sobre o código da ficha de conhecimento e
visualizar todos os dados cadastrados sobre os incidentes, problema, erro conhecido, rfc e liberação.
59
3.4 DIAGRAMA DE CLASSE
O modelo de classes de domínio do projeto (Figura 22) apresenta um modelo conceitual das
entidades envolvidas no sistema, apresentando conceitos importantes do domínio do problema (do
ponto de vista do analista).
Figura 22. Diagrama de Classe Conceitual da Aplicação.
4 DESENVOLVIMENTO
Nesta etapa do TCC, são confeccionados todos os códigos fontes da aplicação descrita na
etapa de projeto. A etapa de projeto serve principalmente para nortear o desenvolvimento e
apresentar ao cliente (no caso a banca avaliadora) o resultado esperado da aplicação.
Nas próximas seções está descrito como foi implementada a aplicação e a forma de
utilização das ferramentas que deram suporte ao desenvolvimento: (i) modelagem de entidades e
relacionamentos; e (ii) framework de programação.
Por fim, neste capítulo serão apresentados os principais módulos do sistema previstos na
Etapa de Projeto (Capítulo 3) e as dificuldades encontradas durante o desenvolvimento.
4.1 MODELAGEM DE ENTIDADE E RELACIONAMENTO
O MER (Modelo Entidade-Relacionamento) é uma percepção de um mundo real que
consiste em uma coleção de objetos básicos chamados entidades, e seus relacionamentos. Uma
entidade é um objeto que é distinguível de outro por um conjunto específico de atributos
(SANCHES, 2007).
Para desenvolvimento do MER foi utilizado o DBDesigner4, uma ferramenta open source,
inicialmente projetada para trabalhar com o banco de dados MySQL (ZINNER, Michael., 2007),
adaptada pelo LCA (Laboratório de Computação Aplicada) para gerar scripts compatíveis com o
PostgreSQL (banco de dados escolhido nos requisitos não funcionais da aplicação).
A utilização desta ferramenta dá-se pela facilidade de utilização, através de uma interface
intuitiva e personalizável. A Figura 23 apresenta a interface principal da aplicação, com um
exemplo simples de entidades e relacionamentos.
61
Figura 23. Screenshot da área de trabalho do DBDesigner4.
Com base no diagrama de classes conceituais, apresentado na Figura 22 e dados auxiliares
necessários para o funcionamento da aplicação, foi elaborado o presente MER (Figura 24).
É possível visualizar no MER o escopo das entidades que fazem parte da aplicação proposta
e as entidades provenientes de outros processos do ITIL como, por exemplo, o Gerenciamento de
Incidentes (e.g., entidade “incidentes”) e o Gerenciamento de Mudanças (e.g., entidades “rfc” e
“liberações”).
62
Figura 24. MER da aplicação.
63
4.2 CRIAÇÃO DA BASE DE DADOS
Na criação e manutenção da base de dados, vale destacar dois pontos: (i) ferramenta
utilizada e (ii) padrão de nomenclaturas utilizado.
4.2.1 PgAdmin III
O PgAdmin III, escolhido para a criação e manutenção da base de dados, é o software open
source mais popular para a manutenção de bancos de dados PostgreSQL (PgAdmin III, 2007), com
versões para inúmeros sistemas operacionais. A utilização deste cliente de acesso ao banco de dados
pode ser visualizada na Figura 25.
Figura 25. Interface do PgAdmin III.
Esta ferramenta possibilita a execução de scripts SQL através de uma interface de
manipulação de textos, conforme apresentado na Figura 25. Nesta interface é carregado o script
gerado na ferramenta de criação do MER, o DBDesigner4.
64
Este script gerado pela ferramenta DBDesigner4 (Apêndice C) obedece algumas
padronizações para nome de entidades e seus atributos, descritos na Seção 4.2.2.
4.2.2 Padrão de nomenclaturas
O padrão utilizado para nomenclaturas é o mesmo utilizado pelo sistema de informação do
PREPS (Programa Nacional de Rastreamento de Embarcações Pesqueiras por Satélite), ambiente
onde será testado e validado o estudo de caso deste TCC.
Este padrão foi desenvolvido pelo LCA e visa facilitar o desenvolvimento das aplicações,
especificando no nome dos atributos o seu tipo e/ou utilização na aplicação (LCA, 2006). Neste
projeto de TCC, este padrão foi seguido para a definição dos nomes dos atributos das entidades.
Os nomes das entidades visam um alinhamento com o negócio da aplicação proposta,
facilitando uma possível integração e/ou desenvolvimento de outros módulos que contemplem os
demais processos do ITIL (mais detalhes no Capítulo 5).
4.3 FRAMEWORK DE DESENVOLVIMENTO
No desenvolvimento de software os frameworks são uma estrutura de suporte definida que
possibilita o desenvolvimento de outra aplicação, poupando o programador de atentar-se à
programação de baixo nível, liberando-o para preocupar-se com as regras de negócio (FAYAD, E;
SCHIMIDT, C; JOHNSON, E, 1999).
Os frameworks ganharam espaço à medida que o tempo para desenvolvimento de uma
solução é cada vez mais curto, a utilização de um framework é ideal para aumentar a velocidade de
implementação e padronização de código, garantindo assim maior grau de paralelismo e facilitando
o desenvolvimento com baixo desacoplamento (MUNDO OO, 2006 appud EVARISTO JR, 2006).
O framework escolhido para desenvolvimento deste projeto de TCC é o Symfony, entre suas
principais características (POTENCIER. F, 2006), pode-se destacar: (i) totalmente compatível com
PHP5; (ii) Orientado a Objetos; (iii) Programação em 3 camadas (modelo, visão e controle); e (iv)
utilização AJAX. Além disso, atende a todos os requisitos não-funcionais definidos na etapa de
projeto (Capítulo 3).
65
4.3.1 Framework Symfony
O Symfony, conforme citado na Seção 2.3.3, utiliza o modelo de desenvolvimento em 3
camadas: (i) modelo, (ii) controle e (iii) visão.
Modelo
A camada de modelo é responsável pela interação e persistência com o banco de dados,
realizando consultas, inserções e atualizações. Para esta camada de modelo o Symfony utiliza o
projeto Propel (Figura 26).
Figura 26. Estrutura de utilização do PROPEL.
Adaptado de: PROPEL PROJECT (2007).
A utilização do Propel visa às seguintes funcionalidades (PROPEL PROJECT, 2007)
(Figura 27):
• Codificação de objetos persistentes: codifica classes em PHP 5.x formando a camada
de persistência de dados;
• Camada de modelo: para desenvolvimento de aplicação conforme o conceito MVC;
• Segurança da aplicação: evita SQL injections, força tipos de variáveis, controle
transacional, etc.;
66
• Aplicações portáveis: através do seu subprojeto Creole que abstrai a utilização de
diferentes bases de dados; e
• É projetado para possibilitar extensões: permitindo que seus métodos de comunicação
com o banco de dados sejam sobre escritos conforme as necessidades da aplicação.
Figura 27. Exemplo de código, gerado pelo Symfony, da camada de modelo.
Controle
Na camada de controle estão as regras de negócio e controle do fluxo de telas da aplicação.
É, por exemplo, nesta camada que deverá ser indicada a página de apresentação dos erros de
validação em um formulário (Figura 28).
67
Figura 28. Exemplo de código da camada de controle.
Visão
Na camada de visão é onde são gerados os códigos HTML que irão ser interpretados pelo
navegador web do cliente.
A utilização de scripts auxiliares (i.e., bibliotecas de apoio) e das próprias funcionalidades
do framework Symfony, tornam a produção dos códigos da camada de visão simples e de rápido
desenvolvimento.
Utilizando o conceito de listagens, detalhamento e cadastro, dividiu-se a produção dos
códigos fontes da aplicação nestes itens. Na Figura 29 é possível visualizar o código necessário para
a produção da Listagem de Itens de Configuração (e.g., Ativos de TI, softwares, etc.) que utiliza o
script auxiliar para a geração de tabelas.
68
Figura 29. Exemplo de código da camada de visão.
4.4 SISTEMA
O CPItil, denominação dada ao sistema, foi desenvolvido conforme a especificação da etapa
de projeto (Capítulo 3) e busca explorar ao máximo as potencialidades do framework Symfony no
quesito de automatização de código, separação de layout e negócio, validações, etc.
O primeiro passo para o desenvolvimento da aplicação foi a estruturação do layout e
construção de bibliotecas de apoio que pudessem agilizar a produção dos códigos fontes. A classe
apresentada na Figura 30, visa auxiliar a programação dos scripts da camada de visão constituídos
por uma listagem de dados (i.e., tabelas).
69
Figura 30. Código da tabela.class.php.
No Capítulo 5 deste TCC serão abordados os testes e resultados obtidos com o uso da
aplicação, demonstrando a utilização dos seus principais módulos.
4.5 DIFICULDADES ENCONTRADAS
Na fase de desenvolvimento foram encontradas algumas dificuldades relacionadas à
utilização do framework. A cada dificuldade encontrada, foram realizados estudos para resolvê-las
de maneira correta:
70
• Estudo detalhado das metodologias de desenvolvimento do framework Symfony
para construção do sistema: para isso foi necessário estudar o tutorial da ferramenta, e
participar do seminário interno de desenvolvimento no LCA;
• Controle de acesso ao sistema de programas por nível de acesso de usuário: buscou-
se no framework a melhor forma de montagem dos menus e bloqueio a scripts não
autorizados a determinados usuários. Este bloqueio dá-se manipulando arquivos de
configuração dos módulos gerados pelo próprio Symfony;
• Inclusão (include) de arquivos externos (biblioteca de apoio) ao script: a exemplo da
classe demonstrada na Figura 30, o Symfony permite a configuração de classes que são
incluídas automaticamente (i.e., autoload) no momento da execução, de forma a
padronizar a organização dos códigos fontes da aplicação, facilitando assim a
manutenção do código; e
• Validação dos campos dos formulários de manipulação de dados: o framework
possibilita realizar automaticamente a validação dos formulários de manipulação de
dados através da configuração dos campos e de seus validadores (conforme Figura 31).
Figura 31. Exemplo de validação de campos pelo framework.
4.6 TESTES E VALIDAÇÃO
Para validação e testes da aplicação, utilizou-se um servidor, onde os usuários finais da
aplicação pudessem ter acesso. Alguns erros de implementação foram encontrados e rapidamente
corrigidos.
No Apêndice D deste TCC está o depoimento do primeiro usuário a utilizar o sistema. A
este usuário foi concedido direito de acesso a todas as funções e a missão de realizar as tarefas
necessárias de preparação do ambiente (e.g., cadastros basilares, incidentes passados), conforme
indicado na Seção 5.1.
5 RESULTADOS E DISCUSSÕES
A utilização e teste da aplicação proposta tiveram como ambiente o Laboratório de
Computação Aplicada (LCA), na Universidade do Vale do Itajaí (UNIVALI), gerenciando os
problemas enfrentados no desenvolvimento, instalação, manutenção, suporte a usuários e
operacionalização do Sistema de Informação do Programa Nacional de Rastreamento de
Embarcações Pesqueiras por Satélite (PREPS).
O Sistema PREPS é um software do Governo Federal que está sendo desenvolvido e
mantido pelo LCA, através de um convênio entre Presidência da República, representada pela
Secretaria Especial de Aqüicultura e Pesca (SEAP), e a UNIVALI.
Considera-se como entrada para a gerência de problemas os incidentes (Seção 5.1.2), como
construção do legado os cadastros/manutenção dos problemas/erros (Seção 5.2) e como os
principais legados o FAQ (Seção 5.3.1) e as Fichas de Conhecimento (Seção 5.3.2).
5.1 PREPARAÇÃO DO AMBIENTE
Para dar início a utilização da aplicação, foi realizado o cadastro dos dados basilares (i.e.,
dados de suporte), ativos de TI (i.e., CIs, no caso o sistema e seus módulos) e incidentes que haviam
ocorridos anteriormente a data inicial de utilização.
Também foi realizada uma palestra de conscientização com os colaboradores, a fim de
informar a importância de estruturar o processo de suporte e entrega de serviços de TI, assim como
a importância de uma boa documentação na descrição dos problemas/erros e suas soluções
paliativas.
Nas próximas subseções veremos os primeiros passos após o desenvolvimento da aplicação,
(i) que possibilitaram a interação dos colaboradores com o sistema e (ii) que deram carga a eventos
ocorridos anteriormente a utilização do CPItil.
5.1.1 Cadastro de Usuário (dados basilares)
Para cadastro e manutenção dos usuários colaboradores (e.g., Service Desk, Call Center) foi
desenvolvido um módulo chamado de Service Desk, neste cadastro são contempladas as regras de
negócio estabelecidas pelo modelo ITIL (e.g., cadastro do(s) tipo(s) do usuário).
72
Na Figura 32 é possível visualizar a tela de listagem de usuários cadastrados no sistema,
dando ênfase aos tipos de cada usuário.
Figura 32. Tela de listagem de usuários.
Para testes e validação do sistema, os programadores/analistas do Sistema do PREPS que
prestam o serviço de suporte foram cadastrados como usuários da aplicação. Antes da utilização do
CPItil, cada um destes usuários somente prestavam suporte aos módulos em que eram especialistas,
muitas vezes postergando o atendimento de chamados (incidentes) pela ausência do
desenvolvedor/analista.
5.1.2 Cadastro de Incidentes (dados basilares)
Como visto na Seção 2.1.9, uma das entradas necessárias para o Gerenciamento de
Problemas é composta pelos dados relacionados ao Gerenciamento de Incidentes. Como o emprego
do CPItil foi realizado após os prévios atendimentos de chamados de
73
suporte/treinamento/problemas do Sistema do PREPS, estes foram documentados em arquivos
textos para posterior cadastramento na aplicação.
Como a gerência de incidentes não faz parte do escopo deste TCC, somente alguns dados
dos atendimentos de chamados foram levados em consideração, dados que fossem relevantes ao
Gerenciamento de Problemas, que pudessem auxiliar na identificação e diagnóstico dos problemas,
e até mesmo que facilitassem a transição de problemas para erros (Figura 33).
Figura 33. Tela de detalhamento de incidentes.
5.2 UTILIZAÇÃO
A utilização do CPItil tem como principais aspectos: cadastro de novos incidentes (Seção
5.1.2), cadastro/manutenção de problemas/erros, visualização de FAQ, Fichas de Conhecimento
(Seção 5.3) e obtenção de informações gerenciais.
Depois de distribuídas as senhas dentre os colaboradores, todo o atendimento a clientes do
Sistema do PREPS passou a ter como suporte o CPItil. A partir disto começou-se a inserir novos
incidentes, cadastrar problemas (Seção 5.2.1) e utilizar a base de conhecimento.
74
Também foram elencados colaboradores para exercerem a função da equipe de gerência de
problemas, com as tarefas de: cadastrar soluções paliativas aos problemas, tornando-os erros
conhecidos (Seção 5.2.2), finalizar erros, solicitar mudanças e estudar possíveis problemas (i.e.,
tornarem-se pró-ativos).
5.2.1 Cadastro de Problemas
O cadastro de problemas pode ser realizado em três momentos: (i) durante o atendimento de
um chamado, (ii) durante a investigação da base de incidentes pela Gerência de Problemas e (iii) na
descoberta de um possível gerador de incidentes.
Para atender esta demanda, o CPItil disponibiliza uma interface (Figura 34) para cadastro de
problemas, solicitando os dados referentes a investigação, descrição, causas prováveis, categoria,
ativos de TI envolvidos, palavras chaves e demais itens que possam auxiliar no resolução desse
problema.
75
Figura 34. Tela de cadastro de problemas.
76
Através deste cadastro de problemas, é que a Gerência de Problemas poderá solicitar as
mudanças e/ou cadastrar os erros conhecidos.
5.2.2 Cadastro de Erros
Os cadastros de erros conhecidos visam facilitar o atendimento em primeiro nível,
possibilitando que o cliente obtenha solução para suas dúvidas/dificuldades no momento que entrar
em contato com o departamento/setor de Tecnologia da Informação.
Em determinados casos o fechamento de um problema/erro é muito mais trabalhoso e
impactante no negócio do que os incidentes gerados, o que leva a Gerência de Problemas optar por
não finalizá-lo e sim manter uma solução de contorno (i.e., erro conhecido) cadastrada na base de
dados.
O cadastro/alteração de um erro deve conter a identificação do problema, sua solução
paliativa, identificações de tempo, resolução e indicador de renovação do processo de resolução
(i.e., renovação do conhecimento, revisão de processos).
77
Figura 35. Tela de cadastro de erros.
A Figura 35 ilustra a tela de cadastro de um erro conhecido, evidenciando os campos
necessários para cadastro e manutenção.
5.2.3 Informações gerenciais
Um sistema de informação deve ater-se as necessidades dos gestores, neste caso do gestor de
TI, proporcionando relatórios que auxiliem na tomada de decisão. Para isto o CPItil conta com um
módulo de relatórios, onde pode ser retirada informações como por exemplo: número de incidentes
por problemas, número de problemas por período, tempo médio de resolução de problemas,
listagem e detalhamento de RFCs.
78
Estas Key Performance Indicators (KPIs) visam auxiliar o gestor na visualização do
desempenho de sua equipe (e.g., gerência de problemas), informando através de tabelas e gráficos o
andamento das tarefas a serem realizadas.
Figura 36. Relatório de RFCs por período
A Figura 36 demonstra um relatório de quantas, e quais requisições de mudanças (Request
for Change - RFC) foram realizadas pela equipe de Gerência de Problemas em um determinado
período.
79
5.3 RESULTADOS
Já nas primeiras semanas de emprego do CPItil no âmbito do LCA, ficaram visíveis os
benefícios de tal aplicação, possibilitando o atendimento de suporte a incidentes recorrentes,
possuidores de problemas/erros identificados, por atendentes de primeiro nível, que procuravam
aplicar as soluções paliativas cadastradas.
Esta pesquisa pode ser executada por duas principias formas: o FAQ e as Fichas de
Conhecimentos, também conhecida como consulta a Knowledge Data Base (KDB). O CPItil não
obriga a autenticação do usuário ao sistema para efetuar tais pesquisas, possibilitando assim que os
próprios clientes tirem suas dúvidas.
5.3.1 FAQ
A estruturação do processo de atendimento possibilita a confecção de artefatos, que auxiliam
em outros atendimentos ou até mesmo que promovam o auto-atendimento. No caso das Frequently
Asked Questions (FAQ) é a possibilidade do auto-atendimento onde os clientes acessam o CPItil e
obtêm respostas através de simples questionamentos, como exemplificado a seguir:
A Figura 37 ilustra a utilização da FAQ, onde um cliente busca saber “O que é SOAP?”.
80
Figura 37. Tela de visualização das FAQs.
No CPItil, as FAQs são organizadas a partir dos erros conhecidos mais utilizados para a
resolução de chamados e das Fichas de Conhecimento com maior média de avaliação de
importância (i.e., feedback do usuário). Através de uma interface específica o administrador
configura quantas perguntas/respostas deverão estar disponíveis para acesso.
Realizou-se uma extensão da proposta inicial, incluída a geração do FAQ em Really Simple
Syndication (RSS) (i.e., tecnologia que permite a troca de conteúdo utilizando arquivos XML
81
padronizados), para que outros sistemas (e.g., Sistema do PREPS onde foi validada a aplicação)
possa obter o FAQ do CPItil.
5.3.2 Ficha de Conhecimento
As fichas de conhecimento são formadas por históricos e/ou detalhamento de
problemas/erros conhecidos. Nelas devem constar todas as informações pertinentes a: causas,
diagnóstico, módulos afetados, forma de resolução (caso tenha), data de revisão e outras
informações conforme a coluna TCC da Tabela 4.
A Figura 38 apresenta uma ficha de conhecimento relacionada ao incidente “Dificuldades no
Cadastro de Usuário”, este incidente é advindo do problema “Problema na máscara de validação do
e-mail”, que envolve o ativo de TI “Software > PREPS > Módulo Basilares > Cadastro de Usuário
> 0.7.5”.
Através desta ficha de conhecimento é possível identificar a maneira correta de executar o
cadastro de um usuário, assim como identificar os principais motivos de erros/dificuldade durante o
cadastro.
82
Figura 38. Ficha de conhecimento gerada pelo CPItil.
As Fichas de Conhecimento são a tentativa de transformar o conhecimento tácito dos
atendentes de suporte em conhecimento explícito do setor/organização de TI.
6 TRABALHOS FUTUROS
O processo de Gerenciamento de Problemas é apenas um passo que o profissional de TI
deve ter conhecimento para uma certificação ITIL, é também um dos passos para empresas que
almejam a obtenção da ISO 20.000.
Por isso, uma aplicação que auxilie no Gerenciamento de Problemas pode ser considerada
um módulo de um Enteprise Resource Planning (ERP) (i.e., sistema que engloba uma grande gama
de soluções para uma organização/departamento) para uma TI que visa o bom atendimento e
entrega de serviços aos seus clientes (internos e externos).
Como recomendações para trabalhos futuros a este TCC, têm-se o desenvolvimento e/ou
integração com aplicações que visam suprir as necessidades de outros processos do ITIL, como por
exemplo, o Gerenciamento de Incidentes, Gerenciamento de Mudanças, Gerenciamento de
Liberações, entre outros.
Acredita-se que a utilização do framework Symfony faz-se primordial neste ponto do
trabalho, visto que a facilidade da adaptação da aplicação para utilização de outros bancos de dados,
suporte a internacionalização (múltiplos idiomas), automatização de desenvolvimento, padronização
de código e organização bem definida, facilitam a integração com outros projetos de TCC, ou
aplicações baseadas na recomendação ITIL.
No âmbito do LCA, planeja-se expandir a utilização do software para os demais projetos que
necessitem de acompanhamento, padronizando assim o atendimento e construção de FAQ para as
aplicações.
Caso seja interesse da própria Universidade, é possível realizar a internalização do sistema
no seu setor de Gestão de Tecnologia da Informação, integrando com a solução de atendimento de
Incidente já utilizada.
7 CONCLUSÕES
O objetivo deste Trabalho de Conclusão de Curso (TCC) foi desenvolver, testar e validar
uma aplicação de apoio ao gerenciamento de problemas baseado na recomendação ITIL: o CPItil,
utilizando como base tecnologias open source e executada em ambiente web.
Para isto, na primeira fase deste TCC, buscou-se estudar o modelo de suporte a serviços do
ITIL, em específico a gerência de problemas, realizando um levantamento bibliográfico e obtendo
as principais regras de negócio presentes na aplicação. Esta etapa constitui a Seção 2.1 do Capítulo
2 deste documento.
Relacionando a Tecnologia da Informação (TI) como parte do negócio das instituições,
buscadora de novas soluções que possibilitem agregar valor e produzir conhecimento para as
organizações, realizou-se um estudo de Gestão do Conhecimento. Seção 2.2 do Capítulo 2 deste
documento.
Ainda na primeira fase, foram estudas as tecnologias, conceitos e paradigmas que envolvem
os sistemas para web, possibilitando delimitar a plataforma, os softwares base, as ferramentas
utilizadas no desenvolvimento e os requisitos não-funcionais da aplicação.
Buscando identificar na prática os conceitos estudados, realizou-se uma comparação com
soluções similares a aplicação proposta, levantando pontos de relevância e confrontando em uma
pesquisa com profissionais e clientes de departamentos/setores de TI.
Ao final da primeira fase, desenvolveu-se o Capítulo 3 e o Apêndice B deste documento,
que constituem na documentação em notação Unified Modeling Language (UML) da aplicação,
identificando seus requisitos, atividades e tarefas.
Dentre as dificuldades encontradas da primeira fase do TCC, está o entendimento das
relações de TI com os clientes internos e externos e como o framework ITIL pode auxiliar neste
processo. Outra dificuldade elencada foi identificar a relação entre as gerências dos processos
propostos pelo ITIL, uma vez que estes são entrelaçados e buscam o conceito de complementação:
com ações e recursos diferentes.
85
Já a segunda etapa do TCC, consistiu em desenvolver, validar e documentar os resultados
obtidos com a utilização da aplicação, formalizando assim a necessidade desta para auxilio ao
Gerenciamento de Problemas proposto pelo ITIL.
O desenvolvimento da aplicação foi realizado conforme a especificação do projeto (Capítulo
3), iniciando pela construção da base de dados e seguida do desenvolvimento, conforme ressaltado
no Capítulo 4.
A utilização do framework Symfony foi crucial ao desenvolvimento do projeto, por
possibilitar a automatização do desenvolvimento de forma já padronizada e fortemente enquadrada
dentro dos conceitos sugeridos pela UML de desenvolvimento em três camadas.
Para testes e validação do sistema foi utilizado o ambiente do LCA na UNIVALI,
gerenciando os problemas enfrentados no desenvolvimento, instalação, manutenção, suporte a
usuários e operacionalização do Sistema de Informação do PREPS. Também foi onde se encontrou
o maior desafio da segunda etapa deste TCC, criar a consciência nos colaboradores (e.g., auxiliares
administrativos, programadores, estagiários) para proverem a documentação dos processos de
suporte e entrega de serviços de TI. Dificuldade esta superada pelo retorno (facilidades)
proporcionado pela aplicação CPItil e o reconhecimento, da boa prática, pelos clientes.
Com isto, conclui-se que este TCC contempla as necessidades de: pesquisa, projeto,
gerência, desenvolvimento, documentação, validação e testes – que são o alicerce da formação de
um Analista de Sistemas, Cientista da Computação, Gerente em TI e/ou Produtor de Pesquisa e
Desenvolvimento.
REFERÊNCIAS BIBLIOGRÁFICAS
3RD ED. COBIT STEERING COMMITTEE AND THE IT GOVERNANCE INSTITUTE. COBIT Executive Summary. Estados Unidos, 2000. Disponível em <http://www.isaca.org/cobit.htm>. Acesso em: 13 nov. 2006.
AMBOUJ GOYAL. General Manager Lótus. In:IBM on demand. 2003, São Paulo.
APACHE SOFTWARE FOUNDATION, Estados Unidos, 2006. Disponível em < http://www.apache.org/>. Acesso em: 13 nov. 2006.
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 18 jun. 2006.
APPLE COMPUTER, INC. Advance Search. Disponível em < http://search.info.apple.com/>. Acesso em: 13 nov. 2006.
BAKKEN, Stig Saether et. al. Manual do PHP. Estados Unidos, 2004. Disponível em <http://www.php.net/manual/pt_BR/>. Acesso em: 29 mar. 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.
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.
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.
CANTOR, M., Object-Oriented Project Management with UML, John Wiley & Sons. Inc., 1998.
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: 13 nov. 2006.
COSTA NETO, Alberto. Disponível em: <http://www.dcce.ufs.br/~alberto/2001-1/aps2/index.htm#Download>. Acesso em: 19 ago. 2006.
DAVENPORT, T. H.; PRUSAK, L. Conhecimento empresarial. 2. ed. Rio de Janeiro: Campus, 1998. 273 p.
87
ESPILDORA, Francisco Gentil. PSGTI - Turbinando o Gerenciamento Serviços em Tecnologia da Informação e Comunicação. Tematec 2004, Disponível em: <http://www.serpro.gov.br/publicacao/tematec/tematec/2004/ttec74.>. Acesso em: 13 nov. 2006.
EVARISTO JR., Ademir Miguel. OPERA - Sistema de Triagem de Informações para Formação de Operações Especiais, para o Setor de Inteligência da Polícia Rodoviária Federal - SC. Itajaí, 2006. 106 f. Trabalho de Conclusão de Curso (Graduação em Ciência da Computação)–Centro de Ciências Tecnológicas da Terra e do Mar, Universidade do Vale do Itajaí, Itajaí, 2006.
FAYAD, E. SCHIMIDT, C. e JOHNSON, E. Implementing Application Frameworks – Object-Oriented Frameworks at Work. Wiley. New York, 1999.
GALUCH, Lucia. Modelo para Implementação das Ferramentas Básicas do Controle Estatístico do Processo –CEP em Pequenas Empresas Manufatureiras. 2002. 86f. Dissertação (Mestrado em Engenharia de Produção) – Programa de Pós-Graduação em Engenharia de Produção, UFSC, Florianópolis.
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.
ICH Architecture Resource Center. Glossary. Disponível em: <http://www.ichnet.org/glossary.htm>. Acesso em: 13 nov. 2006.
IT GOVERNANCE INSTITUTE. COBIT Mapping . Estados Unidos, 2004. Disponível em <http://www.isaca.org/cobit.htm>. Acesso em: 13 nov. 2006.
LCA, Laboratório de Computação Aplicada. Documento de especificação e padrões para desenvolvimento. Itajaí, 2006. Arquivo PDF.
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: 13 nov. 2006.
LLOYD, Vernon, et. al. Planning to Implement Service Management: ITIL – The key to Managing IT Services. The Stationary Office for OGC. Noruega, 2000. CD-ROM. ISBN 0113308779.
MAGALHÃES, Eduardo. ISO 20.000. Melhores práticas na gestão de serviços de TI. Disponível em < http://www.it-aurus.com.br/conteudo.asp?ntipo=16&lista=categoria&cat_id=5&cat_nome=Downloads >. Acesso em: 31 mai. 2007.
MICROSOFT CORPORATION. Ajuda e Suporte. Disponível em <http://support.microsoft.com/ >. Acesso em 13 nov. 2006.
MYSQL AB. MySQL Reference Manual. Estados Unidos, 2006. Disponível em: <http://downloads.mysql.com/docs/refman-5.1-en.a4.pdf>. Acesso em: 13 nov. 2006.
NETSCAPE COMMUNICATIONS CORPORATION. JavaScript Resources. Estados Unidos, 1999. Disponível em: <http://devedge.netscape.com/central/javascript/>. Acesso em: 10 jul. 2006.
88
NETWORK WORKING GROUP. HTTP 1.1 Specification. Estados Unidos, 1999. Disponível em: <http://www.w3.org/Protocols/>. Acesso em: 13 nov. 2006.
NONAKA, I.; TAKEUCHI, H. Criação de conhecimento na empresa. 4. ed. Rio de Janeiro: LTC, 1997. 358 p.
OFFICE OF GOVERNMENT COMMERCE. Business Perspective: the IS view on delivering services to the business. Londres: Stationary Office, 2004. CD-ROM. ISBN 0113308949.
PGADMIN III, PgAdmin III WebSite. Disponível em < http://www.pgadmin.org/ >. Acesso em 27 mai. 2007.
POSTGRESQL GLOBAL DEVELOPMENT GROUP. PostgreSQL Manuals, 2006. Disponível em <http://www.postgresql.org/docs/>. Acesso em: 13 nov. 2006.
POTENCIER. Fabien, et. al. SYMFONY PROJECT , 2006. Disponível em <http://www.symfony-project.com>. Acesso em: 18 dez. 2006.
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 jan. 2006.
PROPEL PROJECT. Disponível em < http://propel.phpdb.org/trac/wiki/Users/Introduction >. Acesso em 04 de jun. 2007.
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 jan. 2006.
RED HAT, INC. Red Hat Knowledgebase, 2006. Disponível em <http://kbase.redhat.com/faq/>. Acesso em: 13 nov. 2006.
REIS, Ricardo, et al. Artigo AJAX : Introdução. 13/12/2005. Disponível em: <http://pwp.net.ipl.pt/alunos.isel/24138/AJAX/IntroducaoAJAX.pdf>. Acesso em: 13 nov. 2006.
SANCHES, André Rodrigo. Fundamentos de Armazenamento e Manipulação de Dados. Disponível em < http://www.ime.usp.br/~andrers/aulas/bd2005-1/aula6.html >. Acesso em 31 de mai. 2007.
SEVERINO, Antonio Joaquim. Metodologia do trabalho científico. São Paulo: Cortez, 2002. ISBN 85-249-0050-4.
STEWART, T. A. Capital intelectual. 3. ed. Rio de Janeiro: Campus, 1998. 237 p.
STRAUSS, Leandro. Portal do Conhecimento Tecnológico na Secretaria da Receita Federal. Itajaí, 2004. [145]f. Trabalho de Conclusão de Curso (Graduação em Ciência da Computação)– Centro de Ciências Tecnológicas da Terra e do Mar, Universidade do Vale do Itajaí, Itajaí, 2004.
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.
89
WORLD WIDE WEB CONSORTIUM. Protocols. Disponível em: < http://www.w3.org/> Acessado em: 18 dez. 2006.
ZINNER, Michael G. FabForce.NET. Disponível em: < http://fabforce.net > Acessado em 27 mai. 2007.
ix
A. ENTREVISTA COM COLABORADORES E CLIENTES DE TI
Questionário sobre Entrega de Serviços de TI TCC I do acadêmico Felipe Luiz Pereira Utilizar esses conceitos para este questionário: Significado Exemplo Incidente Fato que impede a
operacionalização normal do negocio.
- fonte queimou; - usuário não sabe como fazer.
Problema Gerador de um ou mais incidentes.
- rede oscilante; - falta de treinamento.
Base de conhecimento Base de dados com as regras de operacionalização do negocio.
- em caso de fonte queimar, faça isso. - em caso de falta de treinamento, faça isso.
TI Tecnologia da Informação Feedback Solicitação de retorno - questionar ao usuário se ele foi
bem atendido. 1. Nome R. 2. Organização onde trabalha R. 3. Cargo que exerce: ( ) Cliente ( ) Service/Help Desk ( ) Atendimento Nível 1 / 2 / N ( ) Especialista ( ) Gerente de TI 4. Quanto tempo trabalha em funções ligadas com entrega de serviço? Caso cliente, quanto tempo solicita serviços? R. 5. Na sua empresa existe algum software que auxilia o atendimento de incidentes? Qual? R. CLIENTE (Somente os clientes devem responder) 6. Qual a participação do cliente na utilização do software de auxilio a atendimento de chamados? R. 7. É solicitado algum feedback do atendimento? R. 8. É possível ‘aprender’ a resolver suas dúvidas sozinho com ajuda do software de atendimento utilizado por sua empresa? R. 9. Você utiliza ou utilizaria (caso não tenha) o recurso de perguntas freqüentes (FAQ) do sistema de atendimento de sua empresa? R. COLABORADORES DE TI (Somente os Service/Help Desk, Atendimento Nível 1 / 2 / N ou Especialistas devem responder) 10. O software de auxilio a atendimento de incidentes possui formas de pesquisa a incidentes recorrentes? Você acha isso importante? R. 11. Se existe um software, é possível registrar e classificar os problemas enfrentados na organização? R. 12. Se existe um software, há como registrar as causas de um problema? Como? R. 13. As medidas para resolução de problemas são tomadas: ( ) Re-ativamente (apenas atendem a incidentes) ( ) Pró-ativamente (comissão executa tarefas de prevenção a incidentes) 14. Existe algum prazo para termino dos atendimentos de incidentes registrados em contrato interno ou externo? R.
GERENTES DE TI (Somente Gerentes de TI devem responder) 14. Quais tipos de relatórios você pode retirar do sistema utilizado? R. 15. Existe algum relatórios que você considera importante e não tenha neste sistema? R. 16. Você considera importante o uso de uma Base de Conhecimento para agilizar o processo de atendimento de sua equipe? R.
Questionário sobre Entrega de Serviços de TI TCC I do acadêmico Felipe Luiz Pereira Utilizar esses conceitos para este questionário: Significado Exemplo Incidente Fato que impede a
operacionalização normal do negocio.
- fonte queimou; - usuário não sabe como fazer.
Problema Gerador de um ou mais incidentes.
- rede oscilante; - falta de treinamento.
Base de conhecimento Base de dados com as regras de operacionalização do negocio.
- em caso de fonte queimar, faça isso. - em caso de falta de treinamento, faça isso.
TI Tecnologia da Informação Feedback Solicitação de retorno - questionar ao usuário se ele foi
bem atendido. 1. Nome R. Andréia B. Bohner 2. Organização onde trabalha R. Universidade do Vale do Itajaí - UNIVALI 3. Cargo que exerce: ( ) Cliente ( ) Service/Help Desk (X) Atendimento Nível 1 / 2 / N ( ) Especialista ( ) Gerente de TI 4. Quanto tempo trabalha em funções ligadas com entrega de serviço? Caso cliente, quanto tempo solicita serviços? R. 1 ano 5. Na sua empresa existe algum software que auxilia o atendimento de incidentes? Qual? R. Sim. Qualitor. COLABORADORES DE TI (Somente os Service/Help Desk, Atendimento Nível 1 / 2 / N ou Especialistas devem responder) 10. O software de auxilio a atendimento de incidentes possui formas de pesquisa a incidentes recorrentes? Você acha isso importante? R. Sim para ambas. 11. Se existe um software, é possível registrar e classificar os problemas enfrentados na organização? R. Sim. 12. Se existe um software, há como registrar as causas de um problema? Como? R. Sim. Cadastrando na própria ocorrência do chamado. 13. As medidas para resolução de problemas são tomadas: ( X ) Re-ativamente (apenas atendem a incidentes) ( X ) Pró-ativamente (comissão executa tarefas de prevenção a incidentes) 14. Existe algum prazo para termino dos atendimentos de incidentes registrados em contrato interno ou externo? R. Sim. Os prazos são definidos conforme a severidade do chamado a ser atendido (baixa, média, alta ou crítica).
Questionário sobre Entrega de Serviços de TI TCC I do acadêmico Felipe Luiz Pereira Utilizar esses conceitos para este questionário: Significado Exemplo Incidente Fato que impede a
operacionalização normal do negocio.
- fonte queimou; - usuário não sabe como fazer.
Problema Gerador de um ou mais incidentes.
- rede oscilante; - falta de treinamento.
Base de conhecimento Base de dados com as regras de operacionalização do negocio.
- em caso de fonte queimar, faça isso. - em caso de falta de treinamento, faça isso.
TI Tecnologia da Informação Feedback Solicitação de retorno - questionar ao usuário se ele foi
bem atendido. 1. Nome R. Diogo Altoé Lopes 2. Organização onde trabalha R. Prefeitura Municipal de Itajaí 3. Cargo que exerce: ( ) Cliente ( ) Service/Help Desk ( ) Atendimento Nível 1 / 2 / N ( X ) Especialista ( ) Gerente de TI 4. Quanto tempo trabalha em funções ligadas com entrega de serviço? Caso cliente, quanto tempo solicita serviços? R. 4 meses (Prefa) 5. Na sua empresa existe algum software que auxilia o atendimento de incidentes? Qual? R. Sim. i-Controle. COLABORADORES DE TI (Somente os Service/Help Desk, Atendimento Nível 1 / 2 / N ou Especialistas devem responder) 10. O software de auxilio a atendimento de incidentes possui formas de pesquisa a incidentes recorrentes? Você acha isso importante? R. Sim. É importante para manter um histórico e melhor gerenciamento de relatorios. 11. Se existe um software, é possível registrar e classificar os problemas enfrentados na organização? R. Sim, pois é classificados por tipo de problema. 12. Se existe um software, há como registrar as causas de um problema? Como? R. Não. 13. As medidas para resolução de problemas são tomadas: ( X ) Re-ativamente (apenas atendem a incidentes) ( ) Pró-ativamente (comissão executa tarefas de prevenção a incidentes) 14. Existe algum prazo para termino dos atendimentos de incidentes registrados em contrato interno ou externo? R. Não.
Questionário sobre Entrega de Serviços de TI TCC I do acadêmico Felipe Luiz Pereira Utilizar esses conceitos para este questionário: Significado Exemplo Incidente Fato que impede a
operacionalização normal do negocio.
- fonte queimou; - usuário não sabe como fazer.
Problema Gerador de um ou mais incidentes.
- rede oscilante; - falta de treinamento.
Base de conhecimento Base de dados com as regras de operacionalização do negocio.
- em caso de fonte queimar, faça isso. - em caso de falta de treinamento, faça isso.
TI Tecnologia da Informação Feedback Solicitação de retorno - questionar ao usuário se ele foi
bem atendido. 1. Nome R. Fabricio Bortoluzzi 2. Organização onde trabalha R. Universidade do Vale do Itajaí 3. Cargo que exerce: ( ) Cliente ( ) Service/Help Desk ( X ) Atendimento Nível 1 / 2 / N ( ) Especialista ( ) Gerente de TI 4. Quanto tempo trabalha em funções ligadas com entrega de serviço? Caso cliente, quanto tempo solicita serviços? R. Entrego serviços há 3 anos. 5. Na sua empresa existe algum software que auxilia o atendimento de incidentes? Qual? R. Sim, Qualitor COLABORADORES DE TI (Somente os Service/Help Desk, Atendimento Nível 1 / 2 / N ou Especialistas devem responder) 10. O software de auxilio a atendimento de incidentes possui formas de pesquisa a incidentes recorrentes? Você acha isso importante? R. Isso é vital. Caso contrário o software não adiciona inteligência no processo. Meu software possui suporte parcial. 11. Se existe um software, é possível registrar e classificar os problemas enfrentados na organização? R. Sim. 12. Se existe um software, há como registrar as causas de um problema? Como? R. Na descrição de registro de um chamado é possível descrever a causa. Isso vai da boa prática do colaborador em se interessar por registrar a causa. 13. As medidas para resolução de problemas são tomadas: ( X ) Re-ativamente (apenas atendem a incidentes) ( X ) Pró-ativamente (comissão executa tarefas de prevenção a incidentes) 14. Existe algum prazo para termino dos atendimentos de incidentes registrados em contrato interno ou externo? R. Sim. O prazo varia conforme o grau de gravidade previamente estabelecido pelo operador de help desk. Vai até 96 horas.
Questionário sobre Entrega de Serviços de TI TCC I do acadêmico Felipe Luiz Pereira Utilizar esses conceitos para este questionário: Significado Exemplo Incidente Fato que impede a
operacionalização normal do negocio.
- fonte queimou; - usuário não sabe como fazer.
Problema Gerador de um ou mais incidentes.
- rede oscilante; - falta de treinamento.
Base de conhecimento Base de dados com as regras de operacionalização do negocio.
- em caso de fonte queimar, faça isso. - em caso de falta de treinamento, faça isso.
TI Tecnologia da Informação Feedback Solicitação de retorno - questionar ao usuário se ele foi
bem atendido. 1. Nome R. Fernando Silveira de Quadro 2. Organização onde trabalha R. UNIVALI – Sitamar (Projeto TAMAR.gov.br) 3. Cargo que exerce: ( ) Cliente ( ) Service/Help Desk ( ) Atendimento Nível 1 / 2 / N (X) Especialista ( ) Gerente de TI 4. Quanto tempo trabalha em funções ligadas com entrega de serviço? Caso cliente, quanto tempo solicita serviços? R. 2 anos 5. Na sua empresa existe algum software que auxilia o atendimento de incidentes? Qual? R. Não existe. COLABORADORES DE TI (Somente os Service/Help Desk, Atendimento Nível 1 / 2 / N ou Especialistas devem responder) 10. O software de auxilio a atendimento de incidentes possui formas de pesquisa a incidentes recorrentes? Você acha isso importante? R. Não utilizamos software para atendimento de incidentes, porém eu acho importante estar registrando os incidentes. 11. Se existe um software, é possível registrar e classificar os problemas enfrentados na organização? R. 12. Se existe um software, há como registrar as causas de um problema? Como? R. 13. As medidas para resolução de problemas são tomadas: ( X ) Re-ativamente (apenas atendem a incidentes) ( ) Pró-ativamente (comissão executa tarefas de prevenção a incidentes) 14. Existe algum prazo para termino dos atendimentos de incidentes registrados em contrato interno ou externo? R. Sim existe prazo.
Questionário sobre Entrega de Serviços de TI TCC I do acadêmico Felipe Luiz Pereira Utilizar esses conceitos para este questionário: Significado Exemplo Incidente Fato que impede a
operacionalização normal do negocio.
- fonte queimou; - usuário não sabe como fazer.
Problema Gerador de um ou mais incidentes.
- rede oscilante; - falta de treinamento.
Base de conhecimento Base de dados com as regras de operacionalização do negocio.
- em caso de fonte queimar, faça isso. - em caso de falta de treinamento, faça isso.
TI Tecnologia da Informação Feedback Solicitação de retorno - questionar ao usuário se ele foi
bem atendido. 1. Nome R. Rafael Rauber 2. Organização onde trabalha R. Prefeitura Municipal de Itajaí 3. Cargo que exerce: (x ) Cliente ( ) Service/Help Desk ( ) Atendimento Nível 1 / 2 / N ( ) Especialista ( ) Gerente de TI 4. Quanto tempo trabalha em funções ligadas com entrega de serviço? Caso cliente, quanto tempo solicita serviços? R. Um ano e meio 5. Na sua empresa existe algum software que auxilia o atendimento de incidentes? Qual? R. Sim CLIENTE (Somente os clientes devem responder) 6. Qual a participação do cliente na utilização do software de auxilio a atendimento de chamados? R. O cliente notifica o incidente encontrado através do software e pode acompanhar o andamento das etapas para a sua solução. 7. É solicitado algum feedback do atendimento? R. Sim 8. É possível ‘aprender’ a resolver suas dúvidas sozinho com ajuda do software de atendimento utilizado por sua empresa? R. Sim, o software possui uma parte para esclarecimento de eventuais dúvidas que possam ocorrer. 9. Você utiliza ou utilizaria (caso não tenha) o recurso de perguntas freqüentes (FAQ) do sistema de atendimento de sua empresa? R. Sim
Questionário sobre Entrega de Serviços de TI TCC I do acadêmico Felipe Luiz Pereira Utilizar esses conceitos para este questionário: Significado Exemplo Incidente Fato que impede a
operacionalização normal do negocio.
- fonte queimou; - usuário não sabe como fazer.
Problema Gerador de um ou mais incidentes.
- rede oscilante; - falta de treinamento.
Base de conhecimento Base de dados com as regras de operacionalização do negocio.
- em caso de fonte queimar, faça isso. - em caso de falta de treinamento, faça isso.
TI Tecnologia da Informação Feedback Solicitação de retorno - questionar ao usuário se ele foi
bem atendido. 1. Nome R. Tadeu Eduardo Depiné Granemann 2. Organização onde trabalha R. PREPS – Programa Nacional de Rastreamento de Embarcações Pesqueiras por Satélite 3. Cargo que exerce: ( ) Cliente ( ) Service/Help Desk ( ) Atendimento Nível 1 / 2 / N ( X) Especialista ( ) Gerente de TI 4. Quanto tempo trabalha em funções ligadas com entrega de serviço? Caso cliente, quanto tempo solicita serviços? R. 6 meses. 5. Na sua empresa existe algum software que auxilia o atendimento de incidentes? Qual? R. Não. COLABORADORES DE TI (Somente os Service/Help Desk, Atendimento Nível 1 / 2 / N ou Especialistas devem responder) 10. O software de auxilio a atendimento de incidentes possui formas de pesquisa a incidentes recorrentes? Você acha isso importante? R. Não. A importância desse recurso em um software a atendimento de incidentes de auxilio é fundamental, visto que, o tempo do processo de identificação do incidente, bem como sua solução, é reduzido. 11. Se existe um software, é possível registrar e classificar os problemas enfrentados na organização? R. 12. Se existe um software, há como registrar as causas de um problema? Como? R. 13. As medidas para resolução de problemas são tomadas: ( X ) Re-ativamente (apenas atendem a incidentes) ( ) Pró-ativamente (comissão executa tarefas de prevenção a incidentes) 14. Existe algum prazo para termino dos atendimentos de incidentes registrados em contrato interno ou externo? R. Não.
x
B. DOCUMENTO DE ESPECIFICAÇÃO DE REQUISITOS E CASOS DE USO
CPItil
CPITIL: UMA APLICAÇÃO DE APOIO AO GERENCIAMENTO DE PROBLEMAS BASEADO NA RECOMENDAÇÃO ITIL
Documento de Especificação de Requisitos e Casos de Uso
Versão 1.0
Junho/2007
Equipe Técnica Carlos Henrique Bughi Orientador Felipe Luiz Pereira Orientando
Modelo de negócio
pd Modelo de negócio
1.4 Requisitos
+ 1.4.1 Requisitos funcionais
+ 1.4.2 Requisitos não funcionais
1.5 Regras de negócio
+ 1.5.1 Service Desk
+ 1.5.2 Controle de Problemas
+ 1.5.3 Controle de Erros
+ 1.5.4 Gerência, Pró-atividade e Métricas
+ 1.5.5 Gerenciamento de Incidentes
Figura 1: Modelo de negócio
1.1 Objetivo
cd 1.1 Objetivo
O objetivo geral deste projeto de pesquisa é desenvolver uma aplicação de apoio ao gerenciamento de problemas por estruturas de Service Desk baseada em tecnologia Web. Essa aplicação deverá considerar as recomendações de gerenciamentode serviços do ITIL.
Figura 2: 1.1 Objetivo
1.2 Objetivos específicos
cd 1.2 Objetivos específicos
- Estabelecer o conjunto de ferramentas e l inguagens de desenvolvimento de aplicações, para a construção da aplicação;
- Especificar um modelo conceitual, util izando como referência a linguagem UML, de forma a relacionar os requisitos funcionais, não-funcionais, regras de negócios, atores envolvidos, casos de uso, protótipos de telas, classes de domínio e comportamento da aplicação.
Figura 3: 1.2 Objetivos específicos
1.3 Visão geral do sistema
cd 1.3 Visão geral do sistema
Propor uma aplicação web, baseada no modelo ITIL, que permita auxil iar o processo de qualidade no atendimento e satisfação do cliente, tornando o setor de TI um personagem ativo da gestão, e não um mero expectador dos acontecimentos.
Figura 4: 1.3 Visão geral do sistema
1.4 Requisitos
pd 1.4 Requisitos
1.4.1 Requisitos funcionais
+ 1.4.1.1 Service Desk
+ 1.4.1.2 Controle de Problemas
+ 1.4.1.3 Controle de Erros
+ 1.4.1.4 Gerência, Pró-atividade e Métricas
+ 1.4.1.5 Gerenciamento de Incidentes
1.4.2 Requisitos não funcionais
+ 1.4.2.1 Software
+ 1.4.2.2 Desempenho
+ 1.4.2.3 Implementação
+ 1.4.2.4 Conformidade
Figura 5: 1.4 Requisitos
1.4.1 Requisitos funcionais
cd 1.4.1 Requisitos funcionais
1.4.1.1 Serv ice Desk
+ RF1.01 - O sistema deverá permitir o cadastro de usuários por tipo de atuação
1.4.1.2 Controle de Problemas
+ RF2.01 - O sistema deverá permitir o cadastro de problemas.
+ RF2.02 - O sistema deverá permitir o cadastro/edição das palavras chaves de um problemas.
+ RF2.03 - O sistema deverá permitir a classificação, definição de prioridade e urgência de um problema.
+ RF2.04 - O sistema deverá permitir o cadastro de categoria de um problema.
+ RF2.05 - O sistema deverá permitir o escalonamento de um problema.
+ RF2.06 - O sistema deverá permitir o cadastro do diagnóstico do um problema.
+ RF2.07 - O sistema deverá permitir o cadastro de possíveis causas de um problema.
1.4.1.3 Controle de Erros
+ RF3.01 - O sistema deverá permitir o cadastro de um erro conhecido.
+ RF3.02 - O sistema deverá permitir o cadastro de uma frase interrogativa que indique o erro, para posterior uti l ização no FAQ.
+ RF3.03 - O sistema deverá permitir o cadastro/edição das palavras chaves de um erro.
+ RF3.04 - O sistema deverá permitir o cadastro de anotações de um erro.
+ RF3.05 - O sistema deverá permitir o escalonamento de um erro.
+ RF3.06 - O sistema deverá permitir o cadastro de um work-around de um erro.
+ RF3.07 - O sistema deverá permitir o fechamento de um erro conhecido e seus problemas atribuídos.
+ RF3.08 - O sistema deverá permitir a geração/impressão de uma solicitação de mudança.
1.4.1.4 Gerência, Pró-ativ idade e Métricas
+ RF4.01 - O sistema deverá disponibil izar uma lista de erros freqüentes (FAQ).
+ RF4.02 - O sistema deverá permitir a configuração da quantidade de erros disponíveis na l ista de erros freqüentes.
+ RF4.03 - O sistema deverá disponibil izar uma listagem dos problemas cadastrados.
+ RF4.04 - O sistema deverá disponibil izar uma listagem dos erros cadastrados.
+ RF4.05 - O sistema deverá permitir a geração de relatórios contendo informações sobre um problema.
+ RF4.06 - O sistema deverá permitir a geração de relatórios com o número de problemas por período.
+ RF4.07 - O sistema deverá permitir a geração de relatórios com o número de problemas resolvidos por período.
+ RF4.08 - O sistema deverá permitir a geração de relatórios com o número de incidentes por problema.
+ RF4.09 - O sistema deverá permitir a geração de relatórios com a média de tempo gastos para cada etapa de um problema/erro.
+ RF4.10 - O sistema deverá permitir a geração de relatórios com a listagem de RFC por período.
+ RF4.11 - O sistema deverá permitir a geração de relatórios com o tempo médio de resolução dos problemas versus o tempo médio previsto para resolução dos mesmos.
1.4.1.5 Gerenciamento de Incidentes
+ RF5.01 - O sistema deverá permitir a consulta de problemas e erros conhecidos.
+ RF5.02 - O sistema deverá permitir atualizar problemas, tornando-os em erros conhecidos.
+ RF5.03 - O sistema deverá permitir atualizar problemas, cadastrando um novo código de incidente a ele l igado, indicando assim a reincidência do problema.
+ RF5.04 - O sistema deverá permitir atualizar erros conhecidos, cadastrando um novo código de incidente a ele l igado, indicando assim a reincidência do erro.
Figura 6: 1.4.1 Requisitos funcionais
1.4.1.1 Service Desk
cd 1.4.1.1 Service Desk
RF1.01 - O sistema deverá permitir o cadastro de usuários por tipo de atuação
Figura 7: 1.4.1.1 Service Desk
1.4.1.2 Controle de Problemas
cd 1.4.1.2 Controle de Problemas
RF2.01 - O sistema deverá permitir o cadastro de problemas.
RF2.02 - O sistema deverá permitir o cadastro/edição das palavras chaves de um problemas.
RF2.03 - O sistema deverá permitir a classificação, definição de prioridade e urgência de um problema.
RF2.04 - O sistema deverá permitir o cadastro de categoria de um problema.
RF2.05 - O sistema deverá permitir o escalonamento de um problema.
RF2.06 - O sistema deverá permitir o cadastro do diagnóstico do um problema.
RF2.07 - O sistema deverá permitir o cadastro de possíveis causas de um problema.
Figura 8: 1.4.1.2 Controle de Problemas
1.4.1.3 Controle de Erros
cd 1.4.1.3 Controle de Erros
RF3.01 - O sistema deverá permitir o cadastro de um erro conhecido.
RF3.02 - O sistema deverá permitir o cadastro de uma frase interrogativa que indique o erro, para posterior utilização no FAQ.
RF3.03 - O sistema deverá permitir o cadastro/edição das palavras chaves de um erro.
RF3.04 - O sistema deverá permitir o cadastro de anotações de um erro.
RF3.05 - O sistema deverá permitir o escalonamento de um erro.
RF3.06 - O sistema deverá permitir o cadastro de um work-around de um erro.
RF3.07 - O sistema deverá permitir o fechamento de um erro conhecido e seus problemas atribuídos.
RF3.08 - O sistema deverá permitir a geração/impressão de uma solici tação de mudança.
Figura 9: 1.4.1.3 Controle de Erros
1.4.1.4 Gerência, Pró-atividade e Métricas
cd 1.4.1.4 Gerência, Pró-atividade e Métricas
RF4.01 - O sistema deverá disponibi lizar uma lista de erros freqüentes (FAQ).
RF4.02 - O sistema deverá permitir a configuração da quantidade de erros disponíveis na lista de erros freqüentes.
RF4.03 - O sistema deverá disponibi lizar uma listagem dos problemas cadastrados.
RF4.04 - O sistema deverá disponibi lizar uma listagem dos erros cadastrados.
RF4.05 - O sistema deverá permitir a geração de relatórios contendo informações sobre um problema.
RF4.06 - O sistema deverá permitir a geração de relatórios com o número de problemas por período.
RF4.07 - O sistema deverá permitir a geração de relatórios com o número de problemas resolvidos por período.
RF4.08 - O sistema deverá permitir a geração de relatórios com o número de incidentes por problema.
RF4.09 - O sistema deverá permitir a geração de relatórios com a média de tempo gastos para cada etapa de um problema/erro.
RF4.10 - O sistema deverá permitir a geração de relatórios com a listagem de RFC por período.
RF4.11 - O sistema deverá permitir a geração de relatórios com o tempo médio de resolução dos problemas versus o tempo médio previsto para resolução dos mesmos.
Figura 10: 1.4.1.4 Gerência, Pró-atividade e Métricas
1.4.1.5 Gerenciamento de Incidentes
cd 1.4.1.5 Gerenciamento de Incidentes
RF5.01 - O sistema deverá permitir a consulta de problemas e erros conhecidos.
RF5.02 - O sistema deverá permitir atualizar problemas, tornando-os em erros conhecidos.
RF5.03 - O sistema deverá permitir atualizar problemas, cadastrando um novo código de incidente a ele ligado, indicando assim a reincidência do problema.
RF5.04 - O sistema deverá permitir atualizar erros conhecidos, cadastrando um novo código de incidente a ele l igado, indicando assim a reincidência do erro.
Figura 11: 1.4.1.5 Gerenciamento de Incidentes
1.4.2 Requisitos não funcionais
pd 1.4.2 Requisitos não funcionais
1.4.2.1 Software
+ RNF1.01 - A l inguagem de programação adotada deverá ser o PHP5.0 ou superior.
+ RNF1.02 - O SGDB uti l izado deverá ser o PostgreSQL 1.8 ou superior.
+ RNF1.03 - A aplicação deverá ser desenvolvida uti l izando o framework Symfony.
1.4.2.2 Desempenho
+ RNF2.01 - Nenhuma página poderá levar mais do que 3 segundos para serem processadas no servidor.
+ RNF2.02 - Nenhuma página deverá levar mais de 20 segundos para serem carregadas pelo navegador em condições normais de uma conexão de 256kbps.
1.4.2.3 Implementação
+ RNF3.01 - As senhas deverão ser salvas no banco de dados uti l izando criptografia MD5.
1.4.2.4 Conformidade
+ RNF4.01 - O resultado dos scripts da aplicação deverá estar em conformidade com o padrão W3C de HTML, CSS, XML, DOM e JavaScript.
Figura 12: 1.4.2 Requisitos não funcionais
1.4.2.1 Software
cd 1.4.2.1 Software
RNF1.01 - A l inguagem de programação adotada deverá ser o PHP5.0 ou superior.
RNF1.02 - O SGDB uti lizado deverá ser o PostgreSQL 1.8 ou superior.
RNF1.03 - A aplicação deverá ser desenvolvida util izando o framework Symfony.
Figura 13: 1.4.2.1 Software
1.4.2.2 Desempenho
cd 1.4.2.2 Desempenho
RNF2.01 - Nenhuma página poderá levar mais do que 3 segundos para serem processadas no servidor.
RNF2.02 - Nenhuma página deverá levar mais de 20 segundos para serem carregadas pelo navegador em condições normais de uma conexão de 256kbps.
Figura 14: 1.4.2.2 Desempenho
1.4.2.3 Implementação
cd 1.4.2.3 Implementação
RNF3.01 - As senhas deverão ser salvas no banco de dados uti lizando criptografia MD5.
Figura 15: 1.4.2.3 Implementação
1.4.2.4 Conformidade
cd 1.4.2.4 Conformidade
RNF4.01 - O resultado dos scripts da aplicação deverá estar em conformidade com o padrão W3C de HTML, CSS, XML,DOM e JavaScript.
Figura 16: 1.4.2.4 Conformidade
1.5 Regras de negócio
pd 1.5 Regras de negócio
1.5.1 Serv ice Desk
+ RN1.01 - As opções de cadastro, edição, tarefas deverá ser feita por tipo de usuário.
+ RN1.02 - Um usuário poderá ter mais de um tipo.
+ RN1.03 - Os usuários uti l izarão um par de login e senha para autenticação no sistema.
+ RN1.04 - Os logins de usuários deverão ter no mínimo 6 caracteres.
1.5.2 Controle de Problemas
+ RN2.01 - As palavras chaves (key words) deverão possuir índice de importância definidas pelo usuário.
+ RN2.02 - As prioridades de um problema deverão possuir uma escala de horas para resolução.
+ RN2.03 - As categorias de problema deverão ter até 5 níveis hierárquicos.
+ RN2.04 - Todo o escalonamento de um problema deve ser alertado por e-mail.
+ RN2.05 - As causas de um problema deverão ter até 5 níveis hierárquicos.
1.5.3 Controle de Erros
+ RN3.01 - Um erro conhecido deverá ter no mínimo 1 problema associado.
+ RN3.02 - As palavras chaves (key words) deverão possuir índice de importância definidas pelo usuário.
+ RN3.03 - Todo o escalonamento de um erro deve ser alertado por e-mail.
+ RN3.04 - Todo erro deverá possuir uma solução paliativa cadastrada.
+ RN3.05 - A solicitação de mudança deverá conter a descrição do problema/erro.
1.5.4 Gerência, Pró-ativ idade e Métricas
+ RN4.01 - A lista de erros freqüentes deverá ser disposta também aos usuários/cl ientes.
+ RN4.02 - A listagem de problemas deverá ser ordenada por ordem de status e prioridade.
1.5.5 Gerenciamento de Incidentes
+ RN5.01 - A consulta de erros deverá ser ranqueada de acordo com a tabela abaixo ou poderá ter sua configuração alterada pelo administrador do sistema
Figura 17: 1.5 Regras de negócio
1.5.1 Service Desk
cd 1.5.1 Service Desk
RN1.01 - As opções de cadastro, edição, tarefas deverá ser feita por tipo de usuário.
RN1.02 - Um usuário poderá ter mais de um tipo.
RN1.03 - Os usuários util izarão um par de login e senha para autenticação no sistema.
RN1.04 - Os logins de usuários deverão ter no mínimo 6 caracteres.
Figura 18: 1.5.1 Service Desk
1.5.2 Controle de Problemas
cd 1.5.2 Controle de Problemas
RN2.01 - As palavras chaves (key words) deverão possuir índice de importância definidas pelo usuário.
RN2.02 - As prioridades de um problema deverão possuir uma escala de horas para resolução.
RN2.03 - As categorias de problema deverão ter até 5 níveis hierárquicos.
RN2.04 - Todo o escalonamento de um problema deve ser alertado por e-mail.
RN2.05 - As causas de um problema deverão ter até 5 níveis hierárquicos.
Figura 19: 1.5.2 Controle de Problemas
1.5.3 Controle de Erros
cd 1.5.3 Controle de Erros
RN3.01 - Um erro conhecido deverá ter no mínimo 1 problema associado.
RN3.02 - As palavras chaves (key words) deverão possuir índice de importância definidas pelo usuário.
RN3.03 - Todo o escalonamento de um erro deve ser alertado por e-mail.
RN3.04 - Todo erro deverá possuir uma solução pal iativa cadastrada.
RN3.05 - A sol icitação de mudança deverá conter a descrição do problema/erro.
Figura 20: 1.5.3 Controle de Erros
1.5.4 Gerência, Pró-atividade e Métricas
cd 1.5.4 Gerência, Pró-atividade e Métricas
RN4.01 - A lista de erros freqüentes deverá ser disposta também aos usuários/clientes.
RN4.02 - A listagem de problemas deverá ser ordenada por ordem de status e prioridade.
Figura 21: 1.5.4 Gerência, Pró-atividade e Métricas
1.5.5 Gerenciamento de Incidentes
cd 1.5.5 Gerenciamento de Incidentes
RN5.01 - A consulta de erros deverá ser ranqueada de acordo com a tabela abaixo ou poderá ter sua configuração alterada pelo administrador do sistema
Figura 22: 1.5.5 Gerenciamento de Incidentes
2. Visão de funcionalidades
pd 2. Visão de funcionalidades
2.1 Modelo de caso de uso
+ Atores envolvidos
+ 2.1.1 Problemas / Erros
+ 2.1.2 Consultas
+ 2.1.3 Relatórios
+ 2.1.4 Basilares
Figura 23: 2. Visão de funcionalidades
Modelo de caso de uso
pd Modelo de caso de uso
Atores envolv idos
+ Administrador
+ Atendente Nível N
+ Cliente
+ Help Desk
+ Service Desk
+ Supervidor de Atendimento
2.1.1 Problemas / Erros
+ UC1.01 - Cadastro de problemas
+ UC1.02 - Cadastro de erros
+ UC1.03 - Classificação de problema / erro
+ UC1.04 - Cadastro de diagnóstico
+ UC1.05 - Escalonamento de problema / erro
+ UC1.06 - Cadastro de causas de um problema
+ UC1.07 - Fechamento de um erro / problema
+ UC1.08 - Gerando solicitação de mudanças
2.1.2 Consultas
+ UC2.01 - Configurar FAQ
+ UC2.02 - Visualizar FAQ
+ UC2.03 - Buscar por problemas / erros
2.1.3 Relatórios
+ UC3.01 - Detalhamento de problema / erro
+ UC3.02 - Relatório de número de problemas
+ UC3.03 - Incidentes por problemas
+ UC3.04 - Tempo médio por problema / erro
+ UC3.05 - Listagem de RFCs por período
+ UC3.06 - Detalhamento de RFC
2.1.4 Basilares
+ UC4.01 - Cadastro de usuários
+ UC4.02 - Cadastro de tipo de usuário
+ UC4.03 - Cadastro de categorias de problema / erro
Figura 24: Modelo de caso de uso
2.1.1 Problemas / Erros
ud 2.1.1 Problemas / Erros
UC1.01 - Cadastro de problemas
UC1.02 - Cadastro de erros
UC1.03 - Classificação de problema / erro
UC1.04 - Cadastro de diagnóstico
UC1.05 - Escalonamento de
problema / erro
UC1.06 - Cadastro de causas de um
problema
UC1.07 - Fechamento de
um erro / problema
UC1.08 - Gerando solicitação de
mudanças
Atendente Nível N
Help Desk
Superv idor de Atendimento
Figura 25: 2.1.1 Problemas / Erros
UC1.01 - Cadastro de problemas Descrição: Pré-requisito: Um usuário Help Desk, ou superior, deverá estar logado no sistema.
Pós-condição: Um novo problema será cadastrado na base de dados. Tarefa: O usuário poderá descrever um problema com informações textuais, palavras chaves (keywords), possíveis causas e CIs afetados. Através deste cadastro os atendentes de nível superior, poderão realizar o devido fichamento do problema e realizar medidas para transformá-lo num erro conhecido.
Associação -
• Help Desk • UC1.01 - Cadastro de problemas
UC1.02 - Cadastro de erros Descrição: Pré-requisito: Um usuário Atendente de Nível N, ou superior, deverá estar logado no sistema. A solução paliativa de um problema deverá ter sido encontrada.
Pós-condição: Um problema passará a ter uma solução paliativa e consequentemente tornar-se um erro conhecido. Tarefa: O usuário deverá identificar o problema e ser "solucionado paliativamente". Após isso deverá informa a solução, revisar a classificação, palavras chaves (keywords), CIs que afeta, causas, e libera-lo para visualização como erro conhecido. Essa tarefa precede a tarefa de solicitação de mudança (RFC), uma vez que todas as RFCs devem ter um erro conhecido associado.
Associação -
• Atendente Nível N
• UC1.02 - Cadastro de erros
UC1.03 - Classificação de problema / erro Descrição: Tarefa:
- Permitir a classificação de um problema/erro. - Classificar a categoria de um problema/erro.
Associação -
• Help Desk • UC1.03 - Classificação de problema / erro
UC1.04 - Cadastro de diagnóstico Descrição: Tarefa:
- Permitir diagnosticar um problema/erro - Descrever o diagnostico do problema
Associação -
• Help Desk • UC1.04 - Cadastro de diagnóstico
UC1.05 - Escalonamento de problema / erro Descrição: Tarefa:
- Indicar a proximidade de término previsto para o superior do responsável pelo problema/erro.
Associação -
• Help Desk • UC1.05 - Escalonamento de problema / erro
UC1.06 - Cadastro de causas de um problema Descrição: Tarefa:
- Permitir o cadastro de causas de um problema. - Permitir o cadastro de causas e sub-causas de um problema (Princípio do diagrama de Causa e Efeito).
Associação -
• Atendente Nível N • UC1.06 - Cadastro de causas de um problema
UC1.07 - Fechamento de um erro / problema Descrição: Pré-requisito: Um usuário Atendente de Nível N, ou superior, deverá estar logado no sistema. Uma RFC terá sido cadastrada e liberada.
Pós-condição: Um erro conhecido deixar de existir. Tarefa: O usuário deverá identificar a solicitação de mudança e marca-la como entregue. O sistema deverá finalizar o erro conhecido, o problema, e alterar o status dos incidentes associados para "Pendência Pós-Mudança".
Associação -
• Atendente Nível N • UC1.07 - Fechamento de um erro / problema
UC1.08 - Gerando solicitação de mudanças Descrição: Tarefa:
- Gerar/Imprimir uma solicitação de mudança (RFC).
Associação -
• Supervidor de Atendimento • UC1.08 - Gerando solicitação de mudanças
2.1.2 Consultas
ud 2.1.2 Consultas
UC2.01 - Configurar FAQ
UC2.02 - Visualizar FAQ
UC2.03 - Buscar por problemas /
erros
Cliente
Superv idor de Atendimento
Figura 26: 2.1.2 Consultas
UC2.01 - Configurar FAQ Descrição: Tarefa:
- Permitir a configuração da quantidade de top Erros que irão constar na lista do FAQ.
Associação -
• Supervidor de Atendimento • UC2.01 - Configurar FAQ
UC2.02 - Visualizar FAQ Descrição: Tarefa:
- Permitir a visualização do FAQ. Associação -
• Cliente • UC2.02 - Visualizar FAQ
UC2.03 - Buscar por problemas / erros Descrição: Tarefa:
- Efetuar busca na base de problemas e erros conhecidos para apresentação da ficha de conhecimento.
Associação -
• Cliente • UC2.03 - Buscar por problemas / erros
2.1.3 Relatórios
ud 2.1.3 Relatórios
UC3.01 - Detalhamento de problema / erro
UC3.02 - Relatório de número de
problemas
UC3.03 - Incidentes por
problemas
UC3.04 - Tempo médio por
problema / erro
UC3.05 - Listagem de RFCs por
período
UC3.06 - Detalhamento de
RFC
Cliente
Superv idor de Atendimento
Figura 27: 2.1.3 Relatórios
UC3.01 - Detalhamento de problema / erro Descrição: Tarefa:
- Permitir a visualização da ficha de conhecimento.
Associação -
• Cliente • UC3.01 - Detalhamento de problema / erro
UC3.02 - Relatório de número de problemas Descrição: Tarefa:
- Permitir a geração de um relatório com número de problemas por semana, mês, bimestre, semestre e ano. Associação -
• Supervidor de Atendimento • UC3.02 - Relatório de número de problemas
UC3.03 - Incidentes por problemas Descrição: Tarefa:
- Permitir o geração de relatório com a lista de incidêntes por problema.
Associação -
• Supervidor de Atendimento • UC3.03 - Incidentes por problemas
UC3.04 - Tempo médio por problema / erro Descrição: Tarefa:
- Permitir a geração de um relatório com o tempo médio versus o tempo real de problema/erro por semana, mês, bimestre, semestre e ano. Associação -
• Supervidor de Atendimento • UC3.04 - Tempo médio por problema / erro
UC3.05 - Listagem de RFCs por período Descrição: Tarefa:
- Permitir a geração de um relatório com a listagem de RFCs por período definido pelo usuário. Associação -
• Supervidor de Atendimento • UC3.05 - Listagem de RFCs por período
UC3.06 - Detalhamento de RFC Descrição: Tarefa:
- Permitir a geração de um relatório com o detalhamento de uma RFC. Associação -
• Supervidor de Atendimento • UC3.06 - Detalhamento de RFC
2.1.4 Basilares
ud 2.1.4 Basilares
UC4.01 - Cadastro de usuários
UC4.02 - Cadastro de tipo de usuário
UC4.03 - Cadastro de categorias de problema / erro
Serv ice Desk
Administrador
Superv idor de Atendimento
Figura 28: 2.1.4 Basilares
UC4.01 - Cadastro de usuários Descrição: Tarefa:
- Permitir o cadastro de usuário: Help Desk, Atendentes, Supervisores, Administradores, etc. Associação -
• Service Desk • UC4.01 - Cadastro de usuários
UC4.02 - Cadastro de tipo de usuário Descrição: Tarefa:
- Permitir o cadastro de tipo de usuários. Associação -
• Administrador • UC4.02 - Cadastro de tipo de usuário
UC4.03 - Cadastro de categorias de problema / erro Descrição: Tarefa:
- Permitir o cadastro e visualização das categorias de problemas/erros.
Associação -
• Supervidor de Atendimento • UC4.03 - Cadastro de categorias de problema / erro
Atores envolvidos
ud Atores envolvidos
Serv ice Desk
Help Desk Atendente Nível N
Superv idor de Atendimento
Administrador
Cliente
Figura 29: Atores envolvidos
3. Visão Lógica
pd 3. Visão Lógica
3.1 Diagrama de Classes
+ Categoria
+ Causa
+ CIs
+ Erro
+ FeedBack
+ Incidente
+ Keywords
+ Liberacoes
+ Prioridade
+ Problema
+ RFC
+ ServiceDesk
+ TipoDeUsuario
Figura 30: 3. Visão Lógica
3.1 Diagrama de Classes
cd 3.1 Diagrama de Classes
Escopo do Sistema
Incidente
- codIncidente: int- dscIncidente: text- dscSolucao: text- indStatus: int
Problema
- causaProblema: char- codProblema: int- datCriacao: date- datRevisao: date- tempoPrevisto: int- tempoReal: int- txtDiagnostico: char- txtPergunta: char
Erro
- datCadastro: date- datRevisao: date- tempoPrevisto: int- tempoReal: int- txtAnotacoes: text- txtSolucaoPaliativa: text
Causa
- codCausa: int- nomCausa: char
Serv iceDesk
- codUsuario: int- nomUsuario: char
RFC
- codRFC: int- dscRFC: char
Categoria
- codCategoria: int- nomCategoria: char
TipoDeUsuario
- codTipo: int- nomTipo: char
CIs
- codCI: int- nomCI: char
Keywords
- codKey: int- indImportancia: int- nomKey: char
FeedBack
- codFeedBack: int- valFeedBack: int
Liberacoes
- codLiberacao: int- indEntregue: int
Prioridade
- codPrioridade: int- nomPrioridade: char- tempoResolucao: int
0..*
1
0..* 0..1
1..*
0..*
0..*
0..1
0..11..*
0..*
1
10..*
10..*
0..*
1..*
0..1
1
0..*
1
10..*
0..1
1
Figura 31: 3.1 Diagrama de Classes
4. Visão de implementação
pd 4. Visão de implementa...
4.1 Componentes de Hardware
+ Computador do Colaborador
+ Servidor de Banco de Dados
+ Servidor Web
4.2 Componentes de Software
+ Apache
+ Browser
+ Pear
+ PHP 5.x
+ PostgreSQL
+ Symfony
Figura 32: 4. Visão de implementação
4.1 Componentes de Hardware
id 4.1 Componentes de Hardware
Serv idor WebServ idor de Banco de Dados
Computador do Colaborador
WAN | WWW
LAN
Figura 33: 4.1 Componentes de Hardware
Computador do Colaborador Descrição: Computador para acesso a aplicação.
WAN | WWW Associação -
• Servidor Web • Computador do Colaborador
Servidor de Banco de Dados Descrição: Servidor de Banco de Dados
LAN Associação -
• Servidor Web • Servidor de Banco de Dados
Servidor Web Descrição: Servidor que irá abrigar os componentes de software que interagem para sustentar a aplicação.
LAN Associação -
• Servidor Web • Servidor de Banco de Dados
WAN | WWW Associação -
• Servidor Web • Computador do Colaborador
4.2 Componentes de Software
id 4.2 Componentes de Software
4.1 Componentes de Hardware::Computador do Colaborador
4.1 Componentes de Hardware::Serv idor Web
4.1 Componentes de Hardware::Serv idor de Banco de Dados
PostgreSQL
Browser
Apache
PHP 5.x
PearSymfony
TCP
http
LAN
WAN | WWW
Figura 34: 4.2 Componentes de Software
Apache Descrição: - Servidor de páginas de Internet.
Associação -
• Apache • PHP 5.x
http Associação -
• Browser • Apache
Browser Descrição: - Por tratar-se de uma aplicação web os colaboradores e cliente de TI teram acesso as informações através de um browser compativel com as especificações W3C;
- A utilização do padrão W3C foi imposta em um requisito não funcional de conformidade. http Associação -
• Browser • Apache
Pear Descrição:
Associação -
• PHP 5.x • Pear
PHP 5.x Descrição: - Motor dinâmico, que possibilita a interpretação de scripts orientados a objetos.
- A utilização deste motor dinâmico foi feita pela necessidade de atender a um requisito não funcional de software. Associação -
• Apache • PHP 5.x
Associação -
• PHP 5.x • Pear
Associação -
• Symfony • PHP 5.x
TCP Associação -
• PHP 5.x • PostgreSQL
PostgreSQL Descrição: - Banco de dados relacional a ser utilizado na aplicação;
- A utilização deste banco contempla o requisito não funcional de software que trata do SGDB. TCP Associação -
• PHP 5.x • PostgreSQL
Symfony Descrição:
Associação -
• Symfony • PHP 5.x
xii
C. SCRIPT DE CRIAÇÃO DA BASE DE DADOS
CREATE TABLE TTCC_SERVICE_DESK ( COD_USUARIO SERIAL, NOM_USUARIO VARCHAR(100) NOT NULL, TXT_LOGIN VARCHAR(32) NOT NULL, TXT_SENHA VARCHAR(32) NOT NULL ); CREATE TABLE TTCC_INCIDENTE ( COD_INCIDENTE SERIAL, IND_SITUACAO INTEGER NOT NULL DEFAULT 0, DSC_INCIDENTE TEXT NULL, DSC_SOLUCAO TEXT NULL ); CREATE TABLE TTCC_PRIORIDADE ( COD_PRIORIDADE SERIAL, NOM_PRIORIDADE VARCHAR(100) NOT NULL, NUM_TEMPO_RESOLUCAO INTEGER NOT NULL ); CREATE TABLE TTCC_SISTEMA_CONFIGURACAO ( NOM_CAMPO VARCHAR(100) NOT NULL, VAL_CAMPO_INT INTEGER NULL, VAL_CAMPO_TXT TEXT NULL ); CREATE TABLE TTCC_CATEGORIA ( COD_CATEGORIA SERIAL, COD_CATEGORIA_PAI INTEGER NULL, NOM_CATEGORIA VARCHAR(255) NOT NULL ); CREATE TABLE TTCC_TIPO_USUARIO ( COD_TIPO_USUARIO SERIAL, NOM_TIPO_USUARIO VARCHAR(100) NOT NULL ); CREATE TABLE TTCC_CI ( COD_CI SERIAL, COD_CI_PAI INTEGER NULL, NOM_CI VARCHAR(255) NOT NULL ); CREATE TABLE TTCC_SERVICE_DESK_TIPO ( COD_USUARIO INTEGER NOT NULL, COD_TIPO_USUARIO INTEGER NOT NULL ); CREATE TABLE TTCC_PROBLEMA ( COD_PROBLEMA SERIAL, COD_USUARIO INTEGER NOT NULL, COD_CATEGORIA INTEGER NULL, COD_PRIORIDADE INTEGER NULL, TXT_CAUSA_PROBLEMA VARCHAR(255) NOT NULL, DAT_CRIACAO TIMESTAMP NOT NULL, DAT_REVISAO TIMESTAMP NULL, IND_TEMPO_PREVISTO INTEGER NULL, IND_TEMPO_REAL INTEGER NULL, TXT_DIAGNOSTICO TEXT NOT NULL, TXT_PERGUNTA VARCHAR(255) NULL ); CREATE TABLE TTCC_CAUSA ( COD_CAUSA SERIAL, COD_PROBLEMA INTEGER NOT NULL, COD_PROBLEMA_2 INTEGER NOT NULL, COD_CAUSA_PAI INTEGER NULL, NOM_CAUSA VARCHAR(255) NOT NULL ); CREATE TABLE TTCC_KEYWORD ( COD_KEYWORD SERIAL, COD_PROBLEMA INTEGER NOT NULL, IND_IMPORTANCIA INTEGER NOT NULL, TXT_KEYWORD VARCHAR(50) NOT NULL ); CREATE TABLE TTCC_ERRO ( COD_PROBLEMA INTEGER NOT NULL, COD_USUARIO INTEGER NOT NULL, DAT_CADASTRO TIMESTAMP NOT NULL DEFAULT NOW(), DAT_REVISAO TIMESTAMP NULL, IND_TEMPO_PREVISTO INTEGER NULL, IND_TEMPO_REAL INTEGER NULL, TXT_ANOTACAO TEXT NULL,
TXT_SOLUCAO_PALIATIVA TEXT NOT NULL ); CREATE TABLE TTCC_INCIDENTE_PROBLEMA ( COD_PROBLEMA INTEGER NOT NULL, COD_INCIDENTE INTEGER NOT NULL ); CREATE TABLE TTCC_PROBLEMA_CI ( COD_PROBLEMA INTEGER NOT NULL, COD_CI INTEGER NOT NULL ); CREATE TABLE TTCC_RFC ( COD_PROBLEMA INTEGER NOT NULL, COD_USUARIO INTEGER NOT NULL, DSC_RFC TEXT NOT NULL ); CREATE TABLE TTCC_LIBERACAO ( COD_LIBERACAO SERIAL, COD_PROBLEMA INTEGER NOT NULL, IND_ENTREGUE BOOL NOT NULL DEFAULT FALSE ); CREATE TABLE TTCC_FEEDBACK ( COD_FEEDBACK SERIAL, COD_PROBLEMA INTEGER NOT NULL, VAL_FEEDBACK INTEGER NOT NULL ); ALTER TABLE TTCC_SERVICE_DESK ADD CONSTRAINT "ktcc_service_desk_01" PRIMARY KEY (COD_USUARIO); ALTER TABLE TTCC_INCIDENTE ADD CONSTRAINT "ktcc_incidente_01" PRIMARY KEY (COD_INCIDENTE); ALTER TABLE TTCC_PRIORIDADE ADD CONSTRAINT "ktcc_prioridade_01" PRIMARY KEY (COD_PRIORIDADE); ALTER TABLE TTCC_SISTEMA_CONFIGURACAO ADD CONSTRAINT "ktcc_sistema_configuracao_01" PRIMARY KEY (NOM_CAMPO); ALTER TABLE TTCC_CATEGORIA ADD CONSTRAINT "ktcc_categoria_01" PRIMARY KEY (COD_CATEGORIA); CREATE INDEX "itcc_categoria_01" on TTCC_CATEGORIA(COD_CATEGORIA_PAI); ALTER TABLE TTCC_CATEGORIA ADD CONSTRAINT "ftcc_categoria_01" FOREIGN KEY(COD_CATEGORIA_PAI) REFERENCES TTCC_CATEGORIA(COD_CATEGORIA) ON DELETE RESTRICT ON UPDATE CASCADE; ALTER TABLE TTCC_TIPO_USUARIO ADD CONSTRAINT "ktcc_tipo_usuario_01" PRIMARY KEY (COD_TIPO_USUARIO); ALTER TABLE TTCC_CI ADD CONSTRAINT "ktcc_ci_01" PRIMARY KEY (COD_CI); CREATE INDEX "itcc_ci_01" on TTCC_CI(COD_CI_PAI); ALTER TABLE TTCC_CI ADD CONSTRAINT "ftcc_ci_01" FOREIGN KEY(COD_CI_PAI) REFERENCES TTCC_CI(COD_CI) ON DELETE RESTRICT ON UPDATE CASCADE; ALTER TABLE TTCC_SERVICE_DESK_TIPO ADD CONSTRAINT "ktcc_service_desk_tipo_01" PRIMARY KEY (COD_USUARIO, COD_TIPO_USUARIO); CREATE INDEX "itcc_service_desk_tipo_01" on TTCC_SERVICE_DESK_TIPO(COD_USUARIO); CREATE INDEX "itcc_service_desk_tipo_02" on TTCC_SERVICE_DESK_TIPO(COD_TIPO_USUARIO); ALTER TABLE TTCC_SERVICE_DESK_TIPO ADD CONSTRAINT "ftcc_service_desk_tipo_01" FOREIGN KEY(COD_USUARIO) REFERENCES TTCC_SERVICE_DESK(COD_USUARIO) ON DELETE RESTRICT ON UPDATE CASCADE; ALTER TABLE TTCC_SERVICE_DESK_TIPO ADD CONSTRAINT "ftcc_service_desk_tipo_02" FOREIGN KEY(COD_TIPO_USUARIO) REFERENCES TTCC_TIPO_USUARIO(COD_TIPO_USUARIO) ON DELETE RESTRICT ON UPDATE CASCADE;
ALTER TABLE TTCC_PROBLEMA ADD CONSTRAINT "ktcc_problema_01" PRIMARY KEY (COD_PROBLEMA); CREATE INDEX "itcc_problema_01" on TTCC_PROBLEMA(COD_PRIORIDADE); CREATE INDEX "itcc_problema_02" on TTCC_PROBLEMA(COD_CATEGORIA); CREATE INDEX "itcc_problema_03" on TTCC_PROBLEMA(COD_USUARIO); ALTER TABLE TTCC_PROBLEMA ADD CONSTRAINT "ftcc_problema_01" FOREIGN KEY(COD_PRIORIDADE) REFERENCES TTCC_PRIORIDADE(COD_PRIORIDADE) ON DELETE RESTRICT ON UPDATE CASCADE; ALTER TABLE TTCC_PROBLEMA ADD CONSTRAINT "ftcc_problema_02" FOREIGN KEY(COD_CATEGORIA) REFERENCES TTCC_CATEGORIA(COD_CATEGORIA) ON DELETE RESTRICT ON UPDATE CASCADE; ALTER TABLE TTCC_PROBLEMA ADD CONSTRAINT "ftcc_problema_03" FOREIGN KEY(COD_USUARIO) REFERENCES TTCC_SERVICE_DESK(COD_USUARIO) ON DELETE RESTRICT ON UPDATE CASCADE; ALTER TABLE TTCC_CAUSA ADD CONSTRAINT "ktcc_causa_01" PRIMARY KEY (COD_CAUSA, COD_PROBLEMA); CREATE INDEX "itcc_causa_01" on TTCC_CAUSA(COD_CAUSA_PAI, COD_PROBLEMA_2); CREATE INDEX "itcc_causa_02" on TTCC_CAUSA(COD_PROBLEMA); ALTER TABLE TTCC_CAUSA ADD CONSTRAINT "ftcc_causa_01" FOREIGN KEY(COD_CAUSA_PAI, COD_PROBLEMA_2) REFERENCES TTCC_CAUSA(COD_CAUSA, COD_PROBLEMA) ON DELETE RESTRICT ON UPDATE CASCADE; ALTER TABLE TTCC_CAUSA ADD CONSTRAINT "ftcc_causa_02" FOREIGN KEY(COD_PROBLEMA) REFERENCES TTCC_PROBLEMA(COD_PROBLEMA) ON DELETE CASCADE ON UPDATE CASCADE; ALTER TABLE TTCC_KEYWORD ADD CONSTRAINT "ktcc_keyword_01" PRIMARY KEY (COD_KEYWORD, COD_PROBLEMA); CREATE INDEX "itcc_keyword_01" on TTCC_KEYWORD(COD_PROBLEMA); ALTER TABLE TTCC_KEYWORD ADD CONSTRAINT "ftcc_keyword_01" FOREIGN KEY(COD_PROBLEMA) REFERENCES TTCC_PROBLEMA(COD_PROBLEMA) ON DELETE CASCADE ON UPDATE CASCADE; ALTER TABLE TTCC_ERRO ADD CONSTRAINT "ktcc_erro_01" PRIMARY KEY (COD_PROBLEMA); CREATE INDEX "itcc_erro_01" on TTCC_ERRO(COD_PROBLEMA); CREATE INDEX "itcc_erro_02" on TTCC_ERRO(COD_USUARIO); ALTER TABLE TTCC_ERRO ADD CONSTRAINT "ftcc_erro_01" FOREIGN KEY(COD_PROBLEMA) REFERENCES TTCC_PROBLEMA(COD_PROBLEMA) ON DELETE CASCADE ON UPDATE CASCADE; ALTER TABLE TTCC_ERRO ADD CONSTRAINT "ftcc_erro_02" FOREIGN KEY(COD_USUARIO) REFERENCES TTCC_SERVICE_DESK(COD_USUARIO) ON DELETE RESTRICT ON UPDATE CASCADE; ALTER TABLE TTCC_INCIDENTE_PROBLEMA ADD CONSTRAINT "ktcc_incidente_problema_01" PRIMARY KEY (COD_PROBLEMA, COD_INCIDENTE); CREATE INDEX "itcc_incidente_problema_01" on TTCC_INCIDENTE_PROBLEMA(COD_PROBLEMA); CREATE INDEX "itcc_incidente_problema_02" on TTCC_INCIDENTE_PROBLEMA(COD_INCIDENTE); ALTER TABLE TTCC_INCIDENTE_PROBLEMA ADD CONSTRAINT "ftcc_incidente_problema_01" FOREIGN KEY(COD_PROBLEMA) REFERENCES TTCC_PROBLEMA(COD_PROBLEMA) ON DELETE CASCADE ON UPDATE CASCADE; ALTER TABLE TTCC_INCIDENTE_PROBLEMA ADD CONSTRAINT "ftcc_incidente_problema_02" FOREIGN KEY(COD_INCIDENTE) REFERENCES TTCC_INCIDENTE(COD_INCIDENTE) ON DELETE CASCADE ON UPDATE CASCADE; ALTER TABLE TTCC_PROBLEMA_CI ADD CONSTRAINT "ktcc_problema_ci_01" PRIMARY KEY (COD_PROBLEMA, COD_CI); CREATE INDEX "itcc_problema_ci_01" on TTCC_PROBLEMA_CI(COD_PROBLEMA); CREATE INDEX "itcc_problema_ci_02" on TTCC_PROBLEMA_CI(COD_CI); ALTER TABLE TTCC_PROBLEMA_CI ADD CONSTRAINT "ftcc_problema_ci_01" FOREIGN KEY(COD_PROBLEMA) REFERENCES TTCC_PROBLEMA(COD_PROBLEMA) ON DELETE CASCADE
ON UPDATE CASCADE; ALTER TABLE TTCC_PROBLEMA_CI ADD CONSTRAINT "ftcc_problema_ci_02" FOREIGN KEY(COD_CI) REFERENCES TTCC_CI(COD_CI) ON DELETE RESTRICT ON UPDATE CASCADE; ALTER TABLE TTCC_RFC ADD CONSTRAINT "ktcc_rfc_01" PRIMARY KEY (COD_PROBLEMA); CREATE INDEX "itcc_rfc_01" on TTCC_RFC(COD_PROBLEMA); CREATE INDEX "itcc_rfc_02" on TTCC_RFC(COD_USUARIO); ALTER TABLE TTCC_RFC ADD CONSTRAINT "ftcc_rfc_01" FOREIGN KEY(COD_PROBLEMA) REFERENCES TTCC_ERRO(COD_PROBLEMA) ON DELETE CASCADE ON UPDATE CASCADE; ALTER TABLE TTCC_RFC ADD CONSTRAINT "ftcc_rfc_02" FOREIGN KEY(COD_USUARIO) REFERENCES TTCC_SERVICE_DESK(COD_USUARIO) ON DELETE NO ACTION ON UPDATE NO ACTION; ALTER TABLE TTCC_LIBERACAO ADD CONSTRAINT "ktcc_liberacao_01" PRIMARY KEY (COD_LIBERACAO, COD_PROBLEMA); CREATE INDEX "itcc_liberacao_01" on TTCC_LIBERACAO(COD_PROBLEMA); ALTER TABLE TTCC_LIBERACAO ADD CONSTRAINT "ftcc_liberacao_01" FOREIGN KEY(COD_PROBLEMA) REFERENCES TTCC_RFC(COD_PROBLEMA) ON DELETE CASCADE ON UPDATE CASCADE; ALTER TABLE TTCC_FEEDBACK ADD CONSTRAINT "ktcc_feedback_01" PRIMARY KEY (COD_FEEDBACK, COD_PROBLEMA); CREATE INDEX "itcc_feedback_01" on TTCC_FEEDBACK(COD_PROBLEMA); ALTER TABLE TTCC_FEEDBACK ADD CONSTRAINT "ftcc_feedback_01" FOREIGN KEY(COD_PROBLEMA) REFERENCES TTCC_ERRO(COD_PROBLEMA) ON DELETE RESTRICT ON UPDATE CASCADE;
D. DEPOIMENTO DO USUÁRIO TESTER DA SISTEMA
Felipe, em relação a utilização do CPITIL, no Linux
Fedora Core 5, com o navegador Firefox 1.5.0.12, segue minhas
considerações.
O sistema, em sua vesão final, mostrou-se estável. Com
relação à remoção de causas prováveis na edição de um problema,
obteve-se sucesso, já que essa ação não funcionava na semana
anterior. O sistema também possibilitou o cadastro de diagnóstico
contendo caracteres acentuados o que também não funcionava.
Além disso, identificou-se a evolução do FAQ gerado pelo sistema,
bem como a ordenação correta dos itens.
Tendo todas as funcionalidades em perfeito estado de
utilização acredito que agora, já podemos utilizar o CPItil para os
atendimento, visto que a demanda da aplicação, mostrou-se
evidente após os esclarecimentos da nova metodologia de
atendimento.
Tadeu E. D. Granemann