aplicação para avaliação do nível de maturidade da itil e cmmi-svc
TRANSCRIPT
UNIVERSIDADE REGIONAL DE BLUMENAU
CENTRO DE CIÊNCIAS EXATAS E NATURAIS
CURSO DE SISTEMAS DE INFORMAÇÃO – BACHARELADO
APLICAÇÃO PARA AVALIAÇÃO DO NÍVEL DE
MATURIDADE DA ITIL E CMMI-SVC
CHARLES SALES BICALHO
BLUMENAU 2009
2009/2-03
CHARLES SALES BICALHO
PROCESSOS DA ITIL: APLICAÇÃO PARA AVALIAÇÃO DO
NÍVEL DE MATURIDADE
Trabalho de Conclusão de Curso submetido à Universidade Regional de Blumenau para a obtenção dos créditos na disciplina Trabalho de Conclusão de Curso II do curso de Sistemas de Informação - Bacharelado.
Prof. Oscar Dalfovo, Dr. - Orientador
BLUMENAU 2009
2009/2-03
PROCESSOS DA ITIL: APLICAÇÃO PARA AVALIAÇÃO DO
NÍVEL DE MATURIDADE
Por
CHARLES SALES BICALHO
Trabalho aprovado para obtenção dos créditos na disciplina de Trabalho de Conclusão de Curso II, pela banca examinadora formada por:
______________________________________________________ Presidente: Prof. Oscar Dalfovo, Dr. – Orientador, FURB
______________________________________________________ Membro: Prof. Me. Ricardo Alencar de Azambuja
______________________________________________________ Membro: Prof. Me. Everaldo Artur Grahl
Blumenau, 17 de dezembro de 2009
Dedico este trabalho a minha família que me apoiou incondicionalmente e à Cristiane que sempre esteve do meu lado.
AGRADECIMENTOS
À minha família, que mesmo longe, sempre esteve presente.
Aos meus amigos, pelo apoio e companheirismo.
À Cristiane pelo amor.
Ao meu orientador, Oscar Dalfovo, por ter acreditado na conclusão deste trabalho e em
meu potencial.
E o menino, não sabendo que era impossível, foi lá e fez.
Eugène Cocteau
RESUMO
O presente trabalho apresenta um estudo e desenvolvimento de uma aplicação que integra as melhores práticas de Tecnologia da Informação (TI) definidas pela organização internacional Office of Governant Commerce (OGC), designadas e definidas em sua metodologia Information Technology Infrastructure Library (ITIL) e o modelo Capability Maturity Model Integration for Services (CMMI-SVC), no que diz respeito à avaliação de processos destinada à gestão de serviços e a medição dos resultados alcançados com a adoção das melhores práticas da ITIL nas organizações. Baseado nestas premissas, este trabalho tem os seguintes objetivos: o estudo da ITIL e da metodologia CMMI-SVC; a integração entre as melhores práticas da ITIL e o modelo de avaliação de processos do CMMI-SVC; o desenvolvimento de uma aplicação que permita a avaliação dos processos.
Palavras-chave: ITIL. CMMI-SVC. Avaliação de processos.
ABSTRACT
This work aims to present a study and develop an application that integrates the best practices of Information Technology (IT) and the Capability Maturity Model Integration Model for Services (CMMI-SVC). The ITIL established by the International Organization Office of the Governing Commerce (OGC), described and defined in the Information Technology Infrastructure Library (ITIL) and the CMMI-SVC, regarding the evaluation process for the operation of services and measure the results achieved with the adoption of ITIL best practices in organizations. Based on these assumptions, this paper has the following objectives: to study the ITIL methodology and CMMI-SVC, the integration of the ITIL´s best practices and model evaluation process of CMMI-SVC and the development of an application that enables the assessment processes.
Key-words: ITIL. CMMI-SVC. Process Evaluation.
LISTA DE ILUSTRAÇÕES
Figura 1 – Ciclo de vida do serviço e seus processos ............................................................... 17
Figura 2 – Ligações chaves, entradas e saídas dos estágios do ciclo de vida do serviço. ........ 18
Figura 3 – Escopo da mudança e liberação dos serviços de gerenciamento ............................ 23
Figura 4 – 7 passos para melhoria dos processos ..................................................................... 28
Figura 5 – Estrutura da área de processo .................................................................................. 34
Quadro 1 – Tópicos relativos às áreas de processo .................................................................. 35
Figura 6 – Representação por estágios ..................................................................................... 36
Quadro 2 – Nível de maturidade da representação por estágio ................................................ 40
Figura 7 – Representação continua ........................................................................................... 40
Quadro 3 – Nível de maturidade da representação continua .................................................... 43
Quadro 4–Áreas de processo e seus respectivos ML ............................................................... 43
Quadro 5 – Características das classes de avaliação do CMMI ............................................... 44
Quadro 6: Requisitos funcionais............................................................................................... 50
Quadro 7: Requisitos não funcionais ........................................................................................ 50
Figura 8 – Diagrama de casos de uso sobre as funcionalidades do sistema ............................. 51
Figura 9 – Diagrama de entidade relacional ............................................................................. 52
Figura 10 – Visão hierárquica das telas do aplicativo .............................................................. 54
Figura 11 – Tela Inicial do aplicativo ....................................................................................... 54
Figura 12 – Tela de cadastro de cidades ................................................................................... 55
Figura 13 – Tela de cadastro de consultores............................................................................. 56
Figura 14 – Tela de cadastro de avaliadores............................................................................. 57
Figura 15 – Tela de cadastro de tipo de representação ............................................................. 58
Figura 16 – Tela de cadastro de Área de Processo ................................................................... 58
Figura 17 – Tela de cadastro de Nível de Maturidade .............................................................. 59
Figura 18 – Tela de cadastro de metas ..................................................................................... 60
Figura 19 – Tela de cadastro de questões ................................................................................. 60
Figura 20 – Tela de cadastro de avaliações .............................................................................. 61
Figura 21 – Tela de cadastro das respostas - Questionário de avaliação .................................. 62
Figura 22 – Tela de relatório de questionário ........................................................................... 63
Figura 23 – Tela do relatório de resultado modo por estágio ................................................... 64
Figura 24 – Tela do relatório de resultado modo contínuo....................................................... 65
Figura 25 – CMMI e suas constelações .................................................................................... 67
Figura 26 – Integração entre o CMMI e a ITIL ........................................................................ 67
Figura 27 – Mapa de integração entre ITIL e CMMI – PAs Específicas ................................. 68
Quadro 8 – Descrição do caso de uso Cadastra nível de maturidade ....................................... 74
Quadro 9 – Descrição do caso de uso Cadastra área de processo (PA).................................... 75
Quadro 10– Descrição do caso de uso Cadastra metas da área de processo ............................ 76
Quadro 11– Descrição do caso de uso Cadastra perguntas/questões das metas a serem
alcançadas .............................................................................................................. 77
Quadro 12– Descrição do caso de uso Cadastrar consultores .................................................. 78
Quadro 13– Descrição do caso de uso Cadastrar empresas ..................................................... 79
Quadro 14– Descrição do caso de uso Cadastrar avaliadores .................................................. 80
Quadro 15– Descrição do caso de uso Cadastrar avaliação ..................................................... 81
Quadro 16– Descrição do caso de uso Cadastrar avaliações .................................................... 82
Quadro 17– Descrição do caso de uso Cadastrar avaliação ..................................................... 82
LISTA DE SIGLAS
ARC - Appraisal Requirements for CMMI
CAR - Causal Analysis and Resolution
CAM - Capacity and Availability Management
CCTA – Central Computer and Telecommunications Agency
CM - Configuration Management
CMMI - Capability Maturity Model Integration
CMMI-SVC - Capability Maturity Model Integration for Services
CMMI-DEV - Capability Maturity Model Integration for Development
CMMI-ACQ - Capability Maturity Model Integration for Acquisition
DAR - Decision Analysis and Resolution
ITIL – Information Technology Infrastructure Library
IPM - Integrated Project Management
IRP - Incident Resolution and Prevention
ItSMF – IT Service Management Forum
MA - Measurement and Analysis
OCG – Office of Government Commerce
OID - Organizational Innovation and Deployment
OPD - Organizational Process Definition
OPF - Organizational Process Focus
OPP - Organizational Process Performance
OT - Organizational Training
PA – Process Area
PMC - Project Monitoring and Control
PP - Project Planning
PPQA - Process and Product Quality Assurance
QPM - Quantitative Project Management
SAM - Supplier Agreement Management
SCAMPI - Standard CMMI Appraisal Method for Process Improvement
SCON - Service Continuity
SD - Service Delivery
SSD - Service System Development
SST - Service System Transition
STSM - Strategic Service Management
REQM - Requirements Management
RF – Requisito Funcional
RNF - Requisitos Não Funcionais
RSKM - Risk Management
SEI - Software Engineering Institute
TI - Tecnologia da Informação
UML - Unified Modeling Language
V3 – Versão três
SUMÁRIO
1 INTRODUÇÃO .................................................................................................................. 13
1.1 OBJETIVOS DO TRABALHO ........................................................................................ 14
1.2 ESTRUTURA DO TRABALHO ...................................................................................... 14
2 FUNDAMENTAÇÃO TEÓRICA .................................................................................... 15
2.1 INTRODUÇÃO AO ITIL ................................................................................................. 15
2.1.1 Estratégias de Serviços .................................................................................................... 18
2.1.2 Desenho de Serviços ....................................................................................................... 19
2.1.3 Transição de serviços ...................................................................................................... 23
2.1.4 Operação de Serviços ...................................................................................................... 25
2.1.5 Melhoria Contínua de Serviços ....................................................................................... 27
2.1.6 Analisador de aderência .................................................................................................. 31
2.2 CAPABILITY MATURITY MODEL INTEGRATION (CMMI) ................................... 32
2.2.1 CMMI for Services (CMMI-SVC).................................................................................. 44
2.3 TRABALHOS CORRELATOS ........................................................................................ 48
3 DESENVOLVIMENTO .................................................................................................... 49
3.1 LEVANTAMENTO DE INFORMAÇÕES ...................................................................... 49
3.2 ESPECIFICAÇÃO ............................................................................................................ 50
3.3 IMPLEMENTAÇÃO ........................................................................................................ 53
3.3.1 Técnicas e ferramentas utilizadas.................................................................................... 53
3.3.2 Operacionalidade da implementação .............................................................................. 53
3.4 RESULTADOS E DISCUSSÃO ...................................................................................... 66
4 CONCLUSÕES .................................................................................................................. 70
4.1 EXTENSÕES .................................................................................................................... 70
REFERÊNCIAS BIBLIOGRÁFICAS ................................................................................. 72
13
1 INTRODUÇÃO
Com o passar dos anos, a área de Tecnologia da Informação (TI), vem ganhando
grande importância dentro das organizações, deixando de ser uma área com função
meramente tática para assumir um papel acentuadamente estratégico dentro de cada empresa,
confirmando assim a sua importância com o alinhamento ao planejamento de negócios
(HENDERSON; VENKATRAMAN, 1993). Diante desta grande mudança, a TI deixou de
ser apenas um provedor de Tecnologia para se tornar um parceiro nos negócios.
Em virtude deste novo cenário, onde a TI passa a ser importe para os negócios da
empresa, surgiram alguns frameworks de processos e melhores práticas que buscam
constantemente a otimização destes processos e metodologias destinados à avaliação e
mensuração de processos. Dentre estes frameworks surgiu a Information Technology
Infrastructure Library (ITIL) , um modelo de referência para gerenciamento de processos de
TI cujo objetivo é descrever e utilizar um conjunto de melhores práticas de gestão, permitindo
assim o funcionamento eficiente e efetivo de todos os serviços (MANSUR, 2005).
Diante de um mercado competitivo, somente implementar processos e aplicar as
melhores práticas sugeridas por estes modelos, não é mais suficiente para a gestão de um
departamento de TI. Após a implementação dos modelos é preciso monitorá-los e medi-los. É
neste momento que surge um novo nicho de mercado, destinado às empresas que visam
avaliar o nível de maturidade das práticas implementadas nas organizações e verificar os
pontos fortes e fracos das implementações feitas, ou as que ainda precisam ser aplicadas. É
neste sentido que as organizações estão se preocupando atualmente, pois mesmo depois das
implementações destas práticas, muitas destas empresas ainda não conseguem mensurar ou
mapear as áreas do departamento de TI que precisam de maior atenção.
Para garantir que os processos implementados para a prestação dos serviços de TI
tenham um desempenho satisfatório e para certificar-se que estes estão alinhados com seus
objetivos estratégicos, as empresas envolvidas nesse contexto iniciaram uma busca pela
melhoria de seus processos de software (ROCHA, 2001). Com isso, a utilização de modelos
de qualidade de processo aumentou de maneira significativa. Em uma primeira onda, na busca
pela qualidade dos processos, muitos destes modelos da área de TI eram destinados à
Gerência de Projetos, como o Capability Maturity Model Integration (CMMI). Mas como foi
visto antes, os serviços de TI e até mesmo de prestadores de serviços em geral tornaram-se tão
importantes quanto os projetos/produtos. Devido a esta nova demanda foi publicada
14
recentemente pelo Software Engineering Institute (SEI), uma extensão do CMMI,
denominado Capability Maturity Model Integration for Services (CMMI-SVC). Sendo que
este é um novo segmento, dentro do CMMI, que visa auxiliar nos modelos de processos
voltados para gestão de serviços.
1.1 OBJETIVOS DO TRABALHO
O objetivo principal deste trabalho é criar uma aplicação que permita a avaliação do
nível de maturidade dos processos da ITIL e o modelo proposto pela CMMI-SVC.
Os objetivos específicos do trabalho são:
a) disponibilizar uma aplicação que permite a avaliação dos processos da ITIL;
b) disponibilizar informações que possibilitem a visualização do resultado obtido na
avaliação dos processos da ITIL;
c) demonstrar graficamente o nível de maturidade alcançado nos processos.
1.2 ESTRUTURA DO TRABALHO
Este trabalho está organizado em forma de capítulos.
No capítulo um é apresentada uma introdução ao assunto abordado e os objetivos a
serem alcançados pelo trabalho.
No decorrer do capítulo dois descreve-se a fundamentação teórica sobre a ITIL, o
CMMI, a relação entre estes os temas citados anteriormente e os trabalhos correlatos.
Já no capítulo três apresenta-se como foi desenvolvida a aplicação, sendo detalhados
neste capítulo seus requisitos, sua especificação, a implementação, suas funcionalidades e a
operacionalidade de funcionamento.
No capítulo quatro é apresentada a conclusão do trabalho, bem como sugestões para
extensões futuras.
15
2 FUNDAMENTAÇÃO TEÓRICA
Apresentam-se neste capítulo os aspectos teóricos relacionados ao trabalho. São
destacados aspectos importantes dos conceitos da ITIL e CMMI. Além disso, as relações entre
o modelo ITIL e CMMI, destacando-se as possibilidades de como uma implementação dos
processos da ITIL podem ter seu nível de maturidade avaliado. Aborda-se também trabalhos
correlatos a este e que auxiliaram o desenvolvimento deste trabalho.
2.1 INTRODUÇÃO AO ITIL
A ITIL foi desenvolvida inicialmente pela Central Computing and
Telecommunications Agency (CCTA), atual Office of Government Commerce (OGC). O OGC
é um órgão do Governo Britânico que tem como objetivo desenvolver metodologias e criar
padrões dentro dos departamentos do governo britânico, buscando otimizar e melhorar os
processos internos. A biblioteca da ITIL foi desenvolvida pela CCTA, e tinha como objetivo
melhorar os processos dos departamentos de TI do governo britânico. Desde o seu surgimento
em 1980, as empresas e outras entidades do governo perceberam que as práticas sugeridas
poderiam ser aplicadas em seus processos de TI também (MARTINS, 2006, p. 28).
De acordo com Magalhães e Pinheiro (2007, p.62), durante a década de 1990, as
práticas reunidas na ITIL passaram a ser adotadas pelas organizações europeias privadas, uma
vez que a ITIL foi concebida como um padrão aberto, sobretudo pelo grande enfoque em
qualidade, garantido pela definição de processos e a proposição de melhores práticas para o
Gerenciamento dos Serviços de TI.
No histórico da ITIL, desde a criação, tem-se apenas três versões, que são descritas a
seguir:
a) versão 1 (um), com início em 1986: é a ITIL original, baseado em funções de boas
práticas, composto por 40 livros, de acordo com a variedade das práticas de TI;
16
b) versão 2 (dois), lançada em 1999: baseado em processos de boas práticas, é
composto por 10 livros. É a versão globalmente aceita como uma estrutura de boas
práticas para a gestão de serviços de TI:
− Introdução ao ITIL;
− Suporte aos Serviços;
− Entrega de Serviços;
− Planejamento e Implementação;
− Gerenciamento de Aplicações;
− Gerenciamento da Segurança;
− Gerenciamento da Infraestrutura de TI e de Comunicações;
− Perspectiva do Negócio;
− Gerenciamento dos Ativos de Software;
− Implementação da ITIL em pequena escala;
c) versão 3 (três), lançada em 2007, sendo a versão mais atual: baseado em ciclos de
vida das boas práticas de serviços, incorpora o melhor da ITILV1 e V2 e testadas,
tendo as melhores práticas para a gestão de serviços de TI. Os cinco livros
representam o ciclo de vida dos serviços e formam o núcleo das práticas da ITIL.
Os componentes do ciclo de vida dos serviços são:
− Service Strategy - Estratégias de Serviços;
− Service Design - Desenho de Serviços;
− Service Transition - Transição de Serviços;
− Service Operation - Operação de Serviços;
− Continual Service Improvement - Melhoria Contínua de Serviços.
17
Conforme a OGC (2009), na ITIL versão 3 (V3), os livros desenvolvidos alcançam
todo o ciclo de vida do serviço. Isto é possível, ao dividir o serviço em etapas. A Figura 1
representa as etapas do ciclo de vida dos serviços que a ITIL abrange: Estratégias de serviços;
Desenho de serviços; Transição de serviços; Operação de serviços e Melhoria contínua de
serviços. Cada peça representa uma área distinta, onde cada área é composta por um grupo de
processos.
Fonte: Google (2009)
Figura 1 – Ciclo de vida do serviço e seus processos
De acordo com a OGC (2009), todas as soluções de serviços e suas respectivas atividades
devem ser orientadas pelas necessidades do negócio e seus requisitos. Dentro deste contexto,
devem igualmente refletir as estratégias e políticas da organização prestadora de serviços, como
indicado na Figura 2.
18
Fonte: CARTLIDGE (2007, p. 12)
Figura 2 – Ligações chaves, entradas e saídas dos estágios do ciclo de vida do serviço.
2.1.1 Estratégias de Serviços
O componente da estratégia do serviço divide-se em:
a) Financial Management - Gerenciamento Financeiro: Este processo abrange as
funções da gestão de um orçamento de TI do prestador de serviços, contabilidade e
cobrança. Ele fornece aos negócios da organização a quantificação, em termos
financeiros, do valor dos serviços de TI, o valor dos ativos subjacentes ao
fornecimento desses serviços, bem como a qualificação de previsão operacional. As
responsabilidades da TI sobre a Gestão Financeira não existem exclusivamente
dentro da própria TI. Ela é de domínio da contabilidade. Muitas partes da
organização interagem para produzir e utilizar a TI, desde agregação, partilha e
também para manter os dados. Possibilitando a geração de informação para
alimentar decisões críticas;
19
b) Demand Management - Gerenciamento de demanda: Este processo é considerado
crítico para a gestão de serviços. Gerenciar a demanda de serviços é uma fonte de
risco para os prestadores de serviço por causa da incerteza na demanda. O excesso
de capacidade gera custo, sem a criação de valor que fornece uma base para a
recuperação dos custos.O propósito da Gestão de Demanda é a compreensão da
procura pelos serviços e o fornecimento de capacidade para atender a estas
demandas. Em um nível estratégico, isto pode envolver a análise de padrões de
atividade comercial e de mapear os perfis dos utilizadores. No nível tático, ele pode
envolver a utilização de taxas diferenciadas para incentivar os clientes a utilizar os
serviços de TI em tempos menos ocupados;
c) Service Portfolio Management - Gerenciamento de portfólio de serviços (SPM): O
processo gerenciamento de portfólio envolve a gestão pró-ativa dos investimentos
em todos os serviços e os respectivos ciclos de vida. Isto inclui os conceitos dos
serviços, designer e caminho de transição. Não se pode esquecer que, faz parte do
portfólio de uma organização, os serviços pertencentes aos catálogos de serviços
tanto os ativos quanto os inativos. Este processo é considerado contínuo, e inclui as
seguintes ações:
- Definição: serviços de estoque, garantir oportunidades de negócios e validar
a carteira de serviços;
- Analise: maximizar o valor da carteira, alinhar e priorizar e bastecimento/
demanda;
- Aprovar: finalizar pasta proposta, autorizar serviços e recursos;
- Tomada de decisão: comunicação de decisões, alocar recursos e a carteira de
serviços.
2.1.2 Desenho de Serviços
O componente de desenho de serviços divide-se em:
a) Service Catalogue Management - Gerenciamento do catálogo de serviços (SCM):
O catálogo de serviço é simplesmente um cardápio que uma determinada unidade
20
de negócios disponibiliza aos seus usuários. É neste catálogo que podemos
encontrar os serviços prestados às unidades de negócios de uma determinada
organização. Este catálogo exibe uma imagem precisa e consistente do serviços
disponíveis, seus detalhes e status. A principal finalidade do gerenciamento do
catálogo de serviço é fornecer uma única fonte, e atualizada, de informações sobre
os serviços acordados, e garantir que estará disponível para aqueles que possuem
permissão para acessá-lo. A entrada principal para essa informação vem da Carteira
de Serviços dos negócios, que são obtidas através do Gerenciamento de relação dos
negócios ou dos processos de gerenciamento do nível de serviço;
b) Service Level Management - Gerenciamento do nível de serviço (SLM): Quando
se ouve termos, que fazem menção ao termo “nível de serviço”, logo associamos às
métricas de serviço, ou seja: o que deve ser alcançado no nível de atendimento do
serviço prestado. O SLM negocia e acorda as metas de serviços adequadas para os
negócios, e, em seguida, monitora e produz relatórios sobre a entrega contra o nível
de serviço acordado. O objetivo do processo de SLM é garantir que todos os
serviços operacionais e seu desempenho, sejam medidos de forma consistente e
profissional, e que serviços e relatórios atendam às necessidades do negócio e dos
clientes, sejam eles internos ou externos. Considera-se como sendo as principais
informações deste processo: Service Level Agreements - Acordo do Nível de
Serviço (SLA), Operational Level Agreement - Acordo do Nível Operacional
(OLA). Além disto, este processo fornece apoio para geração do Service
Improvement Plan - Plano de Melhoria de serviço (SIP) e Service Quality Plan -
Plano de Qualidade do Serviço (SQP);
c) Capacity Management - Gerenciamento da capacidade: Este processo não se
restringe a medir apenas a capacidade produtiva dos prestadores de um
determinado serviço. A gestão da capacidade inclui empresas, serviços, pessoas e
componentes que são necessários para gestão de todo o ciclo de vida do serviço.
Este processo acompanha todos os demais processos, pois deve estar alinhado com
os objetivos dos negócios, desde a estratégia até a operação. Entretanto não é um
equívoco dizer que a relação mais estreita deste processo é com o Gerenciamento
de demanda;
21
d) Availability Management - Gerenciamento de disponibilidade: Entende-se por
disponibilidade, a quantidade de tempo em que um determinado serviço estará
disponível para seus usuários. No Gerencimaneto de disponibilidade o foco é a
gestão de todas as questões relacionadas à disponibilidade, normalmente serviços,
componentes e recursos. E com isso visa-se garantir que as metas de
disponibilidade serão medidas e alcançadas, entretanto sempre buscando exceder os
metas atuais e futuras necessidades acordadas. O Gerenciamento de
Disponibilidade possui duas atividades fundamentais para alcance de suas metas e
obtenção das informações necessárias para o controle e gestão da disponibilidade:
- atividades reativas: monitoração, medição, análise e gestão de
eventos, incidentes e problemas que envolvem a indisponibilidade do serviço;
- atividades pró-ativa: o planejamento pró-ativo, desenho, recomendação e
melhoria da disponibilidade.
O processo de gerenciamento da disponibilidade deve ser baseada em torno de um
sistema de informação, que deve conter todas as medições e dados necessários para
fornecer as informações relevantes ao negócio.
e) IT Service Continuity Management - Gerenciamento da continuidade do serviço de
TI (ITSCM): Como a tecnologia passou a exercer um papel importante em grande
parte dos processos do negócio é importante que a TI atue para manter a alta
disponibilidade de seus serviços que são essenciais para a sobrevivência do negócio
como um todo. Esta disponibilidade é conseguida através da introdução de medidas
de redução de riscos e opções de recuperação. O objetivo do ITSCM é manter os
serviços de TI em operação e com plena capacidade para atender às necessidades
acordadas, requisitos e prazos da empresa. ITSCM inclui uma série de atividades
durante todo o ciclo de vida dos serviços para garantir que, uma vez que a
continuidade dos serviços e planos de recuperação tenham sido desenvolvidos,
mantenham-se alinhadas com Planos de Continuidade de Negócios e as prioridades
dos negócios. Este alinhamento é essencial para que este processo tenha
aplicabilidade;
22
f) Information Security Management - Gerenciamento da segurança da informação
(ISM): ISM deve ser considerado no contexto da governança corporativa geral. A
governança corporativa é o conjunto de responsabilidades e práticas exercidas pelo
conselho de administração e gestão executiva, com o objetivo de fornecer
orientação estratégica, garantindo que os objetivos sejam atingidos, verificar se
os riscos estão sendo gerenciados de forma adequada, e verificar se os recursos da
empresa estão sendo utilizados de forma eficaz. O objetivo do processo ISM é
alinhar a segurança de TI com a segurança do negócio e garantir a segurança da
informação seja gerida de forma eficaz em todos os serviços e Atividades do
Serviço de Administração, de modo que:
- a informação esteja disponível e utilizável quando necessário
(disponibilidade);
- a informação seja publicada apenas para os que têm o direito de saber
(confidencialidade);
- as informações estejam completas, precisas e protegidas contra a utilização
inadequada (integridade);
- transações comerciais, bem como o intercâmbio de informações, possam ser
confiáveis.
No eixo geral o ISM deve manter e aplicar uma política geral para segurança das
informações, porém sempre alinhada com as políticas estratégicas e políticas de
segurança empresarial;
g) Supplier Management - Gerenciamento de fornecedores: Atualmente as empresa
não podem sisplesmente ter fornecedores, além de contratá-los é preciso fazer com
que o dinheiro seja transformado em valor para a empresa. Diante disto o objetivo
do gerenciamento de fornecedores é assegurar que os fornecedores cumpram com
as metas contidas dentro de seus contratos e acordos, em conformidade com todos
os termos e condições. É claro que mais uma vez estes precisam estar alinhados
com a estratégia do negócio.
23
2.1.3 Transição de serviços
O componente de transição de serviços divide-se em:
a) Change Management - Gerenciamento da mudança: O objetivo do processo de
gerenciamento da mudança é garantir que qualquer mudança executada em uma
organização seja aplicada de forma padronizada, onde através de métodos é
possível o tratamento rápido e eficiente destas mudanças.
Um serviço de mudança é a inclusão, alteração ou remoção de processo,
componente ou até mesmo um serviço. Portanto o gerenciamento da mudança é
relevante em todo o ciclo de vida, aplicando todos os níveis de serviço de gestão
estratégica, tático e operacional, conforme a figura 3.
Fonte: CARTLIDGE (2007, p. 27) Figura 3 – Escopo da mudança e liberação dos serviços de gerenciamento
O gerenciamento de mudança proporciona ao negócio, redução de erros em novos
ou serviços alterados, de forma mais rápida e precisa;
b) Service Asset and Configuration Management - Gerenciamento de ativos e da
configuração (SACM): O SACM presta suporte ao negócio, fornecendo
24
informações precisas de todos os bens e relações que compõem uma infraestrutura
da organização. O objetivo da SACM é identificar e controlar um ativo do serviço,
itens de configuração (IC), protegendo e garantindo a sua integridade em todo o
ciclo de vida do serviço. Este controle estende-se aos itens não ativos de TI.
c) Knowledge Management - Gerenciamento do conhecimento: Em organizações ou
unidades de negócios onde a prestação de serviços é a atividade principal, o
conhecimento possui uma importância considerada imensurável. E a presença da
informação certa, no momento certo e da forma correta é o que transforma os
serviços eficaz e eficiente. Diante disto o gerencimento do conhecimento precisa
garantir que as pessoas tenham acesso ao conhecimento para entregar e suportar os
serviços acordados. Ter as informações transformadas em conhecimento fornece:
- serviços mais eficientes com a melhoria da qualidade;
- informação relevante que está sempre disponível;
d) Transition Planning and Support - Planejamento da Transição e suporte: O
planejamento da transição pode melhorar significativamente a capacidade de
absorção de mudanças, mantendo a qualidade estipulada. As metas do Plano de
Transição e suporte são os seguintes:
- programar e coordenar os recursos para garantir que os requisitos de
utilização da estratégia, gerado no desenho do serviço, poderão ser
efetivamente realizados durante a prestação do serviço;
- identificar, gerenciar e controlar os riscos de fracasso e ruptura em
atividades de transição;
e) Release and Deployment Management - Gerenciamento de liberação e distribuição:
uma liberação acontece quando uma mudança foi aprovada e concluída, sendo que
uma liberação pode acontecer antes da conclusão da mudança, isto vai variar
conforme formato de trabalho da organização. O processo de gerenciamento da
liberação existe para estabelecer critérios para aplicação dos novos serviços ou suas
respectivas alterações. É preciso garantir que a liberação feita agregue valor aos
negócios e que a velocidade, riscos e custos desta liberação seja otimizada;
25
f) Service Validation and Testing - Serviço de Teste e validação: Pode-se considerar
que toda transição, seja ela no momento de elaborar uma mudança ou ao liberar a
mesma precisa de um processo de validação e testes. São estas atividades que
garantirão que todo planejamento foi executado e bem sucedido. Entretanto, o
conceito de bem sucedido depende do entendimento do serviço - de forma holística
- como serão utilizados e a forma como ele é elaborado. Todos os serviços sejam
eles internos ou adquiridos de terceiros devem ser testados de forma adequada,
fornecendo a certeza que os requisitos do negócio podem ser atendidos em toda a
gama de situações previsíveis. O propósito da validação e testes do serviço é
fornecer informações objetivas que atestam que o novo serviço ou suas alterações
suportam os requisitos de negócio, incluindo o SLA acordado;
g) Evaluation – Avaliação: Garantir que o serviço será útil para a organização é
fundamental para o sucesso da transição do serviço e isso se estende também na
garantia que os serviços terão relevância, através do estabelecimento de métricas
adequadas e técnicas de medição. A avaliação deve considerar a entrada de serviços
em fase de transição, direcionando a relevância para a adequação dos novos
serviços ou alterações para os ambientes operacionais e negócios.
2.1.4 Operação de Serviços
O componente de Operação de Serviços divide-se em:
a) Event Management Process - Gerenciamento de eventos: Pode-se considerar como
um evento as mudanças de estado que afetam um IC ou serviço de TI. Um evento
pode indicar que algo não está funcionando corretamente, apenas uma atividade
normal ou uma necessidade de intervenção de rotina, tais como manutenções
preventivas. Gestão de eventos gera e detecta as notificações e recebe verificações
de acompanhamento. Enquanto estes eventos acontecem, o estado dos componentes
alteram. Após um evento tenha sido detectado, ele pode levar a um incidente ou
Problema. Além destas possibilidades, um evento pode ser simplesmente
registrado, pois o acumulo destas informações são importantes para uso durante o
ciclo do serviço;
26
b) Incident Management Process - Gerenciamento de incidentes: Um incidente é uma
interrupção não planejada de um serviço, ou uma
redução da qualidade de um serviço de TI. A falha de algum IC que ainda não
impactou no serviço também é considerado um incidente. O objetivo do
Gerenciamento de Incidentes é restaurar o serviço ao seu estado normal o mais
rápido possível, e buscar a minimização do impacto negativo sobre as operações
comerciais. Geralmente os incidentes são identificados através do gerenciamento
de eventos ou de usuários que possuem contato direto com o Service Desk. Cada
incidente deve ser classificado para que as pessoas que dominam o assunto possam
atuar. O envolvimento nos incidentes é feito conforme priorização de urgência e
impacto aos negócios. Sendo que normalmente esta priorização é previamente
estipulada no SLM. Uma ferramenta de Gerenciamento de Incidentes é essencial
para o registro dos incidentes e com estas informações fazer o gerenciamento
destes;
c) Request Fulfillment Process - Cumprimento de requisições: Este processo diz
respeito à forma em que as requisições serão feitas. Neste momento o service desk,
seja ele para qualquer que for o serviço prestado, define um local para o registro
das requisições e quais são as possibilidades de solicitações que podem ser feitos os
respectivos atendimentos. As possibilidades mencionadas anteriormente são as
opções do catálogo de serviços que foi definido previamente e divulgado aos
envolvidos. O objetivo do cumprimento de requisições é permitir que os usuários
solicitem e recebam serviços padrões, e desta forma prestar informações aos
usuários e clientes sobre os serviços e os procedimentos para obtê-los, e para ajudar
com informações gerais, reclamações e comentários. Todos os pedidos devem ser
registrados e monitorados. Este processo de requisição deve incluir aprovação
adequada antes de cumprir o pedido;
d) Problem Management Process - Gerenciamento de problemas: Considera-se um
problema aquele registro que é a causa de um ou mais incidentes. A causa
geralmente não é conhecida no momento em que um problema é registrado. O
processo de gestão do problema é responsável por mais
investigações até a identificação da causa original. Os problemas são categorizados
de forma semelhante aos incidentes, mas o objetivo é compreender as causas,
criação de documentos que visam solucionar incidentes e solicitar alterações
27
permanentes que resolvam os problemas. Soluções alternativas são documentadas
em um banco de dados de erros conhecidos, o que melhora a eficiência e a eficácia
na resolução de incidentes. O Gerenciamento de Problemas existe para que seja
possível evitar a ocorrência de problemas e incidentes, eliminar incidentes
recorrentes e minimizar o impacto de incidentes que não podem ser impedidos. Isto
inclui diagnosticar as causas dos incidentes, determinando a resolução, e garantindo
que a resolução é válida;
e) Access Management Process - Gerenciamento de acesso: O gerenciamento de
acesso ajuda a gerir a confidencialidade, disponibilidade e integridade de dados e
propriedade intelectual. O processo de gerenciamento de acesso tem como objetivo,
fornecer os direitos aos utilizadores para que eles possam requisitar um serviço ou
conjunto de serviços, enquanto impedindo o acesso para usuários não autorizados.
2.1.5 Melhoria Contínua de Serviços
O Continual Service Improvement - processo de melhoria contínua dos serviços
(CSI) está preocupado com a manutenção do valor que o serviço tem para os clientes.
Isso é feito através da avaliação contínua e a melhoria da qualidade dos serviços e da
maturidade global do ciclo de vida do serviço e seus respectivos processos. CSI
combina princípios, práticas e métodos de gestão da qualidade,
Gestão da Mudança e melhoria de capacidade, trabalhando para melhorar cada
fase do ciclo de vida do serviço, bem como os serviços atuais, processos e
atividades relacionadas ao serviço.
O CSI define três processos-chave para a implementação efetiva da melhoria
contínua: os 7-Step Improvement Process - 7 passos para melhoria do processo;
Service Measurement - medição do serviço e Service Reporting - Relato do Serviço.
Descreve-se abaixo estes 3 processos-chave:
a) 7-Step Improvement Process - 7 passos para melhoria do processo: O processo dos
7 passos para melhoria do processo abrange os passos necessários para coleta
significativa de dados do serviço. Dados estes que possibilitam sua análise a fim de
identificar tendências e questões que apresentem informações para gestão,
28
priorização e implementação de melhorias. Estes passos são demonstrados
conforme figura 4.
Fonte: CARTLIDGE (2007, p. 37) Figura 4 – 7 passos para melhoria dos processos
Cada passo é impulsionado pelos objetivos estratégicos, táticos e operacionais
definidos durante o Serviço de Estratégia e Serviços Designer:
No Passo 1 - Defina o que você deve medir - O foco deve estar em identificar o que
é necessário para satisfazer os objetivos plenamente, sem considerar se os dados
estão disponíveis no momento.
No Passo 2 - Defina o que você pode medir - As organizações podem achar que
possuem limitações no que realmente pode ser medido. Esta etapa é importante,
pois auxilia no reconhecimento das lacunas que existem na prestação de serviços de
dados que podem ou não ser coletados. Entretanto, a análise deve ser conduzida
sem levar em consideração a lacuna entre o que é ou pode ser medido hoje e o que
é idealmente necessário.
No Passo 3 - Reunir os dados - Este abrange o acompanhamento e a coleta de
dados. É uma combinação de acompanhamento das ferramentas de coleta dos
dados e os processos manuais que também geram dados.
29
A ênfase está em identificar onde as melhorias podem ser feitas para o
atual nível de serviço ou desempenho, normalmente através da detecção de
exceções e resoluções.
CSI não está interessado apenas em exceções. Se um SLA é
atingido de forma consistente ao longo do tempo, CSI também está interessada em
determinar se esse nível de desempenho pode ser mantido a um custo menor ou se é
necessário a definição de um nível ainda melhor de desempenho.
No Passos 4 - Processar os dados - Dados brutos são transformados para o formato
exigido, geralmente proporcionando um formato de perspectiva final sobre o
desempenho dos serviços e/ou processos. Tratamento dos dados é uma atividade
CSI importante, que é muitas vezes esquecido.
No Passo 5 - Analisar os dados - A análise dos dados transforma a informação em
conhecimento dos eventos que estão afetando a organização.
Uma vez que os dados são transformados em informações, os resultados podem ser
analisados para responder a perguntas como:
- Os objetivos foram cumpridos?
- Existem tendências claras?
- Quais são as ações corretivas necessárias?
- Qual é o custo?
No Passo 6 - Apresentar e utilizar as informações - Os conhecimentos adquiridos
podem agora ser apresentados em um formato que é de fácil compreensão e permite
que aqueles que recebem as informações possam tomar decisões estratégicas,
táticas e operacionais.
Este passo requer um investimento, de tempo e até recursos, para entender os
negócios específicos, suas metas e traduzi-las para refletir o impacto contra os
objetivos da organização. Muitas vezes existe uma lacuna entre os relatórios e o
que realmente é de interesse para o negócio. Embora a maioria dos relatórios tenda
a se concentrar em áreas de baixo desempenho, boa notícias devem ser relatadas
30
como bem. Um relatório mostrando as tendências de melhoria dos serviços é o
melhor veículo de marketing.
No Passo 7 - Aplicar ação corretiva - O conhecimento adquirido é utilizado para
aperfeiçoar, melhorar e corrigir os serviços, processos, e todas as outras atividades
de suporte e tecnologia. A correção e ações necessárias para melhorar o serviço
devem ser identificadas e comunicadas à organização.
Os 7 passos são contínuos e devem voltar para o início;
b) Service Measurement - Medição do serviço: Existem quatro razões básicas para
monitorar e medir:
- validar decisões anteriores; que foram feitas;
- atividades diretas, a fim de atender estabelecer metas - esta é a razão mais
relevante da monitoração e medição;
- justificar que um curso de ação é necessário, com provas factuais;
- intervir no momento adequado e tomar medidas corretivas.
A monitoração e medição sustentam a CSI e os 7 passos para melhoria dos
processos. Existem três tipos de métricas que uma organização precisa coletar para
apoiar as atividades da CSI, bem como outras atividades do processo.
- Métricas de Tecnologia: muitas vezes associada a componente e aplicação
métricas baseados tais como desempenho, disponibilidade;
- Métricas de Processo: capturada na forma de Critical Success Factors -
Fatores Críticos de Sucesso (CSFs), Key Performance Indicators (KPIs) e
métricas de atividade;
- Métricas de serviço: os resultados do fim do serviço;
c) Service Reporting - Relato do serviço: Uma quantidade significativa de dados são
recolhidos e monitorados durante o dia a dia da prestação de serviços. Entretanto
apenas um pequeno subconjunto possui importância para os negócios. Na gestão
dos negócios o importante são os acontecimentos históricos que continuam a ser
uma ameaça para ir para frente com os negócios, e como pretende-se atenuar tais
ameaças.
31
Não é o suficiente apresentar relatórios que descrevem a adesão ou não aos SLAs.
É preciso construir uma abordagem de recurso à informação, isto é, o que
aconteceu, o que fez, como ele vai garantir que ele não tem impacto mais uma vez
e como a TI está trabalhando para melhorar a prestação de serviços em geral.
Com uma visão mais holística, pode-se criar com o tempo uma análise de
tendência. Isto possibilita a criação de uma gestão estratégica mais assertiva.
2.1.6 Analisador de aderência
Conforme Martins (2006, p. 62) é um instrumento que permite definir o nível de
maturidade da área de TI. Baseado no conjunto de melhores práticas disponibilizadas pelo
OGC (Office of Government Commerce) na forma da ITIL.
O modelo foi desenvolvido e proposto pelo itSMF do Reino Unido e é baseado num
roteiro de nove níveis, que com base na evidência de uso de algumas das melhores práticas
universalmente consagradas podem ser aferidos. Uma observação acerca do modelo em “nove
níveis” do itSMF: na realidade, como são atribuídos pontos fracionários a níveis
intermediários, o maior grau de evolução é indicado por uma pontuação igual a 5 (cinco).
Para avaliar a situação de uma dada organização em relação ao modelo de processos da
ITIL, um número variável de questões deve ser respondido. Para cada questão é atribuído um
peso. Sendo que os pontos mais importantes requerem uma resposta positiva para que se
considere aquele nível de maturidade. A seguir detalha-se cada nível proposto:
a) Nível 1: Pré-requisitos - identifica se há um conjunto mínimo de requerimentos
disponíveis para suportar as atividades.
b) Nível 1.5: Intenção Gerencial - estabelece se há políticas, objetivos de negócio
(ou outra evidência de intenção similar) provendo tanto propósito quanto
orientação na transformação do uso dos itens de pré-requisito. Nos níveis mais
baixos do framework, o questionário é escrito em termos genéricos sobre
produtos e atividades. Nos níveis mais altos os termos mais específicos da
ITIL são utilizados, baseados na premissa de que a organização que está
atingindo níveis mais altos de maturidade conhece melhor o vocabulário da
ITIL.
32
c) Nível 2: Capacidade do Processo - examina as atividades que estão sendo
executadas. As questões são voltadas para identificar se um conjunto mínimo
de atividades está sendo executado.
d) Nível 2.5: Integração Interna - procura certificar que as atividades são
integradas suficientemente para suportar plenamente a intenção do processo.
e) Nível 3: Produtos - examina as saídas atuais dos processos para verificar se
todos os produtos relevantes estão sendo produzidos.
f) Nível 3.5: Controle de Qualidade - é voltado à revisão e verificação das saídas
do processo para garantir que estão aderentes à qualidade esperada.
g) Nível 4: Informação Gerencial - é voltada à governança do processo e garantir
de que há informação adequada e em tempo hábil produzida pelo processo
de modo a suportar a tomada de decisão gerencial.
h) Nível 4.5: Integração Externa - examina se todas as interfaces externas e
relacionamentos entre os processos e outros processos estão estabelecidos
dentro da organização. Neste nível, para Gerenciamento de Serviços de TI, o
uso completo da terminologia da ITIL é esperado.
i) Nível 5: Interface com o Cliente - é principalmente voltada à verificação
contínua e validação do processo para garantir que o mesmo se mantém
otimizado, atendendo as necessidades do cliente.
Para submeter uma organização a este modelo de avaliação é preciso definir qual área
de processo da ITIL será avaliada.
2.2 CAPABILITY MATURITY MODEL INTEGRATION (CMMI)
A gestão por níveis de maturidade surgiu no final da década de 80 através da definição
do modelo de maturidade (HUMPRHREY, 1987a). Sendo que logo após a definição deste
modelo lançou-se o Questionário de Maturidade (HUMPRHREY, 1987b). Este modelo foi
desenvolvido pelo SEI como resposta a uma solicitação do departamento de defesa dos
Estados Unidos sobre um método que permitisse a avaliação de seus fornecedores de
software. O modelo e o questionário de maturidade evoluíram durante alguns anos de
utilização e deram origem ao modelo CMMI, com sua versão final publicada pelo Software
33
Engineering Institute (SEI) em 2003. Atualmente, este modelo é a base da gestão do processo
de desenvolvimento de software de um grande número de empresas da área de tecnologia.
O modelo CMMI iniciou-se com o objetivo de ser aplicado principalmente na área de
desenvolvimento de projetos e foco em desenvolvimento de softwares, entretanto com o
passar dos anos aconteceu uma evolução natural e o modelo passou a atender outros públicos
com a mesma proposta. Atualmente o modelo é composto por 3 subdivisões, sendo eles:
a) CMMI for Development (CMMI-DEV) publicada em agosto de 2006. Dirige-se ao
processo de desenvolvimento de produtos e serviços;
b) CMMI for Acquisition (CMMI-ACQ) publicada em novembro de 2007. Dirige-se
aos processos de aquisição e terceirização de bens e serviços;
c) CMMI for Services (CMMI-SVC) publicada em fevereiro de 2009. Dirige-se aos
processos de empresas prestadoras de serviços.
Conforme Sória (2006), o framework CMMI divide-se em cinco elementos principais:
a) treinamentos: devido a complexibilidade do modelo o SEI criou dentro do modelo
os treinamentos. Estes treinamentos possuem como objetivo principal capacitar as
pessoas para interpreterem as recomendações do modelo e transformalas em ações
práticas. Para as organizações que desejam obter a certificação no modelo, alguns
treinamentos são obrigatórios;
b) disciplinas: representam informações específicas que se relacionam e que reunidas
auxiliam no alcance de um determinado objetivo. O conjunto de disciplinas do CMMI
são: Systems Engineering - Engenharia de Sistemas (SE), Software Engineering -
Engenharia de Software (SE), Integrated Product and Process Development –
Desenvolvimento integrado de processo e produto (IPPD), Supplier Sourcing – Gestão
de Fornecedores (SS), sendo que o IPPD é opcional na versão 1.2. O CMMI procura
ser um modelo que ao unificar suas diversas disciplinas, possibilite sua adaptação em
praticamente todos os ramos de atividades;
c) áreas de processo: são um conjunto de práticas relacionadas que, quando
implantadas coletivamente, atendem o objetivo de implantar melhorias em uma
determinada área ou tema. As áreas de processos são estruturadas em alguns tópicos
dentro do assunto na qual é abordado, conforme figura 5 e o quadro 1.
34
Fonte: SÓRIA (2006, p. 65) Figura 5 – Estrutura da área de processo
Tópicos Descrição
Specific Goals –
Metas Específicas
Referem-se a uma área de processo e lidam com as
características únicas que descrevem o que deve ser
implementado para satisfazer a área de processo.
Specific Practices
– Práticas
Específicas
É uma atividade que é considerada importante para atingir o a
meta específica ao qual está associada.
Generic Goals -
Metas Genéricas
Cada nível da capacidade possui apenas uma Meta Genérica,
que descreve a institucionalização que a organização deve
atingir neste nível de capacidade. É o nível de capacidade de
35
cada processo.
Definem o nível de capacidade dos processos e suas metas
específicas (1 a 5). São as mesmas para todas as áreas de
processo.
GG 1) Atingir as metas específicas
GG 2) Institucionalizar um processo gerenciado
GG 3) Institucionalizar um processo definido
GG 4) Institucionalizar um processo gerenciado
quantitativamente*
GG 5) Institucionalizar um processo em otimização*
* Estas duas últimas não são utilizadas no modelo por estágios.
Generic Practices
- Práticas
Genéricas
Proveem a institucionalização que garantirá que os processos
associados com a área de processo serão eficazes, repetíveis e
duradouros. São práticas consideradas importantes para atingir
determinada meta genérica.
Required -
obrigatórios
Devem ser atingidos pelos processos da organização. São
essenciais para avaliar a execução de uma área de processo.
Metas específicas e genéricas são componentes obrigatórios do
modelo.
Expected -
esperados
Descrevem o que uma organização implementará para
atingir um componente obrigatório. Práticas específicas e
genéricas são componentes esperados do modelo.
Informative -
informativos
Proveem detalhes que ajudam os usuários do modelo a pensar
em como será a abordagem das metas e práticas.
Fonte: SEI (2009) Quadro 1 – Tópicos relativos às áreas de processo
d) representações: no framework existem duas representações para o modelo, sendo
elas: contínua e por estágios. Na prática, estas representações possibilitam que as
organizações escolham a forma que irão trabalhar com as áreas do processo do CMMI.
36
Conforme a representação usada a avaliação do nível de maturidade é alterada, onde
conforme o SEI, entende-se que um nível de maturidade consiste em práticas
genéricas e específicas para um conjunto de áreas de processo que melhora o
desempenho geral da organização. Um nível de maturidade é um estágio evolucionário
definido para servir de parâmetro para melhoria dos processos organizacionais.
A representação por Estágios oferece uma maneira estruturada e sistemática de
atingir o aperfeiçoamento dos processos, um estágio por vez. Atingir cada estágio
garante que uma infraestrutura de processos adequada foi construída e servirá de base
para o próximo estágio. As áreas de processos são organizadas em níveis de
maturidade. A seguir, na figura 6, apresenta-se o modo de avaliação adotado pela
representação por estágios e no quadro 2 o Maturity Level – Nível de Maturidade
(ML) de cada processo dentro deste mesmo tipo de representação.
Fonte: SEI (2009)
Figura 6 – Representação por estágios
Nº do Nível Descrição do Nível Informações adicionais
1
Inicial
Os processos são geralmente caóticos.
A organização normalmente não
fornece um ambiente estável para
apoiar os processos. O sucesso nestas
organizações depende da competência
37
1
Inicial
e heroísmo das pessoas na organização
e não sobre o uso de processos
comprovados. As organizações que se
encontram neste nível de maturidade
são caracterizadas por uma tendência
de overcommit, o abandono dos
processos em um momento de crise, e
uma incapacidade de repetir seus
sucessos.
2 Gerenciado Aqui a organização possui projetos
para estabelecer as bases para se
tornar um provedor de serviço efetivo
e institucionalizar a prestação de
serviço. Neste nível, projetos,
processos e serviços são gerenciados.
O prestador de serviço garante que os
processos são planejados de acordo
com a política. O prestador de
serviços identifica e envolve as partes
interessadas adequadas e
periodicamente monitora e controla o
processo. Literalmente gerencia os
processos para garantir a aplicação
deles.
3
Definido
Neste nível os processos devem estar
incorporados nos princípios da gestão
dos serviços. O prestador de serviços
verifica se os produtos/serviços
satisfazem as suas necessidades e
valida os serviços para garantir que
estes também satisfazem as
necessidades do cliente. Estes
processos são bem caracterizados e
38
3
Definido
entendidos e estão descritos em
normas, procedimentos, ferramentas e
métodos.
Outra distinção para este nível é que,
os processos são geralmente descritos
com mais rigor do que no nível de
maturidade 2. Um processo definido
possui de forma mais clara qual a
finalidade do mesmo, insumos,
critérios de entrada, as atividades,
funções, medidas, medidas de
verificação, saídas e critérios de saída.
No terceiro nível, os processos são
gerenciados de forma mais proativa.
Neste nível a organização ainda deve
amadurecer os processos do nível de
maturidade 2.
4
Gerenciado
Quantitativamente
Os prestadores de serviços
estabelecem objetivos quantitativos
para a qualidade e desempenho do
processo. E utilizam estes como
critérios na gestão dos processos.
Objetivos quantitativos são baseados
nas necessidades do cliente, os
usuários finais, a organização e
implementação do processo.
Qualidade e desempenho do processo
são entendidos em termos estatísticos
e é gerido ao longo da vida dos
processos.
Uma distinção crítica entre os níveis
de maturidade 3 e 4 é a previsibilidade
do desempenho do processo. Ao nível
39
4
Gerenciado
Quantitativamente
de maturidade 4, o desempenho dos
processos é controlado usando
estatísticas e outras técnicas
quantitativas. Ao nível de maturidade
3, os processos são normalmente
apenas qualitativamente previsíveis.
5
Otimizado
Ao nível de maturidade 5, uma
organização melhora continuamente
seus processos com base em um
entendimento quantitativo das causas
comuns de variação inerente nos
processos. Aqui concentra-se e
mantém-se o foco na melhoria
contínua do desempenho do processo
através de um processo incremental e
inovação de tecnologia, sendo estas
melhorias que aumentam a capacidade
do prestador de serviços para atender a
sua qualidade e processos respeitando
os objetivos de desempenho.
Uma distinção crítica entre os níveis
de maturidade 4 e 5 é que ao nível de
maturidade 4, a organização está
preocupada em abordar as causas
específicas das variações do processo
e fornecer previsibilidade estatística
dos resultados. Embora os processos
possam produzir resultados
previsíveis, os resultados podem ser
insuficientes para alcançar os
objetivos estabelecidos. Ao nível de
maturidade 5, a organização está
preocupada na abordagem de causas
40
5
Otimizado
comuns de variação do processo e
mudar o processo (para deslocar a
média do desempenho do processo ou
reduzir a variação do processo
inerente de experiências anteriores)
para melhorar o desempenho de
processos e alcançar os objetivos
estabelecidos a melhoria quantitativa
processo.
Fonte: Adaptado do SEI (2009) Quadro 2 – Nível de maturidade da representação por estágio
A representação Contínua oferece grande flexibilidade ao modelo CMMI.
Neste tipo de representação, não é definido um nível de maturidade da organização
como um todo e sim medido a capacidade de cada área de processo individualmente.
A organização seleciona as áreas de processos mais críticas em seu negócio e foca na
melhoria destas áreas de processo. A seguir, na figura 7, apresenta-se o modo de
avaliação adotado pela representação por estágios e no quadro 3 o Maturity Level –
Nível de Maturidade (ML) de cada processo dentro deste mesmo tipo de
representação.
Fonte: SEI (2009) Figura 7 – Representação continua
41
Nº do Nível Descrição do Nível Informações adicionais
0 Incompleto Considera-se como Incompleto, a
organização que não possui processos
implantados ou o que foi implantado
encontra-se incompleto. Entende-se
por incompleto quando um ou mais
dos objetivos específicos do processo
não é atingido.
1 Executado O nível de capacidade de processo 1,
é caracterizado quando um processo
possui todos seus objetivos específicos
atingidos. Um processo realizado é um
processo que satisfaz as metas
específicas da área de processo. Ele
suporta e permite que o trabalho
necessário seja executado para a
prestação de serviços.
2 Gerenciado Encontra-se neste nível de capacidade,
aquela organização que possui um
processo gerenciado. Um processo
gerenciado é considerado quando o
mesmo tem a infraestrutura básica no
local para apoiar o processo. É
planejado e executado de acordo com
a política, emprega pessoas
qualificadas que dispõem de recursos
suficientes para produzir saídas
controladas; envolve as partes
interessadas; é monitorado, controlado
e revisado, e é avaliada a adesão à sua
descrição do processo.
3 Definido Um processo é caracterizado como
42
3 Definido definido, quando os processos são
padronizados de acordo com diretrizes
da organização e contribui para o
produto final dos trabalhos, medidas e
outras informações de melhoria aos
processos organizacionais.
O processo que encontra-se neste nível
geralmente é descritos com mais rigor
do que no nível de capacidade 2. Um
processo definido tem claramente
descrito qual a finalidade, insumos,
critérios de entrada, as atividades,
funções, medidas de verificação,
saídas e critérios de saída. Na
capacidade de nível 3, processos são
gerenciados mais proativamente
utilizando uma compreensão das inter-
relações das atividades do processo e
medidas detalhadas do processo e dos
produtos de seu trabalho.
4 Gerenciado
Quantitativamente
Em um nível de capacidade de 4, o
processo é caracterizado como um
processo quantitativamente
gerenciado. Considera-se como
quantitativamente gerenciado aquele
processo que é controlado usando
estatística e outras técnicas
quantitativas. Onde os objetivos
quantitativos para a qualidade e
desempenho dos processos são
estabelecidos e utilizados como
critérios na gestão do processo.
5 Otimizado Um processo otimizado é aquele que é
43
5 Otimizado baseado em uma melhor compreensão
das causas comuns de variação do
processo. O foco de um processo de
otimização é a melhoria contínua na
gama de desempenho dos processos
através de melhorias tanto
incrementais e inovadoras.
Fonte: Adaptado do SEI (2009) Quadro 3 – Nível de maturidade da representação continua
Processo Abreviação ML
Configuration Management
CM
2
Measurement and Analysis
MA Project Monitoring and Control
PMC Project Planning
PP Process and Product Quality Assurance
PPQA Requirements Management
REQM Service Delivery
SD Supplier Agreement Management SAM Capacity and Availability Management CAM
3
Decision Analysis and Resolution
DAR Integrated Project Management
IPM Incident Resolution and Prevention
IRP Organizational Process Definition
OPD Organizational Process Focus
OPF Organizational Training
OT Risk Management
RSKM Service Continuity
SCON Service System Development (Additional)
SSD Service System Transition
SST Strategic Service Management STSM Organizational Process Performance OPP 4 Quantitative Project Management
QPM
Causal Analysis and Resolution CAR 5 Organizational Innovation and Deployment
OID
Fonte: Adaptado do SEI (2009) Quadro 4–Áreas de processo e seus respectivos ML
44
e) avaliações: no framework existem avaliações que são preliminares à avaliação de
certificação do SEI. Conforme Sória (2006), os requisitos destas avaliações são
formalizados pelo Appraisal Requirements for CMMI (ARC), que define três classes
de métodos de avaliação baseados nas regras do ARC, no entanto para métodos de
classe A somente o método definido pelo SEI o Standard CMMI Appraisal Method
for Process Improvement (SCAMPI) é valido como avaliação oficial que pode
certificar o nível de maturidade da organização. O quadro 5 descreve as principais
características de cada classe.
Características Classe A Classe B Classe C
Qtd de evidências coletadas Alta Média Baixa
Geração de nota Sim Não Não
Necessidade de recursos Alta Média Baixa
Tamanho da equipe Grande Médio Pequena
Fonte de dados (instrumentos,
entrevistas e documentos).
Todos Dois tipos, ao
menos uma
entrevista.
Um tipo de
fonte
Qualificação do líder da
equipe de avaliação
Autorizado
pelo SEI
Autorizado pelo
SEI ou pessoa
experiente e
treinada
Pessoa
experiente e
treinada
Fonte: Adaptado de Kulpa e Johnson (2003) Quadro 5 – Características das classes de avaliação do CMMI
2.2.1 CMMI for Services (CMMI-SVC)
Conforme o SEI, a prestação de serviços compreende 80% da economia mundial. E
com um mercado crescente, a disputa entre as empresas e as exigências dos consumidores são
cada vez maiores.
45
Essa necessidade de mostrar o nível de excelência da organização na prestação dos
serviços aos seus consumidores, levou estas organizações a buscarem uma forma de medir
este nível. Diante disto algumas tentaram utilizar o CMMI no seu modelo antigo, destinado a
projetos, e com isso algumas obtiveram alguns resultados contraditórios, pois algumas
práticas não se encaixaram no ambiente de serviços.
Devido a esta nova demanda, o SEI lançou em 2009 – em sua versão final - o CMMI-
SVC. Conforme o SEI (2009), o CMMI-SVC é composto por 16 (dezesseis) áreas de processo
(PA) essenciais, 7 (sete) áreas específicas e 1 (uma) adicional. A seguir citam-se quais são
estes processos:
a) Process Management - Gerenciamento de Processo:
− Organizational Innovation and Deployment - Desenvolvimento e Inovação
Organizacional (OID);
− Organizational Process Definition - Definição de processo Organizacional
(OPD);
− Organizational Process Focus - Foco no processo Organizacional (OPF);
− Organizational Process Performance - Performance de processo Organizacional
(OPP);
− Organizational Training - Treinamento Organizacional (OT);
b) Support - Suporte:
− Causal Analysis and Resolution - Análise e Resolução de Causas (CAR);
− Configuration Management - Gerenciamento de Configuração (CM);
− Decision Analysis and Resolution - Análise e Resolução de Decisões (DAR);
− Measurement and Analysis - Medição e Análise (MA);
− Process and Product Quality Assurance - Garantia da qualidade do processo e do
produto (PPQA);
46
c) Project Management - Gerenciamento de Projeto:
− Capacity and Availability Management - Gerenciamento da Capacidade e
Disponibilidade (CAM);
− Integrated Project Management - Gerenciamento da Integração do Projeto
(IPM);
− Project Monitoring and Control - Controle e Monitoração do Projeto (PMC);
− Project Planning - Planejamento do projeto (PP);
− Requirements Management - Gerenciamento de Requisitos (REQM);
− Risk Management - Gerenciamento de Riscos (RSKM);
− Quantitative Project Management - Gerencia Quantitativa do Projeto (QPM);
− Service Continuity - Continuidade do Serviço (SCON);
− Supplier Agreement Management - Gerenciamento do Acordo com fornecedores
(SAM);
d) Service Establishment and Delivery - Entrega e Serviço acordado:
− Incident Resolution and Prevention - Prevenção e Resolução de incidente (IRP);
− Service Delivery - Entrega do Serviço (SD);
− Service System Development - Serviço de Desenvolvimento do sistema (SSD);
− Service System Transition - Serviço para transição de sistema (SST);
− Strategic Service Management - Gerenciamento do serviço estratégico (STSM);
47
Conforme SEI, as áreas de processos consideradas como PAs específicas do CMMI-
SVC são:
a) Strategic Service Management - gerenciamento da estratégia do Serviço (STSM):
Nesta PA são definidos quais são os serviços que devem ser suportados, tornando-os
padrão, e fazer com que as pessoas tenham conhecimento de qual serviço é suportado;
b) Service System Development - serviço de desenvolvimento do sistema (SSD): faz
com que a organização tenha tudo que é preciso para a prestação do serviço, incluindo
pessoas, processos, produtos consumíveis e equipamentos;
c) Service System Transition - serviço para transição de sistema (SST): obtendo novos
sistemas, alterando sistemas, trocando sistemas já existentes e retirando sistemas
obsoletos. Sendo que em todas as situações o foco deste processo é fazer com que a
transição não permita que aconteça algo errado com o serviço que será entregue;
d) Service Delivery - entrega do serviço (SD): processo responsável pela criação de
acordos de serviço na entrega, tendo cuidado com as solicitações e operação dos
serviços;
e) Capacity and Availability Management - gerenciamento da capacidade e
disponibilidade (CAM): Consiste em assegurar que a organização tenha todos os
recursos disponíveis, quando este for requisitado para a prestação do serviço, este
recurso deve estar disponível e em um custo adequado;
f) Incident Resolution and Prevention - prevenção e resolução de incidente (IRP):
Através deste processo são estabelecidas as expectativas organizacionais para uma
abordagem ao incidente tanto quando a antecipação de suas ocorrências e a
apresentação de soluções de contorno;
g) Service Continuity Management - continuidade do serviço (SCON): Este processo
estabelece a expectativa organizacional para o restabelecimento de um serviço após
uma eventual catástrofe, sendo que além de estabelecer as expectativas de prazo
também é o processo onde se encontram os planos de recuperação e validação dos
planos elaborados.
48
2.3 TRABALHOS CORRELATOS
De acordo com Lourenço (2008), a ITIL é a abordagem destinada à gestão dos serviços
de TI mais bem acolhida atualmente. Sendo que sua mantenedora, a OGC, fornece um
conjunto muito coerente de melhores práticas, retiradas dos setores públicos e privados a uma
escala internacional. Diante de uma prática que apresentou aderência considerável no
mercado propôs-se a implementação das práticas da ITIL no departamento de TI em uma
empresa de alimentos. Para isso foi necessário efetuar um estudo teórico das práticas
propostos pela ITIL e aplicar as técnicas na empresa em questão. Ao fim do trabalho foi
possível apontar as deficiências e propor melhorias nos processos de gestão do departamento
de TI, baseando-se nas práticas propostas pela ITIL.
Conforme Martins (2006), a busca pela melhoria nos serviços oferecidos pelas áreas de
TI é atualmente objetivo da maioria das organizações. A utilização de metodologias e boas
práticas para gestão dos serviços de TI vêm se tornando uma prática fundamental para obtenção
do sucesso no oferecimento destes serviços. Nesse contexto, o trabalho mencionado propôs-se
organizar e definir um Framework para conduzir a implantação de Programas de Melhoria de
Serviços de TI. A abordagem proposta possui aderência significativa aos processos da ITIL.
Segundo Theilacher Junior (2000), muitas organizações procuram amenizar os
problemas com o desenvolvimento de software pela adoção de modelos de melhoria da
qualidade. Estas tentativas de melhorias tem sido aprimoradas e adaptadas, com objetivo de
aperfeiçoar os processos e garantir a qualidade dos produtos de Software, diante disto,
Theilacher Junior (2000), desenvolveu um aplicativo que visa auxiliar na mensuração do nível
de maturidade baseado no modelo CMMI v1.0.
49
3 DESENVOLVIMENTO
Neste capítulo serão apresentados os aspectos técnicos referentes ao desenvolvimento
do trabalho, requisitos, especificação, entidade relacional do banco de dados.
3.1 LEVANTAMENTO DE INFORMAÇÕES
Os requisitos, classificados como Requisitos Funcionais (RF) e Requisitos Não
Funcionais (RNF) descrevem o que o sistema deve e o que não deve fazer. Os RF apresentam
às funcionalidades e o comportamento que o sistema deve possuir em determinadas situações.
Os RNF apresentam as restrições que o sistema terá sobre alguns serviços ou funções
oferecidas como usabilidade, navegabilidade, portabilidade, segurança e hardware.
O Quadro 6 apresenta os requisitos funcionais previstos para a aplicação sistema e sua
rastreabilidade, ou seja, vinculação com o(s) caso(s) de uso associado(s).
Requisitos Funcionais Caso de Uso
RF01. O sistema deverá permitir ao administrador inserir, alterar e excluir
os níveis de maturidade dos processos.
UC01
RF02. O sistema deverá permitir ao administrador inserir, alterar e excluir
as áreas de processos (PAs) de cada nível de maturidade.
UC02
RF03. O sistema deverá permitir ao administrador inserir, alterar e excluir
as metas definidas para cada Área de processo.
UC03
RF04. O sistema deverá permitir ao administrador inserir, alterar e excluir
as questões a serem respondidas para cada meta a ser alcançada.
UC04
RF05. O sistema deverá permitir ao administrador inserir, alterar e excluir
consultores (que irão conduzir a avaliação).
UC05
RF06. O sistema deverá permitir ao administrador inserir, alterar e excluir
uma determinada organização (que irá ser submetida à avaliação de seus
processos).
UC06
RF07. O sistema deverá permitir ao administrador inserir, alterar e excluir
avaliadores, pertencentes às empresas (RF06).
UC07
50
RF08. O sistema deverá permitir ao consultor inserir e alterar as avaliações. UC08
RF09. O sistema deverá permitir ao consultor listar o resultado de uma
avaliação finalizada.
UC09
RF10. O sistema deverá permitir aos avaliadores responder às questões
cadastradas para avaliação dos processos de sua empresa.
UC10
Quadro 6: Requisitos funcionais
O Quadro 7 lista os requisitos não funcionais previstos para o sistema.
Requisitos Não Funcionais
RNF01. A aplicação deve ser implementada no ambiente WEB.
RNF02. O sistema deve ser compatível com browser Internet Explorer 7.0.
RNF03. A aplicação deve ser desenvolvida com linguagem PHP.
RNF04. A aplicação deve ser desenvolvida com banco de dados MySQL.
Quadro 7: Requisitos não funcionais
3.2 ESPECIFICAÇÃO
Esta seção apresenta os diagramas de casos de uso do sistema proposto, sendo que o
detalhamento de cada caso de uso está descrito no Apêndice A.
Para a modelagem destes diagramas foi usado o aplicativo Enterprise Architect, uma
ferramenta de análise com interface gráfica e baseada nos conceitos Unified Modeling
Language (UML). Na figura 8 é apresentado o diagrama elaborado.
51
Figura 8 – Diagrama de casos de uso sobre as funcionalidades do sistema
52
A Figura 9 apresenta o diagrama de modelo de entidade relacional.
Figura 9 – Diagrama de entidade relacional
53
3.3 IMPLEMENTAÇÃO
A seguir são mostradas as técnicas e ferramentas utilizadas e a operacionalidade da
implementação.
3.3.1 Técnicas e ferramentas utilizadas
Para a implementação deste aplicativo utilizou-se a linguagem de desenvolvimento
Personal Home Page (PHP). Esta é uma linguagem de script open source de uso para o lado
servidor das aplicações web (OLSON, 2009). Para armazenamento dos dados foi utilizado um
sistema gerenciador de banco de dados, denominado MySQL.
Para os processamentos do aplicativo, que acontecem do lado do cliente, utilizou-se
HyperText Markup Language (HTML) e JavaScript. Ambas linguagens permitem maior
interatividade com o usuário final.
Durante o desenvolvimento deste aplicativo utiliram-se ferramentas para auxiliar no
processo de desenvolvimento do aplicativo, entre as quais incluem-se:
a) Adobe Dreamweaver CS3 – utilizada para a edição das páginas PHP, HTML e
JavaScript;
b) MySQL-Front – utilizada para conexão com banco de dados MySQL;
3.3.2 Operacionalidade da implementação
Nesta seção é apresentada a estrutura operacional para uso do aplicativo desenvolvido.
A estrutura apresentada a seguir tem como objetivo principal demonstrar a ordem cronológica
para uso do sistema, levando em consideração os cadastros e consultas.
A estrutura, representada na figura 10, demonstra todas as opções de cadastros e
consultas sem distinção por tipo de usuário.
54
Administração
Cidade
Departamento
Cargo
Usuários
Consultor
Empresa
Avaliador
Processos
Tipo da Representação
Área Proceso (PA)
Nivel de maturidade (ML)
Meta
Questão
Avaliação
Avaliação
Questionário de avaliação
Relatório
Relatório por ML e PA
Relatório de Questionário
Figura 10 – Visão hierárquica das telas do aplicativo
Na figura 11, apresenta-se a tela inicial do sistema. Nesta tela o usuário deve
informar login e senha para seu acesso.
Figura 11 – Tela Inicial do aplicativo
55
Após confirmação dos dados de acesso o aplicativo exibirá a tela principal do sistema
com todas as opções disponíveis para aquele usuário informado. O sistema possui 3 (três)
tipos de usuários, administrador, consultor e avaliador, o usuário administrador possui acesso
à todas as telas e poderá configurar qualquer combinação de permissão para os demais
usuários.
Na figura 12, apresenta-se a tela de cadastro de cidades. Esta tela encontra-se na
sessão de administração, onde tem-se as telas de cadastros essenciais para o início do uso do
sistema, sendo estas telas o cadastro de cidade, departamento e cargo. Na tela de cidades o
usuário deve informar o nome da cidade e seu respectivo estado. Como padrão de usabilidade
o aplicativo representa os campos obrigatórios através de suas descrições que são
apresentadas em negrito.
Figura 12 – Tela de cadastro de cidades
Na figura 13 e figura 14, apresenta-se a tela de cadastro de consultores e avaliadores
respectivamente. Esta tela encontra-se na sessão de Usuários, onde tem-se as telas de
cadastros de consultores, empresas e avaliadores. Na tela de cadastro dos consultores e
avaliadores o usuário deve informar os dados de cadastro e as telas que cada usuário poderá
acessar.
56
Figura 13 – Tela de cadastro de consultores
57
Figura 14 – Tela de cadastro de avaliadores
As figuras 15-19 representam as telas de cadastro do sistema levando-se em
consideração a representação por estágios. Encontram-se na sessão de processos, onde temos
as telas de cadastros essenciais para o início do cadastro de uma avaliação, sendo estas telas o
cadastro de tipo de representação, área de processo (PA), nível de maturidade (ML), meta e
questão. Todos os cadastros feitos nestas telas serão usados e apresentados durante a
aplicação de uma avaliação de maturidade.
58
Figura 15 – Tela de cadastro de tipo de representação
Figura 16 – Tela de cadastro de Área de Processo
59
Figura 17 – Tela de cadastro de Nível de Maturidade
60
Figura 18 – Tela de cadastro de metas
Figura 19 – Tela de cadastro de questões
A sessão de avaliações é composta pelo cadastro de avaliações - representado pela
figura 20 - e pelo questionário de avaliação – representado pela figura 21.
61
Figura 20 – Tela de cadastro de avaliações
Os processos de TI da organização serão avaliados de acordo com as questões
cadastradas no sistema. Estas questões são transformadas em um questionário on-line que será
respondido pelos avaliadores de cada organização. Representa-se na figura 21, a tela onde os
avaliadores responderão a cada questionamento sobre os processos da ITIL implantados.
62
Figura 21 – Tela de cadastro das respostas - Questionário de avaliação
Conforme figura 22, após a avaliação ter sido finalizada, o consultor poderá emitir o
relatório de questionário. Este relatório retonará na tela todas questões disponíveis e a as
repostas consolidadas por avaliador.
63
Figura 22 – Tela de relatório de questionário
Conforme figura 23, após a avaliação ter sido finalizada, o consultor poderá emitir o
relatório de resultado por nível de maturidade e área de processo, este relatório atende o
requisito específico e.
64
Neste relatório será possível visualizar o nível de maturidade alcançado em um
determinada organização, quando a avaliação aplicada tiver o tipo de representação por
estágio o aplicativo irá consolidar os processos por nível de maturidade. Já na rerpesentação
contínua e também a proposta pela ITIL, os processos serão exibidos sem consolidação por
serem avaliados de forma independente. A seguir destaca-se na figura 23 e 24 a forma de
exibição do relatório em suas duas formas.
Figura 23 – Tela do relatório de resultado modo por estágio
65
Como dados retornados neste relatório tem-se:
- Nível Atingido: que representa qual foi o percentual de maturidade alcançado por
esta área de processo;
- Nível esperado: esta coluna representa o valor cadastrado na tela de cadastro de nível
de maturidade;
- MS/ME: abreviação para metas satisfeitas e metas esperadas.
Figura 24 – Tela do relatório de resultado modo contínuo
66
3.4 RESULTADOS E DISCUSSÃO
Diante da importância que os processos e o gerenciamento dos serviços possuem para
o crescimento e gestão efetiva da empresa, a mensuração destes e seus respectivos processos
são cada vez mais relevantes. E por isso fazem juz ao investimento em aplicativos que
mensurem e promovam o aperfeiçoamento dos processos e serviços. Mesmo diante desta
importância da gestão dos serviços e sua mensuração destes durante a pesquisa para
desenvolvimento deste trabalho não foram encontrados muitos exemplos e trabalhos que
pudessem auxiliar na elaboração do mesmo.
Apesar de não ter sido encontrado estudos sobre os assuntos abordados podem-se
concluir que a maioria dos provedores de serviços de TI ainda vive em dois mundos:
produção e desenvolvimento. Cada um desses mundos tem sua própria linguagem, utiliza os
seus próprios modelos de referência, e ignora os interesses do outro domínio - os desejos e
necessidades do cliente.
Conforme Streubel (2008), aplicar o modelo de integração, CMMI, por si só não é
suficiente, é preciso ter lugar na cabeça das pessoas, bem como: a seção de desenvolvimento
deve ter atenção ao fato de que o tempo de vida da aplicação será maior que o tempo do
desenvolvimento do projeto. Evidenciando a necessidade do aprendizado da sessão de
produção, de que os serviços e os sistemas precisam ser desenvolvidos de forma metódica e
em estado de arte – em busca da perfeição.
Os desenvolvedores do modelo ITIL e CMMI se aproximaram para atender a essas
demandas com o ITIL v3 e CMMI-SVC (STREUBEL, 2008). Para isto o modelo CMMI
deixou de considerar apenas o desenvolvimento para considerar, as aquisições e serviços.
Originando as constelações do modelo, representadas na figura 25.
67
Fonte: Adaptado de Streubel (2008)
Figura 25 – CMMI e suas constelações
Com esta representação por constelações, podemos separar o CMMI e a ITIL por áreas
de aplicação. Na organização: o CMMI-DEV é responsável pelo suporte ao projeto,
engenharia e seus processos de desenvolvimento; a ITIL é responsável pela operação e
serviços; o CMMI-SVC preenche as lacunas entre estes itens e integra as áreas de aplicação.
A figura 26 representa esta divisão por áreas de aplicação. Logo a seguir, na figura 27,
demonstra-se a equivalência entre os processos da ITIL e do CMMI.
Fonte: Streubel (2008)
Figura 26 – Integração entre o CMMI e a ITIL
68
Fonte: Adaptado de Streubel (2008)
Figura 27 – Mapa de integração entre ITIL e CMMI – PAs Específicas
Os resultados obtidos após o estudo das orientações da ITIL e da metodologia do
CMMI-SVC pôde-se concluir que em nenhum momento um substituirá o outro e eles não
podem ser considerados como metodologias concorrentes. Cada metodologia possui seu
enfoque e suas estruturas de organização. Isto pode ser evidenciado através da figura 27, onde
alguns processos possuem equivalência, entretanto a maioria não. Foi possível observar que
dos processos da ITIL ainda faltam 14 equivalentes no CMMI-SVC, visto que a ITIL possui o
enfoque exclusivamente para serviços e a gestão destes. Já nos processos do CMMI-SVC
pode-se evidenciar que ainda faltam 13 processos equivalentes na ITIL, pois seu enfoque
engloba projetos de desenvolvimento e integração com s serviços.
Observou-se que o modo proposto para avaliação do nível de maturidade da ITIL se
aproxima do proposto pelo CMMI, quando utilizado a representação por contínua. Em ambas
são definidos os processos que serão avaliados e após isto pode-se submetê-los à avaliação
deste processo de forma independente. A diferença dos modelos de avaliação é evidenciada
pelos níveis de maturidade, onde a ITIL apresenta 9 níveis e o CMMI 6 níveis.
Os resultados obtidos no desenvolvimento deste trabalho foram satisfatórios nos
quesitos padronização da forma de mensurar a maturidade das organizações. Através do
aplicativo desenvolvido, por meio de sua estrutura, o responsável pela avaliação segue um
padrão que é estipulado durante a configuração do sistema.
Conforme Lourenço (2008) e Martins (2006) pode-se concluir através de um
69
questionário, aplicado de forma escrita, que as empresas onde foram feitos os estudos de caso
obteve-se o nível de maturidade dos processos destas. O diferencial entre este trabalho e os
mencionados anteriormente consiste basicamente em possibilitar que o questionário seja
respondido em um ambiente web, sem a interferência de um interlocutor, tornando assim o
processo de avaliação impessoal e teoricamente mais ágil, por permitir a resposta dos
questionários por vários usuários e empresa de forma simultânea.
Já Theilacher Junior (2000) elaborou sua monografia voltada a processos da área de
projetos de softwares, o trabalho desenvolvido por este, propôs a elaboração de um aplicativo
focado em uma determinada organização onde foi utilizado de forma aplicada, já o aplicativo
elaborado neste trabalho propõe que o mesmo possa ser utilizado em qualquer organização.
Sendo necessário apenas o ajusto do questionário a ser aplicado.
De acordo com os trabalhos correlatos aqui apresentados pode-se concluir que o
trabalho atual é totalmente aderente aos outros e considera-se o mesmo complementar. Os
resultados obtidos neste trabalho, em seu resultado final, conseguiram atingir todos os
objetivos iniciais do trabalho, sejam eles o conhecimento dos processos da ITIL e do CMMI-
SVC, como ainda o desenvolvimento de uma aplicação que permitissem a aplicação destes
conceitos.
70
4 CONCLUSÕES
Este trabalho se propôs a desenvolver uma aplicação web de avaliação do nível de
maturidade dos processos de uma organização.
O aplicativo desenvolvido tem funcionalidades essenciais para a padronização de uma
avaliação de maturidade e permite que um mesmo questionário seja aplicado em várias
organizações.
O sistema conseguiu atender seus objetivos principal e específicos, sendo
implementadas todas as funcionalidades que foram previstas durante a elaboração da
proposta. Espera-se que o mesmo ainda seja aperfeiçoado, pois entende-se que, os processos
estão em constante mudança, com vista às necessidades do mercado e com isso as aplicações
devem acompanhar a finco todas estas necessidades.
Por se tratar de uma ferramenta desenvolvida para um trabalho acadêmico espera-se
que o mesmo seja adotado pelas organizações e profissionais liberais, com o intuito de manter
a aplicação sempre engajada com as demandas do mercado e assim aumentar a eficácia das
avaliações.
As ferramentas e os ambientes utilizados para o desenvolvimento deste trabalho,
mostraram-se ideais, não apresentaram nenhum tipo de restrição que impossibilitasse a
realização do mesmo.
Este trabalho contribuiu ampliação dos conhecimentos pessoais, sobre a ITIL, CMMI,
processos, os termos técnicos e as formas de como avaliar os mesmos.
Também, no que diz respeito à superação das dificuldades, este trabalho contribuiu na
superação destas, visto que a experiência obtida no estudo de um idioma que não é conhecido
em sua plenitude, o inglês, tornou o mesmo mais desafiador e ao mesmo tempo
recompensador.
4.1 EXTENSÕES
Este trabalho apresenta algumas funções básicas para a avaliação da maturidade de
processos de TI e também foram empregados recursos básicos de desenvolvimento, assim
sendo, existem muitas outras formas de avaliação de processos e outras funcionalidades,
71
principalmente voltadas para usabilidade, que poderiam ser incluídas ou aperfeiçoadas. Entre
elas destacam-se:
a) criar relatórios e gráficos com o acompanhamento em tempo real para as
avaliações – fazendo com que os consultores e até a organização que esteja
sendo avaliada, possa acompanhar em tempo real o andamento das respostas
dos questionários e também conseguir identificar com antecedência a
probabilidade das metas serem atingidas ou não;
b) permitir a avaliação de departamentos de uma mesma empresa – em grandes
organizações pode surgira necessidade de aplicar a avaliação de maturidade
porém consolidada por departamento, para isso deve-se elaborar novos
relatórios e interfaces que permita este desmembramento;.
c) permitir a criação de versões para a mesma avaliação, sendo uma inicial e outra
posterior às ações de melhorias adotadas – devido a evolução dos processo é
muito importante fazer o acompanhamento desta evolução e para fazer este
controle faz-se necessário criar versões de uma mesma avaliação, onde após a
respostas de todas versão pode-se obter o comparativo dos níveis de
maturidade alcançados durante os diferentes momentos;
d) utilizar hipermídia adaptativa na interface – atualmente a interface web permite
muitos avanços no que diz respeito à customização da interface permitindo o
aperfeiçoamento da usabilidade;
e) permitir que na tela de questionário seja incluído comentários pelo avaliador;
f) permitir que na tela de questionário seja anexado evidências para a resposta;
72
REFERÊNCIAS BIBLIOGRÁFICAS
CARTLIDGE, Alison et al. Introductory Overview of ITIL® V3, 1. 2007, UK: The UK Chapter of the itSMF.
CLARK, BRADFORD K., The Effects of Software Process Maturity on Software Development Effort, Dissertation, Graduate School University of Southern California, University of Southern California, 1997;
GOOGLE, Imagens. 2009. Disponível em: < http://images.google.com.br >. Acesso em: 24 ago. 2009. HENDERSON, J. C.; VENKATRAMANN, N. Strategic alignment: leveraging information technology for transforming organizations. IBM Systems Journal, v. 32, n.1, p.4-16, 1993.
HUMMPHREY, W. S., Characterizing the Software Process: A Maturity Framework, Software Engineering Institute, CMU/SEI-87-TR-11, ADA182895, Julho, 1987a HUMMPHREY, W. S., Sweet, A Method for Assessing the Software Engineering Capability of Contractors, Software Engineering Institute, CMU/SEI-87-TR-23, ADA187320, Setembro, 1987b
LOURENÇO, Edna Joseane Goulart Amaral. Viabilidade do uso de ITIL em uma empresa de alimentos. 2008. Trabalho de Conclusão de Curso (Bacharelado em Ciências da Computação) - Centro de Ciências Exatas e Naturais, Universidade Regional de Blumenau, Blumenau.
LOVELOCK, C., & WRIGHT, L., 2004, Serviços - marketing e gestão. Editora Saraiva.
KULPA, M. K.;JOHNSON, K. A. Interpreting the CMMI: A process Improvement Approach. Editora Auerbach Publications, 2003.
MAGALHÃES, Ivan Luizio; PINHEIRO, Walfrido Brito . Gerenciamento de Serviços de TI na Prática: uma abordagem com base na ITIL. São Paulo: Novatec, 2007. MANSUR, R.. Governaça de Tecnologia – ITIL, 2005. Disponível em: < http://www.profissionaisdetecnologia.com.br/artigos/arquivos/itil.pdf >. Acesso em: 24 ago. 2009. MARTINS, Márcia Missias Gomes. Gerenciamento de Serviços de TI: uma proposta de integração de processos de melhoria e gestão de serviços. Dissertação de Mestrado. Universidade de Brasília. Distrito Federal, 2006 Disponível em: < http://www.ene.unb.br/public/mestrado/marciamissias.pdf>. Acesso em: 23 mar. 2009. OGC. ITIL, 2008. Disponível em: < http://www.ogc.gov.uk/guidance_itil_4899.asp>. Acesso em: 19 out. 2009.
73
OLSON, Philip. Manual do PHP, 2009. Disponível em: < http://www.php.net/manual/pt_BR/index.php >. Acesso em: 02 set. 2009. ROCHA, 2001; Rocha, A. R. C.; Maldonado, J. C.; Weber, K. C. Qualidade de Software. Prentice Hall, 2001
SEI. CMMI-SVC, 2009. Disponível em: < http://www.sei.cmu.edu/>. Acesso em: 19 out. 2009.
SÓRIA, Felipe Grando. Implantação do CMMI: Metodologia Baseada na abordagem por processos. 2006. Dissertação de Pós graduação. Pontificia Universidade Católica do Paraná.
STREUBEL, Ute. CMMI meets ITIL. Kugler Maag Cie GmbH, 2008.
THEILACHER JUNIOR, Uno. Análise de uma organização de software utilizando o modelo CMMI/sei v1.0. 2000. Trabalho de Conclusão de Curso (Bacharelado em Ciências da Computação) - Centro de Ciências Exatas e Naturais, Universidade Regional de Blumenau, Blumenau.
74
APÊNDICE A – Detalhamento dos casos de uso
No Quadro 8 apresenta-se o caso de uso “Cadastra nível de maturidade".
Nome do Caso de Uso UC001 - Cadastra nível de maturidade
Descrição Usuário acessa a aplicação para administrar os dados do nível de maturidade dos
processos da ITIL.
Ator Administrador
Pré-condição 1)Administrador Logado no sistema
Cenário principal 1) Sistema apresenta tela de listagem das Metas da área de processo
2) Administrador do sistema opta por cadastrar um nível de maturidade
3) Sistema apresenta tela de cadastro do nível de maturidade
4) Administrador preenche dados do nível de maturidade e confirma
5) Sistema valida os dados
6) Sistema confirma ação escolhida pelo administrador
Cenário Alternativo -
Pesquisar nível de
maturidade
No passo 2, caso o administrador do sistema opte por pesquisar um registro
2.1) Sistema apresenta tela de pesquisa do nível de maturidade
2.2) Administrador preenche o nível de maturidade desejado e confirma
2.3) Sistema retorna os dados contemplados na condição de pesquisa
Cenário Alternativo -
Alterar nível de
maturidade
No passo 2, caso o administrador do sistema opte por alterar um registro
2.1) Sistema apresenta tela de alteração do nível de maturidade
2.2) Administrador preenche dados do nível de maturidade e confirma
2.3) Sistema retorna ao passo 5
Cenário Alternativo -
Excluir nível de
maturidade
No passo 2, caso o administrador do sistema opte por excluir um nível de
maturidade
2.1) Sistema apresenta tela de exclusão do nível de maturidade
2.2) Administrador escolhe o nível de maturidade
2.3) Sistema retorna ao passo 5
Cenário Exceção -
Informação invalida -
Inclusão e alteração
No passo 5, caso não tenha sido informado ao menos um caracter na descrição da
Área de processo, sistema apresenta mensagem "Campo descrição deve ser
informado!"
Cenário Exceção -
Exclusão do registro
No passo 2.1, do cenário alternativo Excluir um nível de maturidade:
2.1.1) Sistema apresenta mensagem "Deseja realmente excluir os registros
selecionados?"
2.1.2) Se administrador opta em confirmar a exclusão retorna ao passo 5.
2.1.3) Se administrador opta em confirmar a exclusão retorna ao passo 5.
Pós-condição Administrador consultou, editou, apagou ou inseriu um nível de maturidade.
Quadro 8 – Descrição do caso de uso Cadastra nível de maturidade
75
No Quadro 9 apresenta-se o caso de uso " Cadastra área de processo (PA)".
Nome do Caso de Uso UC002 - Cadastra área de processo (PA)
Descrição Usuário acessa a aplicação para administrar os dados da área de processo.
Ator Administrador
Pré-condição 1)Administrador Logado no sistema; 2)Ao menos um nível de maturidade já cadastrada no sistema;
Cenário principal 1) Sistema apresenta tela de listagem da(s) áreas de processo(s) dos níveis de
maturidade
2) Administrador do sistema opta por cadastrar uma área de processo
3) Sistema apresenta tela de cadastro da Área de processo
4) Administrador preenche dados da Área de processo e confirma
5) Sistema valida os dados
6) Sistema confirma ação escolhida pelo administrador
Cenário Alternativo -
Pesquisar Área de
processo
No passo 2, caso o administrador do sistema opte por pesquisar um registro
2.1) Sistema apresenta tela de pesquisa do Área de processo
2.2) Administrador preenche a Área de processo desejado e confirma
2.3) Sistema retorna os dados contemplados na condição de pesquisa
Cenário Alternativo -
Alterar Área de processo
No passo 2, caso o administrador do sistema opte por alterar um registro
2.1) Sistema apresenta tela de alteração da Área de processo
2.2) Administrador preenche dados da Área de processo e confirma
2.3) Sistema retorna ao passo 5
Cenário Alternativo -
Excluir Área de processo
No passo 2, caso o administrador do sistema opte por excluir uma Área de processo
2.1) Sistema apresenta tela de exclusão da Área de processo
2.2) Administrador escolhe a Área de processo e confirma
2.3) Sistema retorna ao passo 5
Cenário Exceção -
Informação invalida -
Inclusão e alteração
No passo 5, caso não tenha sido informado ao menos um caracter na descrição da
Área de processo, sistema apresenta mensagem "Campo descrição deve ser
informado!"
Cenário Exceção -
Exclusão do registro
No passo 2.1, do cenário alternativo Excluir uma Área de processo:
2.1.1) Sistema apresenta mensagem "Deseja realmente excluir os registros
selecionados?"
2.1.2) Se administrador opta em confirmar a exclusão retorna ao passo 5.
2.1.3) Se administrador opta em confirmar a exclusão retorna ao passo 5.
Pós-condição Administrador consultou, editou, apagou ou inseriu uma área de processo.
Quadro 9 – Descrição do caso de uso Cadastra área de processo (PA)
No Quadro 10 apresenta-se o caso de uso " Cadastra metas da área de processo".
76
Nome do Caso de Uso UC003 - Cadastra metas da área de processo
Descrição Usuário acessa a aplicação para administrar os dados das metas das áreas de
processo.
Ator Administrador
Pré-condição 1)Administrador Logado no sistema; 2)Ao menos uma Área de processo já cadastrada no sistema;
Cenário principal 1) Sistema apresenta tela de listagem das Metas da área de processo
2) Administrador do sistema opta por cadastrar uma meta da área de processo
3) Sistema apresenta tela de cadastro das Metas da área de processo
4) Administrador preenche dados da meta da área de processo e confirma
5) Sistema valida os dados
6) Sistema confirma ação escolhida pelo administrador
Cenário Alternativo -
Pesquisar Metas da área
de processo
No passo 2, caso o administrador do sistema opte por pesquisar um registro
2.1) Sistema apresenta tela de pesquisa das Metas da área de processo
2.2) Administrador preenche a meta da área de processo desejada e confirma
2.3) Sistema retorna os dados contemplados na condição de pesquisa
Cenário Alternativo -
Alterar Metas da área de
processo
No passo 2, caso o administrador do sistema opte por alterar um registro
2.1) Sistema apresenta tela de alteração das Metas da área de processo
2.2) Administrador preenche dados das Metas da área de processo e confirma
2.3) Sistema retorna ao passo 5
Cenário Alternativo -
Excluir Metas da área de
processo
No passo 2, caso o administrador do sistema opte por excluir uma meta da área de
processo
2.1) Sistema apresenta tela de exclusão da meta da área de processo
2.2) Administrador escolhe a Área da meta da área de processo
2.3) Sistema retorna ao passo 5
Cenário Exceção -
Informação invalida -
Inclusão e alteração
No passo 5, caso não tenha sido informado ao menos um caracter na descrição da
meta da área de processo, sistema apresenta mensagem "Campo descrição deve ser
informado!"
Cenário Exceção -
Exclusão do registro
No passo 2.1, do cenário alternativo Excluir uma meta da área de processo:
2.1.1) Sistema apresenta mensagem "Deseja realmente excluir os registros
selecionados?"
2.1.2) Se administrador opta em confirmar a exclusão retorna ao passo 5.
2.1.3) Se administrador opta em confirmar a exclusão retorna ao passo 5.
Pós-condição Administrador consultou, editou, apagou ou inseriu uma área de processo.
Quadro 10– Descrição do caso de uso Cadastra metas da área de processo
No Quadro 11 apresenta-se o caso de uso "Cadastra perguntas/questões das metas a
serem alcançadas".
77
Nome do Caso de Uso UC004 - Cadastra perguntas/questões das metas a serem alcançadas
Descrição Usuário acessa a aplicação para administrar os dados das perguntas/questões das
metas a serem alcançadas.
Ator Administrador
Pré-condição 1)Administrador Logado no sistema; 2)Ao menos uma meta das áreas de processo já cadastrada no sistema;
Cenário principal 1) Sistema apresenta tela de listagem das Perguntas cadastradas
2) Administrador do sistema opta por cadastrar uma pergunta
3) Sistema apresenta tela de cadastro das Perguntas
4) Administrador preenche dados da meta da área de processo e confirma
5) Sistema valida os dados
6) Sistema confirma ação escolhida pelo administrador
Cenário Alternativo -
Pesquisar perguntas
No passo 2, caso o administrador do sistema opte por pesquisar um registro
2.1) Sistema apresenta tela de pesquisa das perguntas
2.2) Administrador preenche a perguntas desejada e confirma
2.3) Sistema retorna os dados contemplados na condição de pesquisa
Cenário Alternativo -
Alterar perguntas
No passo 2, caso o administrador do sistema opte por alterar um registro
2.1) Sistema apresenta tela de alteração das perguntas
2.2) Administrador preenche dados das perguntas e confirma
2.3) Sistema retorna ao passo 5
Cenário Alternativo -
Excluir perguntas
No passo 2, caso o administrador do sistema opte por excluir uma meta da área de
processo
2.1) Sistema apresenta tela de exclusão da meta da área de processo
2.2) Administrador escolhe a Área da meta da área de processo
2.3) Sistema retorna ao passo 5
Cenário Exceção -
Informação invalida -
Inclusão e alteração
No passo 5, caso não tenha sido informado ao menos um caracter na descrição
pergunta, sistema apresenta mensagem "Campo descrição deve ser informado!"
Cenário Exceção -
Exclusão do registro
No passo 2.1, do cenário alternativo Excluir perguntas:
2.1.1) Sistema apresenta mensagem "Deseja realmente excluir os registros
selecionados?"
2.1.2) Se administrador opta em confirmar a exclusão retorna ao passo 5.
2.1.3) Se administrador opta em confirmar a exclusão retorna ao passo 5.
Pós-condição Administrador consultou, editou, apagou ou inseriu uma área de processo.
Quadro 11– Descrição do caso de uso Cadastra perguntas/questões das metas a serem alcançadas
No Quadro 12 apresenta-se o caso de uso " Cadastrar consultores ".
78
Nome do Caso de Uso UC005 - Cadastrar consultores
Descrição Usuário acessa a aplicação para administrar os dados dos consultores que terão
permissão para executar avaliações.
Ator Administrador
Pré-condição 1)Administrador Logado no sistema;
Cenário principal 1) Sistema apresenta tela de listagem dos consultores
2) Administrador do sistema opta cadastrar um consultor
3) Sistema apresenta tela de cadastro dos consultores
4) Administrador preenche dados do consultor e confirma
5) Sistema valida os dados
6) Sistema confirma ação escolhida pelo administrador
Cenário Alternativo -
Pesquisar consultores
No passo 2, caso o administrador do sistema opte por pesquisar um registro
2.1) Sistema apresenta tela de pesquisa dos consultores
2.2) Administrador preenche dados do consultor desejado e confirma
2.3) Sistema retorna os dados contemplados na condição de pesquisa
Cenário Alternativo -
Alterar consultor
No passo 2, caso o administrador do sistema opte por alterar um registro
2.1) Sistema apresenta tela de alteração do consultor
2.2) Administrador preenche dados do consultor e confirma
2.3) Sistema retorna ao passo 5
Cenário Alternativo -
Excluir consultor
No passo 2, caso o administrador do sistema opte por excluir um consultor
2.1) Sistema apresenta tela de exclusão do consultor
2.2) Administrador escolhe o consultor
2.3) Sistema retorna ao passo 5
Cenário Exceção -
Informação invalida -
Inclusão e alteração
No passo 5, caso não tenha sido informado ao menos um caracter no nome do
consultor sistema apresenta mensagem "Campo nome deve ser informado!"
Cenário Exceção -
Exclusão do registro
No passo 2.1, do cenário alternativo Excluir um consultor
2.1.1) Sistema apresenta mensagem "Deseja realmente excluir os registros
selecionados?"
2.1.2) Se administrador opta em confirmar a exclusão retorna ao passo 5.
2.1.3) Se administrador opta em confirmar a exclusão retorna ao passo 5.
Pós-condição Administrador consultou, editou, apagou ou inseriu um consultor.
Quadro 12– Descrição do caso de uso Cadastrar consultores
No Quadro 13 apresenta-se o caso de uso "Cadastrar empresas".
Nome do Caso de Uso UC006 - Cadastrar empresas
Descrição Usuário acessa a aplicação para administrar os dados das empresas que terão seus
processos avaliados.
79
Ator Administrador e Consultor
Pré-condição 1)Administrador Logado no sistema;
Cenário principal 1) Sistema apresenta tela de listagem das empresas
2) Administrador do sistema opta por cadastrar uma empresa
3) Sistema apresenta tela de cadastro das empresas
4) Administrador preenche dados da empresa e confirma
5) Sistema valida os dados
6) Sistema confirma ação escolhida pelo administrador
Cenário Alternativo -
Pesquisar empresa
No passo 2, caso o administrador do sistema opte por pesquisar um registro
2.1) Sistema apresenta tela de pesquisa das empresas
2.2) Administrador preenche dados da empresa desejada e confirma
2.3) Sistema retorna os dados contemplados na condição de pesquisa
Cenário Alternativo -
Alterar empresa
No passo 2, caso o administrador do sistema opte por alterar um registro
2.1) Sistema apresenta tela de alteração da empresa
2.2) Administrador preenche dados da empresa e confirma
2.3) Sistema retorna ao passo 5
Cenário Alternativo -
Excluir empresa
No passo 2, caso o administrador do sistema opte por excluir uma empresa
2.1) Sistema apresenta tela de exclusão da empresa
2.2) Administrador escolhe uma empresa
2.3) Sistema retorna ao passo 5
Cenário Exceção -
Informação invalida -
Inclusão e alteração
No passo 5, caso não tenha sido informado ao menos um caracter no nome da
empresa sistema apresenta mensagem "Campo nome deve ser informado!"
Cenário Exceção -
Exclusão do registro
No passo 2.1, do cenário alternativo Excluir uma empresa
2.1.1) Sistema apresenta mensagem "Deseja realmente excluir os registros
selecionados?"
2.1.2) Se administrador opta em confirmar a exclusão retorna ao passo 5.
2.1.3) Se administrador opta em confirmar a exclusão retorna ao passo 5.
Pós-condição Administrador consultou, editou, apagou ou inseriu uma empresa.
Quadro 13– Descrição do caso de uso Cadastrar empresas
No Quadro 14 apresenta-se o caso de uso "Cadastrar avaliadores".
Nome do Caso de Uso UC007 - Cadastrar avaliadores
Descrição Usuário acessa a aplicação para administrar os dados dos avaliadores de cada
empresa, este avaliadores são as pessoas dentro de cada empresa que participará da
avaliação
Ator Administrador e Consultor
Pré-condição 1)Administrador Logado no sistema;
80
2) Ao menos uma empresa já cadastrada no sistema Cenário principal 1) Sistema apresenta tela de listagem dos Avaliadores
2) Administrador do sistema opta por cadastrar um Avaliador
3) Sistema apresenta tela de cadastro dos Avaliadores
4) Administrador preenche dados do Avaliador e confirma
5) Sistema valida os dados
6) Sistema confirma ação escolhida pelo administrador
Cenário Alternativo -
Pesquisar avaliadores
No passo 2, caso o administrador do sistema opte por pesquisar um registro
2.1) Sistema apresenta tela de pesquisa dos Avaliadores
2.2) Administrador preenche o Avaliador desejado e confirma
2.3) Sistema retorna os dados contemplados na condição de pesquisa
Cenário Alternativo -
Alterar avaliador
No passo 2, caso o administrador do sistema opte por alterar um registro
2.1) Sistema apresenta tela de alteração dos Avaliadores
2.2) Administrador preenche dados dos Avaliadores e confirma
2.3) Sistema retorna ao passo 5
Cenário Alternativo -
Excluir avaliador
No passo 2, caso o administrador do sistema opte por excluir um Avaliador
2.1) Sistema apresenta tela de exclusão dos Avaliadores
2.2) Administrador escolhe o avaliador e confirma
2.3) Sistema retorna ao passo 5
Cenário Exceção -
Informação invalida -
Inclusão e alteração
No passo 5, caso não tenha sido informado ao menos um caracter no nome do
Avaliador, sistema apresenta mensagem "Campo nome deve ser informado!"
Cenário Exceção -
Exclusão do registro
No passo 2.1, do cenário alternativo Excluir um Avaliador:
2.1.1) Sistema apresenta mensagem "Deseja realmente excluir os registros
selecionados?"
2.1.2) Se administrador opta em confirmar a exclusão retorna ao passo 5.
2.1.3) Se administrador opta em confirmar a exclusão retorna ao passo 5.
Pós-condição Administrador consultou, editou, apagou ou inseriu um avaliador.
Quadro 14– Descrição do caso de uso Cadastrar avaliadores
No Quadro 15 apresenta-se o caso de uso "Cadastrar avaliações".
Nome do Caso de Uso UC008 - Cadastrar avaliações
Descrição Usuário acessa a aplicação para administrar as avaliações que poderão ser
respondidas pelos avaliadores de cada empresa.
Ator Administrador ou Consultor
Pré-condição 1)Administrador/consultor Logado no sistema; 2) Ao menos um registro no cadastro de Questões das metas a serem alcançadas (UC004); 3) Ao menos um registro no cadastro de consultores (UC005); 4) Ao menos um registro no cadastro de empresas (UC006);
81
5) Ao menos um registro no cadastro de avaliadores (UC007); Cenário principal 1) Sistema apresenta tela de listagem das Avaliações
2) Administrador do sistema opta por cadastrar uma Avaliação
3) Sistema apresenta tela de cadastro das Avaliações
4) Administrador preenche dados (empresa que será avaliada, avaliadores
envolvidos, data de início da avaliação) das Avaliações e confirma
5) Sistema valida os dados
6) Sistema confirma ação escolhida pelo administrador
Cenário Alternativo -
Pesquisar avaliadores
No passo 2, caso o administrador do sistema opte por pesquisar um registro
2.1) Sistema apresenta tela de pesquisa das Avaliações
2.2) Administrador preenche os dados da Avaliação desejada e confirma
2.3) Sistema retorna os dados contemplados na condição de pesquisa
Cenário Alternativo -
Alterar avaliador
No passo 2, caso o administrador do sistema opte por alterar um registro
2.1) Sistema apresenta tela de alteração das Avaliações
2.2) Administrador preenche dados das Avaliações e confirma
2.3) Sistema valida os dados
2.4) Sistema retorna ao passo 3
Cenário Exceção -
Informação invalida -
Alteração
No passo 5, caso consultor deseje alterar o sistema deve validar se a avaliação já foi
finalizada, caso positivo o sistema apresenta mensagem " Uma avaliação já
finalizada não pode ser alterada!"
Pós-condição Administrador consultou, editou ou inseriu uma avaliação.
Quadro 15– Descrição do caso de uso Cadastrar avaliação
No Quadro 16 apresenta-se o caso de uso " Visualizar Relatório da avaliação ".
Nome do Caso de Uso UC009 – Visualizar Relatório da avaliação
Descrição Usuário acessa a aplicação para extrair relatório da avaliação executada.
Ator Consultor e avaliador
Pré-condição 1)Administrador Logado no sistema; 2) Ao menos uma avaliação cadastrada no sistema
Cenário principal 1) Sistema apresenta tela de relatório das Avaliações
2) Administrador do sistema escolhe a avaliação que deseja obter o relatório e
confirma
3) Sistema apresenta o relatório na tela para o consultor
Cenário Alternativo -
Imprimir relatório
No passo 3,
2.1) Sistema apresenta opção de imprimir o relatório
2.2) Consultor opta em imprimir o relatório ou não
2.3) Sistema envia relatório para impressão
Cenário Alternativo -
Exibir Avaliações
No passo 2, caso o usuário logado seja um consultor serão exibidas todas as
avaliações.
82
Caso o usuário logado seja um avaliador, serão exibidas somente as avaliações
pertencentes à sua empresa
Cenário Exceção -
Informação invalida -
Alteração
No passo 2, caso não tenha nenhuma avaliação disponível cadastrada e finalizada
sistema apresenta mensagem "Nenhuma avaliação disponível no momento"
Pós-condição Consultor visualiza ou imprime o relatório da avaliação.
Quadro 16– Descrição do caso de uso Cadastrar avaliações
No Quadro 17 apresenta-se o caso de uso "Responder às avaliações ".
Nome do Caso de Uso UC010 - Responder às avaliações
Descrição Usuário acessa a aplicação para responder às avaliações que estão disponíveis para
sua empresa e que poderão ser respondidas pelos avaliadores de cada empresa.
Ator Avaliador
Pré-condição 1)Administrador Logado no sistema; 2) Ao menos uma avaliação disponível para responder aos questionários da empresa deste avaliador.
Cenário principal 1) Sistema apresenta tela de listagem das Avaliações
2) Avaliador opta qual Avaliação será respondida
3) Sistema apresenta tela de respostas das questões de uma Avaliação
4) Avaliador responde perguntas (cada pergunta terá respostas objetivas e iguais
para todas as questões) das Avaliações e confirma
5) Sistema valida os dados
6) Sistema confirma ação escolhida pelo avaliador
Cenário Alternativo –
Pesquisar Avaliação
No passo 2, caso o avaliador do sistema opte por pesquisar um registro
2.1) Sistema apresenta tela de pesquisa das Avaliações
2.2) Administrador preenche os dados da Avaliação desejada e confirma
2.3) Sistema retorna os dados contemplados na condição de pesquisa
Cenário Alternativo –
Alterar avaliação
No passo 2, caso o consultor do sistema opte por alterar um registro
2.1) Sistema apresenta tela de alteração das Avaliações
2.2) Administrador preenche dados das Avaliações e confirma
2.3) Sistema valida os dados
2.4) Sistema retorna ao passo 3
Pós-condição Consultor pesquisa, edita ou cadastra uma avaliação.
Quadro 17– Descrição do caso de uso Cadastrar avaliação
83
APÊNDICE B – Questionário de avaliação Conforme Martins (2006), seguem as questões para o processo de gerenciamento de incidentes. Nível 1 Pré-requisitos 1. São mantidos registros de todos os incidentes reportados?
2. Os incidentes são verificados e classificados pela Central de Serviços antes de serem repassados a um especialista?
3. Existe um gestor responsável por gerenciar e escalar os incidentes?
Nível 1.5 Intenção de Gerenciamento
4. A organização está comprometida com a redução do impacto dos incidentes por sua resolução tempestiva?
5. Existem compromisso gerencial, orçamento e recursos disponíveis para o Gerenciamento de Incidentes?
6. O Gerenciamento de Incidentes conhece os objetivos e necessidades do negócio que determinarão as prioridades no trato dos incidentes?
7. Foi realizado um programa de treinamento para a Central de Serviços e gestores de incidentes mostrando seus relacionamentos e interfaces entre si e com os Gerenciamentos de Problemas, Configuração e Mudanças?
Nível 2 Capacidade do Processo
8. É mantida uma Base de Dados de Incidentes, com detalhes sobre todos os incidentes relatados?
9. O tratamento dos incidentes é feito em conformidade com procedimentos documentados em ANS?
10. Existe um procedimento para classificação dos incidentes, com um conjunto detalhado de códigos para classificação, priorização e determinação de impacto?
11. Existe um procedimento para atribuição, monitoramento e comunicação da evolução de incidentes?
12. O Gerenciamento de Incidentes fornece informações sobre a evolução ou mudança de status dos incidentes para a Central de Serviços ou cliente/usuário?
13. Existem procedimentos de fechamento de incidentes?
14. O Gerenciamento de Incidentes fornece a Central de Serviços informações e recomendações para melhoria dos serviços?
15. Os gestores de incidentes têm poderes para cobrar do suporte de segundo nível e dos fornecedores externos o cumprimento dos níveis de serviço estabelecidos?
84
16. Os gestores de incidentes exercem a coordenação do Gerenciamento de Problemas, pessoal de suporte e gerenciamento de serviços de TI quando ocorre um incidente de maior criticidade ou importância?
17. Foi feito um estudo sobre o conjunto de serviços suportados para determinar as habilidades e capacitação do pessoal envolvido, e os custos associados ao gerenciamento de incidentes?
Nível 2.5 Integração Interna 18. O Gerenciamento de Incidentes verifica cada incidente contra a base de dados de problemas e erros conhecidos?
19. O Gerenciamento de Incidentes informa a Central de Serviços e ao Gerenciamento de Problemas sobre os contornos aplicados?
20. É feita identificação de incidentes com acordos de níveis de serviço inadequados, e essa informação é repassada para a equipe de resolução de incidentes?
Nível 3 Produtos
21. São mantidos registros para todos os incidentes relatados (inclusive resolução e/ou contorno)?
22. São produzidas, se necessário, solicitações de mudança para resolução de incidentes?
23. Os registros dos incidentes resolvidos e fechados são atualizados e explicitamente comunicados a Central de Serviços, clientes e demais envolvidos?
24. São produzidos regularmente relatórios acerca do status dos incidentes para todas as equipes que contribuem para o processo de resolução de incidentes?
25. É realizada uma avaliação da carga de trabalho com a finalidade de ajudar a determinar o nível e composição das equipes de trabalho?
26. São executadas revisões gerenciais para destacar e detalhar os incidentes escalados para níveis superiores de resolução?
Nível 3.5 Controle de Qualidade 27. Os padrões e os critérios de qualidade aplicáveis ao registro de incidentes e tratamento de chamados estão claros para a equipe de Gerenciamento de Incidentes?
28. Os Acordos de Níveis de Serviço estão disponíveis para a equipe de Gerenciamento de Incidentes, e são claramente entendidos por seus integrantes?
29. O pessoal responsável pelo Gerenciamento de Incidentes está adequadamente treinado?
30. A organização estabelece e revisa as metas e objetivos para o Gerenciamento de Incidentes?
31. A organização usa ferramentas adequadas para sustentar o processo de Gerenciamento de Incidentes?
85
Nível 4 Informações de Gerenciamento
32. A organização alimenta o gerenciamento com informações referentes à análise de tendências da ocorrência e resolução de incidentes?
33. A organização alimenta o gerenciamento com informações referentes a incidentes escalados?
34. A organização alimenta o gerenciamento com informações referentes a percentual de incidentes tratado dentro do tempo estabelecido em acordo?
35. A organização alimenta o gerenciamento com informações referentes a percentual de incidentes fechados pela Central de Serviços sem recorrência a outros níveis de suporte?
Nível 4.5 Integração Externa 36. São mantidas reuniões regulares entre as partes interessadas e o Service Desk para discutir incidentes relatados, em progresso, escalados e fechados?
37. As interfaces entre a Central de Serviços e o Gerenciamento de Incidentes foram
definidas e adequadamente comunicadas aos envolvidos?
38. O Gerenciamento de Incidentes troca informações com o Gerenciamento de Problemas com relação a problemas relacionados e/ou erros conhecidos?
39. O Gerenciamento de Incidentes troca informações com o Gerenciamento de Configuração quanto à facilidade de uso dos registros de configuração, desvios de configuração e potencial marcação de itens de configuração como ‘em falha’ (ou equivalente)?
40. O Gerenciamento de Incidentes recebe informações do Gerenciamento de Mudanças quanto a mudanças programadas sobre os serviços?
41. O Gerenciamento de Incidentes troca informações com o Gerenciamento de Mudanças quanto aos detalhes de possíveis mudanças que possibilitem resolver incidentes ou problemas específicos?
42. O Gerenciamento de Incidentes troca informações com o Gerenciamento de Níveis de Serviços com relação a eventuais lacunas nos ANS e com relação às implicações para os compromissos de serviço e suporte?
Quadro 18– Questionário