Integração e personalização avançada de um sistema de Gestão de Tickets

i

Universidade de Trás-os-Montes e Alto Douro

Escola de Ciências e Tecnologia

Integração e personalização avançada de um sistema de

Gestão de Tickets

Relatório de Estágio de Mestrado em Engenharia Informática

Mário José Santos Sousa

Sob a orientação do Professor Doutor Luís Filipe Leite Barbosa e do Professor Doutor José Benjamim Ribeiro da Fonseca

Vila Real, outubro de 2019

iii

Relatório de Estágio apresentado por Mário José Santos Sousa à Universidade de Trás-os-Montes e Alto Douro para cumprimento dos requisitos pedidos na obtenção do grau de Mestre em Engenharia Informática, sob a orientação do Prof. Doutor Luís Filipe Leite Barbosa, Professor Auxiliar do Departamento de Engenharias da Escola de Ciências e Tecnologia e Vice-Diretor do curso de Mestrado em Engenharia Informática da Universidade de Trás-os-Montes e Alto Douro e do Prof. Doutor José Benjamim Ribeiro da Fonseca, Professor Auxiliar com Agregação do Departamento de Engenharias da Escola de Ciências e Tecnologia da Universidade de Trás-os-Montes e Alto Douro e CEO da 4ALL Software.

v

Dedicado aos meus pais por todo o esforço realizado para que eu atingisse o grau de mestre.

vi

viii

Ag

Agradecimentos

A realização deste mestrado não seria possível sem o auxílio e colaboração de várias pessoas ao longo de todo este percurso que foi a minha formação académica. Como tal, não podia deixar escapar esta oportunidade para agradecer a todas as pessoas que me ajudaram a atingir este objetivo e que contribuíram de várias formas para a pessoa que sou neste momento.

Em primeiro lugar, quero agradecer aos meus pais, Fátima Santos e José Sousa, que sempre estiveram presentes para todas as ocasiões e que fizeram com que hoje, eu, possa dizer que sou um engenheiro informático.

Em segundo lugar, quero agradecer ao meu irmão, Henrique Sousa, por todos os ensinamentos transmitidos durante os anos da minha vida e pelos fantásticos conselhos dados durante a minha licenciatura e mestrado em engenharia informática.

Em terceiro lugar, quero agradecer ao meu amigo, Carlos Sousa, que desde a licenciatura me acompanhou neste percurso académico e que, neste momento, trabalha comigo na 4ALL Software. Obrigado por todas as risadas, apontamentos e ensinamentos que me transmitiste durante este percurso académico.

Por último, quero agradecer à Universidade de Trás-os-Montes e aos seus professores, em especial o professor Luís Filipe Barbosa, por toda a informação transmitida durante a licenciatura e mestrado. Obrigado por me terem tornado num engenheiro informático competente e profissional.

x

Ab

Abstrato

Este relatório tem como objetivo expor o Estágio Profissional desenvolvido na empresa 4ALL Software, que foi realizado com o propósito de obter o grau de Mestre em Engenharia Informática pela Universidade de Trás-os-Montes e Alto Douro. O relatório em questão relata o projeto desenvolvido durante este estágio que incidiu sobre a área de suporte ao cliente e suporte à infraestrutura de uma entidade. Esta prestação de suporte por parte da entidade é uma atividade comum entre todo o tipo de empresas e instituições que sem o auxílio de um sistema que monitoriza todas as mensagens e conversas entre a entidade e o cliente ocupa muito tempo e produtividade de um funcionário. Para resolver tal necessidade surgiram as plataformas ou sistemas de tickets que tornam o suporte mais fácil, eficaz, organizado e eficiente. Assim, o estágio relatado deu a conhecer aos estagiários um novo sistema de tickets, bem como novas linguagens de programação, ferramentas e tecnologias anteriormente desconhecidas.

xii

Ab

Abstract

This report aims to expose the professional internship developed in the company 4ALL Software. This internship was performed with the purpose of obtaining the Masters degree in Software Engineering in the University of Trás-os-Montes and Alto Douro. The following report describes the project developed during the internship that focused on the customer support and infrastructure support area of an entity. This provision of support by an entity is a common activity done between all type of companies and institutions that without the aid of a system that monitors all entity-customer interactions takes up a lot of employee time and productivity. To address this need, platforms or ticket systems emerged, making que support much easier, effective, efficient and organized. Therefore, this internship provided the knowledge of a new ticket system, as well as new programming languages, tools and technologies that before were unknown to the intern.

xiv

Pc

Palavras-chave

 Desenvolvimento de Software  Serviço de Consultoria Informática  Plataforma de Gestão de Serviços TI  Sistema de Gestão de Serviços TI  OTRS

xvi

Kw

Keywords

 Software Development  IT Consulting

 IT Services Management Platforms  OTRS

xviii

“Try not to become a man of success, but rather try to become a man of value.”

Albert Einstein (1879-1955)

xx

ÍG

Índice geral

Índice de figuras ... xxii

Acrónimos e Definições ... xxiv

1. Introdução ... 1

1.1. Enquadramento ... 1

1.2. Motivações e Objetivos ... 2

1.3. Metodologia de Trabalho ... 3

1.4. Estrutura do Relatório de Estágio ... 4

2. 4All Software ... 5

2.1. Enquadramento Institucional ... 5

2.2. Metodologia de Trabalho da Empresa ... 7

2.3. Sistemas e Tecnologias Utilizadas no Suporte à Atividade ... 8

2.4. Resumo ... 10

3. Open-Source Ticket Request System - OTRS ... 11

3.1. Enquadramento ... 11 3.1.1. Satisfação do cliente ... 11 3.1.2. Produtividade do Agente ... 12 3.1.3. Benefícios Empresariais ... 12 3.2. O Sistema OTRS ... 13 3.2.1. Funcionamento do sistema ... 14

xxi

3.3. Metodologia de Trabalho ... 17

3.4. Ferramentas e Tecnologias Utilizadas ... 18

3.4.1. VirtualBox ... 18 3.4.2. Linux ... 18 3.4.3. Perl ... 18 3.4.4. JavaScript ... 19 3.4.5. Template Toolkit ... 19 3.4.6. Freedcamp ... 19 3.4.7. MySQL ... 20

3.4.8. Extensible Markup Language (XML) ... 20

3.5. Tarefas Realizadas ... 21

3.5.1. Migração do OTRS ... 21

3.5.2. Integração com Sistemas Externos ... 23

3.5.2.1. Sistema de Voz sobre IP ... 23

3.5.2.2. Sistema de Alarmística ... 24

3.5.2.3. Sistema de Backups ... 25

3.5.2.4. Generic Agent ... 26

3.5.3. Módulos Complementares ... 28

3.5.3.1. O Fluxo dos Módulos ... 28

3.5.3.2. Módulo de Impressão de Modelos ... 29

3.5.3.3. Módulo de Exclusão Automática ... 35

3.5.3.4. Módulo de Gestão de Alterações TI ... 38

3.6. Resumo ... 44

4. Conclusões ... 48

4.1. Aprendizagens Realizadas ... 48

4.2. Dificuldades Sentidas ... 49

4.3. Conhecimentos Pré-Adquiridos Vs. Tarefas Realizadas ... 50

4.4. Considerações Finais ... 51

Referências bibliográficas ... 53

Sobre o autor ... 56

xxii

ÍF

Índice de figuras

Figura 1 4ALL Software Logo ... 5 Figura 2 Visualização Geral do Ticket ... 14 Figura 3 Arquitetura do OTRS ... 16 Figura 4 Filtro Email de Backup ... 26 Figura 5 Generic Agent - Execução automática ... 27 Figura 6 Generic Agent – Condições ... 27 Figura 7 Generic Agent - Mover ticket para a nova fila ... 27 Figura 8 Diagrama de fluxo de um módulo ... 28 Figura 9 Nova aba adicionada ... 29 Figura 10 Botão implementado em XML ... 30 Figura 11 Registo de um Módulo ... 30 Figura 12 Reencaminhamento do ficheiro ... 31 Figura 13 Criação do documento e parametrização ... 31 Figura 14 Criação e escrita da primeira página ... 32 Figura 15 Invocar função de campos dinâmicos ... 32 Figura 16 Recolher campos dinâmicos ... 32 Figura 17 Ciclo para imprimir os campos ... 33 Figura 18 Função que verifica o espaço disponível na página ... 34 Figura 19 Documento devolvido ao ficheiro inicial ... 34 Figura 20 Documento devolvido ao utilizador ... 35 Figura 21 Executar um módulo externo com o Generic Agent ... 36 Figura 22 Verificação do ID do ticket e select a base de dados ... 36 Figura 23 Guardar os resultados em um vetor ... 36 Figura 24 Selecionar os anexos dos artigos e eliminar os anexos ... 37 Figura 25 Informar o administrador pelo ficheiro de logs ... 37 Figura 26 Estrutura de uma Alteração no módulo Gestão de Alterações TI ... 38 Figura 27 Visão Geral da Alteração ... 38 Figura 28 Informações adicionais da Alteração ... 39 Figura 29 Menu símbolos OTRS ... 39 Figura 30 Visualização geral de Ordens atribuídas ... 40 Figura 31 Visualização de uma Ordem ... 40 Figura 32 Relatar Ordem ... 41 Figura 33 Estado da Alteração em "Aprovação Pendente" ... 41

xxiii

Figura 34 Condições da Alteração ... 42 Figura 35 Exemplo de uma condição ... 43

xxiv

AA

Acrónimos e Definições

Lista de acrónimos

IDE Integrated Development Environment

OTRS Open-Source Ticket Request System

SVN Apache Subversion

LDAP Lightweight Directory Access Protocol

XML Extensible Markup Language

SGML Standard Generalized Markup Language

HTML Hypertext Markup Language

CSS Cascading Style Sheets

FAQ Frequently Asked Questions

PDF Portable Document Format

Lista de Definições

Palavra Significado(s)

Ticket Conjunto de comunicações e notas entre o Agente e um Utilizador que tem como objetivo resolver um problema que o Utilizador reportou

Open Source Modelo de desenvolvimento de software que disponibiliza o código do software sem qualquer pagamento para examinação e customização ao gosto do programador

Software Conjunto de informação, dados e tarefas para um computador realizar

Switch Dispositivo que reencaminha pacotes numa rede para os vários dispositivos ligados a mesma

IDE Software que facilita a criação e desenvolvimento de software providenciando ferramentas para editar o código e monitorizar o software

xxv

Framework Software que fornece funcionalidades genéricas que podem ser modificadas para algo mais complexo ou concreto por um programador

Interface Uma ligação partilhada entre vários componentes do computador ou entre o computador e o utilizador. Frequentemente utilizada para descrever as várias janelas de um software visto que estas realizam a ligação entre o software e o utilizador

Kernel O Kernel é o core ou núcleo de um sistema operativo. Este executa a base de todo o sistema, possibilita a interação entre os vários software e as componentes físicas da máquina

Patching Sequência de alterações a um programa instalado no computador destinado a melhorar ou corrigir o programa.

1

1

1. Introdução

Este capítulo tem o objetivo de introduzir o estágio realizado, através do enquadramento do mesmo no mestrado realizado, os objetivos e motivações principais, a metodologia de trabalho adotada na realização do projeto e, por fim, a estrutura adotada neste relatório de estágio.

1.1. Enquadramento

O presente documento enquadra-se no âmbito da realização de um Mestrado em Engenharia Informática na Universidade de Trás-os-Montes e Alto Douro, tendo como objetivo a exposição do Estágio Profissional efetuado na empresa, 4ALL Software, de forma a obter o grau de Mestre do curso referido.

Entende-se como Estágio Profissional, a execução de práticas de trabalho devidamente qualificadas no contexto da atividade profissional proporcionando ao estagiário situações reais de trabalho e, aumentando assim, a componente prática de aprendizagem do aluno. A escolha de realização de um estágio profissional em detrimento da realização de uma tese ou projeto foi baseada neste argumento. Cada vez mais, a experiência de trabalho possui um peso maior na seleção de novos funcionários e, como o ensino superior detém uma maior incidência sobre a componente teórica do que a componente prática, a escolha de um estágio profissional proporciona ao aluno conhecimentos que não são possíveis obter em ambiente académico.

A empresa escolhida possui vários projetos inovadores e complexos em áreas relativamente recentes como a realidade aumentada e virtual. Para além disso, possui um conjunto de recursos humanos altamente especializados o que permite a repartição de projetos em componentes distintas resultando em um desenvolvimento rápido e eficaz.

2

1.2. Motivações e Objetivos

Este projeto surgiu devido a versão utilizada pela entidade ficar descontinuada, ou seja, a versão 5 do OTRS deixou de receber atualizações, e como tal é necessário atualizar o sistema de modo a garantir a segurança dos dados . Anteriormente, a entidade utilizava o OTRS em dois departamentos, o departamento de informática e o departamento de recursos humanos, sendo que, com esta atualização, a entidade planeia expandir o sistema para aglomerar novos departamentos como o departamento técnico e financeiro, utilizando o OTRS como um sistema que unifica todas as informações de suporte da entidade. Como não possuíam funcionários qualificados para a configuração do sistema deste nível, recorreram a ajuda da 4ALL Software.

O projeto em si teve os seguintes objetivos:

 Diminuir o tempo de resposta a tickets/emails recebidos pela entidade;

 Facilitar a partilha de informação e o reencaminhamento de tickets/emails entre os vários departamentos da entidade;

 Possibilitar a criação de relatórios automáticos para melhor controlo interno;  Melhorar a gestão de alterações na infraestrutura da entidade;

 Reduzir o peso em termos de processamento do OTRS no servidor da entidade. Enquanto que, o estágio profissional teve os seguintes objetivos:

 Analisar o funcionamento da empresa de desenvolvimento de software;  Aprimorar e executar os conhecimentos adquiridos no ensino superior;  Obter experiência e conhecimentos novos;

 Aprimorar a capacidade de trabalho em equipa;  Obter bons hábitos de trabalho.

3

1.3. Metodologia de Trabalho

No desenvolvimento deste projeto foram adotadas duas metodologias de desenvolvimento de

software, sendo o primeiro o modelo de desenvolvimento de software em cascata e o segundo,

que foi utilizado em conjunto com o primeiro modelo nas últimas fases deste, o modelo de integração contínua.

O modelo de desenvolvimento de software em cascata é caracterizado por definir várias fases que têm de ser concluídas de forma consecutiva, ou seja, só é possível avançar para a próxima fase se a fase anterior a essa já se encontra concluída (Youssef Bassil, 2012). A grande vantagem de tomar esta abordagem em relação a este projeto é que este modelo coloca ênfase na produção de documentação e de código fonte (código com comentários e escrito de um forma rápida à compreensão humana). Em outras metodologias onde o planeamento e documentação são menos pensados, a perda de um elemento da equipa antes do projeto estar concluído resulta em perda de conhecimentos, resultando numa maior dificuldade de recuperação dessa perda. No caso do modelo de desenvolvimento de software em cascata existe, normalmente, um documento sempre atualizado com documentação sobre o que foi feito e a adição de um novo membro na equipa ou até mesmo a alocação de uma equipa nova ao projeto deve ser mais fácil devido aos documentos produzidos (Arcisphere technologies, 2012). O modelo original divide o desenvolvimento de software em cinco fases, o levantamento de requisitos do software; a análise desses requisitos que resulta em diagramas, esquemas e regras do software; a implementação dos requisitos planeados resultando no software em si, a verificação do software com os requisitos planeados, averiguando assim se tudo o que foi planeado foi concretizado; e a manutenção, providenciando suporte ao software e ao cliente com qualquer erro que apareça.

Nas últimas fases do modelo anterior, foi adotado outro modelo de desenvolvimento de

software denominado de modelo de integração contínua. O modelo de integração contínua é

uma prática de desenvolvimento de software onde os membros da equipa integram o trabalho realizado frequentemente. Cada integração é verificada por um programa auxiliar que realiza testes para detetar erros de integração. Muitas equipas defendem que esta abordagem resulta numa redução de problemas com integrações e permite o desenvolvimento de software concisos rapidamente. (Martin Fowler, 2006). O modelo de integração contínua permite as equipas desenvolver o software de uma forma mais concisa e mantem as mesmas informadas sobre o que estava a ser desenvolvido e o que já foi desenvolvido.

4

1.4. Estrutura do Relatório de Estágio

O presente relatório de estágio está dividido em quatro capítulos, a Introdução, que pretende informar ao leitor sobre o tema do relatório e projeto realizado, a 4All Software, que pretende apresentar a empresa ao leitor e informar sobre os métodos utilizados na empresa para o desenvolvimento de software e da experiência que foi trabalhar lá, o Open-Source Ticket Request System - OTRS, onde é explicado no que consiste este software e a sua arquitetura, bem como as ferramentas utilizadas no projeto fornecendo uma breve explicação das mesmas e todo o desenvolvimento feito para a realização das tarefas definidas, e as Conclusões, onde é explicado as aprendizagens adquiridas e dificuldades encontradas e é realizada uma comparação dos conhecimentos pré-adquiridos e o que foi necessário para a realização das tarefas apresentadas.

5

2

2. 4All Software

Figura 1 4ALL Software Logo

A 4ALL Software é uma empresa dedicada ao desenvolvimento e comercialização de software fundada em 2009 e sediada no parque de ciências e tecnologia “Régia-Douro Park”. A empresa oferece serviços como consultoria, desenvolvimento de sistemas colaborativos, soluções web, jogos digitais e realidade mista e virtual. Neste momento conta com uma equipa de dezasseis profissionais, sendo doze programadores, três designers e o CEO e gestor Benjamim Fonseca.

2.1. Enquadramento Institucional

A 4ALL Software é uma empresa privada que resultou numa spin-off da Universidade de Trás-os-Montes e Alto Douro resultando numa ligação a projetos de investigação e projetos universitários. A empresa possui como principais produtos os seguintes:

I. SOSPhone

• O SOSPhone é uma aplicação móvel que foi desenvolvida inicialmente em 2015 e entretanto teve várias evoluções e versões. A aplicação é dirigida a pessoas que necessitam de utilizar linguagem não verbal para comunicar. Sendo assim, a aplicação permite contactar os serviços de emergência sem ser necessário utilizar uma chamada de voz através da sua interface de rápida e fácil

6

compreensão. Depois de selecionar a chamada de emergência, o utente descreve a emergência através de ícones que surgem ao longo do atendimento da chamada na interface da aplicação e, no final, é gerada uma mensagem automática com os detalhes da emergência, a localização do utente e a identificação do mesmo. II. Race Masters

• O Race Masters é uma aplicação móvel dirigida aos amantes dos desportos motorizados que foi inicialmente desenvolvida em 2016 com a realização do 46º Circuito Internacional de Vila Real – WTCC – nos dias 24, 25 e 26 de junho. A aplicação agrega todos os resultados e classificações das principais competições motorizadas e acompanha em direto as mesmas para tempos e resultados em tempo real.

III. CHOVER

• O Chover foi uma aplicação móvel desenvolvida que prestava serviços eletrónicos na área do transporte privado urbano. A aplicação foi desenvolvida em 2017 com o objetivo de concorrer com a Uber e a Cabify. Esta realizava a ligação entre motoristas e passageiros atuando como intermediário neste serviço e facilitando o fornecimento do mesmo. Providenciava também uma fácil gestão de rendimentos para os motoristas e a identificação rápida de locais onde o serviço estava a ser mais requisitado.

IV. 4Lab

• O 4Lab é uma plataforma web para gestão de análises que permite a empresa guardar os dados das suas análises de forma segura e rápida, estando sempre acessível através da web. O desenvolvimento da plataforma começou em 2018 como uma solução privada onde só era possível registar análises microbiológicas. Meio ano depois, a plataforma foi generalizada para abranger diferentes áreas no setor das análises. A plataforma oferece a produção de relatórios dinâmicos em tempo real para as análises concluídas, possibilidade do cliente ver todas as suas análises e o estado das mesmas em tempo real e adição dinâmica de diferentes tipos de análises com parâmetros únicos para tipo.

7

2.2. Metodologia de Trabalho da Empresa

Como dito anteriormente, a 4ALL Software está localizada no parque de ciências e tecnologia, Régia-Douro Park, e neste momento, detém três salas todas equipadas com internet fornecida pelo parque de cem megabits por segundo. As salas podem ser acedidas a qualquer hora através da chave ou de um sistema utilizado em todos os edifícios de impressão digital. Todos os funcionários possuem um computador fixo no local de trabalho com bom hardware e dois ecrãs de vinte e quatro polegadas bem como um rato e teclado.

Quanto a metodologia de gestão de projetos adotada na empresa, em cada projeto existe uma divisão das funcionalidades em detrimento das qualificações dos funcionários envolvidos, sendo que o funcionário com maior experiência e conhecimento fica encarregue de gerir o projeto em mãos e fornecer suporte quando necessário ao resto dos elementos da equipa. Cada equipa faz reuniões semanais para avaliar o trabalho feito e atribuir novas tarefas aos elementos da mesma. O funcionário encarregue pela gestão da equipa depois reporta ao CEO o progresso realizado e atualizações que possam ter surgido no desenvolvimento do projeto, sendo que também é possível que o CEO assista a reunião da equipa para estar mais informado do progresso realizado. Entre o cliente e a empresa, normalmente apenas existe comunicação entre o funcionário encarregue de gerir o projeto e o CEO. Para além disso, também são realizadas reuniões mensais com o cliente de forma a alinhar todas as tarefas com as necessidades pedidas e manter o mesmo a par do progresso realizado.

8

2.3. Sistemas e Tecnologias Utilizadas no Suporte à Atividade

Para auxiliar todo o progresso de desenvolvimento de software a empresa utiliza os seguintes

softwares:

1. Microsoft Windows 10

Microsoft Windows 10 é uma das versões do popular sistema operativo Windows. Windows é um sistema operacional multitarefas desenvolvido para funcionar numa variedade de computadores, servidores e computadores construídos para aplicações técnicas ou científicas (William Stallings, 2012), que tem como objetivo funcionar como um intermediário entre o utilizador do computador e o hardware do computador (Gyöngyi Bujdosó, 2017). Na empresa o Windows 10 é o sistema operativo utilizado por defeito em todos computadores dos funcionários, fornecendo uma base para todos os programas necessários para o desenvolvimento de soluções que os clientes necessitem.

2. Microsoft Visual Studio 2019

Microsoft Visual Studio é um IDE desenvolvido pela Microsoft utilizado para desenvolver programas de computador, sites, aplicações móveis e serviços web. Este foi primeiramente disponibilizado em 2002 com a sua primeira versão Visual Studio .NET que era uma combinação de várias ferramentas que a Microsoft já disponibilizava (Nick Randolph, David Gardner, Chris Anderson, Michael Minutillo, 2010) para o desenvolvimento de programas. Este IDE é utilizado por todos os programadores da empresa para desenvolver a maior parte do software porque fornece ferramentas como o Intelissense, uma ferramenta que ajuda a completar o código que o programador está a escrever sugerindo palavras ou expressões utilizadas regularmente ou uma certa estrutura, Emuladores, permite ao sistema fazer-se passar por outro sistema ou dispositivo (por exemplo: telemóveis) facilitando o desenvolvimento de aplicações ou programas que pretendem funcionar no dispositivo emulado, e Depuradores, um depurador é uma ferramenta que permite ao programador monitorizar o programa enquanto ele está em execução, permitindo verificar se o programar está a funcionar como desejado.

3. TortoiseSVN com extensão para Visual Studio 2019

O TortoiseSVN é um controlador de versões popular e fácil de usar para o Microsoft Windows. É uma extensão da Windows Shell e não está limitado por nenhum IDE

9

(Lesley Harrison, 2011), ou seja, pode ser usado por diferentes IDE’s no desenvolvimento de software. Um controlador de versões é um sistema que soluciona o problema de ter vários programadores a trabalhar sobre o mesmo projeto (Lesley Harrison, 2011), mantendo todo o trabalho num repositório separado dos programadores e várias cópias desse mesmo no computador dos programadores. Este gere as várias versões do software que está a ser desenvolvido ao atualizar a cópia que se encontra no repositório quando um dos programadores decide realizar um commit (enviar as várias alterações efetuadas). Sempre que é realizado um commit, o sistema verifica se existem outras alterações efetuadas pelos programadores que a versão que está a realizar o

commit não possua. Caso não possuir, este é obrigado a atualizar primeiramente a cópia

que detém para a mais recente e, só depois é que pode realizar o commit. Assim, existe sempre uma cópia do trabalho atualizada num repositório e, se houver problemas, é possível reverter as alterações efetuadas para a versão anterior. O sistema também permite tratar de conflitos que acontecem quando duas pessoas alteraram o mesmo ficheiro, fornecendo um ficheiro novo com a informação presente nos dois ficheiros anteriores.

4. Microsoft Teams

Microsoft Teams é uma plataforma que permite a equipa ter todas as conversas, ficheiros, agendamento de reuniões e realização de chamadas na mesma plataforma que está disponível para telemóvel e computador. É utilizado na empresa diariamente para comunicação e partilha de ficheiros rápida, evitando a deslocação do funcionário e a interrupção de raciocínios lógicos que são necessários para o desenvolvimento de um projeto.

5. Microsoft Windows Server 2019

Microsoft Windows Server 2019 é a última versão da série de sistemas operativos que são totalmente desenvolvidos para operar dentro de um servidor (sistema de computação que fornece serviços a outros computadores ou a uma rede de computadores designados de clientes) da empresa Microsoft. Este sistema operativo é utilizado no servidor local para fornecer projetos aos computadores utilizados pelos programadores. Para além disso, detém o repositório do TortoiseSVN, guardando também todas as versões de todos os projetos e controlando as atualizações e commits das equipas.

10

2.4. Resumo

Em suma, a 4ALL Software é uma empresa privada fundada em 2009 que resultou de uma spin-off da Universidade de Trás-os-Montes e Alto Douro. Esta dedica-se ao desenvolvimento de

software, oferecendo serviços como consultoria, soluções web, jogos digitais e realidade mista

e virtual. A empresa tem crescido rapidamente nos últimos anos possuindo, neste momento, dezasseis funcionários qualificados e uma série de produtos no seu histórico que envolvem diferentes áreas do setor informático como websites, aplicações móveis e plataformas. Em termos de gestão de projetos, normalmente o membro mais experiente, ou seja, com um maior nível de senioridade, é o membro que assume a responsabilidade de gerir o projeto e realiza a maior parte da comunicação entre a equipa e o CEO. Para finalizar, na empresa são usados vários sistemas e tecnologias que auxiliam ao desenvolvimento de software como o Windows 10, Microsoft Visual Studio 2019 e o controlador de versões TortoiseSVN.

11

3

3. Open-Source Ticket Request System - OTRS

Este capítulo pretende informar o leitor da plataforma de suporte utilizada na entidade, explicando o porquê da utilização das mesmas e os principais benefícios que estas trazem tanto para a instituição como para o cliente. De seguida, é descrita a plataforma de suporte utilizada neste projeto e explicado o seu funcionamento. Para finalizar são descritos os módulos elaborados neste projeto, bem como as integrações realizadas com vários sistemas externos ao OTRS e a migração efetuada da versão cinco para a versão seis do OTRS.

3.1. Enquadramento

A prestação de suporte é uma atividade comum a diversas instituições e empresas devido ao fornecimento de serviços que podem gerar dúvidas ao utilizador. Para tal, estas contratam funcionários capazes para fornecer o respetivo suporte. As plataformas de suporte ou sistemas de tickets auxiliam nesta atividade permitindo às empresas centralizar, registar e responder a todas as solicitações efetuadas dentro de um contexto empresarial de prestação de serviços (Sarita Souza, 2013), tornando o suporte organizado, eficiente e eficaz. As principais vantagens são discutidas nos seguintes tópicos.

3.1.1. Satisfação do cliente

Um sistema de tickets converte todas as comunicações com o cliente em tickets, mantendo os pedidos organizados para os agentes (funcionários da empresa/instituição) e, consequentemente, diminui o tempo de resolução de tickets. Para além disso, o envio de atualizações sobre o estado do pedido efetuado pelo cliente é facilmente efetuado, resultando num cliente informado e, por isso, mais satisfeito. Por último, o sistema de tickets oferece um canal único de comunicação com o cliente, registando comunicações por email, voz, videoconferência ou por contacto físico, o que resulta numa listagem de todas as comunicações efetuadas em que, tanto o agente como o cliente, podem consultar.

12 3.1.2. Produtividade do Agente

A criação de tickets ocupa uma porção do tempo gasto ao realizar suporte ao cliente. Os sistemas de tickets eliminam esta porção do tempo gasta ao criar automaticamente tickets quando o cliente entra em contacto com a empresa ou instituição, aumentando a produtividade do agente. Além disso, como todos os pedidos realizados pelo cliente encontram-se num sistema ou plataforma unificada, o agente consegue ter acesso a todos os dados do cliente (informações pessoais, histórico de interações), proporcionando uma resolução rápida do pedido.

3.1.3. Benefícios Empresariais

Os sistemas de tickets permitem gerar relatórios dinâmicos, facilitando o trabalho de supervisores na monitorização dos agentes. Também é possível estabelecer acordos de nível de serviços, garantindo a resolução rápida de pedidos que têm uma prioridade maior.

13

3.2. O Sistema OTRS

O sistema de gestão de serviços e apoio ao cliente utilizado para este projeto foi o OTRS visto que o cliente já utilizava este sistema para gestão interna em diversos departamentos. O OTRS é um sistema de gestão de serviços que engloba ticketing, automatização de processos e notificações. O sistema gere, organiza e regista todas as solicitações de suporte e respostas num único lugar (OTRS Team, 2019). Para além disso, para cada pedido o sistema gera um número único e envia uma resposta automática para o cliente notificando-o que o pedido foi recebido e vai ser respondido em breve (OTRS Team, 2019). O sistema pode ser instalado num web server e ser utilizado através do navegador de internet e, por norma, é utilizado por empresas para prestar apoio aos clientes aumentando assim a organização interna.

O projeto OTRS começou em 2001 como um projeto open source. Segundo o site do OTRS, neste momento nenhum dos fundadores pensava que o projeto teria sucesso e colocaram o código do projeto como open source na internet onde alguns programadores se juntaram para melhorar algumas características do mesmo. Passado dois anos, o projeto começou a desenvolver características mais profissionais e foi fundado o grupo “OTRS GmbH”. Nesse mesmo ano a empresa começou a operar internacionalmente e o Escritório Federal de Segurança da Informação da Alemanha começou a utilizar o “OTRS”. Em 2006, o grupo “OTRS” continua a expandir-se e entra no mercado da América do Norte e em 2007 mudam o seu nome para “OTRS AG” devido às limitações da última empresa. De 2007 a 2009 a empresa realizava vários eventos de promoção ao seu software e em 2009 entra no mercado da América Latina. O software continua a ser melhorado num ambiente open source e em 2010 volta a entrar em outro mercado, desta vez na Ásia. Entre 2010 e 2018 abrem seis subsidiárias, Estados Unidos da América, México, Singapura, Asia, Hong Kong, Brasil e Budapeste, sendo que a sede principal do grupo continua a ser na Alemanha. De momento, a empresa conta com mais de 170 mil empresas a utilizar o seu software e o mesmo continua a ser desenvolvido e melhorado.

O software OTRS está dividido em duas versões. A Community Edition, versão gratuita do OTRS que conta com uma comunidade ativa de utilizadores que partilham informação e desenvolvimento através de um fórum. A Business Solution, que foi lançada em 2015, é uma versão contruída para utilizadores profissionais que necessitam de suporte, configurações e funcionalidades adicionais. A versão utilizada neste projeto foi a Community Edition.

14 3.2.1. Funcionamento do sistema

O OTRS é um sistema que funciona através do navegador de internet. Para o agente aceder ao sistema é necessário navegar até ao endereço onde o sistema está alocado e realizar o início de sessão. Este início de sessão pode ser confirmado pelo próprio OTRS acedendo à base de dados ou por um LDAP. Com a sessão iniciada, o Agente é automaticamente redirecionado para a página principal do sistema que apresenta várias tabelas referentes aos vários tipos de tickets. O sistema é intuitivo, sendo que para responder ao ticket carrega-se no mesmo e o Agente é redirecionado para a visão geral [

Figura 2]. Aqui é possível visualizar detalhes do ticket e os vários artigos (interações entre o cliente e a instituição) que compõem o ticket. Se o ticket estiver bloqueado a um Agente, só esse é que pode realizar interações com o cliente, caso contrário é possível responder ao ticket e realizar outras ações.

Figura 2 Visualização Geral do Ticket

O OTRS funciona com base em filas e permissões sobre essas filas, fazendo uma rápida distinção de quais os agentes têm acesso aos tickets. Por exemplo, a entidade criou duas filas, uma para o suporte ao público e outra para assuntos da administração. Associado a estas filas existem um grupo de permissões e, como tal, os agentes pertencentes à administração têm associado a eles o grupo de permissões da fila de administração e as permissões da fila suporte

15

ao público. Enquanto que um funcionário fora da administração apenas tem associado as permissões da fila de suporte ao público.

Para além disso, é possível especificar os serviços fornecidos pela instituição e associá-los as filas disponíveis para que seja mais fácil identificar o assunto do ticket. Assim, é possível filtrar os tickets pelos serviços disponibilizados ou até atribuir automaticamente um ticket a um agente através do serviço pedido pelo cliente. Para complementar os serviços, é possível associar uma SLA. Um SLA ou Acordo de Nível de Serviço é utilizado como um contracto entre um fornecedor de serviços e um consumidor para assegurar a qualidade do serviço (Wu & Buyya, 2012). O SLA é composto por um tempo de resposta, tempo de atualização e tempo de resolução. É possível adicionar notificações para quando estes tempos atingirem alguma percentagem (p.e. 50% do tempo de resolução), para que os tempos sejam atingidos e o cliente fique satisfeito.

Para além de responder a tickets, o sistema possui funcionalidades adicionais como calendários para cada grupo de utilizadores onde é possível criar compromissos gerais ou apenas para um único agente, um sistema de FAQ para ajudar os agentes na resposta de tickets e um sistema de inquéritos para a realização de inquéritos sobre aspetos que a instituição deseje averiguar.

Em termos arquiteturais, o OTRS é uma framework modular [Figura 3], ou seja, este permite a adição de extensões que contribuem para as diferentes páginas ou a adição de páginas novas. Isto resulta num sistema com uma enorme flexibilidade para os desenvolvedores e permite o melhoramento e ajustamento do sistema conforme as necessidades dos utilizadores.

O OTRS pode receber tickets de três formas, através de uma conta de email que ele tem acesso, através de um web service criado (o OTRS possui a funcionalidade de criar vários web services dentro do sistema para realização de logins, criação de tickets, alterações de tickets, entre outros) e através de um portal disponibilizado pelo sistema para clientes. Cada uma destas formas tem um módulo correspondente que está referenciado no módulo core do sistema. A seguir temos uma figura que simplifica toda a arquitetura do OTRS em diretorias.

16

Figura 3 Arquitetura do OTRS

Para atingir entre modularidade, o OTRS utiliza linguagens como perl para a execução de módulos dentro do sistema. Um módulo perl é um ficheiro que utilizada pacotes de declarações para criar o seu próprio “espaço” (namespace). Módulos perl adicionam um nível extra de proteção contra colisões entre nomes (James Tisdall, 2003). Em conjunto com a linguagem perl temos a linguagem de marcação XML que tem a função de construir a interface do utilizador.

A linguagem XML é um subtipo da linguagem de marcação SGML (Murata et al, 2001) que tem o propósito fundamental de descrever informações. Esta capacidade é extremamente importante para o armazenamento, recuperação e transmissão de informações (Otávio Décio, 2000). Para além disso, a linguagem fornece um formato textual que pode ser facilmente entendido quando olhado diretamente (Otávio Décio, 2000). Todas as interações que o utilizador tem com o sistema estão definidas na linguagem XML que aciona módulos em perl. Associado aos módulos perl podemos ter janelas que resultam da execução dos módulos. As janelas são uma combinação da linguagem template toolkit; um sistema de processamento de modelos rápido, flexível e extensível escrito em perl e totalmente gratuito (Andy Wardley, 2014), que combina elementos da linguagem de programação C para aumentar a sua velocidade

17

e marcas do linguagem HTML; juntamento com javascript; linguagem de programação interpretada de alta nível (David Flanagan, 2002), sendo frequentemente utilizada com a linguagem HTML para a criação de páginas web interativas; e CSS, um mecanismo simples para adicionar estilos como fontes, cores e espaçamento a um documento web (W3C Team, 2019).

3.3. Metodologia de Trabalho

Neste projeto, como dito anteriormente, estiveram envolvidos três programadores (incluindo eu), e uma designer. Dois dos programadores são programadores júnior e o terceiro programador é um programador sénior que ficou a gerir o projeto e forneceu ajuda quando necessário. Como o projeto consistiu no melhoramento ao sistema já implementado na entidade, o desenvolvimento deste não necessitou de uma análise e especificação do software e requisitos do mesmo. A entidade elaborou um caderno de encargos com todas as atividades incluídas à prestação de serviço efetuado pela 4All, evitando assim a fase de levantamento de requisitos. Eu, como programador júnior, fiquei encarregue do desenvolvimento de qualquer módulo auxiliar que fosse necessário para concretizar os encargos pedidos pela entidade, da configuração das filas, permissões e modelos de resposta do sistema OTRS, da migração do sistema atual para a nova versão do OTRS em conjunto com o segundo programador júnior e da integração do OTRS com vários os sistemas externos que a entidade possui. Como dito anteriormente, ao longo do projeto foram realizadas reuniões internas semanalmente de forma a controlar as tarefas realizadas e distribuir novas, e reuniões com a entidade para informar do progresso realizado e alinhar as funcionalidades com a visão da entidade.

18

3.4. Ferramentas e Tecnologias Utilizadas

Oracle VM VirtualBox é uma software open source multiplataforma desenvolvido pela Oracle Corporation. Este permite a execução de várias máquinas virtuais que foram criadas em um computador noutro computador com um sistema operativo diferente do computador original, por exemplo, é possível criar uma máquina virtual no Windows e depois executar a mesma no Linux (Biju Mohan, Deepak Damodaran, 2012). Isto é alcançado através de um processo chamado Virtualização. Virtualização é uma framework que divide os recursos de um computador para ser possível a execução de múltiplos ambientes ao mesmo tempo. Mais especificamente, é uma camada de software que providencia a ilusão de uma máquina real para os múltiplos ambientes em execução (Biju Mohan, Deepak Damodaran, 2012). No caso deste projeto, a VirtualBox permitiu a execução do sistema operativo Linux, versão Ubuntu, na máquina da empresa que tem por defeito o Windows 10 e permitiu a realização de backups das máquinas virtuais, tendo sempre uma cópia de segurança com as últimas tarefas realizadas pela equipa.

3.4.2. Linux

Linux é uma família de sistemas operativos open source construídos em torno do kernel do Linux. A componente que define uma versão do Linux é o kernel desse mesmo, um kernel (…) que foi primeiramente publicado em 17 de setembro de 1991 pelo Linus Torvalds (Dharmarajula Jagadeesh, 2018). Neste projeto, o Linux foi utilizado como sistema operativo nas máquina da entidade e, portanto, foi necessário instalar este sistema operativo nas nossas máquinas (programadores), para que seja possível a utilização do OTRS e para simular o ambiente das máquinas da entidade. Para tal, foi utilizado o VirtualBox, evitando a instalação desse mesmo sistema operativo nas nossas máquinas e possibilitando a passagem da máquina virtual para outro computador.

3.4.3. Perl

Perl é uma linguagem de programação desenvolvida em 1987 por Larry Wall. Esta linguagem é a linguagem nativa do OTRS e toda a lógica do sistema, bem como todos os módulo auxiliares, estão escritos em perl. Perl é considerada ser uma linguagem de alto nível devido à grande abstração que esta tem do hardware do computador e a sua estrutura deriva grande parte da linguagem C. Normalmente, os sistemas em perl estão divididos em módulos de programas de

19

perl. Um módulo de perl adiciona uma camada extra de proteção devido a declaração de um namespace através do uso das palavras-chaves “my” e “use strict” (James Tisdall, 2003). Através do uso de módulos, é possível ter uma melhor noção de toda a lógica do sistema e existe uma melhor separação de toda a lógica possibilitando o uso do mesmo módulo para várias aplicações.

3.4.4. JavaScript

Javascript é uma linguagem de programação interpretada com capacidades de uma linguagem orientada a objetos. Sintaticamente, o núcleo do Javascript é semelhante ao de C, C++ e Java, com estruturas de programação semelhantes como o “if”, o ciclo “while”, e os operadores “&&”(David Flanagan, 1996). Javascript é muito utilizado em navegadores, e, nesse contexto, o core do Javascript é extendido com objetos que permitem que os scripts possam interagir com o utilizador, controlar o navegador de internet, e alterar o conteúdo do documento que aparece dentro da janela do navegador da internet (David Flanagan, 1996). Esta linguagem é utilizada em todas as páginas de internet do sistema OTRS e, portanto, é muito importante para o funcionamento do sistema e a aparência do mesmo para o utilizador final.

3.4.5. Template Toolkit

Template Toolkit é um sistema de processamento de modelos completamente baseado em perl. A diferença deste sistema em comparação com os outros sistemas de processamentos de modelos que são baseados em perl, é a sua eficiência ao produzir documentos HTML e documentos XML, PDF ou qualquer outro formato (Darren Chamberlain, Dave Cross, Andy Wardley, 2004). O OTRS utiliza este sistema para produzir todo o tipo de documentos como páginas de internet e documentos em PDF e, como tal, foi importante aprender esta linguagem para entender como o OTRS gera as suas páginas de internet e poder customizá-las se tal fosse necessário.

3.4.6. Freedcamp

Freedcamp é uma plataforma web, disponível em dispositivos móveis e em programa de computador, que auxilia na gestão de projetos e providencia um sistema de colaboração para equipas de desenvolvimento de software. Neste projeto, o Freedcamp foi utilizado para registar todas as tarefas, indicando se a tarefa já estava concluída, em progresso ou por iniciar; a pessoa encarregue da realização da tarefa; o tempo que cada tarefa demorou a concluir (assumindo que o registo de horas é realizado através do cronómetro); quando esta foi criada e quando a mesma

20

deve ser finalizada (permite estipular tempos e visualizar se estes foram concluídos com sucesso) e para partilha de documentos entre a equipa.

3.4.7. MySQL

Como a maior parte dos programas e sistemas computacionais, o OTRS também utiliza base de dados para armazenamento de todos os tickets recebidos, informação dos clientes e dos agentes, dados dos calendários, entre outros. Uma base de dados é uma coleção de dados guardados de uma forma lógica e coerente com significado específico para um certo sistema ou programa. O MySQL é um sistema de gestão de base de dados relacionais. O sistema do MySQL controla todos os acessos feitos aos dados e assegura que não existem colisões quando vários utilizadores estão a trabalhar em paralelo nesses dados, providenciado rápido acesso aos dados e níveis de permissões sobre os utilizadores de modo a gerir os utilizadores que têm acesso aos dados (Luke Welling & Laura Thomson, 2003). Este sistema do MySQL permitiu que nós, programadores, pudéssemos alterar os dados dos utilizadores do sistema antigo de OTRS que a entidade usava e analisar como a base de dados do OTRS funcionava.

3.4.8. Extensible Markup Language (XML)

Extensible Markup Language, abreviado XML, descreve uma classe de objetos de dados

designada de documentos XML que descreve o comportamento de programas de computador que processam estes documentos. Documentos XML são construídos por unidades de armazenamento chamadas entidades que possuem dados. O XML providencia um mecanismo que impõe restrições no armazenamento de dados no layout e na estrutura lógica das páginas web (Tim Bray, Jean Paoli, C. M. Sperberg-McQueen, 1999). O sistema OTRS utiliza esta linguagem na definição de funcionalidades dentro de uma página web, indicando com o mesmo as permissões necessárias para utilizar a funcionalidade, para onde a funcionalidade deve redirecionar, a restrição na passagem de dados entre páginas e módulos através das funcionalidades e a posição da mesma em termos de estrutura de navegação do sistema.

21

3.5. Tarefas Realizadas

Durante o desenvolvimento deste projeto eu, Mário Sousa, como programador júnior, concluí os seguintes encargos:

1. Instalação e configuração do módulo de ITSM (Módulo de gestão de serviços proprietário do OTRS) alargado aos serviços comuns da entidade (Serviços de Informática, Recursos Humanos, Financeiros, entre outros);

2. Integração com o serviço VoIP utilizado na entidade, nomeadamente das linhas de apoio dos serviços e contactcenter com integração ao voice-mail e videoconferência web via plataforma criada pela entidade;

3. Integração com os serviços de monitorização e alarmística da entidade;

4. Desenvolvimento de um módulo para criação de documentos configuráveis em função do pedido (PDF);

5. Produção de manuais de boas práticas e funcionamento;

6. Produção de relatórios de instalação e manuais de administração;

7. Atualização do software para a versão mais recente disponível de forma gratuita; 8. Workshop/ação de capacitação e divulgação do software aos funcionários da entidade

para estes serem capazes de utilizar o OTRS e explicar as novas funcionalidades da nova versão.

3.5.1. Migração do OTRS

O OTRS 5.0.15 era a versão utilizada pela entidade até este projeto. Esta versão, apesar de ser estável e muito popular entre a comunidade do OTRS, vai deixou de receber atualizações devido ao lançamento do OTRS 6 em novembro de 2017 e ao desenvolvimento do OTRS 7, uma nova versão que começou a ser trabalhada em 2019 (OTRS Team, 2019).

Como tal, é necessário atualizar para a última versão do OTRS 6 disponível, sendo esta a versão 6.0.15. Nesta versão foram implementados e melhorados vários aspetos do sistema. A interface foi complemente remodelada, sendo esta mais apelativa tanto para o cliente como para o Agente; foram adicionadas várias opções novas na resposta a tickets como a possibilidade de fazer rascunhos para utilizar mais tarde, enviar notificações ao agente que criou o ticket e várias melhorias no sistema de pesquisa de tickets; foi aumentado o desempenho do sistema ao mover várias informações que estavam em ficheiros log para a base de dados; a utilização de web

22

services foi melhorada ao adicionar suporte para respostas de headers adicionais nos protocolos REST e SOAP, novas operações disponíveis (TicketHistoryGet e SessionGet), possibilidade de incluir dados sobre o ticket nas resposta ao pedido, melhoramento da autenticação, proxy e SSL nos protocolos SOAP e REST, entre outros aspetos (OTRS Team, 2019).

Para realizar a atualização do sistema foi necessário primeiramente parar todos os serviços que o OTRS utiliza como o seu serviço de e-mail e serviços de logs e depois realizar uma cópia de segurança da base de dados e dos ficheiros de configuração que o sistema usa como o ficheiro “ZZZAuto.pm” e o ficheiro “Config.pm”. De seguida, a nova versão do OTRS (versão 6) foi descompactada e a pasta da versão anterior foi arquivada enquanto que a pasta da nova versão foi colocada em substituição da pasta da versão anterior. O próximo passo foi copiar todos os ficheiros de configuração da versão anterior para a nova versão, substituindo os ficheiros de configuração que estão por defeito no sistema e por fim, ceder permissões ao utilizador do OTRS (utilizador do sistema Linux) para gerenciar a pasta do OTRS. O quarto passo foi executar um script providenciado pelo OTRS que realiza a migração da base de dados utilizada na versão anterior. Este script muda a estrutura de dados utilizada na versão anterior do OTRS para a nova estrutura utilizada e reorganiza os dados para as novas tabelas da base de dados. Para finalizar a migração, é necessário atualizar os módulos instalados na versão anterior para a nova versão e reiniciar todos os serviços que o OTRS utiliza e que foram parados.

Esta migração foi executada vezes sem conta em máquinas virtuais que simulavam o ambiente real do programa e da máquina onde este estava alocado. Para além dos passos indicados, também foi necessário resolver problemas que ocorreram no final da migração como:

1. Redefinição de permissões necessárias para aceder a certos módulos do OTRS que foram perdidas durante a migração do sistema;

2. Configurar ou desligar a utilização do protocolo S/MIME, tendo esta desligada por decisão da entidade;

3. Alteração da configuração do apache presente na pasta do OTRS e da localização dos

web services que são criados pelo OTRS;

4. Reestruturação do design antigo utilizado pela entidade, sendo que este gerou erros durante a migração e debilitava no sistema na nova versão.

23

A migração teve a duração de oito horas (incluindo a introdução da nova configuração realizada anteriormente em sistemas de teste) e foi realizada nas instalações da entidade com a ajuda do seu administrador de sistemas.

3.5.2. Integração com Sistemas Externos

Para além de realizar a implementação, configuração e migração dos dados para a nova versão do OTRS, também foi pedido a integração de vários sistemas com o OTRS, proporcionando um sistema com todos os registos de ocorrências dentro da instituição. Os sistemas que foram pedidos para integrar com o OTRS foram o Sistema de Voz sobre IP (VoIP), um Sistema Alarmístico proprietário da instituição e o Sistema de Backups.

3.5.2.1. Sistema de Voz sobre IP

O VoIP é uma tecnologia que permite a realização de chamadas telefónicas através de uma ligação à internet em vez de uma linha telefónica. Este sistema permite ligar a outras pessoas que estejam a utilizar o mesmo serviço, ou até mesmo pessoas que estejam a utilizar uma linha telefónica normal (Federal Communications Commission, 2010).

Esta tecnologia consiste na conversão da voz em sinal digital que é enviado pela Internet. Se o utilizador ligar para um telemóvel normal, o sinal é convertido para o sinal correspondente antes de chegar ao destino. É possível realizar estas chamadas pelos sistemas VoIP através de um computador, um telefone VoIP apropriado ou um telefone normal com um adaptador (Federal Communications Commission, 2010).

A integração do OTRS com este sistema tem o intuito de registar todas a interações que existem com os clientes. Quando o sistema VoIP receber uma chamada, é enviado um pedido para um

web service criado no OTRS, com o método de criação de um novo ticket. Neste pedido, são

enviados campos dinâmicos criados no OTRS para registar informações adicionais da chamada como o número que ligou, a que horas foi efetuada a chamada e o áudio da chamada em mp3.

Os campos dinâmicos são campos especiais criados para que seja possível adicionar informações adicionais a tickets ou artigos (mensagens individuais presentes nos tickets). Estes campos não estão fixos no sistema e apenas aparecem em sítios específicos, sendo estes sítios escolhidos pelo administrador que criou estes campos. Estes campos podem conter texto, datas, uma lista de opções, entre outros. Como o número que ligou e as horas a que a chamada foi

24

efetuada não são campos que um ticket traz por defeito, foi necessário criar dois campos dinâmicos para alocar estes dados. Para receber este pedido também foi necessário criar uma fila nova chamada “NoResponseQueue”. O propósito desta fila é receber todos os pedidos que são acionados de forma automática. Foi necessário criar esta fila, porque as filas previamente criadas são de suporte ao cliente e possuem respostas automáticas para manter o cliente informado da receção, atualização e resolução do seu pedido. Para que o pedido enviado ao web

service do OTRS seja válido é necessário enviar as credenciais do agente que está a criar o

ticket. Para tal, foi criado um agente novo que só tem acesso a esta fila e é apenas usado pelo sistema de VoIP.

Depois do sistema VoIP enviar o pedido para o web service criado no OTRS com os dados da chamada, o módulo “genericinterface” do OTRS faz o mapeamento do pedido recebido e a criação do respetivo ticket com as informações recebidas.

Assim, todas as interações efetuadas por telefone da instituição são registadas através da criação de um ticket, sendo que, quando o Agente acabar de atender o cliente, este tem de preencher e fechar o ticket que foi automaticamente criado no OTRS para mais tarde ser possível ver o histórico de integrações com o cliente.

3.5.2.2. Sistema de Alarmística

A instituição desenvolveu um sistema interno que possibilita a visualização de toda a sua infraestrutura de rede e ajuda na deteção de problemas nas ligações. Quando alguma ligação ou algum equipamento tem um conflito ou deixa de responder é enviado um pedido para o sistema onde a ligação ou equipamento é apresentado em destaque, tornando a reparação do equipamento ou resolução do problema muito mais rápida.

Para a integração deste sistema foi seguida a mesma abordagem utilizado no sistema de VoIP, usufruindo dos web services disponibilizados pelo próprio OTRS. Como tal, foi criado um web

service novo para os pedidos do sistema de alarmística e, quando houver um erro na rede, é

enviado um pedido do sistema de alarmística para o OTRS. Para autorizar este pedido, foi criado um agente para estes pedidos que só tem autorização para a fila “NoResponseQueue”, evitando assim o acionamento de respostas automáticas novamente. Contudo, na integração deste sistema a instituição pediu a adição de SLAs para que os problemas de rede sejam resolvidos o mais rapidamente possível e para que possam realizar relatórios mensais para

25

averiguar se os tempos estão a ser cumpridos pelos funcionários. Como tal, foi criado cinco SLAs, uma para cada nível de prioridade (de 1 a 5). Dependendo do nível de problema encontrado na rede ou de quão crucial é o equipamento onde ocorreu o problema, o sistema interno desenvolvido pela instituição escolhe a SLA apropriada e envia um pedido com os respetivos dados ao OTRS.

Desta forma, todos os problemas ocorridos na infraestrutura de rede são registados tanto no OTRS como no software desenvolvido pela instituição fornecendo redundância.

3.5.2.3. Sistema de Backups

A instituição utiliza um sistema que realiza os backups de todas as máquinas e faz a gestão dos

backups. Infelizmente este sistema não possibilita a opção de invocar um web service quando

um backup é efetuado. O sistema apenas permite o envio de emails como forma de notificação.

Sendo assim, não foi possível utilizar a mesma abordagem que foi utilizada com os outros sistemas. Sendo o OTRS um sistema orientado a receção e envio de emails, o rececionamento do email enviado pelo sistema de backups é possível. Mas, como aconteceu nos outros sistemas, o acionamento de respostas automáticas não é desejado e, para contornar este problema, foi utilizado uma funcionalidade do OTRS denominada “PostMaster Filter”[Figura 4].

Esta funcionalidade disponibiliza a filtragem de emails para que seja possível atribuir certas propriedades ao ticket criado antes de ele ser colocado em qualquer fila ou ser disponibilizado para os agentes. Através da funcionalidade é possível também atribuir valores que estão no corpo do email a propriedades do ticket através do uso de expressões regulares.

26

Figura 4 Filtro Email de Backup

Através desta funcionalidade, os emails do endereço do sistema de backups são redirecionados para a fila sem respostas automáticas e com a utilização de expressões regulares, o equipamento, a prioridade e o estado são atribuídos com os dados presentes no email.

3.5.2.4. Generic Agent

Na integração dos três sistemas pedidos pela instituição, foi necessário o redireccionamento dos tickets criados para uma fila devido às respostas automáticas presentes nas outras filas. A fila nova denominada de “NoResponseQueue”, não deve ser acedida por nenhum agente devido a ser uma fila reservada a tickets criados por sistemas automáticos através dos web services disponibilizados pelo OTRS.

Sendo assim, se os tickets ficassem nesta fila, eles não poderiam ser acedidos por nenhum agente (excluindo os agentes criados para os sistemas automáticos). Como tal, é necessário o redireccionamento destes tickets que já estão criados (depois de serem criados, os tickets podem ser movidos para outras filas sem causar o acionamento de respostas automáticas), para as filas correspondentes dependo dos serviços pedidos. Para realizar este último passo na integração dos sistemas, foi utilizado uma ferramenta fundamental do OTRS, o Generic Agent.

O Generic Agent é uma ferramenta disponibilizada pela OTRS que executa tarefas automaticamente se, certas condições forem verdadeiras. Foram criadas três tarefas, uma para

27

cada fila que fornece serviços. Estas tarefas são executadas de dois em dois minutos todos os dias [Figura 5].

Figura 5 Generic Agent - Execução automática

Os tickets que são afetados pelo Generic Agent são os tickets que possuem os serviços da fila de Serviços de Informática e que estão presentes na fila que não tem respostas automáticas (“NoResponseQueue”) [Figura 6].

Figura 6 Generic Agent – Condições

Se houver algum ticket no sistema que satisfaçam estas condições, o Generic Agent realiza uma atualização as propriedades do mesmo, movendo o ticket para a fila de Serviços de Informática [Figura 7].

Figura 7 Generic Agent - Mover ticket para a nova fila

As outras tarefas são iguais a tarefa ilustrada nas figuras, sendo que os serviços escolhidos são os serviços correspondentes a fila para onde o ticket será movido.

28 3.5.3. Módulos Complementares

Para além da integração do OTRS com vários serviços independentes que a instituição utilizada, foi pedido a instalação de módulos externos à instalação base e a criação de módulos específicos para a satisfação de necessidades adicionais que a instituição necessitava. Este capítulo tem o objetivo primeiramente informar de como operam os módulos dentro da arquitetura do OTRS e, de seguida, explicar o desenvolvimento feito para a criação dos módulos pedidos.

3.5.3.1. O Fluxo dos Módulos

O OTRS é um sistema que segue uma arquitetura modular e, como tal, a adição de módulos customizados ao sistema é uma das suas grandes vantagens. Todos os módulos construídos neste projeto seguiram o fluxo original do sistema, onde o ficheiro que mapeia a interface invoca um módulo. Este módulo pode ser constituído por um ou mais ficheiros mas, geralmente, é constituído por dois, um ficheiro inicial onde são preparados certos aspetos necessários para execução do módulo, e um ficheiro auxiliar que faz um trabalho mais genérico. Este fluxo cria uma granularidade maior e, consequentemente, uma maior reutilização de código. No final da execução do módulo, este ainda pode acionar uma página web (p.e. uma página pop-up ou redirecionar para outra página), sendo que esta página web é um ficheiro do tipo Template

Toolkit e pode utilizar outro ficheiro perl que dita as traduções disponíveis para a página. Caso

o ficheiro de traduções não exista, o sistema não traduz as palavras para a linguagem escolhida pelo utilizador [Figura 8].

29 3.5.3.2. Módulo de Impressão de Modelos

A instituição utiliza internamente modelos já predefinidos onde apenas certos campos mudam de impressão para impressão. O OTRS possui uma opção para imprimir todos os detalhes de um ticket ou para imprimir apenas um artigo (uma das interações realizadas) de um ticket para o formato PDF , mas não possui nenhuma funcionalidade que possibilita a adição de modelos para serem imprimidos com campos do ticket. Sendo assim, a instituição pediu a construção de um módulo onde possam ser inseridos vários modelos e, em cada impressão, certos campos presentes no modelo sejam preenchidos antes da impressão com campos dinâmicos existentes num ticket.

Para tal, foi seguida a arquitetura do OTRS e começou-se por fazer o ficheiro XML que realiza o mapeamento da interface. A instituição pediu que fosse adicionada uma nova aba no menu do ticket do estilo dropdown, onde os vários modelos aparecem abaixo da aba selecionada [Figura 9]. Foi pedida a implementação de apenas um modelo de impressão, sendo que depois deste ser programado, toda a informação de como foi feito o módulo deve ser documentada para mais tarde os técnicos da instituição puderem colocar modelos novos quando desejarem.

Figura 9 Nova aba adicionada

O OTRS possui um mecanismo próprio dedicado a gestão das configurações disponíveis na interface. Este mecanismo faz o mapeamento da interface através de tags de XML próprias do OTRS. Para este módulo foram implementados vários botões iguais ao ilustrado, sendo que apenas um dos botões está ativo. Abaixo temos o botão implementado em XML, sendo que os outros seguem a mesma fórmula [Figura 10].

30

Figura 10 Botão implementado em XML

Pelo nome das propriedades é possuir deduzir o que cada uma faz, sendo importante mencionar as propriedades “Action”, que indica qual o módulo perl que vai ser chamado quando o botão for acionado, “Link” que indica o URL que vai ser gerado ao carregar no botão e possibilita a passagem de conteúdo como o ID do ticket, e o “ClusterName” que indica ao mecanismo próprio do OTRS que o botão é filho de outro botão chamado “Print Templates”.

Toda a interface do OTRS está mapeada através de ficheiros XML com um formato similar ao ilustrado acima. Para além de ser mapeada a interface, os módulos em perl também são registados nestes ficheiros. Como este botão ativa um módulo novo, é necessário fazer o registo do mesmo senão o sistema não terá conhecimento da sua existência [Figura 11].

Figura 11 Registo de um Módulo

Acima temos as tags para o registo de um módulo novo, onde “Group” e “GroupRo” refere-se ao nível de permissões necessárias para executar o módulo, sendo que este módulo não exige permissões adicionais. Sempre que existir algum elemento da interface que aciona um módulo em perl, é necessário fazer o registo do mesmo no ficheiro XML para o sistema saber se o utilizador pode chamá-lo e que o módulo existe.

Estando o ficheiro XML concluído, é necessário construir o módulo que foi registado. O módulo “AgentPrintDynamicFields” reencaminha para o primeiro ficheiro que faz verificações iniciais sobre o ID do ticket recebido, sobre permissões necessárias para ter acesso ao ticket e