suporte de serviÇos, segundo itil: uma ferramenta baseada em software livre

FÁBIO ROCHA

SUPORTE DE SERVIÇOS, SEGUNDO ITIL:

UMA FERRAMENTA BASEADA EM

SOFTWARE LIVRE

FÁBIO ROCHA

SUPORTE DE SERVIÇOS, SEGUNDO ITIL: UMA FERRAMENTA BASEADA EM

SOFTWARE LIVRE

Trabalho de conclusão de curso apresentado à Universidade do Vale do Rio dos Sinos – UNISINOS, como requisito parcial para a obtenção do título de Bacharel em Sistemas de Informação.

Orientador: Prof. Ms. Cristiano Tonietto Galina

São Leopoldo

2009

AGRADECIMENTOS

Agradeço primeiramente aos meus pais, Elizabetha Rocha e Ito Rocha, por terem me

proporcionado até o momento toda a dedicação para com os meus estudos e ainda todo o

carinho dado nos momentos mais difíceis.

Pela minha madrinha, Teresa Gregory, por ter custeado e dado apoio aos meus estudos

nesta faculdade.

Pela minha esposa, Elisandra, por me ajudar neste trabalho e entender a minha

dedicação a essa última etapa da graduação. Agradeço aos meus segundos pais, Antônio e

Selma Pacheco, que me deram força nos meus estudos.

Ao meu orientador e mestre, Cristiano Tonietto Galina, pela atenção, dedicação e

paciência durante a elaboração desse trabalho.

Aos meus colegas Carla, Dani e Manu que estiveram comigo durante a graduação

(principalmente aos sábados).

Aos meus amigos, Alê, Duda e Adri que sempre estiveram ao meu lado.

E às demais pessoas, não menos importantes, que de alguma forma contribuíram para

que este trabalho fosse concebido.

“O insucesso é apenas uma oportunidade para começar de novo com mais inteligência.”

Henry Ford

RESUMO

Este trabalho tem como objetivo propor um método de avaliação de software baseado

nos conceitos da ITIL 2º versão referente ao livro Suporte de Serviços. Para isso, foi realizada

uma pesquisa bibliográfica, onde os processos Gerenciamento de Incidente, Gerenciamento

de Problema, Gerenciamento de Mudança, Gerenciamento de Liberação, Gerenciamento da

Configuração e a função Central de Serviços foram detalhados e essas informações

compuseram o método de avaliação dessa pesquisa.

A aplicação do método ocorreu em três softwares livres que tratam sobre

gerenciamento da tecnologia da informação. Os resultados permitiram a identificação da

melhor ferramenta e também a identificação dos processos que não são bem atendidos pela

ferramenta selecionada. Esses processos foram analisados e sugeridas melhorias.

Palavras-Chave: ITIL, Suporte de Serviços, Software Livre.

ABSTRACT

This paper has as objective to propose a method of software evaluation based on the

concepts of ITIL 2nd version regarding the book Support of Services. For that, a

bibliographical research was accomplished, where the processes Incident Management,

Problem Management, Change Management, Release Management, Configuration

Management and the function Service Desk were detailed and that information composed the

method of evaluation of that research.

The application of the method happened in three free softwares that they treat on

information technology management. The results allowed the identification of the best tool

and also the identification of the processes that they are not well assisted by the selected tool.

Those processes were analyzed and suggested improvements.

Key-Words: ITIL, Service Support, Free Software.

LISTA DE FIGURAS

Figura 01: Metodologia proposta (Autor). ............................................................. 16

Figura 02: ITIL versão 2.0 (MAGALHÃES, 2007, p. 64)..................................... 19

Figura 03: ITIL versão 3.0 (ITSMF, 2009). ........................................................... 20

Figura 04: Relacionamento entre os processos da ITIL (Modificado)

(MAGALHÃES, 2007, p. 67). ................................................................................ 22

Figura 05: Exemplo de processo de Gerenciamento de Incidente (MAGALHÃES,

2007, p.137). ............................................................................................................ 26

Figura 06: Priorização de atendimento do incidente (MAGALHÃES, 2007, p. 141).

................................................................................................................................. 27

Figura 07: Entradas, atividades e saídas do Gerenciamento de Problema (Autor).

................................................................................................................................. 29

Figura 08: Controle de problemas (OGC, 2000, p. 101). ....................................... 30

Figura 09: Identificação e registro dos problemas (OGC, 2000, p. 102). .............. 31

Figura 10: Controle de erros (OGC, 2000, p. 106). ............................................... 33

Figura 11: Entradas, atividades e saídas do Gerenciamento de Mudança (Autor). 39

Figura 12a: Procedimentos básicos do Gerenciamento de Mudança - Parte 01

(OGC, 2000, p. 171). ............................................................................................... 40

Figura 12b: Procedimentos básicos do Gerenciamento de Mudança - Parte 02

(OGC, 2000, p. 172). ............................................................................................... 41

Figura 13: Modelo padrão de uma mudança (OGC, 2000, p. 173). ....................... 42

Figura 14a: Procedimentos para mudanças urgentes – Parte 01 (OGC, 2000, p.

188). ......................................................................................................................... 46

Figura 14b: Procedimentos para mudanças urgentes - Parte 02 (OGC, 2000, p.

188). ......................................................................................................................... 47

Figura 15: Relacionamento entre DSL e o CMDB (OGC, 2000, p. 206). ............. 50

Figura 16: Exemplo de estrutura de configuração (OGC, 2000, p. 137). .............. 62

Figura 17: Exemplo do ciclo de vida de um CI (OGC, 2000, p. 139). .................. 64

Figura 18: Relacionamento do CMDB com o Gerenciamento de Incidente,

Problema, Mudança e Liberação (OGC, 2000, p. 151). .......................................... 67

Figura 19: Relacionamento entre o Gerenciamento da Configuração e o

Gerenciamento de Mudança e Liberação (OGC, 2000, p. 151). ............................. 68

7

Figura 20a: Diagrama de caso de uso representando o processo Gerenciamento de

Liberação – Parte 1(Autor). ..................................................................................... 85

Figura 20b: Diagrama de caso de uso representando o processo Gerenciamento de

Liberação – Parte 2(Autor). ..................................................................................... 86

Figura 21: Diagrama de atividade do caso de uso UC01 – Planejar Liberação

(Autor). .................................................................................................................... 88

Figura 22: Diagrama de atividade do caso de uso UC02 – Documentar Plano de

Retorno (Autor). ...................................................................................................... 89

Figura 23: Diagrama de atividade do caso de uso UC03 – Desenvolver Boletim

Técnico (Autor). ...................................................................................................... 90

Figura 24: Diagrama de atividade do caso de uso UC04 – Desenvolver Treinamento

(Autor). .................................................................................................................... 91

Figura 25: Diagrama de atividade do caso de uso UC05 – Definir Pacote de

Liberação (Autor). ................................................................................................... 92

Figura 26: Diagrama de atividade do caso de uso UC06 – Consultar CI (Autor).. 93

Figura 27: Diagrama de atividade do caso de uso UC07 – Salvar no CMDB

(Autor). .................................................................................................................... 94

Figura 28: Diagrama de atividade do caso de uso UC08 – Avaliar Liberação

(Autor). .................................................................................................................... 95

Figura 29: Diagrama de atividade do caso de uso UC09 – Aprovar Liberação

(Autor). .................................................................................................................... 96

Figura 30: Diagrama de atividade do caso de uso UC10 – Rejeitar Liberação

(Autor). .................................................................................................................... 96

Figura 31: Diagrama de atividade do caso de uso UC11 – Implementar Liberação

(Autor). .................................................................................................................... 97

Figura 32: Diagrama de atividade do caso de uso UC12 – Auditar Implementação

(Autor). .................................................................................................................... 98

Figura 33: Diagrama de caso de uso representando o processo Gerenciamento da

Configuração (Autor). ............................................................................................. 99

Figura 34: Diagrama de atividade do caso de uso UC13 – Planejar Abrangência

(Autor).....................................................................................................................101

Figura 35: Diagrama de atividade do caso de uso UC14 – Registrar CI (Autor)...102

Figura 36: Diagrama de atividade do caso de uso UC15 – Definir Relacionamento

entre CIs (Autor)......................................................................................................103

8

Figura 37: Diagrama de atividade do caso de uso UC16 – Identificar

Automaticamente (Autor).......................................................................................104

Figura 38: Diagrama de atividade do caso de uso UC17 – Auditar CI (Autor)....105

Figura 39: Diagrama de atividade do caso de uso UC18 – Visualizar

Relacionamentos (Autor)........................................................................................106

LISTA DE QUADROS

Quadro 01: Proposta de indicador de desempenho (MAGALHÃES, 2007, p. 130).

................................................................................................................................. 24

Quadro 02: Exemplo de análise de impacto (MAGALHÃES, 2007, p. 140). ........ 27

Quadro 03: Exemplo de análise de urgência (MAGALHÃES, 2007, p. 141). ....... 27


................................................................................................................................. 28


................................................................................................................................. 36


................................................................................................................................. 48

Quadro 07: Matriz de responsabilidade (OGC, 2000, p. 215). ................................ 54


................................................................................................................................. 57

Quadro 09: Sugestão de atributos (OGC, 2000, p. 163). ......................................... 63


................................................................................................................................. 70

Quadro 11: Categoria x número de questões (Autor). ............................................. 73

Quadro 12: Lista de avaliação dos softwares (Autor). ............................................ 80

Quadro 13: Resultados obtidos com a aplicação do método (Autor). ..................... 83

LISTA DE ABREVIATURAS

BD – Banco de Dados

BSD – Berkeley Software Distribution

CAB – Change Advisory Board

CAB/EC – Change Advisory Board/Emergency Committee

CCTA – Central Communications and Telecom Agency

CI – Configuration Items

CIO – Chief Information Officer

CMDB – Configuration Management Database

COBIT - Control Objectives for Information and Related

Technology

CSS – Cascading Style Sheets

DHS – Definitive Hardware Store

DSL – Definitive Software Library

EXIN – Examination Institute for Information Science

GB – Gigabyte

GHz – Giga hertz

GITIMM – Government Information Technology

Infrastructure Management Method

GPL – General Public License

HTML – HyperText Markup Language

ISEB – Information System Executive Board

ITIL – Information Technology Infrastructure Library

itSMF – Information Technology Management Forum

MIT – Massachusetts Institute of Technology

11

OGC – Office of Government Commerce

OTRS – Open Ticket Request System

PC – Personal Computer

PHP – Hypertext Preprocessor

RAM – Random Access Memory

RFC – Request for Change

SLA – Service License Agreement

SPOC – Single Point of Contact

TI – Tecnologia da Informação

SUMÁRIO

1 INTRODUÇÃO .................................................................................................. 13 1.1 OBJETIVOS ...................................................................................................... 14 1.1.1 Objetivo Geral .............................................................................................. 14 1.1.2 Objetivos Específicos .................................................................................... 14 1.2 MÉTODO DE PESQUISA ................................................................................ 15

2 REFERENCIAL TEÓRICO ............................................................................. 17

2.1 ITIL: O CONCEITO ......................................................................................... 17 2.1.1 O framework .................................................................................................. 19

2.1.2 O núcleo da ITIL versão 2 ........................................................................... 21 2.2 ITIL: SUPORTE DE SERVIÇOS ..................................................................... 23

2.2.1 Central de Serviços (Service Desk) .............................................................. 23 2.2.2 Gerenciamento de Incidente (Incident Management) ................................ 25

2.2.3 Gerenciamento de Problema (Problem Management) ............................... 28

2.2.4 Gerenciamento de Mudança (Change Management) ................................ 36

2.2.5 Gerenciamento de Liberação (Release Management)................................ 48

2.2.6 Gerenciamento da Configuração (Configuration Management) .............. 57 2.3 SOFTWARE LIVRE .......................................................................................... 70

2.3.1 Histórico ........................................................................................................ 71 2.3.2 Grau de restrições de licenças ..................................................................... 71 2.3.3 Licenças de software livre ............................................................................ 71

3 O ESTUDO DE CASO PROPOSTO ................................................................ 73

3.1 METODOLOGIA .............................................................................................. 73 3.2 FERRAMENTAS SELECIONADAS ............................................................... 80

3.2.1 OcoMon .......................................................................................................... 80 3.2.2 Spiceworks ..................................................................................................... 81

3.2.3 OTRS .............................................................................................................. 82 3.3 ANÁLISE DAS FERRAMENTAS ................................................................... 83

4 PROPOSTA DE IMPLEMENTAÇÃO ............................................................ 84

4.1 GERENCIAMENTO DE LIBERAÇÃO .......................................................... 84

4.1.1 Detalhamento dos casos de uso .................................................................... 86

4.2 GERENCIAMENTO DA CONFIGURAÇÃO ................................................. 99

4.2.1 Detalhamento dos casos de uso .................................................................... 100

5 CONCLUSÃO ..................................................................................................... 107 5.1 CONSIDERAÇÕES FINAIS ............................................................................ 107

5.2 TRABALHOS FUTUROS ................................................................................ 110

REFERÊNCIAS BILIOGRÁFICAS ................................................................... 111

ANEXO A – DOCUMENTAÇÃO DOS CASOS DE USO ................................ 114

13

1 INTRODUÇÃO

A Governança de TI (Tecnologia da Informação) saiu do status de desejável e passou a

estar na situação de essencial para os gestores das empresas. Desta forma, a Governança de TI

está diretamente relacionada com o objetivo de obter melhorias no desempenho da tecnologia

no âmbito corporativo, envolvendo a adoção de uma série de recursos para influenciar e

direcionar as atividades de TI (STREIT, 2004).

Dentre os recursos para a aplicação da governança de TI, destacam-se no sumário

executivo, os frameworks: ITIL (Information Technology Infrastructure Library) e COBIT

(Control Objectives for Information and Related Technology) (TERZIAN, 2004).

Dentre essas armas à disposição dos CIOs (Chief Information Officer), a ITIL destaca-

se por ser uma compilação de autoajuda em tecnologia da informação. Em linhas gerais ela

reúne as melhores práticas já adotadas em diversas empresas do mundo (BARELLA, 2009).

A ITIL pode ser traduzida como uma biblioteca da infraestrutura da tecnologia da

informação. Essa metodologia surgiu nos anos 80 da necessidade de se ter processos

organizados e claros. Percebeu-se que as organizações estão cada vez mais dependentes da

área de TI e que desta forma, torna-se necessário organizar este departamento (PINK, 2001).

A metodologia ITIL, na segunda versão, é composta inicialmente por sete livros, onde

os principais processos e recomendações sobre as melhores práticas de TI estão descritos.

Dentre esses livros o suporte a serviços é um dos principais livros, pois possui um ponto de

vista de nível operacional dos processos de um departamento de TI (MAGALHÃES, 2007). O

livro o “Suporte a Serviço” (Service Support) é composto dos seguintes processos (OGC,

2009):

� Gerenciamento de Incidentes (Incident Management);

� Gerenciamento de Problemas (Problem Management);

� Gerenciamento de Mudanças (Change Management);

� Gerenciamento de Liberação (Release Management);

� Gerenciamento da Configuração (Configuration Management).

A versão 3 da ITIL foi lançada em 2007 e o seu foco é voltado a serviços, sendo que a

versão 2 da ITIL é voltada a processos (EXIN, 2009).

14

Devido ao fato da infraestrutura de TI estar cada vez maior e mais complexa a

utilização de um software faz-se necessário. O software livre pode ser uma alternativa a essa

necessidade, e dessa forma, qualquer empresa poderá utilizá-lo devido ao conceito do

software livre, que é definido como um software que pode ser utilizado, copiado e alterado

sem a necessidade de pagar pelo produto (HEXSEL, 2003).

Dessa forma, este trabalho tem o propósito de identificar um software livre, baseado

num método de avaliação, que esteja de acordo com os conceitos da ITIL segunda versão

referente ao livro Suporte de Serviços.

1.1 OBJETIVOS

1.1.1 Objetivo Geral

O objetivo geral deste trabalho é definir um método de avaliação de software,

adaptável ao software livre, que atenda aos conceitos da ITIL versão 2 referente ao livro

Suporte a Serviços.

1.1.2 Objetivos Específicos

Para corroborar com o objetivo geral deste trabalho foi definido os seguintes objetivos

específicos:

� Propor um método de avaliação de software destinado a identificar uma ferramenta

de acordo com os conceitos da ITIL 2º versão referente ao livro Suporte a Serviços;

� Aplicar o método em três softwares livres;

� Identificar um Software livre que mais se adere a ITIL segundo o método.

15

1.2 MÉTODO DE PESQUISA

Este trabalho se caracteriza como estudo de caso, porque o mesmo deve responder

uma questão de estudo do tipo: como? e/ou por quê? (YIN, 2001). Sendo assim a pesquisa

trata de como foi desenvolvido o método de avaliação. Outra característica é o fato desse

método ser um tipo de pesquisa empírica que possibilita estudar profundamente uma situação

atual em seu contexto real, sem que o pesquisador interfira de modo significativo no objeto

em estudo (PALVIA, 2003).

Quanto aos objetivos da pesquisa, estes são classificados como exploratório, pois, tem

como objetivo proporcionar maior intimidade com o problema, com vistas a torná-lo mais

explícito. O levantamento bibliográfico envolve ainda entrevistas com pessoas experientes no

problema pesquisado. O estudo dessa pesquisa é qualitativa, pois as principais características

dos métodos qualitativos são a imersão do pesquisador no contexto e a perspectiva

interpretativa de condução da pesquisa (KAPLAN, 1988), o que atende a necessidade do

trabalho proposto.

Para a coleta de dados, a forma escolhida foi uma entrevista com pessoas inseridas

dentro do contexto do tema investigado. Esses entrevistados forneceram percepções e

interpretações sobre o assunto, assim como fontes para a busca de evidências.

Após a conclusão da pesquisa bibliográfica, os dados por ela gerados foram

reagrupados em categorias que se relacionam entre si de forma a ressaltar padrões, temas e

conceitos (BRADLEY, 1993). Depois de categorizados, foi possível fazer uma melhor

interpretação, tarefa que envolve a atribuição de significado à análise, explicando os padrões

encontrados e procurando por relacionamentos entre as dimensões descritivas (PATTON,

1980).

A metodologia adotada para a condução deste trabalho trata de coletar as informações

bibliográficas que serão utilizadas durante todo o andamento dessa pesquisa, bem como, a

seleção das ferramentas baseadas em uma entrevista, a elaboração de uma lista de validações,

a avaliação das mesmas, o projeto de melhoria ao aplicativo escolhido e o desenvolvimento da

conclusão desse trabalho.

16

Para demonstrar, de forma gráfica, como foi abordado a metodologia nesta

monografia, a Figura 01 demonstra essa proposta.

Figura 01: Metodologia proposta (Autor).

Suporte de serviços, segundo ITIL: Uma ferramenta baseada em software

livre

Avaliar as ferramentas através do checklist.

Projetar às melhorias a ferramenta selecionada

Entregar a monografia

Selecionar as ferramentas através das entrevistas

Elaborar a lista de validação (checklist).

ITIL

- I

nfo

rma

tion

Te

chn

olo

gy

Infr

ast

ruct

ure

Lib

rary

So

ftw

are

Liv

re

Ref

eren

cial

teó

rico

17

2 REFERENCIAL TEÓRICO

O objetivo deste capítulo é esclarecer conceitos necessários sobre o livro Suporte de

Serviços (ITIL versão 2) e sobre o Software livre.

Este capítulo está estruturado em sub-capítulos. No primeiro, são expostos os

conceitos do livro Suporte de Serviços e no segundo é descrito o conceito de Software livre e

seus tipos de licenças.

2.1 ITIL: O CONCEITO

Para gerenciar os serviços de TI (Tecnologia da Informação), em um mundo que está

cada vez mais competitivo e onde as mudanças são constantes e inesperadas, é necessário ter

flexibilidade e agilidade para reagir às falhas e imprevistos mais rapidamente, assim como

estar preparado para antevê-los. Soma-se a isso a necessidade das organizações que precisam

contar com a competência e velocidade da área de TI (MAGALHÃES, 2007).

As melhores práticas oferecidas pela ITIL (Information Technology Infrastructure

Library) fornecem uma alternativa para o gerenciamento de serviços de TI, pois

proporcionam uma metodologia focada nos processos. A ITIL orienta a área de TI com base

nas melhores práticas, visando sempre à melhoria contínua para ter um ambiente de qualidade

(MAGALHÃES, 2007).

A utilização da ITIL pode ser aplicada a diversas metodologias de controle

independente da tecnologia ou do tamanho da organização, isso porque ela objetiva

(MAGALHÃES, 2007):

� Alinhamento da área de TI com as necessidades do negócio;

� Melhoria no relacionamento entre cliente e fornecedor;

� Estabelece procedimentos inter-relacionados que se suportam uns aos outros;

� Orientações para tornar a área de TI mais profissional;

� Fornecimento dos resultados esperados com o mínimo de riscos e falhas.

18

Observando os processos centrais da ITIL percebe-se que é similar a forma como

todas as empresas trabalham (PINKROCCADE, 2009). Uma pesquisa feita pela International

Network Services constatou, após entrevistar 194 empresas pelo mundo, que, das práticas de

gerenciamento de serviços de TI analisadas, 38% dessas empresas utilizam ITIL, perdendo

somente para as empresas que adotaram um modelo próprio (MAGALHÃES, 2007).

A ITIL não fornece mapas detalhados para a resolução dos processos. Ela fornece

conceitos para o desenvolvimento dos processos de TI. Ao adotar a ITIL, alguns benefícios

são obtidos e dentre esses se destacam (NUNES, 2007):

� Gestão dos serviços com maior qualidade, disponibilidade e confiabilidade;

� Melhor controle dos processos com menor incidência de problemas;

� Melhoria na comunicação com a equipe de TI, devido a definição dos pontos de

contato;

� A TI passa a ser vista como uma geradora de valor ao invés de um centro de custos

e/ou suporte;

� Os serviços de TI passam a atender às necessidades reais do negócio.

Atualmente a ITIL encontra-se amplamente consagrada, mas ela foi desenvolvida no

final da década de 1980 pela CCTA (Central Communications and Telecom Agency) do

governo britânico, sendo que foi originalmente conhecido como GITIMM (Government

Information Technology Infrastructure Management Method) (PINK, 2001). As melhores

práticas utilizadas pelos segmentos público, privado e empresas de consultoria foram

unificadas e denominadas como ITIL em 1989. Atualmente a OGC (Office of Government

Commerce) é quem detém os direitos sobre o material publicado sobre a ITIL (ITSMF, 2009).

Em parceria com a OGC está a itSMF (Information Technology Management Forum)

que é uma entidade que realiza debates, publicações e resoluções sobre a ITIL. A itSMF

possui comitês em cerca de 42 países, sendo que no Brasil sua sede foi inaugurada em 2004

(ITSMF, 2009).

A EXIN (Examination Institute for Information Science) e a ISEB (Information

System Executive Board), também associadas à OGC/itSMF, promovem provas de

certificação de profissionais na área de TI (ITSMF, 2009).

19

2.1.1 O framework

Para a Engenharia de Software o framework é um esqueleto que regula a forma de

como um conceito deve ser aplicado (DEUTSCH, 1989). É uma estrutura semipronta que

representa um alto nível de reutilização (CUNHA 2003). O framework pode ser encarado

como uma assinatura de qualidade que proporciona a implementação de técnicas já testadas e

essas permitem a sua expansão de sua aplicação (LARMAN, 1998).

A primeira versão da ITIL era composta por aproximadamente 40 livros que tratavam

sobre assuntos relacionados ao gerenciamento de serviços em TI, daí o fato de ser considerada

uma biblioteca (PINHEIRO, 2006). Entre os anos de 2000 e 2002, a ITIL foi reformulada e

revisada passando a ser conhecida como a segunda versão da ITIL (Figura 02).

Figura 02: ITIL versão 2.0 (MAGALHÃES, 2007, p. 64).

Nesta versão ela passou a ser composta por oito volumes, sendo eles (ITSMF, 2001,

p.31):

� Suporte a Serviços (Service Support);

� Entrega de Serviços (Service Delivery);

� Planejamento para Implementação de Gerenciamento de Serviços (Planning to

Implement Service Management);

� Gerenciamento de Aplicações (Application Management );

� Gerenciamento de Segurança (Security Management);

20

� Gerenciamento de Infra-estrutura de TI e de Comunicações (Information and

Communication Technology Infrastructure Management);

� Perspectiva do Negócio (Business Perspective);

� Gerenciamento dos Ativos de Software (Software Asset Management).

Os livros Suporte a Serviços e Entrega de Serviços, são considerado como o núcleo da

ITIL (STATDLOBER, 2006).

Em 2007 a terceira versão da ITIL foi lançada, sendo que os seus trabalhos de

elaboração iniciaram-se em 2004, com uma nova estrutura, que é baseada no ciclo de vida do

serviço e com grande ênfase na integração da TI aos objetivos do negócio (ITIL Central,

2009). A versão 3.0 da ITIL é composta por cinco volumes, sendo estes (RUDD, 2004):

� Estratégia de serviço (Service Strategy);

� Desenho do serviço (Service Design);

� Transição de serviço (Service Transition);

� Operação de serviço (Service Operation);

� Processo contínuo de aperfeiçoamento (Continual Service Improvement).

No geral, a versão 3.0 da ITIL (Figura 03) ficou mais coesa entre as melhores práticas

e mais orientada aos objetivos do negócio. A principal contribuição desta terceira versão está

na abordagem baseada no ciclo de vida do serviço, ao contrário da abordagem baseada em

setores de entrega relatado na versão anterior.

Figura 03: ITIL versão 3.0 (ITSMF, 2009).

21

Essa nova abordagem foca-se no gerenciamento dos serviços desde a fase inicial de

planejamento, passando pela colocação em produção, suporte e substituição ou retirada do

serviço, de forma a estar sempre alinhado aos objetivos do negócio (OGC, 2004).

2.1.2 O núcleo da ITIL versão 2

A versão 2 da ITIL estava programada para ser descontinuada em 2008. Porém, em

virtude de diversas solicitações a versão 2 continuará após dezembro de 2008 até quando

houver demanda que justifique sua permanência no mercado (EXIN, 2009).

A ITIL chama a atenção dos CIOs (Chief Information Officer), pois está bastante

relacionada às tendências de gerenciamento dos serviços de TI com foco no negócio (JESUS,

2006).

O gerenciamento de serviços de TI é baseado em processos que por sua vez, são um

conjunto de atividades inter-relacionadas com foco num objetivo específico. Cada processo

pode ser bastante complexo dependendo da organização e para cada processo existe uma

determinada forma de gerenciamento. Um processo não pode ser visto de forma isolada, pois

eles estão interligados e devem ser coordenados para atingir o mesmo objetivo.

(MAGALHÃES, 2007). A ITIL vem para medir a qualidade e a eficiência da gestão dos

serviços de TI (ENTUITY, 2009).

Desta forma, os processos nucleares da ITIL promovem uma metodologia em que os

eventos, problemas, incidentes, desafios e mudanças são avaliados e priorizados visando o

impacto no negócio (PINKROCCADE, 2009). Os processos nucleares da ITIL são: Suporte

de Serviços e Entrega de Serviços. O Suporte de Serviços subdivide-se em (JESUS, 2006):

� Gerenciamento de Incidente (Incident Management);

� Gerenciamento de Problema (Problem Management);

� Gerenciamento de Mudança (Change Management);



A Entrega de Serviços subdivide-se em (JESUS, 2006):

22

� Gerenciamento de Nível de Serviço (Service Level Management);

� Gerenciamento de Disponibilidade (Availability Management);

� Gerenciamento da Capacidade (Capacity Management);

� Gerenciamento Financeiro (Financial Management);

� Gerenciamento da Continuidade dos Serviços de TI (IT Service Continuity

Management).

Para demonstrar a interatividade entre os processos da ITIL a Figura 04 ilustra o

relacionamento entre esses processos.

Figura 04: Relacionamento entre os processos da ITIL (Modificado) (MAGALHÃES, 2007, p. 67).

Na Figura 04, Cliente é o sujeito que paga pelos serviços de TI e Usuário é o sujeito

que usa os serviços de TI no dia-dia (OGC, 2000).

Portanto, este trabalho irá se deter exclusivamente aos processos que compõem o

Suporte de Serviços, pois, como já mencionado, eles compõem o núcleo da metodologia ITIL

versão 2.

Usuário

Áre

a d

e T

I

Central de Serviços

Gerenciamento da Configuração

Gerenciamento de Incidente

Gerenciamento de Problema

Gerenciamento de Mudança

Gerenciamento de Liberação

Gerenciamento de Nível de Serviço

Gerenciamento Financeiro

Gerenciamento de Continuidade

Gerenciamento de Capacidade

Gerenciamento de Disponibilidade

Suporte de Serviços Entrega de serviços

Cliente

23

2.2 ITIL: SUPORTE DE SERVIÇOS

O Suporte de Serviços é um dos principais livros, pois possui um ponto de vista de

nível operacional dos processos de um departamento de TI (MAGALHÃES, 2007).

Os processos do Suporte de Serviços são:

� Gerenciamento de Incidente (Incident Management);

� Gerenciamento de Problema (Problem Management);

� Gerenciamento de Mudança (Change Management);



Contudo, a central de serviço (Service Desk) é considerada pela ITIL como uma

função importante para os serviços de TI (OGC, 2000)

2.2.1 Central de Serviços (Service Desk)

Central de Serviços ou em inglês Service Desk, tem o objetivo de ser um ponto único

de contato entre os usuários e/ou clientes com o setor de TI. A ITIL não considera a Central

de Serviços como um processo e sim uma função essencial para a implementação do

gerenciamento dos serviços de TI (OGC, 2000).

A Central de Serviços é uma interface amigável para o usuário dos benefícios que a

TI traz aos negócios. Ela é responsável pela primeira impressão da área de TI aos seus

usuários (MAGALHÃES, 2007).

Várias são as atividades relacionadas à Central de Serviços, dentre elas destaca-se a

comunicação que deve ocorrer com os usuários, a fim de, informar sobre o

andamento/conclusão das solicitações, bem como qualquer problema que possa impactar a

disponibilidade dos serviços de TI (STATDLOBER, 2006).

A função Central de Serviços relaciona-se principalmente com o processo de

Gerenciamento de Incidente, solucionando incidentes que já foram mapeados e documentados

pelo processo de Gerenciamento de Incidente (MAGALHÃES, 2007).

24

A Central de Serviços é responsável por registrar todos os incidentes. Para isso, ela

pode utilizar telefone, e-mail, internet, visita pessoal, entre outros (MAGALHÃES, 2007).

Para satisfazer as estratégias do negócio e as necessidades dos clientes, as empresas

estão implementando um ponto único de contato (SPOC - Single Point of Contact). Essa

função é denominada de diversas formas, dentre elas (OGC, 2000):

� Central de Suporte (Help Desk): O objetivo é gerenciar, coordenar e resolver os

incidentes o mais rápido possível, a fim de, evitar que a solicitação seja perdida,

esquecida ou ignorada. Para auxiliar nessa tarefa, ferramentas de gestão do

conhecimento são utilizadas;

� Central de Chamadas (Call Center): O objetivo é gerenciar um grande número de

chamadas telefônicas, encaminhando-as para as áreas específicas e não atuando

sobre as transações;

� Central de Serviços (Service Desk): O objetivo se estende a não só atender aos

incidentes, problemas e dúvidas, mas sim promover uma interface as outras

atividades da área de TI, como: solicitações de mudança, contratos de manutenção,

cronograma das manutenções previstas, solicitações de serviço, etc. Desta forma a

Central de Serviços está focada numa abordagem global, por ser uma única porta de

entrada, aos diversos tipos de serviço da área de TI.

2.2.1.1 Indicador de desempenho

Apesar de ser uma função, a Central de Serviços possui pontos de controle que

permitam averiguar a eficiência, eficácia, efetividade e economicidade. O Quadro 01

demonstra essa proposta.

Perspectiva Indicador

Eficiência Índice de chamadas atendidas. Índice de incidentes encerrados no primeiro nível de suporte.

Eficácia Índice de incidentes encerrados dentro do prazo estabelecido. Índice de disponibilidade da infraestrutura da central de serviços.

Efetividade Índice de incidentes encerrados na primeira chamada. Índice de satisfação com o atendimento da central de serviços.

Economicidade Índice de incidentes resolvidos de forma remota. Índice de evolução do custo médio por chamada atendida.


25

2.2.2 Gerenciamento de Incidente (Incident Management)

Segundo OGC (2000, p. 71):

O principal objetivo do processo de Gerenciamento de Incidente é restabelecer operação normal1 do serviço mais rapidamente possível e minimizar o impacto negativo nas áreas de negócio, garantindo assim que os melhores níveis de qualidade de serviço e disponibilidade possíveis sejam mantidos.

2.2.2.1 Processo

O início do processo ocorre com a abertura da solicitação de serviço na Central de

Serviços. Essa solicitação não será necessariamente um incidente, ela poderá ser, por

exemplo, uma consulta sobre o funcionamento de um determinado software, informações

sobre a aquisição de um produto ou serviço de TI, etc. (STATDLOBER, 2006).

Incidente para a ITIL significa qualquer evento que não faça parte da operação padrão

de um serviço e que cause, ou possa causar interrupção ou redução na qualidade do serviço de

TI (MAGALHÃES, 2007).

Uma vez registrado o incidente, a sua causa será investigada e diagnosticada. Caso a

Central de Serviços não consiga resolvê-lo, ele será escalonado a outros níveis de suporte.

Estes irão investigar utilizando um conjunto de habilidades e ferramentas disponíveis, tais

como uma base de conhecimento de erros conhecidos. Todas as ações ocorridas nesse

processo deverão ser registradas junto ao registro do incidente.

Caso uma solução de contorno (workaround) ou uma solução definitiva para o

incidente seja encontrada, esta será implementada. Se houver necessidade de alguma

mudança, uma requisição de mudança será submetida ao Gerenciamento de Mudança (OGC,

2000).

1 Operação normal de serviço é definido como um serviço em funcionamento dentro dos limites do Acordo de Nível de Serviço (SLA - Service License Agreement) (OCG, 2000).

26

O fluxograma exibido pela Figura 05 demonstra o modo como a informação é tratada

pelo processo de Gerenciamento de Incidente.

Figura 05: Exemplo de processo de Gerenciamento de Incidente (MAGALHÃES, 2007, p.137).

Uma solução de contorno (workaround) nada mais é que uma solução temporária,

previamente definida pelo gerenciamento de problema. Normalmente é a primeira solução a

ser implementada para fazer com que o serviço de TI continue a ser prestado com o mínimo

de incômodo para o usuário, enquanto que uma solução definitiva restabelece as condições

normais do serviço (PINHEIRO, 2006).

2.2.2.2 Classificação

A classificação é o processo para identificar o motivo do incidente, de tal forma, que

permita a identificação de erros conhecidos e forneça informações gerenciais que permitam a

identificação dos tipos de incidentes mais frequentes. Muitos dos incidentes são vivenciados

regularmente e as soluções já são conhecidas. No entanto algumas vezes surgem novos

incidentes e uma classificação adequada ajudará na investigação das causas destes (OGC,

2004). É importante identificar também o impacto e a urgência do incidente, a fim de,

determinar a prioridade do mesmo (MAGALHÃES, 2007).

Início

Detecção e registro das chamadas

Classificação e suporte inicial ao incidente

Procedimento de atendimento da solicitação de serviço

Pesquisa da causa e diagnóstico

Resolução

Escalonamento

Encerramento do incidente

Fim

Solução de serviço?

Solucionado?

Não

Não Sim

Sim

27

Impacto é o número de usuários afetados pelo incidente ou problema. O Quadro 02

ilustra um exemplo de análise de impacto.

Impacto Descrição Fatal Conexão perdida Grave Conexão intermitente Negócio Processo de negócio afetado Parte do negócio Processo de negócio afetado de forma limitada

Quadro 02: Exemplo de análise de impacto (MAGALHÃES, 2007, p. 140).

Urgência é a velocidade que o incidente ou problema precisa ser resolvido. O

Quadro 03 ilustra um exemplo de análise de urgência.

Urgência Descrição Alta Até 30 minutos Média Até 120 minutos Baixa Até 240 minutos Programável Até dois dias úteis

Quadro 03: Exemplo de análise de urgência (MAGALHÃES, 2007, p. 141).

A prioridade é a correlação entre impacto e urgência. A Figura 06 ilustra a correlação

entre impacto e urgência, atribuindo um índice de prioridade entre 1 e 4, sendo 1 a prioridade

mais alta.

Figura 06: Priorização de atendimento do incidente (MAGALHÃES, 2007, p. 141).

2.2.2.3 Escalonamento

Escalonamento é um mecanismo utilizado para obter a resolução de um incidente

dentro do menor período de tempo possível (STATDLOBER, 2006).

Um incidente pode ter dois tipos de escalonamento: funcional ou hierárquico. O

escalonamento funcional é quando o incidente é escalonado para grupos com conhecimento

específicos ou ainda poderá ocorrer de forma automática, quando o tempo para a resolução do

Programável Baixa Média Alta Fatal 3 3 2 1 Grave 4 3 2 2 Negócio 4 4 3 3 Parte do negócio

4 4 4 3

Urgência

Imp

acto

28

problema expirar. Deve-se ter muito cuidado quando o escalonamento funcional ocorrer de

forma automática, pois esse intervalo de tempo não pode ultrapassar ao Acordo de Nível de

Serviço - SLA (Service License Agreement). O escalonamento hierárquico é quando o

incidente necessita ser escalonado para um nível superior (supervisor ou gerente) para uma

aprovação de verba ou uma decisão qualquer. O escalonamento hierárquico poderá ser

também de forma automática quando o incidente ultrapassou o tempo definido na SLA (OGC,

2000).


Para cada processo necessita-se prover pontos de controle que permitam averiguar a

eficiência, eficácia, efetividade e economicidade. O Quadro 04 demonstra essa proposta.


Eficiência Índice de evolução da quantidade de incidentes. Índice de incidentes encerrados no primeiro nível de suporte.

Eficácia Índice de incidentes encerrados dentro do prazo estabelecido. Índice de redução do prazo médio de incidentes de categoria 1.

Efetividade Índice de incidentes encerrados no primeiro atendimento. Índice de satisfação com o atendimento de incidentes.

Economicidade Índice de incidentes resolvidos de forma remota. Índice de evolução do custo médio por incidente encerrado.


2.2.3 Gerenciamento de Problema (Problem Management)

O Gerenciamento de Problema é o processo que visa à eliminação permanente dos

problemas e dos incidentes repetitivos reduzindo assim o impacto nas áreas de negócio do

cliente (Magalhães 2007).

2.2.3.1 Conceitos básicos

Segue abaixo alguns conceitos utilizados pelo Gerenciamento de Incidente (OGC,

2000):

29

� Problema: é uma causa desconhecida sobre um ou mais incidentes;

� Erro conhecido: é um problema onde foi diagnosticada com sucesso a sua causa-

raiz e o desenvolvimento subseqüente de uma solução de contorno (workaround);

� Solução de contorno: é uma solução temporária para a correção do incidente ou

problema. Utilizada para restabelecer o serviço com condições mínimas.

2.2.3.2 Atuações reativas e proativas

O Gerenciamento de Problema pode atuar de duas formas: reativa ou proativamente.

Na atuação reativa o Gerenciamento de Problema resolve os problemas referentes a um ou

mais incidentes reportados pelos usuários. Enquanto que a atuação proativa resolve problemas

antes que ocorram incidentes a eles relacionados (OGC, 2000).

2.2.3.3 Atividades

Controle de erros, controle de problemas e gerenciamento proativo de problemas são

algumas das atividades do escopo do Gerenciamento de Problema (OGC, 2000). A Figura 07

ilustra as entradas, as atividades e as saídas do Gerenciamento de Problema.

Figura 07: Entradas, atividades e saídas do Gerenciamento de Problema (Autor).

Incidentes registrados

Respostas as consultas do Gerenciamento de Incidente

Solução de contorno

Requisição de Mudanças (RFC)

Erro conhecido

Banco de dados de erros conhecidos

Detalhes do item de controle

Encerramento do problema caso resolvido

Informações gerenciais

• Controle de problemas • Controle de erros • Suporte a incidentes graves • Gerenciamento proativo de problemas • Identificação de tendência • Obtenção de informações gerenciais a

partir dos dados de problemas • Revisão dos principais problemas

identificados

30

O processo de Gerenciamento de Problema preocupa-se em gerenciar os problemas de

modo efetivo, eficaz, eficiente e econômico. Sendo assim, tem o objetivo de identificar a

causa-raiz do problema, identificar o Item de Configuração – CI (Configuration Items) que

está com problema e repassar informações sobre soluções de contorno a Central de Serviços

quando solicitado (MAGALHÃES, 2007).

O processo de Gerenciamento de Incidente e o processo do Gerenciamento de

Problema são bem similares e altamente dependentes. A diferença entre eles é que o

Gerenciamento de Problema deve encontrar a causa-raiz do incidente e formular a solução

(OGC, 2000).

2.2.3.4 Controle de problemas

Atividade responsável pela identificação da causa-raiz do problema, a fim de encontrar

uma solução permanente (OGC, 2000). Ela é composta pelas seguintes fases (Figura 08):

� Identificação e registro dos problemas;

� Classificação dos problemas;

� Investigação e diagnóstico da causa dos problemas.

Figura 08: Controle de problemas (OGC, 2000, p. 101).

Aco

mp

anh

amen

to e

mo

nito

raçã

o d

os

pro

ble

mas

Identificação e registro do problema

Classificação do problema

Investigação e diagnóstico do

problema

RFC, possível resolução do problema

e fechamento

(Controle de erros)

31

• Identificação e registro dos problemas

A identificação de um problema não é exclusivo do processo de Gerenciamento de

Problema; outros processos também podem identificar problemas. Qualquer que seja o

problema sempre deve ser notificado ao Gerenciamento de Problema para que seja registrado

(OGC, 2000). A Figura 09 ilustra essa atividade.

Figura 09: Identificação e registro dos problemas (OGC, 2000, p. 102).

32

• Classificação dos problemas

Depois de identificado o problema, este dever ser classificado. A forma de

classificação do problema segue a mesma proposta já apresentada na seção 2.2.2.2.

• Investigação e diagnóstico da causa dos problemas

A fase de investigação do problema é similar a investigação do incidente que ocorre

no Gerenciamento de Incidente, contudo a diferença é que lá o objetivo é restabelecer o mais

rápido possível o serviço e no Gerenciamento de Problema o objetivo é o diagnosticar a causa

do problema (OGC, 2000).

Uma vez diagnosticada a causa do problema, o status do registro da falha no CI deve

ser alterado de problema para erro conhecido. Quando a Central de Serviços registrar um

incidente reincidente o serviço será restabelecido mais rapidamente (OGC, 2000).

2.2.3.5 Incidente, problema e mudança

Os processos Gerenciamento de Incidente, Gerenciamento de Problema,

Gerenciamento de Mudança e a função Central de Serviços devem ter uma ótima integração,

pois caso uma mudança não seja gerida de forma correta poderá ocorrer novos incidentes e

por consequência novos problemas. Os incidentes devem ser registrados de forma exata e

detalhados, pois para descobrir a causa do erro, um problema será definido, pesquisado e

diagnosticado baseado neste registro. Quando um erro torna-se conhecido, uma Requisição de

Mudança é enviada para o gerenciamento de mudança, a fim de implementar a solução

definitiva (MAGALHÃES, 2007).

33

2.2.3.6 Controle de erros

A atividade de controle de erros é responsável pelas requisições de mudanças enviadas

para o Gerenciamento de Mudança, a fim de corrigir o erro através da implementação da

solução (OGC, 2000). Ela é composta pelas seguintes fases (Figura 10):

� Identificação e registro dos erros;

� Avaliação dos erros;

� Registro da resolução dos erros;

� Encerramento dos erros.

Figura 10: Controle de erros (OGC, 2000, p. 106).

Aco

mp

anh

amen

to e

mo

nito

raçã

o d

os

erro

s

Identificação e registro do erro

Avaliar o erro

Gravar a resolução do erro

Finalizar o erro e

associar ao problema(s)

(Controle de problemas)

RFC

Mudança implementada com

34

• Identificação e registro dos erros

Um erro é identificado quando é detectado uma falha no CI. O status de um erro

conhecido somente é atribuído quando a causa-raiz do problema é identificado e uma solução

de contorno é definida. A partir disso o erro é registrado (OGC, 2000).

• Avaliação dos erros

Esta fase avalia os meios para resolver o problema. Se necessário uma Requisição de

Mudança será encaminhada para o Gerenciamento de Mudança. Neste momento a prioridade

será determinada pela urgência e o impacto que o problema está gerando para o negócio. O

número de identificação da Requisição de Mudança deve estar informado no registro do erro

conhecido e vice-versa, a fim de localizar mais facilmente essas informações. Os demais

estágios de resolução do erro são (OGC, 2000):

� Análise de impacto;

� Análise detalhada da ação de correção que será executada;

� Correção do erro;

� Testes de mudanças (situação sob controle do Gerenciamento de Mudança).

• Registro da resolução de erros

Esta fase destina-se a registrar os erros conhecidos na base de dados. Os sintomas, a

resolução, as ações tomas para sanar os erros com os CI devem ser registrados para uma

posterior consulta tanto para investigação quanto para coletar informações gerenciais (OGC,

2000).

35

• Encerramento dos erros

O encerramento do erro ocorre após a implementação e mudança ocorrer

corretamente. Os registros de incidente e problemas que foram abertos serão encerrados com

a informação do identificador do erro conhecido (OGC, 2000).

2.2.3.7 Gerenciamento proativo de problemas

A atividade de gerenciamento proativo de problema visa evitar que um incidente e/ou

problema ocorra (MAGALHÃES, 2007).

2.2.3.8 Identificação de tendência

Essa atividade visa identificar possíveis tendências de problemas. Para desempenhar

essa atividade faz se necessário métodos estatísticos, experiência da equipe de suporte e do

registro de incidentes relatados pelos usuários (MAGALHÃES, 2007).

2.2.3.9 Geração de informações gerenciais

Através dos dados gerados pelo processo de Gerenciamento de Problema é possível

gerar relatórios sobre eficiência, eficácia, economia e efetividade tanto para a equipe de

gerenciamento dos processos de TI quanto para os demais processos (MAGALHÃES, 2007).

36

2.2.3.10 Revisão dos principais problemas identificados

Atividade também conhecida como revisão pós-implementação visa avaliar se a

mudança, executada pelo Gerenciamento de Mudança está correta e se ela causou algum

efeito colateral (MAGALHÃES, 2007).





Eficiência Índice de evolução da quantidade de problemas. Índice de incidentes decorrentes de erros conhecidos.

Eficácia Índice de problemas encerrados dentro do prazo estabelecido. Índice de redução do prazo médio de solução de problemas.

Efetividade Índice de solicitações de mudanças implementadas. Índice de satisfação com o atendimento de problemas.

Economicidade Índice de redução no impacto para o negócio devido a incidentes e problemas. Índice de evolução do custo médio por problema encerrado.


2.2.4 Gerenciamento de Mudança (Change Management)

O processo Gerenciamento de Mudança é responsável por controlar as mudanças que

impactam na infraestrutura e nos serviços de TI, de uma maneira processual, documentada e

controlada, evitando o mínimo de impactos negativos. As mudanças não são só destinadas à

resolução de problemas, mas também para trazer benefícios ao negócio, tais como: redução de

custo e melhoramento nos serviços (OGC, 2000).

O Gerenciamento de Mudança está diretamente relacionado ao processo de

Gerenciamento da Configuração, a fim de acessar o Banco de Dados do Gerenciamento da

Configuração – CMDB (Configuration Management Database) para ter as informações

atualizadas dos CIs. Através dessas informações é possível definir o plano de ação correto

37

para efetuar as mudanças. Veremos ainda que o Gerenciamento de Mudança possui um

ligação estreita com o Gerenciamento de Liberação (MAGALHÃES, 2007).

2.2.4.1 Requisição de Mudança

Requisição de Mudança – RFC (Request for Change) é o início de todo o processo de

Gerenciamento de Mudança que é requisitado por diversas fontes e por diversas razões.

Quanto às razões, podemos destacar (OGC, 2000):

� Resolução de incidentes ou problemas;

� Insatisfação de usuários e/ou clientes quanto aos serviços de TI;

� Inclusão, alteração ou exclusão de um CI na infra-estrutura de TI;

� Mudança nos objetivos do negócio;

� Mudanças referentes à legislação;

� Mudanças nos produtos ou serviços dos fornecedores.

Uma RFC pode alterar parte da infraestrutura de TI ou um serviço de TI ou uma

atividade de TI, tais como: Hardware, Software, Documentação, procedimento, etc. (OGC,

2000).

Os seguintes itens devem constar numa RFC (OGC, 2000):

� Número da RFC;

� Identificador do problema a ser corrigido;

� Descrição e identificação dos CIs a serem alterados;

� Motivo da mudança;

� Efeito de não se implementar esta mudança;

� Versão dos itens de configuração a ser manipulados;

� Nome, localização e telefone da pessoa que propõem a mudança;

� Data em que a mudança foi proposta;

� Prioridade da mudança;

38

� Impacto e estimativa de recursos necessários (podem ser feitas a parte);

� Recomendações do Comitê de Mudanças quando apropriado;

� Hora e data da autorização para a implantação da mudança;

� Assinatura (pode ser eletrônica);

� Cronograma de implementação;

� Local da versão e Plano de implementação;

� Detalhes do desenvolvedor e implementador da mudança;

� Plano de retorno ao original (back-out);

� Hora e data da implementação real;

� Data da revisão;

� Resultados da revisão;

� Avaliação de risco;

� Impacto na comunidade do negócio e nos planos de contingência;

� Status da Requisição de Mudança (por exemplo: registrada, avaliada, rejeitada,

aceita, aguardando).

2.2.4.2 Comitê de Mudança

O Comitê de Mudança – CAB (Change Advisory Board) é um grupo formado por

diversas áreas existentes na organização para auxiliar o gerente de mudança na aprovação,

avaliação e priorização das mudanças (OGC, 2000).

2.2.4.3 Comitê de Mudança Emergencial

O Comitê de Mudança Emergencial - CAB/EC (Change Advisory Board/Emergency

Committee) é um grupo menor que o CAB e somente é convocado para tomar decisões

referentes a grandes problemas emergenciais (PINHEIRO, 2006).

39

2.2.4.4 Atividades

As atividades do processo de Gerenciamento de Mudança visam minimizar os

impactos e os risco através da análise e do planejamento dos processos que serão adotados

para a execução da mudança. As atividades estão descritas abaixo:

� Planejar a execução dos processos operacionais;

� Registrar e filtrar RFCs;

� Atribuir prioridade;

� Definir categoria;

� Reunião do Comitê de Mudança;

� Avaliar impacto e recursos;

� Aprovação da mudança;

� Agendamento da mudança;

� Desenvolvimento, teste e execução da mudança;

� Mudanças urgentes;

� Rever as mudanças.

As entradas, as atividades e saídas que compõem o Gerenciamento de Mudança é

ilustrado pela Figura 11.

Figura 11: Entradas, atividades e saídas do Gerenciamento de Mudança (Autor).

A seguir, descrevem-se as atividades do processo de Gerenciamento de Mudança

conforme a bibliografia descrita em OGC (2000).

Requisições de mudanças (RFC)

Programação de futuras mudanças

Banco de dados do Gerenciamento da Configuração (CMDB)

Programação de futuras mudanças

Requisições de mudanças aprovadas

Atas de reuniões do CAB e ações

Relatórios do Gerenciamento de Mudança

• Registrar e classificar das RFC • Avaliação do impacto • Desenvolvimento da justificativa • Coordenação da implementação • Encerramento e revisão das RFC

Banco de dados de erros conhecidos

40

• Planejar a execução dos processos operacionais

O processo de Gerenciamento de Mudança prevê um plano de implementação dos

procedimentos básicos das atividades. A Figura 12, apresentada em duas partes (a, b),

demonstra o fluxograma destes procedimentos (OGC, 2000).

Figura 12a: Procedimentos básicos do Gerenciamento de Mudança - Parte 01 (OGC, 2000, p. 171).

41

Figura 12b: Procedimentos básicos do Gerenciamento de Mudança - Parte 02 (OGC, 2000, p. 172).

42

No entanto, algumas mudanças possuem procedimentos simples o que os torna

padronizados minimizando assim o risco e o impacto na organização. O fluxograma exibido

na Figura 13 demonstra o modelo padrão de mudança.

Figura 13: Modelo padrão de uma mudança (OGC, 2000, p. 173).

• Registrar e filtrar RFCs

A atividade de registrar uma RFC pode ser feito de diversas formas, por exemplo, e-

mail ou páginas na Intranet. Contudo, as informações descritas na seção 2.2.4.1 devem estar

contempladas para uma posterior filtragem (OGC, 2000).

Requisições de mudanças que forem impraticáveis ou que estivem mal especificadas

serão rejeitadas e devolvidas para o solicitante e no histórico da requisição deve estar

registrado esse fato. Contudo, é permitido que o solicitante esclareça eventuais dúvidas (OGC,

2000).

43

• Atribuir prioridade

O solicitante pode indicar uma prioridade prévia para a RFC, mas a real prioridade da

RFC será definida pelo gestor de mudanças. Através dessa prioridade é definido se será ou

não encaminhado ao CAB, e se for encaminhado, qual a ordem dela perante a reunião do

CAB. Segue abaixo uma sugestão de prioridade para as RFC (OGC, 2000):

� Imediata: Parada severa do(s) serviço(s) de TI ocasionando problemas a muitos

usuários;

� Alta: Parada severa do(s) serviço(s) de TI ocasionado problemas a alguns usuários;

� Média: Sem grandes impactos e que pode ser implementado uma próxima agenda

de mudanças;

� Baixa: Mudança justificada e necessária que pode esperar por uma próxima agenda

de mudanças ou versão (quando se tratar de software).

• Definir categoria

A definição da categoria é feita pelo gerente de mudança, onde irá decidir qual

processo que a RFC irá passar. A categorização examina o impacto das mudança com relação

às necessidades do negócio e os recursos necessários para efetuar a mudança (OGC, 2000).

De acordo com o impacto que a mudança provoca na organização o Gerenciamento

de Mudança pode delegar a autoridade da mudança para outro processo, mas a

responsabilidade continua sendo sua. Segue abaixo um exemplo para categorizar as RFCs

(OGC, 2000):

� Baixo impacto: O gerente de mudança delega a autoridade para outra pessoa

agendar cada mudança, mas exige que as mudanças sejam documentadas para

possibilitar a identificação da mudança para futuros problemas/incidentes e

avaliação dos custos da mudança;

� Impacto significante: De acordo com a urgência da mudança o gerente de

mudança decide se irá encaminhar para a reunião do CAB ou para o CAB/EC.

44

Contudo, antes de encaminhar para a reunião toda a documentação da mudança

deve estar detalhada para avaliação do impacto;

� Alto impacto: Essa categoria exige a avaliação do conselho administrativo, onde,

após aprovado é encaminhado ao CAB para definir a preparação da implementação.

• Reunião do Comitê de Mudança

As reuniões do CAB não precisam ser necessariamente presenciais, contudo em casos

de uma complexidade e riscos altos faz-se necessário uma reunião presencial. Algumas

informações são relevantes que sempre estejam nas pautas destas reuniões, são elas (OGC,

2000):

� Discutir sobre mudanças que falharam e seus planos de contingência;

� Analisar as RFCs selecionadas para a reunião;

� Analisar as RFCs que ainda estão em aberto;

� Revisar as mudanças;

� Melhorias para o Gerenciamento de Mudança;

� Definir a agenda de mudanças e os recursos necessários.

• Avaliar impacto e recursos

A avaliação do impacto e dos recursos de uma RFC é conduzida pelo gerente de

mudança, CAB, CAB/EC e pessoas envolvidas no processo. Alguns itens deve ser

considerados nessa avaliação, como: o impacto no negócio, nos serviços de TI e nos níveis de

serviço acordados (OGC, 2000).

Nos casos em que as especificações dos CIs não mudam (por exemplo, o conserto de

um hardware) não será necessário a avaliação de impacto, entretanto, nos casos de erro de

software é necessário essa avaliação (OGC, 2000).

45

• Aprovação da mudança

A aprovação da mudança deve seguir no mínimo três processos de aprovação, sendo

eles: Técnico, Financeiro e Negócio. A aprovação técnica irá avaliar se as etapas da mudança

são coerentes e executáveis e se os serviços de TI não serão afetados. Há também a

necessidade de informar uma estimativa de custo para a mudança. A aprovação financeira

avalia se os custos não ultrapassam o orçamento definido, bem como, o custo benefício da

mudança. A última aprovação cabe ao cliente definir e entender o que a mudança sugerida irá

afetar o negócio (OGC, 2000).

• Agendamento da mudança

É a reunião de diversas RFCs que já foram analisadas e aprovadas e organizadas,

conforme as suas prioridades, para serem aplicadas numa mesma data. Porém o calendário de

aplicação dessas mudanças deve estar alinhado com as necessidades da organização e dos

usuários finais (OGC, 2000).

• Desenvolvimento, teste e execução da mudança

Após aprovada as RFCs, essas serão encaminhadas para grupos técnicos que irão

desenvolver a mudança. Isso poderá envolver (OGC, 2000):

� Construção de um novo ambiente de produção;

� Criação de uma nova versão ou módulos no sistema;

� Compra de equipamentos ou serviços externos;

� Modificação de hardware;

� Criação ou alteração nas documentações existentes;

� Criação ou alteração no treinamento dos usuários.

46

O gerente de mudança tem a função de coordenar e apoiar o Gerenciamento de

Liberação para que as atividades ocorram conforme a agenda programada. O Gerenciamento

de Liberação tem um papel importante, pois é ele que irá implementar e documentar a

mudança, bem como o processo de retorno (back-out) para o Gerenciamento da Configuração

(OGC, 2000).

Para evitar problemas com a disponibilidade dos serviços de TI é recomendado que

testes sejam feitos com antecedência e se possível procedimentos de retorno sejam

desenvolvidos (OGC, 2000).

Quando o processo de implementação estiver pronto esse deverá aguardar a agenda de

mudanças para a sua implementação. Os incidentes que ocorrerem, em virtude das mudanças,

deverão ser tratados com urgência (OGC, 2000).

• Mudanças urgentes

Mudanças urgentes devem ser mínimas, pois o fracasso é maior nestes casos. Isso

porque elas devem ser implementadas rapidamente e algumas vezes sem testes para validar o

sucesso de sua implementação. Os procedimentos para a implementação dessa atividade está

ilustrado nas Figuras 14a e 14b (OGC, 2000).

Figura 14a: Procedimentos para mudanças urgentes – Parte 01 (OGC, 2000, p. 188).

47

Figura 14b: Procedimentos para mudanças urgentes - Parte 02 (OGC, 2000, p. 188).

• Rever as mudanças

O Gerenciamento de Mudança deve rever todas as mudanças executadas após um

período de tempo, para avaliar se (OGC, 2000):

� Foram efetuadas conforme o planejado;

48

� Geraram o efeito esperado para os clientes e/ou usuários;

� Foram implementadas com os recursos e custos corretos;

� Funcionou o plano de retorno.

Essas avaliações podem ser encaminhadas para o CAB, a fim de melhorar as

estimativas e os processos para as implementações futuras. Caso uma mudança não alcance os

objetivos estipulados o gerente de mudança ou o CAB podem decidir por voltar ao estado que

estava antes da mudança e encerrar a RFC (OGC, 2000).





Eficiência Índice de mudanças implementadas. Índice de incidentes advindos das mudanças implementadas.

Eficácia Índice de mudanças implementadas dentro do prazo estabelecido. Índice de disponibilidade dos serviços de TI.

Efetividade Índice de mudanças retrocedidas. Índice de satisfação com a implementação das mudanças.

Economicidade Índice de incidentes de mudanças canceladas. Índice de evolução do custo médio por mudanças realizadas.


2.2.5 Gerenciamento de Liberação (Release Management)

O processo de Gerenciamento de Liberação (Release Management) é responsável por

proteger o ambiente de produção e os serviços de TI. A proteção vem através de

procedimentos formais e de rotinas de testes extensivos relacionados às mudanças

(MAGALHÃES, 2007).

Os objetivos do Gerenciamento de Liberação são (OGC, 2000):

� Planejar e supervisionar a implantação de hardwares e softwares;

� Desenvolver e aplicar procedimentos eficazes para implementar as mudanças;

49

� Garantir uma manutenção segura de um CI, onde antes de instalado o CI possa ser

testado;

� Prover um armazenamento físico e seguro de itens de hardware e software no

Depósito de Hardware Definitivo (DHS - Definitive Hardware Store) e na

Biblioteca Definitiva de Software (DSL - Definitive Software Library);

� Garantir que todas as alterações feitas nos CI sejam informadas ao Gerenciamento

da Configuração.


Segue abaixo alguns conceitos utilizados pelo Gerenciamento de Liberação (OGC,

2000):

Liberação (Release): é um conjunto de mudanças autorizadas, originadas de RFCs,

que podem alterar tanto hardware como software. As liberações são identificadas de três

formas:

� Maior ( Major release): Consiste em grandes mudanças. Esse tipo de liberação

pode acrescentar novas funcionalidades. Ex: Da versão 2 para a versão 3;

� Menor (Minor release): Consiste em pequenas melhorias e correções. Ex: Da

versão 2.0 para versão 2.1;

� Correções de emergência (Emergency fix): Consiste em pequenas mudanças no

intuito de corrigir problemas significativos. Ex: Da versão 2.0 para versão 2.0.1.

Existem três tipos de liberações:

� Liberação completa (Full release): consiste na liberação de vários componentes

que foram testados em conjunto, evitando assim grandes problemas ao serem

incorporados no ambiente de produção. Um exemplo de liberação completa é a

troca de versão;

� Liberação parcial (Delta release): consiste na liberação de um componente, a fim

de atender a uma melhoria e/ou correção;

50

� Pacote (Package release): consiste na união de várias tipos de liberação (completa

ou parcial) possibilitando assim períodos maiores de estabilidade, onde não é

necessário efetuar atualizações freqüentes.

Biblioteca Definitiva de Software (DSL - Definite Software Library): local onde é

guardado e protegido fisicamente todos os softwares (e documentação técnica) adquiridos

pela organização. A DSL pode ser constituída de uma ou mais áreas de armazenamento, onde

são guardados as cópias originais e cópias-mestras dos softwares e suas documentações

técnicas. O relacionamento entre a DSL e o CMDB é expressa pela Figura 15.

Figura 15: Relacionamento entre DSL e o CMDB (OGC, 2000, p. 206).

Depósito de Hardware Definitivo (DHS - Definitive Hardware Store): local

protegido para o armazenamentos dos equipamentos e peças de reposição (hardware) da

organização. Esses equipamentos e peças devem estar registrados no CMDB.

Gerenciamento do desenvolvimento: para poder controlar a inclusão de um novo CI

no ambiente de produção é necessário que um processo de implantação.

Testes: processo que é executado antes que qualquer implementação de uma nova

liberação no ambiente de produção

Plano de retorno (Back-out): documentação das ações para retornar a situação

original em caso de falha na implementação da mudança.

51

2.2.5.2 Atividades

Às competências do Gerenciamento da Liberação compreendem o planejamento,

concepção, construção, configuração e testes dos CIs (hardware e software), a fim de

construir um conjunto de liberações a ser aplicado no ambiente de produção (OGC, 2000).

As atividades que compõem o gerenciamento da liberação são:

� Planejamento da política de liberação

� Concepção, construção e configuração da liberação

� Aceite da liberação

� Planejamento da implantação

� Realização de testes criteriosos e exaustivos

� Comunicação, preparação e treinamento

� Auditorias nos CIs antes e após a implementação da mudança

� Instalação ou atualização do hardware

� Armazenamento centralizado e controle dos softwares

� Liberação, distribuição e instalação dos softwares

2.2.5.3 Planejamento e Implementação

Neste capítulo será tratado como o planejamento e a implementação das liberações

devem ser efetuadas conforme as informações descritas pela OGC (2000).

• Planejamento

O Gerenciamento de Liberação é extremamente dependente do Gerenciamento da

Configuração e do Gerenciamento de Mudança. Caso isso não ocorra é necessário a

elaboração de um plano para a gestão da liberação (OGC, 2000).

52

Este plano deve contemplar (OGC, 2000):

� Definição de políticas e procedimentos para a liberação;

� Definição de papéis e responsabilidades para as pessoas que farão a mudança;

� Responsabilidades das pessoas da central de gerenciamento da liberação;

� Ferramentas para auxiliar na aplicação da liberação no ambiente de produção;

� Pessoas para fornecer suporte ao Gerenciamento de Liberação;

� Treinamentos;

� Agendamento em conjunto com a organização a data para as liberações de

mudanças;

� Padrões de documentação, a fim de auxiliar no planejamento das liberações;

� Gerenciamento o desenvolvimento de testes;

� Garantia que as correções foram efetuadas;

� Garantir que existe área física para aplicar a mudança e que os testes foram

efetuados.

a) Políticas de liberação: As políticas de liberação servem para esclarecer os

procedimentos adotados pelo Gerenciamento da Liberação. Segue abaixo as informações

que devem constar numa política de liberação (OGC, 2000):

� Definição sobre os requisitos necessários para a aplicação da liberação;

� Nomeação e numeração da liberação;

� Definição de como as formas de liberação (maior, menor e correções de

emergência) serão aplicadas;

� Definição da freqüência para aplicar as liberações;

� Identificação junto a organização intervalos onde será possível efetuar a

implementação sem muitos prejuízos;

� Desenvolvimento de boletins técnicos explicando sobre a nova liberação;

� Políticas para o desenvolvimento de testes e planos de retorno (back-out);

� Planejamento, responsabilidades e avaliações técnicas devem estar assinados;

53

� Descrição do processo de controle do Gerenciamento da Liberação (Ex: reuniões,

avaliação do progresso, análise de impacto, dentre outros.);

� Documentação da configuração da Biblioteca de Software Definitivo.

b) Procedimentos de liberação e plano de implementação: Para que a equipe de

Gerenciamento de Liberação e suporte desempenhem de forma eficiente e eficaz os

procedimentos, modelos e orientações devem estar documentados. Dessa forma, ficam

claros itens como a estrutura da organização, requisitos operacionais e orientações de

desenvolvimento e configuração (OGC, 2000).

c) Matriz de responsabilidade: O processo de liberação, às vezes, pode ser muito

complexo envolvendo diversas pessoas e cada uma com procedimento ou

responsabilidade definidos.

Certos procedimentos de desenvolvimento e instalação já são previamente estabelecidos e

aprovados, sendo assim não há necessidade de obter o aceite do Gerenciamento de

Mudança. Contudo o CMDB deve ser atualizado, de preferência automaticamente,

referente a qualquer mudança ocorrida, documentada e implementada com sucesso.

Para esclarecer os procedimentos e responsabilidades de cada pessoa envolvida no

processo de liberação é utilizado uma matriz de responsabilidade (Quadro 07). Através

dela é possível identificar lacunas e/ou sobreposições referentes as responsabilidades de

cada pessoa (OGC, 2000).

Responsabilidade da liberação

Desenvolvimento Teste controlado do ambiente de produção

Classe de objetos Liberado para Aceite pelo Autorizado para liberar para produção

Suporte e aceite pelo

Registro para controle

Compra de um pacote

Gerente de desenvolvimento

Gerente de testes

Gerente de mudança

Gerente de operações

CMDB DSL

Módulos personalizados


Gerente de testes

Gerente de mudança

Gerente de operações

CMDB DSL

Mudanças físicas de banco de dados (BD)


Administrador de banco de dados

Gerente de mudança

Administrador de banco de dados

CMDB BD Script no DSL

Servidor Construtor do servidor

Gerente de servidor

Gerente de mudança

Gerente de servidor

CMDB

Continua

54

Continuação Responsabilidade da liberação

Desenvolvimento Teste controlado do ambiente de produção

Classe de objetos Liberado para Aceite pelo Autorizado para liberar para produção

Suporte e aceite pelo

Registro para controle

Configuração do computador

Gerente de desenvolvimento de computadores

Gerente de testes

Gerente de mudança

Gerente de suporte de computadores

CMDB DSL

Aplicação para computador

Gerente de desenvolvimento de computadores


Gerente de mudança; Suporte de computadores


CMDB DSL

Montagem do computador

Logística Suporte de computadores

Gerente de mudança; Suporte de computadores


CMDB

Autorização de liberação/Registro de mudança


Gerente de testes

Gerente de liberação; Gerente de mudança; Gerente de testes; Gerente de operações; Suporte de computadores; Central de serviços; Usuários de cada setor

Central de serviços; Usuários

CMDB

Quadro 07: Matriz de responsabilidade (OGC, 2000, p. 215).

d) Planejamento de liberação: O planejamento de liberação envolve obter o aceite da

organização sobre a agenda de liberação, o impacto que esta liberação irá gerar, repassar

os planos de implantação e retorno, determinar as pessoas envolvidas e suas

responsabilidades. É importante também que o Gerenciamento de Mudança esteja a par

das ações que serão tomadas pelo Gerenciamento da Liberação. Para executar o plano de

liberação são necessárias algumas informações (OGC, 2000):

� Visão geral da necessidade do negócio;

� Política de liberação;

� RFCs autorizadas;

� Restrições e dependências;

� Serviços relacionados;

� Ciclo de vida do projeto;

55

� Parecer do CAB.

e) Projetar, desenvolver e configurar uma liberação: Os procedimentos para a

implementação de uma liberação deve ser planejada e documentada, e quando possível,

deve utilizar padrões já estabelecidos de procedimentos de liberação. Ao final será gerado

um manual de implementação da liberação detalhando a instalação e os CIs alterados

(OGC, 2000).

Procedimentos automatizados de liberação são muito comuns, pois minimizam erros, mas

isso não elimina a necessidade da elaboração de um plano de retorno (MAGALHÃES,

2007).

Todos os resultados obtidos (parametrização, configurações, atualizações no banco de

dados, etc.) devem ser registrados no CMDB para uma posterior utilização dessas

informações (OGC, 2000).

f) Aceite da liberação: O aceite da liberação somente ocorre se os testes de implementação

e de retorno estiverem corretos. Para avaliar a realização dos testes é necessário que as

configurações efetuadas no ambiente de teste referentes a hardware e software devam ser

documentadas no CMDB juntamente com os CIs que sofrerão as modificações (OGC,

2000).

Caso a liberação seja rejeitada o Gerenciamento de Mudança deve ser avisado sobre o

adiamento da mudança. Além disso, é necessário relatar os problemas encontrados que

inviabilizaram o sucesso da mudança (OGC, 2000).

g) Planejamento da implementação: O planejamento da implementação é um

detalhamento do planejamento da liberação, onde envolve (OGC, 2000):

� Determinar o tempo de cada procedimento e o que cada responsável irá fazer;

� Detalhar os procedimentos de instalação ou eliminação dos CIs;

� Documentar o plano de ação;

� Elaborar boletins informativos sobre a liberação para os usuários;

56

� Planejar a comunicação;

� Planejar as compras;

� Agendar reuniões com as pessoas envolvidas na implementação.

A implementação pode ocorrer de duas formas "big bang" ou gradual. Quando ocorre

falha de implementação e a abordagem utilização é a "big bang", todos os usuários serão

afetados. Enquanto que a utilização da abordagem gradual é melhor aplicada quando o

novo sistema permite a coexistência do antigo sistema. Caso isso não seja possível a

melhor alternativa é a abordagem "big bang" (OGC, 2000).

• Implementação

Liberar e distribuir um software requer que tudo esteja previamente documentado,

testado e treinado (conforme o planejado) para evitar problemas na implementação (OGC,

2000).

As liberações de softwares desenvolvidos ou comprados devem ser encaminhados

para a DSL registrar as informações no CMDB (OGC, 2000).

� Comunicando, preparando e treinando: Comunicação e treinamento são muito

importantes tanto para os clientes quando a equipe de suporte, pois ambos precisam

saber o que está previsto, o que irá afetar e quais são as expectativas. Os

treinamentos normalmente ocorrem em paralelo com o aceite da liberação e

reuniões são feitas para esclarecer o plano de ação, estabelecer pontos de avaliação

e acordar as respectivas responsabilidades (OGC, 2000).

� Distribuição e instalação: A distribuição pode ocorrer de forma física ou através

de uma rede de dados. Quando a distribuição ocorre por meio físico é importante

saber que está sendo enviado e recebido de forma segura. Numa distribuição por

uma rede de dados as áreas remotas é que farão o acesso e o download do mesmo

(OGC, 2000).

Depois de distribuído o software, a instalação ocorrerá no ambiente de produção

conforme os procedimentos definidos no ambiente de teste. Observa-se que na

documentação enviada deva constar as configurações requeridas de hardware e software

57

para que a implantação ocorra de forma estável. Ao final da instalação o CMDB deve ser

atualizado para garantir o retrato do ambiente atual (OGC, 2000).





Eficiência Índice de evolução dos incidentes advindos das liberações realizadas. Índice de atualização dos CIs em produção.

Eficácia Índice de liberações implementadas dentro do prazo estabelecido. Índice de redução do prazo médio de implantação de liberações.

Efetividade Índice de liberações implementadas sem a necessidade de back-out. Índice de satisfação dos usuários com a implantação de liberações.

Economicidade Índice de liberações realizadas dentro do orçamento acordado. Índice de cumprimento das exigências legais de licenciamento.


2.2.6 Gerenciamento da Configuração (Configuration Management)

O processo de Gerenciamento da Configuração é responsável por identificar e definir

os itens de configuração da infraestrutura de TI, bem como, registrar, informar, controlar e

avaliar o estado dos mesmos (Magalhães 2007) .

Os objetivos do Gerenciamento da Configuração segundo OGC (2000) são:

� Catalogar todos os bens de TI e suas configurações no âmbito da organização;

� Fornecer informações precisas sobre a documentação e configuração para ajudar

todos os processos da gestão de serviços de TI;

� Prover uma base sólida para o Gerenciamento de Incidente, Problema, Mudança e

Liberação;

� Verificar as configurações registradas referentes a infra-estrutura e corrigir

eventuais erros.

58

A gestão da configuração abrange a identificação, configuração, relação dos

componentes incluindo as versões e o relacionamento existente entre eles. Dessa forma fica

claro que Gerenciamento da Configuração não é sinônimo de gerenciamento de ativos, pois as

informações registradas vão além de uma lista de itens, elas demonstram o relacionamento

existente entre os itens (OGC, 2000).


Segue abaixo alguns conceitos utilizados pelo Gerenciamento da Configuração (OGC,

2000):

a) Planejamento do Gerenciamento da Configuração: O planejamento da configuração

consiste em:

� Definir a estratégia, política, contexto, escopo e objetivo do Gerenciamento da

Configuração;

� Analisar a situação dos itens de configuração;

� Definir as políticas relacionadas ao processo de Gerenciamento de Mudança e

Gerenciamento de Liberação;

� Definir os processos, procedimentos, ferramentas de apoio, responsabilidades de

cada pessoa dentro das atividades de Gerenciamento da Configuração;

� Definir os locais de armazenamento do DHS e da DSL.

b) Identificação da configuração e dos itens de configuração: A identificação da

configuração e dos ICs é a identificação, seleção e rotulagem das estruturas de

configuração o dos itens de configuração (CI), incluindo o relacionamento entre eles. Os

CIs podem ser hardwares, softwares e documentações. As identificações da configuração

podem ser atributos dos CIs e suas versões, registros de incidentes, problemas, erros

conhecidos, mudanças, liberações, locais, fornecedores, procedimentos, entre outros.

c) Controle da configuração: O controle da configuração garante que nenhum CI é

adicionado, modificado, substituído ou retirado sem haver um controle da documentação.

59

d) Acompanhamento do status da configuração: O acompanhamento do status da

configuração é a relação de todas as informações atuais ou históricas de cada CI. Dessa

forma é possível rastrear um acontecimento ocorrido com o CI.

e) Verificação e auditoria da configuração: A verificação e auditoria da configuração é

uma série de revisões e auditorias que verificam se um CI existe e se as informações

cadastradas estão corretas. Compreende ainda a verificação da documentação da

configuração referente a liberação que será aplicada no ambiente de produção.

f) Configuração inicial: A configuração inicial é um retrato da situação atual (detalhes da

configuração) de um CI. A partir desse ponto, as informações do CI serão manipuladas

pelos processos Gerenciamento de Mudança e Gerenciamento de Liberação.

g) Base de Dados do Gerenciamento da Configuração (CMDB): O CMDB é um sistema

de cataloga e centraliza as informações dos itens de configuração da infra-estrutura de TI.

Atualmente as infra-estruturas de TI estão cada vez maiores e complexas, e gerenciá-las

torna-se difícil sem um sistema. Abaixo alguns exemplos da necessidade deste sistema:

� Controlar o conteúdo das liberações dos CIs;

� Controlar o número de versão dos CIs tanto no ambiente de teste quanto no

ambiente de produção;

� Controlar os CIs afetados pela mudanças autorizadas;

� Controlar todas as RFCs referentes a um único CI;

� Compra de um determinado CI num período determinado;

� Histórico dos CIs;

� Localizar um equipamento ou software;

� Agendar a atualização, troca ou eliminação de um CI;

� Registro de problemas ou mudança relacionado a um CI;

� Relacionar todos os CIs afetados por um determinado problema.

O CMDB contém informações sobre os CI, os problemas, os incidentes, as mudanças

e as liberações ocorridas, os erros conhecidos, os serviços prestados, os locais, a empresa, os

60

usuários, os técnicos responsáveis, o fornecedor, dentre outros. Todas essas informações estão

relacionadas ao CI.

h) Biblioteca de software ou documentação: A biblioteca de software ou documentação é

um local de armazenamento controlado de documentos ou softwares de um CI. Essa

biblioteca é utilizada para controle das liberações de mudança.

i) Controle de licenças: A instalação de softwares piratas é crime previsto em lei, sendo

assim, o controle de licenças é necessário para poder efetuar auditorias e monitoramentos

sobre as diversas formas de licenciamento.

2.2.6.2 Planejamento e implementação

A infraestrutura de TI é muito complexa e muito distribuída. O mapeamento dessa

estrutura deve ser feito de forma cuidadosa e planejada. Porém nesse planejamento deve ser

incluído o Gerenciamento de Incidente, o Gerenciamento de Problema, o Gerenciamento de

Mudança, o Gerenciamento de Liberação e o Gerenciamento da Configuração (OGC, 2000).

Algumas premissas devem ficar claras para o desenvolvimento do plano de

implementação do Gerenciamento da Configuração (MAGALHÃES, 2007):

� A estratégia, os objetivos, o escopo e a política do Gerenciamento da Configuração

devem ser definidas;

� As políticas e os procedimentos do Gerenciamento da Configuração devem estar

relacionados ao Gerenciamento da Liberação e da Mudança;

� Análise do ambiente organizacional, tanto no âmbito técnico como gerencial, para

definir os processos do Gerenciamento da Configuração;

� A definição das ferramentas, responsabilidades, papeis e procedimentos;

� Planejamento da carga inicial de dados na base de dados de Gerenciamento da

Configuração;

� Definição dos tipos de CIs, de atributos e de relacionamentos;

A população de um CMDB pode ser feita de forma gradual, o que exigirá um controle

maior por parte da equipe de TI, onde caso um CI que já tenha sido inventariado seja

61

modificado, as alterações efetuadas deverão ser replicadas no CMDB. Além disso, o DSL

deve ser implementado em paralelo pelo Gerenciamento de Liberação, pois os códigos das

licenças serão armazenadas no CMDB (OGC, 2000).

2.2.6.3 Atividades

As atividades que compõem o processo de Gerenciamento da Configuração são

(MAGALHÃES, 2007):

� Planejamento;

� Identificação;

� Controle;

� Verificação e auditoria;

� Geração de informações.

• Planejamento

A atividade de planejamento define a abrangência, os fatores críticos de sucesso, o

escopo, os objetivos e os indicadores de desempenho que deverão ser conquistados pela

equipe de TI. Para poder avaliar os resultados é recomendado a definição de pontos de

verificação (checkpoint) dessa forma é possível obter ganhos rápidos (MAGALHÃES, 2007).

Cada ponto de verificação deve ser comparado com a situação atual, e os problemas

encontrados devem ser reparados (OGC, 2000).

• Identificação

A atividade de identificação das configurações dos CIs inicia a partir do que foi

definido na atividade de planejamento. Com o detalhamento do CI efetuado, é possível ter o

controle eficaz das instalações, verificações, distribuição, manutenção e liberação de

62

atualizações (OGC, 2000). O escopo dos tipos de CIs que devem ser considerados são

(MAGALHÃES, 2007):

� Hardware;

� Software (aplicativos, sistema operacional, drives, sistemas do negócio, sistemas de

banco de dados, entre outros);

� Bancos de dados físicos;

� Ambientes;

� Relacionamento entre banco de dados, aplicações e link entre sistemas;

� Documentações (licenças, manuais, contratos, acordos de níveis de serviço,

processos, entre outros);

� Usuários e fornecedores;

� Planos de capacidade e contingência;

� Incidentes, problemas e erros conhecidos;

� Requisição de Mudança (RFC).

O critério para a decomposição (granularidade) de cada CI irá depender do tipo do CI

e das necessidades do negócio. A Figura 16 exemplifica uma estrutura de configuração (OGC,

2000).

Figura 16: Exemplo de estrutura de configuração (OGC, 2000, p. 137).

O excesso de dados poderá gerar um grande trabalho e pouca informação útil,

deixando em descrédito os dados coletados (OGC, 2000). Uma recomendação é planejar

Infraestrutura de T I

Aplicativos Documentação

Sistemas do negócio Sistemas do negócio

Aplicativo 1-1 Aplicativo 1-2

Módulo 1-2-1 Módulo 1-2-2

Equipamentos Rede

Aplicativo 1-3

63

como será o detalhamento dos CIs, e a medida que o processo amadurecer irão surgir novas

necessidades de detalhamento. Definir o planejamento para detalhar o nível mais baixo é

complicado e poderá ser necessário a ajuda externa (MAGALHÃES, 2007).

Como mostra a Figura 16 um mesmo CI (filho) pode atender a mais de um CI (pai),

diminuindo assim o número de relações. Cada CI deve ser classificado com um tipo definido

para facilitar a identificação e documentação. Por exemplo: desktop, servidor, notebook, hub,

switch, sistema operacional. (OGC, 2000).

Os atributos devem ser planejados para cada tipo de CI. Sendo assim, determinado

atributo pode não ser utilizado por todos os CIs. O Quadro 09 sugere uma lista de atributos,

contudo, note que alguns atributos de CI de hardware não são utilizados por CI de software.

Atributos Descrição Nome do CI Único nome na qual o CI é conhecido Número da cópia ou serial Número que identifica a instância do CI. Por exemplo: número de cópias

do software ou o número serial de um hardware. Categoria Classificação do CI Tipo Descrição do tipo do CI. Amplia a abrangência do item “categoria”. Modelo (Hardware) Modelo do CI. Por exemplo: Dell modelo xxx, PC/a modelo yyy Data que expira a garantia Data quando o fornecedor não fornecerá mais a garantia do CI. Versão Número de versão do CI Localização Descrição do local de armazenamento físico do CI. Responsável Nome do responsável pelo CI. Data da responsabilidade Data quando o responsável passou a assumir o CI. Origem/Fornecedor Origem do CI. Por exemplo: desenvolvido internamente, nome do

fornecedor. Licença Número da licença do CI. Data aquisição Data quando o CI foi comprado. Data do aceite Data quando o CI foi aceito para o ambiente de produção Estado atual Estado atual do CI. Por exemplo: Teste, Produção, Eliminado, etc. Estado futuro Próximo estado que o CI estará conforme agenda prévia. Relacionamento(s) (pai) Relacionamento(s) de nível superior referente ao CI. Relacionamento(s) (filho) Relacionamento(s) de nível inferior referente ao CI. Relacionamentos Todos os relacionamentos que o CI possui. Numero de RFCs Número total de RFCs que já afetaram o CI. Número de mudanças Número total de mudanças que já afetaram o CI. Número de problemas Número total de problemas que já afetaram o CI. Número de incidentes Número total de incidentes que já afetaram o CI. Comentários Campo livre para comentários.

Quadro 09: Sugestão de atributos (OGC, 2000, p. 163).

Alguns atributos devem ser revistos, pois a cada interação entre os demais processos

da ITIL algum atributo pode ser alterado. Por exemplo: Número de RFC, mudanças,

problemas e incidentes (OGC, 2000).

64

O ciclo de vida de um IC deve ser definido a cada estágio. Isso pode variar para cada

processo (Gerenciamento de Liberação, Gerenciamento de Mudança, ...). A Figura 17

demonstra os estágios do ciclo de vida de um CI (OGC, 2000).

Figura 17: Exemplo do ciclo de vida de um CI (OGC, 2000, p. 139).

O relacionamento entre CIs deve ser registrado no CMDB para poder determinar a

dependência entre eles. Existem várias formas de se relacionar, sendo elas:

� Um CI é parte de outro CI (Ex.: Um módulo de faturamento é parte de um sistema

de gestão);

� Um CI está conectado a outro CI (Ex.: Um monitor está conectado a uma CPU -

central única de processamento);

� Um CI usa outro CI (Ex.: Um desktop usa um software livre qualquer);

É importante que sejam definidas as nomenclaturas padrões para os CIs, onde através

de alguma padronização da nomenclatura esses CIs possam ser identificados (MAGALHÃES,

2007) . A nomenclatura utilizada para identificar se o CI é muito importante, pois será de fácil

e rápido entendimento. Junto a isso é importante que os hardwares possam ser identificados

com uma etiqueta (não removível) que informe o seu código único (OGC, 2000).

• Controle

A atividade de controle deve assegurar que nenhum CI seja manipulado sem que haja

uma documentação. Através dessa documentação é possível determinar a inclusão,

modificação, realocação ou eliminação de um CI (OCG, 2000). A atividade de controle possui

os seguintes procedimentos (MAGALHÃES, 2007):

� Registro dos novos itens de configuração e atualizações de versão dos mesmos;

� Registros das melhorias dos softwares desenvolvidos internamente;

Aceito Removido Instalado Registrado


Gerenciamento de liberação


65

� Controle das licenças dos softwares adquiridos;

� Manutenção das informações dos CI de forma íntegra e dos serviços de TI;

� Atualização do CMDB;

� Garantia que somente os CI autorizados estejam no ambiente de produção.

• Verificação e auditoria

A atividade de verificação e auditoria é destinada a avaliar se as informações contidas

no CMDB (inclusive as documentações) estão replicadas no ambiente de produção

(MAGALHÃES, 2007). Essa atividade inclui ainda a verificação das informações e

procedimentos no CI antes que o mesmo seja inserido no ambiente de produção (OGC, 2000).

É recomendado que seja efetuado periodicamente uma auditoria para atestar que o CI

esteja presente e em operação no ambiente. Dessa forma haverá uma garantia que a

informação contida no CMDB condiz com a realidade (MAGALHÃES, 2007). Se exceções

forem encontradas no ambiente de produção em relação ao CMDB, deve ser iniciado o

processo de mudança para normalizar a situação e o Gerenciamento da Configuração deverá

instaurar um inquérito para avaliar a origem do problema. A Central de Serviços deve ser

instruída para avaliar periodicamente se o CI está conforme com as informações do CMDB

(OGC, 2000).

• Geração de informações

A atividade de geração de informações compreende a geração de relatórios referentes

aos indicadores para informar a gestão de TI e a organização, sobre os CIs e seus

relacionamentos com os demais processos (MAGALHÃES, 2007).

Esses relatórios referentes ao Gerenciamento da Configuração deverão abranger as

seguintes informações (OGC, 2000):

66

� Resultados das auditorias de configuração;

� Informações sobre os CIs mal registrados ou não cadastrados e as medidas

corretivas;

� Informações sobre o número de CIs cadastrados e suas versões, discriminando por

categoria de tipo e status (e se possível também pela localização ou outros

atributos);

� Crescimento e capacidade de armazenamento das informações;

� Informações sobre o número de mudanças dos CIs/CMDB e da DSL;

� Detalhes referentes aos atrasos gerados pelo Gerenciamento da Configuração e as

medidas para solucioná-los;

� Posição sobre a equipe do Gerenciamento da Configuração;

� Total de horas trabalhadas em atendimentos autorizados e outros serviços TI;

� Resultados comentados sobre a eficiência/eficácia, o crescimento, as auditorias no

CMDB e propostas para o tratamento dos problemas atuais ou potenciais;

� Análises sobre o número de CIs por tipo como serviços, servidores, roteadores,

hubs, licenças, computadores individuais, entre outros;

� O valor dos CIs (ou dos ativos);

� A localização dos CIs na organização.

2.2.6.4 Relacionamento entre processos

O Gerenciamento da Configuração possui um relacionamento com os seguintes

processos: Gerenciamento de Liberação, Gerenciamento de Mudança, Gerenciamento de

Problema, Gerenciamento de Incidente e a função Central de Serviços.

67

A Figura 18 demonstra claramente o relacionamento entre o Gerenciamento da

Configuração e os demais processos.

Figura 18: Relacionamento do CMDB com o Gerenciamento de Incidente, Problema, Mudança e Liberação

(OGC, 2000, p. 151).

68

Contudo, o relacionamento entre o Gerenciamento de Liberação, Gerenciamento de

Mudança e o Gerenciamento da Configuração é mais estreita que entre os demais. Pois O

Gerenciamento de Liberação e Mudança alteram as configurações dos CIs cadastrados no

CMDB. A Figura 19 demonstra claramente esse relacionamento.

Figura 19: Relacionamento entre o Gerenciamento da Configuração e o Gerenciamento de Mudança e

Liberação (OGC, 2000, p. 151).

2.2.6.5 Sistema de Gerenciamento da Configuração

O Gerenciamento da Configuração pode ser muito complexo dependendo do tamanho

da organização. Por isso um sistema que armazene as informações detalhadas dos CIs e a

relação entre eles poderá auxiliar nessa gestão. Além de armazenar informações sobre os CIs,

o sistema deverá arquivar informações sobre os demais processos como: incidentes e

69

problemas ocorridos, mudanças autorizadas ou não e o processo de implementação da

liberação (OGC, 2000).

O sistema de Gerenciamento da Configuração deve prever (OGC, 2000):

� Controles de segurança para limitar o acesso conforme a necessidade do

conhecimento;

� Suporte as diversas complexidades dos CIs.Por exemplo: controle das liberações de

hardware/software, relacionamento entre os CIs, nível hierárquico entre os CIs e

ferramentas para avaliar o impacto de uma RFC;

� Facilidade para incluir e excluir um CI;

� Validações automáticas das informações inclusas (por exemplo: identificação única

para os CIs.);

� Atualizações automáticas dos relacionamentos que possam existir quando um CI é

adicionado;

� Suporte aos CIs que possuírem diferentes números de modelos, versões e cópias;

� Identificação automática de incidentes, problemas, erros conhecidos ou RFCs de

outros CIs já afetados com o mesmo ou similar assunto;

� Integração do Gerenciamento de Problema com o CMDB, ou pelo menos um

interface entre os sistemas do Gerenciamento de Problema e o Gerenciamento da

Configuração;

� Atualização automática do número de versão do CI e de seus componentes quando

alterado;

� Manutenção do histórico de todos os CIs (data das instalações, registro das

mudanças, localizações, etc.);

� Suporte para o uso e gerenciamento das informações padronizadas, incluindo o

controle de versão;

� Facilidade para análise da tendência (por exemplo: identificação do número de

RFCs afetam CIs em particular)

� Relatórios para ajudar no inventário e auditoria dos CIs;

� Ferramenta de relatório flexível para auxiliar na análise de impacto;

70

� Capacidade de demonstrar graficamente a configuração ou a rede de

relacionamento dos CIs;

� Capacidade de demonstrar a hierarquia das relações entre os CIs 'pais' e CIs

'filhos'.





Eficiência Índice de atualização dos dados relativos aos CIs armazenados no CMDB. Índice de alterações no CMDB devido a erros encontrados nos próprios dados armazenados.

Eficácia Índice de RFC não atendidas devido à falta ou inconsistência dos dados armazenados no CMDB. Índice de disponibilidade do CMDB.

Efetividade Índice de “não-conformidades” relativas ao Gerenciamento da Configuração encontradas em processos de auditoria da área de TI e da organização. Índice de CIs em uso sem autorização.

Economicidade Índice de licenças de software registradas no CMDB sem utilização. Índice de evolução do custo médio por solicitação de alteração no CMDB.


2.3 SOFTWARE LIVRE

Software livre (aplicativo livre) segundo Hexsel (2003):

é definido como o software cujo autor o distribui e outorga a todos a liberdade de uso, cópia, alteração e redistribuição de sua obra. A liberdade de uso e alteração somente é viabilizada pela distribuição dos programas na forma de texto legível por humanos, isto é, com seu código fonte, bem como no formato executável por um computador.

71

2.3.1 Histórico

O conceito de Software livre tem origem na década de 60 onde a IBM vendia os seus

computadores e junto entregava os softwares instalados com os códigos fontes (HEXSEL,

2003). Ainda na mesma década, diversas empresas e instituições desenvolviam aplicações de

forma colaborativa e aberta (LEVY, 1994); um exemplo disso é o Unix (MCKUSICK, 1999).

Na década de 70 as empresas passaram a comercializar os aplicativos sem os códigos fontes,

devido aumento de usuários (HEXSEL, 2003).

Na década de 80 as licenças foram alteradas passando a restringir a redistribuição e a

modificação dos softwares (STALLMAN, 1999). Em contrapartida iniciou-se na mesma

década o Projeto GNU, liderado por Richard Stallman, que seria um sistema operacional com

aplicativos a serem distribuídos como softwares livres. Em 1984, o Manifesto GNU foi

publicado, por Stallman, onde se concretizou o conceito de software livre (HEXSEL, 2003).

2.3.2 Grau de restrições de licenças

A maior parte das licenças de softwares são licenças copyright, onde o autor pode

decidir qual a forma mais apropriada para explorar o trabalho criado. Na maioria das vezes

essa forma é feita através de cópias pagas com mídias tangíveis (ENGELFRIET, 2009). Por

outro lado existe a licença copyleft que garante ao usuário direitos de modificar e redistribuir

o aplicativo, mas não permite que o aplicativo seja convertido para aplicativo proprietário

(GNU, 2009).

2.3.3 Licenças de software livre

Existem diversas formas de licenças de softwares livres para a distribuição, que

distingue-se pelo grau de liberdade outorgado ao usuário. Dessas licenças destacam-se as

seguintes (HEXSEL, 2003):

72

� GPL: Licença Pública Geral GNU (General Public License - GPL) a formulação

do texto dessa licença impede que o aplicativo por ela protegido seja convertido em

aplicativo proprietário. Um exemplo da utilização dessa licença é o sistema

operacional Linux onde o núcleo desse sistema é regido por essa lei;

� Debian: Essa licença também é conhecida como Debian Free Software Guidelines

(DFSG) é parte do contrato social entre a Debian e a comunidade de usuários de

aplicativo livre. O texto dessa licença possui critérios que exigem a publicação do

código fonte;

� Open Source: Essa licença de código aberto (Open Source Initiative) é uma

variação da licença Debian, mas sem as menções a Debian;

� BSD: Licença Berkeley Software Distribution - BSD é considerada "permissiva",

pois em seu texto não há garantias que o código fonte será entregue junto com o

aplicativo e também não impede que o aplicativo livre seja convertido em

aplicativo proprietário;

� X.org: Licença que pode até determinar que um aplicativo é livre, mas não está nos

moldes do copyleft. O Consórcio X, que distribui o X Windows System, possui

distribuições livres e também não livres;

� Software em Domínio Público: São aplicativos sem copyright, mas pode haver

restrições conforme a solicitação do autor;

� Software semi-livre: São aplicativos que podem ser utilizados, copiados,

modificados, mas sem fins lucrativos;

� Freeware: São aplicativos não livres, pois não possuem o código fonte e nem há a

permissão de modificá-lo somente distribuí-lo e utilizá-lo;

� Shareware: São aplicativos que tem a permissão para distribuí-los, mas a sua

utilização implica na compra da licença de uso.

73

3 O ESTUDO DE CASO PROPOSTO

O objetivo deste capítulo é apresentar de que forma as ferramentas que possuem

licença de Software Livre foram selecionadas. Como foi elaborado o método proposto para a

avaliação dos softwares selecionados e o resultado da aplicação do método.

3.1 METODOLOGIA

Para selecionar as ferramentas, foi avaliada uma forma de obter essa informação

através da Internet, contudo não foi possível atribuir certa credibilidade no que se refere à

coleta destes dados para a efetivação de uma pesquisa acadêmica. Sendo assim foram

entrevistadas cinco pessoas que possuem influência com gestores da tecnologia da informação

na região da grande Porto Alegre (estado do Rio Grande do Sul). Essa entrevista ocorreu por

e-mail onde os entrevistados foram questionados sobre: “Quais os Softwares Livres, que

tratam sobre ITIL, você indicaria a seus clientes?”. Dessas cinco pessoas três responderam a

pesquisa o que resultou na seleção das seguintes ferramentas: OcoMon, Spiceworks e OTRS.

O método de avaliação das ferramentas é baseado numa lista de avaliação (Checklist)

onde a base para a elaboração das questões encontra-se no referencial teórico, sobre a ITIL 2º

versão, descrita neste trabalho. As questões elaboradas foram baseadas em conceitos mais

relevantes ao referencial proposto. Demais sugestões para as questões, que estivessem de

acordo com o referencial proposto, foram obtidas no site da Pink Elephant (PINK, 2009).

Esse Checklist é composto por cento e quarenta e três questões divididas em sete

categorias conforme demonstrado no quadro 11.

Categoria Número de questões Central de serviços 14 Gerenciamento de Incidente 31 Gerenciamento de Problema 20 Gerenciamento de Mudança 29 Gerenciamento de Liberação 20 Gerenciamento da Configuração 24 Considerações do autor 5

Quadro 11: Categoria x número de questões (Autor).

O resultado de cada ferramenta teve como base as respostas afirmativas das questões

do método proposto (Quadro 12). O software OcoMon foi avaliado através de uma

74

demonstração da ferramenta disponível no site do fabricante. Os demais softwares tiveram

que ser instalados, a fim de, poder utilizar todos os recursos disponíveis das ferramentas.

Cen

tral

de

Ser

viço

s

Nº Validação

1º A ferramenta permite visualizar as informações detalhadas de um ou mais CIs no registro do chamado?

2º A ferramenta facilita a disseminação de informações para os usuários? Por exemplo: uma tela para que os usuários possam conferir o estado de seus chamados ou a indisponibilidade de um serviço.

3º A ferramenta permite definir códigos que categorizam termos referentes ao que foi afetado nos serviços ou nos CIs?

4º A ferramenta permite acessar a máquina do usuário através da tela do chamado?

5º A ferramenta permite anexar arquivos ao chamado? 6º A ferramenta permite visualizar informações sobre o solicitante do chamado?

7º A ferramenta permite ao atendente a visualização do andamento dos chamados? Por exemplo: consultar em que estágio está o chamado.

8º A ferramenta permite uma classificação inicial de impacto e urgência dos incidentes?

9º A ferramenta permite a solução do chamado pela Central de Serviços? 10º A ferramenta permite o encerramento dos chamados pela Central de Serviços? 11º A ferramenta permite desenvolver uma pesquisa de satisfação do usuário?

12º A ferramenta permite a localização dos erros conhecidos relacionados ao chamado?

13º A ferramenta facilita a visualização da agenda de mudanças?

14º A ferramenta permite que a central de serviços comunique informações sobre mudanças para um grupo de usuários? Por exemplo: o uso de correio eletrônico para informar sobre a mudança.

Ger

enci

amen

to d

e In

cide

nte

15º A ferramenta facilita a inclusão, alteração e fechamento de um registro de incidente?

16º A ferramenta permite a digitação de texto livre para descrever o incidente e a resolução do mesmo?

17º A ferramenta obriga à digitação no registro do incidente a data, hora e o número do incidente?

18º A ferramenta permite cadastrar as ações tomadas durante o processo de resolução do incidente?

19º A ferramenta restringe a inclusão, modificação e fechamento de um registro de incidente as pessoas autorizadas?

20º A ferramenta registra e classifica automaticamente um incidente?

21º A ferramenta permite classificar o impacto e a urgência para os registros de incidentes?

22º A ferramenta atribui de forma automática a prioridade, o escalonamento e o responsável por resolver o incidente conforme a categoria do registro?

23º A ferramenta prioriza automaticamente os registros de incidentes conforme o impacto e a urgência informados?

24º A ferramenta permite priorizar o registro do incidente de forma manual?

25º A ferramenta facilita a definição de prioridade para diversos incidentes num mesmo comando?

Continua

75

Continuação G

eren

ciam

ento

de

Inci

dent

e Nº Validação

26º A ferramenta permite editar a decisão dos indicadores de impacto e urgência para classificar o registro de um incidente?

27º A ferramenta permite incrementar de forma automática a urgência ou impacto com relação ao número de incidentes associados e/ou os números de usuários afetados?

28º A ferramenta facilita a personalização de faixas de tempo para determinar o escalonamento automático do registro do incidente?

29º A ferramenta permite escalonar para um prestador de serviços o chamado?

30º A ferramenta facilita o escalonamento do registro de incidente para o registro de problemas?

31º A ferramenta permite o escalonamento automático conforme o número de usuários afetados?

32º A ferramenta permite direcionar, conforme o assunto, os registros de incidente, alertando, quando necessário, o grupo de suporte?

33º A ferramenta facilita visualizar o andamento do registro do incidente? Por exemplo: ver o responsável pela resolução do incidente e o estado atual do mesmo.

34º A ferramenta salva o histórico dos erros conhecidos? 35º A ferramenta salva o histórico dos incidentes?

36º A ferramenta facilita o fechamento dos incidentes utilizando códigos de fechamento personalizáveis?

37º A ferramenta facilita o fechamento de todos os incidentes quando relacionado a um problema ou erro conhecido já resolvido?

38º A ferramenta facilita a procura por incidentes fechados?

39º A ferramenta facilita localizar os problemas encerrados relacionados ao incidente atual?

40º A ferramenta facilita o uso da base de conhecimento ou roteiros de suporte para diagnosticar e resolver o incidente?

41º A ferramenta facilita a manutenção do relacionamento entre o registro de incidente, erro conhecido ou problema?

42º A ferramenta permite o acesso às informações, do Gerenciamento de Mudança, de forma segura e controlada referente ao agendamento de mudanças e ao histórico de mudanças?

43º Dependendo da resolução encontrada a ferramenta permite submeter o incidente ao Gerenciamento de Mudanças?

44º A ferramenta facilita a integração das informações do CMDB com o registro do incidente?

45º A ferramenta após a inclusão do registro do incidente o estado do CI é alterado?

46º A ferramenta facilita a inclusão, alteração e fechamento de um registro de problema?

47º A ferramenta permite incluir automaticamente um registro de problema? Por exemplo: via e-mail, mensagem de voz, através de uma ferramenta de monitoramento.

48º A ferramenta permite a digitação de texto livre para descrever o problema e a resolução do mesmo?

Continua

76

Continuação Nº Validação

Ger

enci

amen

to d

e P

robl

ema

49º A ferramenta permite cadastrar as ações tomadas durante o processo de resolução do problema?

50º A ferramenta facilita a associação e manutenção entre um ou mais registros de incidentes ao registro do problema?

51º A ferramenta distingue um problema de um incidente ou erro conhecido?

52º A ferramenta distingue automaticamente um problema de um incidente ou erro conhecido?

53º A ferramenta permite a geração de uma solução de contorno (Workaround) para atender de forma temporária o problema e remeter à informação a central de serviços?

54º A ferramenta permita cadastrar o erro conhecido informando o sintoma, a causa, as ações tomadas e a resolução?

55º A ferramenta permite classificar o impacto e a urgência para os registros de problemas?

56º A ferramenta permite direcionar os registros de problemas para o suporte pré definido?

57º A ferramenta permite escalonar o problema depois de ultrapassar o tempo estabelecido?

58º A ferramenta alerta automaticamente o gerente de problemas sobre um problema que ultrapassou o limite de risco?

59º A ferramenta permite a análise de tendência dos incidentes com base nos chamados?

60º A ferramenta identifica que um CI esta num estado crítico e precisa ser atendido rapidamente?

61º A ferramenta facilita o Gerenciamento de Problema proativo, onde identifica na infraestrutura quais os CIs que possam estar instáveis ou serem possíveis problemas?

62º A ferramenta facilita visualizar o andamento do registro do problema? Por exemplo: ver o responsável pela resolução do problema e o estado atual do mesmo.

63º A ferramenta salva o histórico dos problemas e erros conhecidos para ser acessado pela equipe de suporte?

64º A ferramenta permite acesso aos detalhes do CI pelo registro do problema? 65º A ferramenta altera o estado do CI após a inclusão do registro do problema?

Ger

enci

amen

to d

e M

udan

ça

66º A ferramenta facilita o registro das RFCs de forma fácil e acessível? 67º A ferramenta permite a entrada de texto livre para descrever o motivo da RFC?

68º A ferramenta permite a utilização de códigos para as RFCs para identificar as RFCs?

69º A ferramenta permite classificar a prioridade das RFCs? Por exemplo: urgente, alta, média e baixa

70º A ferramenta permite classificar a categoria das RFCs? Por exemplo: baixo impacto, impacto significativo e alto impacto.

71º A ferramenta permite a adição de mais de um CI a RFC? Continua

77

Continuação G

eren

ciam

ento

de

Mud

ança

Nº Validação

72º A ferramenta apoia o gerenciamento do ciclo de vida da RFC? Por exemplo: Registrada, avaliada, rejeitada, aceita e aguardando.

73º A ferramenta facilita a gravação de procedimentos no registro de mudança?

74º A ferramenta permite que o solicitante tenha a possibilidade de responder uma RFC que foi rejeitada?

75º A ferramenta permite informar o motivo da falha da execução da RFC? 76º A ferramenta permite que somente pessoas autorizadas possam emitir RFCs?

77º A ferramenta possibilita o controle de acesso a leitura e escrita das mudanças, bem como o ciclo de vidas das mesmas?

78º A ferramenta permite monitorar e acompanhar o ciclo de vida de uma requisição de mudança? Por exemplo: acompanhar a mudança através de diferentes estágios de autorização, coordenação e revisão.

79º A ferramenta facilita o registro do estado dos CI quando a mudança é proposta, autorizada e implementada? Por exemplo: Natureza da mudança, estado futuro, data prevista da mudança.

80º A ferramenta facilita a tarefa de atualizar as informações dos CIs no CMDB? Por exemplo: deixar pré agendado quais CIs serão alterados quando a mudança ocorrer com sucesso.

81º

A ferramenta permite acesso aos detalhes dos CIs para auxiliar no processo de autorização de mudança? Por exemplo: possibilitar a visualização os relacionamentos do CI, a fim de, avaliar o impacto que pode ocorrer à mudança.

82º A ferramenta facilita a avaliação e aprovação dos pedidos de mudanças para os CIs afetados? Por exemplo: na tela de cadastro de CI é possível autorizar um pedido de mudança.

83º A ferramenta facilita a identificação de diferentes RFCs para o mesmo CI?

84º A ferramenta facilita o armazenamento de informações do presente, passado e futuro sobre as mudanças para facilitar o processo de Gerenciamento de Problema?

85º A ferramenta facilita o encaminhamento das RFCs para a aprovação como definido no processo de Gerenciamento de Mudança da ITIL? Por exemplo: 1º Gerente de mudança, 2º CAB, 3º Gerente de TI

86º A ferramenta possibilita rejeitar uma mudança? Por exemplo: informar o motivo pela qual a mudança teria sido rejeitada e notificar a central de serviços e o usuário final.

87º A ferramenta possibilita registrar a avaliação de impacto referente à mudança para apoiar a autorização de mudança? Por exemplo: anexos de laudos técnicos e relatórios.

88º A ferramenta facilita organização da agenda de mudanças? Por exemplo: agendamentos de desenvolvimento, testes e implementações de mudanças.

89º A ferramenta possibilita que o Gerenciamento de Mudança audite uma liberação implementada?

90º A ferramenta possibilita o agendamento para auditar as mudanças já implementadas?

91º No caso de uma mudança executada com sucesso a ferramenta permite o fechamento automático dos registros que foram associados a RFC?

Continua

78

Continuação

Nº Validação

92º A ferramenta facilita a associação e manutenção entre o erro conhecido e as RFCs? Por exemplo, um erro conhecido pode atender uma ou mais RFCs ou vice versa.

93º A ferramenta estabelece uma associação entre o problema identificado, o erro conhecido e a mudança?

94º A ferramenta permite avaliar o impacto e os recursos requeridos para demonstrar o investimento necessário para a organização? Por exemplo: o investimento de implementar o processo de Gerenciamento de Incidente.

95º A ferramenta possibilita avaliar o impacto do pós implantação e os recursos utilizados pela mudança? Por exemplo: resultados referentes ao previsto x realizado das mudanças ocorridas.

Ger

enci

amen

to d

e Li

bera

ção

96º A ferramenta facilita o planejamento, a administração, a documentação dos procedimentos de implantação?

97º A ferramenta facilita o registro dos recursos necessários para efetuar a mudança?

98º A ferramenta permite o desenvolvimento do plano de retorno (back-out) a situação original em caso de falha?

99º A ferramenta facilita o acesso às informações do CMDB para o desenvolvimento das liberações, distribuições e implementações? Por exemplo: saber qual é o sistema operacional utilizado na infra estrutura de TI atualmente.

100º A ferramenta permite definir as versões para os tipos de liberação?

101º A ferramenta permite definir as versões para os itens que o compõem os tipos de liberação?

102º A ferramenta facilita o arquivamento das substituições de versão dos aplicativos?

103º A ferramenta facilita o desenvolvimento de diferentes tipos de liberação? Por exemplo: Full Release, Delta Release e Package Release.

104º A ferramenta facilita a criação de pacotes de liberação contendo todos os aspectos: Hardware, Software e documentação dos CIs?

105º A ferramenta consegue avaliar o tamanho e o tempo de implementação das liberações?

106º

A ferramenta facilita a distribuição e implementação das liberações de softwares automaticamente nos computadores dos usuários? Por exemplo: uma atualização do sistema operacional onde é instalado em várias máquinas ao mesmo tempo.

107º A ferramenta permite o desenvolvimento do plano de treinamento após a mudança implementada?

108º A ferramenta permite a criação dos boletins técnicos para as mudanças implementadas?

109º A ferramenta facilita a tarefa de auditar uma aplicação? Por exemplo: avaliar se nenhuma aplicação foi instalada sem autorização.

110º A ferramenta incorpora a criação e gerenciamento de um DSL? 111º A ferramenta provê controle de acesso ao conteúdo do DSL?

112º A ferramenta facilita o gerenciamento das licenças dos aplicativos? Por exemplo: avaliar o nº de licenças x nº de licenças instaladas.

Continua

79

Continuação

Nº Validação

113º A ferramenta facilita a autorização e o agendamento do desenvolvimento da liberação em conjunto com o processo de Gerenciamento de Mudança?

114º A ferramenta facilita coordenação da execução dos testes de liberação de pacotes? Por exemplo: testes funcionais e operacionais

Ger

enci

amen

to d

a C

onfig

uraç

ão

115º A ferramenta permite cadastrar os tipos de CIs existentes? Por exemplo: hardware, software, contratos (SLA).

116º A ferramenta possui atributos diferenciados a cada tipo de CI?

117º A ferramenta facilita o registro, a gestão e a organização dos itens de configuração (CIs)?

118º A ferramenta facilita a gravação dos atributos dos CIs? Por exemplo: número serial, versão e localização do CI.

119º A ferramenta facilita a atualização dos atributos dos CIs? Por exemplo: trocar a capacidade de armazenamento em disco de um ou mais CIs.

120º A ferramenta facilita a validação das informações do CI? Por exemplo: todos os CI possuem nomes únicos?

121º A ferramenta permite adicionar arquivos as configurações dos CIs? Por exemplo: adicionar o manual de instalação.

122º A ferramenta possibilita salvar as parametrizações dos CIs? Por exemplo: possibilidade de retornar ao estado inicial de um CI depois de uma mudança mal sucedida.

123º A ferramenta facilita o cadastramento do relacionamento entre os CIs? Por exemplo: pai/filho; antecessor/predecessor.

124º A ferramenta possibilita a personalização dos relacionamentos entre os CIs para atender as necessidades do negócio?

125º A ferramenta exibe de forma gráfica o relacionamento entre os CIs?

126º A ferramenta facilita, de forma automática, o relacionamento entre pai e filho quando um CI é incluso, modificado ou excluído?

127º A ferramenta apoia o gerenciamento do ciclo de vida do CI? Por exemplo: Planejado, Ordenado, Em desenvolvimento, Em testes, Implementado, Produção, Reparos/manutenção.

128º A ferramenta permite definir o local onde o CI foi descartado? Por exemplo: quando o estado do ciclo de vida dele for "removido" o sistema solicita o local de descarte.

129º A ferramenta controla o acesso ao CMDB conforme autorização cadastrada? Por exemplo: acesso a leitura, escrita, modificação.

130º A ferramenta possibilita a gravação do histórico de mudanças de um CI para uma auditoria? Por exemplo: data da instalação, modificações ocorridas, localização anterior.

131º A ferramenta facilita a verificação das informações do CI em comparação com a infraestrutura atual? Por exemplo: um sistema que verificasse automaticamente a configuração atual do CI em comparação com o CMDB.

Continua

80

Continuação G

eren

ciam

ento

da

Con

figur

ação

Nº Validação

132º A ferramenta cadastra automaticamente, através da rede, os IC que estão conectados?

133º A ferramenta facilita o agendamento de auditorias da configuração?

134º A ferramenta provê relatórios flexíveis sobre os CIs? Por exemplo: Inventário, informações financeiras e para auditorias.

135º A ferramenta facilita a visualização das informações dos registros de incidentes com o CMDB?

136º A ferramenta facilita a visualização das informações dos registros de problemas com o CMDB?

137º A ferramenta facilita a visualização das informações dos erros conhecidos com o CMDB?

138º A ferramenta facilita a visualização das informações das RFCs com o CMDB?

Con

side

raçõ

es d

o A

utor

139º A ferramenta permite a personalização de relatórios? Por exemplo: capacidade de construir ou modificar um relatório.

140º A ferramenta possui cadastro de usuários?

141º A ferramenta possui com controle de acesso ao sistema conforme as permissões do usuário?

142º Ferramenta permite cadastrar roteiros de suporte? 143º A ferramenta permite criar campos personalizáveis?

Quadro 12: Lista de avaliação dos softwares (Autor).

3.2 FERRAMENTAS SELECIONADAS

Esse sub-capítulo apresenta uma contextualização sobre as ferramentas selecionadas,

onde será tratado assuntos sobre o histórico do software, os requisitos de hardware, a

linguagem de programação, dentre outros.

3.2.1 OcoMon

A ferramenta OcoMon tem como seu idealizador Flávio Ribeiro da universidade

Unilasalle. A ferramenta é regida pela licença GPL e as linguagens com as quais foi

desenvolvida são: PHP (versão 4.3x), HTML, CSS e Javascript. A versão 1.0 foi

disponibilizada em Abril de 2002 junto com o site oficial, atualmente o Software está na

versão 2.0RC5. O idioma padrão da ferramenta é o Português - Brasil.

Os requisitos para a utilização dessa ferramenta são:

81

� Sistema operacional: Independente;

� Servidor Web: Apache;

� Banco de dados: MySQL versão 4.1x ou superior;

� Navegador: Mozilla Firefox ou Internet Explorer.

Algumas empresas já utilizam essa ferramenta são elas: Unilasalle, UniRitter, Instituto

Adolfo Lutz, Grupo Brasilcred entre outros (OCOMON, 2009).

3.2.2 Spiceworks

A ferramenta Spiceworks foi idealizada por Scott Abel, Jay Hallberg, Francis Sullivan

e Greg Kattawar no estado do Texas. Essa ferramenta é livre, porém é mantida por uma

empresa privada onde o lucro está voltado às propagandas que a ferramenta anuncia. Ela foi

lançada em Maio de 2006 e a linguagem de desenvolvimento é baseado em Javascript o que

permite que usuários possam desenvolver novos recursos. O idioma padrão da ferramenta é o

Inglês, contudo existe um recurso desenvolvido por terceiros que possibilita alterar o idioma

para o Português - Brasil, porém esse recurso não traduz a toda a ferramenta, somente a tela

de chamados onde o usuário descreve a solicitação.

Os requisitos para a utilização dessa ferramenta são:

� Sistema operacional: Windows XP ou superior;

� Processador: Pentium III com 1GHz;

� Memória RAM: 1GB;

� Navegador: Mozilla Firefox 2.0 até 3.5 ou Internet Explorer 7.0 até 8.0.

Atualmente a ferramenta é utilizada por 250.000 usuários em todo o mundo

(SPICEWORKS, 2009).

82

3.2.3 OTRS

A ferramenta OTRS (Open Ticket Request System) foi idealizada por Martin Edenhofer

e Sebastian Wormser no ano de 2001. A ideia deles na época era desenvolver somente um

software para o controle de chamados. A licença que regula o mesmo é GPL e a linguagem de

desenvolvimento é Perl 5.8.8 (ou superior) o que possibilita a adição de novos recursos a

critério do usuário. O idioma padrão é o Inglês, mas existem outros 26 idiomas incluindo o

Português - Brasil.

Na instalação padrão da ferramenta é somente a abertura de chamados, mas no site há

a possibilidade de adicionar recursos do tipo: gerenciamento de perguntas e respostas

frequentes, gerenciamento da configuração, controle de agenda, gerenciamento de níveis de

serviço, gerenciamento de problema/incidente, gerenciamento de e-mail dentre outros.

Os recursos para a utilização dessa ferramenta são:

� Sistema operacional: Unix (Red Hat, SUSE, Debian, Fedora, Gentoo, Open BSD ou

FreeBSD), Windows 2000 ou superior ou MacOS X versão 10.x;

� Processador: 2 GHz Intel® Core 2 Duo;

� Memória RAM: 2GB;

� Espaço em disco rígido: 160GB;

� Banco de dados: MySQL versão 4.1x ou superior, MS SQL versão 2000 ou superior,

PostgreSQL versão 8.0 ou superior, Oracle 10g ou superior ou DB2 ou superior;

� Servidor de e-mail: Todos desde que utilizem os protocolos POP3, POP3S, IMAP e

IMAPS;

� Servidor Web: Apache 2 com mod_perl2 ou superior;

� Navegador: Mozilla Firefox, Internet Explorer, Opera, etc.

Esse software já foi instalado por 70.000 pessoas; dentre essas destacam-se as

seguintes empresas: NASA, NOKIA, Siemens, Toshiba, Fujitsu entre outras (OTRS, 2009).

83

3.3 ANÁLISE DAS FERRAMENTAS

A ferramenta OcoMon é a que apresentou a menor pontuação. Ela atende bem a

função Central de Serviços e parcialmente os processos Gerenciamento de Incidente e

Gerenciamento da Configuração. Os demais processos não são atendidos pela mesma.

Contudo, por ser um software livre, ele pode ser personalizado e assim ampliar o seu

escopo.

A ferramenta Spiceworks, ficou em segundo lugar, pois não atende bem o conceito

dos processos: Gerenciamento de Problema, Gerenciamento de Mudança e Gerenciamento de

Liberação. Para que esses processos sejam divididos é necessário a criação de um campo que

defina a situação do chamado.

O software OTRS é o que mais se adere aos conceitos da ITIL versão 2, referente ao

livro Suporte de Serviços. O conceito do processo Gerenciamento de Mudança não fica claro

nesta ferramenta, pois as RFCs são tratadas como um chamado comum. O mesmo vale para

os processos Gerenciamento de Incidente e Gerenciamento de Problema, onde não há uma

separação distinta entre os mesmos.

O quadro 13 demonstra os resultados obtidos das avaliações feitas nas ferramentas. O

percentual exibido está calculado em relação ao número de questões de cada categoria.

Descrição/Ferramenta OcoMon Spiceworks OTRS Central de serviços 64% 50% 71% Gerenciamento de Incidente 39% 42% 61% Gerenciamento de Problema 0% 25% 70% Gerenciamento de Mudança 0% 10% 53% Gerenciamento de Liberação 0% 16% 16% Gerenciamento da Configuração 38% 42% 46% Considerações do autor 60% 60% 60% Total 23% 31% 53%

Quadro 13: Resultados obtidos com a aplicação do método (Autor).

Conforme identificado no quadro 13, a ferramenta OTRS atendeu 53% das 143

questões descritas no checklist. O critério a ser utilizado para identificar quais os processos

que deverão ser aprofundados são os que pontuaram abaixo de 50%. Dessa forma, os

processos Gerenciamento de Liberação e Gerenciamento da Configuração serão tratados no

capítulo seguinte.

84

4 PROPOSTA DE IMPLEMENTAÇÃO

Conforme identificado no capítulo anterior, dos softwares livres analisados o OTRS foi

o que mais pontuou obtendo 53% de aproximação com os conceitos da ITIL versão 2

referente ao livro Suporte de Serviços.

Os processos que compõem o livro Suporte de Serviços são: Gerenciamento de

Incidentes, Gerenciamento de Problemas, Gerenciamento de Mudanças, Gerenciamento de

Liberação e Gerenciamento da Configuração (OGC, 2000). Destes somente dois pontuaram

abaixo de 50% sendo eles: Gerenciamento de Liberação e Gerenciamento da Configuração.

Tendo isso por base, este capítulo tem como objetivo, apresentar uma proposta de

implementação dos processos de Gerenciamento de Liberação e Gerenciamento da

Configuração com base nos itens não atendidos no método de avaliação proposto.

4.1 GERENCIAMENTO DE LIBERAÇÃO

O processo de Gerenciamento de Liberação é responsável por proteger os serviços de

TI e o ambiente de produção, através de procedimentos formais e de rotinas de testes

(MAGALHÃES, 2007). Esse processo tem como objetivos o planejamento e a supervisão das

mudanças, bem como, o desenvolvimento e a aplicação de procedimentos de implementação,

já testados, garantindo assim uma manutenção segura dos CIs. Além disso, é imprescindível o

repasse de informações ao Gerenciamento da Configuração sobre a documentação dos CIs e

os procedimentos executados (OGC, 2000).

Esse processo é dependente de informações que são repassadas pelo Gerenciamento de

Mudanças, onde as RFCs, já avaliadas pelo CAB (seção 2.2.4.2) ou CAB/EC (seção 2.2.4.3),

são repassadas ao Gerenciamento de Liberação para iniciar o planejamento da implementação

da mudança. Após esse planejamento o Gerenciamento de Mudança é informado sobre o

plano de liberação e demais informações.

85

A Figura 20, apresentada em duas partes (a, b), demonstra o diagrama de caso de uso

referente ao processo de Gerenciamento de Liberação conforme o método de avaliação

proposto.

Figura 20a: Diagrama de caso de uso representando o processo Gerenciamento de Liberação – Parte 1(Autor).

86

Figura 20b: Diagrama de caso de uso representando o processo Gerenciamento de Liberação – Parte 2(Autor).

As elipses pintadas de cinza escuro são os casos de uso que não foram atendidos pela

ferramenta. Esses casos estarão descritos nos subcapítulos seguintes.

4.1.1 Detalhamento dos casos de uso

Os casos de uso identificados no diagrama, exibido pela Figura 20, serão detalhados

baseados nas informações necessárias para o entendimento das soluções propostas. Aliado a

isso, os diagramas de atividades exibirão os passos necessários para a conclusão das

atividades. A documentação dos casos de uso está descrita no Anexo A dessa monografia.

87

4.1.1.1 UC01 - Planejar Liberação

Por ser extremamente dependente dos processos de Gerenciamento de Mudança e de

Gerenciamento da Configuração o Gerenciamento da Liberação deve ter um planejamento da

liberação, caso essas relações não ocorram. Dessa forma, o plano de liberação deve

contemplar (OGC, 2000):

� Definição de procedimentos para a liberação;

� Definição de papéis e responsabilidades para as pessoas que farão a mudança;

� Definição sobre os requisitos necessários para a aplicação da liberação;

� Preparação dos materiais de treinamento;

� Desenvolvimento de boletins técnicos explicando sobre a nova liberação;

� Agendamento em conjunto com a organização a data para as liberações de

mudanças;

� Padrões de documentação, a fim de auxiliar no planejamento das liberações;

� Políticas para o desenvolvimento de testes e planos de retorno (back-out);

� Garantir que as correções foram efetuadas;

� Garantir que existe área física para aplicar a mudança e que os testes foram

efetuados;

� Definição de como as formas de liberação (maior, menor e correções de

emergência) serão aplicadas.

A RFC, repassadas pelo Gerenciamento de Mudança, é o início de todo o processo, da

análise do plano de liberação, e a sua origem provém de diversas fontes e por diversas razões,

tais como: resolução de incidente ou problema, mudanças para atender a organização e/ou à

legislação. Das informações necessárias para análise destacam-se o motivo da mudança, os

CIs selecionados e as recomendações do CAB.

Os CIs selecionados na RFC são analisados sobre a real necessidade de mudança,

dessa forma, poderá haver a adição ou a remoção de algum CI caso haja necessidade. Todo

esse plano de liberação que será implementado nos CIs é salvo no CMDB, bem como, as

informações sobre a configuração dos CIs antes da implementação da mudança.

88

A Figura 21 demonstra, através do diagrama de atividade, a solução proposta para

implementação desse caso de uso.

Figura 21: Diagrama de atividade do caso de uso UC01 – Planejar Liberação (Autor).

89

4.1.1.2 UC02 – Documentar Plano de Retorno

O plano de retorno (back-out) é similar a um dos itens que compõem o plano de

implementação. Enquanto que no plano de implementação é necessário detalhar os

procedimentos de instalação ou eliminação dos CIs o plano de retorno fará o processo ao

contrário retornando a situação original em caso de falha.

Testar o plano de retorno certifica que o mesmo deverá funcionar conforme a situação

descrita. Os resultados obtidos nos testes devem ser documentados para auxiliar na análise do

plano de liberação.



Figura 22: Diagrama de atividade do caso de uso UC02 – Documentar Plano de Retorno (Autor).

4.1.1.3 UC03 – Desenvolver Boletim Técnico

O desenvolvimento de boletins técnicos explicando sobre a implementação é

considerado como um dos procedimentos de responsabilidade do Gerenciamento de

Liberação (OGC, 2000).

90

Contudo, a ITIL não determina como elaborar e o que deve ser informado nesses

boletins técnicos. Porém, algumas informações podem ser destacadas para constar nessa

documentação tais como: descrição do problema, benefícios obtidos com essa mudança, o

modo como foi implementado e quais foram os CIs afetados.



Figura 23: Diagrama de atividade do caso de uso UC03 – Desenvolver Boletim Técnico (Autor).

91

4.1.1.4 UC04 – Desenvolver Treinamento

O desenvolvimento do material para treinamento é um dos itens que complementa o

plano de liberação. Através dele os usuários poderão obter melhores benefícios dessa nova

liberação e também a diminuição dos erros na execução das tarefas.

Ao contrário do boletim técnico, seção 4.1.1.3, o texto apresentado deve ser de fácil

compreensão e com o mínimo de termos técnicos.



Figura 24: Diagrama de atividade do caso de uso UC04 – Desenvolver Treinamento (Autor).

4.1.1.5 UC05 – Definir Pacote de Liberação

O processo de Gerenciamento da Liberação possui o conceito sobre liberação, onde é

um conjunto de mudanças autorizadas, originadas de RFCs, que podem alterar tanto hardware

quanto software (OGC, 2000).

92

Conforme descrito na seção 2.2.5.1, as formas existentes de liberação são: Maior

(Major release), Menor (Minor release) e Correções de emergência (Emergency fix). E os

tipos de liberação são: Liberação completa (Full release), Liberação parcial (Delta release) e

Pacote (Package release).

Além de definição o tipo e a forma, determinar a versão da liberação é importante para

saber em qual estágio de atualização um CI ou um componente dele está.

A união dessas informações mais as definidas nos planos de liberação (seção 4.1.1.1)

irão compor o pacote de liberação. A Figura 25 demonstra, através do diagrama de atividade,

a solução proposta para implementação desse caso de uso.

Figura 25: Diagrama de atividade do caso de uso UC05 – Definir Pacote de Liberação (Autor).

93

4.1.1.6 UC06 – Consultar CI

Esse caso de uso é utilizado por todos os processos da ITIL, referente ao livro Suporte

de Serviços, e também pela função Central de Serviços. Ele consiste em exibir uma lista de

CIs cadastrados, onde é possível localizar um determinado CI.

Informações detalhadas sobre o cadastro do CI, o histórico e o relacionamento com os

demais CIs são possíveis através dessa consulta. Isso agiliza a tomada de decisão sobre o CI

que está sendo exibido ou a ser selecionado.



Figura 26: Diagrama de atividade do caso de uso UC06 – Consultar CI (Autor).

4.1.1.7 UC07 – Salvar no CMDB

O caso de uso Salvar no CMDB é utilizado por todos os processos da ITIL, referente

ao livro Suporte de Serviços, incluindo a função Central de Serviços. Sua função é de salvar,

catalogar e centralizar toda e qualquer informação referente aos CIs numa única base de

dados.

94

O CMDB contém informações sobre os CIs, os incidentes, problemas, mudança

liberações, os erros conhecidos, os serviços prestados, os fornecedores, os clientes, os locais,

dentre outras informações (OGC, 2000).



Figura 27: Diagrama de atividade do caso de uso UC07 – Salvar no CMDB (Autor).

4.1.1.8 UC08 – Avaliar Liberação

O plano de liberação somente será aplicado após ele ser avaliado. Essa avaliação

envolve o aceite do cliente sobre a agenda de liberação proposta, a verificação se todos os

testes foram efetuados, se a documentação está correta, se as RFCs foram liberadas e se o

CAB ou CAB/EC autorizou o plano de liberação (OGC, 2000).

Somente através de procedimentos, modelos e orientações devidamente documentados

é que o Gerenciamento de Liberação e o suporte poderão desempenhar de forma eficiente e

eficaz as mudanças propostas (OGC, 2000).

Caso os testes não tenham sido documentados corretamente o gestor do processo de

Gerenciamento da Liberação deverá ser comunicado.

Todas as informações geradas no processo de avaliação do plano de liberação serão

salvas no CMDB.

95



Figura 28: Diagrama de atividade do caso de uso UC08 – Avaliar Liberação (Autor).

4.1.1.9 UC09 – Aprovar Liberação

Quando um plano de liberação é aprovado isso significa que o CAB ou o CAB/EC

estão de acordo com o plano proposto, o cliente aceitou a agenda de liberação e a

documentação está correta.

Sendo assim, os solicitantes das RFCs e o Gerenciamento da Liberação devem ser

informados que a proposta foi aceita. A Central de Serviços deve também ser comunicada

sobre a agenda de implementação.

96



Figura 29: Diagrama de atividade do caso de uso UC09 – Aprovar Liberação (Autor).

4.1.1.10 UC10 – Rejeitar Liberação

Diversos motivos podem fazer com que um plano de liberação seja rejeitado, tais

como: documentação pouco detalhada, a agenda não foi aceita do cliente, dentre outros.

Sendo assim, é necessário informar ao Gerenciamento de Mudança sobre o adiamento da

mudança, os solicitantes das RFCs e o Gerenciamento de Liberação.



Figura 30: Diagrama de atividade do caso de uso UC10 – Rejeitar Liberação (Autor).

97

4.1.1.11 UC11 – Implementar Liberação

O Gerenciamento da Liberação implementará o plano de liberação aprovado conforme

a data agendada. A implementação poderá ocorrer de duas formas manual ou automática. Na

forma automática, um sistema se encarregará de instalar os softwares nos CIs identificados e o

resultado dessa operação é documentado pelo mesmo no CMDB. Enquanto que na forma

manual, é necessário que uma pessoa execute os procedimentos de instalação e documentação

dos acontecimentos durante a implementação.



Figura 31: Diagrama de atividade do caso de uso UC11 – Implementar Liberação (Autor).

98

4.1.1.12 UC12 – Auditar Implementação

O Gerenciamento da Liberação tem como atividade efetuar auditorias nos CIs antes e

depois de uma implementação de mudança (OGC, 2000). Essa auditoria poderá ser realizada

através de um relatório com as informações salvas antes e após a implementação e

comparadas fisicamente no CI.

Caso as informações do CI estejam divergentes ao que está no relatório deverá ser

revisto o plano de liberação. Independente do resultado obtido, a auditoria deverá ser salva no

CMDB.



Figura 32: Diagrama de atividade do caso de uso UC12 – Auditar Implementação (Autor).

99

4.2 GERENCIAMENTO DA CONFIGURAÇÃO

O Gerenciamento da Configuração é responsável por identificar, registrar, controlar,

informar e definir os CIs da infraestrutura de TI, bem como, avaliar o estado dos mesmos

(MAGALHAES, 2007).

Dos objetivos que compõem esse processo pode se destacar (OGC, 2000):

� Catalogar todos os bens de TI e suas configurações no âmbito da organização;

� Fornecer informações precisas sobre a documentação e configuração para auxiliar

todos os processos de gestão de serviços de TI;

� Gerir o relacionamento entre os CIs, bem como, a relação entre os componentes e

suas versões.

O diagrama de caso de uso representado na Figura 33 demonstra como deve ser o

processo de Gerenciamento da Configuração conforme o método de avaliação proposto.

Figura 33: Diagrama de caso de uso representando o processo Gerenciamento da Configuração (Autor).

100

4.2.1 Detalhamento dos casos de uso

Os casos de uso identificados no diagrama, exibido pela Figura 33, serão detalhados

baseados nas informações necessárias para o entendimento das soluções propostas. Aliado a

isso, os diagramas de atividades exibirão os passos necessários para a conclusão das

atividades. A documentação dos casos de uso está descrita no Anexo A dessa monografia.

4.2.1.1 UC13 – Planejar Abrangência

Devido ao fato de que a infraestrutura de TI é muito complexa e distribuída, o

mapeamento deve ser feito de forma cuidadosa e planejada (OGC, 2000). Esse planejamento

deve observar algumas premissas (MAGALHÃES, 2007):

� A estratégia, os objetivos, o escopo e a política do Gerenciamento da Configuração

devem ser definidas;

� Análise do ambiente organizacional, tanto no âmbito técnico como gerencial, para

definir os processos do Gerenciamento da Configuração;

� A definição das ferramentas, responsabilidades, papeis e procedimentos;

� Planejamento da carga inicial de dados na base de dados de Gerenciamento da

Configuração;

� Definição dos tipos de CIs, de atributos e de relacionamentos;

O processo de Gerenciamento da Configuração é a base para todos os processos, pois

a partir dele é que existirão informações para iniciar as atividades. Sendo assim, o caso de uso

nomeado Planejar Abrangência iniciará o cadastro das informações, tais como: tipos de

relacionamentos, estados dos CIs, clientes, fornecedores, itens de configuração, dentre outras

informações.

101



Figura 34: Diagrama de atividade do caso de uso UC13 – Planejar Abrangência (Autor).

4.2.1.2 UC14 – Registrar CI

O registro das informações do CI inicia após o planejamento da abrangência. Os CIs

serão identificados, selecionados e seus atributos de configuração serão catalogados (OGC,

2000).

Esse processo de registro poderá ser feito de forma automática, onde um sistema

analisará a rede a procura de equipamentos e softwares instalados, ou de forma manual, onde

102

uma pessoa irá coletar as informações necessárias referentes a cada tipo de CI, sendo que em

ambos as informações serão sempre salvas no CMDB.

O Gerenciamento da Liberação solicitará uma cópia das informações atuais para que,

após uma mudança implementada, o CI possa ser auditado.



Figura 35: Diagrama de atividade do caso de uso UC14 – Registrar CI (Autor).

103

4.2.1.3 UC15 – Definir Relacionamento entre CIs

Para determinar a dependência entre os CIs, os mesmos devem ter os seus

relacionamentos registrados no CMDB. Essa dependência pode ser de classificada de várias

formas, sendo elas (OGC, 2000):

� Um CI é parte de outro CI;

� Um CI está conectado a outro CI;

� Um CI usa outro CI.

O relacionamento existente entre os CIs é o diferencial entre o Gerenciamento da

Configuração e o gerenciamento de ativo (OGC, 2000).



Figura 36: Diagrama de atividade do caso de uso UC15 – Definir Relacionamento entre CIs (Autor).

104

4.2.1.4 UC16 – Identificar Automaticamente

Quando a infraestrutura de TI está muito grande e complexa, torna-se ineficiente a

verificação manual dos atributos dos CIs. Sendo assim, automatizar essa atividade torna mais

eficiente o setor de TI e diminui a necessidade de contratar mais pessoas.



Figura 37: Diagrama de atividade do caso de uso UC16 – Identificar Automaticamente (Autor).

4.2.1.5 UC17 – Auditar CI

A auditoria destina-se a avaliar se as informações salvas no CMDB estão de acordo

com o ambiente de produção (MAGALHÃES, 2007). Caso haja divergência entre as

105

informações, deve-se iniciar um processo de mudança para normalizar a situação (OGC,

2000).



Figura 38: Diagrama de atividade do caso de uso UC17 – Auditar CI (Autor).

4.2.1.6 UC18 – Visualizar Relacionamentos

A visualização dos relacionamentos entre os CIs facilita numa análise de mudança,

incidente e/ou problema. Proporcionando assim uma visão da abrangência do relacionamento.

106



Figura 39: Diagrama de atividade do caso de uso UC18 – Visualizar Relacionamentos (Autor).

107

5 CONCLUSÃO

5.1 CONSIDERAÇÕES FINAIS

A pesquisa apresentada neste trabalho teve início com a análise da ITIL como recurso

para auxiliar na aplicação da Governança de TI. Em seguida foi reunido referencial teórico

sobre os conceitos da ITIL (seção 2.1), segunda versão, referente ao livro Suporte de Serviços

e sobre o conceito de Software Livre (seção 2.3). Para a seleção das ferramentas, foi realizada

uma entrevista com pessoas que tem influência com gestores da tecnologia da informação

questionando sobre: “Quais os Softwares Livres, que tratam sobre ITIL, você indicaria a seus

clientes?” (seção 3.1). Dessas entrevistas resultou na seleção de três ferramentas: OcoMon,

Spiceworks e OTRS.

A implementação de cada um dos processos da ITIL (Gerenciamento de Incidente,

Gerenciamento de Problema, Gerenciamento de Mudança, Gerenciamento de Liberação e

Gerenciamento da Configuração) deve ser bem planejado pelas empresas, para poder gerar o

retorno esperado. Caso contrário, a falta de planejamento poderá tornar inviável, gerando um

excesso de burocracia. Além disso, a equipe dever estar treinada com os novos conceitos

sobre a metodologia adotada.

É imprescindível que, ao adotar esse conceito, seja necessário documentar as ações

que foram tomadas e os procedimentos padrões que serão utilizados. Essa padronização evita

que as informações fiquem exclusivas a uma parte da equipe. Permitindo que as pessoas

possam evoluir de cargo repassando suas antigas atividades para os novos encarregados sem

que haja perda de qualidade nos serviços.

Todavia, esse volume de documentação irá gerar, no início, uma demanda maior de

trabalho, mas a tendência é que os incidentes/problemas se repitam diminuindo o volume

dessas documentações.

Levando-se em consideração que o volume de documentação é proporcional ao

número de processos implantados na organização, é importante salientar que, equipes

pequenas de TI não conseguirão documentar todos os processos. Como sugestão para a

implementação em uma equipe pequena seriam os processos: Gerenciamento da Configuração

e o Gerenciamento de Incidentes.

108

Com a infraestrutura de TI organizada, possibilita-se controlar, por exemplo, o volume

de atendimentos conforme o cliente, avaliar as compras efetuadas em cada fornecedor, qual o

CI que necessita de manutenção preventiva, o término dos contratos de manutenção, as

licenças instaladas, entre outros.

Através dos históricos é possível efetuar os atendimentos de forma eficiente e eficaz,

pois o retrabalho será minimizado devido à documentação já elaborada. Ele gera também

subsídios para justificar determinadas compras de equipamentos devido ao excesso de

manutenções.

Outro grande benefício é a possibilidade de visualizar os relacionamentos existentes

entre os CIs. Isso permite identificar equipamentos que podem estar gerando determinado

problema, o impacto que poderá gerar na substituição de um determinado equipamento,

número de equipamentos ociosos, dentre outros.

É importante ressaltar que a TI pode ajudar a diminuir os custos das organizações,

ainda mais neste momento de crise mundial, pois essa atitude ajuda na preservação de cargos

de trabalho. Uma alternativa é a utilização de Software Livre, pois a empresa não terá que

liberar verbas altas na compra de licenças e manutenção da ferramenta. Vale ressaltar que, se

a empresa quer efetuar personalizações no software, terá que dispor de verba para a

contratação de programadores.

É necessário observar que nenhum software irá atender 100% uma organização, pois

existirão controles específicos em cada uma delas. O objetivo dessas e outras ferramentas é

codificar e organizar a informação permitindo um melhor gerenciamento da infraestrutura de

TI. Dessa forma é importante à empresa pesquisar quais ferramentas melhor adéquam-se a sua

necessidade.

Procurando unir a teoria com a prática, foi elaborado um checklist com 143 questões

(seção 3.3) para avaliar as ferramentas OcoMon, Spiceworks e OTRS. O software que obteve

melhor aderência foi OTRS com 53%. Isso fugiu um pouco do esperado, pois uma ferramenta

baseada em software livre que apresenta um percentual tão alto de aceitação foi algo que

superou expectativas que surgiam ao longo da pesquisa.

Esta ferramenta conseguiu anteder muito bem os requisitos, porque há várias opções

de configuração, permitindo assim, ao administrador do sistema, a personalização conforme

as nomenclaturas da organização.

109

Além disso, a abertura dos chamados é bem simples e possui um campo para a

identificação dos tipos de chamados disponíveis, o que torna possível a filtragem dos mesmos.

Através dos resultados obtidos, criaram-se condições para identificar e propor

melhorias à ferramenta OTRS referente aos processos de Gerenciamento de Liberação e

Gerenciamento da Configuração. Através dessa melhoria o software passará a atender melhor

aos conceitos do livro Suporte de Serviços da ITIL (seção 4).

Um fato para o qual se torna importante dar destaque é que a ferramenta OTRS tem a

possibilidade de satisfazer as necessidades básicas do gerenciamento de TI de muitas

organizações devido a uma série de funcionalidades atendidas pelo modelo proposto. A sua

instalação é muito simples o que agiliza o processo de implantação. As empresas que

possuírem programadores próprios poderão personalizar essa ferramenta conforme a sua

necessidade.

Contudo, nenhuma ferramenta fará todo o serviço sozinha. É necessário que algumas

informações sejam inseridas no sistema, de forma manual, e, para isso, a equipe deve estar

preparada, pois senão não haverá um controle efetivo.

Quando a ferramenta OTRS não satisfizer mais as necessidades da empresa e a mesma

decidir trocar esse software, o modelo e as análises feitas poderão auxiliar na avaliação da

nova ferramenta e assim comparar as informações. Com esse resultado será possível comparar

as funcionalidades atendidas por ambas às ferramentas.

Finalizando, pode-se verificar a importância da ITIL para a governança de TI, tanto

visualizando o ambiente acadêmico, através de informações repassadas em diversas

atividades, quanto à aplicação no âmbito econômico-social das empresas.

Essa pesquisa permitiu um aprofundamento nas melhores práticas que a ITIL sugere e

ainda a possibilidade de unir esse conhecimento a uma ferramenta baseada em software livre

que auxiliará no gerenciamento da informação.

Para os acadêmicos fica disponível um método de avaliação de software livre baseado

nos conceitos da ITIL, e para a sociedade uma alternativa inicial para a realização do

gerenciamento da TI nas organizações.

110

5.2 TRABALHOS FUTUROS

Como forma de avaliar o checklist proposto nesta monografia, sugere-se a aplicação

do mesmo com ferramentas pagas no intuito de comparar o quanto essas se aproximam aos

conceitos da ITIL. Através deste resultado pode-se obter um comparativo entre as ferramentas

pagas e livres. Evidenciando ao mercado, o quanto os softwares livres estão próximos aos

softwares de mercado.

Outra sugestão é o desenvolvimento das melhorias sugeridas ao software OTRS e o

acompanhamento da implantação deste numa organização.

111

REFERÊNCIAS BILIOGRÁFICAS

(BARELLA, 2009) BARELLA, Irene. ITIL e COBIT unidos na Gestão Empresarial. Computerworld. Disponível em: <http://www.companyweb.com.br/lista_artigos.cfm?id_artigo=160>. Acesso em: 02 fev. 2009.

(BRADLEY, 1993) BRADLEY, Jana. Methodological issues and practices in qualitative research. Library Quarterly, Oct. 1993. p. 431-449, v. 63, n. 4.

(ENTUITY, 2009) ENTUITY, Inc , Eye of the Storm Supports the IT Infrastructure Library (ITIL): Achieving Effective IT Service Mana gement. Disponível em: <http://www.entuity.com/contact/white-paper-itil.html?entuity.contact+target=itil>. Acesso em: 21 mar. 2009.

(ENGELFRIET, 2009) ENGELFRIET, A. Crash course on copyright. Disponível em: <http://www.iusmentis.com/copyright/crashcourse/>. Acesso em: 03 mai. 2009.

(EXIN, 2009) Examination Institute for Information Science – EXIN. EXIN Exams. Disponível em: <www.exin-exams.com>. Acesso em: 02 de abr. 2009.

(GIL, 2002) GIL, Antonio Carlos. Como elaborar projetos de pesquisa. 4. ed. São Paulo: Atlas, 2002.

(GNU, 2009) GNU Operation System. What is Copyleft? Disponível em: <http://www.gnu.org/copyleft>. Acesso em: 03 mai. 2009.

(HEXSEL, 2003) HEXSEL, R. A. Software Livre. Paraná: Universidade Federal do Paraná, 2003.

(HOPPEN, 1996) HOPPEN, Norberto; LAPOINTE, Liette; MOREAU, Eliane. Um guia para a avaliação de artigos de pesquisa em sistemas de informação. Revista Eletrônica de Administração, nov. 1996. v. 2, n. 2.

(ITSMF, 2001) ITSMF - IT Service Management Forum. IT Service Management, an Introduction.Sd. Reino Unido: ITSMF, 2001.

(ITSMF, 2009) ITSMF Brasil. The IT Service Management Forum. Disponível em: <http://www.itsmf.com.br>. Acesso em: 14 mar. 2009.

(ITIL Central, 2009) ITIL Central. News and Information for ITIL® The IT Infrastructure Library Disponível em: <http://itsm.fwtk.org>. Acesso em: 21 mar. 2009.

112

(JESUS, 2006) JESUS, Gonçalo João Vitorino de. ITIL: Valerá a pena? Quais os processos mais afectados? Coimbra: Universidade de Coimbra, 2006.

(LACY, 2001) LACY, S.; HARROW, R. ITIL Best Practices - Service Support. Versão 2.3. Crown, 2001.

(LEVY, 1994) LEVY, S. Hackers: Heroes of the Computer Revolution. 2. ed. New York: Penguin Putnam, 1994.

(MAGALHÃES, 2007) MAGALHÃES, Ivan Luizio; PINHEIRO, Walfrido Brito. Gerenciamento de Serviços de TI na Prática: Uma abordagem com base na ITIL®. São Paulo: Novatec, 2007.

(MCKUSICK, 1999) MCKUSICK, M. K. Twenty years of Berkeley Unix. In: Open Sources. 1. ed. Sebastopol: O’Reilly and Associates, 1999.

(NUNES, 2007) NUNES, Cláudio; ARAÚJO, Thiago Vasques de; DAMASCENO, Cristiane Soares. ITIL - Uma avaliação sobre as melhores práticas e os resultados de sua empregabilidade para corporações de porte variados. São Paulo: Universidade Santa Cecília, 2007.

(OCOMON, 2009) OcoMon. O ocomon. Disponível em: <http://ocomonphp.sourceforge.net>. Acesso em: 27 jul. 2009.

(OGC, 2000) Office of Government Commerce - OGC. Service Support – ITIL. Versão 2.2. Crown, 2000.

(OGC, 2004) Office of Government Commerce - OGC. Service Management – ITIL. Versão 3. Crown, 2004.

(OGC, 2009) Office of Government Commerce - OGC, Successful Delivery Toolkit. Disponível em: <http://www.ogc.gov.uk/resource_toolkit.asp>. Acesso em: 02 fev. 2009.

(OTRS, 2009) OTRS. Open Ticket Request System. Disponível em: <http://otrs.org>. Acesso em: 05 ago. 2009.

(PALVIA, 2003) PALVIA, Prashant; MAO, En; SALAM, A. F.; SOLIMAN, Khalid S. Management information systems research: what's there in a methodology? Communications of the AIS, 2003. v. 11.

(PATTON, 1980) PATTON, Michael Q. Qualitative evaluation methods. United States: Sage Publications, 1980.

113

(PINHEIRO, 2006) PINHEIRO, Flávio R. Fundamentos em Gerenciamento de Serviços em TI Baseado no ITIL. 2006.

(PINK, 2001) PINK. The ITIL History. Pink Elephant North America, 2001.

(PINK, 2009) Pink Elephant. PinkVERIFY. Disponível em: <www.pinkelephant.com/pt-BR/ResourceCenter/PinkVerify>. Acesso em: 17 abr. 2009.

(PINKROCCADE, 2009) PINKROCCADE, Getronics. ITIL be Alright on the Night – But will IT?. Disponível em: <http://www.pinkroccade.co.uk/Images/14_41685.pdf>. Acesso em: 21 mar. 2009

(RUDD, 2004) RUDD, C. The IT Infrastructure Library An Introductory Overv iew of ITIL V3. Versão 1.0. itSMF, 2004.

(SPICEWORKS, 2009) Spiceworks. IT'S EVERYTHING IT. Disponível em: <www.spiceworks.com>. Acesso em: 31 jul. 2009.

(STALLMAN, 1999) STALLMAN, R. M. The GNU Operating System and the Free Software Movement. In: Open Sources. 1. ed. Sebastopol: O’Reilly and Associates, 1999.

(STATDLOBER, 2006) STATDLOBER, Juliano. Help-Desk e SAC com Qualidade. Rio de Janeiro: Brasport, 2006.

(STREIT, 2004) STREIT, R.; MAÇADA, A. C.; BORENSTEIN, D. Tecnologia da Informação na Governança do Sistema Financeiro Nacional (SFN). São Paulo: Congresso Anual de Tecnologia de Informação (CATI), 2004.

(TERZIAN, 2004) TERZIAN, F. Gerenciamento de mudanças. Info Corporate, Março/Abril 2004. Pp. 48-59.

(YIN, 2001) YIN, Robert K. Estudo de Caso. Planejamento e Métodos. 2. ed. Porto Alegre: Bookman, 2001.

114

ANEXO A – DOCUMENTAÇÃO DOS CASOS DE USO

GERENCIAMENTO DE LIBERAÇÃO Código: UC01 Nome: Planejar Liberação Ator(es): Gerenciamento de Liberação, Gerenciamento de Mudança

Descrição: Este caso de uso descreve os passos para o desenvolvimento do plano de liberação.

Pré-condições: Possuir RFCs Liberadas pelo processo de Gerenciamento de Mudança. Pós-condições: Código: UC02 Nome: Documentar Plano de Retorno Ator(es): Gerenciamento de Liberação

Descrição: Este caso de uso descreve os passos para a elaboração do plano de retorno.

Pré-condições: Estar posicionado no plano de liberação e o mesmo deve estar com a descrição da implementação preenchida.

Pós-condições: Código: UC03 Nome: Desenvolver Boletim Técnico Ator(es): Gerenciamento de Liberação

Descrição: Este caso de uso descreve os passos para a elaboração dos boletins técnicos

Pré-condições: Estar posicionado no plano de liberação. Pós-condições: Código: UC04 Nome: Desenvolver Treinamento Ator(es): Gerenciamento de Liberação Descr ição: Este caso de uso descreve os passos para a elaboração do treinamento. Pré-condições: Estar posicionado no plano de liberação. Pós-condições: Código: UC05 Nome: Definir Pacote de Liberação Ator(es): Gerenciamento de Liberação

Descrição: Este caso de uso descreve os passos para a geração do pacote de liberação.

Pré-condições: O plano de liberação e retorno devem estar preenchidos. Pós-condições: Código: UC06 Nome: Consultar CI

Ator(es): Gerenciamento de Incidente, Gerenciamento de Problema, Gerenciamento de Mudança, Gerenciamento de Liberação, Gerenciamento da

115

Configuração e Central de Serviços.

Descrição: Este caso de uso descreve como será exibida a consulta dos CIs. Pré-condições: Pós-condições: Código: UC07 Nome: Salvar no CMDB

Ator(es): Gerenciamento da Configuração, Gerenciamento de Mudança e Gerenciamento de Liberação

Descrição: Este caso de uso descreve como as informações dos CIs serão salvas. Pré-condições: Pós-condições: Código: UC08 Nome: Avaliar Liberação Ator(es): Gerenciamento de Liberação e Gerenciamento de Mudança.

Descrição: Este caso de uso descreve os passos de como será documentado a avaliação da liberação.

Pré-condições: O caso de uso "UC05 - Definir Pacote de Liberação" deve já ter sido executado.

Pós-condições: Código: UC09 Nome: Aprovar Liberação Ator(es): Gerenciamento de Liberação

Descrição: Este caso de uso descreve os passos de como será documentado a liberação quando aprovada.

Pré-condições: O pacote de liberação deve ter passado pela avaliação. Pós-condições: Código: UC10 Nome: Rejeitar Liberação Ator(es): Gerenciamento de Liberação e Gerenciamento de Mudança.

Descrição: Este caso de uso descreve os passos de como será documentado a liberação quando rejeitada.

Pré-condiçõ es: O pacote de liberação deve ter passado pela avaliação. Pós-condições: Código: UC11 Nome: Implementar Liberação Ator(es): Gerenciamento de Liberação

Descrição: Este caso de uso descreve os passos de como documentar uma implementação de um pacote de liberação.

Pré-condições: O pacote de liberação deve estar aprovado. Pós-condições:

116

Código: UC12 Nome: Auditar Implementação

Ator(es): Gerenciamento de Liberação e Gerenciamento de Mudança.

Descrição: Este caso de uso descreve os passos de como documentar uma auditoria após a implementação de um pacote de liberação.

Pré-condições: O caso de uso "UC11 - Implementar Liberação" deve ter sido executado. Pós-condições: GERENCIAMENTO DA CONFIGURAÇÃO Código: UC13 Nome: Planejar Abrangência Ator(es): Gerenciamento da Configuração

Descrição: Este caso de uso descreve quais são os tipos de parâmetros que serão configurados para o gerenciamento dos UC.

Pré-condições: Pós-condições: Código: UC14 Nome: Registrar CI Ator(es): Gerenciamento da Configuração

Descrição: Este caso de uso descreve como serão registrados os CIs. Pré-condições: Pós-condições: Código: UC15 Nome: Definir Relacionamento entre CIs. Ator(es): Gerenciamento da Configuração

Descrição: Este caso de uso descreve como será o cadastrado o relacionamento entre os CIs.

Pré-condições: O CI já deve ter sido cadastrado. Pós-condições: Código: UC16 Nome: Identificar Automaticamente Ator(es): Gerenciamento da Configuração

Descrição: Este caso de uso descreve como serão registrados os CIs de forma automática.

Pré-condições: Pós-condições: Revisar os dados coletados.

117

Código: UC17 Nome: Auditar CI Ator(es): Gerenciamento da Configuração Descrição: Este caso de uso descreve como será feita a auditoria no CI. Pré-condições: Pós-condições: Código: UC18 Nome: Visualizar Relacionamentos Ator(es): Gerenciamento da Configuração

Descrição: Este caso de uso descreve como será exibido o relacionamento entre os CIs.

Pré-condições: O caso de uso "UC14 - Registrar CI" deve já ter sido executado. Pós-condições:

suporte de serviÇos, segundo itil: uma ferramenta baseada em software livre

Documents