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. 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 ii 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 iii LISTA DE ABREVIATURAS AJAX ASP CERN CFML CMDB COBIT COSO CIs CQ CSS DTI DOM EFQM FAQ GP GI GM HTML HTTP IAS ICT IIS ITIL JSP KPIs LCA MER MIME NCSA OSI PgSQL PHP PREPS RFC SGDB SLA SQL TCC TI UML URI W3C WWW XML XSLT Asynchronous Javascript and XML Active Server Pages Centre Europeen de Recherche Nucleaire ColdFusion Configuration Management Database Control Objectives for Information and Related Technology Committee of Sponsoring Organizations of the Treadway Commission Itens de Configuração Controle de Qualidade Cascading Style Sheets Departamento de Tecnologia da Informação Document Object Model European Foundation for Quality Management Frequently Asked Question(s) Gerenciamento de Problemas Gerenciamento de Incidentes Gerenciamento de Mudanças Hyper Text Markup Language Hyper Text Transfer Protocol Oracle Internet Application Server Information and Communication Technology Microsoft Internet Information Services Information Technology Infrastructure Library Java Sever Pages Keys Performance Indicator Laboratório de Computação Aplicada Modelo de Entidade e Relacionamentos Multipurpose Internet Mail Extension National Center for Supercomputing Applications Open Systems Interconnection Banco de Dados PostgreSQL PHP Hypertext Processor Programa Nacional de Rastreamento de Embarcações Pesqueiras por Satélite Request for Changes Sistema Gerenciador de Banco de Dados Service Level Agreement Structured Query Language Trabalho de Conclusão de Curso Tecnologia da Informação Unified Modeling Language Universal Resources Identifier World Wide Web Consortium World Wide Web Extensible Markup Language Extendible Stylesheet Language Transformations iv 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 v 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 vi 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. vii 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. viii 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). 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). 2 Retenção do Empregado I n v e s t i m e n t o Qualidade Interna de Serviços Satisfação do Empregado Aumento do Faturamento Valor para os Clientes Produtividade do Empregado Satisfação do Cliente Fidelização do Cliente Maior Rentabilidade 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. 3 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. 4 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. 5 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. 6 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. 7 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, definese 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, fazse 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. 8 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). 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. 10 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). 11 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. 12 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). 13 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. 14 Tabela 1. Divisões do livro Deliver IT Services. Capítulo Gerenciamento do relacionamento com o cliente Gerenciamento da capacidade Gerenciamento financeiro dos serviços de TI Gerenciamento da disponibilidade Gerenciamento de nível de serviço Gerenciamento da continuidade dos serviços de TI Descrição Estabelece uma função para tratar as questões de relacionamento com o cliente que contrata os serviços de TI 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 Tem como objetivo prover uma economia de custos efetiva dos ativos e recursos de TI usados para o fornecimento dos serviços de TI 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 Determina e monitora o nível dos serviços de TI necessários para suportar os negócios da empresa 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. 15 Tabela 2. Divisões do livro ICT Infrastructure Management. Capítulo Design e planejamento Posicionamento estratégico Operações Suporte técnico Descrição 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 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 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 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): 16 Tabela 3. Divisões do livro Service Suport. Capítulo Service Desk Gerenciamento de incidentes (GI) Gerenciamento de problemas (GP) Gerenciamento de configuração (GC) Gerenciamento de mudanças Gerenciamento de liberação Descrição É 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. 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. 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. 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. 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. 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). 17 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. 18 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. 19 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. 20 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. 21 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. 22 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). 23 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). 24 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 25 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. 26 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. 27 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). 28 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. 29 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: 30 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). 31 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. 32 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. 33 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. 34 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”. 35 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). 36 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). 37 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): 38 Tabela 5. Fases da construção do conhecimento organizacional. Fase Compartilhamento do conhecimento tácito Criação de conceitos Justificação de conceitos Construção de um arquétipo Difusão interativa do conhecimento Descrição Com a socialização o conhecimento tácito criado pelo indivíduo é compartilhado com todos. 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 A organização decide se os conceitos criados na fase anterior têm validade ou utilidade para ela ou para a sociedade. O conceito já justificado é convertido em algo tangível, concreto. Pode ser um protótipo de um produto ou um modelo de procedimentos operacionais 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. 39 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). 40 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). 41 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. 42 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. 43 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. 44 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 45 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: 46 • 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. 47 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 48 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. 49 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). 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. 51 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. 52 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. 53 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. 54 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. 55 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. 56 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 tornarse 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”. 57 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. 58 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. 59 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. 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”). 61 Figura 24. MER da aplicação. 62 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. 63 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). 64 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.; 65 • 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). 66 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. 67 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). 68 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: 69 • 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: buscouse 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. 70 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). 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 72 atendimentos de chamados de 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. 73 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. 74 Figura 34. Tela de cadastro de problemas. 75 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). 76 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. 77 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. 78 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?”. 79 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 80 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. 81 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. 82 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. 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. 85 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/20011/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. 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 – ObjectOriented 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.itaurus.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. 87 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.symfonyproject.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. 88 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. 89 A. ENTREVISTA COM COLABORADORES E CLIENTES DE TI ix 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 Incidente Fato que impede a operacionalização normal do negocio. Problema Gerador de um ou mais incidentes. Base de conhecimento Base de dados com as regras de operacionalização do negocio. TI Feedback Tecnologia da Informação Solicitação de retorno Exemplo - fonte queimou; - usuário não sabe como fazer. - rede oscilante; - falta de treinamento. - em caso de fonte queimar, faça isso. - em caso de falta de treinamento, faça isso. - 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 Incidente Fato que impede a operacionalização normal do negocio. Problema Gerador de um ou mais incidentes. Base de conhecimento Base de dados com as regras de operacionalização do negocio. TI Feedback Tecnologia da Informação Solicitação de retorno Exemplo - fonte queimou; - usuário não sabe como fazer. - rede oscilante; - falta de treinamento. - em caso de fonte queimar, faça isso. - em caso de falta de treinamento, faça isso. - 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 Incidente Fato que impede a operacionalização normal do negocio. Problema Gerador de um ou mais incidentes. Base de conhecimento Base de dados com as regras de operacionalização do negocio. TI Feedback Tecnologia da Informação Solicitação de retorno Exemplo - fonte queimou; - usuário não sabe como fazer. - rede oscilante; - falta de treinamento. - em caso de fonte queimar, faça isso. - em caso de falta de treinamento, faça isso. - 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 Incidente Fato que impede a operacionalização normal do negocio. Problema Gerador de um ou mais incidentes. Base de conhecimento Base de dados com as regras de operacionalização do negocio. TI Feedback Tecnologia da Informação Solicitação de retorno Exemplo - fonte queimou; - usuário não sabe como fazer. - rede oscilante; - falta de treinamento. - em caso de fonte queimar, faça isso. - em caso de falta de treinamento, faça isso. - 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 Incidente Fato que impede a operacionalização normal do negocio. Problema Gerador de um ou mais incidentes. Base de conhecimento Base de dados com as regras de operacionalização do negocio. TI Feedback Tecnologia da Informação Solicitação de retorno Exemplo - fonte queimou; - usuário não sabe como fazer. - rede oscilante; - falta de treinamento. - em caso de fonte queimar, faça isso. - em caso de falta de treinamento, faça isso. - 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 Incidente Fato que impede a operacionalização normal do negocio. Problema Gerador de um ou mais incidentes. Base de conhecimento Base de dados com as regras de operacionalização do negocio. TI Feedback Tecnologia da Informação Solicitação de retorno Exemplo - fonte queimou; - usuário não sabe como fazer. - rede oscilante; - falta de treinamento. - em caso de fonte queimar, faça isso. - em caso de falta de treinamento, faça isso. - 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 Incidente Fato que impede a operacionalização normal do negocio. Problema Gerador de um ou mais incidentes. Base de conhecimento Base de dados com as regras de operacionalização do negocio. TI Feedback Tecnologia da Informação Solicitação de retorno Exemplo - fonte queimou; - usuário não sabe como fazer. - rede oscilante; - falta de treinamento. - em caso de fonte queimar, faça isso. - em caso de falta de treinamento, faça isso. - 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. B. DOCUMENTO DE ESPECIFICAÇÃO DE REQUISITOS E CASOS DE USO x 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 gerenciamento de 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 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. 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 IT IL, que permita auxiliar o processo de qualidade no atendimento e satisfação do cliente, tornando o setor de T I 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 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 solicitação de mudança. 1.4.1.4 Gerência, Pró-ativ idade e Métricas + RF4.01 - O sistema deverá disponibilizar 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á disponibilizar uma listagem dos problemas cadastrados. + RF4.04 - O sistema deverá disponibilizar 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 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 ligado, 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 solicitaçã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á disponibilizar 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á disponibilizar uma listagem dos problemas cadastrados. RF4.04 - O sistema deverá disponibilizar 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 ligado, 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 Softw are + RNF1.01 - A linguagem de programação adotada deverá ser o PHP5.0 ou superior. + RNF1.02 - O SGDB utilizado deverá ser o PostgreSQL 1.8 ou superior. + RNF1.03 - A aplicação deverá ser desenvolvida utilizando 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 utilizando 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 linguagem de programação adotada deverá ser o PHP5.0 ou superior. RNF1.02 - O SGDB utilizado deverá ser o PostgreSQL 1.8 ou superior. RNF1.03 - A aplicação deverá ser desenvolvida utilizando 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 utilizando 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 utilizarã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/clientes. + 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 adm 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 utilizarã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 paliativa cadastrada. RN3.05 - A solicitaçã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 env olv 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.08 - Gerando solicitação de mudanças Superv idor de Atendimento Help Desk UC1.03 Classificação de problema / erro UC1.02 - Cadastro de erros UC1.04 - Cadastro de diagnóstico UC1.06 - Cadastro de causas de um problema Atendente Nív el N UC1.05 Escalonamento de problema / erro UC1.07 Fechamento de um erro / problema 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 Superv idor de Atendimento UC2.02 Visualizar FAQ Cliente UC2.03 - Buscar por problemas / erros 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 Cliente UC3.02 - Relatório de número de problemas UC3.03 Incidentes por problemas UC3.04 - Tempo médio por problema / erro Superv idor de Atendimento UC3.05 - Listagem de RFCs por período UC3.06 Detalhamento de RFC 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 Serv ice Desk UC4.02 - Cadastro de tipo de usuário Administrador UC4.03 - Cadastro de categorias de problema / erro 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 Administrador Superv idor de Atendimento Help Desk Atendente Nív el N Serv ice Desk 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 Prioridade - Causa codPrioridade: int nomPrioridade: char tempoResolucao: int - CIs codCausa: int nomCausa: char 0..1 - codCI: int nomCI: char 0..* 1 0..* 0..* 1 0..* Problema Incidente - codIncidente: int dscIncidente: text dscSolucao: text indStatus: int 1..* 0..1 - Categoria causaProblema: char 1..* codProblema: int datCriacao: date datRevisao: date 0..* tempoPrevisto: int tempoReal: int txtDiagnostico: char txtPergunta: char 0..* 1 0..1 Keyw ords Erro datCadastro: date datRevisao: date tempoPrevisto: int tempoReal: int txtAnotacoes: text txtSolucaoPaliativa: text codCategoria: int nomCategoria: char 0..* 1 - 0..1 - - 1 codKey: int indImportancia: int nomKey: char Serv iceDesk 0..* 1 - codUsuario: int nomUsuario: char 0..* 1 1..* 1 TipoDeUsuario 0..1 0..* FeedBack RFC - codFeedBack: int valFeedBack: int - codRFC: int dscRFC: char Liberacoes - codLiberacao: int indEntregue: int Figura 31: 3.1 Diagrama de Classes - codTipo: int nomTipo: char 4. Visão de implementação pd 4. Visão de implementa... 4.1 Componentes de Hardw are + Computador do Colaborador + Servidor de Banco de Dados + Servidor Web 4.2 Componentes de Softw are + 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 de Banco de Dados Serv idor Web LAN WAN | WWW Computador do Colaborador 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 Hardw are::Serv idor Web 4.1 Componentes de Hardw are:: Serv idor de Banco de Dados LAN Symfony Pear PostgreSQL TCP PHP 5.x Apache WAN | WWW http 4.1 Componentes de Hardw are:: Computador do Colaborador Brow ser 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 C. SCRIPT DE CRIAÇÃO DA BASE DE DADOS xii 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" KEY(COD_TIPO_USUARIO) REFERENCES TTCC_TIPO_USUARIO(COD_TIPO_USUARIO) ON DELETE RESTRICT ON UPDATE CASCADE; FOREIGN 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" REFERENCES TTCC_CATEGORIA(COD_CATEGORIA) ON DELETE RESTRICT ON UPDATE CASCADE; FOREIGN KEY(COD_CATEGORIA) ALTER TABLE TTCC_PROBLEMA ADD CONSTRAINT "ftcc_problema_03" REFERENCES TTCC_SERVICE_DESK(COD_USUARIO) ON DELETE RESTRICT ON UPDATE CASCADE; FOREIGN KEY(COD_USUARIO) 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" REFERENCES TTCC_PROBLEMA(COD_PROBLEMA) ON DELETE CASCADE ON UPDATE CASCADE; FOREIGN KEY(COD_PROBLEMA) 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" REFERENCES TTCC_SERVICE_DESK(COD_USUARIO) ON DELETE RESTRICT ON UPDATE CASCADE; FOREIGN KEY(COD_USUARIO) 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" KEY(COD_INCIDENTE) REFERENCES TTCC_INCIDENTE(COD_INCIDENTE) ON DELETE CASCADE ON UPDATE CASCADE; FOREIGN 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" REFERENCES TTCC_CI(COD_CI) ON DELETE RESTRICT ON UPDATE CASCADE; FOREIGN KEY(COD_CI) 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" REFERENCES TTCC_SERVICE_DESK(COD_USUARIO) ON DELETE NO ACTION ON UPDATE NO ACTION; FOREIGN KEY(COD_USUARIO) 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