Gerenciamento de Aplicações no TJPE

GRUPO SER EDUCACIONAL
FACULDADE MAURÍCIO DE NASSAU
ESPECIALIZAÇÃO EM GESTÃO DE TI

Francisco de Assis de Lima Filho

Gerenciamento de Aplicações baseado no ITIL v3:
Uma Proposta de Implementação para o TJPE

Recife, 2011

Francisco de Assis de Lima Filho


Monografia apresentada ao Programa de Pós-
graduação lato sensu da Faculdade Maurício
de Nassau como requisito parcial para a
obtenção do título de Especialista em Gestão
de TI.

Orientador: Prof. Roberto Delgado Arteiro.

Recife, 2011

GRUPO SER EDUCACIONAL
FACULDADE MAURÍCIO DE NASSAU
ESPECIALIZAÇÃO EM GESTÃO DE TI


Monografia submetida ao corpo docente do Curso de Especialização em Gestão de TI,
promovido pela Faculdade Maurício de Nassau, do Grupo Ser Educacional.

Banca Examinadora:

Professor Roberto Delgado Arteiro Nota: ____________

MENÇÃO GERAL:

_________________________________________________________

Coordenador do Curso:
Prof. Rodrigo Assad.

Agradecimento(s)

À Deus, por ser a força na minha fraqueza, pela minha família e a oportunidade de realizar este
sonho.

À minha família, pelo amor incondicional, e pelo incentivo do meu pai em enfrentar o desafio da
especialização.

Ao meu orientador Roberto Arteiro, que disponibilizou com solicitude seu conhecimento e tempo para
a orientação da monografia.

À minha amada Mariana, por todo o apoio que me deu durante a produção desta monografia.

Aos meus amigos da UIAPL e colegas da SETIC, que me ajudaram, seja cedendo algum material de
pesquisa, com entrevistas ou resolvendo minhas dúvidas: Aldrey, Felipe, Igor, Tércio, Edvaldo,
Wesley, Marcelo Lima, Rodrigo Pedrosa, Márcio, Eddie, Raphael dCastro, Napoleão, Brainer.

À minha amiga Cláudia, pela boa companhia e pelas inúmeras caronas ao longo dessa jornada à
Faculdade.

Ao Sr. César Marinho, por dispor do seu tempo para a entrevista na STI/SEFAZ-PE.

A todas as pessoas aqui não mencionadas que, de uma forma ou de outra, deram sua colaboração.

Comece fazendo o que é necessário,
depois o que é possível,
e de repente você estará fazendo o impossível.
1
São Francisco de Assis

1
Esta epígrafe foi escolhida pelo caráter desafiador de se implantar o Gerenciamento de Aplicações,
proposto por esta monografia.

Resumo

Os serviços de TI (Tecnologia da Informação) são críticos para o exercício
das atividades organizacionais. As aplicações são componentes integrantes dessa
estrutura, uma vez que, por meio delas, seus usuários têm acesso aos serviços
prestados. No contexto das instituições públicas, as aplicações têm assumido um
papel essencial, tendo em vista a crescente demanda para o atendimento
populacional e exigência da qualidade pelo nível de serviço oferecido. Isto implica
que os atuais modelos de gestão de TI precisam tratar, de forma precisa, toda a
estrutura envolvida em manter seus serviços, bem como as aplicações, funcionando
em meio a todas as possíveis mudanças dentro da área de TI. O problema reside no
fato de que a falta de Gerenciamento de Serviços de TI acarreta falhas na
disponibilidade dos serviços, alocação extra de recursos para resolver problemas
recorrentes e consequências indesejáveis para a imagem da TI perante a
organização e a opinião pública. O cenário atual da SETIC/TJPE mostra a
necessidade em se resolver a questão envolvendo a inadequada interação entre as
equipes de desenvolvimento e de produção, bem como promover a agilidade na
implantação de aplicações e componentes de hardware que afetem o funcionamento
delas. O objetivo deste trabalho é estudar o ITIL (Information Technology
Infrastructure Library), na sua terceira versão, como uma biblioteca de melhores
práticas para implementar um modelo de Gerenciamento de Serviços de TI a fim de
contribuir para a resolução dos problemas citados. A função de Gerenciamento de
Aplicações, por meio dos processos de Gerenciamento de Configuração e Ativos,
Gerenciamento de Mudança e Gerenciamento de Liberação e Implantação também
são apresentados. Por fim, são elaboradas algumas propostas para estes processos
dentro da SETIC, sobretudo para o processo de Gerenciamento de Liberação e
Implantação.

Palavras-chave: Gerenciamento de Serviços de TI, ITIL, Gerenciamento de
Aplicações, Gerenciamento de Liberação e Implantação

Abstract

The services of IT (Information Technology) are critical to the performance of
organizational activities. The applications are integral components of this structure,
since, through them, your users have access to services. In the context of public
institutions, applications have an essential role in view of the growing demand to
meet population and demand for the quality level of service offered. This implies that
the current models of IT management must deal with, precisely, the entire structure
involved in maintaining their services and applications, running through all the
possible changes within the IT field. The problem lies in the fact that the lack of IT
Service Management involves flaws in the availability of services, allocation of extra
resources to tackle recurring problems and undesirable consequences for the image
of IT to the organization and the public. The current scene of the SETIC/TJPE shows
the necessity to resolve the question involving the inappropriate interaction between
development and production teams, and to promote flexibility in the deployment of
applications and hardware components that affect the operation of them. The
objective of this work is to study the ITIL (Information Technology Infrastructure
Library), in it’s third version, such as a library of best practices for implementing a
model of IT Service Management in order to contribute to solving the problems
mentioned. The Application Management function, through the processes of Asset
and Configuration Management, Change Management and Release and Deployment
Management are also presented. Finally, some proposals are made for these
processes within the SETIC, particularly for the process of Release Management and
Deployment.

Key words: IT Service Management, ITIL, Application Management, Release and
Deployment Management

Lista de Ilustrações

Figura 1 - Relação entre negócio e serviços prestados por TI 17

Figura 2 - Relação entre processo e suas atividades 20

Figura 3 - O ciclo de Deming no ITIL versão 3 21

Figura 4 - O ciclo de vida de serviços do ITIL versão 3 22

Figura 5 – Elementos da Estratégia de Serviços 24

Figura 6 – Elementos do Desenho de Serviços 26

Figura 7 – Elementos da Transição de Serviço 29

Figura 8 – Elementos da Operação de Serviço 32

Figura 9 – Elementos da Melhoria Contínua de Serviço 34

Figura 10 – Relacionamentos no gerenciamento de aplicações 35

Figura 11 – Inter-relacionamento entre os processos de Gerenciamento de Mudança, 44
Gerenciamento de Configuração e Gerenciamento de Liberação e Implantação

Figura 12 – Atividades do processo de Gerenciamento de Liberação e Implantação 49

Lista de Tabelas

Tabela 1 – Perguntas Críticas para documento de Implantação 37

Tabela 2 – Exemplo de checklist do Plano de Implantação Piloto 38

Tabela 3 – Atividades operacionais típicas de acompanhamento de aplicação 39

Tabela 4 – Perguntas referentes ao processo de revisão da aplicação 40

Lista de Siglas

ASCOM Assessoria de Comunicação da Presidência
CAB Change Advisory Board (Comitê de Mudança)
CI Configuration Item (Item de Configuração)
CMDB Configuration Management Database (Base de Dados do
Gerenciamento de Configuração)
CMS Configuration Management System
CSF Critical Success Factor
CSI Continual Service Improment (Melhoria Contínua do Serviço)
DIOP Diretoria de Operações de TIC
DISIS Diretoria de Sistemas
DML Definitive Media Library (Biblioteca de Mídia Definitiva)
ELS Early Life Support (Suporte para Período de Tempo
Experimental)
GSTI Gerenciamento de Serviços de TI
ITIL Information Technology Infrastructure Library
ITSMF IT Service Management Forum
KPI Key Performance Indicator (Principal Indicador de Desempenho)
MTRS Mean Time to Restore Service (Tempo Médio para Restaurar
Serviço)
OGC UK Office of Government Commerce
OLA Operational Level Agreement (Acordo de Nível Operacional)
PDCA Plan-Do-Check-Act (Planejar-Executar-Verificar-Agir)
PETI Plano Estratégico de Tecnologia da Informação
RFC Request For Change (Requisição de Mudança)
SDP Service Design Package (Pacote de Desenho de Serviço)
SEFAZ-PE Secretaria da Fazenda do Estado de Pernambuco
SETIC Secretaria de Tecnologia de informação e comunicação
SLA Service Level Agreement (Acordo de Nível de Serviço)
SLM Service Level Management (Gerenciamento de Nível de Serviço)
SQL Structured Query Language (Linguagem de Consulta
Estruturada)
TCO Total Cost of Ownership (Custo Total de Propriedade)
TI Tecnologia da Informação
TJPE Tribunal de Justiça do Estado de Pernambuco
UC Underpinning Contract (Contrato de Apoio)

Sumário

1 Introdução 13

2 Gerenciamento de Serviços de TI 16
2.1 Visão Geral 16
2.2 ITIL 18
2.2.1 Visão Geral 19
2.2.2 O Modelo de Ciclo de Vida de Serviços 21
2.2.3 O Estagio de Estratégia de Serviço 23
2.2.4 O Estágio de Desenho de Serviço 24
2.2.5 O Estágio de Transição de Serviço 26
2.2.6 O Estágio de Operação de Serviço 29
2.2.7 O Estágio de Melhoria Contínua de Serviço 32

3 O Gerenciamento de Aplicações 34
3.1 Visão Geral 34
3.2 O Ciclo de Vida do Gerenciamento de Aplicações 34
3.3 Papéis e Responsabilidades 40
3.3.1 Configuração e Mudança 41
3.3.2 Suporte 41
3.3.3 Operações 42
3.3.4 Segurança 43
3.3.5 Infraestrutura 43
3.4 Processos Relacionados 44
3.5 O Processo de Gerenciamento de Liberação e Implantação 46
3.5.1 Planejamento da Liberação 50
3.5.2 Desenvolvimento, Construção e Configuração 51
3.5.3 Teste 52
3.5.4 Planejamento da Implantação 52
3.5.5 Comunicação,Preparação e Treinamento 53
3.5.6 Implantação (Instalação) 54

4 O Gerenciamento de Aplicações no TJPE 55
4.1 Cenário Atual 55
4.2 Proposta 59

5 Considerações Finais 66
5.1 Limitações 67
5.2 Sugestões para Trabalhos Futuros 68

Referências 69

APÊNDICE 70

13

1 Introdução

A gestão de TI tem se tornado vital para a sua própria sobrevivência, e, por
fim, das próprias organizações. O principal motivo é a busca pela excelência na
qualidade do serviço, além disso, recursos humanos e tecnológicos precisam ser
cada vez mais bem administrados.
Isto tem impulsionado uma mudança do perfil da TI de mera provedora de
tecnologia para provedora de serviços, possibilitando à organização uma parceria
estratégica, por meio do alinhamento dos serviços de TI aos objetivos estratégicos
organizacionais, isto é, às necessidades atuais e futuras do negócio.
Gestores de TI são cada vez mais pressionados a mostrarem o valor da área
sob sua responsabilidade. Cabe a eles a responsabilidade de adicionarem valor ao
negócio reduzindo custos operacionais.
Dessa forma, a saída que o mercado corporativo tem encontrado é promover
um efetivo gerenciamento dos serviços prestados pela TI. Em termos conceituais, o
gerenciamento de serviços é um conjunto de processos e funções, conduzidos por
habilidades profissionais especializadas, com o propósito de prover valor para os
clientes2 na forma de serviços (OGC ITIL – Service Transition, 2007).
O gerenciamento de serviços se propõe, entre outros aspectos, a controlar o
impacto de mudanças no ambiente de TI, sejam elas planejadas ou não, ao
disponibilizar serviços de forma rápida e confiável.
O gerenciamento de serviços de TI permitirá o controle contínuo, maior
eficiência e oportunidades de melhoria por meio da formalização de seus processos
internos eventualmente implícitos. Por consequência, isto agiliza o atendimento aos
seus usuários.
Uma boa implantação do gerenciamento de serviços reduz o risco da TI para
o negócio. Possibilita-se, assim, uma redução do número de falhas operacionais e
um retorno mais rápido na operação normal dos serviços.
Ressalta-se também o ganho de velocidade de resposta da TI no que se
refere às mudanças na estratégia do negócio. TI ajuda a alavancar o negócio.

2
Pessoas que compram produtos, serviços, ou que definem e fazem acordo sobre as metas de nível
de serviço (OGC ITIL – Glossário de Termos, Definições e Acrônimos, 2007)

14

Os problemas trazidos pela falta de gerenciamento de serviços são graves.
Falhas na disponibilidade de serviços críticos para o negócio podem ser desastrosas
para a imagem da organização perante a opinião pública.
Atualizações de ativos (hardware ou software) mal planejadas geram custos
inesperados com reativação dos sistemas danificados. Indenizações por acordos de
níveis de serviço (SLA – Service Level Agreement) não cumpridos também podem
ser alegadas.
Para uma implantação de serviços ágil e transparente para os usuários, a TI
precisa, de fato, gerenciar o ciclo de vida das suas aplicações. Consequentemente,
exige-se que as equipes de desenvolvimento e de operações assegurem a
implantação bem sucedida de aplicações de software. A fim de que isto se torne
realidade, é necessário diminuir o tempo exigido para suas implantações, aumentar
a confiabilidade e rastreabilidade em mudanças de software. A meta é reduzir a
probabilidade de erros manuais durante as atividades operacionais de entrega de
serviços de negócio.
Ter uma visão clara das dependências é vital para impedir o caos na
infraestrutura após uma atualização ou inclusão de novos serviços. O gestor de TI
precisa saber, com precisão, se o seu Datacenter está preparado para colocar no ar
uma determinada aplicação. Ele deve ter mecanismos que o apóiem a tomar a
decisão de adquirir ou não mais recursos para a sua infraestrutura.
Resumindo, alguns dos principais problemas que a TI enfrenta hoje são
resolver a questão da inadequada interação entre as equipes de desenvolvimento e
produção, agilizar a implantação de serviços e monitorar todo o ciclo de vida das
aplicações.
Como uma forma de resolver esses problemas, o mercado corporativo de TI
vem adotando melhores práticas no gerenciamento de serviços. O ITIL, a biblioteca
de infraestrutura de TI, é um exemplo de melhor prática de gerenciamento de
serviços em TI.
Este trabalho estuda como a função de gerenciamento de aplicações do ITIL
pode contribuir para a resolução dos problemas citados. Para isso, os processos
relacionados a esta função são analisados.
Para ilustrar o estudo, o caso do Tribunal de Justiça de Pernambuco é
apresentado e discutido. Esta monografia analisa procedimentos atuais e propõe

15

melhorias. Sugere a formalização de mecanismos que visem melhorar a forma como
a TI entrega seus serviços
O capítulo 2 introduz os conceitos de serviços e de gerenciamento de
serviços de TI. O ITIL versão 3 é abordado como a biblioteca de melhores práticas
para implementar o gerenciamento de serviços de TI. São abordados os cinco livros
do ITIL versão 3 segundo um modelo de Ciclo de Vida de Serviços.
O capítulo 3 apresenta os conceitos do Gerenciamento de Aplicações. É
apresentado o Ciclo de Vida do Gerenciamento de Aplicações. Também são
apresentados os processos relacionados à Função do Gerenciamento de
Aplicações.
O capítulo 4 descreve o cenário atual em que se encontra a Secretaria de
Tecnologia da Informação e Comunicação no Tribunal de Justiça de Pernambuco.
Contempla ainda as propostas baseadas no ITIL versão 3 e em práticas já adotadas
pelo mercado de TI.
O capítulo 5 apresenta as considerações finais do trabalho. São listadas
também as limitações do estudo e algumas sugestões para trabalhos futuros.

16

2 Gerenciamento de Serviços de TI

Este capítulo apresenta os conceitos de serviços e de gerenciamento de
serviços numa abordagem baseada na biblioteca de melhores práticas do ITIL
versão 3.
Na primeira seção, explica-se qual a relação existente entre o
gerenciamento de serviços de TI e o negócio. Na segunda seção, é apresentada a
biblioteca de melhores práticas do ITIL e seus conceitos básicos. Ainda nesta seção,
é abordado o modelo de ciclo de vida de serviços. As seções seguintes abordam os
estágios do ciclo de vida de serviços.

2.1 Visão Geral

Um serviço é um meio de entregar valor aos clientes, facilitando os
resultados que os clientes querem alcançar. Um conjunto de serviços precisa ser
efetivamente gerenciado de forma que possam agregar maior valor à empresa. Um
serviço é composto, indivisivelmente, por pessoas, processos, e tecnologia
(infraestrutura, incluindo aplicações). Indivisivelmente porque mudanças em
qualquer um desses componentes irão afetar a forma como o serviço é prestado.
O Gerenciamento de serviços é um conjunto especializado de capacidades
organizacionais para fornecer valor para o cliente em forma de serviços. Os clientes
ficam livres para focar na real competência do negócio. Torna-se estratégico para a
organização quando está alinhado ao negócio e é bem administrado, e ainda um
diferencial competitivo no que se refere ao atendimento dos usuários.
Estas capacidades compreendem as competências das organizações e
competências para executar as ações necessárias para a empresa. É suportada
pelos profissionais e seus conhecimentos. Ressalta-se que um bom gerenciamento
de serviços implica em constante manutenção, monitoramento e melhoria dos
recursos organizacionais, representados por processos, pessoas, produtos e
parceiros.

17

O ato de transformar recursos em serviços valiosos é a chave do
Gerenciamento de Serviços. Sem essas capacidades, a organização dos serviços
será somente um conjunto de recursos que por si só tem pouco valor intrínseco para
os clientes.
Para uma organização funcionar efetivamente, ela tem de identificar e
gerenciar numerosas atividades interligadas. Uma atividade pode ser vista como
processo se ela, através do uso de recursos organizacionais, é gerenciada a fim de
possibilitar a transformação de entradas em saídas. Frequentemente, a saída de um
processo se torna uma entrada para outro processo.
A figura 1 mostra a relação entre o negócio, os serviços prestados por TI, e
os serviços, processos e contratos envolvidos:

Figura 1 - Relação entre negócio e serviços prestados por TI

Processos surgem num cenário secular no qual a forma de trabalho
fragmenta e não coopera de forma eficiente o desempenho final da organização.
Aos poucos, vai-se perdendo a noção de que a organização é o fim, e o objetivo final
só é alcançado com o bom trabalho conjunto de todos os diferentes setores
envolvidos na produção do resultado.
Processos ajudam a reduzir os erros e desperdício de tempo por
transferências de atividades entre os diversos setores envolvendo hierarquias
funcionais, através dos quais cada setor se preocupa isoladamente com seu bom
desempenho.

18

Processos são bens estratégicos quando criam vantagens competitivas e
diferenciação no mercado, ajudando a organizar o trabalho de forma melhor.
Tendo isso em vista, os processos de negócio são atividades inerentes ao
negócio, e usam os serviços oferecidos pela TI como mecanismos para atingir os
objetivos definidos pela organização.
Cada serviço de negócio pode ser visto como um processo único, pois é
dessa forma que é percebido pelos clientes, ainda que sejam serviços complexos e
de implementação distribuída. Caso ocorra uma falha de qualquer um dos ativos
constituintes do conjunto de ativos pertencente a esta solução, o usuário percebe a
falha do serviço como um todo.
Definem-se contratos, denominados acordos de níveis de serviços (SLA)
entre os clientes e a TI, a fim de se possibilitar uma adequada utilização dos
serviços de negócio por parte dos clientes. A interface com o negócio responsável
pelo contato da TI com os clientes pode ser definida pela organização.
Serviços técnicos e recursos encontram-se no contexto da TI. São os peças
fundamentais de fato que promovem a utilização por parte dos clientes. A agregação
dos mais diversos componentes, desde ativos de rede, área de armazenamentos,
até as aplicações, formam uma solução denominada serviço.
Definem-se também internamente entre as áreas de TI contratos chamados
acordos de nível operacional (OLA – Operational Level Agreement). Normalmente
são também celebrados contratos com terceiros, relativos a suporte técnico e de
manutenção de softwares e de infraestrutura de apoio, denominados contratos de
suporte (UC).

2.2 ITIL

Nesta seção, cada estágio do ciclo de vida do ITIL é apresentado, sem a
pretensão de detalhar todos os seus aspectos.
A primeira subseção cobre o estágio de Estratégia de Serviço. As subseções
seguintes apresentam os estágios de Desenho de Serviço, Transição de Serviço e
Operação de Serviço, respectivamente.

19

2.2.1 Visão Geral

O ITIL, biblioteca de infraestrutura de TI, é uma melhor prática para
gerenciamento de serviços de TI, de propriedade da OGC (UK Office of Government
Commerce) e gerenciada pela itSMF (IT Service Management Forum). A terceira
versão do ITIL, a que é explorada nesta monografia, foi liberada publicamente em
2007. É mundialmente difundido e adotado como guia para o Gerenciamento de
Serviços de TI (GSTI).
A organização não é submetida ao modelo do ITIL. Cabe aos gestores de TI
analisar em quais combinações e em quais contextos a adequação ao ITIL exige
apenas certo grau de conformidade, e em quais exige um grau mais rígido de
adequação.
O ITIL não define os processos a serem implementados na área de TI. Por
isto, ele pode ser empregado por áreas de TI que já possuam processos orientados
ao Gerenciamento de Serviços de TI. Muitos procedimentos já existentes podem ser
preservados ou adaptados, pois podem já ser a melhor prática para o
desenvolvimento da tarefa ao qual se propõe, no contexto organizacional daquela
área de TI (MAGALHÃES e PINHEIRO, 2007).
O foco desta melhor prática é muito mais forte nos resultados do negócio e
pensa em termos de serviços, e não apenas em processos. Nesta versão, há uma
nova abordagem a partir de uma visão de ciclo de vida de serviços, no qual o
negócio está ativamente envolvido com a meta de aumentar seu valor por meio de
uma integração bem sucedida com a TI.
O ITIL é composto de funções e processos. Uma função é uma equipe ou
grupo de pessoas e de ferramentas usadas para conduzir um ou mais processos ou
atividades. São unidades de organizações auto-suficientes em termos de
capacidade e recursos, e são responsáveis por prover resultados específicos.
Funções tipicamente definem papéis, autoridade e responsabilidades associadas
(OGC ITIL – Service Transition, 2007).
Um processo é um conjunto de atividades que produzem um resultado
específico. Cada atividade é dividida numa sequência de tarefas, cada uma com sua
entrada. Processos, ao contrário de funções, são mensuráveis (ITIL – Service
Transition, 2007).

20

Tarefas possuem procedimentos a serem seguidos. Os procedimentos
cobrem como a tarefa deve ser feita. Uma tarefa possui um responsável pela sua
execução (ator participante do processo, seja ele físico ou etapa automatizada), e
cada responsável tem um papel. No final, é produzida uma saída, que poderá ser a
entrada para outra tarefa ou o resultado final da atividade do qual faz parte.
Processo usa também o conceito de realimentação (feedback) como medida
auto-corretiva, no qual sua saída é usada como sua própria entrada. As saídas de
um processo devem estar alinhadas com seus objetivos.
A figura 2 ilustra o conceito de processo como apresentado:

Figura 2 - Relação entre processo e suas atividades

Processos têm características muito claras e importantes, que precisam ser
estar bem definidas durante toda a sua execução. São mensuráveis quanto a custo,
qualidade, produtividade e dirigido a desempenho. Isto é, gerentes podem controlá-
los através de variáveis.
Possuem resultado específico, que precisa ser nitidamente identificável e
contabilizado. Sempre entregam algum resultado aos clientes, que podem ser
internos ou externos à organização. É vital que o processo satisfaça suas
expectativas.
O Dono do processo é responsável por garantir que o processo atende a um
propósito desejado e é cobrado pelos resultados desse processo. Vale salientar que
todo processo obrigatoriamente tem um dono. As mesmas pessoas podem acumular
a responsabilidade pela execução de mais de uma tarefa, e o gerente do processo
auxilia na coordenação destes papéis (MAGALHÃES e PINHEIRO, 2007).

21

2.2.2 O Modelo de Ciclo de Vida de Serviços

O método de ciclo de vida de serviços do ITIL incorpora e estende a
interpretação do ciclo de qualidade de Deming de Planejar-Fazer-Monitorar-Agir
(Plan-Do-Check-Act), como ilustrado na figura 3:

Figura 3 - O ciclo de Deming no ITIL versão 3

No ITIL, o ciclo de Deming é aplicado em estágios de ciclo de vida do
serviço. Isto ajuda a alinhar as práticas de ITIL à estrutura de práticas que alvejam a
qualidade de serviços, por exemplo. Cabe salientar que o ITIL é arquitetado de
modo a permitir que as capacidades de serviços de uma organização sejam
desenhadas e operadas de forma compatível com a norma ISO/IEC 20000:2005
(OGC The Official Introduction to the ITIL Service Lifecycle, 2007).
Usando o ciclo de vida do serviço como modelo, consegue-se uma visão
mais ampla do GSTI. Esta visão de como TI deve integrar-se com a estratégia de
negócios é a essência proposta pelos cinco livros do ITIL versão 3.
Os elementos do ciclo de vida do serviço continuamente interagem, de forma
que cada parte dele recebe dos outros as entradas dos quais necessitam. Através
do modelo ciclo de vida de serviços, pode-se assegurar que os serviços podem se
adaptar às demandas e mudanças do negócio de acordo com o exigido.

22

O núcleo do ciclo de vida de serviços contempla todas as fases que
compõem um serviço, desde sua concepção até sua operacionalização no ambiente
de produção. A espiral, que se inicia no núcleo e vai se expandindo em constante
rotacionamento, como na figura 4, é movimentada pelo processo de melhoria
contínua do serviço.

Figura 4 - O ciclo de vida de serviços do ITIL versão 3

Este ciclo promove o alinhamento com o negócio e vai se expandido com o
desenho dos serviços. Perpassa pela transição, que garante que os mecanismos
formais estão sendo seguidos e prossegue até que o serviço seja entregue para
operacionalização.
Com o serviço em produção, monitora-se seu estado a fim de possibilitar o
cumprimento do estabelecido com os clientes a respeito dos acordos de níveis de
serviço e acordos de nível operacional.
Por fim, o núcleo está sendo constantemente rotacionado pela melhoria
contínua do serviço, como um motor que impulsiona a adequação dos serviços da TI
ao negócio.
Dentro do ciclo de vida de serviços encontram-se tanto especialização
quanto coordenação. Neste ciclo, existe uma constante realimentação e controle
entre processos e funções, combináveis de acordo com a necessidade da
organização. Dentro de cada estágio, monitoramento, avaliação e realimentação
norteiam decisões sobre correções menores ou iniciativas de melhoramento nos
serviços.

23

2.2.3 O Estágio de Estratégia de Serviço

O estágio de Estratégia de Serviço encontra-se no núcleo do modelo do ciclo
de vida de serviços. O ponto central da discussão coberta é sobre a estratégia a ser
adotada para a oferta de serviços. Os tomadores de decisão são levados a refletir
sobre os aspectos que tornam seus serviços únicos ou difíceis de serem
substituídos no mercado, ou seja, encontrar um espaço de mercado. Para isso, a
organização pode se valer de ferramentas de análise interna e externa da
organização, como Análise SWOT, por exemplo.
O fortalecimento do relacionamento com os clientes irá crescer à medida
que TI, como provedora de serviços, entregar valor aos negócios por meio da
entrega de serviços que representem oportunidades no espaço de mercado. O
próximo passo passa então a ser a confecção de um plano de negócios, contendo
um conjunto de ações, que guiará como o serviço será lançado para entregar valor
ao negócio.
Durante esta fase é definido o portfólio de serviços. Ele contém os acordos
contratuais atuais, plano financeiro, estudo de viabilidade e de retorno de
investimentos, os novos serviços a serem desenvolvidos, a melhoria dos serviços já
em produção, além dos serviços terceirizados (OGC The Official Introduction to the
ITIL Service Lifecycle, 2007). Todos os projetos que entram, continuam e saem do
ciclo de vida de serviços precisam da aprovação contida no portfólio de serviços. Por
fim, inclui também o catálogo de serviços.
O catálogo de serviços é o subconjunto do portfólio de serviços visível aos
clientes. Consiste de serviços ativos no estágio de Operação de Serviços e daqueles
aprovados para serem oferecidos aos clientes atuais ou potenciais (OGC The
Official Introduction to the ITIL Service Lifecycle, 2007). A importância do catálogo de
serviços neste estágio reside no fato de que ele representa as capacidades atuais e
reais do provedor de serviços.
Neste passo, é avaliado se o Portfólio já contempla algum serviço que
satisfaça à nova demanda do negócio, ou ainda se algum serviço prestes a ser
disponibilizado possa suprir esta demanda. Caso contrário, é feito um estudo sobre

24

a capacidade atual, e financeira, de TI suportar a oferta de mais um serviço ainda
não contido no Portfólio. Isso é feito em conjunto com o Gerenciamento Financeiro.
O Gerenciamento financeiro passa a trabalhar em conjunto com TI e o
negócio para apoiar na atividade de atribuir valor aos serviços, seja com custos de
licenças, taxas anuais de manutenção de hardware ou software ou pessoal de
suporte. A estratégia de Outsourcing também deve ser levada em conta, quando o
custo de gerenciar os serviços é maior do que o valor retornado por ele. Assegura-
se, assim, o financiamento apropriado para a entrega de serviços.
A figura 5 ilustra que o gatilho para os processos de Estratégia de Serviços é
a estratégia de negócio desejada. Por fim, conclui-se com o mapeamento de um
serviço e o provimento de um pacote de Nível de Serviço (SLP – Service Level
Package), que dá início aos processos de Desenho de Serviços.

Figura 5 – Elementos da Estratégia de Serviços

2.2.4 O Estágio de Desenho de Serviço

Este estágio recebe como entrada um Pacote de Nível de Serviço, contendo
requisitos identificados e acordados no estágio de Estratégia de Serviços. Em
seguida, é feito o desenho da arquitetura tecnológica a ser usada. Analisam-se os
requisitos funcionais e todos os requisitos operacionais. Estabelece-se uma
adequação do serviço à arquitetura corporativa como política tecnológica e gerencial
para os serviços, permitindo melhor adequação a futuras integrações com outros
serviços e redução do Custo Total de Propriedade (TCO – Total Cost of Ownership).
São investigados todos os impactos envolvidos quando é solicitado o
desenvolvimento de uma nova aplicação ou uma mudança em qualquer elemento de
outra já existente
Através do processo de Gerenciamento de Capacidade, é realizado um
planejamento das necessidades atuais e futuras do negócio em termos de
desempenho e capacidade de armazenamento. Este processo é referenciado para

25

se conhecer o potencial de entrega de novos serviços. Além disso, preocupa-se com
a manutenção dos SLAs e OLAs, com o acordado no Portfólio de Serviços, com o
apoio à resolução de incidentes e problemas relacionados ao desempenho de
componentes e serviços, e com o melhoramento proativo do desempenho destes
sempre que tiverem um custo justificável.
Assim como o processo anterior, o processo de Gerenciamento de
Disponibilidade também é responsável pela atividade proativa de manutenção de
SLAs e OLAs relativos à disponibilidade do serviço. Envolve o monitoramento e
análise reativa de todos os eventos, incidentes e problemas com indisponibilidade de
serviços ou de componentes, assegurando a menor duração possível do impacto
sobre o negócio.
Um dos aspectos deste estágio é o desenho do Portfólio de Serviços como
uma das ferramentas para o gerenciamento e controle do serviço durante todo o seu
ciclo de vida. Salienta-se que os requisitos para os serviços são extraídos do
Portfólio de Serviços e tudo que é acordado é comparado com as estratégias e
restrições a partir do que foi definido no estágio anterior (Estratégia de Serviços).
É durante o estágio de Desenho de Serviços que é construído e mantido o
catálogo de serviços. O catálogo de serviços fornece uma visão do ponto de vista do
cliente dos serviços de TI, retratando os processos de negócio que eles suportam e
os níveis de serviços que eles podem esperar de cada serviço.
O gerenciamento do catálogo de serviços também fornece suporte ao
sistema de gerenciamento de configuração (CMS – Configuration Management
System), estruturando a hierarquização de serviços, promovendo relacionamento
entre serviços, incidentes e mudanças nos serviços afetados. Esta integração
possibilita o monitoramento mais eficiente dos serviços.
O Gerenciamento de Nível de Serviços (SLM – Service Level Management)
é feito com base nas informações contidas no portfólio e no catálogo de serviços.
Negociam-se e documentam-se as expectativas dos clientes representantes do
negócio com relação aos serviços oferecidos por TI. O SLM garante que todos os
serviços possuem algum mecanismo de mensuração. Isto permite o monitoramento
dos SLAs sobre a fidelidade dos serviços oferecidos por TI ao alinhamento com os
requisitos do negócio e o acordado com os clientes em termos de qualidade de
serviço. Contratos de suporte também são revisados.

26

O julgamento da eficiência e eficácia das atividades de SLM é feito por meio
de KPIs (Key Performance Indicator) e métricas. De acordo com o acompanhamento
fornecido por estes indicadores, são produzidos relatórios cobrindo tanto aspectos
objetivos, como percentual de serviços tendo métricas sendo atingidas, quanto
subjetivos, mensurando nível de satisfação dos clientes.
De forma complementar, os processos são desenhados para permitirem a
inclusão de controles necessários para a sua mensuração. Posteriormente, avaliam-
se e gerenciam-se os riscos associados à imaturidade de alguns processos ou da
insuficiência de treinamento e orçamento.
Percebe-se a importância sobre a proteção das informações pertencentes ao
negócio. É durante este estágio que são desenvolvidos e mantidos documentos de
políticas de TI. As instruções sobre o que deve ser protegido e em qual nível de
proteção devem vir do negócio. O Gerenciamento de Segurança da Informação deve
tratar os processos de negócio de ponta a ponta a fim de que a segurança seja
efetiva. Durante este estágio, o ITSCM envolve-se com medidas de redução de risco
e opções de recuperação em caso de desastres envolvendo a paralisação da área
de TI do negócio
Por fim, o Gerenciamento de Fornecedor, presente em todas as fases do
ciclo de vida de serviços, é o processo responsável por garantir que todos os
contratos com fornecedores suportem a necessidade do negócio e que todos os
fornecedores atendam suas obrigações contratuais.
A figura 6 elenca as atividades durante o estágio de Desenho de Serviço.

Figura 6 – Elementos do Desenho de Serviços

2.2.5 O Estágio de Transição de Serviço

Em linhas gerais, a proposta deste estágio do ciclo de vida de serviços é
entregar um serviço, conforme especificado no estágio anterior, de forma que possa
ser devidamente executado e gerenciado no estágio de Operação de Serviço.

27

Este processo recebe como entrada o Pacote de Desenho de Serviço (SDP
– Service Design Package), que inclui várias informações, dentre elas a
especificação do serviço, projeto da arquitetura do serviço, projeto detalhado da
integração dos componentes do pacote da liberação, planos de liberação e
implantação e critérios de aceitação do serviço.
O primeiro passo é executar o processo de Planejamento e Suporte da
Transição, responsável pelo planejamento de todos os outros processos envolvidos
neste estágio e a utilização de recursos que eles requerem. Os recursos devem ser
coordenados de tal forma que se obtenha uma implantação bem sucedida de um
serviço no ambiente de produção dentro de custo e qualidade previstos e no prazo
estimado.
Embora o Desenho de Serviço forneça o plano inicial, o gerente de projeto
alocará recursos específicos às atividades e modificará o plano para se adequar a
quaisquer novas circunstâncias, de acordo com o plano de Transição de Serviço.
Um plano de Transição de Serviço descreve as tarefas e atividades
requeridas para construir, testar, implantar, avaliar proativamente melhorar um
serviço através do Suporte para Período de Tempo Experimental (ELS - Early Life
Support)3. Este plano também inclui a programação de marcos de projeto e datas de
entregas, pessoal e recursos para alocação e orçamento, além dos riscos a serem
gerenciados.
Com o planejamento da transição concluído, quaisquer Requisições de
Mudança (RFC – Request For Change) existentes passam a ser coordenadas pelo
processo de Gerenciamento de Mudança. Fica a seu encargo reduzir o número de
incidentes ou paradas por falhas em serviços. Este processo prioriza a extinção ou
diminuição de falhas ocasionadas por mudanças emergenciais ou não planejadas,
que contribuem para a diminuição da produtividade uma vez que requerem esforço
coletivo voltado para a resolução da falha. Com isso, o tempo médio para restaurar o
serviço (MTRS) é reduzido, pois a implementação da mudança é concluída de forma
mais rápida e satisfatória.
Uma RFC adotará um modelo de mudança de acordo com o tipo da
mudança. O modelo de mudança padrão é normalmente usado para mudanças de
manutenção operacionais e envolvem mudanças pré-autorizadas, repetitivas, de

3
O suporte fornecido para um serviço de TI novo ou modificado por um período de tempo após ele ter
sido liberado. (OGCb, 2007, p.16)

28

baixo risco e bem testadas. O modelo de mudança normal define um fluxo mais
complexo e inclui reunião e autorização por parte do Comitê de Mudança (CAB –
Change Advisory Board)4 antes da implementação. O modelo de mudança
emergencial é usado somente para mudanças necessárias a fim de restaurar um
serviço altamente crítico ou que previne uma falha iminente deste serviço.
Após as mudanças terem sido implementadas, é fundamental o seu registro.
A fim de contribuir com o suporte a mudanças, o processo de Gerenciamento de
Configuração e Ativos é responsável por registrar e manter as configurações
específicas de cada Item de Configuração (CI – Configuration Item) entregando um
serviço e a dependência ou relacionamento existente entre os itens que colaboram
para a entrega de serviços.
Isso é suportado por meio de um sistema de gerenciamento de configuração
(CMS – Configuration Management System). Este sistema utiliza uma Base de
Dados do Gerenciamento de Configuração (CMDB – Configuration Management
Database), que guarda informações sobre CIs, podendo incluir desde configuração
de um componente de hardware até documentação sobre SLAs e contratos de
suporte de um serviço. A CMDB também mantém informações sobre os
relacionamentos entre todos os componentes de um serviço e quaisquer
documentações relacionadas sobre incidentes, problemas, erros conhecidos,
mudanças ou liberações. O CMS é usado pelo Service Desk (Central de Serviços) e
por outros processos de gerenciamento de serviço tais como o gerenciamento de
mudança e o gerenciamento de disponibilidade e continuidade.
Uma vez analisada o impacto da mudança, e atualizada a documentação
sobre os componentes do serviço, o próximo processo executado deve conduzir
todo o caminho desde a implementação até a implantação. Isto é feito através do
processo de Liberação e Implantação.
Este processo deve assegurar que um pacote de liberação pode ser
construído, testado e implantado eficientemente em seus respectivos ambientes,
provendo os recursos capazes de entregar os serviços de acordo com os requisitos
de serviços.

4
Um grupo que aconselha o Gerente de Mudanças na avaliação de impactos, priorização e
agendamento das mudanças. (OGCb, 2007, p.9)

29

Ao fim da implementação e testes prévios, o processo de Validação e Teste
de Liberações de Serviço fica responsável por controlar os ambientes de
empacotamento (construção do pacote) e teste. É fundamental que estes ambientes
sejam dedicados.
Os componentes constituindo um serviço geralmente são produzidos por
fornecedores diferentes. Isto faz com que a padronização dos ambientes seja de
extrema importância a fim de facilitar a integração entre estas soluções.
É interessante automatizar a instalação de sistemas e softwares aplicativos
nos servidores. É reduzida, assim, a dependência de pessoas e aumenta-se o
controle e precisão dos procedimentos de instalação. Outro meio de dar maior
garantia na implantação de uma liberação é replicar a infraestrutura do ambiente de
produção para um ambiente de testes.
A figura 7 ilustra, de forma condensada, os elementos envolvidos no estágio
da Transição de Serviço.

Figura 7 – Elementos da Transição de Serviço

2.2.6 O Estágio de Operação de Serviço

O objetivo primordial deste estágio é entregar e suportar serviços de TI. A
finalidade do gerenciamento de infraestrutura e das atividades operacionais deve
sempre ser voltada para o suporte aos serviços.
Existe um trabalho em conjunto com a Transição de Serviço durante o
período inicial em produção (Early Life Support). Nesta etapa o monitoramento é
feito a fim de acompanhar eventos e incidentes sobre questões despercebidas
durante as fases de testes e de piloto do projeto, ou até de acompanhar problemas
já conhecidos que entraram na liberação do serviço.
Durante este período, podem ser gerados eventos, que são notificações
oriundas de um serviço de TI, item de configuração ou ferramenta de
monitoramento. Os eventos precisam ser avaliados, pois podem indicar a ocorrência

30

de um iminente incidente, desvio no funcionamento normal de um serviço ou
infraestrutura, mudanças de temperatura, proximidade de expiração de licença de
software, entre outros aspectos.
Visando este controle, o processo de Gerenciamento de Eventos é
responsável por monitorar qualquer aspecto do gerenciamento de serviços que
precisa ser controlado e que pode ser automatizado. Este processo pode ser
integrado com os processos de Gerenciamento de Disponibilidade ou de
Capacidade.
Há eventos indicam a interrupção de algum serviço. Estes eventos podem
ter sido notificados diretamente por usuários, pela Central de Serviços ou pelo
processo de gerenciamento de Eventos. O processo de Gerenciamento de
Incidentes trata desta questão.
Quando a causa de um ou mais incidentes é desconhecida, depara-se então
com um problema. Devido a isto, o processo de Gerenciamento de Problemas fica
encarregado de gerenciar o ciclo de vida de todos os problemas. Seu objetivo básico
é eliminar a ocorrência de incidentes recorrentes e minimizar o impacto de
incidentes que não podem ser prevenidos.
Através de um forte relacionamento com os processos de Gerenciamento de
Mudança e de Gerenciamento de Liberação e Implantação, garante-se a devida
implementação da correção. Em casos mais urgentes, pode-se implementar uma
solução de contorno, através de uma RFC emergencial. Entretanto, é imprescindível
que o trabalho para resolver a questão de uma forma permanente continue em
seguida. A solução de contorno deve ser documentada no registro do problema, e
este deve permanecer em aberto até que esta atividade termine.
Para acompanhamento de todas as ocorrências geradas a partir dos
usuários, a função de Central de Serviços (Service Desk) se situa como o ponto
único de contato para os usuários de TI e é responsável por tratar todos os
Incidentes e Requisições de Serviço. A Central provê os primeiros diagnósticos,
resolvem os Incidentes e requisições de Serviços de que forem capazes e escalam
os demais.
Cabe à Central de Serviços manter os usuários informados do progresso de
incidentes. O Gerente da Central de Serviços fica responsável por tomar a
responsabilidade geral sobre Incidentes e Requisições de Serviços.

31

Para pleno uso dos serviços e gerenciamento da Central de Serviços, estes
precisam estar publicados no Catálogo de Serviços e de forma facilmente acessível
aos usuários. É preciso também que já tenha sido definido o nível de autorização de
acesso a determinadas requisições.
Normalmente usuários são associados a papéis ou perfis, e grupos são
criados para conter usuários pertencentes a um mesmo perfil de acesso.
Corriqueiramente é necessário prover, remover ou restringir direitos de acesso.
É da responsabilidade do processo de Gerenciamento de Acesso prover o
gerenciamento de confidencialidade, disponibilidade e integridade dos dados e da
propriedade intelectual da organização. O acionamento deste processo pode
também partir de uma Requisição de Serviço. As equipes envolvidas com este
processo normalmente se situam na área operacional e fica a cargo das funções
Técnica e de Gerenciamento de Aplicações.
A função de Gerenciamento Técnico é assumida por equipes que fornecem
o conhecimento técnico e gerenciam a infraestrutura de TI. Detém o conhecimento
para o desenho, teste, gerenciamento e melhoria da infraestrutura de TI e assegura
que recursos humanos são treinados para gerenciar a tecnologia.
A função de Gerenciamento de Operações de TI é responsável pelo
gerenciamento e manutenção da infraestrutura de TI a fim de assegurar a entrega
do nível acordado de serviços de TI ao negócio.
A função de Gerenciamento de Aplicações é responsável por gerenciar
aplicativos durante todo o seu ciclo de vida, além de gerenciar também aplicações
adquiridas de terceiros. Esta função desempenha um importante papel no desenho,
teste e melhoria de aplicações que constituem serviços de TI.
A equipe de Gerenciamento de Aplicações orienta as equipes da função de
Gerenciamento de Operações de TI sobre como devem controlar o ambiente
operacional a fim de atingir estabilidade e ótimo desempenho para as aplicações.
Por fim, é uma boa prática que o pessoal operacional esteja envolvido desde
as etapas iniciais dos projetos. Particularmente, é fundamental que nos estágios de
Desenho de Serviço e Transição de Serviço este envolvimento aconteça a fim de
assegurar os níveis corretos acordados e esperados dos requisitos de serviços. Este
relacionamento leva a uma maior garantia de que a operação do serviço possa ter
um suporte melhor no futuro dos pontos de vista tecnológico e contratual.

32

A figura 8 exibe os elementos da Operação de Serviços.

Figura 8 – Elementos da Operação de Serviço

2.2.7 O Estágio de Melhoria Contínua de Serviço

O estágio de Melhoria Contínua do Serviço (CSI – Continual Service
Improment) surge da necessidade de adequar os serviços de TI às necessidades do
negócio sempre em mutação. Este estágio é responsável por avaliar e melhorar a
qualidade dos serviços, a maturidade do Ciclo de Vida dos Serviços e dos seus
processos constituintes, procurando formas de melhorar a eficiência e a eficácia
destes, inclusive no que diz respeitos aos custos envolvidos.
Entende-se por melhoria toda avaliação feita por meio de métricas ao se
comparar o valor atual da métrica com o seu valor em algum estado anterior. A partir
dessa comparação, pode-se obter um incremento de uma métrica desejada ou uma
diminuição do valor de uma métrica indesejada.
Fica também a cargo do CSI, fornecer uma avaliação final de tendências de
modo a assegurar que os SLAs estão sendo cumpridos, checar se as saídas dos
processos estão gerando os resultados esperados, conduzir avaliações de níveis de
maturidade das atividades dos processos e conduzir estudos periódicos de
satisfação dos clientes. Vale salientar que a equipe responsável pelas atividades de
Melhoria Contínua de Serviço deve possuir a autoridade necessária para exercerem
suas funções.
O processo é constituído basicamente de seis passos. Através do
entendimento dos objetivos do negócio, procura-se garantir que a estratégia de TI
esteja alinhada com o negócio. Avalia-se a situação atual (baseline) das pessoas,
processos e tecnologia.
A partir disso, estimam-se, com medidas tangíveis e a partir dos requisitos
do negócio, as possíveis métricas a serem utilizadas. Com as métricas, passa-se a
monitorar e a coletar os dados. Há métricas de tecnologia, que envolvem

33

componentes de aplicações, mais voltadas para análise de desempenho e
disponibilidade. Há também métricas de processos, que envolvem Principais
Indicadores de Desempenho (KPI – Key Performance Indicator) e dizem respeito a
conformidade e desempenho de processos. As métricas de tecnologia podem ser
usadas como métricas para serviços.
O trabalho da equipe encarregada de executar as atividades do processo de
Melhoria Contínua se estende por todo o Ciclo de Vida de Serviços. O
monitoramento e a coleta de dados perpassam o estágio de Estratégia de Serviço,
no qual são monitoradas as implementações das estratégias e decisões políticas
tomadas.
No estágio de Desenho de Serviço, monitoram-se as atividades referentes a
criação e modificação de serviços e processos de gerenciamento de serviços. Estão
incluídas a eficácia e a habilidade de medir os Fatores Críticos de Sucesso (CSF –
Critical Success Factor) e KPIs definidos ao se analisar os requisitos de negócio. Por
fim, também se atenta para o progresso dos projetos e de seus marcos, bem como
dos seus resultados.
No estágio de Transição de Serviço, desenvolvem-se os procedimentos e
critérios de monitoramento a serem usados durante e após a implementação. É da
responsabilidade do CSI durante este estágio garantir que os serviços e os
processos de gerenciamento de serviços são gerenciáveis de acordos com as
estratégias e planejamentos traçados.
No estágio de Operação de Serviço, o processo de Melhoria Contínua de
Serviço é responsável pelo monitoramento dos serviços no ambiente de produção.
Verificam-se quais métricas estão adequadas de forma a garantir que os
marcos de projeto almejados foram atingidos, os processos estão em conformidade
e que os objetivos do negócio foram atingidos. A partir de então, é produzido o plano
de CSI.
A figura 9 exibe os elementos da Melhoria Contínua de Serviços.

Figura 9 – Elementos da Melhoria Contínua de Serviço

34

3 O Gerenciamento de Aplicações

Este capítulo apresenta os conceitos do Gerenciamento de Aplicações numa
abordagem baseada na biblioteca de melhores práticas do ITIL versão 3.
Na primeira seção, explica-se o Ciclo de Vida do Gerenciamento de
Aplicações. Na segunda seção, são apresentados os papéis e responsabilidades
envolvidos.
Na terceira seção, são apresentados os processos relacionados à Função
do Gerenciamento de Aplicações. Ainda nesta seção, foca-se no Processo de
Gerenciamento de Liberação e Implantação e nas suas fases.

3.1 Visão Geral

Aplicações têm se tornado elementos cada vez mais críticos dentro uma
organização, uma vez que se tornam parte crítica do negócio. Entretanto, o devido
gerenciamento destas aplicações ainda é uma realidade distante. A TI ainda se
depara com a falta da inclusão do gerenciamento de serviços em todas as fases do
ciclo de vida da aplicação, deixando de levar em conta todos os requisitos não
funcionais que permitem um efetivo uso das aplicações pelos usuários de TI.

3.2 O Ciclo de Vida do Gerenciamento de Aplicações

A abordagem tratada nesta seção para aplicações instancia o ciclo de vida
do serviço do ITIL versão 3. O gerenciamento de aplicações visualiza a aplicação
num ciclo PDCA, indo desde a sua concepção passando pela implantação, até que
se atinja a sua descontinuação. Ao percorrer o ciclo de vida, encontram-se
atividades de desenvolvimento de sistemas - realizadas pelas fases de Requisitos,
Desenho e Construção - e atividades do gerenciamento de serviços de uma
aplicação, realizadas pelas fases de Implantação, Operação e Otimização (OGC
Application Management, 2002).

35

A figura 10 mostra as fases pertencentes ao ciclo de vida do gerenciamento
de aplicações.

Figura 10 – Relacionamentos no gerenciamento de aplicações

O desafio é promover um forte trabalho conjunto, desde o início do projeto,
entre os que criam as aplicações e os que se esforçam para gerenciá-las. Para o
êxito desta abordagem, é vital que, em cada fase, as equipes possam dedicar
especial atenção às questões impactantes na entrega da aplicação (OGC
A fase de Requisitos é a etapa inicial de uma aplicação, na qual os analistas
de negócio se preocupam em identificar, dentre outros aspectos, os níveis de
desempenho esperados pela aplicação. São aspectos que determinam restrições a
um sistema e que não fazem parte do serviço propriamente dito, porém cooperam
para seu uso eficaz. A engenharia de software denomina este tipo de critério como
“requisitos não-funcionais”.
Os requisitos não-funcionais devem guiar o desenho do serviço do ponto de
vista da sua operacionalidade, isto é, do gerenciamento do serviço. A aplicação é
concebida levando em conta os requisitos de desempenho, segurança, entre outros
aspectos. Do ponto de vista do processo de Gerenciamento de Liberação e
Implantação, devem ser já levantados requisitos de interoperabilidade com sistemas
externos (OGC Application Management, 2002).

36

É na fase de Desenho que os requisitos da aplicação são escritos em termos
de especificações, que fornecerão os detalhes necessários para se construir a
aplicação. O desenho do serviço determinará a arquitetura ideal para a solução.
Nesta fase é feito um mapeamento em termos de componentes físicos. Este
mapeamento permite o dimensionamento da aplicação para a infraestrutura na qual
ela precisa ser executada.
Do ponto de vista do processo de Gerenciamento de Liberação e
Implantação, os arquitetos de software devem levar em conta os procedimentos e
ferramentas usadas para liberar aplicações no ambiente de produção. De forma
complementar, o desenho da solução dada para a liberação deve propiciar uma
forma simples e eficiente para implantar a aplicação (OGC Application Management,
2002).
Na fase de Construção, o modelo de arquitetura produzido na fase anterior é
mapeado para a codificação em alguma linguagem de programação. Com o
gerenciamento de serviços em mente, a atividade de codificação deve ser feita com
foco nos requisitos não-funcionais.
Pode-se definir um padrão de codificação, por meio do qual é adotada uma
convenção de codificação independente da linguagem de programação escolhida.
Habilita-se, assim, o gerenciamento da aplicação e às ferramentas de
gerenciamento é fornecida a capacidade de interagir com a aplicação.
Esta fase deve possuir uma etapa de testes antes da implantação da
aplicação. Nesta etapa, o gerenciamento de serviços deve exigir que o plano de
teste contemple os requisitos não-funcionais com o mesmo rigor aplicado aos
requisitos funcionais. Convém ressaltar que a cada iteração no ciclo do
gerenciamento de aplicações, uma nova etapa de testes é requerida.
A fim de tornar o ambiente de testes o mais próximo possível do ambiente
de produção, ambos devem ser colocados sob a supervisão dos processos de
Gerenciamento de Configuração e de Gerenciamento de Mudança (OGC Application
Management, 2002).
Implantação, a construção e os testes devem assegurar que a aplicação é
implantada de uma forma simples e eficiente (OGC Application Management, 2002).
Em seguida, tem-se a fase de implantação, no qual é feito o planejamento
para a aplicação entrar no ambiente de produção. Para que a implantação tenha

37

êxito, é essencial que ele seja conduzido por um guia respondido por perguntas
críticas.
Este guia deve conter um checklist e um cronograma. Além disto, deve
contemplar detalhadamente todas as atividades e responsabilidades, inclusive as
atividades que devem ser seguidas em caso de desfazer a implantação da aplicação
(roll-back) (OGC Application Management, 2002).
A tabela 1 descreve as perguntas críticas para um documento de
implantação.

Tabela 1 – Perguntas Críticas para documento de Implantação
CONTEXTO PERGUNTAS CRÍTICAS
A equipe responsável detém toda a experiência necessária
para implantar a aplicação?
Alvo da implantação Sabem-se exatamente quais são todos os componentes ou
módulos que constituem a aplicação?
As regras de negócio para a implantação estão
documentadas?
Usuários Quais usuários e departamentos são afetados?
Eles precisarão de treinamento para usarem a nova versão?
Localização dos usuários Existem usuários remotos? Como eles serão afetados?
Cronograma O Cronograma foi definido? Ele admite flexibilidade ou é
rígido?
Motivo A finalidade da implantação é corrigir problemas ou estender
a funcionalidade?
Critérios de aceitação Foi definido quem decidirá se a implantação está concluída?

Antes de ser dado o início à implantação propriamente dita, é necessário
que o Comitê de Mudança (CAB), através do acionamento do processo de
Gerenciamento de Mudança, aprove a mudança e avise a todos os impactados.
Após todo o conjunto de testes ter sido bem sucedido no ambiente de testes,
o passo seguinte é proceder com a implantação piloto. Primeiro é criado o
documento do Plano de Implantação Piloto. O plano contém as funcionalidades a
serem disponibilizadas, um cronograma, uma lista de atividades com seus
responsáveis e um checklist de ações. A tabela 2 descreve alguns dos componentes
do checklist do Plano de Implantação Piloto (OGC Application Management, 2002).
Nesta etapa, apenas um subconjunto das funcionalidades é disponibilizada
para um primeiro contato dos usuários. Um dos objetivos é colher um feedback dos
sistema com relação a ajustes nos treinamentos dos usuários. A validação dos
requisitos não-funcionais também deve ser feita, possibilitando a adequação dos

38

parâmetros relativos ao desempenho da aplicação no ambiente de produção e a
devida atualização do Plano de Implantação.

Tabela 2 – Exemplo de checklist do Plano de Implantação Piloto
TIPO DA ESTRATÉGIA DECISÕES A TOMAR
Há um procedimento para verificação da correta implantação da
liberação?
Como o piloto será conduzido?
A Central de Serviços foi avisada do Plano de Implantação?
Funcional Há concorrência do Plano de Implantação com alguma
solicitação de mudança na infraestrutura de TI?
O Plano de Roll-back está detalhado e testado?
O horário de Implantação da liberação foi comunicado a todos
os envolvidos?
Os SLAs foram revisados para refletir as condições do serviço
após a implantação?
Treinamento As salas de treinamento estão prontas? Já foram reservadas?
O cronograma de treinamento já foi definido?
Todas as equipes operacionais responsáveis já estão prontas
para a implantação?
Suporte A aplicação já foi mapeada e seu fluxo de suporte já foi
definido?
O procedimento de implantação foi testado?

Implantação, a recomendação é que a aplicação seja liberada de maneira que
minimize os riscos (OGC Application Management, 2002). A observação a ser feita é
que todas as equipes associadas aos processos do ITIL pertinentes existentes na
organização devam ser envolvidos.
A fase seguinte é a Operação. Numa organização, o número de incidentes e
problemas é um diagnóstico da falta de medidas preventivas às aplicações em uso
operacional. Uma das atividades desta fase é gerenciar a expectativa do usuário.
Isto é feito através da mensuração dos SLAs e de pesquisas de satisfação do
usuário.
Cada aplicação está vinculada a um perfil, e é tarefa da equipe operacional,
para cada aplicação, listar as tarefas e a frequência com que precisam ser
realizadas e os seus responsáveis. A tabela 3 lista as atividades e periodicidade
típicas associadas ao acompanhamento de uma aplicação em produção (OGC

39

Tabela 3 – Atividades operacionais típicas de acompanhamento de aplicação
FREQUÊNCIA ATIVIDADE
Diária Verificar RFCs emergenciais
Verificar logs de erros
Verificar eventos gerados pelo monitoramento da aplicação
Atender o Comitê Revisor do Gerenciamento de Mudança
Semanal Promover reuniões com equipe
Criar relatórios de melhoria
Compilar um relatório da situação das aplicações
Mensal Verificar contas do sistema
Verificar situação da recuperação dos dados a partir das mídias
de backup (restore)
Brainstorm com equipe
Aleatória Rever como melhorar processos
Rever mensagens de violações de segurança e alterar
permissões de acesso

Nesta fase também se inclui a condução da avaliação do comportamento da
aplicação, a partir dos pontos de vista do usuário, de nível de serviços, de custos
para sua manutenção e de agregação de valor ao negócio. A informação obtida a
partir desta avaliação pode ser incorporada a um projeto de melhoria da aplicação.
Implantação, é importante assegurar que um membro da equipe (papel) de
Operações participe das reuniões do Gerenciamento de Mudança. Também é
essencial que o processo de Gerenciamento de Liberação e Implantação forneça
toda informação necessária para implantação para o grupo operacional (OGC
A última fase do ciclo, denominada de Otimização, revisa periodicamente a
aplicação já executando em produção. O objetivo é determinar se ela está
funcionando dentro dos padrões de nível de serviço acordados.
Esta fase pode ser iniciada devido ao tempo fixado para sua execução, pelo
processo de Gerenciamento de Problemas, por mudança nos requisitos de negócio,
ou por motivos de infraestrutura.
O processo de avaliação da necessidade de melhoria deve ser conduzido
sob os pontos de vista do usuário, dos processos de negócio e da tecnologia. A
tabela 4 lista os questionamentos desse processo. (OGC Application Management,
2002).

40

Tabela 4 – Perguntas referentes ao processo de revisão da aplicação
PONTO DE VISTA PERGUNTAS
Usuário Existem mudanças requeridas na aplicação para tratar
necessidades dos usuários?
A interface da aplicação pode ser considerada intuitiva?
A aplicação continua a servir ao propósito da missão do
Processo de Negócio negócio?
Os Requisitos de Nível de Serviço mudaram?
Existem questões técnicas impedindo a aplicação de
Tecnologia suportar os níveis de serviço acordados?
Existem melhorias técnicas pendentes que exigem
mudança na aplicação?

Em resposta ao questionário acima, é obtido um relatório mantendo a
aplicação inalterada, requerendo uma RFC, ou a retirada da aplicação de produção.
Implantação, é importante assegurar que a equipe envolvida nesta fase entende o
processo de Liberação. O plano de melhoria deve estar em conformidade com o
processo citado a fim de a aplicação ser implantada com êxito (OGC Application
Management, 2002).

3.3 Papéis e Responsabilidades

Visando garantir a eficácia da implantação das aplicações, é necessário que
o gerenciamento de aplicações seja segmentado de tal forma que sejam criadas
equipes especialistas. Cada equipe assume um papel, que vinculam
responsabilidades inerentes a sua área de atuação.
Vale salientar que cada papel (equipe) contribui em todas as fases do ciclo
de vida da aplicação. O objetivo, como afirmado antes, é envolver o gerenciamento
de serviços no desenvolvimento da aplicação.
As subseções seguintes listam estes papéis e como cada equipe
responsável por eles contribui para a implantação da aplicação (OGC Application
Management, 2002).

41

3.3.1 Configuração e Mudança

Na fase de Requisitos, esta equipe é responsável pela administração da
CMDB. Também se responsabiliza pelo processo de aprovação de RFCs para a
liberação das aplicações.
Na fase de Desenho, sugere aos desenvolvedores como a aplicação pode
transicionar para o ambiente de produção. Além disso, analisa como a aplicação
pode se comunicar com o CMDB de forma automática.
Na fase de Construção, recomenda aos desenvolvedores o desenvolvimento
da aplicação segundo os padrões do gerenciamento de configuração e de mudança.
Ex.: identificação de componentes, controle de versões.
Na fase de Implantação, provê recomendações sobre implantação da
aplicação, através do uso do CMDB, no que diz respeito à configuração do servidor
de aplicação. Também apóia o planejamento da implantação. Por fim, aconselha o
uso da CMDB para rastrear a implantação da aplicação.
Na fase de Operação, trabalha com equipe de operações para assegurar
que a aplicação está em produção com a versão correta e que está corretamente
configurada. Também se preocupa com a atualização da documentação repassada
ao pessoal operacional.
Na fase de Otimização, provê as informações de configuração necessárias
para a realização da avaliação da aplicação. Para possibilitar isto, leva em conta os
processos de Mudança e informação vinda do CMDB.
Além disto, assegura que a equipe de Gerenciamento de Mudança está
ciente das mudanças requeridas pelo relatório de avaliação, caso existam.

3.3.2 Suporte

Na fase de Requisitos, ajuda a fornecer os requisitos para suporte da
aplicação em produção, inclusive para restaurar o serviço. De forma complementar,
provê apoio ao gerenciamento de incidentes e de problemas.
Na fase de Desenho, recomenda o desenho da aplicação suportando
comunicação com Service Desk e gerenciamento de Incidentes e de Problemas

42

Na fase de Construção, trabalha com equipe de testes validando requisitos
não-funcionais e fornecer feedback direto para desenvolvedores
Na fase de Implantação, assegura que o nível correto de recursos está
disponível e que os processos de gerenciamento de incidentes e de problemas são
capazes de lidar com a implantação da aplicação.
Na fase de Operação, trabalha em conjunto com equipe operacional para
tratar incidentes.
Na fase de Otimização, assegura que problemas atuais no ambiente de
produção sejam inseridos no relatório de avaliação. Provê suporte para
implementação das melhorias relatadas.

3.3.3 Operações

Na fase de Requisitos, ajuda a definir os requisitos operacionais da
aplicação.
Na fase de Desenho, assegura o desenho da aplicação com controles
operacionais compatíveis com infraestrutura existente. Fica encarregada de
desenhar o modelo de backup e restore.
Além disso, assegurar que aplicação é desenhada para suportar SLAs e
OLAs e que a documentação da aplicação segue a norma definida pela organização.
Na fase de Construção, participa do teste da aplicação.
Na fase de Implantação, assegura que o ambiente operacional está
preparado para receber a implantação.
Na fase de Operação, gerencia operações diárias e executa atividades de
administração de sistemas. Sua função é ocupar-se de manter a aplicação
funcionando corretamente de acordo com os procedimentos operacionais
acordados.
Na fase de Otimização, apóia o processo de avaliação ao fornecer
informações sobre falhas operacionais na aplicação em produção.

43

3.3.4 Segurança

Na fase de Requisitos, executa atividade de gerenciamento de riscos.
Também é responsável pela criação de um plano de auditoria, retenção,
classificação e eliminação segura de dados.
Na fase de Desenho, assegura que o desenho da aplicação suporta
requisitos de segurança, como, por exemplo, não ser suscetível a ataques de
negação de serviço
Na fase de Construção, assegura que aplicação é construída em
conformidade com padrões de segurança e acompanha conformidade de segurança
durante testes.
Além disso, revisa código e documentação e acompanha decisões sobre
custo-benefício impactando a segurança.
Na fase de Implantação, atenta para o planejamento da implantação.
Na fase de Operação, assegura que aplicações estão sob padrões de
segurança, e promove auditorias periódicas de segurança sobre procedimentos
operacionais e arquivos de logs.
Na fase de Otimização, fornece informações para possibilitar tornar a tanto a
aplicação quanto os dados corporativos mais seguros. Assegura que as mudanças
propostas a serem incluídas no documento de melhoria se adéquam com os
padrões de segurança vigentes.

3.3.5 Infraestrutura

Na fase de Requisitos, atenta para a arquitetura corporativa e novas
exigências tecnológicas demandadas pelo negócio. Também define requisitos para
gerenciamento de capacidade e disponibilidade.
Na fase de Desenho, assegura que o desenho da aplicação trata previsão
com o gerenciamento de capacidade.
Na fase de Construção, apoia a construção de aplicações que suportem o
gerenciamento de capacidade e de disponibilidade. Além disso, ajuda a construir
aplicações de acordo com SLAs definidos na fase de requisitos.

44

Na fase de Implantação, planejar e monitora a capacidade e disponibilidade
do ambiente para que a aplicação seja implantada. Recomenda mudanças para
manutenção inicial dos SLAs.
Na fase de Operação, trabalha em conjunto com equipe de operações para
coletar métricas e propor melhorias. Trabalha em conjunto com pessoal de suporte e
de operações para prover suporte técnico de terceiro nível.
Na fase de Otimização, provê ao planejamento de melhoria recomendações
técnicas sobre capacidade, disponibilidade, tecnologias e ferramentas. Recomenda-
se que esta equipe guie o processo de otimização.

3.4 Processos Relacionados

Os benefícios esperados pela implementação da Função de Gerenciamento
de Aplicações dependem intrinsecamente da maturidade dos processos dos quais
ela depende.
Os processos Gerenciamento de Mudança, Gerenciamento de Configuração
e Gerenciamento de Liberação e Implantação estão diretamente envolvidos no
Gerenciamento de Aplicações. Esse grupo é também denominado de processos de
controle e liberação. Atuam de maneira a introduzir no ambiente operacional de
produção as mudanças aprovadas, com mínimo risco de falha nos serviços de TI. A
figura 11 exibe o inter-relacionamento destes processos (BON e VEEN, 2007).

Figura 11 – Inter-relacionamento entre os processos de Gerenciamento de Mudança, Gerenciamento
de Configuração e Gerenciamento de Liberação e Implantação

45

O processo de Gerenciamento de Liberação e Implantação é o processo
operacional onde todas as mudanças e liberações são preparadas para roll-out
(implantação). Os outros dois processos realizam as funções de controle exigidas
para rodar o processo efetiva e eficientemente.
O processo de Gerenciamento de Mudança determina quais mudanças são
prioritárias e que deverão estar na versão a ser liberada. Fica sob sua
responsabilidade a estratégia de liberação das versões, bem como a produção do
procedimento de Roll-back (MAGALHÃES e PINHEIRO, 2007). Este procedimento é
aplicável a todos os tipos de liberação.
O Plano de Back-out5 contém os procedimentos para restaurar um serviço
após uma mudança mal sucedida, possivelmente por meio da restauração de
baselines6 de Itens de Configuração (CI – Configuration Item) de software e dados
(OGC Service Transition, 2007).
Este plano deve estar intimamente vinculado com quaisquer milestones
(marcos) ou check points dentro do plano de mudança. Ele deve conter diferentes
ações de acordo com qual fase do plano de mudança havia sido concluída quando o
Plano de Back-out foi iniciado (ADDY, 2007). Nos casos em que nem todas as
mudanças forem reversíveis ou voltar ao estado original é indesejável, aplica-se,
como alternativa, o Plano de Remediação (OGC ITIL – Service Transition, 2007).
A eficácia deste processo dependerá da implantação prévia, bem como da
maturidade do processo de Gerenciamento de Configuração.
Além disso, de acordo com o definido pela TI e maturidade deste processo,
o Gerenciamento de Liberação e Implantação pode estar sob o controle e autoridade
do processo de Gerenciamento de Mudança (MAGALHÃES e PINHEIRO, 2007).
Para que seja possível o controle do ambiente, é crítico que existam
informações detalhadas o suficiente sobre ele. Detalhes da infraestrutura e
relacionamentos entre os CIs podem revelar os impactos sobre outros processos de
negócio ao se propor uma mudança. Precisam estar sob seu controle informações
críticas para a liberação e implantação, como histórico de versões, configuração de
parâmetros e configuração dos ativos envolvidos.
5
A literatura costuma também se referir ao Plano de Roll-back como Plano de “Back-out”.
6
Um Baseline captura uma referência autorizada, tais como a estrutura, conteúdo e detalhes de uma
configuração e representa um conjunto de Itens de Configuração que estão relacionados entre si.

46

Tendo isso em vista, o processo de Gerenciamento de Configuração provê
os mecanismos administrativos para que o processo de Gerenciamento de Mudança
controle todas as mudanças e implantações de liberações. Além disso, também
apóia o processo de Gerenciamento de Liberação e Implantação com o
armazenamento, controle e verificação de todos os CIs envolvidos na liberação.
Controles de inventário, tanto de hardware quanto de software, devem ser
automatizados sempre que possível via CMDB. Além disso, podem ser configurados
alertas a serem enviados quando licenças estiverem próximas da sua expiração.
O tamanho da equipe de controle e liberação deve ser proporcional à
demanda da organização. Pode consistir de apenas uma única pessoa ou, de forma
descentralizada, composta por vários integrantes (BON e VEEN, 2007). A partir
deste ponto de vista, fica evidente a necessidade dos papéis, já citados, envolvidos
no Gerenciamento de Aplicações.
A fim de reportar a eficiência e eficácia destes processos, os Fatores Críticos
de Sucesso (CSF – Critical Success Factor) e os Indicadores de Desempenho
Principais (KPI – Key Performance Indicator) devem ser identificados, no máximo de
três, para o primeiro e no máximo de três, para o segundo, por cada CSF (BON e
VEEN, 2007).
O processo de Gerenciamento de Liberação e Implantação, foco da próxima
seção, é o ponto final deste fluxo de aprovação das mudanças até a chegada ao
ambiente de produção.
Estes três processos atuam fortemente no Gerenciamento de Aplicações.
Suas atividades são altamente interdependentes. Isto justifica a necessidade por
uma equipe responsável por estes processos coordenando as equipes de
desenvolvimento e as equipes de operações (BON e VEEN, 2007).

3.5 O Processo de Gerenciamento de Liberação e
Implantação

Este processo é responsável pela implementação das mudanças no ambiente
de infra-estrutura de TI. Itens de Configuração novos ou alterados são testados em
conjunto e finalmente colocados em produção (MAGALHÃES e PINHEIRO, 2007).

47

Conceitualmente, uma liberação (release) é uma mudança significativa na
infra-estrutura de TI e que representa um potencial risco ao negócio e impacto para
a Central de Serviços (MAGALHÃES e PINHEIRO, 2007).
A implantação do processo de Gerenciamento de Liberação e Implantação
deve iniciar de forma simples, focando as liberações consideradas mais críticas para
o negócio (MAGALHÃES e PINHEIRO, 2007). Convém salientar que a TI pode
definir critérios para determinar se uma mudança será implantada no ambiente de
produção usando este processo. Critérios como duração da implementação, número
de usuários afetados e complexidade da mudança podem servir de pontos de
partida para a tomada de decisão.
Levando isto em consideração, o Gerente de Mudança (em conjunto com o
CAB) pode decidir envolver a equipe de Gerenciamento de Liberação e Implantação
na implantação da mudança no ambiente de produção (ADDY, 2007).
Antes do início do fluxo deste processo, as RFCs são revisadas e aprovadas
pelo Gerenciamento de Mudança e, em seguida, coordenadas com o
Gerenciamento de Liberação e Implantação para empacotamento em liberações e
sua distribuição para os sistemas alvo. Salienta-se que apenas versões autorizadas
e testadas sejam instaladas.
A Gerência de Liberação e Implantação é responsável por definir o nível de
controle e rastreabilidade a ser aplicado aos diferentes tipos de ICs. O nível de
controle pode variar de acordo com o risco e as ameaças que os ICs apresentem
para a estabilidade do ambiente de produção (MAGALHÃES e PINHEIRO, 2007).
É também da responsabilidade deste processo coordenar os vários
fornecedores de serviços envolvidos com um número significativo de mudanças de
ICs (MAGALHÃES e PINHEIRO, 2007).
Quanto aos tipos de liberação, a primeira delas, denominada liberação do tipo
“Delta” ou “Parcial”, apenas inclui os CIs dentro da Unidade de Liberação (conjunto
de componentes constituintes de uma liberação) que, de fato, sofreram alteração.
O tipo de liberação “Completa” contempla uma versão completamente nova
de uma aplicação. O tipo de liberação em “Pacote” é uma combinação de várias
Unidades de Liberação dos outros dois tipos, permitindo implantar, ao mesmo
tempo, liberações relacionadas.
Por fim, o tipo liberação de “Emergência” contém correções para um
pequeno número de correções relacionadas a incidentes ou problemas. Deve ser

48

utilizada de forma muito reduzida, pois interrompe o ciclo de liberação e é, por isso,
bastante suscetível a falhas (MAGALHÃES e PINHEIRO, 2007).
O Gerenciamento de Mudança aprova o tipo de mudança a ser feita. Em
consequência, define-se assim o tipo de liberação a ser seguido pelo Gerenciamento
de Liberação e Implantação. Este estreito relacionamento entre os dois processos
permite que ambos compartilhem os riscos envolvidos na implantação desta
liberação (BON e VEEN, 2007).
A política de liberação tem uma importante atribuição dentro do processo.
Esta política define os papéis e responsabilidades, frequência e os padrões de
identificação da liberação. Pode ser um documento único e detalhado, ou apenas
um guia permitindo que documentos específicos por serviço sejam produzidos. Em
ambos os casos, deve estar em conformidade com a política do cliente.
Os componentes de uma liberação precisam ser armazenados de forma
gerenciável e segura. Para tal finalidade, existe um repositório denominado de
Biblioteca de Mídia Definitiva (DML – Definitive Media Library), constituindo-se de
uma área de armazenamento lógica única, mesmo sendo fisicamente distribuída.
Engloba ainda um espaço de armazenamento físico para mídias (OGC ITIL –
Service Transition, 2007).
Contém todas as versões de software aprovadas, sejam elas desenvolvidas
ou adquiridas, além de licenças e documentação. Os seus componentes são
acessados através do Sistema de Gerenciamento de Configuração, registrados e
rastreáveis através da CMDB como CIs (OGC ITIL – Service Transition, 2007).
Convém destacar que apenas softwares provenientes da DML são aceitos
para liberações. É da responsabilidade dos processos de Gerenciamento de
Mudança e de Gerenciamento de Liberação e Implantação o controle destes
softwares.
O Gerente de Liberação, papel mais importante neste processo, é o
responsável pela definição e manutenção da Política de Liberação e controle das
atividades. Deve possuir grande experiência técnica e estar atualizado sobre o
estado da arte em termos de ferramentas de suporte utilizadas no mercado
(MAGALHÃES e PINHEIRO, 2007). Além disso, fica encarregado de popular a DML
e de comunicar as mudanças à Gerência de Configuração.
A Política de Liberação estabelece o conteúdo da Unidade de Liberação. Ela
também define o nível de automação e uso de ferramentas, que deve ser

49

incentivado sempre que possível, a fim de diminuir a probabilidade de erro humano
durante o processo de implantação (roll-out).
Os desenvolvedores não devem ter credenciais de acesso ao ambiente de
produção. Após a geração do build, e sua atualização na DML, o Gerenciamento de
Liberação e Implantação capta a liberação e implanta-a no ambiente de testes
seguindo os procedimentos de roll-out e de roll-back. As novas versões devem
passar por rígidos testes de aceitação do usuário em ambientes espelhando o
máximo possível o ambiente de produção.
O Plano de Liberação deve determinar o escopo (aluguel de hardware, tipo da
liberação, por exemplo), a prioridade, necessidade de capacitação e conformidade
com Política de Liberação. O Plano também deve cobrir a avaliação sobre submeter
a liberação novamente ao Comitê de Mudança.
Cabe ao Gerente de Liberação coordenar o escopo da Liberação,
considerando sua urgência e impacto no cronograma contido no Plano de Liberação.
Seu papel também inclui avaliar perfis dos membros da sua equipe e avaliar
competências.
Geralmente a equipe de liberação é formada por integrantes de setores
diferentes, por isso é importante gerenciar expectativas quanto ao tempo de
resposta das atividades de liberação estabelecendo OLAs.
A figura 12 mostra as atividades do processo de Gerenciamento de Liberação
e Implantação e seu escopo dentro do Ciclo de Vida da Aplicação.

Figura 12 – Atividades do processo de Gerenciamento de Liberação e Implantação

Pode-se deduzir rapidamente que o processo Gerenciamento de Liberação e
Implantação perpassa o Ciclo de Vida da Aplicação, com fases maiores consistindo
de Planejamento e Desenvolvimento, Teste e Implantação.

50

Convém ressaltar que estão fora do escopo deste processo quaisquer
atividades de gerenciamento de projetos e de gerenciamento de contratos. Além
disso, reforça-se que estas atividades não sejam concluídas sem que haja uma
participação da equipe do processo de Gerenciamento de Liberação e Implantação
(MAGALHÃES e PINHEIRO, 2007). As próximas subseções colocam isto de forma
clara ao detalhar as atividades de cada fase deste processo.
Durante esse processo, estão envolvidas outras equipes responsáveis por
aquisição de hardware, software e licenças, de segurança, testes de requisitos
funcionais e não-funcionais, melhoria contínua, relacionamento com usuário (o que
envolve testes de aceitação) e seu treinamento.
A atividade de comunicação precisa ter uma atenção especial. Os usuários e
clientes devem ser mantidos informados sobre o progresso do atendimento das
liberações, por meio da Central de Serviços (MAGALHÃES e PINHEIRO, 2007).
O processo de Gerenciamento de Liberação e Implantação precisa ser
acompanhado pela equipe de Gerência de Serviços de TI. Esta equipe, por meio de
um relatório de gestão das atividades, pode fornecer números para monitoração do
progresso e planejamento do processo (MAGALHÃES e PINHEIRO, 2007).
O relatório pode definir parâmetros sobre o quantitativo de liberações e
correlacioná-los com diversos critérios, tais como tipo, que necessitaram de Roll-
back ou que tiveram sua implantação atrasada. Ainda pode conter informações
sobre crescimento da demanda, utilização de licenças, liberações ainda não-
atendidas (backlog), custos decorrentes com erros nos serviços gerados por
implantações. Pode contemplar ainda indicadores de desempenho (MAGALHÃES e
PINHEIRO, 2007).
A seguir, são descritas as atividades inerentes a cada fase do processo de
Gerenciamento de Liberação e Implantação.

3.5.1 Planejamento da Liberação

A entrada para esta atividade é formada pela RFC autorizada, do documento
da Política de Liberação e da capacitação concluída das equipes envolvidas.

51

Nesta atividade, são criados os documentos de Plano de Liberação, Plano
de Testes e Plano de Comunicação. O Plano de Liberação deve conter um
cronograma de alto nível (submetido à Política de Liberação) e os acordos sobre
papéis e responsabilidades.
Comunicação e treinamento dos usuários são fatores críticos de sucesso
para liberações, e as primeiras atividades devem começar já neste estágio.
É a fase propícia para a obtenção das propostas dos fornecedores de
hardware, software ou serviços. Além disso, pode-se incluir a criação de um plano
de qualidade para cada liberação. Finalmente, o planejamento final passa pela
aceitação da equipe de suporte e do cliente (MAGALHÃES e PINHEIRO, 2007).
A saída desta atividade é composta pelos Planos de Liberação e de Testes,
critérios de aceitação validados. Quanto aos recursos, todo equipamento, software e
licença necessários já devem estar adquiridos, ou ao menos, com data de entrega
confirmada.

3.5.2 Desenvolvimento, Construção e Configuração

A entrada para esta atividade é formada pela RFC, pelas especificações
técnicas e funcionais, recursos e do documento de liberação.
Nesta fase, os preparativos para os treinamentos dos usuários são iniciados.
Dá-se início à criação de scripts de instalação automatizada e elaboração do plano
de Roll-back.
Além disso, uma vez que as propostas já foram obtidas na fase anterior,
procede-se com a emissão dos pedidos de compra, licenças e garantias para os
softwares e hardwares necessários (MAGALHÃES e PINHEIRO, 2007).
A aplicação só é armazenada na DML quando sua implementação está
autorizada pelo Gerenciamento de Mudança e registrado como CI na CMDB pelo
Gerenciamento de Configuração. A partir de então, as liberações desenvolvidas
passam a ser baseadas em uma cópia do software armazenado na DML. Cada nova
liberação passa a ser identificada por um código único para controle e
rastreabilidade (MAGALHÃES e PINHEIRO, 2007).

52

A saída desta atividade é composta pelas instruções detalhadas sobre os
procedimentos de desenho, geração e configuração da liberação. Além disso, ao
término da atividade é produzido o Plano de Roll-back.

3.5.3 Teste

A entrada para esta atividade é formada pelo Plano de Testes, ambiente de
testes espelhando o ambiente de produção. Além disso, é importante que a equipe
de testes não esteja envolvida com a construção do sistema.
É fundamental que o ambiente de testes seja exclusivo. Durante as
atividades desta fase, as soluções de contorno e demais soluções devem ser
documentadas de modo que possam ser repassadas para a equipe de
desenvolvimento.

Os testes devem ser conduzidos de forma a prevenirem qualquer impacto
sobre os Níveis de serviço e Qualidade de Serviço. Isso implica também em poupar
recursos, incluindo tempo para corrigir erros de implementação após uma liberação.
Liberações urgentes podem ser dispensadas de testes completos. Isto deve
estar explicitado no Plano de Comunicação.
Dependendo do Plano de Testes, elaborado na etapa anterior, pode ser
desejável incluir um teste técnico (para requisitos não funcionais) e o Plano de
Testes de Roll-back. Ressalta-se que precisam estar incluídos também os testes de
aceitação do usuário.
A saída desta atividade é composta pelo Documento contendo resultado dos
testes funcional, técnico, e de Roll-back, se for o caso. Estes resultados
determinarão a manutenção ou re-agendamento do cronograma de implantação.

3.5.4 Planejamento da Implantação

A entrada para esta atividade é formada pelo Plano de Liberação,
proveniente da fase “Preparar e Planejar Liberação”. Este plano não contém
detalhes.

Gerenciamento de Aplicações no TJPE

Gerenciamento de Aplicações no TJPE

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Andere mochten auch

Andere mochten auch (11)

Ähnlich wie Gerenciamento de Aplicações no TJPE

Ähnlich wie Gerenciamento de Aplicações no TJPE (20)

Gerenciamento de Aplicações no TJPE