UNIVERSIDADE DE LISBOA

Transcrição

1 UNIVERSIDADE DE LISBOA Faculdade de Ciências Departamento de Informática ANÁLISE E DESENVOLVIMENTO DE SOLUÇÃO DE SERVICE DESK MANAGEMENT - ITIL V3: SERVICE ASSET & CONFIGURATION MANAGEMENT E SERVICE LEVEL MANAGEMENT Ricardo Manuel Vitória Reis VERSÃO PÚBLICA MESTRADO EM ENGENHARIA INFORMÁTICA Especialização em Sistemas de Informação 2011

2

3 UNIVERSIDADE DE LISBOA Faculdade de Ciências Departamento de Informática ANÁLISE E DESENVOLVIMENTO DE SOLUÇÃO DE SERVICE DESK MANAGEMENT - ITIL V3: SERVICE ASSET & CONFIGURATION MANAGEMENT E SERVICE LEVEL MANAGEMENT Ricardo Manuel Vitória Reis ESTÁGIO Trabalho orientado pelo Prof. Doutor Carlos Jorge da Conceição Teixeira e co-orientado pelo Eng.º Miguel Ângelo de Jesus Pereira Ramos MESTRADO EM ENGENHARIA INFORMÁTICA Especialização em Sistemas de Informação 2011

4

5 Agradecimentos Em primeiro lugar, quero agradecer a todas as pessoas que, de alguma forma, deram o seu contributo para a minha formação profissional e pessoal. À Maksen, quero agradecer a maneira como todos os colaboradores me receberam e acolheram na sua (nossa) equipa, pelo ambiente jovem e profissional que me proporcionaram, por todo o apoio prestado e por todos os recursos disponibilizados. Em particular, agradeço ao meu co-orientador Eng.º Miguel Ramos e ao manager Rui Miguel por terem apostado em mim, pelo tempo dedicado ao meu trabalho e pelos preciosos conselhos que me deram e que certamente seguirei ao longo da minha carreira profissional. Muito Obrigado. Agradeço também ao meu colega e amigo Nelson Pinto, que comigo levou a cabo a implementação da solução proposta, por toda a camaradagem e espírito de equipa demonstrados, mas também por todos os sacrifícios feitos em prol do projecto e por todas as discussões, motivações e esclarecimentos. Muito Obrigado. Agradeço igualmente ao André Santos e ao Carlos Valente por todo o apoio prestado, quer na especificação dos requisitos, quer nas sessões de testes, fases determinantes do projecto, mas também por todo o suporte técnico, em particular com o servidor de desenvolvimento. De seguida, quero agradecer ao meu orientador Prof. Carlos Teixeira por todos os esclarecimentos prestados, especialmente na elaboração dos dois relatórios produzidos. A todos os colegas e amigos da faculdade, quero agradecer todos os conhecimentos e troca de ideias ao longo do percurso académico. A este grande grupo de amigos, o meu Muito Obrigado. Por fim, mas não com menos importância, agradeço à minha família todo a ajuda e aconselhamento ao longo de toda a minha vida, quer académica, quer pessoal. Muito Obrigado.

6

7 À minha família.

8

9 Resumo Este projecto tem como objectivo efectuar a análise e o desenvolvimento de uma solução de Service Desk Management segundo as melhores práticas de ITIL v3. Dos processos que a framework ITIL v3 de melhores práticas de Information Technology Service Management advoga para este tipo de projectos, este documento referir-se-á aos seis que são âmbito deste projecto: Incident Management, Problem Management, Change Management, Release & Deployment Management, Service Asset & Configuration Management e Service Level Management. Os 4 primeiros foram implementados em conjunto com outro PEI, sendo os restantes dois específicos deste projecto e que serão aqui particularmente focados. Relativamente aos seis processos abordados, e no contexto do Projecto de Estágio, será apresentado o trabalho relacionado já desenvolvido nesta área, bem como serão detalhados, quer a análise e o desenho da solução proposta, quer a implementação dos dois processos mais focados no projecto: Service Asset & Configuration Management e Service Level Management. Palavras-chave: Service Desk Management; ITIL v3; OutSystems Agile Platform; Service Asset & Configuration Management; Service Level Management. i

10 ii

11 Abstract This project aims to analyze and develop a Service Desk Management solution based on ITIL v3 best practices. From the processes that the Information Technology Service Management best practices ITIL v3 framework advocates for this kind of projects, this document will refer to the six that are part of the project: Incident Management, Problem Management, Change Management, Release & Deployment Management, Service Asset & Configuration Management and Service Level Management. The first 4 were implemented in conjunction with other PEI, and the remaining two are specific to this project and will be particularly focused here. As far as the six processes discussed are concerned, and in the context of this Project, it will be presented the related work already undertaken in this area and it will be detailed, both the analysis and design of the proposed solution and the implementation of the two most focused processes in the project: Service Asset & Configuration Management and Service Level Management. Keywords: Service Desk Management; ITIL v3; OutSystems Agile Platform; Service Asset & Configuration Management; Service Level Management. iii

12 iv

13 Conteúdo Capítulo 1 Introdução Motivação Objectivos Contribuições Enquadramento institucional Organização do projecto Estrutura do documento... 8 Capítulo 2 Metodologias e planeamento Framework ITIL v OutSystems Agile Platform Metodologia Estrutura da plataforma Hub Server Metodologia de desenvolvimento Planeamento Gestão de Projecto e Controlo de Qualidade Formações Capítulo 3 Processos implementados Service Asset & Configuration Management Service Level Management Outros processos Incident Management Problem Management Change Management Release & Deployment Management Capítulo 4 Trabalho relacionado Benchmark de mercado v

14 4.2 Processos analisados Método de avaliação Resultados Capítulo 5 Análise do problema e desenho da solução Definição de requisitos Desenho do modelo conceptual Modelo de Casos de Uso Modelo de Domínio Modelo de Desenho Capítulo 6 Implementação da solução Service Asset & Configuration Management Secção no painel de administração Gestão de activos Gestão de inventários Service Level Management Níveis de serviço Acordos e contratos Avaliação da solução Capítulo 7 Conclusões e trabalho futuro Capítulo 8 Bibliografia vi

15 vii

16 Lista de acrónimos CA Computer Associates; CI Configuration Item; CMDB Configuration Management Database; CMS Configuration Management System; DCF Documento Comparativo de Ferramentas; DFD Diagrama de Fluxo de Dados; FCUL Faculdade de Ciências da Universidade de Lisboa; GMS Global Management Solutions; HP Hewlett-Packard; ITIL Information Technology Infrastructure Library; ITSM Information Technology Service Management; OLA Operational Level Agreement; PEI Projecto de Engenharia Informática; RDM Release & Deployment Management; SACM Service Asset & Configuration Management; SDM Service Desk Management; SIP Service Improvement Plan; SKMS Service Knowledge Management System; SLA Service Level Agreement; SLM Service Level Management; SQL Structured Query Language; TI Tecnologias de Informação; UC Underpinning Contract; e UML Unified Modeling Language. viii

17 ix

18 Lista de Figuras Fig. 1 Organograma do projecto... 7 Fig. 2 Framework ITIL v Fig. 3 Arquitectura da plataforma OutSystems Fig. 4 Detalhe da arquitectura da plataforma OutSystems, destacando o processo 1- Click-Publishing Fig. 5 SCRUM Agile Methodology Fig. 6 Planeamento inicial das actividades do projecto Fig. 7 Planeamento das actividades do projecto nos 4 meses finais Fig. 8 Modelo de acompanhamento do projecto Fig. 9 Processos ITIL v3 implementados e respectivo mapeamento Fig. 10 Estudos de 2008 da Forrester [11] e da Gartner [12] Fig. 11 Modelo de avaliação de ferramentas concorrentes Fig. 12 Resultado da avaliação das soluções por dimensão Fig. 13 Resultado da avaliação dos requisitos funcionais Fig. 14 Resultado da avaliação dos requisitos de integração Fig. 15 Diagrama de Casos de Uso simples do processo Service Asset & Configuration Management Fig. 16 Diagrama de Casos de Uso simples do processo Service Level Management 43 Fig. 17 Diagrama de arquitectura do Ambiente de Desenvolvimento Fig. 18 Diagrama de arquitectura do Ambiente de Qualidade Fig. 19 Diagrama de arquitectura do Ambiente de Produção Fig. 20 DFD de nível 0 do processo Service Asset & Configuration Management Fig. 21 DFD de nível 0 do processo Service Level Management Fig. 22 Ecrã com a lista de tipos de componentes Fig. 23 Janela de pop-up para a criação/edição de um tipo de componente Fig. 24 Ecrã com a lista de modelos de activos Fig. 25 Janela de pop-up para a criação/edição de um modelo de activos Fig. 26 Ecrã com a lista de campos adicionais x

19 Fig. 27 Ecrã de criação/edição de um campo adicional Fig. 28 Ecrã com a lista de estados dos activos Fig. 29 Janela de pop-up para a criação/edição de um estado de activo Fig. 30 Ecrã com a lista de sub-atribuições Fig. 31 Janela de pop-up para a criação/edição de uma sub-atribuição Fig. 32 Ecrã com a lista de activos afectos a um utilizador Fig. 33 Ecrã com as listas de activos Fig. 34 Ecrã de escolha do modo de registo de um novo activo Fig. 35 Ecrã de registo de um novo activo Fig. 36 Página de detalhes de um activo Fig. 37 Separador Relações da página de detalhes de um activo Fig. 38 Janela de pop-up para edição das relações pai-filho de um activo Fig. 39 Separador Histórico da página de detalhes de um activo Fig. 40 Ecrã com a lista de inventários Fig. 41 Página de detalhes de um inventário Fig. 42 Código da acção RefreshAssetTable, com os 4 caminhos de execução assinalados Fig. 43 Janela de pop-up para a escolha dos activos do inventário Fig. 44 Ecrã principal da secção de gestão dos SLA s (níveis de serviço) Fig. 45 Janela de pop-up para criação/edição de SLA Fig. 46 Matriz de níveis de serviço de um SLA Fig. 47 Página com a lista de Service Level Agreements Fig. 48 Ecrã de criação de um novo acordo/contrato Fig. 49 Ecrã de edição de um acordo/contrato Fig. 50 Ecrã de detalhes de um SLR xi

20 xii

21 Capítulo 1 Introdução Este capítulo introduz o projecto, inserido na cadeira de Projecto de Engenharia Informática, realizado desde o dia 02 de Setembro de 2010 e que tem como principal objectivo analisar e desenvolver uma solução de Service Desk Management (SDM) segundo as melhores práticas de ITIL v3. Para além da motivação para construir uma solução desta natureza, são apresentados os objectivos do projecto, as contribuições deste, a instituição onde foi desenvolvido e, por fim, a organização do presente documento. 1.1 Motivação A motivação geral para a adopção de soluções de SDM está associada à cada vez maior complexidade dos ambientes de Tecnologias de Informação (TI) distribuídos e ao aumento da dependência da tecnologia por parte das empresas, levando à criação dos alicerces para uma gestão de serviços bem sucedida. Os helpdesks reactivos e autónomos já não são suficientes. Para satisfazer as exigências empresariais em termos de serviços de tecnologia fiáveis, as empresas de TI necessitam de processos de gestão de serviços integrados que vejam os componentes da tecnologia como partes interrelacionadas dos serviços de TI a si prestados. As incessantes alterações das condições de mercado que se verificam actualmente levaram a uma adaptação contínua por parte das organizações. A capacidade de 1

22 resposta, fortemente ligada à flexibilidade das organizações, é o factor que dita a sobrevivência e bem-estar no mercado. A estruturação das organizações, tendo em conta os seus processos de negócio, tornouse uma abordagem recorrente por permitir melhorar cada vez mais os processos internos às organizações, cortando custos e maximizando a eficácia. Desta forma, aumentou o interesse na área da gestão de processos de negócio. O principal modo pelo qual os processos oferecem a flexibilidade desejada pelas organizações é a possibilidade de executar processos, tornando imediatamente reais as alterações desenvolvidas durante a fase de modelação. Isto permite aos elementos das organizações alterarem e melhorarem os seus processos sempre que necessário e ver as suas alterações repercutidas na organização, podendo voltar a ser alteradas caso necessário. Em última análise, a fase de execução é essencial para a flexibilidade necessária para as organizações se manterem de acordo com as inconstantes condições de mercado. Ao longo do tempo, tem sido reconhecido que a informação é o recurso estratégico mais importante que uma organização tem de gerir, sendo fulcral a qualidade dos serviços de TI, no que diz respeito à recolha, análise, produção e distribuição dessa mesma informação dentro da organização. É, portanto, fundamental que os serviços de TI sejam considerados como cruciais e estratégicos, bem como activos organizacionais nos quais se deve investir apropriados níveis de recursos no seu suporte, entrega e gestão, assim como nos sistemas de TI que os suportam. Porém, todos estes aspectos são quase sempre desprezados ou superficialmente abordados pelas organizações. [1] Neste sentido, os gestores de TI têm de cooperar activamente com a componente de negócio, adoptando uma abordagem mais orientada ao cliente e ao negócio, a fim de prestarem serviços de TI de elevada qualidade, ao mesmo tempo que se minimizam os custos. [1] 2

23 1.2 Objectivos O principal objectivo deste projecto é fazer a análise e o desenvolvimento de uma solução de SDM segundo as melhores práticas de ITIL v3, focando-se principalmente nos processos Service Asset & Configuration Management e Service Level Management. A solução deve ser capaz de automatizar e dar resposta aos processos de service desk, gestão de incidentes, gestão de problemas, gestão de alterações e gestão do ciclo de vida dos activos e serviços, assim como implementar uma Configuration Management Database (CMDB), com um modelo de dados único, plataforma de workflow e interface de utilizador. São adoptados os standards de ITIL v3 para a gestão dos serviços acima mencionados, seguindo uma abordagem unificada que, quando aperfeiçoada com outras soluções para gestão de infra-estruturas, permite a melhoria proactiva e contínua de disponibilidade de serviços, qualidade e poupança de custos em ambientes empresariais complexos. É objectivo que a solução final automatize os processos de gestão de pedidos, incidentes e problemas, permitindo a qualquer organização, ou Clientes desta, responder rapidamente e com eficiência às condições que quebram os serviços críticos. A solução deve actuar como um único ponto de contacto para os pedidos de utilizador, incidentes submetidos pelo mesmo e incidentes gerados nas infra-estruturas. Os seus workflows ITIL profundos, flexíveis e com as melhores práticas devem acelerar a restauração do serviço normal, ajudar a prevenir futuros eventos de serviços empresariais de impacto adverso e aumentar a eficiência dos recursos de TI. Devem estar previstos workflows que capturem e localizem relações do início do incidente à correlação do problema, implementem a investigação da causa, erros conhecidos e pedidos de alterações. A inclusão de um knowledge management deve 3

24 oferecer authoring rico, pesquisa de linguagem natural e serviço autónomo para reduzir o volume de incidentes e permitir uma maior resolução de suporte de primeiro nível. A CMDB deve referir quais os serviços empresariais e os utilizadores afectados e ajudar a diagnosticar a causa através da visibilidade para as dependências da infra-estrutura. Do conjunto de processos que compõem a framework ITIL v3, foram implementados, no âmbito deste projecto, os seis processos que mais se adequam ao seu desenvolvimento, nomeadamente: Incident Management, Problem Management, Change Management, Release & Deployment Management, Service Asset & Configuration Management e Service Level Management. Estes processos serão abordados com maior profundidade em secções futuras deste documento. 1.3 Contribuições No âmbito da solução de SDM implementada, podem ser identificados os seguintes benefícios que a mesma traz: Aumento da disponibilidade dos sistemas críticos para o negócio (ex.: Customer Relationship Management CRM), quer da organização onde a solução de SDM esteja implementada, quer dos seus Clientes, acelerando a resolução de incidentes e problemas; Redução da duração e do volume das chamadas de suporte; Aumento da produtividade dos agentes de service desks, apoio aos recursos de TI e aos utilizadores; Identificação das causas principais dos incidentes, tendo em vista a prevenção da sua ocorrência recorrente; Localização do desempenho segundo os acordos de nível de serviço para garantir que os objectivos são atingidos; Possibilidade de utilização, de forma global, regional e/ou local, quer por uma qualquer organização, quer pelos Clientes desta; Rápido encaminhamento dos pedidos para o suporte correcto; e Aumento da disponibilidade das infra-estruturas de TI. 4

25 1.4 Enquadramento institucional A Maksen (inicialmente GMS) é uma empresa cujo objectivo é o de prestar serviços de consultoria estratégica, de negócio, de sistemas de informação e de engenharia/redes de comunicações, focando a sua actividade nos sectores de estratégia empresarial e de negócio, organização, processos e análises económico-financeiras, sistemas e tecnologias de informação, e engenharia e redes de comunicações. Através desta especialização, a empresa adquiriu um elevado nível de conhecimento e experiência, adequados às exigências actuais de cada indústria. Para responder de forma eficaz às exigências do mercado, a Maksen é constituída por três divisões [2] que se complementam: Consulting: divisão que centra a sua actividade na prestação de serviços de consultoria estratégica, operacional e de sistemas de informação, especializandose em aspectos como a redefinição estratégica de negócios, a transformação empresarial e processual, e as análises económico-financeiras. Os serviços prestados por esta divisão apoiam-se num elevado nível de conhecimento e experiência especializada, adaptados às especificidades de cada cliente; Engineering: divisão vocacionada para a prestação de serviços na área de engenharia e redes de comunicações, não só desenhando a arquitectura do sistema, como também fazendo a sua implementação e integração tecnológica; e IT Management: divisão cuja oferta consiste essencialmente na prestação de serviços continuados de consultoria e outsourcing, no âmbito da evolução tecnológica e exploração operacional de plataformas e sistemas de informação. Aqui, as grandes mais-valias são os conhecimentos técnicos especializados e as parcerias efectivas com as equipas tecnológicas dos clientes, criando condições para que a Maksen seja um parceiro presencial rigoroso, competente e de valor acrescentado para esses clientes. 5

26 A cadeira de Projecto de Engenharia Informática é constituída pela componente de trabalho autónomo supervisionado, tendo este sido co-orientado pela Maksen, através do Eng.º Miguel Ramos, ao qual estiveram atribuídas as tarefas de coordenação e acompanhamento das actividades realizadas. 1.5 Organização do projecto Para este projecto, reuniu-se um conjunto de profissionais com conhecimento e experiência nas áreas abrangidas, propondo a afectação de uma equipa multidisciplinar de elementos da Maksen e da Faculdade de Ciências da Universidade de Lisboa, com competências de intervenção necessárias. A Figura 1 mostra a disposição dos stakeholders do projecto num organograma, o qual indica também os intervenientes que compõem cada um dos papéis mencionados. 6

27 Fig. 1 Organograma do projecto Os stakeholders encontram-se organizados da seguinte forma: 1. Comité de Acompanhamento tem a responsabilidade de aprovar os outputs intermédios e finais do projecto (descritos ao longo dos capítulos 4 a 6 deste documento), confirmar a adequação do trabalho desenvolvido face aos objectivos definidos e coordenar e facilitar a integração das decisões de carácter estratégico com os princípios gerais de gestão. 2. Comité Operacional com responsabilidades de validação dos outputs intermédios e finais do projecto e da adequação do trabalho desenvolvido face aos objectivos definidos, bem como coordenar a Equipa de Projecto. 3. Sponsor de Projecto encarregue de dinamizar o projecto internamente, contribuindo de forma determinante para o sucesso da solução na resposta às necessidades específicas. 4. Controlo de Qualidade é política da Maksen, para a realização de qualquer Projecto, incluir nas equipas de trabalho uma figura de controlo da qualidade, 7

28 que tem como responsabilidade principal validar os outputs do projecto face às expectativas e necessidades. 5. Gestão de Projecto disponibilizar os recursos humanos, logísticos, técnicos e funcionais da Maksen necessários ao desenvolvimento do projecto, intermediar os contactos e reuniões necessárias ao desenvolvimento do projecto e participar na execução de tarefas planeadas com a restante equipa de trabalho. 6. Equipa Core de Projecto executar as actividades de projecto planeadas, assim como as de Gestão de Projecto. 1.6 Estrutura do documento O presente Relatório Final encontra-se estruturado em oito capítulos, pelo que de seguida se descrevem os sete capítulos seguintes. Capítulo 2 descreve a framework ITIL v3 de melhores práticas de Information Technology Service Management, a qual é o conceito teórico principal inerente a este projecto; apresenta a plataforma de desenvolvimento rápido OutSystems Agile Platform, a qual foi utilizada para implementar a aplicação de SDM decorrente do projecto; refere a metodologia de desenvolvimento que foi usada neste projecto, e que também é advogada pelo fabricante da plataforma OutSystems, a SCRUM Agile Methodology; apresenta o planeamento efectuado para realizar o projecto, bem como uma confrontação com o plano de trabalho inicial; aborda o modelo de acompanhamento do projecto, referindo por fim, as formações iniciais realizadas. Capítulo 3 dá uma descrição de cada um dos processos ITIL v3 que foram implementados no contexto da solução desenvolvida. 8

29 Capítulo 4 pretende dar uma visão do trabalho relacionado que já foi realizado na área de SDM, através da comparação de duas ferramentas líderes de mercado. Capítulo 5 descreve a análise de requisitos do problema proposto, assim como os documentos de desenho produzidos no âmbito da solução implementada. Capítulo 6 aborda em detalhe a implementação dos dois processos ITIL v3 focados neste documento, englobados no âmbito da solução desenvolvida, abordando também a forma como a mesma foi testada. Capítulo 7 apresenta as conclusões do trabalho descrito neste relatório e o trabalho futuro no âmbito da aplicação entregue. Capítulo 8 lista a bibliografia usada para desenvolver o projecto e o presente documento. 9

30 Capítulo 2 Metodologias e planeamento O presente capítulo tem o objectivo de fornecer um contexto teórico sobre o principal conceito abordado neste projecto, a framework ITIL v3 de melhores práticas de Information Technology Infrastructure Library (ITSM), bem como dar uma visão da plataforma e da metodologia de desenvolvimento usadas para implementar a solução proposta, a OutSystems Agile Platform e a metodologia SCRUM Agile, respectivamente. 2.1 Framework ITIL v3 A versão 3 da framework ITIL é uma nova abordagem, com base no ciclo de vida dos serviços e numa nova estrutura, diferenciando as práticas essenciais do modelo com novos processos, preenchendo lacunas da versão anterior. A visão é integrada de Tecnologias de Informação (TI), negócios e fornecedores. Conceitos chave: Serviço de TI Um serviço é uma forma para criar valor acrescentado nos clientes, propiciando os resultados que eles queiram alcançar sem que tenham que assumir custos e riscos específicos. [3]; e 10

31 Gestão de Serviços de TI Gestão de serviços é um conjunto de capacidades organizacionais específicas (processos, métodos, funções, papéis e actividades) para providenciar valor aos clientes sob a forma de serviços. [3] Fig. 2 Framework ITIL v3 Ciclo de vida de serviços de TI: 1. Service Strategy Esta fase visa decidir os princípios base usados para desenvolver as políticas, os objectivos (quer estratégicos, quer aqueles que a organização espera alcançar através dos serviços que presta), os guidelines e os processos necessários ao longo do ciclo de vida do serviço de TI. Os requisitos de negócio são identificados e os resultados esperados são acordados num Service Level Package (SLP). Também envolve a identificação de oportunidades de negócio; 2. Service Design Durante esta fase, é realizado o design e o desenvolvimento do serviço de TI requerido. O design engloba todos os aspectos do serviço, ou seja, os planos, processos, infra-estrutura, ambientes, aplicações e recursos de dados, os quais devem cumprir todos os requisitos de negócio e objectivos e são 11

32 documentados num Service Design Package (SDP). O design do serviço é também baseado nos princípios estabelecidos na fase anterior; 3. Service Transition Aqui, o objectivo é criar a framework que vai garantir que o serviço desenhado é eficaz e eficientemente implementado no ambiente final, incluindo também determinar os riscos, as restrições e o grau de satisfação dos requisitos, assegurando que a performance esperada vai estar em conformidade com o planeado. Adicionalmente, o Service Knowledge Management System (SKMS) é actualizado com as informações do ambiente de produção. Decorrente desta fase, o prestador de serviços torna-se mais adaptável e competitivo para conseguir lidar com uma grande quantidade de alterações, melhoramentos e releases para os seus clientes; 4. Service Operation Esta fase lida com as actividades e processos requeridos para o eficaz desenrolar do serviço criado, de modo a que a framework desenvolvida na fase anterior seja eficazmente implementada, garantindo assim a obtenção dos níveis de serviço acordados no Service Level Agreement (SLA). Posto isto, os objectivos desta fase são: Fazer a manutenção contínua da tecnologia que acompanha o serviço; Garantir que a operação diária dos processos é conduzida e controlada apropriadamente; Garantir a eficaz e eficiente gestão dos processos de operação; e Monitorizar continuamente o desempenho do serviço de TI, conduzindo avaliações e recolhendo informação. Em suma, a fase de Service Operation permite recolher e consolidar o valor que cada uma das outras fases fornece. 5. Continual Service Improvement Esta última fase tem a missão de manter o valor para os clientes, gerado nas fases anteriores, através da contínua avaliação e melhoramento da qualidade dos serviços prestados e da maturidade geral de todo o ciclo de vida da gestão de serviços e dos processos que a suportam. 12

33 Os seus objectivos principais são: Garantir que as áreas que necessitam de melhoramentos são identificadas, e que esses melhoramentos são apropriadamente administrados; Garantir a satisfação do cliente, mantendo o equilíbrio financeiro; Melhorar cada fase do ciclo de vida; e Desenvolver actividades para melhorar a generalidade dos processos de ITSM. 2.2 OutSystems Agile Platform A plataforma OutSystems destina-se principalmente ao desenvolvimento de aplicações empresariais com uma estrutura web-based. Esta tem suporte para redes móveis e de e- mail e permite integração com os sistemas legacy normalmente existentes nas organizações actuais. A principal diferença em relação a outras ferramentas semelhantes assenta na metodologia de desenvolvimento proposta e na flexibilidade apresentada. Nas secções seguintes, abordar-se-ão a metodologia de desenvolvimento que a plataforma OutSystems promove, os seus componentes e finalmente uma visão mais detalhada do componente responsável pela execução das aplicações desenvolvidas Metodologia Com a sua plataforma, a OutSystems sugere uma abordagem diferente para o controlo e organização de projectos baseada em metodologias ágeis. A OutSystems Agile Methodology aborda a actual necessidade de rápido desenvolvimento e contínua mudança das aplicações desenvolvidas, permitindo a criação de aplicações que respeitem, quer as necessidades tecnológicas, quer as necessidades de negócio das 13

34 organizações. Esta metodologia surgiu da adaptação dos conceitos da SCRUM Agile Methodology (detalhada na secção 2.3) às características da plataforma criada. Apoiando-se nesta metodologia, a OutSystems promove uma abordagem built-tochange, na qual, independentemente da fase do ciclo de vida das aplicações, novas funcionalidades podem ser facilmente adicionadas, erros corrigidos e feedback analisado, com riscos reduzidos e sem graves consequências para o negócio. Ao contrário do comum das ferramentas de desenvolvimento, esta plataforma aposta num estilo de programação visual drag and drop, sendo possível a criação de aplicações sem ter de se escrever qualquer linha de código. Desde o desenho do modelo de dados, criação de interfaces, definição da lógica de negócio ou instalação, tudo pode ser feito visualmente. Esta abordagem permite diminuir o desalinhamento existente entre o negócio e as TI, pois torna as aplicações mais fáceis de compreender para os elementos do negócio e permite aos elementos das TI responder atempadamente às necessidades que lhes são apresentadas Estrutura da plataforma Esta plataforma é destinada ao desenvolvimento de aplicações para Internet/Intranet ou redes móveis e é composta por quatro componentes. Estes pretendem endereçar as fases de desenvolvimento, integração de sistemas, execução e monitorização das aplicações criadas. 14

35 Fig. 3 Arquitectura da plataforma OutSystems A Figura 3 ilustra a arquitectura da plataforma OutSystems, seguindo-se uma descrição mais detalhada de cada um dos componentes dessa arquitectura: Service Studio: Componente de desenvolvimento visual, destinado à criação, alteração e instalação das aplicações desenvolvidas. Todo o processo de desenvolvimento é realizado neste componente, desde o desenho e criação do modelo de dados, desenho de interfaces e criação da lógica de negócio. A instalação das aplicações é feita neste componente recorrendo ao processo denominado 1-Click-Publishing, o qual verifica, guarda, efectua o upload no componente de execução, compila e instala a aplicação. Se todo este processo decorrer sem erros, obtém-se uma aplicação pronta a executar. Integration Studio: Componente de integração. Neste componente é possível fazer a integração com diversos sistemas legacy, quer através de wizards disponibilizados ou recorrendo à programação tradicional, oferecendo assim flexibilidade para integrar com qualquer tipo de sistema. Uma vez publicados, estes adaptadores podem ser utilizados na componente de desenvolvimento como blocos visuais para permitir a interacção das aplicações com os sistemas existentes. 15

36 Hub Server: Componente central responsável pela execução. Orquestra todas as compilações, instalações e qualquer actividade que decorra em tempo de execução. Todos os objectos desenvolvidos necessitam de ser aqui publicados para que possam ser usados nos vários componentes. Service Center: Componente de monitorização e gestão das aplicações. Este componente permite monitorizar todos os objectos necessários à execução, desde aplicações, serviços, adaptadores e quaisquer outros recursos. Permite, por exemplo, ter acesso aos registos dos erros gerados durante a execução das aplicações, facilitando assim a sua correcção. Com o conjunto dos componentes descritos anteriormente, a plataforma OutSystems aborda praticamente todos os factores necessários ao desenvolvimento de aplicações empresariais Hub Server Para melhor se perceber as propostas e o trabalho realizado, segue-se uma descrição mais detalhada de algumas partes do componente de execução. Após a ordem de publicação, proveniente do Service Studio, é enviado para o Hub Server o ficheiro com a definição completa e detalhada do que foi desenvolvido visualmente no componente de desenvolvimento. Este ficheiro oml está estruturado de acordo com a linguagem interna OutSystems Markup Language (OML). Após o upload do ficheiro com a definição da aplicação, este é processado e utilizado num gerador de código responsável por criar todo o código da aplicação que anteriormente tinha sido desenvolvida visualmente. São geradas as classes, as queries SQL, os ecrãs e tudo o que é necessário à execução da aplicação. 16

37 Uma vez gerado o código da aplicação, este é compilado e os resultados desta compilação, bem como os da geração de código são instalados. A instalação corresponde a colocar os ficheiros criados nos locais respectivos para que possam ser acedidos durante a execução, a criar tabelas na base de dados ou reflectir alterações efectuadas, agendar serviços, produzir informação para a componente de monitorização e ainda a publicar a aplicação no Service Center. Qualquer erro que seja encontrado durante este processo é reportado ao programador, que ficará responsável por o corrigir e republicar a aplicação. Fig. 4 Detalhe da arquitectura da plataforma OutSystems, destacando o processo 1-Click-Publishing Após este processo (1-Click-Publishing), a aplicação está pronta para executar. Qualquer pedido que lhe chegue, ela vai utilizar os executáveis criados anteriormente que irão actuar, quer sobre a base de dados, quer sobre outros ficheiros ou sistemas com que a aplicação tenha de comunicar. 17

38 2.3 Metodologia de desenvolvimento Para implementar a solução de SDM proposta para este projecto, usou-se a metodologia de desenvolvimento SCRUM Agile. Nesta metodologia (ver Figura 5), os projectos são compostos por uma sequência de iterações, denominadas de sprints, no final das quais uma versão funcional limitada do sistema está pronta. Estas iterações, com duração de duas a quatro semanas, são desta forma compostas por actividades de análise, desenvolvimento e teste, no final das quais uma ou mais funcionalidades do sistema final é terminada. No final de todas as iterações consegue-se um sistema com todas as funcionalidades disponíveis, que foram sendo testadas, adaptadas e aprovadas paralelamente com o seu desenvolvimento. Fig. 5 SCRUM Agile Methodology Todos os dias é realizada uma Daily Standup Meeting, de modo a manter toda a equipa de desenvolvimento sincronizada e focada nos objectivos para o sprint corrente. No final de cada sprint, os stakeholders e os membros da equipa de desenvolvimento reúnem-se para avaliar o progresso do projecto e definir os próximos passos a dar, permitindo assim que o rumo do projecto seja ajustado com base no trabalho já desenvolvido, e não em previsões, as quais podem ser irrealistas. 18

39 2.4 Planeamento Esta secção pretende dar a conhecer o planeamento inicial das tarefas realizadas no projecto, bem como a evolução desse planeamento até ao final do estágio, referindo as razões dos desvios ocorridos. Como já foi referido, este Projecto de Engenharia Informática (PEI) realizou-se em parceria com a instituição de acolhimento descrita na secção 1.4 deste relatório e teve o seu início no dia 02 de Setembro de 2010, tendo terminado no dia 15 de Julho de 2011, um mês e meio depois da data prevista de 31 de Maio. Fig. 6 Planeamento inicial das actividades do projecto Como demonstra a Figura 6, o projecto encontra-se dividido em sete fases, as quais estão distribuídas em três etapas. A primeira etapa (denominada INPUT) composta pela Fase I Organização e Planeamento e pela Fase II Definição de requisitos foi realizada durante os meses de Setembro e Outubro. A segunda etapa (denominada CONCEPÇÃO), com a duração de dois meses (Novembro e Dezembro), compreendeu a Fase III Desenho do modelo conceptual e 19

40 a Fase IV Especificação funcional e técnica. A partir desta etapa, começou-se a efectuar o desenvolvimento segundo os métodos advogados pela SCRUM Agile Methodology, pelo que as tarefas a realizar foram divididas em sprints. Não se aplicaram esses métodos na Etapa I, pois considerou-se ser inadequado face à natureza das actividades inerentes à mesma. A Etapa II dividiu-se assim nos seguintes sprints: Sprint 1 Teve a duração de três semanas e compreendeu a realização de todas as actividades da Fase III; Sprint 2 Teve a duração de duas semanas e nele foram produzidos dois dos três deliverables da Fase IV; e Sprint 3 Teve a duração duas semanas e foi elaborado o outro deliverable da Fase IV. Por fim, a terceira etapa (denominada OUTPUT) é composta pela Fase V Configuração / Implementação, pela Fase VI Formação de utilizadores e testes de aceitação e pela Fase VII Roll-out e documentação da solução. Esta última etapa teve a duração 6 meses e meio (de Janeiro até meados de Julho). Ao longo de todo o projecto, existiram actividades transversais de Gestão de Projecto e Controlo de Qualidade, as quais correspondem a reuniões semanais onde se monitorizou o progresso do mesmo. À medida que se foram implementando as funcionalidades dos vários módulos, o planeamento inicial foi sofrendo várias alterações. Os desvios ocorridos ficaram a dever-se à quantidade e complexidade dos requisitos a implementar o que, aliado à falta de experiência na plataforma OutSystems e aos vários problemas técnicos com o servidor de desenvolvimento, fez com que a implementação da aplicação se prolongasse por mais um mês para além da data estabelecida. 20

41 A Figura 7 ilustra as últimas alterações efectuadas ao planeamento, apresentando o diagrama das actividades do projecto nos últimos 4 meses do mesmo (de Abril a Julho). Fig. 7 Planeamento das actividades do projecto nos 4 meses finais 2.5 Gestão de Projecto e Controlo de Qualidade Com o objectivo de acompanhar todo o progresso do projecto, identificando e monitorizando também todos os riscos que lhe são inerentes, o modelo de acompanhamento do presente projecto foi o seguinte: 21

42 Fig. 8 Modelo de acompanhamento do projecto Reuniões semanais de Ponto de Situação (PdS) com o Comité Operacional, de modo a fazer um ponto de situação em relação às actividades planeadas e à monitorização dos riscos inerentes às mesmas, rever os outputs actualmente em produção e discutir os principais aspectos a considerar e as decisões operacionais a tomar; Reuniões quinzenais de PdS que, para além do Comité Operacional, contam também com a presença do Comité de Acompanhamento (excepto o orientador da FCUL), com o propósito de, juntamente com a realização das tarefas do tipo de reuniões anterior, tomar decisões estratégicas e de gestão transversal do projecto; e Reuniões trimestrais de Controlo de Qualidade com todos os intervenientes do projecto, cujos principais objectivos são dar a conhecer o ponto de situação do projecto aos orientadores da FCUL e verificar que o progresso do mesmo está alinhado com os objectivos da disciplina de PEI. 22

43 O planeamento das actividades e o progresso das mesmas foram registados e mantidos num ficheiro elaborado na ferramenta Microsoft Office Project 2007, a qual é ideal para cobrir estes aspectos de uma forma eficiente e eficaz. 2.6 Formações Durante a Fase I foram realizadas, para além do planeamento inicial das tarefas a realizar, a organização e confirmação das responsabilidades da equipa de projecto, formações em ITIL v2, ITIL v3 e na plataforma OutSystems, e a reunião de kick-off com os responsáveis da instituição de acolhimento envolvidos no projecto, na qual se deu a conhecer o mesmo aos referidos intervenientes. Detalha-se de seguida as actividades que requereram um maior esforço durante esta fase. Nas três primeiras semanas do estágio, teve lugar um conjunto de 3 formações que permitiram assimilar os conceitos essenciais, em primeiro lugar para uma boa compreensão dos requisitos, através das formações em ITIL v2 (ITIL V2 Foundation) e ITIL v3 (IT Infrastructure Library (ITIL) v3 Foundation Syllabus v4.2), e em segundo lugar para uma boa implementação da aplicação a desenvolver, através das formações em OutSystems Agile Platform (OutSystems Developer Course 1, OutSystems Developer Course 2 e OutSystems Developer Course 3. As três formações realizadas foram ministradas em plataformas de e-learning, sendo que as da framework ITIL foram na plataforma SkillPort [4] da SkillSoft, e as da plataforma OutSystems foram na OutSystems Agile Network Academy [5]. 23

44 Capítulo 3 Processos implementados No âmbito do presente projecto, foram implementados seis processos da framework ITIL v3, de modo a cumprir os objectivos estabelecidos, no que ao desenvolvimento da solução diz respeito. Os processos encontram-se destacados na Figura 9. Fig. 9 Processos ITIL v3 implementados e respectivo mapeamento A implementação desses processos está organizada da seguinte forma: Conjunto de quatro processos (Incident Management, Problem Management, Change Management e Release & Deployment Management) implementado em parceria com o outro PEI; e 24

45 Dois processos (Service Asset & Configuration Management e Service Level Management) da responsabilidade do autor. Seguidamente, descreve-se cada um dos processos implementados. 3.1 Service Asset & Configuration Management O processo de Service Asset & Configuration Management (SACM), integrado no módulo Service Transition [6] do ITIL v3, é um dos dois processos que serão detalhados neste relatório. Este processo [6] visa definir e controlar os componentes dos serviços e da infraestrutura da organização, bem como manter informação de configuração precisa sobre o estado desses serviços e da própria infra-estrutura. Por outras palavras, o propósito deste processo é identificar, controlar, registar, reportar, auditar e verificar os activos de serviços e Configuration Items (CI), incluindo versões, baselines, componentes constitutivos, os seus atributos e relações. Neste processo, os activos de serviços e os CI s são os conceitos centrais. Um activo de serviços, ou simplesmente activo, representa um componente da infra-estrutura tecnológica organizacional usado para prestar um serviço ao Cliente. Um CI representa um componente de um desses activos de serviços O SACM pretende ainda proteger a integridade dos activos de serviço e os itens de configuração, ao longo do ciclo de vida do serviço, bem como assegurar a integridade dos activos e configurações requeridas para controlar os mesmos e a infra-estrutura de Tecnologias de Informação (TI), estabelecendo e mantendo um Configuration Management System preciso e completo. 25

46 A componente de Asset Management do processo abrange todos os activos de serviços em todo o ciclo de vida do serviço. Fornece um inventário completo dos activos, sendo responsável pelo seu controlo, e inclui: Toda a gestão do ciclo de vida de TI e dos activos de serviço, desde a aquisição até à eliminação; e Manutenção do inventário de activos. Por seu lado, o Configuration Management assegura que os componentes seleccionados de um serviço completo, sistema ou produto são identificados, mantidos e que as alterações efectuadas sobre eles são controladas. Também garante que o lançamento de versões, em ambientes controlados e operacionais, é realizado com base em aprovações formais. Além disso, fornece um modelo de configuração dos serviços, activos e itens de configuração. A componente de Configuration Management permite ainda ter acesso ao modelo dos serviços, dos activos e da infra-estrutura, registando as relações entre os itens de configuração. Isto permite que outros processos possam gerar informação valiosa, tal como: Avaliação do impacto e da causa dos incidentes e problemas; Avaliação do impacto de alterações propostas; Planeamento e desenho de novos serviços ou alteração de serviços existentes; Planeamento de actualização da tecnologia e do software; Planeamento do lançamento de versões de software/hardware desenvolvido e migração de activos de serviços para diferentes localizações; e Optimização da utilização dos activos e dos custos. 26

47 3.2 Service Level Management O processo de Service Level Management (SLM), parte integrante do módulo Service Design [7] do ITIL v3, é um dos processos, para além do SACM, que serão alvo de maior detalhe neste relatório. A função deste processo é negociar, acordar e documentar níveis de serviço adequados com o negócio, fazendo depois toda a monitorização desses níveis de serviço, através da produção de relatórios onde se possa comparar o desempenho real com o que foi acordado. Assim, o objectivo do SLM é garantir que todos os serviços em produção, e respectivo desempenho, são medidos de um modo profissional e consistente em toda a organização, fazendo com que esses serviços, bem como os relatórios produzidos, satisfaçam as necessidades do negócio e dos clientes. Deste processo, resultam vários documentos [3]: Service Level Agreement (SLA) Um acordo entre o prestador de serviços de TI e o cliente. Descreve o serviço de TI, os níveis de serviço e as responsabilidades dos dois intervenientes. Um único SLA pode cobrir vários serviços ou vários clientes; Operational Level Agreement (OLA) Um acordo entre um prestador de serviços de TI e uma outra parte da mesma organização. Suporta a prestação dos serviços de TI, definindo os bens ou serviços a fornecer, bem como as responsabilidades de ambas as partes. Por exemplo, pode haver um OLA entre: o O prestador de serviços de TI e o departamento comercial para obter hardware em períodos de tempo acordados; ou o O Service Desk e um grupo de suporte para o fornecimento de resolução de incidentes em períodos de tempo acordados. Underpinning Contract (UC) Um contrato entre o prestador de serviços de TI e uma organização externa, a qual fornece bens ou serviços que apoiam a prestação de um serviço de TI a um cliente. O UC define as metas e 27

48 responsabilidades necessárias para satisfazer os níveis de serviço acordados num SLA; e Service Improvement Plan (SIP) Plano formal para implementar melhoramentos num processo ou num serviço de TI. 3.3 Outros processos Seguidamente, descrevem-se os processos desenvolvidos em conjunto com o outro PEI Incident Management O propósito deste processo, descrito no módulo Service Operation [8], é o de restaurar o normal funcionamento do serviço de TI no mais curto espaço de tempo possível, minimizando assim o impacto negativo no negócio. Um incidente [8] é uma interrupção não planeada de um serviço de TI, ou uma redução na qualidade do mesmo, bem como a falha de um CI que ainda não tenha tido impacto no serviço. O ciclo de vida de um incidente começa com a sua detecção, geralmente pelo processo de Event Management (não abordado neste projecto) ou por utilizadores que contactam o service desk, seguindo-se o seu registo e categorização, com o objectivo de identificar a equipa de apoio que o tratará e para fazer uma análise de tendências. Após um diagnóstico inicial, o incidente pode ser escalado para um nível de suporte mais especializado, caso não se consiga resolvê-lo dentro do tempo esperado. De seguida, a equipa de suporte investiga as causas que estão na origem do incidente e põe em prática os resultados da sua investigação. Depois de efectuados os devidos testes, o Service Desk tem de garantir que o utilizador ficou satisfeito com a resolução para dar o incidente como encerrado, através do envio de um inquérito de satisfação que o 28

49 utilizador deverá preencher com o seu feedback e posteriormente submeter para o Service Desk Problem Management Neste processo, também ele descrito no módulo Service Operation [8], a atenção centrase em minimizar o impacto de incidentes que não podem ser prevenidos e prevenir a recorrência dos incidentes. Um problema [8] é a causa de um ou mais incidentes. Aquando do seu registo, a sua causa não é conhecida, pelo que o processo de Problem Management é responsável por investigar essa causa e tentar resolver o problema. A partir do momento em que se conhece a causa para um problema, este passa a ser um erro conhecido. Este processo inclui, para além do diagnóstico das causas dos problemas, determinar a sua resolução e garantir que a mesma é implementada. Para além disso, também é responsável por gerir a informação sobre problemas e respectivas soluções. Aqui, os problemas são categorizados de forma semelhante aos incidentes, mas o objectivo é entender as causas, documentar as soluções (numa Known Error Database, o que melhora a eficácia e eficiência do Incident Management) e requerer alterações que permanentemente resolvam os problemas Change Management O processo de Change Management, descrito no módulo Service Transition [6], tem a missão de gerir o ciclo de vida das alterações de uma maneira controlada, nomeadamente o registo, avaliação, autorização, prioritização, planeamento, teste, implementação, documentação e revisão das mesmas. 29

50 Uma alteração [6] é a adição, modificação ou remoção de um serviço autorizado, planeado ou suportado, ou componente de um serviço e respectiva documentação. O propósito deste processo é o de garantir que são utilizados métodos padronizados para o tratamento eficiente e imediato de todas as alterações, que todas elas são registadas no Configuration Management System (CMS) e que o risco geral do negócio é optimizado. O processo de Change Management é relevante para todas as etapas do ciclo de vida do serviço, sendo aplicado a todos os níveis da gestão de serviços: estratégico, táctico e operacional. Este processo tem como finalidade a prestação de serviços mais precisos, mais rápidos e com menos erros, mas também a concentração dos recursos, financeiros ou não, nas alterações que trazem maior benefício ao negócio Release & Deployment Management Este processo, descrito no módulo Service Transition [6], tem como objectivo principal gerir todos os aspectos relacionados com a entrada em produção das várias releases dos serviços prestados pela organização, assim como o estabelecimento de um uso eficaz dos mesmos, cobrindo assim todas as fases de montagem e implementação do novo serviço, ou de um serviço alterado, desde o planeamento da release até ao suporte inicial no ambiente de produção. O sucesso deste processo acarreta grande valor para o negócio, na medida em que as releases são lançadas com rapidez, risco e custos optimizados. É igualmente possível obter, através deste processo, uma implementação consistente, apropriada e auditável de serviços úteis para o negócio. 30

51 Capítulo 4 Trabalho relacionado Uma vez identificados os processos a desenvolver no âmbito deste projecto, procedeuse à produção de um documento comparativo de ferramentas de Service Desk Management (SDM) líderes de mercado, a fim de suportar a caracterização de uma solução deste género e tendo como objectivos principais: Obter uma melhor compreensão dos processos a implementar, para posterior construção do documento de análise de requisitos; e Avaliar o comportamento de soluções best-of-breed de mercado face aos requisitos base disponibilizados. 4.1 Benchmark de mercado Para uma análise das melhores ferramentas de SDM de mercado, optou-se por recorrer à Gartner [9] e à Forrester [10], pois são duas empresas, reconhecidas a nível mundial, especializadas em pesquisa e consultoria em Tecnologias de Informação (TI). A sua actividade centra-se em apoiar os business and technology leaders a terem o pragmatismo, a visão de futuro e a introspecção necessárias para tomarem as decisões mais acertadas no dia-a-dia da actividade das suas empresas. 31

52 Fig. 10 Estudos de 2008 da Forrester [11] e da Gartner [12] Para decidir quais as ferramentas que iriam ser avaliadas, tendo em vista a elaboração do documento de trabalho relacionado, foram considerados, tanto o estudo [11] elaborado em Abril de 2008 pela Forrester, como o estudo [12] realizado em Outubro de 2008 pela Gartner. Os resultados destes estudos estão ilustrados na Figura 10. Segundo a Forrester, as quatro ferramentas líderes de mercado são a BMC Software - Remedy IT Service Management, a HP Service Manager, a CA Unicenter Service Desk e a IBM Tivoli Service Request Manager, pois têm uma oferta de soluções e uma estratégia de negócio fortes, fazendo com que ocupem uma posição de liderança de mercado actualmente. Segundo a Gartner, as ferramentas líderes de mercado são a BMC Software - Remedy IT Service Management e a HP Service Manager, pois são as que apresentam, não só uma visão de negócio mais consolidada, mas também uma maior capacidade para implementar essa visão. 32

53 Analisando os dois estudos, concluiu-se que deveriam ser analisadas as quatro ferramentas apontadas no estudo da Forrester. Porém, decidiu-se que só se iriam avaliar as ferramentas da BMC e da CA, uma vez que são as que têm mais expressão no mercado português. 4.2 Processos analisados Com base na análise das referidas ferramentas, foram avaliados os requisitos base disponibilizados, sendo estes suportados pelos seis processos a implementar: Incident Management; Problem Management; Change Management; Release & Deployment Management; Service Asset & Configuration Management; e Service Level Management. Para a análise comparativa entre a solução a desenvolver e as ferramentas supramencionadas, usaram-se como fontes de informação, manuais de utilizador [13] [14] [15] e vídeos demonstrativos das ferramentas. Por falta de documentação disponível, não foi possível analisar os requisitos suportados pelos processos Release & Deployment Management e Service Level Management. 33

54 4.3 Método de avaliação Para a análise das ferramentas da BMC e da CA, usou-se, para cada requisito, a seguinte abordagem: Fig. 11 Modelo de avaliação de ferramentas concorrentes Inicialmente, determinou-se que o peso atribuído a cada requisito seria o mesmo (ponderação usada no cálculo das médias apresentadas na secção 4.4), procedendo-se posteriormente à sua avaliação com base numa escala de 0 a 5. Consoante a avaliação feita e a documentação existente das ferramentas acima mencionadas, elaboraram-se comentários sobre a forma como cada uma responde aos mesmos. De acordo com os valores obtidos da avaliação a cada requisito, efectuou-se uma média ponderada sobre o modo como as ferramentas respondem ao conjunto dos requisitos. O valor representa essa média ponderada, de 0 a 5, que cada processo obteve segundo a avaliação realizada a todos os requisitos, com o seguinte racional de avaliação: 0 Inexistente: Ausência total de evidências da implementação do requisito; 34

55 1 Inicial/Ad-hoc: Há evidências que o requisito existe e deve ser considerado. No entanto, existem apenas abordagens ao mesmo; 2 Básico/Incipiente: O requisito foi desenvolvido, porém não há documentação de que o requisito tenha sido padronizado. Possível tendência a erros; 3 Definido: O requisito foi padronizado e documentado, contudo é pouco provável que sejam detectadas falhas durante a execução em ambiente de produção. A forma como o requisito foi implementado não é a mais sofisticada; 4 Gerido: É possível monitorizar e medir o cumprimento do requisito. Embora haja automatização, o requisito não está optimizado; e 5 Optimizado: O requisito foi refinado ao nível das melhores práticas, com base nos resultados de modelagem de maturidade com outras ferramentas. O requisito está assim automatizado e optimizado. 4.4 Resultados Na análise final das duas ferramentas, o resultado obtido para BMC Software Remedy IT Service Management e CA Unicenter Service Desk foi de 2,67 e 2,79, respectivamente. Os resultados obtidos representam a média ponderada dos valores de cada requisito classificado. Deste modo, tanto a ferramenta da BMC como a da CA são ferramentas cujos requisitos foram documentados e implementados, no entanto não da forma mais sofisticada. A Figura 12 reflecte estas conclusões. 35

56 Fig. 12 Resultado da avaliação das soluções por dimensão Neste gráfico, os dois primeiros pares de barras representam, respectivamente, os resultados obtidos para os requisitos funcionais e os resultados obtidos para os requisitos de integração. O terceiro par de barras representa a média dos dois resultados anteriores. A nível funcional (ver Figura 13), a ferramenta da BMC tem um melhor desempenho em Incident Management e Change Management, enquanto a ferramenta da CA se destaca pela positiva em Problem Management e Service Asset & Configuration Management. 36

57 Fig. 13 Resultado da avaliação dos requisitos funcionais Por outro lado, a nível de integração (ver Figura 14), a ferramenta da BMC é superior no processo de Incident Management, enquanto a ferramenta da CA se superioriza em Problem Management e Change Management. Fig. 14 Resultado da avaliação dos requisitos de integração 37

58 Após a análise das ferramentas mencionadas no decorrer deste estudo comparativo, a BMC Software - Remedy IT Service Managem System e CA Unicenter Service Desk, chegou-se à conclusão de que a comparação efectuada não foi a mais precisa devido à falta de documentação sobre os processos de Release & Deployment Managment e Service Level Manangement, bem como sobre alguns dos requisitos dos outros processos analisados. 38

59 Capítulo 5 Análise do problema e desenho da solução Este capítulo tem o objectivo de fornecer uma descrição detalhada dos documentos produzidos no âmbito das tarefas de análise do problema e desenho da solução. São apresentados, para além do documento de análise de requisitos, os modelos de casos de uso, de domínio e de desenho. 5.1 Definição de requisitos Na Fase II do projecto (ver secção 2.4), para além da elaboração do documento comparativo de ferramentas (DCF) de Service Desk Management, descrito no Capítulo 4, foi produzido o documento de análise de requisitos, baseado no documento anterior e vital para o sucesso, em primeiro lugar da etapa seguinte (Etapa II CONCEPÇÃO), e em segundo lugar de todo o projecto, pois uma boa análise de requisitos é o primeiro grande passo para se conseguir implementar uma aplicação de qualidade e que cumpra todos os requisitos especificados. Depois de produzido o DCF, a tarefa que se seguiu foi a elaboração do documento de análise de requisitos, um dos deliverables cruciais para o bom desenvolvimento da solução proposta. 39

60 Este documento teve como objectivos principais: Disponibilizar informação detalhada sobre um conjunto de requisitos que deva servir de base para a fase de desenho da aplicação; e Complementar o entendimento dos processos a implementar, com base na avaliação de versões trial de outras soluções e nos comentários dos utilizadores finais proferidos em entrevistas com os mesmos. Para a produção deste documento, foram analisadas várias ferramentas, com o objectivo de obter informação complementar relativamente aos seis processos a implementar, os quais estão listados na secção 4.2. A especificação de cada um dos processos pretendeu detalhar o workflow existente no mesmo, bem como os atributos que constarão nos formulários e nas entidades associadas aos processos. Para o detalhe e entendimento dos processos, foram utilizadas como fontes de informação, versões trial das ferramentas acima mencionadas e comentários dos utilizadores finais obtidos em entrevistas. Os utilizadores entrevistados foram os stakeholders da instituição de acolhimento indicados no organograma do projecto (Sponsor, Manager de Quality Assurance e Gestor de Projecto), o gestor da área administrativa da empresa e dois outros com perfil de administrador do sistema, pois são aqueles que desempenham funções enquadradas nos perfis de utilizador identificados como inerentes à solução proposta. Após a análise das versões trial das ferramentas supramencionadas, verificou-se a impossibilidade de compreender, na sua totalidade, alguns dos processos a implementar no âmbito deste projecto. Dos seis processos a implementar, não foi possível especificar o processo Release & Deployment Management, visto que as ferramentas analisadas não o implementam. 40

61 Porém, este problema foi mitigado, uma vez que durante as entrevistas com futuros utilizadores da aplicação, a maior parte dos processos foram especificados segundo a sua percepção dos mesmos. Deste modo, e ao longo de cada entrevista, foi possível obter informação complementar à especificação já existente de cada processo. No final do processo de levantamento de requisitos, foram compiladas as descrições obtidas em cada uma das entrevistas, bem como as descrições baseadas em ferramentas líderes de mercado e outras ferramentas, e construída uma descrição final com a especificação detalhada de cada requisito, de modo a ser usada na fase de desenho da aplicação. 5.2 Desenho do modelo conceptual A Etapa II do projecto iniciou-se com a elaboração do desenho do modelo conceptual da solução implementada. O Sprint 1, e simultaneamente a Fase III, compreendeu a realização desta actividade, que consistiu em produzir cada um dos três documentos previstos para esta fase, usando a notação UML. Seguidamente detalham-se os três documentos elaborados: Modelo de Casos de Uso, Modelo de Domínio e Modelo de Desenho Modelo de Casos de Uso Este documento teve o propósito de ilustrar o desenho dos casos de uso referentes à solução de SDM desenvolvida. Nesse sentido, os seus objectivos principais foram: Identificar, para cada processo, os casos de uso envolvidos, de modo a perceber quais as funcionalidades a implementar e a dar cobro a todos os requisitos propostos; e Especificar, para cada caso de uso, o cenário principal, os cenários alternativos, bem como os actores envolvidos. 41

62 Com base na descrição final de cada requisito, elaborada no documento de análise de requisitos, procedeu-se à identificação dos casos de uso de cada um dos seis processos, e também dos requisitos gerais, a implementar no âmbito da solução de SDM. A especificação de cada um dos casos de uso pretendeu ser a base principal para a identificação das funcionalidades a implementar, assim como os actores intervenientes em cada uma delas, os quais são baseados nos papéis ITIL v3 associados a cada processo. Para essa especificação, em cada processo, procedeu-se, em primeiro lugar, à elaboração de um Diagrama de Casos de Uso simples, seguindo-se depois a descrição do cenário principal de utilização, assim como dos possíveis cenários alternativos, para cada um dos casos de uso identificados. As Figuras 15 e 16 mostram os Diagramas de Casos de Uso simples para os processos Service Asset & Configuration Management e Service Level Management. Fig. 15 Diagrama de Casos de Uso simples do processo Service Asset & Configuration Management 42

63 Fig. 16 Diagrama de Casos de Uso simples do processo Service Level Management Após a elaboração deste documento, concluiu-se que foram cumpridos os dois objectivos iniciais do mesmo. Com o desenho dos Diagramas de Casos de Uso, foram identificadas as fronteiras do sistema, ou seja, aquilo que pertence e não pertence a ele Modelo de Domínio O segundo deliverable desta fase consistiu no desenho do Modelo de Domínio referente à solução de SDM implementada. Os objectivos principais do documento foram: Identificar e representar as classes conceptuais do domínio do problema; Identificar e representar as relações conceptuais entre essas classes; e Constituir-se como uma das bases principais para a construção da base de dados relacional da aplicação. Neste documento, foram considerados os conceitos envolvidos na definição do problema proposto para o Projecto de Estágio, representados através de classes conceptuais, bem como as relações conceptuais existentes entre os mesmos. Neste sentido, o processo de produção do Modelo de Domínio foi o seguinte: 1. Identificar as classes conceptuais, inspeccionando os cenários dos casos de uso que foram alvo do Sprint 1; 43

64 2. Desenhar essas classes no Diagrama de Domínio; e 3. Adicionar as associações entre as classes, de modo a representar relações cujo conhecimento é importante preservar, mesmo que seja durante pouco tempo. Com a produção deste documento, conclui-se que todos os objectivos propostos para a realização do Modelo de Domínio foram cumpridos: as classes conceptuais inerentes ao problema, bem como as relações entre elas, ficaram identificadas, permitindo assim ter uma boa base para implementação da base de dados relacional da aplicação Modelo de Desenho Por fim, o terceiro e último deliverable da Fase III do projecto consistiu na elaboração do Modelo de Desenho da solução desenvolvida, cujos objectivos principais foram: Capturar a topologia (ambiente) de hardware da solução, sobre a qual são executados os componentes de software; e Esquematizar os processos do sistema, as entidades externas com quem este dialoga e os fluxos de dados existentes. Posto isto, o Modelo de Desenho pretendeu, por um lado, dar a conhecer, através de diagramas de arquitectura, os principais componentes de hardware, e respectivas características técnicas, que fazem parte de cada um dos ambientes em que a aplicação esteve presente (Ambiente de desenvolvimento, Ambiente de Pré-produção/Qualidade e Ambiente de Produção) e, por outro lado, identificar, através de Diagramas de Fluxos de Dados (DFD) de nível 0 (Figs. 20 e 21), os processos, as entidades externas e os principais fluxos de dados que constituem a mesma aplicação. Os diagramas de arquitectura foram construídos da seguinte forma: 1. Averiguação da arquitectura de hardware da instituição de acolhimento para cada ambiente da aplicação; e 44

65 2. Obtenção das especificações técnicas dos vários componentes presentes nessa arquitectura. As Figuras 17, 18 e 19 representam os diagramas de arquitectura para cada um dos 3 ambientes por onde a solução final esteve/está instalada: Ambiente de Desenvolvimento, Ambiente de Qualidade e Ambiente de Produção. Ambiente de Desenvolvimento Browser Lenovo T400 Caracteristicas Técnicas Application Server Máquina Sistema Operativo CPU Lenovo T400 Windows XP Pro SP3 Intel Core 2 Duo P8600 2,40GHZ Application Servers Web Server RAM Disco Software 3 GB 160 GB SQL Server 2005 Caracteristicas Técnicas DB Server Application Server Máquina Sistema Operativo Lenovo T400 Windows XP Pro SP3 DB Server CPU Intel Core 2 Duo P8600 2,40GHZ DB Server RAM Disco 3 GB 160 GB Fig. 17 Diagrama de arquitectura do Ambiente de Desenvolvimento 45

66 Caracteristicas Técnicas Application Server Ambiente de Qualidade Máquina HP proliant dl 380 g6 Sistema Operativo Windows 2008 r8 Browser Lenovo CPU RAM Intel xeon E GB Disco 300GB Software SQL Server 2005 Web Server Application Servers Caracteristicas Técnicas DB Server Application Server Máquina Sistema Operativo HP proliant dl 380 g6 Windows 2008 r8 DB Server DB Server CPU RAM Disco Intel xeon E GB 3 x 150GB Fig. 18 Diagrama de arquitectura do Ambiente de Qualidade Caracteristicas Técnicas Application Server Ambiente de Produção Máquina HP proliant dl 380 g6 Browser Lenovo Sistema Operativo CPU Windows 2008 r8 Intel xeon E5506 RAM 6 GB Disco 3 x 150GB Web Server Software SQL Server 2005 Application Servers Caracteristicas Técnicas DB Server Application Server Máquina Sistema Operativo HP proliant dl 380 g6 Windows 2008 r8 DB Server CPU Intel xeon E5506 DB Server RAM Disco 6 GB 3 x 150GB Fig. 19 Diagrama de arquitectura do Ambiente de Produção 46

67 Para elaborar os DFD s de nível 0, utilizou-se o seguinte processo: 1. Visualização dos Diagramas de Casos de Uso simples, elaborados no Modelo de Casos de Uso, a fim de identificar, como entidades externas, os actores envolvidos em cada processo a implementar; e 2. Examinação das descrições dos casos de uso, produzidas no mesmo documento, com intuito de determinar os fluxos de dados entre as entidades externas e os vários processos do sistema. As Figuras 20 e 21 ilustram os DFD s de nível 0 elaborados para os processos Service Asset & Configuration Management e Service Level Management. Fig. 20 DFD de nível 0 do processo Service Asset & Configuration Management 47

68 Fig. 21 DFD de nível 0 do processo Service Level Management Após a elaboração deste documento, determinou-se a arquitectura do sistema e as suas componentes para os três ambientes da aplicação, bem como o fluxo de dados entre os processos implementados e os actores envolvidos no mesmo. 48

69 Capítulo 6 Implementação da solução O presente capítulo descreve em pormenor a implementação dos dois processos da framework ITIL v3 que são objecto deste relatório: Service Asset & Configuration Management (SACM) e Service Level Management (SLM). A implementação destes processos insere-se no contexto da solução de SDM proposta para este projecto, ou seja, os dois processos constituem dois dos oito módulos da aplicação. De referir que houve participação activa na implementação dos outros módulos, porém apenas serão enfatizados os dois módulos acima mencionados. 6.1 Service Asset & Configuration Management Como referido no contexto teórico apresentado na secção 3.1 deste relatório e com o objectivo de cumprir os requisitos disponibilizados, o módulo de SACM da aplicação proporciona duas funcionalidades principais, que são a gestão de cada um dos activos de TI individualmente e a gestão desses mesmos activos como um todo, ou seja, através de inventários. Para além disso, este módulo conta ainda com uma secção no painel de administração onde se pode configurar a hierarquia (tipos de componentes e modelos) dos activos, os campos adicionais da página de detalhes de cada um, os estados dos activos e as sub-atribuições. 49

70 Neste módulo, são considerados os dois papéis ITIL v3 fundamentais para a sua concretização: Configuration Manager: Papel desempenhado pela pessoa responsável por gerir todo o processo de SACM. Possui as permissões máximas sobre o mesmo; e Configuration Team Member: Papel desempenhado por uma pessoa da equipa de gestão de activos, a qual está subordinada à pessoa que desempenha o papel anterior. Possui permissões semelhantes às do papel anterior, com a excepção de não poder aprovar ou rejeitar o registo de um novo activo. Seguidamente, são detalhadas cada uma das funcionalidades deste módulo, juntamente com a secção do painel de administração Secção no painel de administração Como referido anteriormente, nesta secção, o administrador do sistema tem a possibilidade de configurar vários aspectos relacionados com o módulo de SACM. Esses aspectos passam pela configuração de: Hierarquia de activos Na solução de SDM, os activos estão organizados segundo uma hierarquia de 3 níveis, em que no nível mais baixo estão cada um dos activos registados, os quais estão agrupados em modelos (nível intermédio) que, por sua vez, estão afectos a um tipo de componente (nível mais alto). Um exemplo desta hierarquia é ter o activo com o número de série X que tem o modelo Lenovo T400, o qual pertence ao tipo de componente Portátil. Posto isto, esta área é composta por uma lista de tipos de componentes (Figura 22) e por uma lista de modelos (Figura 24). 50

71 Fig. 22 Ecrã com a lista de tipos de componentes A adição de um novo tipo de componentes é efectuada através de uma janela de pop-up (Figura 23), que é acedida através do botão Adicionar tipos de componente Fig. 23 Janela de pop-up para a criação/edição de um tipo de componente Como um tipo de componente é apenas caracterizado por um nome e uma descrição, nesta janela, apenas é necessário introduzir estes dados e pressionar um dos botões de gravação para registar o novo tipo de componente na base de dados. Para a edição de um tipo de componente existente, é usada a mesma janela de pop-up, a qual é acedida 51

72 através da hiperligação presente no nome do tipo pretendido na tabela de tipos de componente. Para remover um tipo de componente, o administrador de sistema deve pressionar o botão Remover à frente do tipo pretendido, fazendo despoletar a acção de remoção respectiva. Esta acção começa por verificar se existem activos associados ao tipo de componente e, apenas no caso de não existirem, é que o tipo é removido; caso contrário, isso não é possível. A lista de modelos de activos é gerida de forma semelhante à da lista de tipos de componentes. Fig. 24 Ecrã com a lista de modelos de activos Para além do nome e da descrição, um modelo de activos é caracterizado pelo tipo de componente a que pertence e pelo fornecedor que fornece os activos desse modelo à organização, pelo que, neste ecrã, a lista de modelos pode ser filtrada por tipo de componente e/ou por fornecedor. A adição de um novo modelo é efectuada através de uma janela de pop-up (Figura 25), que é acedida através do botão Adicionar modelos 52

73 Fig. 25 Janela de pop-up para a criação/edição de um modelo de activos Nesta janela, é necessário introduzir todos os dados indicados e pressionar um dos botões de gravação para registar o novo modelo de activos na base de dados. Para a edição de um modelo existente, é usada a mesma janela de pop-up, a qual é acedida através da hiperligação presente no nome do modelo pretendido na tabela de modelos. Para remover um modelo de activos, o administrador de sistema deve pressionar o botão Remover à frente do modelo pretendido, fazendo despoletar a acção de remoção respectiva. Esta acção, à semelhança dos tipos de componentes, começa por verificar se existem activos associados ao modelo e, apenas no caso de não existirem, é que o modelo é removido; caso contrário, isso não é possível. Formulário de detalhes Nesta área, são configurados campos adicionais que podem ser adicionados ao formulário de detalhes de um activo. Esta opção insere-se no carácter genérico da aplicação, permitindo deste modo que qualquer organização possa definir o formulário de acordo com as suas necessidades. No entanto, é importante referir que aqui apenas se 53

74 configuram campos adicionais, não sendo possível alterar os campos pré-definidos do formulário. Fig. 26 Ecrã com a lista de campos adicionais A área de configuração dos campos adicionais apresenta uma lista com todos os campos já adicionados, na qual podemos visualizar o nome e o tipo de dados 1 de cada campo. Esta lista pode ser filtrada por tipo de dados. Pressionando o botão Adicionar campos, é iniciada a criação de um novo campo adicional. Para isso, foi implementada a página da Figura Existem 4 tipos de dados possíveis: Texto, Numérico, Data/Hora e DropBox. 54

75 Fig. 27 Ecrã de criação/edição de um campo adicional No topo da página, o utilizador tem sempre a indicação de quantos campos, por tipo de dados, ainda pode criar. Foi decidido impor um limite de campos que se podem criar devido à necessidade de guardar os valores inseridos nesses campos e não ser possível prever, em tempo de execução, quantos campos o administrador decidiu criar. Após o preenchimento dos dados do novo campo e da submissão dos mesmos, o novo campo é registado na base de dados. Para a edição de um campo existente, é usada a mesma janela (Figura 27), a qual é acedida através da hiperligação presente no nome do campo pretendido na tabela de campos adicionais. Para remover um campo adicional, o administrador de sistema deve pressionar o botão Remover à frente do campo pretendido, fazendo despoletar a acção de remoção respectiva. 55

76 Estados A área de configuração dos estados dos activos tem o objectivo de definir quais os estados que um activo de TI pode ter ao longo do seu ciclo de vida. Segundo a framework ITIL v3, existe um conjunto de estados pré-definidos, os quais estão presentes na aplicação e não podem ser alterados pelo administrador. Sendo assim, nesta área, apenas é possível configurar estados adicionais, o que, mais uma vez, está inserido no carácter genérico da solução. Esta área, à semelhança de outras, é composta por uma tabela com a lista de estados registados (Figura 28) onde, para adicionar um novo estado, deve-se pressionar o botão Adicionar estados. Fig. 28 Ecrã com a lista de estados dos activos Isto faz com que surja uma janela de pop-up como aquela que mostra a Figura

77 Fig. 29 Janela de pop-up para a criação/edição de um estado de activo Nesta janela, apenas é preciso inserir o nome e a descrição do novo estado, pressionando depois um dos botões de gravação para que esse estado seja gravado na base de dados. Para a edição de um estado existente, é usada a mesma janela, a qual é acedida através da hiperligação presente no nome do estado pretendido na tabela de estados dos activos. Para remover um estado, o administrador de sistema deve pressionar o botão Remover à frente do estado pretendido, fazendo despoletar a acção de remoção respectiva. Como já foi referido, apenas os estados não pré-definidos podem ser alterados e/ou removidos. 57

78 Sub-atribuições Nesta área, são configuradas as sub-atribuições que os activos de TI podem ter. Uma sub-atribuição designa o tipo de pessoa à qual o proprietário do activo delegou a responsabilidade de fazer uso desse mesmo activo. Por exemplo, a sub-atribuição Pessoal significa que o activo é única e exclusivamente da responsabilidade do proprietário do mesmo. Por outro lado, a sub-atribuição Outsourcer significa que o proprietário do activo delegou a responsabilidade do mesmo a um colaborador em regime de outsourcing. Mais uma vez, esta área é composta por uma tabela com a lista de sub-atribuições registadas (Figura 30) onde, para adicionar uma nova sub-atribuição, deve-se pressionar o botão Adicionar sub-atribuições. Fig. 30 Ecrã com a lista de sub-atribuições Isto faz com que surja uma janela de pop-up como aquela que mostra a Figura 31. Fig. 31 Janela de pop-up para a criação/edição de uma sub-atribuição 58

79 Nesta janela, apenas é preciso inserir o nome da nova sub-atribuição, pressionando depois um dos botões de gravação para que essa sub-atribuição seja gravada na base de dados. Para a edição de uma sub-atribuição existente, é usada a mesma janela, a qual é acedida através da hiperligação presente no nome da sub-atribuição pretendida na tabela de sub-atribuições. Para remover uma sub-atribuição, o administrador de sistema deve pressionar o botão Remover à frente da sub-atribuição pretendida, fazendo despoletar a acção de remoção respectiva Gestão de activos A funcionalidade de gestão de activos tem a missão de facilitar a gestão de cada um dos activos de TI da organização individualmente. Para implementar esta funcionalidade, foi desenvolvido, em primeiro lugar, o ecrã Os meus activos (Figura 32) que é acessível a todos os utilizadores e onde cada um deles pode visualizar os activos de que é proprietário e ter acesso aos detalhes de cada um. Fig. 32 Ecrã com a lista de activos afectos a um utilizador Os activos do utilizador estão listados na tabela presente neste ecrã, a qual permite visualizar, para cada activo, o nome (contém hiperligação para a página de detalhes), o tipo de componente, o modelo, a versão e o estado em que se encontra actualmente, para além dessa tabela poder ser filtrada por tipo de componente, modelo e estado. 59

80 O segundo ecrã implementado no âmbito desta funcionalidade foi o ecrã Lista de activos (Figura 33), o qual está acessível apenas a utilizadores que possuam os papéis de Configuration Manager ou Configuration Team Member. Fig. 33 Ecrã com as listas de activos A figura acima mostra o ecrã como ele é visto pelo Configuration Manager. Este utilizador tem acesso a duas tabelas de activos nesta página: Activos para aprovar: Esta tabela só está disponível para este utilizador e lista os activos que foram submetidos para sua aprovação/rejeição. Este processo será explicado mais adiante nesta secção; e Todos os activos: Esta tabela está disponível, quer ao Configuration Manager, quer aos utilizadores com o papel de Configuration Team Member, e lista todos os activos registados na aplicação. O processo de registo de um novo activo tem início quando é escolhida a opção criada para o efeito no menu principal, a qual faz surgir um ecrã como aquele que exibe a Figura

81 Fig. 34 Ecrã de escolha do modo de registo de um novo activo Neste ecrã, o utilizador deve escolher o modo como quer registar o novo activo: 1. Novo activo: Proporciona o registo do novo activo de raiz, ou seja, com todos os campos do formulário de registo vazios; ou 2. A partir de baseline: O utilizador deve seleccionar, da tabela que surge automaticamente com a escolha desta opção, o activo a partir do qual quer registar o novo activo. Esta tabela é preenchida com a lista de todos os activos que foram registados como baseline. Seleccionando o activo pretendido e confirmando essa escolha, é mostrado o ecrã de registo do novo activo com os campos do formulário preenchidos de acordo com os dados do activo escolhido (Figura 35). Isto permite o registo mais eficiente e mais rápido de novos activos. Fig. 35 Ecrã de registo de um novo activo Após o preenchimento dos campos do formulário e pressionando um dos botões de gravação, é iniciada a acção de registo do novo activo. Esta acção começa por verificar se o número de série do activo que se está a registar já existe na tabela de activos na 61

82 base de dados, uma vez que o número de série é um atributo do activo que o identifica univocamente. Posto isto, se o número de série já existir, é lançada uma mensagem de erro informando o utilizador de que não é possível proceder com o registo; caso contrário, o novo activo é registado. Se o utilizador que registou o novo activo for um Configuration Team Member, o activo fica com o estado Submetido, ficando assim sujeito à aprovação/rejeição do Configuration Manager. O activo fica, deste modo, disponível na lista de activos para aprovar. Se o Configuration Manager aprovar o activo, este fica definitivamente registado, passando para o estado Aprovado ; caso contrário, este utilizador deverá inserir os motivos pelos quais rejeita o novo activo, sendo esses motivos comunicados ao Configuration Team Member que efectuou o registo. Neste caso, o activo passa para o estado Rejeitado e o Configuration Team Member tem a possibilidade de efectuar as alterações necessárias, voltando depois a submeter essas alterações para o Configuration Manager. Estas opções de aprovação e rejeição estão disponíveis no ecrã de detalhes do activo, como mostra a Figura 36. Fig. 36 Página de detalhes de um activo Por outro lado, se tiver sido o Configuration Manager a efectuar o registo do novo activo, o mesmo fica automaticamente aprovado, pois não faz sentido este utilizador aprovar/rejeitar um activo que ele próprio registou. 62

83 No ecrã de detalhes de um activo, existe o separador Relações que permite editar as relações pai-filho que o activo tem estabelecidas. A Figura 37 exibe esse separador. Fig. 37 Separador Relações da página de detalhes de um activo A tabela presente no separador Relações lista todos os activos que são filhos do activo do qual estamos a visualizar os detalhes. Para editar as relações pai-filho desse activo, pressiona-se o botão Editar relações que faz com que surja a janela de popup como aquela que se pode observar na Figura 38. Fig. 38 Janela de pop-up para edição das relações pai-filho de um activo 63

84 Esta janela apresenta duas listas, sendo que a da esquerda é a de todos os activos que podem ser adicionados como filhos do activo e a da direita lista todos os activos que já foram identificados como filhos do mesmo. Através dos dois botões entre as duas listas, é possível mover os activos pretendidos entre elas. Após a confirmação das alterações, os activos presentes na lista da direita são mostrados na tabela de activos filho no separador Relações. Para uma correcta manutenção desta lista, criaram-se duas tabelas auxiliares na base de dados, AssetCacheIn e AssetCacheOut, em que a primeira guarda os activos identificados como filhos e a segunda guarda todos os outros activos que ainda podem ser identificados como tal. Sendo estas tabelas auxiliares, há a necessidade de limpar o seu conteúdo sempre que se quer utilizá-las, de modo a evitar inconsistências, pois estas tabelas são também utilizadas em funcionalidades de outros módulos onde é igualmente necessário lidar com uma lista de activos semelhante. Para remover um activo da lista de activos filho, pressiona-se o X vermelho ao lado da lista de activos e da tabela AssetCacheIn, e adicionado à tabela AssetCacheOut. Por fim, a página de detalhes de um activo apresenta um terceiro separador ( Histórico ) que permite consultar os logs de todas as acções efectuadas sobre o registo do activo. A Figura 39 exibe esse separador. Fig. 39 Separador Histórico da página de detalhes de um activo 64

85 6.1.3 Gestão de inventários Como referido anteriormente, a funcionalidade de gestão de inventários tem como objectivo gerir os inventários de activos de TI da organização. Para concretizar esta funcionalidade, foram desenvolvidos dois ecrãs principais: um com a lista de todos os inventários registados (Figura 40) e outro onde podemos aceder aos detalhes de cada um deles (Figura 41). Fig. 40 Ecrã com a lista de inventários Neste ecrã com a lista de inventários, podemos visualizar, para cada um deles, o seu título (contém hiperligação para a página de detalhes), a sua data de criação, a data da última actualização, bem como a pessoa que efectuou essa última actualização. Podemos ainda dar início à criação de um novo inventário. Tanto para a criação, como para a edição de um inventário, é utilizada a mesma página, cujo layout é adaptado consoante cada uma destas opções, tirando assim partido da reutilização de código. As diferenças entre os dois layouts são: Possibilidade de alteração do título do inventário na opção de criação, não sendo possível fazê-lo na edição. Esta opção foi tomada de acordo com as indicações fornecidas pelos utilizadores finais; e Visualização do separador com o histórico do inventário, apenas disponível para a opção de edição, pois não faz sentido estar disponível para a opção de criação, uma vez que, nesta opção, o inventário ainda não foi registado na base de dados. 65

86 Fig. 41 Página de detalhes de um inventário Nesta página, para além do título e da descrição, é disponibilizada uma lista, em forma de tabela, que contém os activos do inventário. Para uma correcta manutenção desta lista, utilizaram-se também as duas tabelas auxiliares AssetCacheIn e AssetCacheOut, em que, neste caso, a primeira guarda os activos que pertencem ao inventário e a segunda guarda todos os outros activos que ainda não estão no inventário. Para o preenchimento da lista e, consequentemente, da tabela de activos, usou-se a acção RefreshAssetTable, cujo código é o que está ilustrado na Figura

87 Fig. 42 Código da acção RefreshAssetTable, com os 4 caminhos de execução assinalados 67

88 Como o ecrã de detalhes de um inventário é utilizado para visualizar qualquer uma das versões do mesmo, decidiu-se que só se poderia editar a lista de activos se a versão que estivéssemos a visualizar fosse a mais recente, pois não faz sentido alterar versões antigas do inventário. Posto isto, esta acção permite preencher, quer a lista (tabela) de activos da versão mais recente, como a de uma versão antiga. Na Figura 42, estão assinalados os 4 possíveis caminhos de execução da acção RefreshAssetTable. Os caminhos 1 e 4 fazem com que a tabela de activos da versão mais recente seja preenchida (variável IsCurrentVersion com valor True) e os caminhos 2 e 3 preenchem a tabela de activos de uma versão antiga (variável IsCurrentVersion com valor False). No preenchimento das tabelas de activos, há que distinguir duas situações: 1. Carregamento da página: Ocorre quando o utilizador acede à página de detalhes do inventário através de uma hiperligação. Neste caso, se estiver a aceder à versão mais recente, é executado o caminho 1 da acção supramencionada, o qual começa por obter as versões mais recentes de todos os activos que pertencem ao inventário, através da acção GetAssetsByInventoryId e, de seguida, os insere, um a um, na lista que guarda esses activos (acção AssetList_Append), na lista que guarda os activos pré-adicionados 2 (acção PreAddedList_Append) e na tabela auxiliar AssetCacheIn (acção AddValuesToAssetCache). Se estiver a aceder a uma versão antiga, é executado o caminho 2; e 2. Interacção com uma tabela de activos: Ocorre quando o utilizador interage com uma tabela de activos do inventário, quer seja a da versão mais recente, quer seja a de uma versão antiga. Exemplos de interacção são a adição de 2 Lista usada aquando da gravação da nova versão do inventário para perceber quais os activos que foram adicionados e quais os que foram removidos, de uma versão para outra. 68

89 activos à tabela ou a ordenação dessa mesma tabela. No caso da versão mais recente, é executado o caminho 4, o qual usa a acção GetAssetCacheIn para carregar os activos que estão na tabela auxiliar AssetCacheIn e refrescar a tabela com esses activos. No caso de uma versão antiga, é executado o caminho 3. Para adicionar um ou mais activos à lista (e à tabela), está disponível o botão Adicionar activos que, quando pressionado, faz aparecer uma janela de pop-up, como mostra a Figura 43, onde se devem escolher os activos a adicionar. Fig. 43 Janela de pop-up para a escolha dos activos do inventário Esta janela contém uma lista de todos os activos que podem ser adicionados ao inventário, os quais estão guardados na tabela auxiliar AssetCacheOut. Escolhendo os activos, através das respectivas check boxes, e pressionando o botão Adicionar, os activos seleccionados são adicionados à tabela de activos, sendo removidos da tabela AssetCacheOut e inseridos na tabela AssetCacheIn, recorrendo a queries SQL apropriadas. Para remover um activo da lista, pressiona-se o X vermelho ao lado do nome do activo que se quer remover, fazendo assim com que o activo seja removido da lista de activos e da tabela AssetCacheIn, e adicionado à tabela AssetCacheOut. 69

90 6.2 Service Level Management De modo a cumprir os requisitos estabelecidos e baseado no contexto teórico apresentado na secção 3.2 deste documento, o módulo de SLM da aplicação desenvolvida apresenta duas secções principais, as quais são descritas nas subsecções seguintes. Neste módulo, um dos conceitos centrais é o de Service Level Agreement (SLA), o qual é tratado de duas formas: 1. Como um conjunto de pares tempo de resposta - tempo de resolução, ou seja, dado um tipo de ticket (incidente ou pedido de serviço), uma empresa e uma categorização 3 para esse ticket, o SLA define-se pelo conjunto de pares constituídos pelos tempos de resposta e tempos de resolução para os tickets que sejam registados por um utilizador daquela empresa e que sejam categorizados de acordo com a categorização dada. Um exemplo deste tipo de SLA s seria o conjunto de pares formados pelos tempos de resposta e pelos tempos de resolução para todos os tickets de incidente, categorizados como Hardware Servidor Servidor OutSystems, e que sejam registados por utilizadores da empresa A; e 2. Como um acordo celebrado entre o prestador de serviços (neste caso, a organização onde a aplicação está implementada) e um dos seus clientes, no qual o prestador de serviços se compromete a cumprir os níveis de serviço estabelecidos nesse acordo. Estes SLA s estabelecidos são do tipo de SLA s descritos no ponto anterior, isto é, conjuntos de pares tempo de resposta tempo de resolução. 3 Na aplicação desenvolvida, cada ticket é categorizado de acordo com uma hierarquia de 3 níveis. Um exemplo de categorização é Software Microsoft Office Word, em que Software corresponde ao nível 1, Microsoft Office ao nível 2 e Word ao nível 3. 70

91 De seguida, são detalhadas as três secções que compõem o módulo de SLM da solução implementada Níveis de serviço Nesta secção, são geridos os níveis de serviço estabelecidos com vista à resolução, quer de incidentes, quer de pedidos de serviço. Aqui, o conceito de SLA é tratado tal como está descrito no ponto 1 da secção anterior. Fig. 44 Ecrã principal da secção de gestão dos SLA s (níveis de serviço) A Figura 44 mostra o ecrã principal desta secção, o qual é composto por uma lista de todos os SLA s definidos para os tickets de incidente, por um conjunto de filtros que permitem filtrar a lista e por um botão que permite a criação de um novo SLA. Adicionalmente, a partir da lista, é possível, não só activar/desactivar um SLA através da checkbox respectiva, como também aceder aos seus detalhes, assim como aceder à respectiva matriz de níveis de serviço. Os SLA s são guardados na tabela SLA da base de dados, pelo que, para preencher a lista de SLA s, é efectuada uma query SQL a esta tabela, passando como parâmetros de pesquisa os valores seleccionados nas drop boxes de filtragem. 71