Faculdade de Ciências...Agradecimentos Em primeiro lugar, quero agradecer a todas as pessoas que,...

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

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

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.

À minha família.

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;

Service Asset & Configuration Management; Service Level Management.

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


Keywords: Service Desk Management; ITIL® v3; OutSystems Agile Platform; Service

Asset & Configuration Management; Service Level Management.

v

Conteúdo

Capítulo 1 Introdução............................................................................................ 1

1.1 Motivação ................................................................................................... 1

1.2 Objectivos ................................................................................................... 3

1.3 Contribuições .............................................................................................. 4

1.4 Enquadramento institucional ...................................................................... 5

1.5 Organização do projecto ............................................................................. 6

1.6 Estrutura do documento .............................................................................. 8

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

4.1 Benchmark de mercado ............................................................................ 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

Capítulo 8 Bibliografia........................................................................................ 84

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

Fig. 26 – Ecrã com a lista de campos adicionais ............................................................ 54

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

Fig. 50 – Ecrã de detalhes de um SLR ........................................................................... 78

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,

Fig. 1 – Organograma do projecto

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

implementados no contexto da solução desenvolvida.

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

documento.

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

Fig. 2 – Framework ITIL® v3

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.

Fig. 3 – Arquitectura da plataforma OutSystems

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.

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

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.

Fig. 5 – SCRUM Agile Methodology

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

Fig. 6 – Planeamento inicial das actividades do projecto

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:

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

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.

Fig. 8 – Modelo de acompanhamento do projecto

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

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

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

Management System preciso e completo.

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

Optimização da utilização dos activos e dos custos.

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

incidente como encerrado, através do envio de um inquérito de satisfação que 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 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.

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

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


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;

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

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.

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

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

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

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

processos analisados.

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.

41

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.

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

42

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

43

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.

5.2.2 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;

Fig. 16 – Diagrama de Casos de Uso simples do processo Service Level Management

44

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.

5.2.3 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

45

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.

Fig. 17 – Diagrama de arquitectura do Ambiente de Desenvolvimento

Ambiente de Desenvolvimento

Browser

Application

Servers

DB Server

Lenovo T400

Web Server

Application Server

DB Server

Máquina Lenovo T400

Sistema Operativo Windows XP Pro SP3

CPU

RAM

Disco

Software

Intel® Core™ 2 Duo P8600

2,40GHZ

3 GB

160 GB

SQL Server 2005

Caracteristicas Técnicas Application Server

Máquina Lenovo T400

Sistema Operativo Windows XP Pro SP3

RAM

Disco

3 GB

160 GB

Caracteristicas Técnicas DB Server

CPUIntel® Core™ 2 Duo P8600

2,40GHZ

46

Fig. 18 – Diagrama de arquitectura do Ambiente de Qualidade

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

Máquina HP proliant dl 380 g6

Sistema Operativo Windows 2008 r8

CPU

RAM

Disco

Software

Intel xeon E5506

6 GB

300GB

SQL Server 2005


Ambiente de Qualidade

Browser

Application

Servers

DB Server

Lenovo

Web Server

Application Server

DB Server



CPU

RAM

Disco

Intel xeon E5506

6 GB

3 x 150GB


Ambiente de Produção

Browser

Application

Servers

DB Server

Lenovo

Web Server

Application Server

DB Server



CPU

RAM

Disco

Software

Intel xeon E5506

6 GB

3 x 150GB

SQL Server 2005




CPU

RAM

Disco

Intel xeon E5506

6 GB

3 x 150GB


47

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

48

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.

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

49

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.

50

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.

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

51

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…”

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

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

52

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.

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…”

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

53

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

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

54

configuram campos adicionais, não sendo possível alterar os campos pré-definidos do

formulário.

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 dados1 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 27.

1 Existem 4 tipos de dados possíveis: Texto, Numérico, Data/Hora e DropBox.

Fig. 26 – Ecrã com a lista de campos adicionais

55

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.

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

56

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…”.

Isto faz com que surja uma janela de pop-up como aquela que mostra a Figura 29.

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

57

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.

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

58

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…”.

Isto faz com que surja uma janela de pop-up como aquela que mostra a Figura 31.

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

59

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.

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

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.

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

60

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.

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

Fig. 33 – Ecrã com as listas de activos

61

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.

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

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

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

62

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.

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.

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

63

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.

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 pop-

up como aquela que se pode observar na Figura 38.

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

64

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

65

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

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.

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

66

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

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

67

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

68

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é-adicionados2 (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.

69

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.

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.

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

70

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ção3 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.

71

De seguida, são detalhadas as três secções que compõem o módulo de SLM da solução

implementada.

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

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.

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

72

Para dar início ao processo de criação de um novo SLA, pressiona-se o botão criado

para o efeito, o qual faz aparecer a janela de pop-up exibida na Figura 45.

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

Esta janela é usada, tanto na criação, como na edição de um dado SLA. Após o

preenchimento dos campos indicados, procede-se à submissão desses dados, através de

um dos botões de gravação, e um novo SLA é registado na base de dados, caso ainda

não exista um com as mesmas características. Esta verificação permite que não haja

informação duplicada na base de dados. Caso já exista um SLA idêntico (ou seja, com

as mesmas características), é apresentada uma mensagem de erro ao utilizador

informando desta situação; caso contrário, o novo SLA é registado na base de dados e a

lista de SLA’s é novamente preenchida através da mesma query SQL usada no primeiro

preenchimento.

O próximo passo é a edição da matriz de níveis de serviço do SLA criado. Esta matriz

(ver Figura 46) é acedida através do botão correspondente ao SLA na lista de SLA’s.

73

Nesta matriz, são editados os pares tempo de resposta – tempo de resolução para todas

as combinações de impacto (o mesmo que o nível de perfil do utilizador4) e urgência

com que os tickets com as características do SLA são classificados.

Após a gravação dos tempos da matriz, o SLA fica pronto para ser usado no processo ao

qual o SLA está associado, desde que o mesmo esteja activo. Isto significa que, quando

um novo ticket com as características do SLA é registado, é verificado se o mesmo está

activo. Caso não esteja, o tempo de resposta para o ticket fica indefinido; caso contrário,

é o tempo de resposta definido na matriz, de acordo com o nível de perfil do utilizador

que o registou e com a urgência com que foi classificado.

O mesmo processo de verificação do SLA é realizado quando for necessário calcular o

tempo de resolução do mesmo ticket. Isto acontece quando o ticket for seleccionado por

um helpdesker para por si ser tratado.

4 Na aplicação, cada utilizador tem associado a si um nível de perfil, o qual pode variar de 1 a 5,

sendo o nível 5 o mais importante e o nível 1 o menos importante. Isto é útil na medida em que permite

mapear a hierarquia da organização e, assim, atribuir diferentes prioridades aos vários utilizadores.

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

74

6.2.2 Acordos e contratos

A segunda secção do módulo de Service Level Management foi implementada com o

objectivo de gerir os acordos e contratos que uma organização mantém com outras

entidades. Os tipos de contrato contemplados nesta secção são:

Service Level Requirement (SLR): É um acordo entre a organização e um dos

seus clientes, no qual se especificam os requisitos a cumprir para criação de um

novo serviço ou para a alteração de um serviço já existente;

Service Level Agreement (SLA): Tal como descrito no ponto 2 da secção 6.2

deste relatório, é um contrato celebrado entre a organização e um dos seus

clientes, no qual a organização se compromete a cumprir os níveis de serviço

estabelecidos;

Operational Level Agreement (OLA): É um acordo entre a organização e um dos

departamentos da mesma, no qual este último fica responsável por fornecer um

determinado conjunto de serviços ou bens, de acordo com as condicionantes

estabelecidas; e

Underpinning Contract (UC): É um contrato entre a organização e uma entidade

externa (prestador de serviços ou fornecedor), no qual esta fica com a

responsabilidade de fornecer bens ou serviços que apoiam a prestação de um

serviço de TI a um cliente da organização.

A secção “Acordos e contratos” é composta pelas listas dos vários tipos de contratos

que uma organização possui, cada uma com hiperligações para as páginas de detalhes de

cada um deles.

75

A título de exemplo, a Figura 47 ilustra a página com a lista de SLA’s celebrados.

Para além da lista de contratos, na qual a coluna da esquerda contém as hiperligações

para as respectivas páginas de detalhes, esta página apresenta a possibilidade de

filtrarmos a lista por cliente e/ou por estado do contrato. Os estados possíveis para um

contrato são:

Novo: Significa que a data actual é anterior à data de entrada em vigor do

contrato;

Em vigor: O contrato encontra-se actualmente em vigor;

Expirado: A data actual atingiu ou é posterior à data estipulada para a expiração

do contrato; e

Inactivo: O contrato foi desactivado pelo Service Level Manager.5

Esta página permite igualmente aceder às listas dos outros tipos de contratos, através de

hiperligações, bem como dar início ao processo de criação de um novo contrato. Este

processo é despoletado clicando no botão criado para o efeito, o qual faz abrir a página

destinada à criação de contratos (ver Figura 48).

5 Service Level Manager – papel ITIL® v3 desempenhado pela pessoa responsável pelo processo

de Service Level Management.

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

76

Neste ecrã, para além da inserção dos dados relativos ao acordo, há a possibilidade de

anexar o ficheiro com o contrato assinado pelas duas partes, de modo a que a gestão

fique mais completa. Enquanto os dados do novo acordo não forem submetidos, é

sempre possível alterar o tipo de acordo (SLA, OLA ou UC) que se quer registar. Para o

registo de um SLR, é usado um outro ecrã que será descrito mais à frente. Após a

validação e submissão dos dados, o novo acordo é registado na base de dados, sendo

criada a versão 1 do mesmo.

A Figura 49 mostra a página de detalhes de um acordo (neste caso, um SLA) já

existente.

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

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

77

Neste ecrã, sempre que se pressiona um dos dois botões de gravação dos dados, é criada

uma nova versão do acordo, sendo que são igualmente gravados registos (logs) de todas

as alterações efectuadas de uma versão para a outra, permitindo assim registar todas as

actualizações do ciclo de vida do acordo.

Em termos de layout, as diferenças do ecrã da Figura 49 para o da Figura 48 são a

adição de um separador “Histórico” e de um botão “Desactivar acordo…”.

No separador, é possível aceder a cada uma das outras versões do acordo, bem como

consultar os logs de todas as alterações efectuadas.

O botão dá o início ao processo de desactivação do acordo, fazendo, em primeiro lugar,

aparecer uma janela de pop-up que contém uma caixa de texto onde se devem inserir os

motivos pelos quais se vai desactivar o acordo. Após a submissão dos motivos, é gerada

uma nova versão do acordo, sendo o seu estado alterado para “Inactivo”.

Enquanto o estado do acordo for “Inactivo”, não é possível fazer qualquer alteração aos

dados já inseridos. Para voltar a reactivar o acordo, está disponível o botão “Reactivar

acordo”, o qual volta a colocar o acordo activo, actualizando o seu estado.

Por fim, a última funcionalidade da secção “Acordos e contratos” é facilitar a gestão dos

Service Level Requirements. Para isso, esta secção apresenta, à semelhança dos outros

tipos de acordo, uma página com a lista dos SLR’s registados, a qual contém

hiperligações para as páginas de detalhes de cada um deles.

A Figura 50 exibe a página de detalhes de um dos SLR.

78

Como referido anteriormente, um SLR é usado para especificar os requisitos a cumprir

para a criação de um novo serviço ou para a alteração de um serviço existente. Posto

isto, para além de campos de texto para o nome e para a descrição do SLR, este ecrã dá,

não só a possibilidade de se escolher que tipo de alteração se quer fazer, nomeadamente

através de uma caixa de texto para a inserção do nome do novo serviço a criar, ou

através de uma drop box para a escolha do serviço que se quer alterar, como também

disponibiliza uma caixa de texto para a inserção desses requisitos a cumprir.

De modo a complementar a gestão do SLR, é facultada a oportunidade de se anexar o

ficheiro com o acordo entre as duas partes.

Ao contrário dos outros tipos de acordos, a gravação dos dados do SLR não faz com que

seja gerada uma nova versão do mesmo. Esta opção foi tomada, pois considerou-se não

ser necessário registar o histórico de alterações do SLR.

Fig. 50 – Ecrã de detalhes de um SLR

79

6.3 Avaliação da solução

Com o objectivo de testar os módulos implementados, foram realizadas sessões de teste

com alguns utilizadores finais da aplicação.

Para isso, foram elaborados casos de teste para cada um dos módulos, de modo a

garantir que eram testadas todas as funcionalidades implementadas.

Ao longo das várias sessões, os utilizadores finais assinalaram algumas debilidades nas

funcionalidades implementadas e identificaram alguns pontos de melhoria, pelo que,

findas as sessões de teste, essas debilidades foram corrigidas e os pontos de melhoria

implementados.

De seguida, efectuaram-se novas sessões de teste com esses utilizadores, com o fim de

testar as correcções implementadas e proceder à aceitação da ferramenta. Aqui, foram

utilizados os mesmos casos de teste das sessões descritas anteriormente e, no final, os

utilizadores finais aprovaram as novas alterações, terminando assim o procedimento de

testes.

80

Capítulo 7

Conclusões e trabalho futuro

Este capítulo pretende analisar criticamente o trabalho desenvolvido neste projecto de

Estágio, apresentando também as possibilidades de trabalho futuro no contexto da

aplicação desenvolvida.

Com o trabalho desenvolvido, conclui-se que, de um modo geral, todos os objectivos

propostos foram cumpridos.

A integração na Maksen foi muito satisfatória, tendo-me sido proporcionado um

ambiente de trabalho bastante profissional, desde o primeiro dia.

Em relação ao projecto propriamente dito, as formações inicialmente realizadas, quer na

framework ITIL®, quer na plataforma OutSystems, foram essenciais para uma correcta

compreensão dos requisitos a implementar e para a ambientação às funcionalidades que

a plataforma de desenvolvimento oferece.

Os resultados obtidos com a elaboração do documento comparativo de ferramentas, no

âmbito do trabalho relacionado, espelham a pouca informação disponível para a

avaliação dessas ferramentas. Com base na experiência adquirida através da

visualização de outras ferramentas de SDM e com base nos estudos das prestigiadas

empresas Gartner e Forrester, acredita-se que esses resultados não representam o real

valor das ferramentas avaliadas. Este situar-se-ia, de acordo com a escala proposta (0 a

81

5), num intervalo entre os 4 e os 5 valores, o que significa que, no mínimo, é possível

monitorizar e medir o cumprimento dos requisitos. Embora haja automatização, os

mesmos não estão optimizados.

Seguidamente ao estudo de trabalho relacionado, procedeu-se à elaboração do

documento de análise de requisitos. Aqui, a grande complexidade residiu na

especificação do processo Release & Deployment Management, uma vez que as

ferramentas líderes não têm informação disponível e uma das versões trial analisadas

não implementa este processo. No entanto, com a realização de entrevistas aos

utilizadores finais da aplicação, esta dificuldade foi ultrapassada, uma vez que os

futuros utilizadores forneceram informações suficientes que permitiram o detalhe do

processo.

A elaboração do Modelo de Casos de Uso cumpriu todos os objectivos propostos para

esse documento, porém revelou-se uma tarefa complexa identificar correctamente os

actores envolvidos em cada caso de uso, devido à diferença que existe entre os

conceitos de “Papel do utilizador” e “Perfil de utilizador”.

Durante o processo de entrevistas, ficou decidido que se deveriam usar os papéis ITIL®

para cada um dos processos a implementar, de modo a definir as permissões que cada

utilizador final pode ter quando usar a aplicação. Ao serem definidos estes papéis,

poder-se-á então associá-los aos perfis de utilizador existentes na organização, e assim

completar o modelo de permissões da solução proposta. Esta solução permite que a

aplicação final tenha uma grande flexibilidade e uma grande adaptabilidade a este nível,

pois, qualquer que seja a organização, ou Clientes desta, em que esteja implementada, a

mesma só tem de associar os papéis ITIL®, que são imutáveis, aos seus próprios perfis

organizacionais, podendo sempre, e a qualquer altura, configurar os papéis associados a

cada perfil.

82

Posto isto, a complexidade esteve em distinguir claramente um papel de um perfil, na

medida em que, por exemplo, no caso de uso “Registar incidente” do processo Incident

management, primeiramente foram considerados que todos os actores envolvidos

estariam relacionados com o caso de uso, pois todas as pessoas da organização,

independentemente do(s) papel(is) associados ao seu perfil, devem poder registar um

incidente. Mas, numa segunda análise, e recorrendo à bibliografia de ITIL® v3, chegou-

se à conclusão que só faz sentido que os actores (e ao mesmo tempo papéis ITIL® v3)

User e 1st level support estejam relacionados com o caso de uso mencionado. O papel

de User corresponde àquele que tem as permissões mínimas sobre a aplicação, logo toda

e qualquer pessoa, independentemente dos papéis que lhe estão associados, tem essas

permissões mínimas, ou seja, todas as pessoas têm o papel de User associado, não

fazendo assim sentido que todos os actores estejam relacionados com o caso de uso.

Porém, o actor 1st level support ficou também associado ao caso de uso para representar

o facto de uma pessoa com este papel poder, para além de registar um pedido de serviço

em nome próprio (como User), poder também fazê-lo em nome de outra pessoa,

conforme um dos requisitos base disponibilizados.

Para o processo Service Level Mangement, não houve qualquer tipo de dificuldade a

este nível, pois apenas existe um actor envolvido neste processo: o Service Level

Manager.

No que diz respeito à implementação da solução de SDM, e particularmente aos dois

processos que são objecto deste relatório, o ponto mais crítico prende-se com a

utilização das duas tabelas auxiliares, AssetCacheIn e AssetCacheOut, para efectuar a

manutenção das listas de activos. Esta solução é um pouco ineficiente, na medida em

que são necessárias várias interacções com a base de dados, o que torna a

navegabilidade da aplicação mais lenta. Uma solução para mitigar este problema passa

por usar, em vez das duas tabelas, duas variáveis de sessão do tipo estrutura (Structure)

que tenham os mesmos atributos daquelas tabelas. Isto faz com que o desempenho da

plataforma seja melhorado substancialmente, pois são evitadas as interacções com a

83

base de dados, sendo o processamento feito do lado do cliente, para além de evitar

também acessos concorrentes à mesma tabela física.

Por fim, o trabalho futuro, no âmbito da aplicação implementada, passa por desenvolver

secções de monitorização para cada um dos módulos, à excepção do módulo de SACM.

Cada uma destas secções tem o objectivo de proporcionar a produção de relatórios de

desempenho para o módulo respectivo, em forma de tabelas e/ou gráficos. Poderão ser

feitas também algumas simplificações ao código da aplicação, sendo que uma delas

seria, no seguimento do parágrafo anterior, implementar a solução descrita para fazer a

manutenção das listas de activos.

84

Capítulo 8

Bibliografia

1. Rudd, Colin. Introduction. [ed.] Alison Cartlidge. An Introductory Overview of

ITIL®. Reading : itSMF Ltd, 2004, 1.

2. Maksen. Maksen. [Online] Maksen. [Citação: 10 de Julho de 2011.]

http://www.maksen.com/.

3. Hanna, Ashley e Rance, Stuart. ITIL® v3 Glossary of Terms, Definitions and

Acronyms. 2007. Best Management Practice™.

4. SkillSoft. SkillPort® - SkillSoft. E-Learning for Business Skills & IT Certification -

SkillSoft. [Online] SkillSoft, 2010.

http://www.skillsoft.com/products/skillport/default.asp.

5. OutSystems. Agile Network Academy. OutSystems Agile Network. [Online]

OutSystems. https://secure.outsystems.com/Training/.

6. Cartlidge, Alison, et al. Service Transition. [ed.] Alison Cartlidge e Mark Lillycrop.

An Introductory Overview of ITIL® v3. s.l. : The UK Chapter of the itSMF, 2007, 6.

7. OGC - Office of Government Commerce. ITIL Version 3 - Service Design.

8. Cartlidge, Alison, et al. Service Operation. [ed.] Alison Cartlidge e Mark Lillycrop.

An Introductory Overview of ITIL® v3. s.l. : The UK Chapter of the itSMF, 2007, 7.

9. Gartner, Inc. About Gartner. Gartner Web Site. [Online] [Citação: 17 de Outubro de

2010.] http://www.gartner.com/technology/about.jsp.

10. Forrester Research, Inc. Forrester Research. Forrester Research Web site.

[Online] [Citação: 17 de Outubro de 2010.]

85

http://www.forrester.com/FactSheet?cm_re=Navigation_010710-_-about_forrester_tab-

_-about_forrester.

11. Forrester Research, Inc.. "The Forrester Wave: Service Desk Management Tools".

2008.

12. Gartner, Inc.. "Gartner Magic Quadrant: ITSM ". 2008.

13. MDECA. Using the CA Unicenter Service Desk. 2010.

14. CA. Unicenter Service Desk ITIL User Guide r11.2. 2005.

15. Lassiter, William e Beal, Ashley. CA Unicenter Service Desk Training Instruction

Manual. 2009.

Faculdade de Ciências...Agradecimentos Em primeiro lugar, quero agradecer a todas as pessoas que,...

Documents

Transcript of Faculdade de Ciências...Agradecimentos Em primeiro lugar, quero agradecer a todas as pessoas que,...