IMPLEMENTAÇÃO DE UM SISTEMA DE INFORMAÇÃO DE APOIO AO GERENCIAMENTO DE MUDANÇAS SEGUNDO A ITIL

Transcrição

1 1 UNIME - UNIÃO METROPOLITANA DE EDUCAÇÃO E CULTURA FACULDADES DE CIÊNCIAS EXATAS E TECNÓLOGICAS BACHARELADO EM SISTEMAS DE INFORMAÇÃO ANTONIO CESAR DE OLIVEIRA JUNIOR IMPLEMENTAÇÃO DE UM SISTEMA DE INFORMAÇÃO DE APOIO AO GERENCIAMENTO DE MUDANÇAS SEGUNDO A ITIL Lauro de Freitas 2009

2 2 ANTONIO CESAR DE OLIVEIRA JUNIOR IMPLEMENTAÇÃO DE UM SISTEMA DE INFORMAÇÃO DE APOIO AO GERENCIAMENTO DE MUDANÇAS SEGUNDO A ITIL Trabalho de conclusão de curso apresentado ao curso de graduação em Sistemas de Informação da Faculdade Unime, como requisito parcial para obtenção do Bacharelado em Sistemas de Informação. Orientador: Prof. Ednílson Rosa Lauro de Freitas 2009

3 3 TERMO DE APROVAÇÃO [NO AGUARDO DO MODELO]

4 A minha mãe Lúcia, pelo apoio jamais ausente, sempre mostrando a importância dos estudos na vida do homem e a todos os profissionais da área da tecnologia de informação com quem tive a oportunidade de trabalhar, obtendo experiências e compartilhando conhecimento. 4

5 5 AGRADECIMENTOS A Deus, por ter me dado saúde e forças para superar este desafio. A minha mãe, que sempre me apoiou e me ensinou a lutar pelas vitórias. A meu orientador, que aceitou a parceria e acreditou no sucesso desta pesquisa.

6 6 Quanto maior a dificuldade, tanto maior o mérito em superá-la. (Henry Ward Beecher)

7 7 RESUMO Diante da necessidade das organizações de avaliarem as mudanças e diminuírem ao máximo os impactos negativos provocados caso estas mudanças ocorram nos serviços de TI, como uma das garantias da qualidade, resolveu-se desenvolver este trabalho cujo objetivo é a implementação de um sistema de informação livre e de código-fonte aberto de apoio ao Gerenciamento de Mudanças adotadas pelas boas práticas da ITIL para viabilizar a aplicação deste modelo pelas organizações, permitindo assim, que as mesmas possam contribuir para a expansão e melhoria do sistema, inclusive alinhando o mesmo a outros processos deste modelo. Espera-se com isso que as organizações possam melhorar a qualidade dos serviços de TI, tratando as mudanças de forma rápida e avaliando os seus impactos. Para tanto, será necessária a utilização do sistema, levando-se em consideração os resultados mostrados pelo mesmo ao final da análise. Foi realizado um estudo horizontalizado sobre Governança de TI e ITIL, focando na entrega de Suporte ao Serviço, verticalizando o modelo de Gerenciamento de Mudanças com especificação e análise do sistema de informação para a conclusão deste trabalho. Palavras-chave: Sistemas de informação. Governança de TI. Biblioteca de infraestrutura de tecnologia da informação. Gerenciamento de mudanças.

8 8 ABSTRACT In face of the organization necessities in evaluating its changes and diminish to the maximum the negative impacts made by these changes in case they happen in IT services, as one of the quality guarantees, It was decided to develop this project which objective was the implementation of a system of free information with open source code to support the Management Changes adopted by good ITIL practice, to make possible the application viability of this model by the organizations, permitting this way that they could be able to aid the system extension and development, including the arrangement of it to other processes of this method. It is expected that the organizations may increase the IT service quality, dealing fast with these changes and evaluating its impacts. To do so, it is necessary to use the system, considering the results shown by it by the end of the analysis. A horizontalized study of IT and ITIL governance was made, focusing in releasing the Service Support, verticalizing the Change Management method with specification and analysis of the information system to conclude this project. Keywords: Information system, IT Governance, Information technology infrastructure library, Change management.

9 9 LISTA DE FIGURAS Figura 1. Figura 2. Figura 3. Figura 4. Figura 5. Figura 6. Figura 7. Figura 8. Figura 9. Figura 10. Fatores Motivadores da Governança de TI Áreas de Conhecimento do Gerenciamento de Projetos Estrutura das Publicações da ITIL Relacionamento entre BDGC e Outros Processos Processos do Gerenciamento de Incidentes Fluxo do Processo de Gerenciamento de Liberação Relacionamentos de Processo de Gerenciamento de Mudanças Camadas do Sistema de Gerenciamento de Mudanças Tela de Listagem de Fornecedores do Sistema Proposto Tela de RDM do Sistema com Validação de Campos

10 10 LISTA DE SIGLAS BDGC BSC BPM CCM CCTA CMMI COBIT CRM EJB ERP GC GM IC ITIL ITSMF JPA JSF OGC Base de Dados do Gerenciamento de Configuração. Balanced ScoreCard Business Process Management Comitê de Controle de Mudança Central Computer and Telecommunications Agency Capability Maturity Model Integration Control Objectives for Information and Related Technology Customer Resource Management Enterprise Java Beans Enterprise Resource Planning Gerente de Configuração Gerente de Mudança Item de Configuração Biblioteca de infraestrutura de Tecnologia da Informação Information Technology Service Management Forum Java Persistence API JavaServer Faces Office Government Commerce PMBOK Project Management Body of Knowledge PMI RDM TI Project Management Institute Request for Comments Tecnologia da informação

11 11 LISTA DE QUADROS Quadro 1. Quadro 2. Quadro 3. Quadro 4. Domínios do COBIT Exemplo de Atributos de um Item de Configuração Exemplo de Sistema de Codificação de Prioridades Classificação de um Problema

12 12 SUMÁRIO 1 INTRODUÇÃO GOVERNANÇA DE TI COBIT CMMI PMBOK Gerenciamento de Projetos BSC ISO IEC ITIL Estrutura da ITIL Planejamento para implantar o Gerenciamento de Serviços Perspectiva do Negócio Entrega dos Serviços SUPORTE AO SERVIÇO Gerenciamento de Configuração Gerenciamento de Incidentes Gerenciamento de Problemas Gerenciamento da Liberação GERENCIAMENTO DE MUDANÇAS Dependências e Relacionamentos Entradas e Saídas do Processo de Mudança Autoridades do Processo de Mudança SISTEMA DE APOIO AO GERENCIAMENTO DE MUDANÇAS Tecnologias Camadas de Aplicação... 52

13 Implementação do Sistema Fluxo do Sistema de Mudanças Proposto Composição do Sistema CONSIDERAÇÕES FINAIS REFERÊNCIAS APÊNDICE... 69

14 14 1. INTRODUÇÃO A tecnologia da informação faz cada vez mais parte do dia-a-dia de uma empresa. O crescimento dos computadores, das redes e da internet, enfim, do conjunto da Tecnologia da Informação como um todo facilitou para que as empresas levassem, com maior eficiência, os seus produtos e serviços para o mercado e os avanços em TI tiveram um grande impacto nos processos de negócios (OGC, 2006). Consequentemente, a tecnologia da informação passou a alinhar os serviços com a presente e a futura necessidade do negócio, passando, também, a reduzir os custos e riscos, garantir a segurança das informações, justificar retorno sobre o investimento feito e manter conformidades com leis e regulamentos. Além disso, o apelo da qualidade dos serviços de tecnologia da informação também reduz os custos, aumenta a satisfação do cliente, melhora o alinhamento com os negócios, dentre outros benefícios. E, com este intuito, foi criado a Information Technology Infrastructure Library, que significa Biblioteca de Infraestrutura de Tecnologia da Informação, conhecida pela sigla ITIL, que representa um conjunto de melhores práticas para atingir estes objetivos, sendo atualmente um modelo bastante difundido e, por isso, vem sendo alvo de especialização por parte de muitos profissionais da área da Tecnologia da Informação. Na ITIL existem diversos processos e um deles é o processo de Gerenciamento de Mudanças, que visa garantir o uso de métodos e procedimentos padronizados, de modo que as mudanças possam ser tratadas de forma rápida, com o menor impacto possível sobre a qualidade do serviço. Entretanto o custo para a implantação destes processos é alto, tanto quanto o apelo por sistemas de informação que apoiem o Gerenciamento de Mudanças, de livre utilização e de código-fonte aberto, a fim de diminuir os custos e poder eventualmente aplicar este sistema a outros processos da ITIL, de acordo com a necessidade das organizações. A relevância deste trabalho consiste no desenvolvimento de um sistema de informação que permita aplicar o Gerenciamento de Mudanças, seguindo as

15 15 práticas da ITIL, auxiliando o usuário na tomada de decisão e demonstrando os impactos de uma mudança nos processos de serviços de TI. São levantados aspectos do Gerenciamento de Mudanças da ITIL, a fim de gerar um sistema de informação como modelo para a aplicação deste processo. Para tal foi necessário analisar os processos da ITIL e seus fundamentos, descrevendo a Governança de TI, melhores práticas dos processos do modelo ITIL, os processos do Gerenciamento de Mudanças dentro da ITIL e seus benefícios, compreender a relação deste modelo com os outros modelos do Livro de Suporte ao Serviço do modelo em questão, além de desenvolver uma ferramenta voltada ao processo de Gerenciamento de Mudanças. Para alcançar esses resultados, inicialmente foi realizado um estudo sobre Governança e Gerenciamento de TI, focando no modelo de melhores práticas ITIL. Depois foi estudado o Livro de Suporte ao Serviço, para poder entender todo o fluxo e relações do processo de Gerenciamento de Mudanças. Logo em seguida, foi estudado o Gerenciamento de Mudanças, que é o processo da ITIL responsável por garantir o uso de métodos e procedimentos padronizados, de modo que as mudanças possam ser tratadas de forma rápida e com o menor impacto possível sobre a qualidade do serviço. Foi necessário ainda a preparação de um ambiente de desenvolvimento de sistemas com o Jboss Seam e o desenvolvimento do projeto técnico para a implementação da ferramenta. A estrutura deste trabalho está dividida da seguinte forma: o capítulo 2 descreve a Governança de TI, fazendo uma breve explanação a respeito de alguns dos muitos modelos como o COBIT, CMMI, PMBOK e BSC, relacionados com governança. O capítulo 3 mostra a ITIL na sua segunda versão, de forma horizontalizada, descrevendo o seu foco principal, o conceito de serviços de TI para este modelo, a sua estrutura e suas publicações. O capítulo 4 descreve o Suporte ao Serviço, o Livro da ITIL em que está contido o processo de Gerenciamento de Mudanças, foco deste trabalho. O capítulo 5 apresenta o Gerenciamento de Mudanças, de maneira verticalizada, descrevendo os seus objetivos, as atividades relacionadas, sua relação e dependência com os outros processos do Suporte ao Serviço, além dos

16 16 benefícios e problemas que este processo pode trazer. No capítulo 6, há o sistema de informação de apoio ao Gerenciamento de Mudanças, a sua especificação e estrutura. O capítulo 7 trata da conclusão e, por fim, as referências bibliográficas utilizadas para o desenvolvimento deste estudo.

17 17 2 GOVERNANÇA DE TI Este capítulo aborda a Governança de Tecnologia da Informação, a sua composição e os seus fatores de motivação. Além disso, são abordados alguns dos principais modelos de Governança de TI, com uma breve conceituação dos mesmos. Governança de TI é o termo utilizado para descrever o modo de como as pessoas encarregadas na governança de uma determinada organização irão supervisionar, controlar e acompanhar a tecnologia da informação, impactando na visão, missão e objetivos estratégicos. Deve ser de responsabilidade da alta administração, incluindo diretores e executivos na liderança, na estrutura organizacional e nos processos que garantem que a TI da empresa sustente e estenda as estratégias e objetivos da organização (IT GOVERNANCE INSTITUTE, 2005). A Governança de TI especifica a correta decisão e encoraja comportamentos desejáveis na utilização da tecnologia da informação (WEILL et al, 2004, p.37). Segundo Weill et al (2004), a Governança visa ao compartilhamento de decisões de tecnologia da informação nas organizações, estabelecendo regras e processos que irão definir uma melhor utilização da TI pelos usuários, departamentos, negócios, enfim, todos os envolvidos nos processos da empresa, definindo como o uso desta tecnologia irá prover os serviços. A Governança deve, ainda, garantir o alinhamento da TI ao negócio, focando nos objetivos e nas estratégias das empresas, tanto no que diz respeito a aplicações como à infraestrutura de serviços de TI, além de garantir a continuidade do negócio contra falhas e o alinhamento desta tecnologia aos requisitos dos negócios. Segundo Fernandes e Abreu (2006), cinco são os fatores motivadores da Governança de TI. Esses fatores estão demonstrados na Figura 1.

18 18 Figura 1. Fatores motivadores da Governança de TI. Fonte: Fernando; Abreu, 2006, p. 7. Com o avanço da tecnologia, o ambiente de negócios, sobretudo no Brasil, vem sendo caracterizado pela intensa competição de novas entrantes potenciais no mercado, surgimento de produtos e serviços substitutos, além de clientes mais exigentes, informados e conscientes. No que diz respeito à integração, há entre a gestão da organização junto com seu chão de fábrica, através de aplicações de Enterprise Resource Planning ERP, também entre redes de distribuição, de gestão estratégica com a gestão tática, dos processos de desenvolvimento de produtos com os processos de manufatura, e de processos de gestão de clientes de alta sofisticação através de aplicações Customer Resource Management CRM. A segurança impacta a integridade do negócio com a globalização. No mundo interligado à rede de redes, a gestão de TI ficou mais complexa e sua infraestrutura sofre ameaças constantes de invasão de privacidade e acesso a informações de natureza estratégica, além de ameaças a danos com códigos maliciosos injetados nos computadores da organização, afetando, de maneira destrutiva, as operações da mesma. Ainda de acordo com Fernandes e Abreu (2006), no que diz respeito à dependência do negócio em relação a TI, ocorre quando o número de

19 19 operações diárias e as estratégias corporativas chave crescem, acarretando em um maior papel estratégico da tecnologia da informação para a empresa. A TI pode ser considerada estratégica para o negócio de uma organização quando a mesma tem um alto impacto nas operações presentes e alto impacto nas estratégias futuras. Por fim, os marcos de regulação que representam as restrições ao negócio, porém deve ser observada sua capacidade de atração de capital de risco e de geração de lucros. Por estes fatores, a Governança de TI vem sendo bastante difundida e, nas últimas décadas, vem sendo elaborados diversos modelos e melhores práticas. Desses modelos, alguns dos mais importantes e consolidados no mercado mundial e no meio acadêmico são: COBIT Control Objectives for Information and Related Tecnology, CMMI Capability Maturity Model Integration, BS 7799, ISO/IEC e ISO/IEC Códigos de prática para a gestão da segurança da informação, Modelos ISO International Organization for Standardisation, PMBOK Project Management Body of Knowledge, BSC Balanced ScoreCard e ITIL Information Technology Infrastructure Library. As sessões seguintes irão fazer uma breve explanação sobre alguns destes importantes modelos de Governança de TI. 2.1 COBIT De acordo com o IT Institute Governance (2007), o COBIT Control Objectives for Information and Related Technology contribui para o sucesso da entrega de produtos e serviços de tecnologia da informação, dependendo da perspectiva do negócio da organização, dando mais ênfase no controle do que na execução, identificando os recursos fundamentais para maiores investimentos, definindo objetivos de controle para serem salientados na gestão e organizando as tarefas em um modelo de processo genérico, representando, assim, todos os processos normalmente encontrados nas funções de TI. Cinco são as áreas essenciais que sustentam o núcleo da Governança no COBIT, sendo esses: o alinhamento estratégico, que garante a

20 20 ligação entre o negócio e os planos de TI, a agregação de valor que visa demonstrar os valores da TI na organização, fazendo com que o setor execute de forma estratégica os benefícios prometidos à organização, o gerenciamento de recursos que é o foco no melhor aproveitamento dos recursos, otimizando os investimentos, o gerenciamento de riscos que tem o foco no conhecimento dos riscos que podem ocorrer por parte dos diretores da organização, para que os mesmos possam controlá-los e, por fim, a medição de desempenho que foca no monitoramento da execução das estratégias, nos processos e na entrega dos serviços, utilizando, para isso, por exemplo, o Balanced ScoreCard, que colabora para que as estratégias saiam do papel e entrem em execução. Ainda de acordo com o IT Institute Governance (2007), o COBIT possui quatro domínios definidos: Planejamento e Organização, Aquisição e Implementação, Entrega e Suporte, e Monitoração e Avaliação, como demonstra o quadro abaixo: Planejamento e Organização Aquisição e Implementação Entrega e Suporte Monitoração e Avaliação Quadro 1 - Domínios do COBIT Fornece orientação para solução de entrega e prestação de serviços. Define as implementações da TI de acordo com as diretivas estratégicas e de projeto pré-definidos no Plano Estratégico de Informática da Organização. Recebe as soluções e os torna utilizáveis para usuários finais. Monitora todos os processos para garantir que a direção prestada é seguida. 2.2 CMMI Segundo Chrissis et al (2006), CMMI é um processo de melhoria para o modelo de desenvolvimento de produtos e serviços relacionados à tecnologia da informação. Ele consiste nas melhores práticas que abordam o

21 21 desenvolvimento e manutenção que abrangem o ciclo de vida do produto. Este modelo reflete em níveis de maturidade que consiste de práticas específicas e genéricas para o ajuste pré-definido das áreas de processos que aumentam o desempenho geral das organizações. A ideia do CMMI não é dizer como fazer, e sim o que fazer, o que o caracteriza como um modelo, e não um padrão. São cinco os níveis de maturidade: inicial, gerenciado, definido, gerenciado quantitativamente e otimizado. No nível inicial, os processos são críticos, e as organizações geralmente não têm um ambiente estável para suportar os processos. Neste nível, o sucesso das organizações depende da competência das pessoas e não do uso dos processos de forma comprovada. Apesar disso, organizações do nível inicial de maturidade, muitas vezes, podem produzir produtos e serviços que funcionam, entretanto excedendo o orçamento e o cronograma de seus projetos. É um nível de instabilidade e inconsistências. No nível de maturidade gerenciado, o nível dois, os projetos das organizações garantem que seus processos sejam planejados e executados em conformidade com a política. Os projetos são qualificados por pessoas que têm recurso adequado para produzir saídas controladas. Todos os stakeholders relevantes devem estar envolvidos nos projetos que são monitorados, controlados e revisados. No nível de maturidade definido, os processos são bem caracterizados e entendidos, descritos na norma, procedimentos, ferramentas e métodos. Neste nível o conjunto de processos da organização é estabelecido e melhorado ao longo do tempo. No nível de maturidade, gerenciado quantitativamente, as organizações e projetos estabelecem quantitativamente os objetivos para a qualidade e o desempenho dos processos são definidos e utilizados como critérios para o gerenciamento de processos. Os objetivos quantitativos são baseados nas necessidades dos clientes, usuários finais, usuários da organização e dos responsáveis pela implementação dos processos. Por fim o último nível, o de otimização, que visa ao melhoramento contínuo do desempenho de processos através de melhorias tecnológicas inovadoras e incrementais. São estabelecidos os objetivos quantitativos de melhoria de

22 22 processos para a organização e são constantemente revisados para refletir alterações nos objetivos do negócio e utilizados como critérios para o gerenciamento da melhoria de processos. Numa fábrica de software, especificamente, o CMMI é um modelo que pode ser mais adotado do que alguns modelos como a ITIL. Isso porque o CMMI é um modelo que possui os seus processos voltados para o desenvolvimento de sistemas, diferentemente do modelo ITIL que trata seus processos para os serviços de TI como um todo. Para uma empresa conseguir uma certificação CMMI, ela passa por auditoria que irá verificar se os seus projetos estão aderentes aos processos e se esses processos estão aderentes ao modelo. Os envolvidos no projeto da organização passam por entrevistas que irão evidenciar se as ações dos mesmos estão ou foram seguidas de acordo com o especificado no modelo. 2.3 PMBOK Gerenciamento de Projetos Segundo o PMI (2004) no PMBOK Guide, o PMBOK é a soma dos conhecimentos dos profissionais da área de gerenciamento de projetos. O PMI é um Instituto de Gerenciamento de Projetos, sendo uma organização nãogovernamental que conta com centenas de gerentes de projetos em todo o mundo. O propósito do PMBOK é identificar o conjunto de conhecimentos em Gerenciamento de Projetos, constituindo, desta forma, não uma metodologia, mas um conjunto de boas práticas a serem seguidas dentro da área da Gestão de Projetos. Muitas definições são estabelecidas para projetos por diversos autores da área de TI e de diversas áreas. Para Heldman (2005), um projeto é um empreendimento temporário, com datas de início e término definidas, que tem por finalidade criar um produto ou serviço único e que está concluído quando suas metas e objetivos foram alcançados e aprovados por todos os seus participantes.

23 23 Para o PMI (2004), na realização de um projeto, o gerenciamento propõe nove áreas do conhecimento, conforme ilustrado na figura 2. Figura 2 Áreas do Conhecimento de Gerenciamento de Projetos do PMBOK Ainda de acordo com o PMI (2004), na fase do Gerenciamento de Integração do Projeto, deve ser desenvolvido o termo de abertura do projeto, a declaração do escopo e o plano de gerenciamento do projeto. Além disso, nesta etapa, deve-se orientar e gerenciar a execução do projeto, monitorar e controlar o trabalho, integrar mudanças e realizar o encerramento do projeto. No Gerenciamento do Escopo do Projeto, deve-se fazer o planejamento e descrição do escopo, a criação da estrutura analítica do projeto, assim como a verificação e controle do escopo. Na fase de Gerenciamento do Tempo do projeto, deve ser feita a definição e sequenciamento de atividades, estimativas de recursos e duração de cada atividade e, também, o desenvolvimento e controle do cronograma. No Gerenciamento de Custos, deve ser feita uma estimativa de custos, com orçamentação, além do controle dos mesmos. No gerenciamento da Qualidade do Projeto, deve ser feito o planejamento, a garantia e controle da qualidade. Na fase do Gerenciamento de Recursos Humanos do Projeto, deve-se planejar os recursos humanos, contratar ou mobilizar a equipe que irá participar do projeto, assim como desenvolver e gerenciar esta equipe. Na fase de Riscos, deve-se fazer o planejamento do

24 24 gerenciamento de riscos, a identificação dos riscos, análise quantitativa e qualitativa dos riscos, o planejamento de respostas a riscos, assim como o monitoramento e controle dos riscos. E, por fim, o Gerenciamento de Aquisições do Projeto, onde é feito o planejamento de compras e aquisições, contratações, seleção de fornecedores e administração das cláusulas dos contratos. 2.4 BSC O Balanced Scorecard é um modelo de gestão de estratégia que fornece aos executivos uma visão em conjunto coerente de medidas de desempenho, alinhando as organizações à estratégia que é convertida em processo contínuo e traduzida em tarefas operacionais. Ele permite o trabalho conjunto na organização e a amarração da estratégia com o planejamento e o orçamento. A grande motivação para o estudo e existência desta abordagem era o fato de que, anteriormente, os indicadores de desempenho apenas consideravam os indicadores financeiros e, desta maneira, não mais satisfaziam as organizações que não tinham como gerar valores econômicos sobre perspectiva futura. (KAPLAN; NORTON, 1996). Ainda de acordo com Kaplan e Norton (1996), o resultado financeiro é resultado de outros três fatores ou perspectivas conhecidas como a perspectiva do cliente, de processos internos e a perspectiva de aprendizado e crescimento. É com base nessas perspectivas, juntamente com a perspectiva financeira, que o BSC se fundamenta, com a visão e estratégia apontando para todas estas quatro perspectivas, e não apenas observando os indicadores financeiros, como os indicadores comuns e insuficientes. A perspectiva financeira visa demonstrar os resultados esperados da estratégia da organização de forma financeira como os sistemas tradicionais. A perspectiva do cliente descreve a proposição de valor para o cliente. A perspectiva de processos internos visa identificar os processos críticos para gerar o valor para o cliente e a perspectiva de aprendizado e crescimento identifica os ativos não

25 25 atingíveis que são críticos para os processos internos e para a geração de valor para o cliente. 2.5 ISO IEC O ISO IEC é um modelo de Governança de TI que trata da Segurança da Informação. Segundo a NBR ISO/IEC (2005), a informação é um ativo que, como qualquer outro ativo considerado importante, é essencial para os negócios de uma organização e, consequentemente, necessita ser adequadamente protegida. Não é relevante a maneira com que a informação se apresenta. Ela pode estar sob a forma de escrita em papel, impressa, digital, transmitida de forma eletrônica ou por correios, falada, enfim, independente da forma com que a informação se apresenta, ela necessita ser protegida de forma adequada. Segurança da informação é a proteção da informação de vários tipos de ameaças para garantir a continuidade do negócio, minimizar o risco ao negócio, maximizar o retorno sobre os investimentos e as oportunidades de negócio (NBR ISO, 2005, p.9). Ainda de acordo com a NBR ISO, definir, alcançar, manter e melhorar a segurança da informação podem ser atividades essenciais para assegurar a competitividade, o fluxo de caixa, a lucratividade, o atendimento aos requisitos legais e a imagem da organização junto ao mercado. A segurança da informação torna-se bastante relevante, visto que as empresas, seus sistemas de informação e redes de computadores estão expostos a diversos tipos de ameaças à segurança da informação, incluindo fraudes eletrônicas, espionagem e todos os tipos de ataques possíveis. Prejuízos causados por código malicioso, hackers e ataques diversos estão se tornando cada vez mais comuns, mais ambiciosos e sofisticados. O documento da ISO/IEC define uma série de categorias com objetivos de controle que podem ajudar na obtenção do mesmo. Uma dessas categorias é a Política de Segurança. A Política de Segurança visa prover uma orientação

26 26 e apoio da direção para a segurança da informação de acordo com os requisitos do negócio e com as leis e regulamentações relevantes. Existem, ainda, outras categorias como a Gestão de Ativos, Controle de Acesso, Conformidade, Segurança Física e do Ambiente, dentre outros. Cada categoria é constituída pelo Documento de Controle e Diretrizes para Implantação.

27 27 3. ITIL Neste capítulo é apresentado o modelo de Governança ITIL, relevância neste trabalho, com a sua estrutura e os seus objetivos. Modernamente, as empresas dependem com muita frequência dos serviços de TI e esperam que estes não apenas as auxiliem como também apresentem novas opções para desenvolver os seus almejados objetivos. A ITIL é uma marca registrada pelo Departamento de Comércio do Governo (Office Government Commerce - OGC) e foi criada na década de 1980 pela mesma a pedido do governo britânico que não estava satisfeito com a baixa qualidade dos serviços de TI a ele oferecidos. Nesta época, este departamento era conhecido como a Agência Central de Computação e Telecomunicações (Central Computer and Telecommunications Agency CCTA). Com a solicitação, o governo pretendia garantir bons resultados e eficiência em custos com a melhor utilização possível dos recursos. De acordo com o OGC (2006), os serviços são fornecidos por meio da interação com o cliente e não podem ser avaliados sem que antes tenham sido fornecidos. A qualidade de um serviço tem referência ao nível em que este atende às expectativas e exigências do cliente. Para atingir a qualidade de um serviço, é importante manter um contínuo diálogo entre o cliente e o provedor para garantir que seja sabido o que ambos esperam do serviço. Geralmente, os clientes avaliam a qualidade dos serviços, se o mesmo atende às suas expectativas e se o preço é razoavelmente cabível em seu orçamento. Qualidade é a totalidade das características de um produto ou serviço que se relaciona com a sua capacidade de satisfazer necessidades declaradas ou implícitas (NBR ISO-8402, 1994, p. 3). A falha nos serviços de TI pode levar uma organização a intensos prejuízos, como redução das vendas, perdas de clientes, atraso nas entregas, perda de ações, diminuição do lucro, perda da qualidade, dentre outros indesejáveis

28 28 eventos. Para se ter uma ideia dos prejuízos causados por falhas nos serviços de TI, uma indústria financeira mundial pode ter em uma hora de interrupção em seus serviços, um prejuízo equivalente a mais de dez milhões de reais atualmente. Serviços ao cliente significa todos os aspectos, atitudes e informações que ampliem a capacidade do cliente de compreender o valor potencial de um bem ou serviço essencial (UTTAL; DAVIDOW, 1991, p.48). Um serviço de TI possui um ciclo de vida definido em quatro fases, onde em cada fase algumas questões devem ser avaliadas. A primeira é a fase de requisição. O serviço surge com a sua justificativa e quantidade de demanda. A segunda fase é de aquisição que tem relação com quem o solicitou, onde será provido e quanto será pago por ele. A terceira fase é a de utilização, onde é necessário saber como o serviço será utilizado, como e quem o irá validar e como o mesmo será restabelecido em caso de falha ou insucesso. A quarta e última fase é a fase de desativação onde deverá ser avaliado o custo para manter o serviço e o retorno que o mesmo proporcionou. ITIL representa um conjunto de melhores práticas para o gerenciamento de serviços de Tecnologia da Informação. Ele oferece um alinhamento dos serviços de TI às necessidades da organização, promovendo uma abordagem qualitativa para o uso econômico, efetivo, eficaz e eficiente da infraestrutura de TI, objetivando obter vantagens para a organização tanto em termos de redução de custos pelo aumento da eficiência na entrega e suporte dos serviços de TI quanto na capacidade da organização de gerar entrada financeira, permitindo que a área concentre os seus esforços em novos projetos para atender melhor as estratégias de negócios. Gerenciar serviços de TI significa gerenciar a integração entre pessoas, processos e tecnologias e componentes de um serviço de TI com o objetivo de viabilizar a entrega e o suporte de serviços de TI, focados nas necessidades dos clientes e, de modo alinhado, à estratégia de negócio da organização e garantir que a equipe de TI, com a execução e gerenciamento dos diversos processos de TI, entregue os serviços de TI dentro do acordado, em termos de custos e nível de desempenho com as áreas de negócios paralelos aos objetivos estratégicos definidos para a organização. Os serviços de TI para o modelo de Governança

29 29 ITIL é um sistema ou um conjunto de sistemas de Tecnologia da Informação que habilitam um processo de negócio, tendo como premissa que um sistema de TI é uma combinação de processos, hardware, software, pessoas e facilidades (MAGALHÃES; PINHEIRO, 2007). Para o OGC (2006), quando se fala em processos é falar em uma série de atividades logicamente relacionadas dirigidas para um objetivo definido e, frequentemente, são conhecidos com o uso de procedimento e instrução de trabalho, respectivamente definido como descrição de atividades de quem as realiza e atividades de um procedimento que devem ser realizadas. Atualmente a ITIL é o modelo padronizado para o Gerenciamento de Serviços de TI mais utilizado em todo o mundo. No Brasil, por exemplo, a ITIL vem sendo uma realidade para boa parte das empresas, com mais de 36% das empresas utilizando este modelo, como apontou a pesquisa realizada no dia 30 de agosto de 2005 com 114 empresas pela ComputerWorld em parceria com o Fórum Brasileiro de Gerenciamento de Serviços de TI, o ITSMF. Para Magalhães e Pinheiro (2007), o custo de entrega e manutenção dos serviços de TI, a complexidade da infraestrutura de tecnologia, o alto ritmo de mudanças de TI e o requerimento das organizações em relação à qualidade e a relação custo-benefício dos serviços de TI são as maiores motivações deste crescimento na adoção das boas práticas da ITIL. 3.1 Estrutura da ITIL A segunda versão da ITIL, atualizada em 2006, declara sete publicações que se subdividem em livros que abordam assuntos específicos ligados a cada publicação. A figura abaixo retrata esta estrutura.

30 30 Figura 3 Estrutura das publicações da ITIL Fonte: OGC, 2006, p.26 Nesta versão, são ao todo, sete publicações que se dividem em dezenas de livros. O Gerenciamento de Mudanças, foco deste trabalho, encontra-se na publicação de Suporte ao Serviço, juntamente com Gerenciamento de Incidentes, Gerenciamento de Problemas, Gerenciamento de Configuração e Gerenciamento de Liberações. Assim como os demais, este Gerenciamento é muito importante e relaciona-se com os demais processos deste livro da ITIL. As publicações Entrega de Serviços e Suporte ao Serviço são consideradas núcleos da ITIL e juntas somam dez livros. As demais publicações são complementos da ITIL que se direcionam ao Gerenciamento de Serviços de TI. As sessões a seguir irão retratar cada uma dessas publicações, iniciando, de maneira introdutória e resumida, pelas entregas mais abstraídas do foco deste trabalho até o capítulo que conceitua de forma verticalizada o Gerenciamento de Mudanças, um dos núcleos da biblioteca ITIL.

31 Planejamento para implementar o Gerenciamento de Serviços Segundo o OGC (2006), esta é uma etapa que deve garantir que os Sistemas de Informação se tornem melhor ajustados ao negócio e, também, que os serviços de TI forneçam os reais benefícios ao negócio. Sabendo-se da importância do bom gerenciamento de serviços, da sua manutenção e do seu aperfeiçoamento para trazer benefícios relevantes no conjunto da organização, é necessário o planejamento para a implementação do Gerenciamento de Serviços de TI. Para isso, o OGC recomenda a técnica PAIS - Programa de Aperfeiçoamento Ininterrupto do Serviço. Trata-se de uma técnica importante para o planejamento, sendo que para, a sua implantação, é necessário seguir seis etapas. A primeira diz que a organização necessita criar a visão com objetivos, orçamentos e métricas. Deverá saber nesta etapa onde a empresa deseja estar. A declaração desta etapa deve esclarecer o PAIS, os objetivos técnicos e os objetivos do negócio, iniciar o compromisso, as visões do gerenciamento e um processo motivacional dos envolvidos para agir conforme o programa. Trata-se de uma etapa com objetivos de alto nível do negócio. A segunda é uma etapa de avaliação para que a organização seja capaz de saber onde ela está atualmente, sob o ponto de vista do negócio, da tecnologia, orientadores e visões e necessidades dos responsáveis. A terceira etapa é o estágio em que a organização necessita saber onde deseja estar. A quarta etapa é o aperfeiçoamento do processo, que visa orientar a organização a chegar aonde ela deseja estar, considerando como as mudanças exigidas serão realizadas e quais itens do PAIS devem ser tratados. O quinto estágio verifica se os marcos foram atingidos, com medições e métricas e o sexto e último estágio deve ser responsável pela manutenção dos aperfeiçoamentos obtidos de acordo com os estágios anteriores.

32 Perspectiva do Negócio Como é muito importante uma adequada entrega de serviços de TI para o sucesso de uma organização, esta publicação da ITIL preocupa-se com a visão dos sistemas de informação sobre entrega de serviços ao negócio. Para o OGC (2006), seguir as adequações desta publicação ajuda a TI da organização a dar um suporte adequado na entrega de serviços, estabelecendo relacionamentos efetivos entre a TI e o negócio, compreendendo como os sistemas de informação podem agregar valor dentro do negócio, ajustando a entrega de serviços e as práticas do negócio e incorporando a visão do negócio a todos os segmentos de atividades rotineiras de TI. 3.4 Entrega dos Serviços Para o OGC (2006), o livro de Entrega dos Serviços juntamente com o livro de Suporte ao Serviço faz parte do núcleo da estrutura do modelo ITIL em sua segunda versão. De modo geral, o livro Entrega dos Serviços descreve quais os serviços que uma organização necessita para dar suporte aos seus negócios e o que é necessário para fornecer estes serviços. Este livro divide-se em cinco entregas: Gerenciamento de Nível de Serviços, Gerenciamento da Capacidade, Gerenciamento Financeiro para Serviços de TI, Gerenciamento da Continuidade e Gerenciamento da Disponibilidade dos Serviços de TI. O Gerenciamento do Nível de Serviços visa melhorar a qualidade percebida pelos clientes e usuários, diminuir a indisponibilidade dos serviços de TI, manter o foco na estratégia de negócio e o alinhamento entre TI e os negócios e estabelecer com o cliente acordos claros a respeito do tipo e qualidade dos serviços de TI a serem entregues, garantindo o cumprimento desses acordos, juntamente com o Gerenciamento da Capacidade. Como consequência, este gerenciamento necessita de informações sobre a necessidade do cliente, as facilidades oferecidas pelas organizações e os recursos financeiros obtidos. O

33 33 Gerenciamento da Capacidade visa garantir que a infraestrutura de Tecnologia da Informação da organização é capaz de suportar a demanda pelos serviços de TI, permitindo a sua expansão de forma estruturada para não comprometer os prazos e custos Este gerenciamento otimiza o custo, planejamento e alinhamento de forma que os níveis de serviços acordados possam ser cumpridos. O Gerenciamento Financeiro visa ao fornecimento prudente e controlado dos serviços de TI, garantindo o funcionamento eficiente, econômico e efetivo dos serviços no que diz respeito a custos. Com o apoio de indicadores financeiros, pode-se realizar análise financeira de um projeto, oferecendo informações sobre os custos incorridos no fornecimento de serviços de TI, possibilitando uma avaliação importante e adequada dos benefícios e custos quando decisões são tomadas sobre mudanças na infraestrutura ou nos serviços de TI. O Gerenciamento da Disponibilidade visa garantir uma disposição adequada dos recursos, métodos e técnicas para dar suporte à disponibilidade dos serviços de TI acordada com o cliente. Para o Gerenciamento da Disponibilidade, o serviço deve estar em um nível aceitável de disponibilidade, o que significa a alta probabilidade que um serviço tem em um determinado momento. O Gerenciamento da Continuidade dos serviços de TI visa assegurar a recuperação de desastres numa eventual interrupção do negócio, com preparação e medidas que possibilitem esta recuperação. Com a atual dependência das organizações à Tecnologia da Informação, a descontinuidade, mesmo que por um pequeno intervalo de tempo, pode trazer resultados indesejáveis nas organizações. Este gerenciamento bem sucedido assegura que os serviços de TI que suportem os processos de negócio da organização sejam recuperados o mais rápido possível, em ordem de prioridade, após a ocorrência de um desastre (OGC, 2006). [CITAR A VERSÃO 3 DO ITIL, DEIXANDO CLARO QUE ESTE TRABALHO FOI BASEADO NA V2]

34 34 4 SUPORTE AO SERVIÇO Este capítulo concentra-se no Livro da ITIL, onde está contido o Gerenciamento de Mudanças, foco deste estudo. O Livro de Suporte ao Serviço possui processos que tratam das tarefas de execução do cotidiano das organizações, importantes para a manutenção dos serviços de TI já entregues. Esses processos são denominados Gerenciamento de Configuração, Gerenciamento de Incidentes, Gerenciamento de Problemas, Gerenciamento de Mudanças e Gerenciamento de Liberação. Para o OGC (2006), na segunda versão da ITIL, esta publicação abrange ainda a Central de Serviços, não como um processo, e sim como uma função. Todos esses processos serão abordados nas sessões a seguir, importantes para a compreensão das relações e dependências dos processos com o Gerenciamento de Mudanças que será abordado no capítulo posterior. 4.1 Gerenciamento de Configuração Para o OGC (2006), o Gerenciamento de Configuração trata do controle de uma infraestrutura de tecnologia da informação em constante mudança e controle de status. Ele visa fornecer informações confiáveis e atualizadas sobre a infraestrutura de TI, verificando se as mesmas sofreram alterações e se foram registradas corretamente em caso de alterações. Este processo permite à equipe de TI ter um controle efetivo dos diversos componentes da infraestrutura de TI, podendo estes ser físico como um hardware, lógico como um software ou, até mesmo, um documento que possa ser considerado importante para o Gerenciamento da infraestrutura de TI como, por exemplo, um manual técnico ou procedimentos de trabalho. Estes componentes são denominados itens de configuração (MAGALHÃES; PINHEIRO, 2007). As informações detalhadas dos itens de configuração devem ficar armazenadas em uma base de dados conhecida pela sigla BDGC - Base de

35 35 Dados do Gerenciamento de Configuração. Dentro destas informações detalhadas, encontram-se as relações existentes entre os itens de configuração para a entrega e o suporte de tecnologia da informação. O quadro 2 demonstra as atribuições de um item de configuração armazenadas num BDGC. Quadro 2. Exemplo de atributos de um item de configuração. Código de Identificação Código de Inventário Número de Sério UKMILFIN Descrição Data da Última Atualização Data da Última Auditoria Notebook 01/01/ /12/2005 Categoria Tipo Modelo Microcomputador Portátil Notebook 256/80 AC 887 Validade da Garantia Número da Versão Local de Instalação 31/12/ Prédio Financeira I Proprietário Fornecedor Tipo da Licença João da Silva ACER Permanente Data de Aquisição Data de Aceite Estado Atual 13/05/ /05/2005 Em operação Próximo Estado Item de Configuração (Pai) Itens de Configuração (Filhos) Armazenado Não aplicável Pente de memória de 2 GB Relações (exceto Pai/Filho) RDM Atuais Histórico de RDM SO. Windows XP Nenhuma RDM 2345/03 Quantidade de Problemas Quantidade de Incidentes Comentários 1 4 Nenhum Fonte: Magalhães; Pinheiro, 2007, p. 90.

36 36 O quadro 2 é um exemplo de atributos de itens de configuração da categoria hardware, sugeridos por Magalhães e Pinheiro (2007) a serem registrados no BDGC. Essas definições de atributos dos itens de configuração devem levar em consideração as necessidades específicas da área de TI e da empresa onde ela está inserida. Ainda de acordo com Magalhães e Pinheiro (2007), um item indispensável é o Código de Identificação do item de configuração. Este código deve permitir a identificação de forma única de cada item de configuração cadastrado na base de dados do Gerenciamento de Configuração, além de ser utilizado para estabelecer relacionamentos do item de configuração, sendo chaves primárias da tabela, com os dados armazenados em outras tabelas do modelo de dados da BDGC. Segundo o OGC (2006), para a obtenção do Gerenciamento de Configuração é necessária uma série de seis atividades sequenciais. A primeira atividade é a de Planejamento, onde é determinada a estratégia, a política e os objetivos do processo, da análise das informações disponíveis, da identificação das ferramentas e recursos, além da criação de interfaces com outros processos, de projetos e fornecedores. A segunda atividade é a de Identificação que deve estabelecer os procedimentos para manter a base de dados atualizada e deve ser desenvolvido um modelo de dados para o registro de todos os componentes da infraestrutura de TI. A terceira atividade é a atividade de Controle que deve garantir que seja atualizada a BDGC, unicamente com a admissão, registro e monitoração de itens de configuração autorizados e identificados, evitando que nenhum item de configuração seja acrescentado, substituído, modificado ou retirado sem a devida documentação. A quarta atividade é a de Registro e Histórico do estado que armazena dados atuais e do passado sobre o estado dos itens de configuração durante o ciclo de vida. A quinta atividade, a de Verificação, deve verificar a BDGC por meio de auditorias na infraestrutura de TI para confirmar a existência dos itens de configuração registrados e garantir a precisão dos registros. Por fim, a atividade de Informação e Relatório que fornece informações para outros processos, comunicando as tendências e evoluções no uso dos itens de configuração.

37 37 A figura abaixo demonstra o relacionamento entre a BDGC e os outros processos. Figura 4. Relacionamento entre BDGC e outros processos. Fonte: OCG, 2006, p. 63. O sucesso da implantação do Gerenciamento da Configuração fornece informações precisas de Política quanto ao produto, as avaliações do impacto e informações que ajudam a detectar e solucionar os defeitos e o fornecimento de serviços e cobrança. Como benefícios, há o controle dos componentes, fazendo com que somente itens de configuração autorizados estejam presentes no ambiente de TI, a obtenção de registros confiáveis e precisos de detalhes dos itens de configuração, incluindo o acompanhamento de todo o seu ciclo de vida, assim como seu estado atual e histórico, a garantia de serviços de TI de alta qualidade.

38 Gerenciamento de Incidentes Para o OGC (2006), incidente é qualquer evento que não faz parte de um funcionamento normal de um serviço e que causa ou pode causar a redução no desempenho e qualidade do serviço ou, até mesmo, a não execução do mesmo. Um problema de hardware como um erro de um processador de um servidor, um software de proteção de vírus desatualizado, uma falha em um banco de dados, o acesso não autorizado a um sistema, a transação que apresenta erro no seu resultado são exemplos de incidentes. Segundo Magalhães e Pinheiro (2007), a necessidade de garantir a melhor utilização dos recursos da área de tecnologia da informação para dar suporte ao negócio, registrar e preservar informações relevantes aos incidentes e desenvolver e implantar uma estratégia consistente de atendimento para todos os incidentes reportados fizeram com que houvesse motivação para a criação do Gerenciamento de Incidente. Neste processo, os incidentes devem ser registrados, classificados e encaminhados para os devidos profissionais especializados para assegurarem que, depois das suas ocorrências, o serviço de TI afetado tenha restaurada a sua condição original de funcionamento o mais breve possível, minimizando os impactos decorrentes do efeito sobre o nível de serviço ou da sua total indisponibilidade. A evolução do incidente deve ser monitorada, sendo o mesmo solucionado e encerrado. O Gerenciamento de Incidentes deve ser aplicado horizontalmente em uma organização, de maneira a abranger os departamentos desde os usuários até os fornecedores, incluindo, neste intervalo, a Central de Serviços, Gerenciamento de redes, desenvolvimento, dentre outros (OGC, 2006). Além de minimizar os impactos na resolução dos incidentes para que os serviços possam voltar a seu estado normal o mais breve possível, o Gerenciamento de Incidentes objetiva, também, minimizar a adversidade do impacto ocasionado pelo incidente sobre as operações do negócio, avaliar um incidente para determinar se é provável que volte a acontecer ou mesmo se é um sintoma de problema crônico para que seja informado à equipe de

39 39 Gerenciamento de Problemas, além de assegurar os melhores níveis de disponibilidade e de desempenho dos serviços de TI. Para o OGC (2006), no tratamento de mais de um incidente é necessário que se estabeleçam prioridades, pela Central de Serviços, que se baseiam no grau de gravidade do erro para o negócio e para o usuário. Para que haja uma avaliação de prioridade para estabelecer qual o incidente tem maior prioridade sobre os demais, é importante avaliar o impacto e urgência do incidente. O impacto do incidente é a extensão do desvio em relação ao nível de normalidade do serviço, medido pelo número de usuários ou de processos de negócios afetados. Os incidentes considerados graves são aqueles cujo grau de impacto sobre um grande número de usuários é altamente relevante. A urgência do incidente se relaciona com o quanto é aceitável para o usuário ou para o processo de negócio demorar para solucionar o incidente. A relação impacto, urgência e prioridade do incidente é demonstrada no quadro 3 abaixo: Quadro 3. Exemplo de sistema de codificação de prioridades. Fonte: OGC, 2006, p. 33. Para as atividades do processo de Gerenciamento de Incidentes, oito atividades devem ser realizadas. A figura 5 representa essas atividades no processo de Gerenciamento de incidentes.

40 40 Figura 5 Processos do Gerenciamento de Incidentes. Fonte: OGC, 2006, p. 38. A atividade de Aceite e Registro do Incidente é quando o incidente é detectado e cria-se para ele um registro. Na Classificação e Suporte inicial, o incidente é codificado por status, tipo, impacto, urgência, prioridade, dentre outros. Se a ligação refere-se a uma Requisição de Serviço, inicia-se o procedimento de requisição de serviços, senão, faz-se a comparação. Na comparação, é feita uma verificação para saber se o incidente é conhecido, se já ocorreu, ou se está relacionado com algum problema que esteja ocorrendo, se pode ser contornado ou se há uma solução. Na Investigação e Diagnóstico, é feita uma investigação do incidente caso o mesmo não seja conhecido. Na Resolução e Recuperação, se descoberta uma solução, o incidente pode ser dado como resolvido. Na atividade de Encerramento, antes do encerramento do incidente após a sua resolução, deve-se perguntar ao usuário se ele está satisfeito e se pode deixar o incidente como encerrado. Na última atividade, a de Monitoração e Rastreamento do progresso, é onde é monitorado o ciclo de vida de um

41 41 incidente. Caso o incidente não possa ser resolvido a tempo, o incidente é encaminhado para outro nível. Para Berkhout et al (2000), um incidente é algo indesejável, que pode acarretar numa queda de desempenho de um serviço ou, até mesmo, a sua interrupção. Na teoria, todos os incidentes deveriam ser reportados à Central de Serviços, porém, de acordo com Magalhães e Pinheiro (2007), 99% dos casos de incidentes só são comunicados à Central de Serviços quando atingem patamares elevados. Um incidente pode passar por uma solução de contorno, conhecido como Workaround. Quando isso acontece significa que uma decisão provisória irá ser tomada com o intuito de retornar o mais breve a normalidade do problema ou incidente, sabendo-se que não é uma solução permanente. 4.3 Gerenciamento de Problemas Segundo Magalhães e Pinheiro (2007), o principal objetivo do processo de Gerenciamento de Problemas é minimizar o impacto adverso no negócio dos incidentes e problemas decorrentes de erros conhecidos relacionados com a infraestrutura de TI. Ele visa eliminar permanentemente os problemas e os incidentes repetitivos que afetam a infraestrutura de TI. A causa do problema é reportada para a Central de Serviços e as ações necessárias para a implementação de uma solução para tal problema são tomadas. Na integração com o processo de Gerenciamento de Incidentes, o incidente é detectado, registrado, classificado e diagnosticado. Após esta análise, se o incidente for considerado um problema, o mesmo é direcionado para o Gerenciamento de Problemas, caso contrário, o incidente deverá ser resolvido, o serviço de TI deverá ser restaurado para o seu estado normal e deverá haver o encerramento do incidente em questão. Um problema que não é resolvido provoca incidente. Isso significa que, dependendo da quantidade de incidentes provocados num determinado período e o tempo médio gasto pela equipe de suporte aos serviços de TI para

42 42 solucionar cada incidente provocado, para que se tenha noção do impacto negativo, a organização neste caso poderá necessitar contratar funcionários para suprir as deficiências na produtividade. A quantidade de funcionários poderá ir aumentando ao longo em que este problema não é solucionado, aumentando, consequentemente, os custos para aumentar os esforços. Um problema define uma situação indesejável, indicando a causa raiz desconhecida de um ou mais incidentes potenciais ou existentes (OGC, 2006, p.45). Para o OGC (2006), se um incidente é proveniente de uma causa desconhecida deve ser ligado a um problema. Existe um profissional capacitado, responsável por identificar um problema. Este profissional é chamado de Analista de Problemas. Pode ainda haver a participação de outros profissionais como os do Gerenciamento da Capacidade. Ainda de acordo com o OGC, um problema pode ser analisado e classificado sob a visão de cinco pontos importantes. O quadro 4 demonstra esses pontos com seus respectivos significados. Quadro 4. Classificação de um problema. Categoria Impacto Urgência Prioridade Status Domínio pertinente como, por exemplo, hardware e software O impacto do incidente corrente no processo do negócio Determina o tempo aceitável para que seja solucionado o problema Combina a urgência, os recursos exigidos, o risco e o impacto Determina se é um problema ou erro conhecido, se esta resolvido, dentre outros

43 Gerenciamento da Liberação O objetivo do Gerenciamento de Liberação é proteger o ambiente de produção, garantindo a qualidade do mesmo através de procedimentos formais e rotinas de testes extensivas para demonstrar que todos os aspectos envolvidos nas mudanças propostas, seja alteração de hardware ou de software não sejam afetados, assegurando consistência, continuidade dos serviços de TI, disponibilidade e estabilidade, isto é, uma liberação de um novo recurso ou atualização não afete negativamente os serviços de Tecnologia da Informação. A ideia é que uma liberação é uma mudança relevante na infraestrutura de TI de uma organização e, por isso, requer cuidados. Para o OGC (2006), uma liberação é considerada uma introdução de novos itens de configuração ou atualização dos mesmos. De acordo com Magalhães e Pinheiro (2007), nenhuma outra mudança na infraestrutura de TI pode ter maior potencial de risco para o negócio do que uma liberação. De fato, como uma liberação é considerada uma introdução de novos IC e, tratando-se de tecnologia que se renova frequentemente, o apelo por implantação de novas tecnologias nas empresas é muito grande, até porque modernamente estas estão com a tecnologia cada vez mais engajada em seus serviços. Numa organização, muitas vezes acredita-se que a implantação de novas tecnologias disponíveis trará benefícios imediatos como um todo, esquecendo dos impactos negativos que esta mudança pode acarretar inclusive de segurança e, por isso, uma liberação necessita de cuidados para evitar que esta seja efetivada sem os devidos cuidados. Para o OGC (2006), num grande projeto, o Gerenciamento de Liberação deve participar de todo o seu plano para garantir que a implementação seja eficiente. Existe custo para esta atividade, mas este não se compara com os custos que uma organização poderá ter caso uma liberação seja dada de forma equivocada. Exemplos desastrosos de planejamento e controle inadequados do hardware e do software podem ser dados como instabilidade de um servidor por conta de uma inclusão de um componente de hardware incompatível com o

44 44 seu conjunto e interrupções graves devidas a liberações de software mal planejadas. Magalhães e Pinheiro (2007) afirmam que o processo de Gerência de Liberação inicia com a identificação dos requisitos da liberação. Caso esses requisitos sejam aceitos, a liberação é construída, validada, distribuída, implementada e aprovada. A figura 5 mostra o fluxo do processo de Gerenciamento de Liberação. Figura 6. Fluxo do processo de Gerenciamento de Liberação. Fonte: Magalhães e Pinheiro, 2007, pg Uma vez que a liberação não for validada, é feito a sua correção. É necessário que sejam feitos testes logo após a sua construção para que seja garantido o bom funcionamento no procedimento de implantação. Caso ocorra alguma falha, a liberação é corrigida e validada novamente. Após a implementação da liberação, a mesma é passada por testes de aprovação e, caso não seja aprovada, a liberação volta a sua condição original, conhecida como back out, e corrigida, voltando a sua fase de validação.

45 45 5 GERENCIAMENTO DE MUDANÇAS Este capítulo aborda o Gerenciamento de Mudanças, suas dependências e relacionamentos, entradas e saídas do processo e seu fluxo. Além disso, são mostradas as autoridades participam deste processo. A todo instante é salientado que o avanço da Tecnologia da Informação é constante e, com este, as organizações são forçadas a mudar para poder acompanhar o mercado competitivo, aperfeiçoando seus serviços e reduzindo os custos. Melhorar, inovar, acelerar, aperfeiçoar e corrigir são ações necessárias em uma empresa e sempre acarretam em mudança. O problema é que mudança não é algo simples que pode ser feito de qualquer forma. Mudar pode trazer resultados negativos se não for feito da maneira correta, avaliando as suas reais necessidades e seus impactos. Um exemplo que demonstra a complexidade de uma mudança é a simples reforma de uma casa. Qualquer pessoa que pretenda fazer uma mudança dessa natureza deverá realizar o mínimo de planejamento, análise e avaliação da mesma. Para uma parede ser derrubada por motivo de estética, por exemplo, deverá ser feito um estudo de impacto para garantir que a estrutura da casa não seja abalada, que não afete a casa do vizinho, que não pese no orçamento familiar, dentre outros fatores. Dependendo da análise, a parede pode até ser impedida de ser removida daquele determinado local da residência. Para o OGC (2006) uma elevada proporção dos incidentes de TI causados estão relacionados à mudança, provavelmente porque esta não foi avaliada de forma correta, podendo ser provocada por falta de recursos, descuidos, testes mal executados, análise pouco qualificada dos impactos, dentre outros motivos. Para Magalhães e Pinheiro (2007), normalmente o custo para contornar um problema causado por uma mudança é alto, muito mais do que a própria mudança, sendo relevante o suficiente para que uma empresa e seus clientes criem resistência ao aceitá-la. Entretanto, é interessante distinguir de fato o que é considerado uma mudança. Ainda de acordo com Magalhães e Pinheiro (2007), diversas operações do cotidiano de um ambiente de TI fazem parte de um grande fluxo de serviços, porém não são consideradas mudanças como, por exemplo, a alteração de

46 46 senha ou nome de usuário, criação de login ou perfil de usuário, movimentação de arquivos que não são considerados críticos e de riscos e, até mesmo, instalação de sistemas de escritório. Essas solicitações devem ser feitas a Central de Serviços para que não sobrecarregue o Gerenciamento de Mudanças e, ainda, agilizar os serviços. Mudança é o processo de mover de um estado definido para outro (OGC, 2003, p.79). O Gerenciamento de Mudança da ITIL, base deste trabalho, visa administrar o processo de mudança limitando o surgimento de erros e, consequentemente, reduzindo os incidentes relacionados às mudanças. Este gerenciamento, assim como os demais do Livro de Suporte ao Serviço, possui relações e dependências com outros processos. Essas relações não foram explanadas acima com o intuito de não tornar este trabalho excessivamente extenso, perdendo o foco do seu objetivo. Para o Gerenciamento de Mudanças, alguns processos e funções são indispensáveis para a sua implantação e desenvolvimento. Estes processos e funções são o Gerenciamento de Configuração, o Gerenciamento de Liberação e a Central de Serviços. Segundo o OGC (2006), o Gerenciamento de Mudanças tem por objetivo garantir o uso de métodos e procedimentos padronizados, de modo que as mudanças possam ser realizadas rapidamente com o menor impacto possível sobre a qualidade do serviço. Ele visa manter um controle entre a flexibilidade e a estabilidade. A flexibilidade permite mudanças capazes de levar a erros e a estabilidade admite mudanças para remediar erros. Ainda de acordo com o OGC (2006), toda mudança deve manter uma rastreabilidade, de forma a permitir saber o que foi modificado sempre que necessário. Um exemplo de rastreabilidade pode ser visto, por exemplo, num artefato conhecido como Matriz de Rastreabilidade Requisito sobre Código, muito utilizada no CMMI. Ela visa manter um controle do que possivelmente será afetado no código caso algum requisito seja modificado ou vice-versa. Isso é de grande valia uma vez que fica registrada e mantida uma rastreabilidade em qualquer mudança, conhecendo o que será impactado. Gerenciamento de Mudanças é vital para qualquer organização de TI que quer prover o mais alto nível de entrega de serviços (IBM Corporation, 2006, p.19).

47 Dependências e Relacionamentos Como citado anteriormente, todo processo da ITIL se relaciona com outros. O Gerenciamento de Mudanças tem relação com todos os demais processos do Suporte ao Serviço. A relação com o Gerenciamento de Incidentes, por exemplo, ocorre uma vez que pode ser necessária uma mudança para que um incidente seja solucionado, como por exemplo, a troca de uma impressora que deixou de imprimir, sendo que deverá ser analisada e avaliada. Pelo mesmo motivo, o Gerenciamento de Problemas tem relação com o Gerenciamento de Mudanças se for necessário realizar uma mudança para resolver um problema. Da mesma forma uma mudança pode causar um incidente e este se não for tratado, pode ser convertido em um problema. A relação do Gerenciamento de Mudanças com o Gerenciamento de Configuração deve-se ao fato de que o Gerenciamento de Mudança utiliza a Base de Dados do Gerenciamento da Configuração (BDGC) para identificar o impacto das mudanças que serão afetadas, o que se torna um processo de fundamental importância para qualquer implementação de mudança, seguindo as práticas da ITIL. Não há como o Gerenciamento de Mudança agir se o Gerenciamento de Configuração não fornecer uma base de itens a ser avaliada. Com o Gerenciamento de Liberação a relação ocorre a partir do momento em que uma liberação pode-se tornar um item de configuração ou uma atualização de um item de configuração já existente e, com isso, tem-se como consequência que uma liberação é uma mudança significativa na infraestrutura de tecnologia. Uma mudança pode resultar num conjunto de novas implementações ou infraestrutura e este, quando liberado, resulta em uma mudança. Logo, a relação entre o Gerenciamento de Mudança com os demais processos é bastante estreita e, para a sua implementação, existe uma relação muito forte com o Gerenciamento da Configuração e de Liberação. (OGC, 2006). A figura abaixo demonstra o relacionamento do Gerenciamento de Mudança com outros processos da ITIL.

48 48 Figura 7. Relacionamentos do processo de Gerenciamento de Mudança. Fonte: Magalhães e Pinheiro, 2007, p Entradas e Saídas do Processo de Mudança Segundo o OGC (2006), as principais entradas do processo da Gestão de Mudanças são as RDM (Requisição de Mudança), que são as requisições ou solicitações de mudanças realizadas pelo usuário, os agendamentos das mudanças realizadas pelo Gerente de Mudança (GM) que é o responsável por receber, avaliar e priorizar as mesmas, as informações fornecidas pela BDGC (Base de Dados do Gerenciamento de Configuração) e as informações do Processo de Gerenciamento da Liberação que irá realizar análises em cima da solicitação no que diz respeito a custos e riscos. As principais saídas do Gerenciamento de Mudanças são as aprovações das RDM e suas programações futuras, informações de Gerência do processo de Mudanças e as atas de reunião do Comitê de Controle de Mudança que devem se reunir periodicamente para discutir assuntos relevantes a respeito das RDM e do processo. Ainda de acordo com o OGC, o processo de Gerenciamento de Mudanças inclui as atividades sequenciais de registrar e classificar as solicitações de

49 49 mudanças, aprovação, coordenação, autorização, implementação e avaliação das mesmas. O registro das solicitações deve ser feito pelo usuário solicitante (cliente) a partir de uma necessidade ou por um incidente ou problema de Erro conhecido oriundo do Gerenciamento de Problemas. Na prática, este usuário poderá ser qualquer pessoa que esteja inserida nos processos da organização, não havendo uma restrição para a solicitação de mudança e esta ainda pode ser solicitada por um sistema de informação ou mesmo por um formulário manual. Uma das informações importantes informadas pelo usuário é a prioridade de cada solicitação de mudança, pois é através dela que será definida a ordem no agendamento de RDM programadas. 5.3 Autoridades e fluxo do Processo de Mudança De acordo com o OGC (2006), o processo de Gestão de Mudanças da ITIL possui duas autoridades básicas fundamentais. O primeiro é o Gerente de Mudanças (GM), que, como já mencionado, é a pessoa responsável pela filtragem, aceite e classificação de todas as Solicitações de Mudança realizadas. Isso é importante, pois como uma RDM pode ser realizada por qualquer usuário que faça parte dos processos de maneira geral, algumas solicitações poderão ser rejeitadas pelo gerente, como uma solicitação que não é relevante naquele determinado momento ou, até mesmo, que o seu benefício não justifique o alto investimento para a sua implantação. A solicitação ainda poderá ser encaminhada para a Central de Serviços ou Service Desk, que são as requisições que não afetam o fluxo como um todo. Um bom exemplo disso é a simples mudança de senha, que deverá ser tratada pela Central de Serviços, seguindo procedimentos bem definidos, pois não é considerada uma solicitação de alta relevância. Se toda requisição desta natureza for encaminhada para o Gerenciamento de Mudanças, o mesmo irá ficar com carga excessiva de trabalho acarretando atrasos e serviços ineficientes. A outra autoridade do processo de Mudanças é o CCM (Comitê de Controle de Mudança). Este comitê é uma equipe que pode ser formada por diversos

50 50 integrantes como o Gerente de Mudança, Gerente de Serviços, Gerente de TI, Gerente de Negócios, representante de grupo de usuários, representantes de fornecedores, enfim, por representantes de todas as áreas envolvidas. Esta equipe é formada para apresentar conselhos à equipe e a gerência do processo de Gerenciamento de Mudança. Ainda de acordo com OGC (2006), somente as mudanças mais importantes serão apresentadas a este comitê. Isso significa que este comitê irá avaliar requisições que têm impacto relevante em custos ou que tenham altos riscos ou mesmo que são de natureza emergencial, estabelecendo prioridades dentre as relevantes requisições, e ainda, avaliando e planejando as mesmas. Segundo Magalhães e Pinheiro (2007), existe ainda o CME, que é o Comitê de Mudança Emergencial. Este comitê é uma recomendação da ITIL para ser utilizado em RDM bastante críticas, isso porque o CCM, por ser formal e por possuir um número considerado de integrantes, geralmente se reúne semanalmente, levando-se em consideração à sua disponibilização. O problema é que existem RDM emergenciais que, se não implantadas o mais depressa possível, podem causar prejuízos incalculáveis à organização. O mais depressa possível, muitas vezes, não tolera nem uma semana ou mesmo nem uma hora. Neste caso, o CME tem autoridade de implantar RDM desta natureza, o mais depressa possível, fugindo de todo o formalismo do CCM. A figura abaixo ilustra o fluxo do processo do Gerenciamento de Mudanças disposto neste projeto. [INCLUIR AQUI O FLUXO DO PROCESSO QUE ESTÁ SENDO DESENVOLVIDO]

51 51 6 SISTEMA DE APOIO AO GERENCIAMENTO DE MUDANÇAS Este capítulo concentra-se no sistema de informação para o apoio ao Gerenciamento de Mudanças, descrevendo as tecnologias utilizadas, a divisão das camadas e a composição das mesmas. Ainda é apresentado aqui o fluxo de funcionamento do sistema. Segundo O Brien (2004), um sistema de informação é um grupo de funções ou componentes inter-relacionados ou em interação que trabalham juntos rumo a uma meta comum recebendo insumos e produzindo resultados em um processo organizado de transformação, sendo dividido nas funções de entrada, processamento e saída. A entrada envolve a captação e reunião de elementos que entram no sistema para serem processados, o processamento envolve processos de transformação que convertem entrada em produtos e a saída envolve a transferência de elementos produzidos por um processo de transformação até seu destino final. Existe, ainda, o componente Feedback e Controle, definidos respectivamente como o conjunto de dados sobre o desempenho de um sistema e a monitoração e a avaliação do feedback para determinar se o sistema está no caminho certo para atingir a sua meta. O sistema de informação proposto neste trabalho é um sistema baseado na programação Orientada a Objetos. Para Sommerville (2000), um sistema Orientado a Objetos é constituído de objetos que interagem entre si, que mantêm seu próprio estado local e fornecem operações com base nessas informações de estados. Em um projeto Orientado a Objetos, os projetistas de sistemas projetam os sistemas pensando em termos coisas do mundo real, ao invés de operações ou funções. Ainda de acordo com Sommerville (2000), os objetos são criados de acordo com uma definição de classe de objetos, que serve como uma forma para criar objetos. Esta classe apresenta declarações de todos os atributos e operações que devem ser associados a um objeto dessa classe.

52 52 O projeto Ferramentas para a Gestão de Mudanças do Modelo ITIL Aplicado a Uma Empresa de Telecomunicações, escrito por Albert Frederico de Menezes e Felipe Pontes Guimarães, estudantes da Universidade de Brasília, assim como esta pesquisa, retrata a implementação de Sistemas de Informação para Gerenciamento de Mudanças da ITIL, porém de maneira mais verticalizada no Gerenciamento de Mudanças, focando unicamente em uma empresa na qual os autores fizeram uma análise de estudo de caso. O projeto citado tem por objetivo o estudo de adequabilidade do modelo ITIL por meio de um mapeamento e modelagem de processos para análise da situação atual das gerências já existentes com enfoque na Gestão de Mudanças. Os autores iniciaram com um estudo da organização, avaliando a necessidade da implantação da Gestão de Mudanças na mesma. No estudo da ITIL, foram salientados o Gerenciamento de Configurações, Gerenciamento de Incidentes, Gerenciamento de Mudanças e Gerenciamento de Liberações. A primeira grande diferença entre os dois trabalhos é o fato de que, no projeto proposto, não foi feita uma abordagem horizontalizada em toda a ITIL, justamente por ser um trabalho mais técnico, voltado à aplicabilidade em uma empresa. A outra diferença está na ferramenta que foi desenvolvida utilizando a linguagem de programação PHP, diferente da linguagem Java e de outras diversas tecnologias adotadas no mercado atualmente utilizadas neste projeto. Não há concordância quando os autores afirmam que a ITIL é dividida em dois livros sendo estes o livro de Entrega de Serviços e o livro de Suporte ao Serviço. De acordo com o OGC (2006), estes livros citados são o núcleo do modelo ITIL, e não apenas as suas divisões. Existem outros livros que compõem a ITIL, sendo estes abordados de maneira breve neste trabalho. Um dos pontos positivos, interessantes a serem salientados, é o fato do trabalho estar bastante objetivo, focando na aplicabilidade do modelo, destacando a importância do mesmo e ganhos primordiais na sua implantação. Outro ponto interessante foi a escolha da linguagem de programação para o desenvolvimento do software proposto, visto que é uma linguagem difundida no mercado e de livre utilização, o que estimula futuras contribuições por outros estudantes ou profissionais da área de TI.

53 Tecnologias do Sistema Proposto O sistema de informação proposto neste trabalho para apoiar o Gerenciamento de Mudanças da ITIL deverá ser desenvolvido na linguagem de programação Java, utilizando o framework de integração Jboss Seam, com servidor de aplicação Jboss e banco de dados HSQLDB. A escolha destas tecnologias para o desenvolvimento do sistema se deve ao grande potencial de desenvolvimento que estas ferramentas fornecem ao desenvolvedor, garantindo a simplicidade e produtividade no desenvolvimento de sistemas além de serem tecnologias de livre utilização, o que potencializa futuras implementações e melhorias do sistema tanto para novos projetos de pesquisa, quanto na customização de empresas que tenham interesse em implantar o Gerenciamento de Mudanças, alinhando o software a outros processos do modelo ITIL. Para King et al (2007), o Jboss Seam é um poderoso framework de códigofonte aberto para a construção de aplicações WEB em Java EE. O Seam integra tecnologias como o JavaScript e XML, Richfaces, JSF (Java Server Faces), JPA (Java Persistence API), EJB 3.0, Hibernate, BPM e Web Service, em uma solução unificada e completa, funcionando adequadamente com o servidor de aplicação Jboss AS, visto que é um servidor de aplicação que suporta a linguagem Java e EJB (Enterprise Java Bean). Além de integrar todas essas tecnologias, é válido salientar que o Seam visa, principalmente, fazer uma ponte entre o JSF e o EJB, respectivamente nas camadas de apresentação e negócio, deixando o desenvolvedor mais concentrado no domínio de negócios modelado. Uma implementação interessante do Seam é o modelo de componentes que podem ser criados e injetados dentro de outros componentes e manipulados de acordo com a necessidade do desenvolvedor. Outro conceito interessante deste framework é o contexto de conversação que faz com que os componentes adicionados neste contexto assegurem o estado do cache ao corrente usuário de interação. Todos esses fatores fazem com que o desenvolvimento de um sistema de informação com o Seam seja de grande valia e produtividade. Na verdade o Seam é uma framework de frameworks.

54 54 Isso porque ela integra tecnologias que são conhecidas também como framework JSF. Segundo Husted et al (2004), um framework é uma aplicação reutilizável e semicompleta que pode ser especializada para produzir aplicações personalizadas, fornecendo aos desenvolvedores um conjunto de componentes estruturais. 6.2 Camadas de Aplicação Com o intuito de garantir a facilidade de manutenção e prover subsídios para o incremento de futuras melhorias, o sistema de informação de apoio ao Gerenciamento de Mudanças deverá ser desenvolvido em três camadas bem definidas: a camada de apresentação, a camada de negócio e a camada de persistência. Resumidamente, uma aplicação mantém e disponibiliza informações aos usuários, que acessam as regras de negócio a partir da camada de apresentação. As informações são armazenadas e acessadas pela camada de persistência. A figura 6 demonstra a divisão de camadas do sistema proposto. Figura 8. Camadas da aplicação do sistema de Gerenciamento de Mudanças.

55 55 O modelo das camadas funcionará como muitos sistemas desenvolvidos atualmente. A camada de apresentação é responsável pela disponibilização e coleta das informações dos usuários. Uma aplicação pode disponibilizar diversas formas de acesso à sua lógica de negócio, por exemplo: WEB, que pode ser acessado através do navegador de internet como Internet Explorer, Mozilla Firefox, dentre outros. Caso uma nova tecnologia de acesso a aplicações, não prevista apareça, apenas a camada de apresentação seria modificada para suportar o novo recurso. Neste caso, as demais camadas não sofreriam modificações. A camada de apresentação deve se comunicar com a lógica de negócio e nunca acessar a camada de persistência diretamente. Naturalmente, toda a inteligência da aplicação deve estar concentrada na camada de negócio, onde devem ficar os serviços. As camadas periféricas têm como objetivo converter uma linguagem em outra linguagem, assim são as camadas de apresentação e persistência. A camada de negócio está no núcleo da arquitetura do software protegendo a lógica do sistema, acessando e sendo requisitada pelas camadas periféricas. A regra de negócio não deve se preocupar como as informações serão persistidas e nem como serão apresentadas para o usuário, aumentando, assim, o isolamento entre as camadas. Nesta abordagem, a camada de apresentação deve-se comunicar com a lógica de negócio e não deve acessar a camada de persistência diretamente. Um cadastro básico com as operações de inserção, alteração, listagem e remoção de dados, sem regras atreladas, são operações que as classes de abstração do Seam facilitam para o desenvolvedor. Por este motivo, neste modelo, não se reescrevem métodos de operações padrão na camada de persistência, pois o que se reescreve é específico e o que é específico fica nos serviços, a menos que haja alguma exceção nessa camada que force a implementação na mesma.

56 Implementação Para a implementação do sistema de apoio ao Gerenciamento de Mudanças do modelo ITIL, não seria possível focar apenas no processo de mudança abstraindo, literalmente, os demais processos atrelados a este gerenciamento, tamanha a dependência que há com os processos do Livro de Suporte ao Serviço. Para uma melhor compreensão é necessário voltar ao item de configuração. Na verdade, tudo inicia de um IC. Qualquer sistema de apoio a Gestão de Mudanças, assim como a Gestão de Incidentes, Problemas e Liberação necessita de uma BDGC, que seja acessada pelo próprio sistema de apoio, seja pelo consumo de serviços externos de outros sistemas ou população de uma BDGC oriunda de algum outro software específico em Gestão de Configuração como, por exemplo, o CACIC do governo Federal. A partir de um IC, inicia-se um incidente que pode ter seu erro conhecido. Um incidente de erro conhecido é quando já é conhecida a causa do problema, resultante da análise realizada anteriormente e que, muito provavelmente, estará numa base de dados armazenada. Este tipo de incidente pode gerar uma solicitação de mudança para a sua solução e, se assim não for, ou seja, se não for conhecida a causa do seu problema este incidente irá ser encaminhado para o Gerenciamento de Problemas para que seja analisado o problema, descoberta a sua causa e que o mesmo seja enviado para o Gerenciamento de Mudanças para a efetivação da solução (OGC, 2006). Pode-se entender, então, que um sistema de Gerenciamento de Mudanças precisa ter como entradas itens de configuração, incidentes ou problemas, além das entidades envolvidas no processo como usuário, Gerente de Mudança, Gerente de Configuração e integrantes do Comitê de Controle de Mudança. O sistema proposto neste trabalho irá ter essas entradas de maneira horizontalizada, tendo como premissa que o Gerenciamento de Configuração, Incidentes e Problemas já teve participação relevante no fluxo, para que o escopo definido seja cumprido e o foco do projeto não seja desviado. A

57 57 categoria dos IC e a granularidade dos mesmos é algo importante a ser definido no desenvolvimento do software. O sistema proposto objetiva-se em itens de configuração do tipo hardware com granularidade baixa, com intuito de demonstrar o fluxo e funcionamento de um sistema simples de Gestão de Mudanças. Para maiores efeitos, quanto maior a granularidade, melhor é o nível de detalhes obtido em análises de IC, problemas e incidentes e maiores e mais eficientes poderão ser os resultados obtidos. 6.4 Fluxo do Sistema de Mudança Obedecendo às recomendações da ITIL e seguindo o fluxo do processo de Mudança estabelecido na seção 5.3, o fluxo inicia-se quando o usuário administrador do sistema cadastra os recursos humanos envolvidos diretamente, setores da organização, locais pertencentes a estes setores, fabricantes, ou outras entidades básicas de input do sistema. Em seguida, deverão ser cadastrados os itens de configuração. Este cadastramento no sistema deverá ser realizado pelo Gerente de Configuração (GC), haja vista que é ele o responsável em garantir a integridade e controle dos IC, autorização de registro na BDGC, dentre outras atividades. Um usuário solicitante realiza uma Solicitação de Mudança no sistema, conhecida como RDM. Como já mencionado anteriormente, este usuário é qualquer pessoa incluída nos processos. A princípio esta solicitação será iniciada com o status de espera (aguardando), até que o Gerente de Mudança (GM) receba esta solicitação e faça as suas devidas análises a avaliações. No cadastramento da RDM, o usuário deverá informar, dentre outras informações, o motivo da solicitação, os IC envolvidos, a razão, o tipo da mudança e a prioridade. O GM, ao receber esta solicitação, irá avaliar e deverá editar alguns dados que achar cabíveis e necessários como, por exemplo, a prioridade da solicitação definida pelo solicitante e, até mesmo, recusar a RDM. Pode ser um exemplo de uma RDM recusada à solicitação de alteração de uma estação de trabalho eficiente que trabalhe sob a plataforma Unix para ser modificada por

58 58 Windows, apenas porque o solicitante julgue uma maior produtividade pessoal por estar mais familiarizado com determinada tecnologia. Neste caso, a RDM será encerrada e não voltará ao fluxo do sistema. Se registrada e aceita, a RDM deverá passar por agendamento de implantação, e o Gerenciamento de Liberação irá ou não efetuar a liberação da mudança. Uma RDM pode não ser liberada, caso a mesma tenha um impacto relevante nos custos da empresa, necessitando de recursos financeiros que já estejam comprometidos naquele momento. Existe, ainda, uma parte do sistema dedicada ao Comitê de Controle de Mudança, o CCM, que irá tratar de casos específicos de RDM direcionadas pelo GM que envolvam grandes prioridades com custos altos, dentre outras situações e ao agendamento de reuniões para avaliação das RDM pelo comitê, visto que a ITIL prega que reuniões periódicas e presenciais sejam de fundamental importância para avaliar as mudanças de maneira mais efetiva, mesmo com todas as intervenções das tecnologias como eletrônico, sistemas workflow, dentre outras. Uma vez liberada a RDM, encerra-se o fluxo do sistema. 6.5 Composição De acordo com as camadas do sistema explanadas na seção 6.2, o sistema proposto é composto basicamente por arquivos de apresentação em XHTML, os componentes Seam HOME e QUERY que são representados por classes Java, os arquivos Page.xml que servem para passagens de parâmetros das páginas, além das classes de modelo Java que representam as entidades do sistema. Os arquivos xhtml são os arquivos de apresentação do sistema que mesclam tecnologias como Expression Language (EL), Facelets, Richfaces, JSF, Taglib, e JavaScript. Neste projeto, os arquivos de apresentação, assim como deve ser em todos os projetos desenvolvidos em Java, recebem padronização em seus nomes de forma que todos os arquivos que se iniciam de Edit representam as

59 59 telas de edição e criação de registros sistema e List representam as telas de listagem e pesquisa dos mesmos. Essas telas são gerenciadas respectivamente pelos componentes Seam Home e Query que trabalham como code behind na camada de apresentação. Isso significa que um componente Seam pode ser invocado em uma tela.xhtml na camada de apresentação pelo seu nome. Uma classe pode ser representada por um componente Seam recebendo uma ( Nome_do_Componente ). Na camada de negócio, ficam os serviços da aplicação que servem como ponte para a camada de persistência. De maneira semelhante, as classes das camadas de negócios (service) e persistência (DAO) são representadas através por componentes Seam recebendo como nomenclatura o padrão Service e DAO ao final dos nomes, seguindo a mesma nomenclatura das classes. Por exemplo, a classe ItemConfiguracao.java possui sua a sua home equivalente nomeada de ItemConfiguracaoHome.java que, por sua vez, recebe ( itemconfiguracaohome ) e a classe EntidadeService.java recebe entidadeservice ) como nomenclatura padrão para o sistema. Um componente Seam pode ser acessado por outro componente através da No entanto, não se deve acessar um componente DAO diretamente pelos componentes Home ou Query. Esses componentes devem injetar os componentes Service, onde ficam as regras de negócios do sistema, e este injetar os componentes DAO, de persistência, para que seja obedecido o modelo MVC (Model, View e Controller) do sistema. As classes de modelo utilizam as tecnologias Hibernate annotation, Hibernate Validator e Hibernate JPA. Com elas, quando o servidor Jboss é iniciado, todas as classes de modelo que forem reconhecidas com a são entidades do banco de dados, dependendo dos arquivos de configuração de banco que informam qual o gerenciador de bando de dados será utilizado e a tecnologia se encarrega na criação de tabelas, tipos, tamanhos e restrições, tudo de acordo com as anotações que são descritas em cima de cada atributo da classe. O Hibernate Validator, por exemplo, adiciona regras para validação de dados, através das anotações na camada de modelo, de forma que estas validações sejam implementadas uma única vez em toda a aplicação, o que evita a redundância de regras entre as diversas camadas. Através das

60 60 anotações, é possível estabelecer características dos atributos das classes como, por exemplo, a O atributo da classe que receber esta anotação será, na camada de persistência, um campo que não pode receber valores nulos. Todo o mapeamento do modelo Orientado a Objetos também é feita na camada de modelo, utilizando o Hibernate JPA, podendo definir qual entidade é herdada de outra entidade, quais campos são transientes na aplicação, se a persistência será realizada em cascata, qual estratégia de mapeamento será utilizada, quais as chaves primárias da aplicação, quais ponteiros serão relacionados nas entidades, dentre diversas outras informações. As classes de modelo no sistema proposto não são componentes Seam e não possuem regras de serviços específicas, apenas anotações do Hibernate e métodos Gets e Sets para atribuição e recuperação de dados. Essas classes Java são acessadas através da camada de negócios e entregues a camada de apresentação. 6.6 Navegabilidade O sistema de informação proposto neste projeto segue um padrão de navegação com o intuito de manter a organização das informações tendo como consequência uma navegação intuitiva por parte do usuário. O sistema apresenta ao usuário um menu simples e organizado com informações de manipulação de dados. Ao cadastrar ou alterar um registro, o sistema direciona o usuário a uma tela de listagem, onde esses registros serão dispostos em um componente grid JSF com as suas principais informações. Cada registro possui um link onde o usuário poderá alterar ou excluir o mesmo. Nesta tela de listagem existe também o botão nomeado Novo, onde o usuário poderá adicionar um novo registro no sistema. Ao término da inclusão de um novo registro, o sistema volta à tela de listagem automaticamente onde o usuário poderá ver novamente todos os registros daquela categoria, inclusive o novo registro recém-criado. A figura abaixo ilustra uma tela de listagem do sistema,

61 61 com campo de busca e registros dispostos de forma organizada num componente de grid do JSF. Figura 9. Tela de Listagem de Fornecedores de IC do Sistema Proposto. Para a inclusão ou alteração de um registro, o sistema valida, na camada de apresentação, todas as regras implementadas pelo desenvolvedor. Por exemplo, um campo de preenchimento obrigatório que o usuário esqueceu-se de preencher no momento do cadastro, o sistema manterá a tela com todos os campos preenchidos e contornará de vermelho o referido campo vazio com uma mensagem ao lado informando que o mesmo é requerido, apesar da legenda que adverte sobre esta informação representada pelo asterisco. Quando necessário, após a validação na camada de apresentação o sistema valida na camada de negócio através das classes de serviços, e devolvendo à camada de apresentação mensagens de falha na transação para o usuário. A figura 10 abaixo ilustra uma tela de RDM do sistema com validação de campos.

62 62 Figura 10. Tela de Requisição de Mudança do Sistema com validação de tela. 6.7 Controle de Acesso Para controlar o acesso de usuários, o sistema proposto neste projeto possui integração com uma ferramenta de controle de acesso livre e de código-fonte aberto, conhecida como Rasea. O Rasea é um acrônimo de Cross Platform Access for Enterprise Applications e, assim como o sistema referido, foi desenvolvido em Java, com framework Jboss Seam e pode ser utilizado independente de SGBD. Ele provê serviços para serem consumidos por qualquer sistema, oferecendo segurança confiável, boa navegabilidade e fácil integração. É fundamental que um sistema cuide da segurança de suas informações, porém o esforço necessário para a implementação de um bom controle de acesso é alto. A integração do sistema proposto com o Rasea foi