Análise e desenvolvimento de solução de Service Desk Management - ITIL®V3: Service Asset & Configuration Management e Service Level Management

U

NIVERSIDADE DE

L

ISBOA

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

U

NIVERSIDADE DE

L

ISBOA

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

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.

i

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;

iii

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

v

Conteúdo

Capítulo 2 Metodologias e planeamento ... 10

2.1 Framework ITIL® v3 ... 10

2.2 OutSystems Agile Platform ... 13

2.2.1 Metodologia ... 13

2.2.2 Estrutura da plataforma ... 14

2.2.3 Hub Server... 16

2.3 Metodologia de desenvolvimento ... 18

2.4 Planeamento ... 19

2.5 Gestão de Projecto e Controlo de Qualidade ... 21

2.6 Formações ... 23

Capítulo 3 Processos implementados ... 24

3.1 Service Asset & Configuration Management ... 25

3.2 Service Level Management ... 27

3.3 Outros processos ... 28

3.3.1 Incident Management ... 28

3.3.2 Problem Management ... 29

3.3.3 Change Management... 29

3.3.4 Release & Deployment Management ... 30

Capítulo 4 Trabalho relacionado ... 31

vi

4.2 Processos analisados ... 33

4.3 Método de avaliação ... 34

4.4 Resultados ... 35

Capítulo 5 Análise do problema e desenho da solução ... 39

5.1 Definição de requisitos ... 39

5.2 Desenho do modelo conceptual ... 41

5.2.1 Modelo de Casos de Uso ... 41

5.2.2 Modelo de Domínio ... 43

5.2.3 Modelo de Desenho ... 44

Capítulo 6 Implementação da solução ... 49

6.1 Service Asset & Configuration Management ... 49

6.1.1 Secção no painel de administração... 50

6.1.2 Gestão de activos ... 59

6.1.3 Gestão de inventários ... 65

6.2 Service Level Management ... 70

6.2.1 Níveis de serviço ... 71

6.2.2 Acordos e contratos ... 74

6.3 Avaliação da solução ... 79

Capítulo 7 Conclusões e trabalho futuro ... 80

viii

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.

x

Lista de Figuras

Fig. 1 – Organograma do projecto ... 7

Fig. 2 – Framework ITIL® v3 ... 11

Fig. 3 – Arquitectura da plataforma OutSystems ... 15

Fig. 4 – Detalhe da arquitectura da plataforma OutSystems, destacando o processo 1-Click-Publishing ... 17

Fig. 5 – SCRUM Agile Methodology ... 18

Fig. 6 – Planeamento inicial das actividades do projecto ... 19

Fig. 7 – Planeamento das actividades do projecto nos 4 meses finais ... 21

Fig. 8 – Modelo de acompanhamento do projecto ... 22

Fig. 9 – Processos ITIL® v3 implementados e respectivo mapeamento ... 24

Fig. 10 – Estudos de 2008 da Forrester [11] e da Gartner [12] ... 32

Fig. 11 – Modelo de avaliação de ferramentas concorrentes ... 34

Fig. 12 – Resultado da avaliação das soluções por dimensão ... 36

Fig. 13 – Resultado da avaliação dos requisitos funcionais ... 37

Fig. 14 – Resultado da avaliação dos requisitos de integração ... 37

Fig. 15 – Diagrama de Casos de Uso simples do processo Service Asset & Configuration Management ... 42

Fig. 16 – Diagrama de Casos de Uso simples do processo Service Level Management 43 Fig. 17 – Diagrama de arquitectura do Ambiente de Desenvolvimento ... 45

Fig. 18 – Diagrama de arquitectura do Ambiente de Qualidade ... 46

Fig. 19 – Diagrama de arquitectura do Ambiente de Produção... 46

Fig. 20 – DFD de nível 0 do processo Service Asset & Configuration Management .... 47

Fig. 21 – DFD de nível 0 do processo Service Level Management ... 48

Fig. 22 – Ecrã com a lista de tipos de componentes ... 51

Fig. 23 – Janela de pop-up para a criação/edição de um tipo de componente... 51

Fig. 24 – Ecrã com a lista de modelos de activos ... 52

Fig. 25 – Janela de pop-up para a criação/edição de um modelo de activos ... 53

xi

Fig. 27 – Ecrã de criação/edição de um campo adicional ... 55

Fig. 28 – Ecrã com a lista de estados dos activos ... 56

Fig. 29 – Janela de pop-up para a criação/edição de um estado de activo ... 57

Fig. 30 – Ecrã com a lista de sub-atribuições ... 58

Fig. 31 – Janela de pop-up para a criação/edição de uma sub-atribuição ... 58

Fig. 32 – Ecrã com a lista de activos afectos a um utilizador ... 59

Fig. 33 – Ecrã com as listas de activos ... 60

Fig. 34 – Ecrã de escolha do modo de registo de um novo activo ... 61

Fig. 35 – Ecrã de registo de um novo activo ... 61

Fig. 36 – Página de detalhes de um activo ... 62

Fig. 37 – Separador “Relações” da página de detalhes de um activo ... 63

Fig. 38 – Janela de pop-up para edição das relações pai-filho de um activo... 63

Fig. 39 – Separador “Histórico” da página de detalhes de um activo ... 64

Fig. 40 – Ecrã com a lista de inventários ... 65

Fig. 41 – Página de detalhes de um inventário ... 66

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

Fig. 43 – Janela de pop-up para a escolha dos activos do inventário ... 69

Fig. 44 – Ecrã principal da secção de gestão dos SLA’s (níveis de serviço) ... 71

Fig. 45 – Janela de pop-up para criação/edição de SLA ... 72

Fig. 46 – Matriz de níveis de serviço de um SLA ... 73

Fig. 47 – Página com a lista de Service Level Agreements ... 75

Fig. 48 – Ecrã de criação de um novo acordo/contrato ... 76

Fig. 49 – Ecrã de edição de um acordo/contrato ... 76

1

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 inter-relacionadas 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

2

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, tornou-se 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]

3

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

4

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.

5

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, especializando-se 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.

6

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.

7

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,

8

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

9

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

10

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

11

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]

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

12

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.

13 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.

2.2.1 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

14

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-to-change, 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.

2.2.2 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.

15

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.

16

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.

2.2.3 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.

17

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.

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.

18

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.

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.

19

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.

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

20

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.

21

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).

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:

22

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.

23

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].

24

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.

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

25

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 infra-estrutura 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

26

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

27

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

28

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.

3.3.1 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

29

utilizador deverá preencher com o seu feedback e posteriormente submeter para o

Service Desk.

3.3.2 Problem Management

Neste processo, também ele descrito no módulo Service Operation [8], a atenção centra-se em minimizar o impacto de incidentes que não podem centra-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.

3.3.3 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.

30

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.

3.3.4 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.

31

Capítulo 4

Trabalho relacionado

Uma vez identificados os processos a desenvolver no âmbito deste projecto, procedeu-se à 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.

32

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.

33

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.

34

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:

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;

35

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.

36

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.

37

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. 13 – Resultado da avaliação dos requisitos funcionais

38

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

39

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.

40 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.