Governança TI concursos

Governana de TI
para concursos
Volume terico
Sumrio
Sumrio
A Srie de Volumes Tericos
Prefcio
Direitos Autorais
Autores
Canais de Comunicao
11
Princpios de Governana de TI
12
1.1 Governana Corporativa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.2 Governana de TI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
ITIL V3 - Information Technology Infrastructure Library

2.1 Padres Relacionados ITIL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.1.1 BS 15000 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.1.2 ISO 20000 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.1.3 COBIT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.1.4 CMMI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2 Histrico e Principais Diferenas entre as Verses do ITIL . . . . . . . . . . . . . .
2.3 Principais Instituies Envolvidas com a ITIL . . . . . . . . . . . . . . . . . . . . .
2.4 Os Livros da ITIL V3 e as suas Disciplinas . . . . . . . . . . . . . . . . . . . . . . .
2.4.1 Service Strategy (Estratgia de Servio) . . . . . . . . . . . . . . . . . . . .
Strategy Generation (Gerao de Estratgia) . . . . . . . . . . . . . . . . .
Financial Management (Gerenciamento Financeiro) . . . . . . . . . . . . .
Service Portfolio Management (Gerenciamento de Portflio de Servio) .
Demand Management (Gerenciamento de Demanda) . . . . . . . . . . . .
Principais Papis e Responsabilidades . . . . . . . . . . . . . . . . . . . . .
2.4.2 Service Design (Desenho de Servio) . . . . . . . . . . . . . . . . . . . . . .
Service Catalogue Management (Gerenciamento de Catlogo de Servio)
Service Level Management (Gerenciamento de Nvel de Servio) . . . . .
Capacity Management (Gerenciamento de Capacidade) . . . . . . . . . . .
Availability Management (Gerenciamento de Disponibilidade) . . . . . .
IT Service Continuity Management (Gerenciamento de Continuidade de
Servio de TI) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Information Security Management (Gerenciamento da Segurana da Informao) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Supplier Management (Gerenciamento de Fornecedor) . . . . . . . . . . .
Principais Papis e Responsabilidades . . . . . . . . . . . . . . . . . . . . .
2
www.handbookdeti.com.br
14
17
17
17
17
18
18
20
21
23
25
25
25
26
26
26
27
27
28
28
29
29
30
30
Sumrio
2.4.3
2.5
2.6
2.7
3
Service Transition (Transio de Servio) . . . . . . . . . . . . . . . . . .

Transition Planning and Support (Planejamento e Suporte da Transio)
Change Management (Gerenciamento de Mudana) . . . . . . . . . . . .
Service Asset and Configuration Management (Gerenciamento de Configurao e Ativo de Servio de TI) . . . . . . . . . . . . . . . .
Knowledge Management (Gerenciamento de Conhecimento) . . . . . .
Service Validation and Testing (Validao e Teste de Servio) . . . . . . .
Release and Deployment Management (Gerenciamento de Liberao e
Implantao) . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Evaluation (Avaliao) . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Principais Papis e Responsabilidades . . . . . . . . . . . . . . . . . . . .
2.4.4 Service Operation (Operao de Servio) . . . . . . . . . . . . . . . . . .
Event Management (Gerenciamento de Evento) . . . . . . . . . . . . . .
Incident Management (Gerenciamento de Incidente) . . . . . . . . . . .
Problem Management (Gerenciamento de Problema) . . . . . . . . . . .
Request Fulfillment (Cumprimento de Requisio) . . . . . . . . . . . .
Access Management (Gerenciamento de Acesso) . . . . . . . . . . . . . .
2.4.5 Continual Service Improvement (Melhoria Contnua de Servio) . . . .
The 7 Improvement Process (Processo de Melhoria em 7 Etapas) . . . . .
Service Measurement (Mensurao de Servio) . . . . . . . . . . . . . . .
Service Reporting (Relatrio de Servio) . . . . . . . . . . . . . . . . . . .
Referncias entre Processos e Publicaes . . . . . . . . . . . . . . . . . . . . . .
Exames e Qualificaes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Os Principais Conceitos e Ferramentas da ITIL V3 . . . . . . . . . . . . . . . . .
COBIT 4.1 - Control Objectives for Information and related Technology

3.1 Framework COBIT 4.1 . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.1.1 Evoluo do COBIT . . . . . . . . . . . . . . . . . . . . . . . .
3.1.2 Produtos do COBIT . . . . . . . . . . . . . . . . . . . . . . . .
3.2 Conceitos Bsicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2.1 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Objetivos de Negcio . . . . . . . . . . . . . . . . . . . . . . . .
Objetivos de TI, de Processo e de Atividade . . . . . . . . . . .
Objetivos de Controle . . . . . . . . . . . . . . . . . . . . . . .
3.2.2 Critrios de Informao . . . . . . . . . . . . . . . . . . . . . .
3.2.3 Recursos de TI . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2.4 Crontrole Interno . . . . . . . . . . . . . . . . . . . . . . . . . .
3.3 Caractersticas do COBIT . . . . . . . . . . . . . . . . . . . . . . . . . .
3.3.1 Foco nos Negcios . . . . . . . . . . . . . . . . . . . . . . . . .
3.3.2 Orientado a Processos . . . . . . . . . . . . . . . . . . . . . . .
3.3.3 Baseado em Controles . . . . . . . . . . . . . . . . . . . . . . .
3.3.4 Direcionado a Medies . . . . . . . . . . . . . . . . . . . . . .
3.4 Estrutura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.5 Domnios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.5.1 Planejar e Organizar (PO) . . . . . . . . . . . . . . . . . . . . .
3.5.2 Adquirir e Implementar (AI) . . . . . . . . . . . . . . . . . . .
3.5.3 Entregar e Suportar (DS) . . . . . . . . . . . . . . . . . . . . . .
3
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 31
. 31
. 31
. 32
. 33
. 33
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
33
34
34
35
35
36
37
38
39
39
40
40
42
43
43
43
45
48
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
63
63
64
65
66
66
66
67
67
68
68
69
70
70
71
72
72
72
76
76
77
78
Sumrio
3.6
3.7
3.8
3.9
3.5.4 Monitorar e Avaliar (ME) . . . . . . . . . . . . . . . . . . . . . . . . . .

Controles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Modelo de Maturidade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Medio de Desempenho . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Processos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.9.1 Planejar e Organizar . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
P01 - Definir um Plano Estratgico de TI . . . . . . . . . . . . . . . . .
P02 - Definir a Arquitetura da Informao . . . . . . . . . . . . . . . . .
PO3 - Determinar as Diretrizes de Tecnologia . . . . . . . . . . . . . . .
PO4 - Definir os Processos, a Organizao e os Relacionamentos de TI
PO5 - Gerenciar o Investimento de TI . . . . . . . . . . . . . . . . . . .
PO6 - Comunicar Metas e Diretrizes Gerenciais . . . . . . . . . . . . .
PO7 - Gerenciar os Recursos Humanos de TI . . . . . . . . . . . . . . .
PO8 - Gerenciar a Qualidade . . . . . . . . . . . . . . . . . . . . . . . .
PO9 - Avaliar e Gerenciar os Riscos de TI . . . . . . . . . . . . . . . . .
PO10 - Gerenciar Projetos . . . . . . . . . . . . . . . . . . . . . . . . . .
3.9.2 Adquirir e Implementar . . . . . . . . . . . . . . . . . . . . . . . . . . .
AI1 - Identificar Solues Automatizadas . . . . . . . . . . . . . . . . .
AI2 - Adquirir e Manter Software Aplicativo . . . . . . . . . . . . . . .
AI3 - Adquirir e Manter Infraestrutura de Tecnologia . . . . . . . . . .
AI4 - Habilitar Operao e Uso . . . . . . . . . . . . . . . . . . . . . . .
AI5 - Adquirir Recursos de TI . . . . . . . . . . . . . . . . . . . . . . . .
AI6 - Gerenciar Mudanas . . . . . . . . . . . . . . . . . . . . . . . . . .
AI7 - Instalar e Homologar Solues e Mudanas . . . . . . . . . . . .
3.9.3 Entregar e Suportar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
DS1 - Definir e Gerenciar Nveis de Servios . . . . . . . . . . . . . . .
DS2 - Gerenciar Servios Terceirizados . . . . . . . . . . . . . . . . . . .
DS3 - Gerenciar o Desempenho e a Capacidade . . . . . . . . . . . . .
DS4 - Assegurar a Continuidade dos Servios . . . . . . . . . . . . . .
DS5 - Garantir a Segurana dos Sistemas . . . . . . . . . . . . . . . . .
DS6 - Identificar e Alocar Custos . . . . . . . . . . . . . . . . . . . . . .
DS7 - Educar e Treinar os Usurios . . . . . . . . . . . . . . . . . . . . .
DS8 - Gerenciar a Central de Servio e os Incidentes . . . . . . . . . . .
DS9 - Gerenciar a Configurao . . . . . . . . . . . . . . . . . . . . . . .
DS10 - Gerenciar Problemas . . . . . . . . . . . . . . . . . . . . . . . . .
DS11 - Gerenciar os Dados . . . . . . . . . . . . . . . . . . . . . . . . .
DS12 - Gerenciar o Ambiente Fsico . . . . . . . . . . . . . . . . . . . .
DS13 - Gerenciar as Operaes . . . . . . . . . . . . . . . . . . . . . . .
3.9.4 Monitorar e Avaliar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
ME1 - Monitorar e Avaliar o Desempenho de TI . . . . . . . . . . . . .
ME2 - Monitorar e Avaliar os Controles Internos . . . . . . . . . . . . .
ME3 - Assegurar a Conformidade com Requisitos Externos . . . . . .
ME4 - Prover Governana de TI . . . . . . . . . . . . . . . . . . . . . .
Normas para Qualidade de Software

4.1 Conceitos Bsicos . . . . . . . . .
4.2 Normas da ISO . . . . . . . . . .
4.2.1 ISO 9000:2000 . . . . . . .
4.2.2 ISO 9001:2000 . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
4
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
80
80
83
86
88
90
90
92
94
96
98
100
102
104
106
108
110
110
112
114
116
118
120
122
124
124
126
128
130
132
134
136
138
140
142
144
146
148
150
150
152
154
156
.
.
.
.
.
.
.
.
159
159
160
160
161
Sumrio
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
162
165
170
170
172
173
174
174
175
175
175
178
179
184
185
189
190
Tpicos Especiais em Governana de TI

5.1 Arquitetura Corporativa . . . . . . . . . . . . . . . . . . . . . . . . . .
5.1.1 Framework Zachman . . . . . . . . . . . . . . . . . . . . . . .
5.1.2 The Open Group Architecture Framework (TOGAF) . . . . .
5.1.3 Federal Enterprise Architecture (FEA) . . . . . . . . . . . . . .
5.1.4 Metodologia Gartner . . . . . . . . . . . . . . . . . . . . . . . .
5.2 Marcos de Regulao . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.2.1 Foreign Corrupt Practices Act of 1977 (FCPA) . . . . . . . . .
5.2.2 Lei Sarbanes-Oxley . . . . . . . . . . . . . . . . . . . . . . . . .
5.2.3 Acordo de Basileia II e a Resoluo 3380/2006 do CMN . . . .
5.3 Arquitetura de Controle Interno . . . . . . . . . . . . . . . . . . . . . .
5.3.1 Frameworks de controles internos . . . . . . . . . . . . . . . .
5.3.2 COSO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.4 Metodologias para Outsourcing de TI . . . . . . . . . . . . . . . . . .
5.4.1 eSCM-SP - eSourcing Capability Model for Service Providers
5.4.2 eSCM-CL - eSourcing Capability Model for Clients . . . . . .
5.4.3 SAS 70 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.5 Metodologias de Qualidade e Desempenho . . . . . . . . . . . . . . .
5.5.1 Seis Sigma . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.5.2 BSC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.6 Outros Frameworks de Governana em TI . . . . . . . . . . . . . . . .
5.6.1 ISO/IEC 38500 . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.6.2 Val IT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
192
192
193
195
198
199
200
200
201
203
204
204
205
208
209
211
212
213
213
216
218
218
220
4.3
4.4
4.2.3 ISO/IEC 12207 . . . . . . . . . . . . . . . . . . .

4.2.4 ISO/IEC 15504 (SPICE) . . . . . . . . . . . . . .
CMMI . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.3.1 Histrico e Objetivos do CMMI . . . . . . . . . .
4.3.2 Conceitos Bsicos de CMMI . . . . . . . . . . . .
4.3.3 Representao Contnua . . . . . . . . . . . . . .
Gerenciamento de Processos . . . . . . . . . . .
Gerenciamento de Projetos . . . . . . . . . . . .
Engenharia . . . . . . . . . . . . . . . . . . . . .
Suporte . . . . . . . . . . . . . . . . . . . . . . . .
4.3.4 Representao em Estgios . . . . . . . . . . . .
4.3.5 Comparao entre as Formas de Representao
4.3.6 Constelaes . . . . . . . . . . . . . . . . . . . .
MPS.Br . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.4.1 MR-MPS . . . . . . . . . . . . . . . . . . . . . . .
4.4.2 MA-MPS . . . . . . . . . . . . . . . . . . . . . . .
4.4.3 MN-MPS . . . . . . . . . . . . . . . . . . . . . . .
ndice Remissivo
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
226
5

O Grupo Handbook de TI existe desde 2005, e desde ento os nossos materiais didticos j alcanaram mais de 500 cidades espalhadas por todo o territrio nacional. O pioneirismo desse
trabalho auxiliou concurseiros de TI dos mais diversos perfis e necessidades. Para os que estavam no incio da jornada de preparao, tais materiais serviram como guia inicial de estudo
para os assuntos mais importantes. Para os que buscavam revisar contedos j conhecidos, os
Handbooks trabalharam como aceleradores.
Com o nosso primeiro produto, o Handbook de TI para Concursos - O Guia Definitivo, levamos aos
candidatos mais de 550 pginas do que havia de mais relevante a ser estudados para concursos
na rea de TI. Na sequncia, trouxemos as sries Handbook de Questes de TI Comentadas para
Concursos Alm do Gabarito e Handbook de Questes de TI Comentadas para Concursos Divididas
por Assunto, ambas com centenas de questes comentadas em detalhes, ou, como costumamos
dizer, comentadas alm do gabarito.
Porm os desafios dos concursos de TI permanecem em mutao. Diante disso, para complementar o nosso portflio e deixar o seu arsenal ainda mais forte, trazemos agora a srie
Handbook de TI - Volumes Tericos, cuja estruturao e contedo so frutos de uma rigorosa
anlise de editais dos concursos de TI mais atuais.
Sero diversos volumes tericos que traro, em nvel de detalhe apropriado para os concurseiros, snteses tericas sobre assuntos como Governana de TI, Segurana da Informao, Sistemas Operacionais e muitos outros tambm de grande importncia. Esperamos que a srie
Handbook de TI - Volumes Tericos lhe auxilie ainda mais a alcanar a sua vaga e os seus objetivos.
Bons estudos,
Grupo Handbook de TI
6
Prefcio
Prefcio
Segundo o IT Governance Institute, Governana de TI uma parte integral da Governana
Corporativa e formada pela liderana, estruturas organizacionais e processos que garantem
que a TI sustente e melhore a estratgia das organizaes, permitindo que elas alcancem seus
objetivos. Em termos prticos, a governana de TI engloba a adoo de padres de mercado,
como ITIL, Cobit, CMMI, BSC, entre outros.
Compreender esses padres e ser capaz de implement-los nas organizaes pblicas e privadas tm se tornado requisitos bsicos para os profissionais da rea de TI. Por isso, em quase
todos os concursos pblicos na rea de TI tm sido exigidos conhecimentos de ITIL, Cobit,
entre outros padres de mercado.
Para suprir essa necessidade, o Grupo Handbook de TI preparou este volume, trazendo e
detalhando os principais temas em governana de TI para voc se preparar ainda melhor para
as provas do seu interesse.
Bons estudos,
7
Direitos Autorais
Direitos Autorais
Este material registrado no Escritrio de Direitos Autorais (EDA) da Fundao Biblioteca
Nacional. Todos os direitos autorais referentes a esta obra so reservados exclusivamente aos
seus autores.
Os autores deste material no probem seu compartilhamento entre amigos e colegas prximos de estudo. Contudo, a reproduo, parcial ou integral, e a disseminao deste material de
forma indiscriminada atravs de qualquer meio, inclusive na Internet, extrapolam os limites
da colaborao. Essa prtica desincentiva o lanamento de novos produtos e enfraquece a comunidade concurseira Handbook de TI.
A srie Handbook de TI Volumes Tericos uma produo independente e contamos com voc
para mant-la sempre viva.
8
Autores
Autores
O Grupo Handbook de TI garante a alta qualidade do contedo produzido atravs de uma
equipe de autores altamente capacitada, que inclui profissionais de peso que mesclam vasto
conhecimento prtico e acadmico. Na linha de frente da operao e produo do Grupo
Handbook de TI, esto os seguintes profissionais:
Andr Camatta
Andr Camatta Engenheiro de Computao pela Universidade Federal do Esprito Santo,
e atualmente trabalha como Analista de Sistemas no BNDES. Atuou tambm por 2 anos como
Analista de Sistemas da Petrobras, administrando sistemas SAP. Andr tem timos conhecimentos nas reas de programao, desenvolvimento de sistemas e de banco de dados. Andr
um dos fundadores do Grupo Handbook de TI.
Bruno Zanetti
Bruno Engenheiro de Computao e Mestre em Engenharia Eltrica pela Universidade Federal do Esprito Santo. Bruno especialista em computao de alto desempenho, busca e classificao automtica de informaes, e atualmente um integrante do brao acadmico do
Grupo Handbook de TI. Bruno um dos fundadores do Grupo Handbook de TI.
Diogo Gobira
Diogo Gobira Engenheiro de Computao pela Universidade Federal do Esprito Santo, e
atualmente trabalha como Analista de Sistemas no BNDES. Atuou tambm como Analista de
Sistemas na Petrobras por 2 anos, gerenciando projetos corporativos de Segurana da Informao e Integrao de Sistemas. Diogo possui timos conhecimentos em redes, segurana da
informao e integrao de sistemas. Diogo um dos fundadores do Grupo Handbook de TI.
Felipe Thomaz
Felipe Thomaz Engenheiro e Mestre em Computao pela Universidade Federal do Esprito
Santo, sendo especialista nas reas de arquitetura de computadores e sistemas operacionais
e, atualmente, trabalha como Engenheiro de Desenvolvimento de Produto na Embraer. Tem
vasto conhecimento em computao de alto desempenho e pesquisador em diversas reas
de TI. Assim como Bruno, Felipe compe o brao acadmico do Grupo Handbook de TI.
Ricardo Vargas
Ricardo Vargas Engenheiro de Computao e Mestre em Engenharia Eltrica pela Universi-
9
Autores
dade Federal do Esprito Santo. Atualmente, trabalha como Analista de Sistemas da Petrobras.
Possui vasto conhecimento nas reas de programao e administrao de clusters. No Grupo
Handbook, Ricardo desempenha o papel fundamental de editor, sendo responsvel pela implementao de processos de melhoria contnua nos materiais publicados.
10
Canais de Comunicao
Canais de Comunicao
O Grupo Handbook de TI disponibiliza diversos canais de comunicao para os concurseiros
de TI.
Loja Handbook de TI
Acesse a nossa loja virtual em http://www.handbookdeti.com.br
Servio de Atendimento
Comunique-se diretamente conosco atravs do e-mail faleconosco@handbookdeti.com.
br
Twitter do Handbook de TI
Acompanhe de perto promoes e lanamentos de produtos pelo nosso Twitter http://
twitter.com/handbookdeti
11
Captulo 1. Princpios de Governana de TI
Captulo 1
Princpios de Governana de TI
1.1
Governana Corporativa
Governana o conjunto de processos, costumes, polticas, leis, regulamentos e instituies

que regulam o funcionamento de um sistema. Quando este sistema uma empresa, comum
a utilizao da expresso governana corporativa. A governana corporativa diz respeito, portanto, maneira como uma empresa administrada, tendo como pilares:
Transparncia: A informao deve ser prestada s partes interessadas pelo desejo de
informar, e no apenas pelo cumprimento de exigncia legal ou estatutria. Esse princpio defende ainda que a informao v alm das demonstraes econmico-financeiras,
atingindo tambm atitudes que norteiam aes gerenciais que possam conduzir gerao de valor da organizao.
Equidade: Esse princpio se estabelece para evitar qualquer ao discriminatria e a
certeza de tratamento justo entre as partes relacionadas.
Prestao de Contas: Os agentes que esto frente da Governana (scios, diretores,
conselheiros de administrao, auditores, administradores em geral) esto obrigados a
prestar contas por sua atuao, sendo totalmente responsveis por seus atos ou omisses.
Responsabilidade Corporativa: Esse princpio prope que cada um faa a sua parte para
um mundo melhor, orientando as organizaes que projetem suas aes incorporando
consideraes de ordem social e ambiental na definio dos seus negcios e operaes.
1.2
Governana de TI
A governana corporativa, por sua vez, pode ter derivaes. A Governana Tecnolgica, ou
Governana de TI, uma delas, englobando a gesto tecnolgica e das informaes de forma
alinhada aos objetivos estratgicos das empresas.
Segundo Peter Weill e Jeanne Ross, autores de Governana de TI, em virtude deste forte
alinhamento a estratgia da empresa, uma boa estrutura de governana de TI deve ser capaz
de responder as seguintes questes:
Os investimentos em TI esto gerando retorno para a empresa?
Como garantir o uso e a gesto apropriada dos recursos de TI?
12
Captulo 1. Princpios de Governana de TI

Quem deve tomar as decises de TI na empresa?
Como as decises de TI devem ser tomadas e monitoradas?
J em termos mais prticos, Joo Peres define Governana de TI da seguinte forma:
Governana de TI um conjunto de prticas, padres e relacionamentos estruturados, assumidos por
executivos, gestores, tcnicos e usurios de TI de uma organizao, com a finalidade de garantir controles efetivos, ampliar os processos de segurana, minimizar os riscos, ampliar o desempenho, otimizar
a aplicao de recursos, reduzir os custos, suportar as melhores decises e conseqentemente alinhar TI
aos negcios.
Para permitir que as organizaes construam seus sistemas de governana de TI, desenvolveramse uma grande quantidade de frameworks voltados para a governana de TI, alguns mais
genricos, outros focados em segmentos de TI especficos. Entre a grande sopa de letrinhas
com a qual voc ir se deparar ao estudar governana de TI, merecem destaque os padres
COBIT, ITIL, CMMI, MPS.BR, e outras que sero abordados com mais detalhes neste Volume.
13
Captulo 2. ITIL V3 - Information Technology Infrastructure Library
Captulo 2
ITIL V3 - Information Technology

Infrastructure Library
ITIL (Information Technology Infrastructure Library) o modelo de referncia pblico para
gerenciamento de servios de TI mais aceito mundialmente nos dias de hoje. Ela um conjunto
de boas prticas recomendadas a serem aplicadas no desenvolvimento, na infraestrutura, na
operao e na manuteno de servios de TI em geral. Cabe ressaltar que esse conjunto de boas
prticas foi compilado a partir de experincias prticas de organizaes, privadas e pblicas,
de todo o mundo.
importante ter sempre em mente que a ITIL no pode ser classificada como uma metodologia. Portanto, no seria correto se referir a qualquer empresa como conforme em relao
ITIL. Essa biblioteca como um todo estabelece um conjunto de recomendaes que podem ser
integral ou parcialmente seguidas. Ou seja, no h de qualquer forma estabelecido nenhum
conjunto mnimo de determinaes que devem ser respeitadas. justamente por isso que no
h nenhum processo de certificao oficial associado diretamente ITIL aplicado a empresas
ou instituies.
Antes de prosseguirmos com o assunto, interessante conhecermos duas definies formais:
Servio de TI: um meio para entregar valor aos clientes, propiciando os resultados
que eles queiram alcanar sem que eles tenham que assumir custos e riscos especficos.;
Gerenciamento de Servios de TI: um conjunto de capacidades organizacionais especficas (processos, mtodos, funes, papis e atividades) para prover valor aos clientes
sob a forma de servios..
A ITIL foi desenvolvida no final dos anos 80 pela CCTA (Central Computer and Telecommunications Agency) e atualmente est sob custdia da OGC (Office for Government Commerce), ambas instituies inglesas. O objetivo inicial era disciplinar e facilitar a comparao
entre as diversas propostas de prestadores de servios de TI do governo britnico. Na verdade, antes dela receber este nome, ela era chamada de Government Information Technology
Infrastructure Management.
Esse modelo de referncia busca promover gesto com foco no cliente e na qualidade dos
servios de TI. A ITIL enderea estruturas de processos para a gesto de uma organizao de
TI, apresentando um conjunto abrangente de processos e procedimentos gerenciais, organizados em disciplinas, com os quais uma organizao pode fazer sua gesto ttica e operacional
14

em vista de alcanar o alinhamento estratgico com os seus negcios. Essa biblioteca tambm
oferece uma descrio detalhada sobre importantes prticas de IT, como checklists, tarefas e
procedimentos, que qualquer organizao de IT pode adotar e adaptar, tendo em vista as suas
necessidades especficas. Os conceitos, processos e ferramentas propostos so genricos, podendo ser utilizados por qualquer empresa de TI, seja ela pblica ou privada, de grande ou
pequeno porte.
Ao ler este Captulo, possvel perceber que ITIL um tema muito vasto e rico. Informaes
adicionais a respeito de aspectos especficos podem ser buscadas nos prprios livros da ITIL.
Esses materiais so vendidos em livrarias, principalmente as on-line, ou no website oficial da
ITIL: http://www.itil-officialsite.com. Em geral, tais livros no so facilmente encontrados em livrarias fsicas por conta dos seus preos, que so relativamente altos. Contudo,
certamente so eles que tm todos os termos e definies relacionados ITIL, inclusive os
menos utilizados, comentados e famosos. Na Figura 2.1, so apresentadas as capas dos livros
oficiais da ITIL V3.
15
Figura 2.1: capas dos livros oficiais da ITIL V3.
16
2.1
Padres Relacionados ITIL
Desde os anos 90, ITIL considerada Padro de Fato. Ou seja, o prprio mercado de servios
de TI passou a adotar, sem nenhum tipo de imposio governamental ou algo do gnero, essa
biblioteca e as suas recomendaes de boas prticas. Em relao a padres relacionados ITIL,
podemos citar:
2.1.1
BS 15000
A sigla BS significa British Standard (Padro Britnico). Este foi o primeiro padro elaborado
exclusivamente para gerenciamento de servios de TI, lanado em 2005. Ele descreve um conjunto de processos para uma efetiva entrega de servios ao negcio e aos seus clientes. Ele
composto pelo BS 15000-1 e pelo BS 15000-2.
O primeiro a parte certificvel deste padro. Ou seja, ele que contm a especificao dos
requisitos mnimos a serem cumpridos pelas instituies que buscam estar conformes em relao a este padro. J o BS 15000-2 tido como um documento para as instituies utilizarem
durante as suas preparaes para o processo de certificao dentro do escopo do BS 15000-1.
Assim como a ITIL, o BS 15000-2 tambm traz uma srie de boas prticas para gerenciamento
de servios de TI.
2.1.2
ISO 20000
Em 2006 o padro BS 15000 foi submetido ISO (International Organization for Standardization), dando origem ao ISO 20000. Com isso, de certa forma, o BS 15000 passou a ser um
padro mundial.
Assim como no padro britnico, o ISO 20000 composto por dois volumes: ISO 20000-1
(sucessor do BS 15000-1) e ISO 2000-2 (sucessor do BS 15000-2). As suas ltimas revises se
deram, respectivamente, em 2011 e 2005.
A forma mais fcil de se obter o padro ISO 20000 no prprio website oficial da instituio:
http://www.iso.org. Esse padro completo pode ser adquirido por, aproximadamente,
U$ 300.
2.1.3
COBIT
COBIT um framework para governana de TI. Ele foi elaborado e continua sendo mantido
pela ISACA (Information Systems Audit and Control Association), que foi fundada nos EUA
em 1967. O website oficial da ISACA o www.isaca.org.
O COBIT destinado primordialmente a auditores, sejam eles internos ou externos. Isso
porque ele enfatiza o que pode ser auditado e como isso pode ser feito. Ele no norteia de
forma detalhada os profissionais que operam de fato os processos auditveis.
importante perceber que o COBIT e a ITIL no so publicaes concorrentes, nem mesmo
mutuamente excludentes. Elas podem ser utilizadas em conjunto pela organizao. A ITIL
prov as melhores prticas para o gerenciamento e a melhoria continua dos processos destinados entrega de servios de TI de alta qualidade. J o COBIT prov um guia de como os
17

processos devem ser auditados e avaliados no intuito de se verificar se tais processos esto
sendo operacionalizados a contento, gerando o mximo de benefcios organizao.
2.1.4
CMMI
CMMI (Capability Maturity Model Integration) um modelo de maturidade proprietrio desenvolvido pela Software Engineering Institute (SEI), um rgo da Carnegie Mellon University. Essa universidade fica nos EUA. Ela mantm um website com mais informaes sobre o
CMMI: www.sei.cmu.edu/cmmi.
Apesar do CMMI e da ITIL tratarem de assuntos com vrios pontos de interseo, entendese que eles tambm no so mutuamente excludentes. O CMMI prov as melhores prticas
aplicadas aos processos de desenvolvimento, manuteno e integrao de sistemas computacionais. J a ITIL prov as melhores prticas para o gerenciamento e a melhoria continua dos
processos, mais relacionados infraestrutura de TI (software e hardware), destinados a entrega de servios de TI de alta qualidade.
Perceba, portanto, que enquanto o foco do CMMI auxiliar a organizao a ganhar cada vez
mais competncia e experincia em como desenvolver, manter e integrar sistemas; o foco da
ITIL auxiliar o alinhamento de todos os processos de TI em relao aos processos da rea de
negcio da organizao.
2.2
Histrico e Principais Diferenas entre as Verses do ITIL
A sua primeira verso, denominada ITIL Original, durou de 1986 at 1999. Ao longo da sua
existncia, ela chegou a ser composta por cerca de 40 livros. Essa a razo do termo biblioteca.
A sua segunda verso (ITIL V2) durou de 1999 at 2007. O foco principal dessa reviso foi
a consolidao das publicaes anteriores em conjuntos lgicos que agrupam os processos
relacionados aos diferentes aspectos do gerenciamento de TI. O conjunto de Gerenciamento de
Servio de TI (Service Support e Service Delivery) o mais conhecido e aplicado. Contudo,
a biblioteca prov um conjunto de melhores prticas bem mais extenso, que alcana tambm
o gerenciamento estratgico, de operaes e at mesmo financeiro. Os sete principais livros
(volumes) da verso 2 da ITIL so:
Grupo de Gerenciamento de Servio de TI
1. Service Delivery (Entrega de Servio)
2. Service Support (Suporte de Servio)
Grupo de Guias Operacionais
3. ICT Infrastructure Management (Gerenciamento de Infraestrutura de TI e Comunicaes)
4. Security Management (Gerenciamento de Segurana)
5. The Business Perspective (A Perspectiva do Negcio)
6. Application Management (Gerenciamento de Aplicao)
7. Software Asset Management (Gerenciamento de Recursos de Software)
18

Visando auxiliar a implementao das melhores prticas sugeridas pela ITIL, um novo livro
foi publicado posteriormente.
8. Planning to Implement Service Management (Planejamento para a Implementao
da Gesto de Servio)
Sem dvida, os dois livros (volumes) mais importantes da ITIL V2 so: Service Support e
Service Delivery. Abaixo esto listadas as suas disciplinas (processos):
Service Support (Suporte de Servio)
Incident Management (Gerenciamento de Incidente)
Problem Management (Gerenciamento de Problema)
Configuration Management (Gerenciamento de Configurao)
Change Management (Gerenciamento de Mudana)
Release Management (Gerenciamento de Liberao)
Service Delivery (Entrega de Servio)
Service Level Management (Gerenciamento de Nvel de Servio)
Financial Management (Gerenciamento Financeiro)
Availability Management (Gerenciamento de Disponibilidade)
Capacity Management (Gerenciamento de Capacidade)
Service Continuity Management (Gerenciamento de Continuidade de Servio)
A Figura 2.2 sintetiza as interfaces entre os volumes da ITIL V2 e tambm os relacionamentos
entre eles, o negcio e a prpria tecnologia da informao.
Figura 2.2: interfaces entre os volumes da ITIL V2.

Em dezembro de 2005, a OGC anunciou uma nova reviso da biblioteca, denominada ITIL V3,
que se tornou disponvel em maio de 2007. Essa mais nova verso reorganiza os processos em
funo das 5 fases do ciclo de vida de servio TI. A saber:
19

Service Strategy (Estratgia de Servio), com 4 processos
Service Design (Desenho de Servio), com 7 processos
Service Transition (Transio de Servio), com 7 processos
Service Operation (Operao de Servio), com 5 processos
Continual Service Improvement (Melhoria Contnua de Servio), com 3 processos
As principais novidades da verso 3 em relao verso anterior so:
abordagem mais clara de TI como servio;
reorganizao dos processos ao longo das fases do ciclo de vida de servio TI;
casamento de um ciclo de melhoria contnua dos servios (PDCA) com as prprias fases
do ciclo de vida de servio;
o ncleo passou a ser os processos da fase Service Strategy, deixando de ser os processos
do Grupo de Gerenciamento de Servio de TI. Compare as Figuras 2.2 e 2.3.
2.3
Principais Instituies Envolvidas com a ITIL
Como j foi mencionado, a ITIL mantida pela Office for Government Commerce. Essa instituio assegura, em alto nvel, a qualidade da estrutura atual e futura da ITIL. Alm dessa
instituio, h outras envolvidas com o tema de gerenciamento de servios de TI.
APM Group Ltd
Aps o lanamento da verso 3 da ITIL, a OGC responsabilizou o APM Group por definir os
padres dos exames, os provedores de treinamento, os instrutores e os prprios materiais de
treinamento. Alm disso, a APM Group tambm passou a definir as instituies examinadores.
So as instituies examinadores que tm os instrutores e executam de fato os treinamentos e
exames.
Atualmente, h vrias instituies examinadores certificadas:
APMG-International
BCS-ISEB
CERT-IT
CSME
DANSK IT
DF Certifiering AB
EXIN
Loyalist Certification ServicesLoyalist Certification Services
PEOPLECERT Group
20

TUV SUD Akademie
itSMF
O Frum de Gerenciamento de Servio de TI (itSMF) foi criado na prpria Inglaterra em 1991.
A partir da filiais foram sendo abertas em vrios pases do globo, por exemplo: frica do
Sul, Alemanha, Austrlia, ustria, Blgica, Brasil, EUA, Holanda e Sua. Cada filial legalmente independente das demais.
O itSMF busca promover experincias que permitem as organizaes de TI melhorarem os
seus servios. Ele organiza congressos, encontros tcnicos e outros eventos ligados a gerenciamento de servios de TI. Cabe ressaltar que o itSMF uma organizao independente e sem
fins lucrativos. Ele representa atualmente uma rede com mais de 6000 instituies e 40000
profissionais membros.
2.4
Os Livros da ITIL V3 e as suas Disciplinas
So descritas nesta Seo todas as 26 disciplinas (processos) da terceira verso da ITIL. Em

geral, o prprio nome do processo j revela o seu principal objetivo. Por conta disso, as descries dos processos so breves e objetivas.
Como j foi comentado na Seo anterior, praticamente todas as disciplinas e conceitos foram
pouco alterados ao longo das 3 verses existentes at ento. Em geral, as definies e prticas
sugeridas nos processos da ITIL v2 esto alinhadas respectivamente com as novas publicaes
na verso 3. Por conta disso, todas a abordagens a partir deste ponto so feitas em relao
viso organizacional da ITIL V3.
A Figura 2.3 resume em formato grfico os relacionamentos entre as 5 fases (livros) do ciclo de
vida de servio de TI. Como se pode perceber tambm nessa figura, a ITIL V3 traz alm dos 5
livros outras publicaes e servios de suporte na web.
21
Figura 2.3: resumo grfico dos livros da ITIL V3.

Figura retirada do documento
itSMF_ITILV3_Intro_Overview.pdf, disponvel em http://www.itsmfi.org.
22

A Figura 2.4 tambm ajuda muito no entendimento da estrutura da ITIL V3. Nela pode-se
visualizar como so as interaes entre as fases do ciclo de vida de servio de TI e o prprio
negcio. Em resumo, possvel identificar o seguinte fluxo a partir desse diagrama.
Figura 2.4: relacionamento entre as fases do ciclo de vida de servio e o prprio negcio. Figura retirada do documento itSMF_ITILV3_Intro_Overview.pdf, disponvel em http:
//www.itsmfi.org.
O ciclo de vida inicia a partir de requisies do negcio. Essas requisies so identificadas
e acordadas durante a fase de Service Strategy no chamado Service Level Package (SLP). O
SLP passado como entrada da prxima fase do ciclo (Service Design), onde as solues de
servios e o Service Design Package (SDP) so desenvolvidos. O SDP por sua vez entregue
fase de Service Transition. Nesse ponto o servio avaliado, testado e validado. O Service
Knowledge Management System (SKMS) atualizado e o servio transferido para o ambiente de produo, quando inicia ento a fase de Service Operation. Sempre que possvel, em
qualquer uma das fases do ciclo, a Continual Service Improvement identifica oportunidades
de melhorias dos pontos fracos ou de falha.
2.4.1
Service Strategy (Estratgia de Servio)
O Volume Service Strategy fornece orientaes sobre como projetar, desenvolver e implementar a gesto de servios de TI, no apenas como uma capacidade organizacional, mas tambm
como um ativo estratgico da organizao como um todo. So fornecidas orientaes sobre os
23

princpios subjacentes prtica da gesto de servio que so teis para o desenvolvimento de
polticas de gesto de servios, diretrizes e procedimentos em todo o ciclo de vida do servio.
Service Strategy consideravelmente til no contexto da Service Design, Service Transition,
Service Operation, e Continual Service Improvement. Como se trata da primeira fase do ciclo
de vida de servio, as decises tomadas em relao Service Strategy tm consequncias de
longo alcance, incluindo aquelas com efeito retardado.
As organizaes podem utilizar as orientaes da Service Strategy a fim de definir objetivos e
expectativas de desempenho para servir os clientes e o mercado, e tambm para identificar, selecionar e priorizar oportunidades. Service Strategy consiste em garantir que as organizaes
esto em uma posio para lidar com os custos e os riscos associados aos seus portflios de
servios de TI, e esto posicionadas no apenas para a eficcia operacional, mas tambm para
um desempenho distinto.
Em ltima instncia, este volume fomenta a reflexo e a definio de questes da seguinte
natureza:
quais servios devem ser oferecidos?
para quais clientes os servios sero oferecidos?
como se diferenciar em um mercado competitivo?
como criar valor para esses clientes?
como fazer com que eles percebam o valor criado?
como desenvolver planos de negcio para obter capacidades e recursos necessrios aos
servios?
como otimizar a alocao desses recursos?
como medir o desempenho dos servios?
Perceba que a Service Strategy expande de certa forma o mbito da estrutura da ITIL alm da
tradicional platia de profissionais de TI.
Este volume utiliza alguns termos e conceitos especficos. Conhec-los importante.
4 Ps da Estratgia de Servio
perspective (perspectiva): direcionamento e viso estratgica;
position (posio): estratgia de diferenciao;
plan (plano): traduo da estratgia para operao;
pattern (padro): caractersticas essenciais dos servios.
Valor do Servio
Entende-se que o valor do servio composto por:
24

Service Utility (Utilidade do Servio): mede o quo o servio adequado em relao ao
seu propsito;
Service Warranty (Garantia do Servio): mede o quo o servio adequado em relao
ao seu uso (disponibilidade, capacidade, continuidade e segurana).
H 3 Tipos de Provedores de Servio
Tipo 1: interno, atende uma nica unidade do negcio;
Tipo 2: interno, atende vrias unidades do negcio;
Tipo 3: externo, atende vrias organizaes.
H 3 Modelos de Provimento de Servio
managed (gerenciado): totalmente custeado por uma unidade de negcio, que controla
o servio;
shared (compartilhado): custos rateados por vrias unidades;
utility (utilitrio): servios providos (e pagos) sob demanda.
A Service Strategy composta por 4 processos, que so resumidos a seguir.
Strategy Generation (Gerao de Estratgia)
Este processo prov um guia de planejamento estratgico de como elaborar, desenvolver e implementar gerenciamento de servios de TI. Ele um processo conceitual que auxilia as organizaes a promoverem um melhor alinhamento entre as necessidades de negcio e os servios
de TI. Alm disso, a Strategy Generation tambm aborda boas prticas para desenvolvimento
e otimizao dos recursos e capacidades de TI.
Financial Management (Gerenciamento Financeiro)
Financial Management cobre as atividades relacionadas gesto de oramento. Esse gerenciamento possibilita a quantificao, em termos financeiros, dos valores dos servios de TI prestados ao negcio. So quantificados e demonstrados tambm os custos operacionais desses
servios.
Service Portfolio Management (Gerenciamento de Portflio de Servio)
Service Portfolio Management envolve a gesto pr-ativa do investimento em todo o ciclo de
vida do servio, incluindo os servios no conceito, no design e no pipeline de transio. Ele
um processo contnuo que inclui:
definio: garantir oportunidades de negcios, construir e atualizar portflio;
anlise: maximizar valor do portflio, alinhar, priorizar e balancear produo/demanda;
aprovao: finalizar portflio proposto, autorizar servios e recursos;
formalizao: comunicar decises, alocar recursos.
Cabe ressaltar que a proposta de se gerenciar servio como um portflio passou a ser feita na
verso 3 da ITIL. As suas verses anteriores no englobavam esse conceito.
25

Demand Management (Gerenciamento de Demanda)
Sempre que uma demanda mal gerida, os riscos dela resultar em uma prestao de servio
com qualidade inferior passam a ser mais altos. Servios sub-dimensionados quase sempre
so de baixa qualidade. J os servios sobre-dimensionados acarretam em custos elevados.
Por esses motivos o Demand Management considerado um ponto chave do processo de
prestao de servios de TI como um todo.
A ideia central do Demand Management relacionar as demandas dos usurios pelos servios
com os aprovisionamentos de capacidade. Com esse relacionamento, os ajustes necessrios
para uma melhor prestao de servio so mais perceptveis.
Principais Papis e Responsabilidades
Os principais papis e responsabilidades definidos no Volume Estratgia de Servio so:
Business Relationship Manager (BRM): responsvel por estabelecer o relacionamento
entre a rea de TI e o negcio. indicado que este papel seja executado por algum que
tenha pleno conhecimento dos processos e das necessidades do negcio. Em algumas
organizaes ele pode ser conhecido tambm como Account Manager;
Chief Sourcing Officer (CSO): responsvel por estabelecer a estratgia de contratao
de servios terceirizados;
Financial Manager: responsvel por gerenciar o oramento do provedor de servios de
TI;
IT Steering Group (ISG): responsvel por estabelecer a estratgia para os servios de TI.
Geralmente esse grupo inclui membros do negcio e da rea de TI. Outras duas responsabilidades atribudas ao ISG so: alinhar as estratgias do negcio com as da rea de TI e
estabelecer prioridades em relao ao desenvolvimento de novos projetos e programas;
Product Manager (PM): responsvel por desenvolver e gerenciar os servios ao longo
dos seus ciclos de vida;
Service Portfolio Manager: responsvel por definir a estratgia de prestao de servios
de TI em conjunto com o ISG.
2.4.2
Service Design (Desenho de Servio)
O Volume Service Design fornece orientaes para a concepo e o desenvolvimento de servios

de TI. Ele tambm orienta sobre os processos de gesto de servios. Nele so cobertos os princpios de design e os mtodos para a converso de objetivos estratgicos em portflios e bens de
servios.
O mbito do Service Design no se limita a novos servios. Ele inclui tambm as melhorias
necessrias para se aumentar ou manter o valor dos servios de TI percebidos pelos clientes.
Em resumo, ele guia as organizaes sobre como desenvolver capacidades de design para
gesto de servios.
O principal conceito especfico deste volume descrito a seguir.
26

4 Ps do Desenho de Servio
Diz-se que a eficincia do Service Design depende de quatro quesitos. So eles:
people: pessoas e suas habilidades e competncias;
products: produtos tecnolgicos e sistemas de gerenciamento;
processes: processos e os seus papis e responsabilidades;
partners: fabricantes, fornecedores e colaboradores.
O Service Design composto por 7 processos, que so resumidos a seguir.
Service Catalogue Management (Gerenciamento de Catlogo de Servio)
Catlogo de Servio um documento que contm alm da lista dos servios fornecidos, todas as informaes sobre eles, tais como: descrio, nveis de servio, custo, clientes e a pessoa/departamento responsvel pela manuteno. O contedo do Catlogo de Servio varia de
acordo com os requisitos da organizao de TI.
O Service Catalogue Management prov uma fonte centralizada de informaes sobre os servios
de TI providos, garantindo que as reas de negcios possam exibir uma imagem precisa e consistente dos servios de TI disponveis, seus detalhes e status.
O propsito do Service Catalogue Management fornecer uma fonte nica e consistente de informaes sobre todos os servios acordados, e garantir que elas estejam amplamente disponveis
para aqueles que tenham permisso para acess-lo. As informaes-chave dentro do processo
de Service Catalogue Management esto contidas no Service Catalogue.
Uma observao importante que este um dos novos processos da ITIL V3. A segunda
verso j utilizava o termo Catlogo de Servio, mas no havia sugestes de boas prticas para
o seu gerenciamento.
Service Level Management (Gerenciamento de Nvel de Servio)
Nvel de servio se refere qualidade com a qual os servios de TI devem ser entregues aos
usurios. Tais nveis so discutidos e firmados entre o departamento de TI e os seus clientes, o
que d origem aos chamados Acordos de Nvel de Servio (ANSs) ou Service Level Agreement
(SLA). Esses acordos visam garantir:
a confiabilidade do suporte de TI ao negcio;
a qualidade (disponibilidade e desempenho) dos servios prestados;
o custo dos servios prestados;
a viso do gerencimento baseada em processos.
O processo de Gerenciamento do Nvel de Servio se preocupa, como o seu prprio nome
revela, se os ANSs esto sendo de fato cumpridos. O foco deste processo possibilitar pelo
menos a manuteno da qualidade dos servios atravs de um ciclo constante de monitorao,
27

gerao de relatrios, negociaes e novos acordos. Ele estrategicamente focado no negcio,
mantendo o alinhamento entre o negcio e os servios de TI.
importante manter em mente que este processo prov outras sadas tambm importantes.
Trs delas so: Operational Level Agreement (OLA), Service Improvement Plan (SIP) e o Service Quality Plan.
Capacity Management (Gerenciamento de Capacidade)
O Capacity Management visa garantir o atendimento das necessidades futuras do negcio,
estabelecendo sempre um equilbrio entre demandas e custos. Alm disso, ele tambm contempla as necessidades de capacidade dos prprios servios e componentes de TI ao longo dos
seus ciclos de vida.
A principal sada deste processo um documento chamado Capacity Plan (Plano de Capacidade). Nele so especificadas as previses de carga de hardware e de software, de custos e de
outras recomendaes. Os principais modelos para elaborao de um Plano de Capacidade
so os seguintes:
Modelagem por Referncia: modelagem a partir de um modelo vlido pr-existente;
Anlise de Tendncias: projees futuras com base em dados histricos;
Modelagem Analtica: validao de um modelo matemtico com a situao real;
Modelagem por Simulao: utilizao de dados fictcios para dimensionamento de novas aplicaes;
Testes de Laboratrio: testes com dados reais em um ambiente real.
A ITIL prega que utilizar um Capacity Management Information System (CMIS) essencial para o gerenciamento de capacidade. Esse sistema armazena todas as informaes relacionadas a gerenciamento de capacidade. Essas informaes so analisadas por todos os subprocessos para as realizaes dos aprovisionamentos e para as geraes de relatrios, inclusive
o prprio Plano de Capacidade.
Availability Management (Gerenciamento de Disponibilidade)
Dizemos que um servio esta disponvel quando os usurios o recebem dentro das condies
estabelecidas no acordo de nvel de servio (ANS).
O processo de Gerenciamento de Disponibilidade visa garantir que os servios de TI estaro
disponveis sempre que os seus usurios necessitarem deles, de acordo com os nveis de disponibilidade acordados. A ITIL chama a ateno para a importncia desta disciplina principalmente em relao aos servios que suportam o que ela chama de Vital Business Function (VBF),
ou seja, aqueles servios que suportam sistemas que so considerados vitais para o negcio.
O Gerenciamento da Disponibilidade depende de muitas entradas para funcionar corretamente. Entre elas temos:
os requisitos relacionados disponibilidade do negcio;
28

informao relacionada confiabilidade, sustentabilidade, capacidade de recuperao e
oficiosidade dos ICs;
informao de outros processos, incidentes, problemas, ANSs e nveis de servios alcanados.
As sadas do processo geralmente so:
recomendao relacionada infraestrutura de TI para assegurar a resilincia da infraestrutura de TI;
relatrios sobre a disponibilidade dos servios;
procedimentos para assegurar a disponibilidade e recuperao de cada servio em TI
novo ou aperfeioado;
planos para aperfeioar a disponibilidade dos servios em TI, inclusive o Availability
Plan.
Ao longo das descries das boas prticas em relao a este processo so utilizados vrios
termos inter-relacionados. Os mais relevantes so:
disponibilidade: tempo durante o qual o servio est disponvel;
confiabilidade: capacidade de se manter operacional dentro de um determinado perodo
de tempo;
sustentabilidade: capacidade de retorno ao estado normal aps algum incidente;
resilincia: capacidade de se manter operacional mesmo na falta de um ou mais componentes;
oficiosidade: obrigaes contratuais com terceiros (Contratos de Apoio).
IT Service Continuity Management (Gerenciamento de Continuidade de Servio de TI)
A proposta desta disciplina prover sugestes sobre como as instituies podem manter a capacidade de recuperao de servios de TI em caso de desastre. Isso, claro, levando-se em
conta os requisitos do negcio, como por exemplo a escala de tempo. Afinal, h certos negcios
que exigem recuperaes mais geis e podem pagar por isso.
O IT Service Continuity Management inclui uma srie de recomendaes para manter os
planos de continuidade e de recuperao alinhados s prioridades do negcio e tambm ao
Business Continuity Plan (BCP) (Plano de Continuidade do Negcio). Em geral, essa manuteno
feita por meio de dois exerccios regulares: Business Impact Analysis (BIA) (Anlise de Impacto ao Negcio) e Risk Management (Gerenciamento de Risco).
Information Security Management (Gerenciamento da Segurana da Informao)
O seu objetivo central garantir confidencialidade, integridade, disponibilidade e no-repdio
das informaes, dos dados e dos servios de TI prestados. Geralmente este gerenciamento
segue alinhado s estratgias do gerenciamento da segurana como um todo da organizao.
29

Supplier Management (Gerenciamento de Fornecedor)
O Gerenciamento de Fornecedores, como o nome j sugere, engloba uma srie de recomendaes para a garantia de que todos os contratos sejam respeitados e que todos os fornecimentos necessrios sejam efetivados. Fornecimentos esses que auxiliam na prestao dos servios
de TI organizao.
A ITIL sugere a utilizao de uma Supplier and Contract Database (SCD), que deve conter
todas as informaes a cerca dos fornecedores, seus contratos e os seus servios relacionados.
Os principais papis e responsabilidades definidos no Volume Desenho de Servio so:
Availability Manager: responsvel por analisar, planejar, mensurar, definir e otimizar
todos os aspectos relacionados a disponibilidade dos servios de TI;
Capacity Manager: responsvel por garantir que os servios e a prpria infraestrutura
so adequados para a entrega da capacidade e do desempenho acordados dentro de um
custo efetivo e cronograma especificados;
Security Manager: responsvel por garantir confidencialidade, integridade e disponibilidade dos ativos, informaes, dados e servios de TI;
IT Designer/Architect: responsvel por toda a coordenao e desenho das tecnologias
necessrias, da arquitetura, das estratgias e dos planejamentos;
IT Planner: responsvel pela coordenao e produo dos planos de TI;
IT Service Continuity Manager: responsvel por gerenciar os riscos que podem impactar seriamente os servios de TI. ele quem deve garantir que o provedor de servio
de TI capaz de respeitar os ANSs, mesmo em caso de desastre;
Service Catalogue Manager: responsvel por manter o Catlogo de Servio preciso e
atualizado;
Service Design Manager: responsvel por incluir qualidade, segurana e resilincia no
design dos servios novos e melhorados. Ele deve, inclusive, gerar e manter toda a documentao de design;
Service Level Manager: responsvel por negociar os ANSs e garantir que eles sejam
cumpridos;
Supplier Manager: responsvel por garantir que os fornecimentos contratados sejam
efetivamente obtidos. Ele garante tambm que os contratos com os fornecedores suportem de fato as necessidades do negcio;
Service Owner: responsvel por entregar um servio especfico em conformidade com o
ANS estabelecido.
30
2.4.3
Service Transition (Transio de Servio)
O Volume Service Transition fornece orientaes para o desenvolvimento e a melhoria de

capacidades para transio de novos servios que sero colocados em operao e tambm
servios que j se encontram em operao e que precisam ser alterados. Esta publicao fornece
orientaes sobre como as exigncias da Service Strategy codificadas em Servio Design so
efetivamente realizadas no Service Operation enquanto identifica, gerencia e controla os riscos
de fracasso e ruptura em todas as atividade de transio. A publicao combina, dentre outros
conceitos, prticas de Gerenciamento de Liberao, Programa de Gesto e Gerenciamento de
Riscos, colocando-os no contexto da prtica de gerenciamento de servio.
O volume fornece tambm orientaes sobre como gerenciar a complexidade relacionada a
alteraes de servios e de processos de gesto de servio, evitando indesejveis consequncias, alm de permitir que a inovao ocorra paralelamente.
A Service Transition composta por 7 processos, que so resumidos a seguir.
Transition Planning and Support (Planejamento e Suporte da Transio)
Resumidamente, esta disciplina trata sobre planejamento e coordenao de recursos para garantir que as definio feitas nas fases Service Strategy e Service Desing sejam de fato realizadas
na fase Service Operation com o mnimo de impacto para o negcio. Tudo isso respeitando
os critrios de custo, tempo e qualidade. Este processo se mostra ainda mais importante em
ambientes que exigem alto volume de mudanas e/ou atualizaes.
Este mais um dos novos processos da ITIL. Na verso 2, alguns aspectos relacionados a
este processo eram tratados no processo Release Management. J na verso 3, este assunto
mais bem explorado e descrito por meio de um processo prprio.
Change Management (Gerenciamento de Mudana)
No presente contexto, uma mudana em servio a adio, modificao ou remoo de qualquer servio suportado ou documentao associada. Na prtica, isso quer dizer que qualquer
alterao do ambiente de produo uma mudana. Como exemplo, podemos citar o seguinte:
alterao do nome lgica de um servidor, instalao de atualizao de sistema operacional, atualizao de vacina de anti-vrus, desinstalao de software, etc.
Apesar dos exemplos citados acima serem apenas referentes parte operacional do gerenciamento de servio, cabe ressaltar que o escopo do processo Gerenciamento de Mudana tambm
inclui outros nveis. Ou seja, as mudanas decorrentes de todos os trs nveis de abstrao do
gerenciamento de servio de TI so endereadas nesta disciplina, dando origem s: mudanas
estratgicas, mudanas tticas e mudanas operacionais. A Figura 2.5 sintetiza muito bem esse
relacionamento entre os trs tipos de mudana.
Este processo tem como misso gerenciar todas as mudanas que possam causar impacto na
habilidade da rea de TI em entregar seus servios. Isso feito por meio de um processo
nico e centralizado para aprovao, programao, priorizao, documentao, teste e controle das mudanas. A proposta que esse processo nico assegure que a infraestrutura de TI
permanea alinhada aos requisitos do negcio, com o menor risco possvel.
31
Figura 2.5: escopo do processo Gerenciamento de Mudana. Figura retirada do documento

muito importante manter em mente que este processo no tem como objetivo executar de fato
a implementao das mudanas. As implementaes so realizadas por uma equipe tcnica
responsvel pela rea de mudana, como a rea de redes, sistemas ou hardware. O processo
de Gerenciamento de Mudana controla as mudanas para que elas sejam implementadas de
forma eficiente e eficaz.
Para que se possa fazer uma anlise de riscos adequada, importante o uso de uma Base
de Dados de Gerenciamento da Configurao (BDGC), que fornea uma listagem de todos os
servios e recursos relacionados ao item de configurao que sofrer a mudana.
Cabe ressaltar que a ITIL V3 passou a diferenciar as mudanas em relao as suas abrangncias. Mudanas mais significativas passam a ser submetidas e tratadas de modo especial pelo
processo Evaluation. J as mudanas consideradas pequenas so gerenciadas pelo subprocesso
Minor Change Deployment.
Service Asset and Configuration Management (Gerenciamento de Configurao e Ativo de
Servio de TI)
O foco deste gerenciamento prover ao negcio informaes precisas sobre todos os ativos,
e seus inter-relacionamentos, que compem a infraestrutura de TI da instituio, inclusive os
ativos no TI e de provedores de servios (internos e externos). As prticas sugeridas nesta
disciplina se destinam a identificar, a controlar e a contabilizar todos os ativos de servios e
itens de configurao (ICs), garantindo que todas as informaes permaneam ntegras durante todo o ciclo de vida do servio.
32

A ITIL prega que os valores histricos, planejados e correntes desse tipo de informao sejam mantidos em um sistema de apio chamado Configuration Management System (CMS),
modelo lgico de dados introduzido pela ITIL V3.
Knowledge Management (Gerenciamento de Conhecimento)
Knowledge Management tem como objetivo garantir que a pessoa certa tenha o conhecimento
certo, no momento certo para entregar e suportar os servios requeridos pelo negcio. Um processo de Gerenciamento de Conhecimento adequado minimiza o custo e o tempo necessrios
a qualquer redescoberta de conhecimento.
As prticas elencadas nesta disciplina fornecem meios para o provimento de:
servios mais eficientes e com maior qualidade;
compreenso clara e comum do valor fornecido pelos servios;
informaes relevantes que esto sempre disponveis.
Vrios aspectos relacionados a Gerenciamento de Conhecimento j eram endereados pela
ITIL V2, mas de forma interna a outros processo, como Gerenciamento de Problema, que era
responsvel por manter a chamada Base de Erros Conhecido. Contudo, na verso 3 a ITIL
dedicou um processo especfico para o macro-assunto de gesto de conhecimento.
A principal sada deste processo sem dvida o Service Knowledge Management System
(SKMS), sigla traduzida como Sistema de Gesto do Conhecimento de Servio.
Service Validation and Testing (Validao e Teste de Servio)
Para que o processo de teste seja efetivo, necessrio uma viso holstica dos servios prestados. Todos os servios desenvolvidos interna ou externamente devem ser apropriadamente
testados. necessrio tambm validar se os requerimentos do negcio so respeitados e se
os eventuais riscos so aceitos. O propsito chave do Service Validation and Testing prover
evidncias objetivas relacionadas a esses testes e validaes.
A ITIL defende que este processo vital para a rea de gerenciamento de servios de TI, pois se
um servio no suficientemente testado, a sua introduo no ambiente operacional causar
um aumento no nmero de incidentes, de requisies de suporte, de problemas e de erros. Isso
tudo acarreta em elevao de custo e diminuio do valor dos servios prestados.
Este mais um dos processos introduzidos na ITIL V3.
Release and Deployment Management (Gerenciamento de Liberao e Implantao)
O objetivo deste processo construir, testar e implantar atualizaes do ambiente de produo.
Ao transferir novas verses de servios ou novos servios para a fase Service Operation, este
processo estabelece uso efetivo desses servios pelos seus usurios, o que significa em ltima
anlise entrega de valor real ao cliente. Maior ser esse valor se as atualizaes foram aplicadas
de forma adequada, com o menor tempo de transio, menor risco e menor custo.
Release and Deployment Management responsvel por planejar, programar e controlar os
33

momentos em que as atualizaes devem ser realizadas nos ambientes de teste e de operao.
A sua preocupao primordial garantir que o ambiente de produo permanea integro e
que as atualizaes corretas sejam feitas.
Cabe ressaltar que este processo abrange atualizaes do ambiente de produo tanto no sentido da adio de novos servios quanto da aplicao de novas verses de servios j existentes.
Evaluation (Avaliao)
O propsito do processo Evaluation prover uma forma consistente de clculo de variao de
desempenho em funo de uma possvel efetivao futura de mudana em um servio de TI.
Ou seja, ele apresenta prticas de se medir o quo benfica uma mudana , justamente para
se criticar a sua viabilidade em termos financeiros, de custo e risco.
Este processo tambm enderea tcnicas de avaliao regular dos servios, incluindo (1) a identificao daqueles cujo ANS no est eventualmente sendo mais respeitado e (2) a abordagem
adequada para a manuteno do alinhamento entre os nveis de servios acordados e as necessidades do negcio.
A sada do processo Avaliao de extrema relevncia para o Continual Service Improvement.
Os principais papis e responsabilidades definidos no Volume Transio de Servio so:
Change Advisory Board (CAB): grupo de pessoas responsvel por aconselhar o Change
Manager em relao s estimativas, priorizaes e cronogramas de mudanas;
Change Authority: responsvel por emitir autorizao formal para cada mudana;
Change Manager: responsvel por controlar o ciclo de vida de todas as mudanas. ele
quem autoriza as mudanas mais significativas;
Configuration Manager: responsvel por manter todas as informaes sobre ICs necessrias
para a entrega dos servios de TI. Na prtica, ele responsvel por manter o CMS integro
e atualizado;
Emergency Change Advisory Board (ECAB): subgrupo do CAB responsvel por tomar
decises em relao s mudanas emergenciais;
Knowledge Manager: responsvel por garantir que a organizao de TI apta a reunir,
analisar, armazenar e compartilhar conhecimentos e informaes. O seu objetivo maior
maximizar a eficincia deste processo de forma a reduzir os custos associados redescoberta de conhecimento;
Project Manager: responsvel por planejar e coordenar recursos para que as transies
sejam feitas respeitando-se os custos, tempo e qualidade estimados;
Release and Deployment Manager: responsvel por planejar e controlar o momento
em que as atualizaes devem ser testadas e aplicadas no ambiente de produo. A sua
responsabilidade maior em relao a integridade do ambiente de produo;
34

Service Transition Manager: responsvel pelas atividades do dia a dia executadas pelas
equipes envolvidas com o processo Transio de Servio;
Test Manager: responsvel por garantir que os resultados das implementaes das atualizaes atinjam as expectativas. Ele responsvel tambm por verificar se a operao
de TI est apta a suportar novos servios.
2.4.4
Service Operation (Operao de Servio)
Este volume incorpora as prticas de gesto de operaes de servios de TI. Ele inclui orientaes sobre como alcanar a eficcia e a eficincia na entrega e no suporte de servios, de
modo a garantir o cumprimento dos ANSs estabelecidos e tambm a entrega efetiva de valor
ao cliente por meio de uma adequada prestao de servios.
Os objetivos estratgicos so, em ltima anlise, realizados atravs de operaes de servio,
tornando-se, portanto, numa capacidade crtica. Neste processo, so fornecidas orientaes
sobre formas de manter a estabilidade nas operaes de servios, permitindo mudanas no
design, na escala, no mbito e em nveis de servio.
Organizaes so providas com detalhadas orientaes de processos, mtodos e ferramentas
para uso em duas perspectivas de controle: reativa e pr-ativa. J os gestores e os profissionais
so providos com conhecimentos que lhes permitem tomar melhores decises em reas como
a gesto da disponibilidade dos servios, controle de demanda, otimizao da capacidade utilizada, agendamento de operaes e resoluo de problemas.
As orientaes so fornecidas em apoio s operaes por meio de novos modelos e arquiteturas, tais como: servios compartilhados, computao sob demanda, servios web e comrcio
eletrnico utilizando dispositivos mveis.
A Service Operation composta por 5 processos, que so resumidos a seguir.
Event Management (Gerenciamento de Evento)
A ITIL traz a seguinte definio em relao a eventos. Um evento uma mudana de estado
que tem significncia para o gerenciamento de um item de configurao ou servio de TI..
O Gerenciamento de Evento trata do monitoramento, da deteco, da filtragem, da classificao e do tratamento de todos os eventos que ocorrem na infraestrutura de TI como um todo,
de forma a possibilitar uma operao normal dos seus servios. Este processo tambm prov
mecanismos de notificao a cerca dos servios de TI e dos itens de configurao. Notificaes
essas que incluem informaes operacionais, alertas e erros. De uma maneira geral, tais mecanismos so utilizados para a automatizao de diversas atividades relacionadas a operao de
servios de TI.
A ttulo de exemplificao, podemos citar as seguintes causas de evento:
problema de funcionamento que cause ou possa vir a causar incidentes;
necessidade de execuo de tarefas de produo ou manutenes rotineiras;
restabelecimento de servios.
35

importante notar que a pesar do Event Management depender de monitoramento, ele no
se resumi a isso. Isso porque alm de realizar monitoramento, ele tambm realiza gerao dos
prprios eventos.
Incident Management (Gerenciamento de Incidente)
A definio de incidente no contexto da ITIL a seguinte. Um incidente uma interrupo
programada de um servio de TI, ou a reduo na qualidade de um servio de TI. Falha de um
item de configurao que ainda no impactou um servio tambm um incidente.. Alguns
exemplos de incidentes so:
falha de hardware;
erro de software;
rompimento de cabo de rede;
queima de fonte eltrica;
infeco por praga digital.
Os incidentes de uma maneira geral podem ser percebidos por muitos agentes, humanos ou
no. Alguns exemplos so: usurios, equipes de operao e ferramentas de monitoramento.
O processo de Gerenciamento de Incidente tem como misso restaurar a operao normal dos
servios, em face ao surgimento de um incidente, o mais rpido possvel com o mnimo de
interrupo, minimizando os impactos negativos nas reas de negcio. Os seus principais
objetivos so:
resolver os incidentes o mais rpido possvel, restabelecendo o servio normal dentro do
prazo acordado nos ANSs (Acordos de Nvel de Servio);
manter a comunicao dos status dos incidentes com os usurios;
escalonar os incidentes para os grupos de atendimento para que seja cumprido o prazo
de resoluo;
fazer avaliao dos incidentes e suas possveis causas, informando ao processo de Gerenciamento de Problemas.
muito importante perceber que o foco do Gerenciamento de Incidentes no a resoluo
da causa raiz do incidente, e sim a eliminao dos seus efeitos. Em muitos casos a prpria
identificao da causa raiz no trivial, o que demandaria um esforo inicial grande e uma
consequente demora no restabelecimento dos servios.
Este processo como um todo dividido em sete partes principais, que so apresentadas na
Figura 2.6 e descritas a seguir.
1. Deteco do Incidente: todos os incidentes devem ser registrados em termos de sintomas, dados de diagnstico bsico e informaes sobre o item de configurao e servios
afetados. Independente dos mecanismos com que os incidentes so registrados, o service
desk deve receber alertas apropriados e manter controle total;
36
Figura 2.6: ciclo de vida de incidente.

2. Classificao do Incidente: novos incidentes registrados devem ser analisados para se
descobrir a razo do incidente. Incidentes tambm devem ser classificados e nesse
sistema de classificao que se baseiam as aes posteriores de solues;
3. Suporte Inicial: o usurio deve ser provido com os meios para continuar seu trabalho o
mais rpido possvel, sendo necessrio muitas vezes oferecer solues paliativas (workarrounds) para os incidentes;
4. Investigao e Diagnstico: todo o esforo deve ser feito para minimizar o impacto do
incidente no negcio e encontrar uma soluo definitiva para o incidente o mais rpido
possvel;
5. Resoluo e Recuperao: aes no sentido de recuperar os nveis dos servios devem
ser conduzidas. O sistema de gerenciamento de incidentes deve permitir o registro dos
eventos e aes durante as atividades de soluo e recuperao;
6. Concluso do Incidente: o service desk responsvel por conhecer e supervisionar a
resoluo de todos os incidentes que aparecem, qualquer que seja a fonte inicial. Quando
o incidente resolvido, o service desk deve assegurar que o registro do incidente tenha
sido completado e que a resoluo tenha sido aceita pelo cliente;
7. Monitoramento e Comunicao do Incidente: procedimentos devem ser implantados
para garantir que cada incidente individual seja resolvido dentro dos prazos acordados.
A verso 3 da ITIL trouxe um avano significativo ao Gerenciamento de Incidente. Requisies
padro passaram a ser tratadas pelo processo Request Fulfillment, antes inexistente. Por exemplo, na verso 2, uma simples solicitao de trota de senha de usurio era encarada como um
incidente. Na nova verso esse tipo de ocorrncia tratada como uma requisio de usurio.
Problem Management (Gerenciamento de Problema)
A definio que a ITIL estabelece para problema a seguinte. Um problema a causa de
um ou mais incidentes. A causa no usualmente conhecida no momento da ocorrncia do
problema..
O foco principal deste processo possibilitar a eliminao de erros na infraestrutura de TI,
37

identificando e removendo a causa raiz dos incidentes, evitando assim, recorrncia desses
eventos. Ou seja, o foco em questo encontrar os relacionamentos entre os incidentes e os
problemas causados por eles, e ento resolv-los. Esses dois tipos de elementos (incidentes
e problemas) so chaves para compreender a anlise da causa raiz. Em geral, o princpio
bsico est em comear a anlise com muitas possibilidades e ir estreitando a anlise at a
causa raiz de fato.
Em ltima anlise, pode-se dizer que este processo tem como misso minimizar o nmero
de interrupes nos servios de TI, resultando em nveis mais altos de disponibilidade e produtividade.
Os seus principais objetivos especficos so:
minimizar os efeitos adversos nos negcios;
tratar incidentes e problemas causados por erros na infraestrutura;
prevenir pr-ativamente a ocorrncia dos incidentes, problemas e erros;
reduzir o nmero geral de incidentes de TI.
O processo de Gerenciamento de Problema pode utilizar as seguintes entradas:
registros de incidentes e detalhes sobre os incidentes;
erros conhecidos;
informao sobre os ICs (Itens de Configurao) a partir do BDGC;
informaes de outros processos (exemplo: Gerenciamento do Nvel de Servio prov
informao sobre os tempos a serem cumpridos, o Gerenciamento de Mudanas prov
informao sobre as mudanas recentes que podem ser parte do erro conhecido).
J as suas sadas mais comuns so:
RDMs (Requisies de Mudana) para resolver os erros conhecidos;
informaes gerenciais (relatrios);
erros conhecidos;
atualizaes dos registros de problemas e registros de problemas resolvidos.
Em relao a este processo, a principal adequao em face ITIL V2 foi a criao do subprocesso Major Problem Review, que tem a funo de rever o histrico das solues dos problemas considerados como mais relevantes.
Request Fulfillment (Cumprimento de Requisio)
Neste contexto, uma requisio qualquer contato de usurio feito com objetivo de tratar sobre os servios de TI. Alguns exemplos so: solicitao de informao, solicitao de servio
padro, solicitao de acesso, reclamao e sugesto.
O propsito do processo Cumprimento de Requisio o de permitir aos usurios solicitar
38

e receber servios j considerados padro. J sob a tica do departamento de TI, o foco deste
processo nortear a prestao de informaes aos usurios e clientes sobre os servios e sobre
os procedimentos para obt-los. Alm, claro, de tratar sobre como lidar com informaes
gerais, reclamaes e comentrios.
Esta disciplina prope como boa prtica que todos os pedidos devem ser adequadamente registrados e monitorados. Defende tambm que o processo deve incluir aprovao adequada
antes do cumprimento da requisio.
Como j foi comentado, este processo uma novidade na ITIL V3. A principal motivao para
a criao de um processo dedicado ao Cumprimento de Requisio foi deixar transparente a
distino entre as boas prticas de tratamento e incidentes e requisies.
Access Management (Gerenciamento de Acesso)
Gerenciamento de Acesso consiste basicamente dos processos e dos procedimentos de concesso e revogao de acesso dos usurios aos servios, sistemas, aplicaes, dados e a outros
ativos de TI.
O seu principal objetivo garantir que apenas os usurios autorizados estejam aptos a acessar
e/ou alterar os ativos de TI. Portanto, este processo tambm foca na manuteno da confidencialidade, integridade e disponibilidade dos ativos de TI.
importante perceber que as prticas propostas neste processo so as execues tticas referentes s polticas da instituio relacionadas ao Gerenciamento da Segurana da Informao
e ao Gerenciamento de Disponibilidade.
Este processo outro que foi includo na ITIL a partir da sua verso 3. Em algumas organizaes, esta disciplina tambm conhecida como Rights Management ou Identity Management.
Os principais papis e responsabilidades definidos no Volume Operao de Servio so:
1st Level Support: responsvel por registrar e classificar incidentes. Responsvel tambm por realizar os primeiros esforos para resolver os incidentes. Se necessrio, este
nvel de suporte deve escalar o incidente ao 2nd Level Support. Manter os usurios
informados a respeito dos incidentes tambm uma responsabilidade do 1st Level Support;
2nd Level Support: responsvel por tratar os incidentes repassados pelo 1st Level Support. Se necessrio, ele deve escalar novamente o incidente ao 3rd Level Support;
3rd Level Support: responsvel por tratar os incidentes repassados pelo 2nd Level Support. Em geral, neste nvel as equipes so formadas por fornecedor de hardware ou
software;
Access Manager: responsvel por conceder acessos aos usurios autorizados e por revogar
acessos aos usurios no-autorizados;
39

Facilities Manager: responsvel por gerenciar o ambiente fsico (edifcio, complexo, etc.)
onde a infraestrutura de TI est instalada;
Incident Manager: responsvel pela implementao efetiva do processo de Gerenciamento de Incidente. Ele representa o primeiro estgio de escalao (repasse para equipes
mais especializadas) de incidentes;
IT Operations Manager: responsvel por todas as atividades executadas pela equipe de
operao;
IT Operator: responsvel por executar as atividades de operao do dia a dia, que inclui
configurao e verificao de cpias de segurana, configurao e verificao de tarefas
agendadas, instalao e desinstalao de hardware, etc.;
Major Incident Team: responsvel por concentrar e resolver os incidentes considerados
mais importantes. Usualmente este time formado por tcnicos especialistas e liderado
pelo Incident Manager;
Problem Manager: responsvel por gerenciar o ciclo de vida de todos os problemas. O
seu principal objetivo prevenir o acontecimento de incidentes e minimizar o impacto
dos incidentes que no podem ser prevenidos. sua responsabilidade tambm manter
as informaes sobre erros conhecidos e workarounds;
Service Desk Manager: responsvel por gerenciar a Service Desk;
Service Desk Supervisor: responsvel por auxiliar o Service Desk Manager;
Service Request Fulfilment Group: responsvel por atender requisies especializadas.
Tipicamente, as requisies simples so atendidas pelo 1st Level Support (Gerenciamento de Incidente).
2.4.5
Continual Service Improvement (Melhoria Contnua de Servio)
Este volume fornece orientaes sobre a criao e a manuteno de valor para os clientes por
meio de um melhor design, deployment e operao dos servios de TI. Ele combina os princpios, as prticas e os mtodos de gesto de qualidade, gesto de mudanas e melhoria de
capacidade.
O seu principal foco identificar e garantir que melhorias continuas sejam aplicadas aos
servios, infraestrutura e ao processo de gesto de servios de TI como um todo. A preocupao com os servios se d em qualquer uma das suas fases do ciclo de vida. Este processo
tambm enderea prticas de medio, verificao e gerao de relatrios que comprovem se
as melhorias aplicadas foram adequadas e efetivas.
A Continual Service Improvement composta por 3 processos, que so resumidos a seguir.
The 7 Improvement Process (Processo de Melhoria em 7 Etapas)
De uma maneira geral, este processo levanta questes sobre o que medir e onde encontrar as
informaes a serem medidas de forma a possibilitar implementaes de aes corretivas e
evolutivas.
40

Como o seu nome j sugere, este processo cclico em torno de sete etapas. Esse ciclo de
certa forma bastante similar ao to famoso ciclo PDCA (Plan, Do, Check and Act). Cada uma
dessas 7 etapas executada com estratgias tticas e operacionais definidas nas fases Service
Strategy e Service Design.
A qualidade em si o foco deste processo. Na prtica, a nfase dada na identificao de
onde melhorias podem ser feitas. Isso tipicamente detectado por meio de excees e suas
resolues. Contudo, este processo no se limita a esse tipo de deteco. Ele tambm se interessa em detectar se o nvel de eficincia do servio pode ser mantido com menor custo ou se o
nvel de eficincia requerido deve ser elevado.
A Figura 2.7 ilustra o fluxo proposto pelo Processo de Melhoria em 7 Etapas.
Figura 2.7: ilustrao do Processo de Melhoria em 7 Etapas. Figura retirada do documento

A seguir, cada etapa deste processo resumida:
Passo 1 - Define what you should measure
Um conjunto de medidas que representam os objetivos da organizao deve ser definido. O
foco deve ser identificar o que preciso para satisfazer as necessidades da organizao, sem
considerar onde as informaes esto disponveis.
Passo 2 - Define what you can measure
Geralmente algumas da medidas pretendidas no podem ser feitas em decorrncia de limi41

taes da organizao. Essas situaes devem ser devidamente registradas, inclusive os seus
riscos associados que podem se concretizar e, ento, afetar os resultados entregues aos clientes.
Um relatrio sobre as medidas que no podem ser feitas e as suas implicaes pode ser gerado
e encaminhado ao negcio e ao prprio gerente de TI. Novas ferramentas ou adaptaes das
existentes podem ser cogitadas no futuro.
Passo 3 - Gather the data
Este passo cobre as atividades de monitoramento e coleta de informaes. Geralmente uma
mistura de ferramentas de monitorao e processos manuais deve ser utilizada para a execuo de fato das medies definidas.
Passo 4 - Process the data
Neste passo as informaes so processadas e formatadas de acordo com o planejado. Tipicamente a proposta promover uma perspectiva geral e em alto nvel da eficincia dos servios
e seus processos.
Passo 5 - Analyze the data
A ideia deste passo transformar a anlise das informaes em conhecimento sobre quais
eventos afetam a organizao. Em geral, aps este passo possvel e interessante refletir sobre
questes do seguinte tipo:
os alvos estabelecidos esto sendo atingidos?
h alguma clara tendncia nos resultados das anlises?
aes corretivas so necessrias? Qual so os custos envolvidos?
Passo 6 - Present and use the Information
O conhecimento obtido no passo anterior pode ser apresentado. Sugere-se que tal apresentao seja feita em um formato que facilite o entendimento e que permita tomadas de decises
estratgicas, tticas e operacionais.
Passo 7 - Implement corrective action
Novamente utilizado o conhecimento j obtido, dessa vez para otimizar os processos e todas
as atividades envolvidas, alm da prpria infraestrutura tecnolgica.
Em geral, diversas oportunidades de melhorias so identificadas. Este processo prega que
as prioridades, os objetivos e os recursos a serem aplicados devem ser estabelecidos pela rea
do negcio.
Service Measurement (Mensurao de Servio)
So quatro as razes bsicas para se monitorar e medir servios de TI:
validar decises que tenham sido tomadas;
42

direcionar atividades para o alcance de metas;
fornecer evidncias que justifiquem aes;
sinalizar a necessidade de aes corretivas.
Monitorar e medir so consideradas atividades essenciais para a Melhoria Contnua de Servio.
Muitas organizaes realizam medies apenas em nvel de componentes. Essas medies so
necessrias, mas no so suficientes. A Mensurao de Servio deve ser aplicada tambm em
nveis mais altos, de forma a propiciar uma viso mais fiel ao ponto de vista dos usurios e
clientes em relao aos servios de TI entregues.
De acordo com este processo, para uma organizao alcanar plenamente os seus objetivos,
ela precisa coletar trs tipos de mtricas:
mtrica de tecnologia: performance, disponibilidade, etc.;
mtricas de processos: Critical Success Factors (CSFs), Key Performance Indicators
(KPI), etc.;
mtricas de servios: mtricas de componentes e de tecnologia.
Service Reporting (Relatrio de Servio)
Este processo apresenta prticas sobre como os relatrios de servio devem ser gerados. Ele
defende que esses relatrios devem abordar aspectos alm dos necessrios para retratar se
os ANSs esto sendo cumpridos. Eles devem mostrar comportamentos passados, tendncias,
solues relacionadas, impactos envolvidos e esforos aplicados.
Sabe-se que qualquer rea de TI gera uma quantidade grande de informaes sobre os servios
que ela presta. O Service Reporting enfatiza que apenas parte dessas informaes so importantes para as reas do negcio. Ento, ele apresenta as possveis abordagens que podem ser
utilizadas nas preparaes dos relatrios sobre os servios de TI.
Os principais papis e responsabilidades definidos no Volume Melhoria Contnua de Servio
so:
CSI Manager: responsvel por todas as atividades do processo Melhoria Contnua de
Servio;
Service Manager: responsvel por desenvolver, implementar, avaliar e gerenciar novos
e j existentes produtos e servios.
2.5
Referncias entre Processos e Publicaes
A Figura 2.8 apresenta uma viso alto nvel sobre em quais publicaes cada processo da ITIL
V3 explorado. Essa viso engloba todos os 26 processos em ordem alfabtica. As siglas que
aparecem nessa figura dizem respeito aos estgios do ciclo de vida de servio de TI: Service
Strategy (SS), Service Design (SD), Service Transition (ST), Service Operation (SO) e Continual
43

Service Improvement (CSI). A coluna 2 (Primary Source) traz em qual publicao o processo
foi inicialmente definido. A coluna 3 (Further Expansion) traz em quais outras publicaes o
processo tem relevncia e, por isso, mais explorado.
Figura 2.8: referncias entre os processos e publicaes da ITIL V3. Figura retirada do documento itSMF_ITILV3_Intro_Overview.pdf, disponvel em http://www.itsmfi.org.
44
2.6
Exames e Qualificaes
No incio deste Captulo, foi frisado que ITIL um conjunto de boas prticas e que, justamente
por isso, ela no estabelece nenhuma relao mnima de requisitos para qualquer tipo de certificao. Muito embora o foco da ITIL no seja certificar organizaes, ela define uma srie
de cursos e exames de qualificao oficiais para os profissionais de TI. Esta Seo descreve de
forma sucinta o esquema de qualificao adotado pela ITIL V3.
importante ter em mente que esse esquema de qualificao dinmico. Informaes especficas e atualizadas podem ser buscadas no prprio website oficial da ITIL (http://www.
itil-officialsite.com).
O atual sistema de qualificao ITIL dividido em 4 nveis: ITIL Foundation, ITIL Intermediate Level, ITIL Expert Level e ITIL Master Qualification. Ao analisar a Figura 2.9, possvel
perceber que boa parte do sistema de qualificao segue a mesma estrutura modular da ITIL
V3. Essa abordagem favorece aos candidatos flexibilidade e foco gradual nas vrias disciplinas
da ITIL.
O esquema funciona no sistema de crditos, onde cada mdulo corresponde a certa quantidade de crditos. Praticamente todas as qualificaes relacionadas a outros frameworks ou
padres que tratam de gerenciamento de servio de TI tambm so reconhecidos no esquema
de qualificao da ITIL. Na prpria Figura 2.9 esto indicados quantos pontos so associados
a qual mdulo ou certificao.
45
Figura 2.9: esquema de qualificao da ITIL V3.

itil-officialsite.com.
Figura retirada de http://www.
46

A seguir, cada nvel do sistema de qualificao brevemente descrito.
ITIL Foundation
Este o primeiro nvel de certificao que um profissional de TI pode obter em relao ITIL
V3. Durante 3 dias de curso oficial, o foco apresentar os conceitos, a terminologia e os processos da ITIL V3. Ao final, h um exame com 40 questes de mltipla escolha que deve ser feito
em at 1 hora. Os candidatos aprovados ganham a certificao e mais 2 crditos que podem
ser utilizados como pr-requisitos para os demais nveis.
ITIL Intermediate Level
Cada mdulo do nvel intermedirio representa crditos. Ao completar um mdulo, o profissional passa por um exame e se aprovado ele qualificado. Essas qualificaes so de fato
reconhecidas pelo mercado de TI.
Os mdulos relacionados ao ciclo de vida de servio de TI representam 3 crditos cada. So
eles:
Service Strategy (SS)
Service Design (SD)
Service Transition (ST)
Service Operation (SO)
Continual Service Improvement (CSI)
J os relacionados a capacidade representam 4 crditos cada. So eles:
Operational Support & Analysis (OSA)
Planning, Protection & Optimization (PPO)
Release, Control & Validation (RCV)
Service Offerings & Agreements (SOA)
Os candidatos que j tm a certificao de primeiro nvel (ITIL Foundation ou uma qualificao
Bridge equivalente) podem obter a quantidade de mdulos intermedirios que julgar interessante para a sua atividade. A ordem de qualificao entre esses mdulos tambm flexvel.
Quando um candidato acumula no mnimo 17 crditos, ele passa a ter direito de se inscrever
no curso e posterior exame para a qualificao intitulada de ITIL Managing Across the Lifecycle, que se obtida gera 5 crditos adicionais. Esse o ltimo mdulo de certificao do nvel
intermedirio e particularmente interessante aos candidatos que pretendem obter a qualificao ITIL Expert Level.
ITIL Expert Level
Ter sido aprovado na qualificao ITIL Managing Across the Lifecycle um pr-requisito chave
47

para os interessados em obter certificaes de mais alto nvel. Isso porque so requeridos 22
crditos para um profissional ser considerado um Expert.
ITIL Master Qualification
Candidatos a este nvel de qualificao devem ter passado necessariamente pelo nvel anterior, ou seja, terem o certificado de ITIL Expert. Alm disso, o candidato deve ter trabalhado
como lder, gerente, ou algo do gnero por pelo menos 5 anos na rea de gerenciamento de
servio de TI.
Em resumo, para obter este certificado, o candidato deve estar apto a explicar e justificar como
ele seleciona e aplica uma srie de conhecimentos, princpios, mtodos e tcnicas sugeridas
pela ITIL para atingir os resultados esperados pelo negcio em uma misso real especfica.
Na realidade, diferentemente dos nveis de certificao anterior, no h um curso padro para
a certificao em ITIL Master Qualification. Isso se deve ao fato tambm deste nvel ser relativamente novo. Com isso, o prprio processo de certificao em si ainda no est concludo.
Contudo, j se sabe que o candidato dever selecionar uma rea especfica da ITIL do seu
interesse. Em seguida, ele dever submeter uma proposta a uma entidade certificadora, descrevendo a situao real que ele pretende enderear e quais elementos da ITIL ele ir utilizar.
O exame em si ser customizado em relao proposta do candidato.
2.7
Os Principais Conceitos e Ferramentas da ITIL V3
Ao longo deste Captulo vrias ferramentas e conceitos foram apresentados. Nesta Seo eles
so agrupados e descritos em ordem alfabtica.
A proposta aqui termos uma breve definio das principais ferramentas e conceitos relacionados ITIL. No a inteno deste material cobrir absolutamente todos os conceitos, termos e ferramentas.
Grande parte das definies trazidas nesta Seo so tradues oficiais das prprias publicaes da ITIL V3. Outra parte so tradues livres das publicaes oficiais.
Application Portfolio - Portflio de Aplicativo
Um banco de dados ou documento estruturado usado para gerenciar os aplicativos durante
os seus ciclos de vida. O portflio de aplicativos contm os atributos principais de todos os
aplicativos. O portflio de aplicativo algumas vezes implementado como parte do portflio
de servio ou como parte do Sistema de Gerenciamento de Configurao (SGC).
Availability Plan - Plano de Disponibilidade
Plano que garante que os requisitos de disponibilidade existentes e futuros de servios de
TI possam ser fornecidos com boa relao custo-benefcio.
Baseline - Linha de Base
Refere-se a um instantneo, momento ou retrato que usado como um ponto de referncia.
48

Muitos instantneos podem ser feitos e registrados ao longo do tempo, porm apenas alguns
sero usados como linhas de base.
Por exemplo:
uma linha de base do GSTI pode ser usada como ponto de partida para medir o efeito de
um plano de melhoria do servio;
uma linha de base de desempenho pode ser usada para medir mudanas no desempenho
durante todo o perodo em que um servio de TI estiver na ativa;
uma linha de base de configurao pode ser usada como um plano de retorno para permitir que a infraestrutura de TI seja restaurada para uma configurao conhecida se uma
mudana ou liberao falhar.
Benchmark - Referncia
Uma linha de base que usada para comparar conjuntos de dados relacionados como parte de
um exerccio de comparao contnua. Por exemplo, um instantneo recente de um processo
pode ser comparado a uma linha de base prvia desse processo ou uma linha de base atual
pode ser comparada aos dados do setor ou melhor prtica.
Brainstorming - Tempestade de Ideias
Uma tcnica que ajuda uma equipe a gerar ideias. As ideias no so revisadas durante as
sesses de tempestade de ideias, mas num estgio posterior. A tempestade de ideias frequentemente usada pelo gerenciamento de problema para identificar causas possveis.
Business Continuity Management (BCM) - Gerenciamento de Continuidade de Negcio
(GCN)
o processo de negcio responsvel pelo gerenciamento de riscos que podem impactar seriamente o negcio. O gerenciamento de continuidade de negcio protege as convenincias das
principais partes interessadas, reputao, marca e atividades de criao de valor. O processo
envolve a reduo de riscos a um nvel aceitvel e planejamento para a recuperao de processos de negcio caso ocorra uma interrupo ao negcio. O gerenciamento de continuidade de
negcio define objetivos, escopo e requisitos para o gerenciamento de continuidade de servio
de TI.
Business Continuity Plan (BCP) - Plano de Continuidade do Negcio (PCN)
Um plano que define as etapas necessrias para recuperar os processos de negcio logo aps
uma interrupo. O plano tambm identifica os gatilhos para invocao, as pessoas a serem
envolvidas, comunicaes, etc. Os planos de continuidade de servio de TI formam uma parte
significante dos planos de continuidade de negcio.
Business Continuity Strategy - Estratgia de Continuidade do Negcio
Trata-se de um documento com as linhas gerais sobre qual abordagem utilizar para garantir a continuidade das funes vitais do negcio em caso de eventos de desastre. A Estratgia
49

de Continuidade do Negcio preparada pelo negcio e serve com um ponto de partida para
a elaborao do IT Service Continuity Strategy (Estratgia de Continuidade do Servios de TI).
Business Impact Analysis (BIA) - Anlise de Impacto no Negcio (AIN)
A anlise de impacto no negcio a atividade no gerenciamento de continuidade de negcio
que identifica funes de negcio vitais e as suas dependncias. Essas dependncias podem
incluir fornecedores, pessoas, outros processos de negcio, servios de TI, etc. A anlise de
impacto no negcio define os requisitos de recuperao para servios de TI. Estes requisitos
incluem objetivos de tempo de recuperao, objetivos de ponto de recuperao e as metas de
nvel de servio mnimas para cada servio de TI.
Business Relationship Manager (BRM) - Gerente de Relacionamento de Negcio (GRN)
Um papel responsvel por manter o relacionamento com um ou mais clientes. Este papel
frequentemente combinado com o papel do gerente de nvel de servio.
Call Center - Central de Atendimento
Uma organizao ou unidade de negcio que recebe ou faz grandes volumes de ligaes telefnicas.
Capacity Management Information System (CMIS) - Sistema de Informao de Gerenciamento de Capacidade (SIGC)
Um conjunto de ferramentas, dados e informaes que usado para dar suporte ao gerenciamento de capacidade.
Capacity Plan - Plano de Capacidade
O plano de capacidade utilizado para gerenciar os recursos requeridos para a entrega dos
servios de TI. Esse plano contm cenrios para as diferentes previses de demanda do negcio.
Nele so especificadas as previses de carga de hardware e de software, de custos e de outras
recomendaes. Os principais modelos para elaborao de um plano de capacidade so os
seguintes:
Modelagem por Referncia: modelagem a partir de um modelo vlido pr-existente;
Anlise de Tendncias: projees futuras com base em dados histricos;
Modelagem Analtica: validao de um modelo matemtico com a situao real;
Modelagem por Simulao: utilizao de dados fictcios para dimensionamento de novas aplicaes;
Testes de Laboratrio: testes como dados reais em um ambiente real.
50

Change Advisory Board (CAB) - Comit Consultivo de Mudana (CCM)
Um grupo de pessoas que suportam a avaliao, priorizao, autorizao e programao de
mudanas. Um comit consultivo de mudana normalmente composto de representantes de
todas as reas do provedor de servio de TI, do negcio e de terceiros, tais como fornecedores.
Change Model - Modelo de Mudana
Uma forma repetitvel de lidar com uma categoria de mudana especfica. Um modelo de
mudana define etapas predefinidas que sero seguidas para uma mudana dessa categoria.
Os modelos de mudana podem ser muito complexos, com vrias etapas que requerem autorizao (por exemplo, uma importante liberao de software) ou podem ser bem simples, sem
necessidade de autorizao (por exemplo, uma mudana de senha).
Change Proposal - Proposta de Mudana
um documento que inclui uma descrio de alto nvel de uma potencial introduo de
servio ou mudana significativa, junto com um caso de negcio correspondente e um cronograma da implementao esperada. As propostas de mudana so normalmente criadas pelo
processo de gerenciamento de portflio de servio e so passadas para o gerenciamento de
mudana para autorizao. O gerenciamento de mudana analisa o impacto potencial em outros servios, em recursos compartilhados e no cronograma geral de mudana. Depois que a
proposta de mudana autorizada, o gerenciamento de portflio de servio contrata o servio.
Change Record - Registro de Mudana
Registro que contm informaes detalhadas de uma determinada mudana. Cada registro
de mudana documenta o ciclo de vida de apenas uma mudana. Ele criado por cada requisio de mudana (Request for Change) recebida, mesmo que ele seja rejeitado em seguida.
Os registros de mudana devem fazer referncias aos itens de configurao (ICs) afetados na
mudana. Todos os registros de mudana so armazenados no Configuration Management
System.
Configuration Item (CI) - Item de Configurao (IC)
Qualquer componente ou outro ativo de servio que precisa ser gerenciado de forma que um
servio de TI possa ser entregue. As informaes sobre cada item de configurao so registradas em um registro de configurao no sistema de gerenciamento de configurao (SGC)
e mantido por todo o seu ciclo de vida pelo gerenciamento de configurao e ativo de servio.
Os itens de configurao esto sob o controle do gerenciamento de mudana. Eles incluem
tipicamente hardware, software, prdios, pessoas e documentos formais, tais como documentao de processos e acordos de nvel de servio (ANSs).
Configuration Management Database (CMDB) - Base de Dados de Gerenciamento da Configurao (BDGC)
uma base de dados que contm os registros de configurao (Configuration Records) ao
longo dos seus ciclos de vida. O BDGC fornece informaes sobre os ICs (itens de configu51

rao) e os relacionamentos do tipo pai/filho entre eles. Essa base pode auxiliar na identificao dos vrios aspectos relacionados aos eventos, incidentes e problemas, como a causa, a
soluo, o roteamento e o possvel impacto ao negcio.
A ttulo de exemplificao, seguem algumas das informaes que podem ser extradas de um
BDGC:
itens de configurao relacionados a um determinado evento, incidente ou problema;
eventos, incidentes e problemas similares anteriores;
mudanas registradas;
problemas abertos.
Configuration Management System (CMS) - Sistema de Gerenciamento de Configurao
(SGC)
Conjunto de ferramentas, dados e informaes que usado para dar suporte ao gerenciamento
de configurao e ativo de servio. O SGC parte de um sistema de gerenciamento de conhecimento de servio (SGCS) e inclui ferramentas para coletar, armazenar, gerenciar, atualizar,
analisar e apresentar dados sobre todos os itens de configurao e os seus relacionamentos.
O SGC tambm pode incluir informaes sobre incidentes, problemas, erros conhecidos, mudanas e liberaes.
O SGC mantido pelo gerenciamento de configurao e ativo de servio e usado por todos os demais processos do gerenciamento de servio de TI.
Um fato relevante que o SGC uma novidade da ITIL V3.
Configuration Record - Registro de Configurao
Um registro contendo os detalhes de um item de configurao. Cada registro de configurao
documenta o ciclo de vida de um nico item de configurao. Os registros de configurao
so armazenados em um banco de dados de gerenciamento de configurao e mantidos como
parte do sistema de gerenciamento de configurao.
Contract Portfolio - Portflio de Contratos
Enquanto o catlogo de servios contm a lista completa dos servios gerenciados pelo provedor de servios, o portflio de contratos traz a lista de todos os contratos de servio que formam uma estrutura de suporte que possibilita a entrega dos servios a um cliente especfico.
Cost Center - Centro de Custo
Uma unidade de negcio ou projeto ao qual os custos sero designados. Um centro de custo
no cobra pelos servios prestados. Um provedor de servio de TI pode operar como um
centro de custo ou centro de lucro.
52

Critical Success Factor (CSF) - Fator Crtico de Sucesso (FCS)
Algo que deve ocorrer para que um servio, processo, plano, projeto ou outra atividade de TI
tenha sucesso. Os principais indicadores de desempenho so usados para medir a obteno de
um fator crtico de sucesso. Por exemplo: um fator crtico de sucesso como proteger servios
de TI quando mudanas so feitas pode ser medido por principais indicadores de desempenho como reduo na percentagem de mudanas que no obtiveram sucesso, reduo
na percentagem de mudanas que causaram incidentes, etc.
Customer Agreement Portfolio - Portflio de Acordo de Cliente
Um banco de dados ou documento estruturado usado para gerenciar contratos ou acordos
de servio entre um provedor de servio de TI e seus clientes. Cada servio de TI entregue a
um cliente convm possuir um contrato ou outro acordo que faz parte do portflio de acordo
de cliente.
Customer Portfolio - Portflio de cliente
Um banco de dados ou documento estruturado usado para registrar todos os clientes de um
provedor de servio de TI. O portflio de cliente a viso do gerente de relacionamento de
negcio dos clientes que recebem servios do provedor de servio de TI.
Definitive Media Library (DML) - Biblioteca de Mdia Definitiva (BMD)
Um ou mais local onde as verses aprovadas e definitivas de todos os ICs do tipo software
so armazenados de forma segura. A DML tambm pode conter ICs relacionados a software
como licenas, documentao, etc. Uma DML uma rea de armazenamento lgico. Todos os
software na DML so controlados pelo Gerenciamento de Mudana e pelo Gerenciamento de
Liberao e Implantao. Apenas verses de software presentes na DML devem ser aceitas em
uma liberao.
Definitive Software Library (DSL) - Biblioteca de Software Definitiva (BSD)
utilizada pelo Gerenciamento de Liberao para fornecer um local de armazenamento fsico
de todos os itens de configurao de software. Os software vm de diversas formas, tais como:
cdigos-fonte, pacotes, bibliotecas e executveis. As diferentes verses do mesmo software
so mantidas na BSD e, por meio de autorizao e controles de qualidade, so usadas para
construo e implementao das liberaes.
Cabe ressaltar que a verso 3 da ITIL abandonou essa biblioteca, passando a utilizar apenas a
Definitive Media Library (DML).
Effectiveness - Eficcia
Uma medida para identificar se os objetivos de um processo, servio ou atividade foram atingidos. Um processo ou atividade eficaz aquele que atinge os seus objetivos acordados.
53

Efficiency - Eficincia
Uma medida para identificar se a quantidade correta de recursos foi usada para a entrega
de um processo, servio ou atividade. Um processo eficiente alcana seus objetivos com a
quantidade mnima necessria de tempo, dinheiro, pessoas ou outros recursos.
Emergency Change - Mudana Emergencial
Uma mudana que deve ser introduzida assim que possvel, por exemplo, para resolver um
incidente grave ou implementar uma correo de segurana. O processo de gerenciamento
de mudana normalmente tem um procedimento especfico para manipulao de mudanas
emergenciais.
Emergency Change Advisory Board (ECAB) - Comit Consultivo de Mudana Emergencial
(CCME)
Um subgrupo do comit consultivo de mudana que toma decises sobre mudanas emergenciais. Os membros podem ser nomeados no momento da convocao da reunio e depende da
natureza da mudana emergencial.
Functional Escalation - Escalada Funcional
Transferncia de um incidente, problema ou mudana para uma equipe tcnica que tenha
maior nvel de especializao e conhecimento tcnico que possa auxiliar na escalada.
Hierarchic Escalation - Escalada Hierrquica
Informar ou envolver nveis gerenciais mais seniores para ajudar em uma escalada.
Information Security Management (ISM) - Gerenciamento de Segurana da Informao
(GSI)
O processo responsvel por garantir que a confidencialidade, integridade e disponibilidade
dos ativos, informaes, dados e servios de TI de uma organizao correspondam s necessidades acordadas do negcio. O gerenciamento de segurana da informao suporta a segurana do negcio e tem um escopo mais amplo que aquele do provedor de servio de TI, e
inclui o tratamento de papel, do acesso predial, chamadas telefnicas, etc., para toda a organizao.
Information Security Policy - Poltica de Segurana da Informao
Refere-se poltica que governa a abordagem da organizao quanto ao gerenciamento de
segurana da informao.
Ishikawa Diagram - Diagrama de Ishikawa
Uma tcnica que ajuda uma equipe a identificar todas as possveis causas de um problema.
Originalmente desenvolvida por Kaoru Ishikawa, o resultado dessa tcnica um diagrama
que se assemelha a uma espinha de peixe.
54

IT Service Continuity Plan - Plano de Continuidade do Servio de TI
um plano que define as etapas necessrias para recuperar um ou mais servios de TI. O
plano tambm identifica os gatilhos para a invocao, as pessoas a serem envolvidas, comunicaes, etc. O plano de continuidade de servio de TI deve ser parte do plano de continuidade
de negcio.
Kano Model - Modelo Kano
Um modelo desenvolvido por Noriaki Kano que usado para compreender as preferncias
do cliente. O modelo Kano considera atributos de um servio de TI agrupados em reas tais
como fatores bsicos, fatores de entusiasmo, fatores de desempenho, etc.
Kepner and Tregoe Analysis - Anlise de Kepner e Tregoe
Uma abordagem estruturada resoluo de problemas. O problema analisado com base
em o qu, onde, quando e extenso. As possveis causas so identificadas, a causa
mais provvel testada e a causa verdadeira verificada.
Known Error Database (KEDB) - Banco de Dados de Erros Conhecidos (BDEC)
uma base de dados que contm registros dos erros conhecidos (Known Error Records). Essa
base de dados criada pelo Gerenciamento de Problema e utilizada tanto pelo Gerenciamento
de Problema quanto pelo Gerenciamento de Incidente. A KEDB parte integrante do Service
Knowledge Management System.
Maintenance Plan - Plano de Manuteno
Trata-se de um plano produzido pelo Gerenciamento de Disponibilidade para definir a frequncia e o escopo da manuteno preventiva para os servios considerados crticos e para
os componentes da infraestrutura sobre o controle do Gerenciamento de Disponibilidade. O
Plano de Manuteno tambm conhecido como Procedimento Operacional Padro (POP).
Management Information System (MIS) - Sistema de Informao de Gerenciamento (SIG)
Um conjunto de ferramentas, dados e informaes que usado para dar suporte a um processo ou funo. Os exemplos incluem o sistema de informao de gerenciamento de disponibilidade e o sistema de informao de gerenciamento de fornecedor e contrato.
Mean Time Between Failures (MTBF) - Tempo Mdio entre Falhas (TMEF)
Uma mtrica para medir e relatar a confiabilidade. O TMEF o tempo mdio em que um
servio de TI ou outro item de configurao consegue realizar a sua funo acordada sem interrupo. medido a partir do momento em que o item de configurao comea a funcionar,
at sua prxima falha.
55

Mean Time Between Service Incidents (MTBSI) - Tempo Mdio entre Incidentes de Servio
(TMEIS)
Uma mtrica usada para medir e relatar a confiabilidade. o tempo mdio desde quando
um sistema ou servio de TI falha at a sua prxima falha. O TMEIS igual ao TMEF mais
TMRS.
Mean Time to Repair (MTTR) - Tempo Mdio para Reparo (TMPR)
O tempo mdio levado para reparar um servio de TI ou outro item de configurao aps
uma falha. O TMPR medido a partir de quando o item de configurao falha at que seja
reparado. O TMPR no inclui o tempo necessrio para recuperar ou restaurar. algumas
vezes usado incorretamente no lugar de tempo mdio para restaurar o servio.
Mean Time to Restore Service (MTRS) - Tempo Mdio para Restaurar Servio (TMRS)
O tempo mdio levado para restaurar um servio de TI ou outro item de configurao aps
uma falha. O TMRS medido a partir do momento em que o item de configurao falha at
quando ele estiver completamente restaurado e executando a sua funcionalidade normal.
Operational Level Agreement (OLA) - Acordo de Nvel Operacional (ANO)
Trata-se de um acordo formal entre um provedor de servios de TI e uma outra parte da mesma
organizao. Esse documento define os servios que sero providos e as responsabilidades de
ambas as partes. Em muitos os casos esses servios no so relacionados a TI.
Vrios servios de TI dependem de outros servios, de TI ou no, que so providos dentro
da prpria organizao. Esses acordos so firmados por meio de OLAs e do suporte aos
ANSs.
Pareto Principle - Princpio de Pareto
Uma tcnica usada para priorizar atividades. O princpio de Pareto diz que 80% do valor
de qualquer atividade so criados com 20% do esforo. O princpio de Pareto tambm usado
no gerenciamento de problema para priorizar as possveis causas de um problema para investigao.
Plan, Do, Check and Act (PDCA) - Planejar, Executar, Verificar e Agir (PEVA)
um ciclo de 4 estgio para gerenciamento de processo atribudo ao Edward Deming. Por
isso, PDCA tambm chamado de Deming Cycle.
Plan: planejar ou revisar processo;
Do: implementar o plano e gerenciar o processo;
Check: mensurar o processo, comparar com os objetivos e gerar relatrios;
Act: planejar e implementar alteraes para melhorar o processo.
56

Post-implementation Review (PIR) - Reviso Ps-implementao (RPI)
Uma reviso que ocorre depois que uma mudana ou projeto foi implementado. Uma RPI
determina se a mudana ou o projeto obteve sucesso e identifica oportunidades de melhoria.
Process Manager - Gerente de Processo
Um papel responsvel pelo gerenciamento operacional de um processo. As responsabilidades
de um gerente de processo incluem o planejamento e coordenao de todas as atividades
necessrias para executar, monitorar e relatar informaes do processo. Pode haver vrios
gerentes de processo para um processo, por exemplo, gerentes de mudana regionais ou gerentes da continuidade do servio de TI para cada centro de dados.
O papel de gerente de processo frequentemente atribudo mesma pessoa que executa o papel de dono de processo, mas os dois papis podem estar separados em organizaes maiores.
Profit Center - Centro de Lucro
Uma unidade de negcio que cobra por servios fornecidos. Um centro de lucro pode ser
criado com o objetivo de ter lucro, recuperar custos ou ser operado com alguma perda. Um
provedor de servio de TI pode operar como um centro de custo ou centro de lucro.
Project Charter - Termo de Abertura de Projeto
Um documento que contm detalhes de um novo servio, uma mudana significativa ou outro
projeto significante. Os termos de abertura so normalmente autorizados pelo gerenciamento
de portflio de servio ou por um escritrio de gerenciamento de projeto. O termo de abertura
tambm usado para descrever a ao de autorizao do trabalho necessrio para concluir a
mudana de servio ou de projeto.
Project Plan - Plano de Projeto
Um Plano de Projeto, tambm conhecido como Service Transition Plan (Plano de Transio
de Servio), documento formal e aprovado que mostra as principais entregas, marcos, atividades e recursos para um projeto de Transio de Servio. Esse plano utilizado como um
guia tanto para o projeto executivo quanto para o controle do projeto.
Project Portfolio - Portflio de Projeto
Um banco de dados ou documento estruturado usado para gerenciar projetos durante todo
o seu ciclo de vida. O portflio de projeto usado para coordenar projetos e garantir que atendam aos seus objetivos de maneira oportuna e com custo eficaz. Em organizaes maiores, o
portflio de projeto normalmente definido e mantido por um escritrio de projeto. O portflio de projeto importante para o gerenciamento de portflio de servio, pois novos servios
e mudanas significativas so normalmente gerenciadas como projetos.
Recovery Plan - Plano de Recuperao
Os Planos de Recuperao so criados pelo Availability and IT Service Continuity Manage57

ment. Esse tipo de plano contm instrues especficas para retornar servios e sistemas ao
seu estado de operao.
Release Policy
Refere-se a uma lista de regras para instalao de atualizaes no ambiente operacional. Este
documento define abordagens diferentes para as atualizaes em funo de emergncia e impacto.
Request for Change (RFC) - Requisio de Mudana (RDM)
Trata-se de um pedido formal para fazer uma mudana. Inclui os detalhes da mudana solicitada e pode ser registrada em papel ou em formato eletrnico. O termo frequentemente
confundido com o registro da mudana ou com a mudana propriamente dita.
Request Model - Modelo de Requisio
Uma forma repetitvel de lidar com uma categoria especfica de requisio de servio. Um
modelo de requisio define etapas especficas acordadas que sero seguidas para uma requisio de servio dessa categoria. Modelos de requisio podem ser muito simples, sem requisito para autorizao (por ex., restaurao de senha) ou podem ser muito complexos, com
vrias etapas que requeiram aprovao (por ex., proviso de um servio de TI existente).
Return on Investment (ROI) - Retorno do Investimento (RDI)
Uma medida do benefcio esperado de um investimento. No sentido mais simples, o lucro lquido de um investimento dividido pelo valor lquido dos ativos investidos.
Root Cause Analysis (RCA) - Anlise de Causa Raiz (ACR)
A atividade que identifica a causa raiz de um incidente ou problema. A anlise de causa raiz
concentra-se normalmente em falhas da infraestrutura de TI.
Security Management Information System (SMIS) - Sistema de Informao do Gerenciamento de Segurana (SGSI)
Um conjunto de ferramentas, dados e informaes que usado para dar suporte ao gerenciamento de segurana da informao. O SGSI parte do sistema de gerenciamento de segurana
da informao.
Service Asset and Configuration Management (SACM) - Gerenciamento de Configurao
e de Ativo de Servio (GCAS)
O processo responsvel por garantir que os ativos requeridos para entregar servios sejam
devidamente controlados e que informaes precisas e confiveis sobre esses ativos estejam
disponveis quando e onde forem necessrias. Essas informaes incluem detalhes sobre como
os ativos foram configurados e os relacionamentos entre os ativos.
58

Service Catalogue - Catlogo de Servio
Catlogo de Servio um documento que contm alm da lista dos servios fornecidos, todas as informaes sobre eles, tais como: descrio, nveis de servio, custo, cliente e a pessoa/departamento responsvel pela manuteno. O contedo do Catlogo de Servio varia de
acordo com os requisitos da organizao de TI.
O Catlogo de Servio a nica parte do Service Portfolio publicada para o cliente. Ele
utilizado para suportar a venda e a entrega dos servios de TI.
Service Charter - Termo de Abertura de Servio
Um documento que contm detalhes de um servio novo ou modificado. Introdues de
novos servios ou de servios com mudanas significativas so documentadas em um termo
de abertura e autorizadas pelo gerenciamento de portflio de servio. Os termos de abertura
de servio so passados para a etapa de ciclo de vida do desenho de servio onde um pacote
de desenho de servio novo ou modificado criado. O termo tambm usado para descrever
o ato de autorizar o trabalho requerido por cada etapa do ciclo de vida do servio com relao
ao servio novo ou alterado.
Service Design Package (SDP) - Pacote de Desenho de Servio (PDS)
Um Service Design Package define todos os aspectos e requisitos relacionados a um servio
de TI ao longo do seu ciclo de vida. Um SDP deve ser produzido sempre que:
um novo servio passar a ser necessrio;
surgir uma alterao significativa em algum servio j existente;
algum servio deixar de existir.
Service Desk - Central de Servios
De uma maneira geral, bastante comum a diviso do departamento de TI em equipes. Dependendo da rea de mercado envolvida, podem existir equipes de desenvolvimento de sistemas,
equipes de desenvolvimento de projetos, equipes de relacionamento com clientes e equipes
de suporte a usurios. Em muitos casos, as equipes de suporte so subdividas em nveis de
atendimentos. Os primeiros nveis so capacitados e treinados a resolverem os incidentes mais
comuns, simples e j conhecidos. Os demais nveis so responsveis por assumir e tratar os
incidentes mais complexos, muitas vezes ainda desconhecidos, e as requisies de servio.
A central de servios, tambm conhecida em ingls como service desk, uma funo dentro da
TI que tem como objetivo receber, registrar e dar incio ao tratamento dos eventos, incidentes
e requisies de servio. Ou seja, a central de servios representa justamente o atendimento de
primeiro nvel do suporte.
As responsabilidades mais comuns atribudas central de servios so:
ponto nico de contato entre o departamento de TI e os usurios, quando o assunto
tratamento de eventos, incidentes e requisies de servio;
59

promover a satisfao dos usurios;
comunicar os usurios sobre as mudanas planejadas;
monitorar o cumprimento dos ANSs;
identificar necessidade de treinamento de usurios;
auxiliar na identificao de problemas;
produzir informaes gerenciais.
Ter uma equipe especfica para a central de servios traz geralmente vantagens para os usurios
(maior agilidade e qualidade) e tambm para o prprio departamento de TI (mais eficincia).
Isso ocorre porque os tcnicos especialistas no so mais interrompidos por chamadas diretas
dos usurios que buscam apoio para resolverem problemas simples e corriqueiros. Por consequncia, eles tm mais tempo disponvel para se dedicarem aos incidentes e problemas mais
complexos.
Service Improvement Plan (SIP) - Plano de Melhoria de Servio (PMS)
um plano formal para implementar melhorias em um processo ou servio de TI.
Service Knowledge Management System (SKMS) - Sistema de Gerenciamento de Conhecimento de Servio (SGCS)
um conjunto de ferramentas e bancos de dados utilizado para gerenciar conhecimento, informaes e dados. O SKMS inclui o sistema de gerenciamento de configurao (SGC), alm
de outros bancos de dados e sistemas de informao. Ele inclui ferramentas para coletar, armazenar, gerenciar, atualizar, analisar e apresentar todos os conhecimentos, informaes e dados que um provedor de servios de TI precisa para gerenciar o ciclo de vida completo os seus
servios.
Service Level Agreement (SLA) - Acordo de Nvel de Servio (ANS)
Um ANS um documento que define nveis de servios acordados entre o cliente e o provedor de servios. Ele descreve o servios, documenta os objetivos dos servios e especifica as
responsabilidades de cada parte. Um ANS pode cobrir vrios servios para vrios clientes distintos.
Um ANS deve ser escrito em uma linguagem que o cliente entenda (clara, concisa e livre de
jarges). Um ANS no deve incluir diagramas de procedimentos detalhados para outros processos ou contedo com informaes tcnicas que o negcio no ir entender.
Service Level Package (SLP) - Pacote de Nvel de Servio (PNS)
Um Service Level Package define o nvel de utilidade e garantia para um pacote de servio.
Ele deve sempre ser elaborado considerando-se as necessidades especficas do negcio.
60

Service Level Report (SLR) - Relatrio de Nvel de Servio (RNS)
O RNS d uma percepo sobre a capacidade do provedor de servio em entregar os servios
com a qualidade acordada com o cliente. Para essa proposta, ele compara os nveis de servio
atuais e acordados, e tambm analisa informaes sobre a utilizao dos servios, sobre a mensurao contnua para otimizao de servios e sobre qualquer evento excepcional.
O RNS um documento que gerado pelo provedor de servio para os seus clientes, em
relao ao gerenciamento de TI e tambm outros processos de gerenciamento de servios. Um
relatrio similar ao RNS criado por fornecedores externos para documentar o desempenho
dos seus servios.
Service Level Requirement (SLR) - Requisitos de Nvel de Servio (RNS)
Este um documento que contm todos os requisitos apontados pelo cliente relacionados aos
servios de TI. Dentre outras definies, so estabelecidos pelo cliente a disponibilidade e o
desempenho requeridos para cada servio. Este documento representa o ponto inicial para se
traar os Acordos de Nvel de Servio (ANSs).
Service Lifecycle - Ciclo de Vida de Servio
Uma abordagem ao gerenciamento de servio de TI que enfatiza a importncia da coordenao e controle atravs de vrias funes, processos e sistemas necessrios para gerenciar o
ciclo de vida completo de servios de TI. A abordagem de ciclo de vida de servio considera a
estratgia, o desenho, a transio, a operao e a melhoria contnua de servios de TI. Tambm
conhecido como ciclo de vida de gerenciamento de servio.
Service Portfolio - Portflio de Servio
o conjunto completo de servios gerenciados por um provedor de servio. O portflio de
servio usado para gerenciar o ciclo de vida inteiro de todos os servios de TI, incluindo trs
categorias:
funil de servio (proposto ou em desenvolvimento);
catlogo de servio (em produo ou disponvel para implantao);
servios obsoletos.
Service Specsheet - Especificao de Servio
A organizao de TI rascunha as especificaes dos servios baseadas nos RNSs. Essa uma
transcrio dos requisitos do cliente de como a organizao de TI ir fornecer os seus servios.
Quais so as necessidades tcnicas? Ele ir mostrar os relacionamentos entre os ANSs, fornecedores e a prpria organizao de TI.
Supplier and Contract Database (SCD) - Base de Dados de Fornecedor e Contrato (BDFC)
uma base de dados ou um documento estruturado utilizado para gerenciar os contratos
de fornecedor ao longo dos seus ciclos de vida. O DBFC contm os atributos chave de todos
61

os contratos com fornecedores e deve fazer parte do Service Knowledge Management System
(SKMS).
Supplier and Contract Management Information System (SCMIS) - Sistema de Informao
de Gerenciamento de Fornecedor e Contrato (SIGFC)
Um conjunto de ferramentas, dados e informaes que usado para dar suporte ao gerenciamento de fornecedor.
Underpinning Contract (UC) - Contrato de Apoio (CA)
Este um tipo de contrato com fornecedor externo envolvido na entrega de servios de TI.
Esse tipo de contrato garante que o fornecimento ser concretizado dentro de um certo tempo
acordado, custo, nvel, etc. Como a organizao de TI repassa os requisitos do negcio aos
fornecedores externos, esse tipo de documento reflete nos nveis de servios definidos nos
ANSs.
Por exemplo, se um ANS apresenta um conserto de uma impressora em 5 dias, ento o CA
com o terceiro dever dar suporte a essa necessidade.
Vital Business Function (VBF) - Funo de Negcio Vital (FNV)
Parte de um processo de negcio que crtico para o sucesso do negcio. A funo de negcio
vital uma considerao importante no gerenciamento de continuidade de negcio, gerenciamento de continuidade de servio de TI e gerenciamento de disponibilidade.
Workaround - Soluo de Contorno
Reduo ou eliminao do impacto de um incidente ou problema para o qual uma resoluo
completa ainda no est disponvel, por exemplo, reiniciando um item de configurao em
falha. Solues de contorno para problemas so documentadas nos registros de erro conhecido. As solues de contorno para incidentes que no possuem um registro de problema
associado so documentadas no registro de incidente.
62
Captulo 3. COBIT 4.1 - Control Objectives for Information and related Technology
Captulo 3
COBIT 4.1 - Control Objectives for

Information and related Technology
3.1
Framework COBIT 4.1
As principais necessidades de Governana de TI (Tecnologia de Informao) dentro de uma

organizao esto pautadas em avaliar o valor de TI (quer dizer, como os gastos em TI agregam
aos processos de negcio da empresa), controlar os riscos envolvidos e controlar as informaes. Com o objetivo de suprir essas necessidades, a Governana de TI integra e institucionaliza prticas para a rea de TI suportar os objetivos do negcio da organizao.
O COBIT (Control Objectives for Information and related Technology - Objetivos de Controle para
informao e Tecnologia relacionada) uma ferramenta ou framework que permite a TI suportar os objetivos de negcio. O COBIT estabelece um conjunto de boas prticas para permitir
a organizao gerenciar e controlar as atividades de TI por meio de processos e objetivos de
controle.
O COBIT prov uma metodologia que assegura que numa organizao:
A rea de TI esteja alinhada com os negcios;
A rea de TI habilite o negcio e maximiza os benefcios;
Os recursos de TI sejam usados responsavelmente;
Os riscos de TI sejam gerenciados apropriadamente.
Alm de assegurar esses pontos, o COBIT prover modelos de maturidade e mtricas que permitem a organizao medir de forma objetiva o seu estgio atual, identificar onde as melhorias
so necessrias e monitorar as melhorias.
O COBIT est posicionado em alto nvel, direcionado por requisitos de negcio, abrange todas
as atividades de TI (planejar, construir, executar e monitorar) e concentra-se no que deve ser
realizado para atingir uma governana efetiva e no como atingir, isto , preocupa-se no que e
no no como.
Devido ao foco em processos, o COBIT mapeia as principais atividades de TI em em 34 processos,os quais esto agrupados em quatro domnios. O COBIT garante que a TI prov as
63
informaes necessrias para suportar os objetivos e os requisitos do negcio, utilizando um
conjunto estruturado de processos e recursos de forma eficiente.
Para atingir uma governana efetiva, os executivos exigem que controles sejam implementados pelos gerentes operacionais. Os objetivos de controle do COBIT esto organizados em
processos, proporcionando uma ligao entre os requisitos de Governana, processos e controles.
O COBIT influencia diferentes nveis de usurio numa organizao:
Alta Direo: para obter valor do investimento de TI, balancear riscos e controlar investimentos em um ambiente de TI s vezes imprevisto;
Executivos de Negcios: para assegurar que a gerncia e o controle dos servios de TI
esto funcionando de modo adequado;
Executivos de TI: para prover os servios de TI para suportar a estratgia de negcios de
maneira controlada e gerenciada;
Auditores: prover recomendaes sobre controles internos para os executivos.
Os benefcios de implementar o COBIT como um modelo de governana de TI so:
Um melhor alinhamento baseado no foco do negcio;
Uma viso clara para os executivos sobre o que TI faz;
Uma clara diviso das responsabilidades baseada na orientao para processos;
Aceitao geral por terceiros e rgos reguladores;
Entendimento compreendido entre todas as partes interessadas, baseado em uma linguagem comum;
Cumprimento dos requisitos do COSO (Committe of Sponsoring Organisations of the Treadway Commissions Internal Control - Integrated Framework) para controle do ambiente de
TI.
O COBIT bastante utilizado por empresas de capital aberto para suprir uma deficincia na
lei Sarbanes-Oxley (SOx), pois esta lei requer a avaliao da infraestrutura e das operaes
de TI e do pessoal envolvido. Porm, esta lei no faz meno sobre quais controles precisam
ser estabelecidos dentro da TI para estar em conformidade com o SOx. Ento, como o COBIT fortemente baseado em controles para os processos TI e um modelo independente de
plataforma e tecnologia, as empresas adotam o COBIT para definir os objetivos de controle da
TI, assim ficando em conformidade com a lei SOx.
Este material foi elaborado tendo como principal referncia o Manual do COBIT 4.1, disponvel
em http://www.isaca.org/Knowledge-Center/cobit/Pages/Downloads.aspx. Tambm foi utilizado o livro Implantando a Governana de TI da Estratgia Gesto dos Processos
e Servios - Aguinaldo Aragon Fernandes e Vladimir Ferraz de Abreu.
3.1.1
Evoluo do COBIT
A Tabela 3.1 mostra a evoluo do COBIT de acordo com as suas verses.

64
Ano
Verso
1996
COBIT 1.0
1998
COBIT 2.0
2000
COBIT 3.0
2002
Lei SOx
2005
COBIT 4.0
2007
COBIT 4.1
Descrio
ISACA (Information Systems Audit and Control Association - www.isaca.org) lana um
conjunto de objetivos de controle para as aplicaes de negcio
Inclui uma ferramenta de suporte implementao e a especificao de alto nvel
Inclui as normas e guias associados a gesto
Lanamento da lei SOx, influenciando diretamente o COBIT
Melhorias dos controles para assegurar a segurana e disponibilidade de ativos de TI na organizao
As principais melhorias em relao verso 4.0
foram nos objetivos de controle
Objetivo Principal
Auditoria
Controle
Gesto
Governana
Governana
Tabela 3.1: apresentao das verses do COBIT de acordo com os respectivos anos de lanamento.
3.1.2
Produtos do COBIT
A Figura 3.1 apresenta no formato de pirmide os produtos do COBIT. Neste diagrama, cada
produto do COBIT est relacionado com perguntas, mostrando onde cada produto oferece suporte.
O produto Board Briefing on IT Governance (2nd Edition) auxilia os executivos a entender o motivos de que a governana importante para a organizao, mostrando as principais questes
e o papel deles em gerenci-las. As Diretrizes de Gerenciamento / Modelo de Maturidade
oferecem suporte na definio de responsabilidades, avaliao de desempenho, benchmark e
deficincias de capacidade. O produto Objetivos de Controle oferece um conjunto de requisitos de alto nvel a serem considerados pelos executivos para controle efetivo de cada Processo
de TI. O produto IT Governance Implementation Guide: Using COBIT and Val IT TM (2nd Edition)
possui um mapa para implementar a governana numa organizao. O produto COBIT Control
Practices: Guidance to Achieve Control Objectives for Successful IT Governance (2nd Edition) explica
os motivos de implementar os controles e como implement-los. O produto IT Assurance Guide:
Using COBIT traz como o COBIT suporta as diversas atividades de avaliao.
65
Figura 3.1: apresentao dos produtos do COBIT. Fonte: ISACA.
3.2
Conceitos Bsicos
Nesta Seo apresentamos os conceitos bsicos utilizados no COBIT, como Objetivos de Negcios, de TI, de Processo, de Atividade, de Controle; os Critrios de Informao; os Recursos; e
o Controle Interno.
3.2.1
Objetivos
No COBIT, existem seguintes tipos de objetivos: de Negcio, de TI, de Processo, de Atividade

e de Controle. Esses objetivos so definidos nas subsees seguintes.
Objetivos de Negcio
Com base no Plano de Negcio, as organizaes definem o seu planejamento estratgico para
os prximos anos baseado em objetivos de negcio. Os objetivos de negcio (Business Goals)
definem os resultados (quantitativo ou qualitativo) que a organizao deseja alcanar de forma
a manter alinhada com a viso do negcio, isto , onde a empresa quer estar no futuro. Para
atingir os objetivos de negcio, todos os nveis da organizao (executivo, gerencial e o operacional) devem estar alinhados com os objetivos. Por exemplo, um objetivo de negcio para um
nvel executivo pode ser Aumentar a satisfao dos clientes em 20% e para o nvel operacional pode ser Estabelecer a continuidade e disponibilidade de servios.
66
Objetivos de TI, de Processo e de Atividade
As organizaes utilizam a TI para suportarem as operaes de negcios e por isso investem
grandes quantias de dinheiro na rea de TI. Ento importante que a rea de TI esteja alinhada
com os Objetivos de Negcio da organizao.
Os objetivos so definidos do nvel estratgico para o nvel operacional, isto , de cima para
baixo, de forma que os Objetivos de Negcio determinem os vrios Objetivos de TI (IT Goals),
tornando a TI alinhada com a estratgia da empresa. Uma vez que esses objetivos esto alinhados, eles precisam ser monitorados para garantir que eles esto sendo atingidos.
Um objetivo de TI atingido atravs de um processo ou da interao de vrios processos.
Ou seja, o objetivo de TI define vrios Objetivos de Processo (Process Goals), que por sua vez,
cada objetivo de processo requer vrias atividades, definindo os Objetivos de Atividade (Acitivity Goals).
A Figura 3.2 fornece um exemplo de relacionamento entre os Objetivos de Negcios, de TI,
de Processos e de Atividade.
Figura 3.2: exemplo de relacionamento de objetivos de negcios, de TI, de processo e de atividade. Fonte: ISACA.
Objetivos de Controle
Para garantir uma governana efetiva na organizao, os executivos exigem que controles sejam implementados pelos gerentes operacionais com base em uma metodologia de controles
definida para cada processo de TI. Desta maneira, para cada processo de TI existem os Objetivos de Controle. Assim, o COBIT proporciona uma clara ligao entre os requisitos de
negcio, processos de TI e controle de TI.
Um objetivo de controle (Control Objective) uma declarao do resultado desejado ou de um
propsito a ser atingido com a implementao de um procedimento de controle em um processo em particular. Procedimentos so definidos como parte de processos e entende-se por
procedimento os passos necessrios para executar uma atividade.
A definio de Objetivos de Controle proporciona um completo conjunto de requisitos de alto
nvel para os executivos, permitindo um controle efetivo de cada processo de TI.
67
3.2.2
Critrios de Informao
Para atender aos Objetivos de Negcio, as informaes precisam estar adequadas a determinados critrios, os quais o COBIT chama de Requisitos de Negcio, ou necessidades de informao ou Critrios de Informao (Information Criteria). Com base em requisitos de qualidade,
segurana e fiducirios (que revela confiana), os Critrios de Informao so:
Efetividade (Effectiveness): a capacidade de alcanar metas e resultados. Trata a informao como sendo relevante e pertinente para o processo de negcio to bem como a
mesma sendo entrega em tempo, correta, consistente e utilizvel;
Eficincia (Efficiency): a capacidade de produzir o mximo com o mnimo de recurso.
Diz respeito proviso da informao atravs do uso otimizado dos recursos, isto ,
entrega da informao utilizando da melhor forma (mais produtivo e econmico) os recursos na organizao;
Confidencialidade (Confidentiality): diz respeito proteo da informao sigilosa contra
acessos no autorizados;
Integridade (Integrity): relaciona a preciso e a perfeio da informao bem como a sua
validade em conformidade com os valores e expectativas do negcio;
Disponibilidade (Availability): relaciona a informao disponibilizada quando solicitada
pelo processo de negcio hoje e no futuro. Diz respeito tambm proteo dos recursos
necessrios e capacidades associadas;
Conformidade (Compliance): trata do cumprimento das leis, dos regulamentos e dos contratos os quais o processo est sujeito, isto , critrio de negcios imposto bem como
polticas internas;
Confiabilidade (Reliability): relaciona-se com a entrega da informao apropriada para os
executivos para administrar a organizao e para exercer suas responsabilidades fiducirias
e de governana.
Os critrios Efetividade e Eficincia esto relacionado aos requisitos de qualidade; Confidencialidade, Integridade e Disponibilidade esto relacionados aos requisitos de segurana; e Conformidade e Confiabilidade esto relacionados aos requisitos fiducirios.
O COBIT relaciona os Objetivos de Negcio com os objetivos de TI e os Critrios de informao para cada processo de TI.
3.2.3
Recursos de TI
A organizao precisa investir nos recursos necessrios a fim de criar capacidades que atendam aos requisitos de negcio para alcanar o retorno desejado.
Os recursos de TI (IT Resources) identificados no COBIT pode ser definido como:
Aplicativos (Applications): sistemas automatizados para usurios e procedimentos manuais que processam a informao;
Informaes (Information): dados em todas as suas formas, a entrada, o processamento e
a sada fornecida pelo sistema de informao em qualquer formato a ser utilizado pelos
negcios;
68
Infraestrutura (instalaes) (Infrastructure): refere-se tecnologia e aos recursos (hardware,
sistemas operacionais, banco de dados, etc..) que possibilitam o processamento de aplicativos;
Pessoas (People): pessoal necessrio para planejar, organizar, adquirir, implementar, entregar, prestar suporte, monitorar e avaliar os sistemas de informao e servios. Eles
podem ser internos, terceirizados ou contratados, de acordo com a necessidade.
Os Recursos de TI utilizando a experincia das pessoas e a infraestrutura tecnolgica e um
conjunto de processos claramente definidos entrega as informaes necessrias para os aplicativos de negcios process-las, aprimorando as informaes de negcios. Esses recursos em
conjunto com os processos constituem a Arquitetura Corporativa de TI.
3.2.4
Crontrole Interno
Conforme a definio no modelo COSO, controle interno Iternal Control um processo desenvolvido para garantir, com razovel certeza, que sejam atingidos os objetivos da organizao,
nas seguintes categorias:
Eficincia e efetividade operacional (objetivos de desempenho ou estratgia) - esta categoria esta relacionada com objetivos bsicos da organizao, inclusive com objetivos e
metas de rentabilidade, bem como da segurana e da qualidade dos ativos;
Confiana nos registros contbeis/financeiros (objetivos de informao) - todas as transaes
devem ser registradas, todos os registros devem refletir transaes reais, registradas pelos valores e enquadramentos corretos;
Conformidade (objetivos de conformidade) - com leis e normas aplicveis entidade e
sua rea de atuao.
O Controle Interno de responsabilidade de toda a organizao e um elemento que compe
o processo de gesto da organizao.
Pelo COSO, o controle interno um processo constitudo por cinco elementos, que esto interrelacionados e presentes em todo o controle interno:
Ambiente de controle - a conscincia de controle da organizao, sua cultura de controle. Ou seja, os funcionrios sabem o que deve ser feito e como fazer;
Avaliao e gerenciamento de riscos - a identificao e anlise dos riscos associados a
no comprimento das metas e objetivos;
Atividade de Controle - so as atividades que quando executadas e tempo de maneira
adequada, permitem a reduo ou administrao dos riscos. As atividades podem ser de
preveno ou deteco;
Informao e Comunicao - esto relacionadas ao fluxo de informao dentro de uma
organizao, em todos os nveis hierrquicos (dos superiores aos inferiores e vice-versa).
Ou seja, as informaes sobre planos, riscos, atividades de controle e desempenho devem
ser transmitidas para toda a organizao e informaes de fontes externas, devem ser
identificadas, capturadas e verificadas;
69
Monitoramento - a avaliao dos controles internos para saber se os controles internos
esto sendo efetivos ou no.
O COSO (e outras metodologias similares) geralmente aceito como uma metodologia de
controle interno para corporaes. O COBIT um modelo de controles internos geralmente
aceitos para a rea de TI.
3.3
Caractersticas do COBIT
Com base nas necessidades de Governana de TI (o valor de TI, controlar riscos e informaes),
o COBIT foi criado para ser focado nos negcios, orientado a processos, baseado em controles
e direcionados a medies.
3.3.1
Foco nos Negcios
Foco nos negcios o principal tema do COBIT, que visa sempre manter os objetivos da TI
alinhados com os objetivos de negcio de uma organizao.
Para manter o foco nos negcios, o modelo COBIT baseado nos seguintes princpios (vide
Figura 3.3): Informao organizacional, Requisitos de Negcio, Recursos de TI e Processos
de TI. Esses princpios fazem com que a organizao invista, gerencie e controle os Recursos
de TI utilizando um conjunto estruturado de Processos de TI de modo a prover servios que
disponibilizam as informaes para organizao. Essas informaes adequadas a determinados Critrios de Informao e aos Objetivos de Negcios e de TI fornecem uma base para o
estabelecimento dos Requisitos de Negcio da organizao e o desenvolvimento de mtricas,
que permitem avaliar se esses objetivos esto sendo atendidos.
Figura 3.3: princpios bsicos do COBIT. Fonte: ISACA.

Alm disso, para garantir o foco nos negcios, o COBIT precisa ser utilizado tanto pelos provedores de servios, usurio e auditores quanto, o mais importante, pelos executivos e donos dos
processos de negcio.
70
Ento, conforme ilustra a Figura 3.4, a estratgia da empresa dever ser traduzida pela rea
de negcios, isto , pelos executivos da organizao em objetivos relacionados s iniciativas
da rea de TI (Objetivos de Negcios para TI), que por sua vez devem levar a uma definio
clara dos prprios objetivos da rea de TI (Objetivos de TI). Com esses objetivos definidos de
forma clara, organizao definir os recursos e capacidades de TI (Arquitetura Corporativa
de TI) necessrias para a rea de TI executar de forma bem sucedida a parte que lhe cabe na
estratgia da empresa. Uma vez os Objetivos de Negcios e de TI alinhados, eles precisam
ser monitorados para garantir que as entregas realizadas pela rea de TI atendam as expectativas da organizao. Isso realizado por mtricas derivadas dos objetivos e capturadas pelo
Scorecard (indicadores) de TI.
Figura 3.4: objetivos e arquitetura corporativa. Fonte: ISACA.
3.3.2
Orientado a Processos
Em uma organizao, as tradicionais reas de responsabilidade de TI so planejamento, construo, processamento e monitoramento. Para mapear essas reas, o COBIT promove a organizao das atividades de TI em torno de processos de TI fornecendo um modelo para as
organizaes adotarem e adaptarem conforme necessrio. Um modelo baseado em processos
incentiva a determinao dos proprietrios, facilitando a definio de responsabilidades.
O COBIT define as atividades de TI em um modelo de processos genricos em quatro domnios:
Planejar e Organizar (Plan and Organise), Adquirir e Implementar (Acquire and Implement),
Entregar e Suportar (Deliver and Support) e Monitorar e Avaliar (Monitor and Evaluate). Dentro desses quatro domnios, o COBIT identifica 34 processos de TI.
71
3.3.3
Baseado em Controles
No nvel operacional, os gerentes utilizam os processos para organizar e gerenciar as atividades de TI. Como o modelo proposto pelo COBIT organiza as atividades de TI em torno de
processos, para se alcanar uma governana efetiva, controles precisam ser implementados
para todos os processos de TI. Desta maneira, consegue uma ligao clara entre os requisitos
de negcio, processos de TI e controle de TI.
3.3.4
Direcionado a Medies
Uma necessidade bsica de toda organizao entender o status dos seus sistemas de TI e
decidir que nvel de gerenciamento e controle deve adotar. As empresas precisam medir onde
elas esto e onde as melhorias so necessrias. Para lidar com essas questes, o COBIT fornece
Modelos de Maturidade; Objetivos de performance e mtricas para os processos de TI; e Objetivos de Atividade.
3.4
Estrutura
Conforme explicamos anteriormente, o modelo do COBIT est pautado no seguinte princpio

bsico: a organizao precisa investir, gerenciar e controlar os Recursos de TI utilizando um
conjunto estruturado de Processos de TI a fim de se atingir os Objetivos de TI, que por sua vez
esto definidos a partir dos Objetivos de Negcio, os quais adequados aos Critrios de Informao estabelecem os Requisitos de Negcio da organizao. Para avaliar se esses objetivos
(negcio e de TI) esto sendo atingidos, so utilizadas as mtricas de Medidas de Resultado e
Indicadores de Performance. A Figura 3.5 ilustra toda essa dinmica de gerenciamento, controle, alinhamento e monitoramento do COBIT.
Figura 3.5: gerenciamento, controle, alinhamento e monitoramento do COBIT. Fonte: ISACA.
72
Com base no princpio bsico, o modelo COBIT est pautado em trs componentes: Processos
de TI, Recursos de TI e Requisitos de Negcio, que formam o cubo do COBIT (vide Figura
3.6). Ou seja, os Recursos de TI esto definidos em Aplicaes, Informaes, Infraestrutura e
Pessoas; os Processos de TI esto divididos em Domnios, que por sua vez esto subdividos
em Processos os quais esto divididos em Atividades; e os Requisitos de Negcios atendem
aos critrios de Efetividade, Eficincia, Confidencialidade, Integridade, Disponibilidade, Conformidade e Confiabilidade.
Figura 3.6: os componentes do COBIT representados em um cubo 3D. Fonte: ISACA.

A Figura 3.7 mostra graficamente como o modelo COBIT est estruturado: um modelo estruturado em 4 Domnios contento 34 Processos genricos, os quais so utilizados na gerncia dos
Recursos de TI para entregarem as informaes necessrias para a rea de negcio conforme
os Requisitos de Negcio e de Governana.
Para sumarizar a nossa discusso a respeito da estrutura do COBIT, apresentamos a Figura 3.8
que mostra o inter-relacionamento entre os componentes do COBIT. Alguns conceitos presente
nessa figura e o como eles se relacionam j discutidos apresentado e outros sero apresentados
nas prximas sees.
73
Figura 3.7: a viso geral do modelo COBIT. Fonte: ISACA.
74
Figura 3.8: inter-relacionamento dos componentes do COBIT. Fonte: ISACA.
75
3.5
Domnios
O COBIT define as atividades de TI em um modelo de processos genricos agrupados em

quatro domnios: Planejar e Organizar (PO), Adquirir e Implementar (AI), Entregar e Suportar (DS), e Monitorar e Avaliar (ME). A Figura 3.9 mostra o inter-relacionamento entre esses
domnios.
Figura 3.9: inter-relacionamento entre os domnios do COBIT. Fonte: ISACA.

O domnio PO prov direo para a entrega de solues (AI) e a entrega de servios (DS); o
domnio AI prov solues e as transfere para tornarem-se servios; o domnio DS recebe as
solues e as tornam passveis de uso pelo usurio final; e o domnio ME monitora todos os
processos para garantir que a direo definida seja seguida.
Dentro desses quatro domnios, o COBIT identifica 34 processos de TI. Para cada um desses 34
processos so feitas relaes entre os Objetivos de Negcio e de TI; so fornecidas informaes
de como os objetivos podem ser medidos; so definidas as atividades chaves e os respectivos
responsveis. Com essa estrutura, as atividades de TI ficam mais fceis de serem controladas
e organizadas.
3.5.1
Planejar e Organizar (PO)
O domnio Planejar e Organizar preocupa-se com a identificao da forma que a TI pode ser
utilizada de maneira a contribuir com os Objetivos de Negcios. Este domnio preocupa-se
com a ttica e a estratgia da organizao, isto , a estratgia precisa ser planejada, comunicada
e gerenciada por diferentes perspectivas utilizando uma infraestrutura tecnolgica adequada.
Este domnio est divido em 10 processos, os quais so:
PO1 - Definir um Planejamento Estratgico de TI (Define a strategic IT plan): criao de
um plano estratgico e de um plano ttico para a TI de forma a manter a TI alinhada com
as prioridades do negcio;
PO2 - Definir a Arquitetura da Informao (Define the information architecture): definio
de uma arquitetura de informao de modo a integrar as aplicaes nos processos de
negcio e fornecer informaes seguras e confiveis;
76
PO3 - Determinar o Direcionamento Tecnolgico (Determine technological direction): elaborao de um plano de infraestrutura tecnolgica para permitir a integrao e padronizao de aplicativos e recursos com uma boa relao de custo benefcio;
PO4 - Definir os Processos, Organizao e os Relacionamentos de TI (Define the IT processes, organisation and relationships): definio de estruturas organizacionais de TI em
uma estrutura de processos de TI com definies claras de papis e de responsabilidade;
PO5 - Gerenciar o Investimento de TI (Manage the IT investment): estabelece e mantm
uma estrutura para gerenciar os investimentos em TI, permitindo uma melhora na relao custo-benefcio da TI e na lucratividade do negcio;
PO6 - Comunicar as Diretrizes e Expectativas da Diretoria (Communicate management aims
and direction): a Direo desenvolve uma estrutura de controles de TI e define, aprova e
comunica polticas por meio de um programa de comunicao contnuo, afim de tornar
as polticas, procedimentos e diretrizes compreensveis em toda a organizao;
PO7 - Gerenciar os Recursos Humanos de TI (Manage IT human resources): definio de
prticas de recrutamento, treinamento, avaliao de desempenho, promoo e desligamento com o objetivo de ter uma fora de trabalho competente e motivada para entregar
os servios de TI para o negcio;
PO8 - Gerenciar a Qualidade (Manage quality): desenvolvimento e manuteno de um sistema de gesto de qualidade que gere requisitos, procedimentos e polticas de qualidade
de forma clara;
PO9 - Avaliar e Gerenciar os Riscos de TI (Assess and manage IT risks): criar e manter uma
estrutura de gesto de riscos na qual exista riscos TI acordados, estratgias de mitigao
e riscos residuais;
PO10 - Gerenciar Projetos (Manage projects): implementar uma estrutura de gesto de
projeto para o gerenciamento dos projetos na rea de TI, assegurando a coordenao e
priorizao dos projetos.
O domnio PO suporta as seguintes dvidas gerenciais:
As estratgias de TI e de negcios esto alinhadas?
A empresa est obtendo um timo uso dos seus recursos?
Todos na organizao entendem os objetivos de TI?
Os riscos de TI so entendidos e esto sendo gerenciados?
A qualidade dos sistemas de TI adequada s necessidades de negcios?
3.5.2
Adquirir e Implementar (AI)
O domnio Adquirir e Implementar preocupa-se em como a TI pode executar as estratgias de

TI definidas pela rea gerencial. Para isso, as solues de TI precisam ser identificadas, desenvolvidas ou adquiridas, implementas e integradas ao processo de negcios. Alm disso, este
domnio cobre as alteraes e manutenes nos sistemas existentes .
77
AI1 - Identificar Solues Automatizadas (Identify automated solutions): este processo
est relacionado a tomadas de decises entre adquirir ou desenvolver uma aplicao
necessria para que os requisitos de negcio sejam alcanados, mas sempre buscando
automatizar as solues;
AI2 - Adquirir e Manter Software Aplicativo (Acquire and maintain application software):
este processo contempla a disponibilizao de aplicaes alinhadas aos requisitos do
negcio;
AI3 - Adquirir e Manter Infraestrutura de Tecnologia (Acquire and maintain technology
infrastructure): as organizaes precisam ter uma abordagem planejada de aquisio,
manuteno e proteo da infraestrutura alinhada s estratgicas tecnolgicas e prover
ambientes de desenvolvimento e teste;
AI4 - Habilitar Operao e Uso (Enable operation and use): documentos e manuais para
usurios e para a TI so elaborados e treinamentos so promovidos para assegurar a
operao e uso apropriado das aplicaes e infraestrutura de TI;
AI5 - Adquirir Recursos de TI (Procure IT resources): este processo requer a definio e
aplicao de procedimentos de aquisio, seleo de fornecedores, estabelecimento de
arranjos contratuais e a aquisio de fato do modo que os recursos de TI sejam adquiridos;
AI6 - Gerenciar Mudanas (Manage changes): as mudanas (manutenes e correes) na
infraestrutura e nas aplicaes no ambiente de produo devem ser registradas, avaliadas e autorizadas antes da implementao, e depois da implementao elas devem ser
revisadas;
AI7 - Instalar e Homologar Solues e Mudanas (Install and accredit solutions and changes):
para um sistema entrar em produo, necessrio realizar testes, definir instrues de
implantao e migrao, planejar a liberao do sistema e revisar aps a implantao.
O domnio AI trata as seguintes questes:
Os novos projetos fornecero solues que atendam s necessidades de negcios?
Os novos projetos sero entregues no tempo e oramento previstos?
Os novos sistemas ocorreram apropriadamente quando implementado?
As alteraes ocorrero sem afetar as operaes de negcios atuais?
3.5.3
Entregar e Suportar (DS)
O domnio Entregar e Suportar trata da entrega dos servios solicitados, o que inclui entrega
de servio, gerenciamento da segurana e continuidade, servios de suporte para os usurios
e o gerenciamento de dados e recursos operacionais.
DS1 - Definir e Gerenciar Nveis de Servios (Define and manage service levels): definido
e documentado um acordo para permitir comunicao eficaz entre a Direo de TI e os
clientes de negcio sobre os servios necessrios de TI e os nveis de servio esperado;
78
DS2 - Gerenciar Servios de Terceiros (Manage third-party services): este processo requer
uma efetiva gesto da terceirizao a fim de assegurar que os servios prestados por
fornecedores esto satisfazendo os requisitos do negcio;
DS3 - Gerenciar Capacidade e Desempenho (Manage performance and capacity): anlise
crticas de desempenho e da capacidade dos atuais recursos de TI so realizadas com
certa frequncia com o objetivo de gerenciar o desempenho e a capacidades desses recursos;
DS4 - Assegurar Continuidade de Servios (Ensure continuous service): este processo visa
prover a continuidade dos servios de TI essenciais para o negcio afim de minimizar o
impacto de uma interrupo de um servio de TI nos processos crticos de negcio;
DS5 - Assegurar a Segurana dos Servios (Ensure systems security): uma gesto de segurana implementada com objetivo de manter a integridade da informao e proteger os
ativos de TI;
DS6 - Identificar e Alocar Custos (Identify and allocate costs): construo e a operao de
um sistema para capturar, alocar e reportar os custos de TI aos usurios dos servios a
fim de que a organizao tome decises mais embasadas sobre o uso dos servios;
DS7 - Educar e Treinar os Usurios (Educate and train users): neste processo definido
e executado uma estratgia eficaz de treinamento e medio de resultados em cima das
necessidades identificadas de treinamento dos usurios finais e da prpria equipe de TI;
DS8 - Gerenciar a Central de Servio e os Incidentes (Manage service desk and incidents):
implantao de uma central de servios para atendimento a dvidas e problemas de
usurios de TI, tratamento de incidentes, registro, encaminhamento, anlise de tendncia, anlise de causa-raiz e resoluo;
DS9 - Gerenciar a Configurao (Manage the configuration): este processo requer o estabelecimento e manuteno de um repositrio de configurao preciso e completo para
assegurar a integridade das configuraes de hardware e software na organizao;
DS10 - Gerenciar os Problemas (Manage problems): este processo requer uma efetiva gesto
de problemas que identifique e classifique o problema, anlise as causas-raiz, prove
solues, identifica a recomendao de melhorias, realiza a manuteno dos registros
de problemas e revisa a situao das aes corretivas;
DS11 - Gerenciar os Dados (Manage data): definio de uma gesto dos dados que identifique os requisitos de dados, estabelea procedimentos efetivos para controlar mdia,
backups, recuperao de dados e dispensa de mdias;
DS12 - Gerenciar o Ambiente Fsico (Manage the physical environment): neste processo
so definidos requisitos do local fsico, instalaes apropriadas, questes acessos fsicos
e monitoramento dos fatores ambientes a fim de prover instalaes fsicas planejadas e
gerenciadas para a proteo de pessoas e dos equipamentos;
DS13 - Gerenciar as Operaes (Manage operations): este processo requer a definio de
polticas e procedimentos de operaes para a gerncia eficaz de processamentos agendados, proteo de resultados sigilosos, monitoramento de infraestrutura e manuteno
preventiva de hardware.
O domnio DS trata as seguintes questes:
79
Os servios de TI esto sendo entregues de acordo com as prioridades de negcios?
Os custos de TI esto otimizados?
A fora de trabalho est habilitada para utilizar os sistemas de TI de maneira produtiva
e segura?
Os aspectos de confidencialidade, integridade e disponibilidade esto sendo contemplados para garantir a segurana da informao
3.5.4
Monitorar e Avaliar (ME)
O domnio Monitorar e Avaliar aborda o gerenciamento de performance, o monitoramento

do controle interno, a aderncia regulatria e a governana como forma de garantir que os
processos de TI esto regularmente sendo avaliados, a qualidade est sendo assegurada e os
requisitos de controle esto aderentes.
ME1 - Monitorar e Avaliar o Desempenho (Monitor and evaluate IT performance): este processo requer a definio e monitoramento de indicadores de desempenho relevantes,
informes de desempenhos e aes para os desvios encontrados;
ME2 - Monitorar e Avaliar os Controles Internos (Monitor and evaluate internal control):
este processo monitora os controles internos de TI e reporta as excees de controle, os
resultados de auto-avaliao e avaliao de terceiros;
ME3 - Assegurar a Conformidade com Requisitos Externos (Ensure compliance with external requirements): este processo requer a identificao e superviso de requisitos de
conformidade com leis, regulamentaes e contratos;
ME4 - Prover a Governana de TI (Provide IT governance): este processo define estruturas organizacionais, processos, lideranas, papis e responsabilidades para assegurar
que investimentos em TI estejam alinhados e sendo entregues em conformidade com as
estratgias e objetivos da organizao.
O domnio ME trata as seguintes questes:
A performance de TI mensurada para detectar problemas antes que seja muito tarde?
O gerenciamento assegura que os controles internos sejam efetivos e eficientes?
O desempenho da TI pode ser associado aos objetivos de negcio?
Existem controles adequados para garantir confidencialidade, integridade e disponibilidade das informaes
3.6
Controles
Controle pode ser definido como polticas, procedimentos, prticas e estruturas organizacionais elaborados para fornecer uma razovel garantia de que os objetivos de negcio de
uma organizao sejam alcanados e eventos indesejveis sejam prevenidos ou detectados e
corrigidos.
80
Um controle efetivo reduz risco, aumenta a probabilidade da entrega de valor e aumenta a
eficincia porque existiro poucos erros e um gerenciamento mais consistente.
O modelo COBIT para o gerenciamento de processos de TI foi desenvolvido com uma nfase forte em controles. Cada processo de TI do COBIT tem um objetivo de controle alto nvel
e um nmero de objetivos de controle detalhados. Os objetivos de controle detalhados so
identificados por dois caracteres do domnio mais o nmero do processo e o nmero do objetivo de controle. Alm dos objetivos de controle detalhados, cada processo do COBIT tem
necessidades de um controle genrico que so identificadas por PCn (Process Control Number). Eles devero ser considerados juntos com os objetivos de controle detalhados para ter a
viso completas das necessidades de controle. Os PCn so:
PC1 - Metas e Objetivos do Processo (Goals and Objectives): define e comunica as metas
e objetivos especficos no tempo apropriado (SMARRT) para efetiva execuo de cada
processo de TI;
PC2 - Propriedade dos Processos (Process Owner): atribui um proprietrio a cada processo
e define claramente os papis e responsabilidades do proprietrio;
PC3 - Repetibilidade dos Processos (Repeatability): elabora e estabelece cada processo
chave de TI de forma que ele possa ser repetido e produza de maneira consistente os
resultados esperados;
PC4 - Papis e Responsabilidades (Roles and Responsibilities): define as atividades chaves
e as entregas do processo; designa e comunica os papis e responsabilidades para uma
efetiva e eficiente execuo das atividades chaves bem com a responsabilidade pelo processo e as entregas;
PC5 - Polticas, Planos e Procedimentos (Policy, Plans and Procedures): define e comunica
como todas as polticas, planos e procedimentos que direcionam os processos de TI so
documentados, revisados, mantidos, aprovados, armazenados, comunicados e utilizados para treinamento. Designa responsabilidades para cada uma dessas atividades e em
momentos apropriados verifica se elas so executadas corretamente. Assegura que as
polticas, planos e procedimentos sejam acessveis, corretos, entendidos e atualizados;
PC6 - Melhoria da Performance do Processo (Process Perfomance): identifica um conjunto
de mtricas que fornecem direcionamento para os resultados e performance dos processos; estabelece metas que refletem nos objetivos dos processos e indicadores de performance que permitem atingir os objetivos dos processos; define como os dados so
obtidos; compara as medies reais com as metas e toma medidas quanto aos desvios
quando necessrio; alinha mtricas, metas e mtodos com o enfoque de monitoramento
de performance geral da TI.
Alm dos controles necessrios, os proprietrios dos processos precisam entender quais entradas eles precisam receber de outros processos e quais processos dependem de seu processo.
O entendimento dos papis e responsabilidades de cada processo essencial para uma efetiva
governana. Para facilitar esse entendimento, o COBIT fornece uma tabela chamada RACI
(vide Seo 1.9) para cada processo.
Alm dos objetivos de controles, o COBIT tambm define os seguintes controles internos: Controle Gerais de TI e Controle de Aplicativos. Os controles gerais de TI so controles nos processos de TI e servios, por exemplo, desenvolvimento de sistemas, gerenciamento de mudanas,
81
segurana e operaes de computadores. Os controles de aplicativos so controles inseridos
nos aplicativos de processos de negcios, por exemplo, totalidade, veracidade, validade, autorizao e segregao de funes.
O COBIT considera que o projeto e a implementao dos controles de aplicativos so de responsabilidade da rea de TI. A responsabilidade pelo controle e gerenciamento operacional
dos controles de aplicativos no da rea de TI, mas do proprietrio do processo de negcio,
conforme ilustrado na Figura 3.10. Ou seja, a responsabilidade pelos controles de aplicativos
compartilhada entre as reas de negcios e de TI:
rea de negcio responsvel por definir os requisitos funcionais e de controles; e utilizar os servios automatizados;
rea de TI responsvel por automatizar e implementar os requisitos funcionais e de
controles; e estabelecer controles para manter a integridade dos controles de aplicativos.
Figura 3.10: inter-relacionamento dos componentes do COBIT. Fonte: ISACA.

Portanto, os processos de TI do COBIT cobrem os controles gerais de TI, mas somente nos aspectos relacionados ao desenvolvimento dos controles de aplicativos. A rea de negcio fica
responsvel pela definio e uso operacional.
O COBIT possui um conjunto recomendado de objetivos de controles de aplicativos, os quais
so identificados com ACn, que significa o nmero de controle do aplicativo:
AC1 Preparao e Autorizao de Dados Originais (Source Data Preparation and Authorisation): assegura que documentos fontes so preparados por pessoal autorizado e qualificado seguindo procedimentos estabelecidos, atentando-se para as funes de criao e
aprovao dos documentos;
82
AC2 Entrada e Coleta de Dados Fontes (Source Data Collection and Entry): estabelece que
a entrada de dados seja executada por pessoal autorizado e qualificado, e no caso de
dados inseridos de forma errada, a correo e o reenvio de no devem comprometer a
autorizao da transao original;
AC3 Testes de Veracidade, Totalidade e Autenticidade (Accuracy, Completeness and Authenticity Checks): assegura que transaes sejam exatas, completas e vlidas;
AC4 Processamento ntegro e Vlido (Processing Integrity and Validity): mantm a integridade e validade dos dados no ciclo de processamento. A deteco de transaes errneas
no interrompe o processamento de transaes vlidas;
AC5 Reviso de Sadas, Reconciliao e Manuseio de Erros (Output Review, Reconciliation
and Error Handling): define procedimentos e responsabilidades para assegurar que sadas
so manuseadas de forma autorizada, entregues ao destinatrios corretos e protegidos
durante a transmisso;
AC6 Autenticao e Integridade das Transaes (Transaction Authentication and Integrity):
assegura que a autenticidade da origem, o endereamento e integridade do contedo so
verificados antes de transportar os dados das transaes entre aplicativos e as funes de
negcios/operacionais.
3.7
Modelo de Maturidade
O modelo de maturidade do COBIT derivado dos modelos de maturidade da Engenharia de

Software. O COBIT define uma escala de maturidade similar ao CMM para cada um dos 34
processos de TI, que vai de um nvel de maturidade no-existente (0) a otimizado (5) - cada
um desses nveis est descritos na Tabela 3.2. Esse modelo de maturidade permite medir quo
bom os processos de gerenciamento so, ou seja, quo capazes eles so.
Diferente do enfoque no CMM, no COBIT no h inteno de medir os nveis de maneira
precisa ou tentar certificar que aquele nvel foi exatamente atingido. No COBIT, podemos
ter um processo situado em vrios nveis de maturidade, ou seja, possvel avanar para o
prximo nvel de maturidade sem ter cumprido as exigncias do nvel inferior. A utilizao
do modelo de maturidade para o gerenciamento e controle de cada um dos 34 processos de TI,
permite a organizao se auto-avaliar, isto :
a empresa consegue identificar o seu estgio atual (onde a empresa est hoje);
o estgio atual do mercado (comparao);
onde as melhorias so necessrias (onde a empresa quer estar);
os caminhos para o crescimento do estgio atual (como est) para onde a organizao
estar (como ser).
Ao fazer essa avaliao, a organizao est identificando os aprimoramentos necessrios de capacidade. A capacidade aplicada de forma correta ajuda a reduzir os riscos, mas a organizao
ainda precisa avaliar os controles necessrios para a mitigao dos riscos de forma a se manter
alinhada com os objetivos de negcio. Esses controles so guiados pelos objetivos de controle do COBIT. Assim, o processo de maturidade do COBIT est pautado em trs dimenses:
capacidade, cobertura e custo (vide ilustrao Figura 3.11).
83
Figura 3.11: as trs dimenses do Modelo de Maturidade com os respectivos direcionadores

primrios. Fonte: ISACA.
A capacidade est relacionada a quais os atributos que a organizao precisar ter para atingir de forma primria os objetivos de TI e consequentemente as necessidades do negcio. A
cobertura est relacionada a quanto dessa capacidade entregue, isto , quanto esta capacidade custa e o retorno do investimento esperado pela organizao. O controle est relacionado
o que a capacidade deve fazer de forma a mitigar os riscos de forma a continuar em conformidade com os objetivos de negcios. Ento, a abrangncia e a profundidade do controle e como
a capacidade utilizada e entregue so decises de custo-benefcio.
Uma caracterstica fundamental do modelo de maturidade que ele permite uma organizao medir o nvel de maturidade e definir quais nveis de maturidade quer chegar e quais
brechas existentes nos processos deseja eliminar.
Um ambiente de controle atingido quando todos os trs aspectos da maturidade (capacidade,
desempenho e controle) tiverem sido tratados. Com isso, a organizao melhora a maturidade,
reduz riscos e aprimora a eficincia, levando a uma menor quantidade de erros, processos mais
previsveis e uso eficiente dos recursos sob o ponto de vista de custos.
84
Nvel
Nome
Descrio
Inexistente
Inicial/Ad hoc
Repetvel, porm intuitivo
Processo definido
Gerenciado e Mensurvel
Otimizado
Completa falta de um processo reconhecido. A

empresa ainda no reconheceu que existe uma
questo a ser trabalhada.
A empresa reconhece que existem questes a
serem trabalhadas. Porm, no existem processos padronizados; existem alguns enfoques
Ad Hoc que tendem a ser aplicados individualmente; gerenciamento desorganizado.
Os processos possuem procedimentos similares
seguidos por diferentes pessoas para realizar
a mesma tarefa; no existe treinamento e/ou
comunicao formal dos procedimentos; a responsabilidade de cada indivduo; A confiana est no conhecimento do indivduo e erros
podem ocorrer.
Procedimentos padronizados, documentados
e comunicados atravs de treinamentos. Os
processos devem ser seguidos, porm desvios
ainda no so detectados.
A gerncia mede e monitora a aderncia aos
procedimentos e adota aes onde os processos parecem no estar funcionando. Os processos esto debaixo de um aprimoramento constante. Automao e ferramentas so utilizadas
de maneira limitada ou fragmentada.
Os processos foram refinados a um nvel de
boas prticas, baseado no resultado de um contnuo aprimoramento e modelagem da maturidade como outras organizaes. A TI utilizada como um caminho integrado para automatizar o fluxo de trabalho, provendo ferramentas para aprimorar a qualidade e efetividade, tornando a organizao rpida em
adaptar-se.
Tabela 3.2: os nveis do Modelo de Maturidade.
85
3.8
Medio de Desempenho
O modelo de maturidade do COBIT focado na capacidade, e no no desempenho. A medio

de performance, essencial para determinar a performance atual da empresa em seus processos de TI.
Os Objetivos de performance e mtricas para os processos de TI permitem demonstrar como
os processos atingem os objetivos de negcios e de TI e so utilizados para mensurar a performance dos processos. Os objetivos e mtricas so definidos em trs nveis no COBIT:
Objetivos e mtricas de TI, que definem o que os negcios esperam de TI e como medir
isso;
Objetivos e mtricas dos processos, que definem o que os processos de TI precisam entregar para suportar os objetivos de TI e como medir isso;
Objetivos e mtricas de atividades que estabelecem o que precisa acontecer dentro do
processo para atingir a requerida performance e como medir isso
Em verses anteriores do COBIT existiam dois indicadores Key Goal Indicators (KGI) e Key
Performance Indicators (KPI). No COBIT 4.1, esses indicadores foram trocados por dois tipos
de mtricas: Medidas de Resultados e Indicadores de Performance. A mtrica Medida de
Resultado, anteriormente chamado de KGI, indica se os objetivos foram atingidos; e a mtrica
Indicador de Performance, anteriormente chamado de KPI, indica se os objetivos sero possveis de serem atingidos.
Na mtrica Medidas de Resultados, os indicadores so medidos somente aps os fatos e so
chamados de indicadores histricos (lag indicators). Por exemplo, de acordo com a Figura 3.2,
podemos ter as Medidas de Resultado, conforme ilustrado na Figura 3.12, para os Objetivos
de Negcio, de TI, de Processo e de Atividades.
Figura 3.12: exemplo de medidas de resultado com os respectivos objetivos. Fonte: ISACA.
As Medidas de Resultado normalmente so expressas em termos de critrios de informao:
Disponibilidade da informao necessria para suportar as necessidades de negcios;
Ausncia de riscos de integridade e confidencialidade;
86
Eficincia de custos de processos e operao;
Confirmao de fidedignidade, efetividade e conformidade.
Na mtrica Indicador de Performance, os indicadores so medidos antes que os resultados sejam claros e so chamados de indicadores futuros (lead indicators). Esta mtrica define medidas
que determinam quo bem os negcios ou processos de TI esto sendo executados para permitir que os objetivos sejam atingidos. s vezes, os Indicadores de Performance so chamados
de direcionadores de performance, pois um servio entregue pela TI pode ser um objetivo de
TI e tambm um indicador de performance para o negcio.
As Medidas de Resultados no nvel menor tornam-se Indicadores de Performance para o nvel
maior. Por exemplo, conforme apresentado nas Figuras 3.2 e 3.12, uma Medida de Resultado
indicando que deteco e soluo de um acesso no autorizado (Objetivo de Processo) esto
nas metas ir possivelmente indicar que os servios de TI podem resistir a ataques e se recuperar deles (Objetivo de TI). Esse exemplo mostra que uma Medida de Resultado para um
Objetivo de Processo pode ser um direcionador de performance para um Objetivo de TI. A
Figura 3.13 ilustra direcionadores de performance para os exemplos das Figuras 3.2 e 3.12.
Figura 3.13: direcionadores de performance relacionados aos respectivos objetivos. Fonte:

ISACA.
Para sumarizar o assunto de mtricas, apresentamos a Figura 3.14, a qual ilustra os relacionamentos entre Objetivos de Negcio, TI, Processos e Atividades e as respectivas mtricas.
Do canto superior esquerdo ao canto superior direito, so ilustrados os objetivos em cascata.
Abaixo do objetivo est demonstrada a medida de resultados. As setas menores mostram que
a mesma mtrica um indicador de performance para um objetivo de maior nvel.
87
Figura 3.14: relacionamento entre processos, objetivos e mtricas. Fonte: ISACA.
3.9
Processos
Nesta Seo detalhamos os 34 processos de TI. Cada processo de TI ser apresentado da

seguinte forma:
uma descrio geral, os benefcios, os objetivos de TI, os objetivos de Processo, os objetivos de Atividade (como o processo alcanado), as mtricas chaves (como o processo
medido);
os Requisitos de Negcio, os Recursos de TI e as reas foco da Governana;
objetivos de controle detalhados;
modelo de maturidade.
Antes de descrevemos os processos, vamos apresentar dois conceitos ainda no abordados nas
sees anteriores: reas da Governana de TI e Matriz RACI.
As reas da Governana de TI so:
Alinhamento estratgico: foca em garantir o alinhamento da TI com os planos de negcio;
88
Entrega de valor: a TI entrega os benefcios previstos na estratgia da organizao,
concentrando-se em otimizar custos e prover valor intrnseco;
Gesto de recursos: melhor utilizao dos investimentos e gerenciamento apropriado
dos recursos crticos de TI;
Gesto de risco: entendimento claro e transparncia dos riscos da empresa e dos requerimentos da empresa e insero do gerenciamento dos riscos nas atividades da empresa;
Mensurao de desempenho: acompanha e monitora a implementao da estratgia,
trmino do projeto, uso dos recursos, processo de performance e entrega dos servios;
No COBIT as reas de Governana so definidas em termos de relacionamento primrio (P) e
secundrio (S) para cada processo.
A matriz RACI indica quem responsvel, responsabilizado, consultado e informado de acordo
com as atividades nos processos de TI. O termo responsabilizado, representado pela letra A,
significa que a responsabilidade deste indivduo, isto , esta a pessoa que d orientaes
e autoriza uma atividade. A responsabilidade, representado pela letra R, atribuda pessoa
que faz com que a tarefa seja executada. O consultado e informado, representado pelas letras C e I respectivamente, asseguram que todos que precisam sero envolvidos e suportam o
processo. As seguintes responsabilidades so mapeadas na matriz RACI:
Chief executive officer (CEO);
Chief financial officer (CFO);
Executivo de Negcio;
Chief information officer (CIO);
Proprietrio do Processo de Negcio;
Chefe de Operaes;
Responsvel por Arquitetura;
Responsvel por Desenvolvimento;
Responsvel pela Administrao de TI (nas grandes empresas, o responsvel por funes
como recursos humanos, oramentos e controles internos);
Project management officer (PMO) ou funo equivalente;
Conformidade, auditoria, riscos e segurana (grupos como responsabilidades por controles mas no de operaes de TI);
Ao estudar os processos do COBIT tenha sempre em mente que o COBIT concentra-se no que
deve ser obtido e no como atingir uma governana efetiva.
Vale lembrar que as entradas, as sadas, as responsabilidades, as mtricas e os objetivos definidas
no COBIT so ilustrativos e no uma receita completa ou exaustiva. Eles fornecem uma base
de conhecimento a partir da qual cada organizao deve selecionar o que se aplica de maneira
eficiente e eficaz considerando-se a estratgia, os objetivos e as polticas da organizao.
89
3.9.1
Planejar e Organizar
P01 - Definir um Plano Estratgico de TI

Descrio Geral: o plano estratgico deve melhorar o entendimento da organizao no
que diz respeito a oportunidades, limitaes da TI, desempenho atual e investimentos
requeridos. As estratgias e as prioridades de negcio so executadas por planos tticos
de TI, os quais estabelecem objetivos concisos, tarefas e planos bem definidos.
Benefcios: permitir a gerncia de todos os Recursos de TI de forma a ficar alinhado com
prioridades e estratgias de negcio.
Objetivos de TI: sustentar as estratgias de negcio e governana de TI; e ser transparente quanto a benefcios, custos e riscos.
Objetivos de Processo: traduzir os requisitos de negcio em ofertas de servios e o desenvolvimento de estratgias para entregar os servios de forma eficaz e transparente.
Objetivos de Atividade: comprometimento da Alta Direo no alinhamento do plano
estratgico de TI com as necessidades atuais e futuras; Entendimento da capacidade atual de TI; Definio de um esquema com priorizao dos objetivos de negcios, que
quantifique os requisitos de negcio.
Mtricas Chaves: percentual dos objetivos de TI no plano estratgico de TI que sustentam o plano estratgico de negcio; Percentual de projetos no portflio de projetos de TI
que podem ser diretamente relacionados ao plano ttico de TI; Demora entre a atualizao do plano estratgico de TI e a atualizao dos planos tticos de TI.
Os Requisitos de Negcio, os Recursos de TI e as reas foco da Governana so mostrados na
Figura 3.15 (a), (b) e (c), respectivamente.
Os objetivos de controle do processo PO1 so mostrados na Tabela 3.3.
O processo PO1 tem o objetivo de definir o plano estratgico de TI. Ento, o modelo de maturidade deste processo referencia o plano estratgico de TI de acordo com os nveis de maturidade
mostrados na Tabela 3.2. Apresentamos a Tabela 3.4 que mostra o modelo de maturidade do
processo PO1.
Voc pode utilizar esta mesma anlise para definir o modelo de maturidade dos outros processos de TI.
90
Figura 3.15: os requisitos de negcio, os recursos de TI e as reas foco da Governana do

processo PO1. Fonte: ISACA.
Nmero
Nome
PO1.1
Gerenciamento de Valor da TI
PO1.2
Alinhamento entre TI e Negcio
PO1.3
Avaliao da Capacidade e Desempenho Correntes
PO1.4
Plano Estratgico de TI
PO1.5
Planos Tticos de TI
PO1.6
Gerenciamento do Portflio de TI
Tabela 3.3: objetivos de controle detalhados para o processo PO1.
91
Nvel
Descrio
plano estratgico de TI no executado
1
2
3
4
planejamento estratgico de TI conhecida pela

Direo de TI
planejamento estratgico de TI compartilhado
com a Direo do Negcio
uma poltica define quando e como realizar um
planejamento estratgico de TI
planejamento estratgico de TI uma prtica
padro cujas excees so detectadas pela Direo
planejamento estratgico de TI um processo
documentado e dinmico, sempre considerado no estabelecimento dos objetivos de negcio, e resulta em valor de negcio identificvel
atravs dos investimentos em TI
Tabela 3.4: os nveis do Modelo de Maturidade para o processo P01.
P02 - Definir a Arquitetura da Informao

Descrio Geral: melhora a qualidade de deciso certificando-se de que informaes
seguras e confiveis so fornecidas; e permite racionalizar os recursos de sistemas de
informao para atender s estratgias de negcio.
Benefcios: melhora a efetividade e o controle de compartilhamento da informao, permitindo maior responsabilidade pela integridade e segurana dos dados.
Objetivos de TI: ser gil para atender os requisitos; fornecer informaes confiveis e
consistente; integrar as aplicaes nos processos de negcio.
Objetivos de Processo: definir um modelo de dados de negcio que incorpore um esquema de classificao de dados, visando assegurar a integridade e consistncia dos dados.
Objetivos de Atividade: garantia da preciso da arquitetura da informao e do modelo
de dados; definio da propriedade dos dados; classificao da informao utilizando
um esquema de classificao previamente estabelecido.
Mtricas Chaves: percentual de elementos de dados redundantes ou duplicados; percentual de aplicao que no esto em conformidade com a arquitetura de informao;
frequncia de atividades da validao dos dados.
92

O processo PO2 tem o objetivo de definir a Arquitetura da Informao na organizao. Ento,
o modelo de maturidade deste processo referencia a Arquitetura de Informao de acordo com
os nveis de maturidade mostrados na Tabela 3.2.
93
Nmero
Nome
PO2.1
Modelo de Arquitetura da Informao da Organizao
PO2.2
Dicionrio de Dados Corporativos e Regras de Sintaxe de Dados
PO2.3
Esquema de Classificao de Dados
PO2.4
Gerenciamento de Integridade
PO3 - Determinar as Diretrizes de Tecnologia

Descrio Geral: a criao de um plano de infraestrutura tecnolgica e um conselho de
arquitetura permite estabelecer e gerenciar as expectativas do que a rea de TI pode oferecer. Este plano aborda aspectos relacionados a arquitetura de sistemas, direcionamento
tecnolgico, plano de aquisies, padres, estratgias de migrao e contingncia.
Benefcios: com este plano, consegue-se respostas rpidas a mudanas, economia em
equipe e em investimentos nos sistemas de informao e interoperabilidade entre aplicaes; este processo auxilia os responsveis pelos servios de informao a determinarem
o direcionamento tecnolgico que suporta o negcio.
Objetivos de TI: possuir aplicativos, recursos e capacidades integrados, padronizados,
estveis e com boa relao custo-benefcio de forma a atender os requisitos atuais e futuros do negcio.
Objetivos de Processo: definir e implementar um plano de infraestrutura, arquitetura e
padres de tecnologia.
Objetivos de Atividade: estabelecimento de um frum para conduzir a arquitetura e
verificar a sua conformidade; estabelecimento de um plano de infraestrutura tecnolgica com relao os requisitos, custos e riscos; definies de padres de infraestrutura
tecnolgica com base nos requisitos da arquitetura de informao.
Mtricas Chaves: quantidade e tipo de desvios do plano de infraestrutura tecnolgica;
frequncia de atualizao/reviso do planejamento de infraestrutura tecnolgica; quantidade de plataformas de tecnologia por rea da organizao.
94

O processo PO3 tem o objetivo de definir o planejamento de infraestrutura de tecnologia para
a organizao. Ento, o modelo de maturidade deste processo referencia o planejamento de
infraestrutura de tecnologia de acordo com os nveis de maturidade mostrados na Tabela 3.2.
95
Nmero
Nome
PO3.1
Planejamento da Diretriz Tecnolgica
PO3.2
Plano de Infraestrutura Tecnolgica
PO3.3
Monitoramento de Regulamentos e Tendncias Futuras
PO3.4
Padres Tecnolgicos
PO3.5
Conselho de Arquitetura de TI
PO4 - Definir os Processos, a Organizao e os Relacionamentos de TI

Descrio Geral: estruturas organizacionais de TI deve fazer parte de uma estrutura de
processos de TI que assegura transparncia e controle; priorizao dos recursos de TI de
acordo com as necessidades do negcio; processos, polticas administrativas e procedimentos so estabelecidos para todas as funes, em especial as de controle, de garantia
da qualidade e de segurana da informao.
Benefcios: a TI envolvida nos processos de deciso relevantes para assegurar o rpido
atendimento das exigncias do negcio.
Objetivos de TI: ser gil em resposta estratgia de negcio; atender aos requisitos da
Governana; e fornecer pontos de contatos.
Objetivos de Processo: estabelecimento de estruturas organizacionais de TI; definio e
implantao de processos de TI com proprietrios, papis e responsabilidade;
Objetivos de Atividade: definio de uma estrutura de processos TI; criao de conselhos e estruturas organizacionais; definio de papis e responsabilidades.
Mtricas Chaves: percentual de funes com posies e descries de autoridades documentadas; nmero de processos de negcio no suportados pela organizao de TI, mas
que deveriam ser suportados de acordo com a estratgia; nmero de atividades centrais
de TI realizadas fora da organizao de TI e que no so aprovadas ou submetidas aos
padres organizacionais de TI.
A organizao de TI definida com base nos requisitos de pessoal, habilidades, funes, autoridade, papis e responsabilidades, rastreabilidade e superviso.
Os Requisitos de Negcio, os Recursos de TI e as reas foco da Governana so mostrados
na Figura 3.18 (a), (b) e (c), respectivamente.
96

O processo PO4 tem o objetivo definir processos, organizar a rea de TI e estabelecer os relacionamentos de TI a fim de a TI estar alinhada com o negcio. Ento, o modelo de maturidade
deste processo referencia os processos, a organizao de TI e os relacionamentos de acordo
com os nveis de maturidade mostrados na Tabela 3.2.
97
Nmero
Nome
PO4.1
Estrutura de Processos de TI
PO4.2
Comit Estratgico de TI
PO4.3
Comit Executivo de TI
PO4.4
Posicionamento Organizacional da rea de TI
PO4.5
Estrutura Organizacional de TI
PO4.6
Definio de Papis e Responsabilidades
PO4.7
Responsabilidade pela Garantia de Qualidade
PO4.8
Responsabilidade por Riscos, Segurana e Conformidade
PO4.9
Proprietrios de Dados e Sistemas
PO4.10
Superviso
PO4.11
Segregao de Funes
PO4.12
Recrutamento de pessoal de TI
PO4.13
Pessoal Chave de TI
PO4.14
Polticas e Procedimentos para Pessoal Contratado
PO4.15
Relacionamentos
PO5 - Gerenciar o Investimento de TI

Descrio Geral: estabelecer e manter uma estrutura para gerenciar os investimentos em
TI em termos de custos, benefcios e oramentos. Este processo promove a relao entre
as partes interessadas no negcio e a TI, uso eficaz e eficiente dos recursos de TI, prov
transparncia, atribui responsabilidade pelo custo total de propriedade (TCO, Total Cost
of Ownership) e retorno sobre os investimentos em TI.
Benefcios: promover a parceria entre a TI e as partes interessadas do negcio; e permitir
o uso eficaz e eficiente dos recursos de TI.
Objetivos de TI: melhorar a relao custo-beneficio da TI; e contribuir para a lucratividade do negcio com servios integrados e padronizados.
Objetivos de Processo: decidir os investimentos em TI de forma eficaz e eficiente; e
elaborar e rastrear oramentos de TI alinhados com as estratgias da TI e com as decises
de investimento.
Objetivos de Atividade: previso e alocao de oramentos; definio de critrio de investimento (Retorno Sobre Investimento - ROI, perodo de recuperao de investimento,
Valor Presente Lquido - NPV).
Mtricas Chaves: reduo do percentual de custo unitrio dos servios de TI; percentual
de desvio do valor orado comparado com o oramento total; e percentual dos gastos de
TI expressos atravs de motivadores de valor de negcio.
98

O processo PO5 tem o objetivo de gerenciar os investimentos em TI. Ento, o modelo de maturidade deste processo referencia os investimentos de TI de acordo com os nveis de maturidade mostrados na Tabela 3.2.
99
Nmero
Nome
PO5.1
Estrutura da Administrao Financeira
PO5.2
Priorizao dentro do Oramento de TI
PO5.3
Processo de Oramento de TI
PO5.4
Gerenciamento de Custo
PO5.5
Gerenciamento de Benefcios
PO6 - Comunicar Metas e Diretrizes Gerenciais

Descrio Geral: a Direo desenvolve uma estrutura de controles de TI e define, aprova
e comunica polticas por meio de um programa de comunicao contnuo. Este programa
permitir a articulao de misses, metas, polticas, procedimentos, etc. O programa de
comunicao visa apoiar o alcance dos objetivos de TI e assegura o entendimento dos
negcios, dos riscos de TI, dos objetivos e das diretrizes.
Benefcios: assegurar conformidade com leis e regulamentos relevantes; e apoiar o alcance dos objetivos de TI em toda a organizao.
Objetivos de TI: manter as informaes precisas e atualizadas nos servios de TI, bem
como os riscos de TI e responsabilidades.
Objetivos de Processo: estabelecer polticas, procedimentos e diretrizes compreensveis
e incorporadas uma estrutura de controles de TI.
Objetivos de Atividade: definio de uma estrutura de controle de TI; desenvolvimento
e implantao de polticas de TI; e imposio de polticas de TI.
Mtricas Chaves: quantidade de interrupes no negcio devido a problemas nos servios
de TI; percentual das partes interessadas que entendem a estrutura corporativa de controle de TI; e percentual das partes interessadas que no esto em conformidade com a
poltica.
100

O processo PO6 tem o objetivo estabelecer um ambiente de controle da informao. Ento,
o modelo de maturidade deste processo referencia o ambiente de controle da informao de
acordo com os nveis de maturidade mostrados na Tabela 3.2.
101
Nmero
Nome
PO6.1
Poltica de TI e Ambiente de Controle
PO6.2
Risco de TI Corporativo e Estrutura Interna de Controle
PO6.3
Gerenciamento de Polticas de TI
PO6.4
Distribuio da Poltica
PO6.5
Comunicao dos Objetivos e Diretrizes de TI
PO7 - Gerenciar os Recursos Humanos de TI

Descrio Geral: definir prticas de recrutamento, treinamento, avaliao de desempenho, promoo e desligamento com o objetivo de adquirir, manter e motivar uma fora
de trabalho competente, que precisa criar e entregar servios de TI para o negcio. Este
processo muito crtico, pois as pessoas so ativos importantes, e a governana e controle
de dados dependente da motivao e da competncia das pessoas.
Benefcios: prticas de recrutamento e reteno; mapeamento de competncias; e motivao das pessoas.
Objetivos de TI: ter pessoas motivadas e competentes para criar e entregar os servios
de TI.
Objetivos de Processo: admitir e treinar pessoas; motiv-las com planos de carreira
claros; atribuio de funcionalidades de acordo com as habilidades; criar descries de
cargos; assegurar a conscincia da dependncia dos indivduos na organizao.
Objetivos de Atividade: reviso do desempenho do pessoal; admisso e treinamento do
pessoal de TI; mitigar a dependncias excessiva de recursos chave.
Mtricas Chaves: nvel de satisfao das partes interessadas com as experincias e habilidades da equipe de TI; rotatividade da equipe de TI; percentual da equipe de TI certificado de acordo com as necessidades da funo.
102

O processo PO7 tem o objetivo gerenciar os recursos humanos de TI. Ento, o modelo de maturidade deste processo referencia a gerncia dos recursos humanos de TI de acordo com os
nveis de maturidade mostrados na Tabela 3.2.
103
Nmero
Nome
PO7.1
Recrutamento e Reteno de Pessoal
PO7.2
Competncias Pessoais
PO7.3
Preenchimento de Vagas
PO7.4
Treinamento do Pessoal
PO7.5
Dependncia de Indivduos
PO7.6
Procedimentos de Liberao de Pessoal
PO7.7
Avaliao de Desempenho Profissional
PO7.8
Mudana e Desligamento de Cargo
PO8 - Gerenciar a Qualidade

Descrio Geral: desenvolvimento e manuteno de um sistema de gesto de qualidade
que gere requisitos, procedimentos e polticas de qualidade de forma clara.
Benefcios: a gesto da qualidade assegura que a TI est fornecendo valor para o negcio, melhoria contnua e transparncia para as partes interessadas.
Objetivos de TI: melhoria continua e mensurvel da qualidade dos servios entregues
pela rea de TI.
Objetivos de Processo: definir uma sistema de gesto de qualidade (SGQ); implementar um programa de melhoria contnua dos servios de TI; monitorar continuamente o
desempenho do SGQ com base em objetivos pr-definidos.
Objetivos de Atividade: definio de prticas e padres de qualidade; melhoria contnua do SGQ; monitorar e revisar o desempenho comparado com os padres de qualidade definidos.
Mtricas Chaves: percentual das partes interessadas satisfeitas com a qualidade da TI;
percentual dos processos de TI formalmente revisados pelo processo de garantia de qualidade periodicamente e que atingem metas e objetivos de qualidade; percentual dos processos que recebem revises de garantia de qualidade (Quality Assurance - QA).
104

O processo PO8 tem o objetivo de estabelecer um Sistema de Gesto de Qualidade. Ento, o
modelo de maturidade deste processo referencia o Sistema de Gesto de Qualidade de acordo
105
Nmero
Nome
PO8.1
Sistema de Gerenciamento de Qualidade (SGQ)
PO8.2
Padres e Prticas de Qualidade de TI
PO8.3
Padres de Desenvolvimento e Aquisio
PO8.4
Foco no Cliente
PO8.5
Melhoria Contnua
PO8.6
Medio, Monitoramento e Reviso da Qualidade
PO9 - Avaliar e Gerenciar os Riscos de TI

Descrio Geral: criar e manter uma estrutura de gesto de riscos na qual exista riscos
TI acordados, estratgias de mitigao e riscos residuais.
Benefcios: permiti que as partes interessadas alinhem o risco a nveis de tolerncia
aceitveis.
Objetivos de TI: analisar e comunicar os riscos de TI e seus possveis impactos nos objetivos de negcios.
Objetivos de Processo: estabelecer uma estrutura de gerenciamento de risco integrada
ao nvel corporativo e operacional.
Objetivos de Atividade garantir que o gerenciamento de risco esteja integrada aos processos gerenciais e operacionais e sendo aplicado; realizar avaliaes de risco; recomendar e comunicar planos de ao de mitigao de riscos.
Mtricas Chaves: percentual de objetivos crticos de TI cobertos pela avaliao de risco;
percentual de riscos crticos de TI identificados que possuam planos de ao desenvolvidos; percentual dos planos de ao de gesto de risco aprovados para implementao.
106

O processo PO9 tem o objetivo de gerenciar os riscos de TI e do negcio. Ento, o modelo de
maturidade deste processo referencia a gerncia dos riscos de TI de acordo com os nveis de
maturidade mostrados na Tabela 3.2.
107
Nmero
Nome
PO9.1
Alinhamento da gesto de riscos de TI e de Negcios
PO9.2
Estabelecimento do Contexto de Risco
PO9.3
Identificao de Eventos
PO9.4
Avaliao de Risco
PO9.5
Resposta ao Risco
PO9.6
Manuteno e Monitoramento do Plano de Ao de Risco
PO10 - Gerenciar Projetos

Descrio Geral: implementar uma estrutura de gesto de projeto para o gerenciamento
dos projetos na rea de TI, assegurando a coordenao e priorizao dos projetos. Essa estrutura inclui um plano mestre, atribuio de recursos, definio dos resultados a serem
entregues, aprovao dos usurios, uma diviso por fases de entrega, garantia da qualidade, um plano de teste formal e uma reviso ps-implementao para assegurar a
gesto de risco do projeto e a entrega de valor para o negcio.
Benefcios: reduz o risco de custos inesperados e de cancelamentos de projeto; aperfeioa a comunicao, melhora o envolvimento das reas de negcio e dos usurios finais; assegura o valor e a qualidade dos resultados do projeto; e maximiza a contribuio
para os programas de investimentos em TI.
Objetivos de TI: entregar projetos dentro do tempo, oramento e qualidade acordados.
Objetivos de Processo: aplicar uma gesto de projetos aos projetos de TI, permitindo o
monitoramento do projetos e riscos envolvidos e partio das partes interessadas.
Objetivos de Atividade definio de diretrizes de gesto de projetos; realizao de planejamento de projetos para os projetos de TI.
Mtricas Chaves: percentual de projetos que atendem aos acordos; percentual de projetos que foram revisados aps a implementao; percentual de projetos que seguem os
padres e as prticas de gerenciamento de projetos.
108

O processo PO10 tem o objetivo estabelecer prticas de gerenciamento de projetos. Ento, o
modelo de maturidade deste processo referencia a gesto de projetos de acordo com os nveis
de maturidade mostrados na Tabela 3.2.
109
Nmero
Nome
PO10.1
Estrutura de Gesto de Programas
PO10.2
Estrutura de Gesto de Projetos
PO10.3
Abordagem da Gesto de Projetos
PO10.4
Comprometimento das Partes Interessadas
PO10.5
Declarao do Escopo do Projeto
PO10.6
Fase de Incio do Projeto
PO10.6
Plano Integrado de Projeto
PO10.6
Recursos do Projeto
PO10.6
Gesto de Risco do Projeto
PO10.6
Plano de Qualidade de Projeto
PO10.6
Controle de Mudana de Projeto
PO10.6
Planejamento de mtodos de validao
PO10.6
Medio de Desempenho, Monitoramento e Reporte do Projeto
PO10.6
Concluso do Projeto
3.9.2
Adquirir e Implementar
AI1 - Identificar Solues Automatizadas

Descrio Geral: este processo est relacionado tomada de deciso entre adquirir ou
desenvolver uma aplicao necessria para que os requisitos de negcio sejam alcanados. Este processo possui a definio da necessidade, fontes alternativas, reviso de
viabilidade econmica e tecnolgica, anlises de riscos e de custo-benefcio e a obteno
da deciso final por desenvolver ou comprar.
Benefcios: permite as organizaes minimizar os custos de aquisio e implementao
de solues; e permite o negcio alcanar seus objetivos.
Objetivos de TI: traduzir os requisitos funcionais de negcio em um projeto eficiente e
eficaz de solues automatizadas.
Objetivos de Processo: identificar solues tecnicamente viveis e com boa relao custobenefcio.
Objetivos de Atividade: definio de requisitos tcnicos e de negcios; realizao de
estudos de viabilidade; aprovao ou rejeio de requisitos e do estudo de viabilidade.
Mtricas Chaves: quantidade de projetos nos quais os benefcios esperados no foram
alcanados devido a premissas incorretas de viabilidade; percentual de estudos de viabilidade aceitos pelos respectivos proprietrios de processos de negcios; percentual de
usurios satisfeitos com as funcionalidades entregues
110

processo AI1. Fonte: ISACA.
Os objetivos de controle do processo AI1 so mostrados na Tabela 3.14.
O processo AI1 tem o objetivo identificar e avaliar as solues de TI. Ento, o modelo de maturidade deste processo referencia a identificao e avaliao de solues de TI de acordo com
111
Nmero
Nome
AI1.1
Definio e Manuteno de Requisitos Tcnicos e Funcionais de Negcio
AI1.2
Relatrio de Anlise de Risco
AI1.3
Estudo de Viabilidade e Formulao de Aes Alternativas
AI1.4
Deciso e Aprovao de Requisitos e Estudo de Viabilidade

Tabela 3.14: objetivos de controle detalhados para o processo AI1.
AI2 - Adquirir e Manter Software Aplicativo

Descrio Geral: este processo contempla a disponibilizao de aplicaes alinhadas aos
requisitos do negcio. Para uma aplicao ser disponibilizada, ela deve ter um projetos
de aplicao, ser desenvolvida e configurada de acordo com padres, ter controles e
atender a requisitos de segurana apropriados.
Benefcios: permite as organizaes apoiarem de forma adequada as operaes do negcio com as aplicaes corretas.
Objetivos de TI: disponibilizar aplicaes alinhadas aos requisitos do negcio em um
prazo desejado e com custo razovel.
Objetivos de Processo: garantir a existncia de processos de desenvolvimento que contemplem otimizao de custos e cumprimento de prazo.
Objetivos de Atividade: traduzir os requisitos de negcio nas especificaes de projetos; adotar padres de desenvolvimento; separar o projeto em atividades de desenvolvimento, teste e operao.
Mtricas Chaves: quantidade de problemas em produo por indisponibilidade de aplicao; percentual de usurios satisfeitos com a funcionalidade oferecida.
112

O processo AI2 tem o objetivo de definir processo de aquisio e manuteno de aplicaes.
Ento, o modelo de maturidade deste processo referencia a aquisio e manuteno de aplicaes de acordo com os nveis de maturidade mostrados na Tabela 3.2.
113
Nmero
Nome
AI2.1
Projeto em Nvel Macro
AI2.2
Projeto Detalhado
AI2.3
Controle e Auditabilidade do Aplicativo
AI2.4
Segurana e Disponibilidade do Aplicativo
AI2.5
Configurao e Implementao de Software Aplicativo Adquirido
AI2.6
Principais Atualizaes dos Sistemas Existentes
AI2.7
Desenvolvimento de Software Aplicativo
AI2.8
Garantia de Qualidade de Software
AI2.9
Gesto dos Requisitos das Aplicaes
AI2.10
Manuteno de Software Aplicativo
AI3 - Adquirir e Manter Infraestrutura de Tecnologia

Descrio Geral: as organizaes precisam ter uma abordagem planejada de aquisio,
manuteno e proteo da infraestrutura alinhada s estratgicas tecnolgicas adotadas
e prover ambientes de desenvolvimento e teste. Para isso, processos de aquisio, implementao e atualizao da infraestrutura tecnolgica precisam ser definidos.
Benefcios: assegura um apoio tecnolgico contnuo s aplicaes de negcio.
Objetivos de TI: adquirir e manter uma infraestrutura de TI integrada e padronizada.
Objetivos de Processo: disponibilizar plataformas apropriadas s aplicaes de negcio
com base na arquitetura de TI e nos padres de tecnologia.
Objetivos de Atividade: preparar um plano de aquisio tecnolgica alinhado com o
plano de infraestrutura tecnolgica; planejar manuteno da infraestrutura; e implementar auditorias, controles internos e medidas de segurana.
Mtricas Chaves: percentual das plataformas que no esto alinhadas com os padres
de tecnologia e arquitetura de TI; quantidade de processos crticos de negcio sustentados por infraestrutura obsoleta; quantidade de componentes de infraestrutura que no
possuem suporte.
114

O processo AI3 tem o objetivo gerenciar a infraestrutura de TI em termos de aquisies e
manutenes. Ento, o modelo de maturidade deste processo referencia a aquisio e manuteno
da infraestrutura de TI de acordo com os nveis de maturidade mostrados na Tabela 3.2.
115
Nmero
Nome
AI3.1
Plano de Aquisio de Infraestrutura Tecnolgica
AI3.2
Infraestrutura de Recursos, Proteo e Disponibilidade
AI3.3
Manuteno da Infraestrutura
AI3.4
Viabilidade do Ambiente de Teste
AI4 - Habilitar Operao e Uso

Descrio Geral: este processo requer a elaborao de documentos e manuais para usurios
e para TI e a promoo de treinamentos para assegurar a operao e uso apropriado das
aplicaes e infraestrutura, almejando que o conhecimento sobre novos sistemas esto
sempre disponveis.
Benefcios: garante que o conhecimento sobre novos sistema esto sempre disponveis.
Objetivos de TI: garantir a satisfao do usurio provendo servios; integrao completa
das aplicaes e solues de TI aos processos de negcio.
Objetivos de Processo: fornecer documentos, manuais e materiais de treinamento para
transferir o conhecimento necessrio, garantindo o uso correto dos sistemas;
Objetivos de Atividade: desenvolver e disponibilizar documentao para transferncia
de conhecimento; comunicar e treinar usurios, gestores, equipes de suporte e operao;
gerar materiais de treinamento.
Mtricas Chaves: quantidade de aplicaes nas quais os procedimentos de TI esto integrados aos processos de negcio; percentual de proprietrios de negcio satisfeitos com
treinamentos e material de suporte das aplicaes; quantidade de aplicaes que dispem de treinamento adequado e de suporte de usurio e operacional.
116

O processo AI4 tem o objetivo de definir documentao de usurios, manuais de operaes e
material de treinamento. Ento, o modelo de maturidade deste processo referencia procedimentos que geram as documentaes, manuais e material de treinamento de acordo com os
117
Nmero
Nome
AI4.1
Planejamento para Solues Operacionais
AI4.2
Transferncia de Conhecimento ao Gerenciamento do Negcio
AI4.3
Transferncia de Conhecimento aos Usurios Finais
AI4.4
Transferncia de Conhecimento s Equipes de Operaes e Suporte

AI5 - Adquirir Recursos de TI

Descrio Geral: este processo requer a definio e aplicao de procedimentos de aquisio,
seleo de fornecedores, estabelecimento de arranjos contratuais e a aquisio de fato,
pois os recursos de TI (pessoas, hardware, software e servios) precisam ser adquiridos/contratados.
Benefcios: assegura que a organizao tenha todos os recursos de TI necessrios a
tempo e com boa relao custo-benefcio.
Objetivos de TI: melhorar o custo-eficincia de TI e sua contribuio para a lucratividade
do negcio.
Objetivos de Processo: reduzir os riscos de aquisio de recursos de TI; adquirir e manter uma infraestrutura de TI padronizao e integrada; e adquirir e manter habilidades
de TI que respondam estratgia de entrega.
Objetivos de Atividade: obter parecer profissional para aspectos legais e contratuais;
definir procedimentos de aquisio; adquirir/contratar hardware, software e servios de
TI.
Mtricas Chaves: quantidade de discordncias relacionadas aos contratos de aquisio;
custo reduzido de compra; percentual das principais partes interessadas satisfeitas com
os fornecedores.
118

O processo AI5 tem o objetivo adquirir os recursos de TI. Ento, o modelo de maturidade
deste processo referencia a aquisio de recursos de TI de acordo com os nveis de maturidade
mostrados na Tabela 3.2.
119
Nmero
Nome
AI5.1
Controle de Aquisio
AI5.2
Gerenciamento de Contratos de Fornecedores
AI5.3
Seleo de Fornecedores
AI5.4
Aquisio de Recursos de TI
AI6 - Gerenciar Mudanas

Descrio Geral: este processo visa garantir que mudanas (manutenes e correes)
na infraestrutura e nas aplicaes no ambiente de produo devem ser registradas, avaliadas e autorizadas antes da implementao, e depois da implementao, elas devem ser
revisadas.
Benefcios: assegura a mitigao de riscos de impactos negativos na estabilidade ou na
integridade no ambiente de produo.
Objetivos de TI: atender aos requisitos de negcio, reduzindo trabalhos e defeitos nas
solues e nos servios entregues.
Objetivos de Processo: controlar a avaliao de impacto, autorizao e implementao
das mudanas no ambiente de produo; minimizar erros devido as especificaes de
requisitos incompletas; interromper a implantao de mudanas no autorizadas.
Objetivos de Atividade: definir e comunicar procedimentos de mudanas; avaliar, priorizar e autorizar as mudanas; acompanhar o status das mudanas.
Mtricas Chaves: quantidade de paradas ou erros devido a especificaes inadequadas
ou avaliaes de impacto crticas incompletas; retrabalho de infraestrutura ou aplicao
causado por especificaes de mudana inadequadas; percentual de mudanas que seguem
o processo formal de controle de mudanas.
120

O processo AI6 tem o objetivo gerenciar as mudanas. Ento, o modelo de maturidade deste
processo referencia o gerenciamento de mudanas de acordo com os nveis de maturidade
121
Nmero
Nome
AI6.1
Padres e Procedimentos de Mudana
AI6.2
Avaliao de Impacto, Priorizao e Autorizao
AI6.3
Mudanas de Emergncia
AI6.4
Acompanhamento de Status e Relatrios de Mudanas
AI6.5
Finalizao da Mudana e Documentao
AI7 - Instalar e Homologar Solues e Mudanas

Descrio Geral: este processo requer que para um sistema entrar em produo, necessrio
realizar de testes, definir de instrues de implantao e migrao, planejar a liberao
do sistema e revisar aps a implantao.
Benefcios: assegura que os sistemas operacionais esto alinhados com as expectativas e
os resultados acordados.
Objetivos de TI: sistemas novos ou alterados funcionem corretamente aps a instalao.
Objetivos de Processo: testar se as aplicaes e solues esto livres de erros e atendem as requisitos pretendidos; planejar a implantao e a migrao para o ambiente de
produo.
Objetivos de Atividade: estabelecer metodologia de teste; realizar planejamento para
liberao para a produo; avaliar e aprovar os resultados de testes; realizar revises
aps a implantao.
Mtricas Chaves: tempo de indisponibilidade da aplicao ou quantidade de correes
devido a testes inadequados; percentual de sistemas que na avaliao aps a implementao atende aos benefcios planejados originalmente; percentual de projetos que tenham
plano de testes documentado e aprovado.
122

O processo AI7 tem o objetivo instalar e homologar solues e mudanas. Ento, o modelo
de maturidade deste processo referencia a instalao, verificao e validao de solues e
mudanas de acordo com os nveis de maturidade mostrados na Tabela 3.2.
123
Nmero
Nome
AI7.1
Treinamento
AI7.2
Plano de Teste
AI7.3
Plano de Implementao
AI7.4
Ambiente de Testes
AI7.5
Converso de Dados e Sistemas
AI7.6
Teste de Mudana
AI7.7
Teste de Aceitao Final
AI7.8
Promoo para a Produo
AI7.9
Reviso ps-implementao
3.9.3
Entregar e Suportar
DS1 - Definir e Gerenciar Nveis de Servios

Descrio Geral: neste processo um acordo definido e documentado a fim de permitir comunicao eficaz entre a Direo de TI e os clientes de negcio sobre os servios
necessrios de TI e os nveis de servio esperado. Este processo tambm inclui monitoramento e relatrio a respeito do atendimento dos nveis dos servios.
Benefcios: alinhamento entre os servios de TI e os respectivos requisitos do negcio
por meio de uma comunicao eficaz entre a Direo de TI e os clientes de negcio.
Objetivos de TI: assegurar que os principais servios de TI esto alinhados com a estratgia de negcio.
Objetivos de Processo: identificar os requisitos de servios; acordar os nveis de servio;
e monitorar o atendimento aos nveis de servio.
Objetivos de Atividade: formalizar acordos de nveis de servio internos e externos
que estejam alinhas com os requisitos e a capacidade de entrega; reportar por meio de
reunies e/ou documentos aos nveis de servios acordados; identificar e comunicar os
requisitos de servios novos e atualizados para o planejamento estratgico.
Mtricas Chaves: percentual das partes interessadas que consideram que os nveis de entrega de servio esto de acordo com os nveis acordados; quantidade de servios prestados inexistentes no acordo; quantidade anual de reunies formais de anlise crtica de
acordo de nvel de servio (SLA) com os representantes do negcio.
Os objetivos de controle do processo DS1 so mostrados na Tabela 3.21.
124

processo DS1. Fonte: ISACA.
O processo DS1 tem o objetivo de definir os nveis de servio. Ento, o modelo de maturidade deste processo referencia os nveis de servio de acordo com os nveis de maturidade
125
Nmero
Nome
DS1.1
Estrutura de Gesto de Nveis de Servio
DS1.2
Definio de Servios
DS1.3
Acordos de Nvel de Servio
DS1.4
Acordos de Nvel Operacional
DS1.5
Monitoramento e Relatrio de Realizaes de Nvel de Servio
DS1.6
Reviso dos Acordos de Nvel de Servio e dos Contratos
Tabela 3.21: objetivos de controle detalhados para o processo DS1.
DS2 - Gerenciar Servios Terceirizados

Descrio Geral: este processo requer uma efetiva gesto da terceirizao a fim de assegurar que os servios prestados por fornecedores esto satisfazendo os requisitos de
negcio. Nesta gesto, h uma definio muito clara dos papis, das responsabilidades
e das expectativas nos acordos de terceirizao e reviso e monitoramento dos acordos
quanto a efetividade e conformidade.
Benefcios: permite gerenciar de forma eficaz os servios terceirizados, minimizando os
riscos de negcio relacionados aos terceirizados que no cumprem o seu papel.
Objetivos de TI: fornecer servios terceirizados satisfatrios e transparentes do ponto de
vista custo, riscos e benefcios.
Objetivos de Processo: estabelecer relacionamentos e responsabilidades bilaterais com
fornecedores terceirizados qualificados; e monitorar a entrega dos servios para garantir
o cumprimento dos acordos.
Objetivos de Atividade: identificar e categorizar os fornecedores; identificar e reduzir
os riscos associados ao fornecedor; e monitorar e medir o desempenho do fornecedor.
Mtricas Chaves: quantidade de reclamaes de usurios devido aos servios contratados; percentual de grandes fornecedores que atendam aos requisitos e nveis de servio
definidos; e percentual de grandes fornecedores sujeitos a monitoramento.
126

O processo DS2 tem o objetivo definir polticas e procedimentos relacionados contratao de
servios terceirizados. Ento, o modelo de maturidade deste processo referencia a gesto de
servios de terceiros de acordo com os nveis de maturidade mostrados na Tabela 3.2.
127
Nmero
Nome
DS2.1
Identificao do Relacionamento com Todos os Fornecedores
DS2.2
Gesto do Relacionamento com Fornecedores
DS2.3
Gerenciamento de Riscos do Fornecedor
DS2.4
Monitoramento de Desempenho do Fornecedor
DS3 - Gerenciar o Desempenho e a Capacidade

Descrio Geral: este processo requer que anlise crticas de desempenho e da capacidade dos atuais recursos de TI sejam realizadas com certa frequncia com o objetivo de
gerenciar o desempenho e a capacidades desses recursos. A realizao da anlise critica
permite identificar as previses de necessidades futuras.
Benefcios: assegura que os recursos de informao que suportam os requisitos do negcio esto sempre disponveis.
Objetivos de TI: otimizar o desempenho da infraestrutura, dos recursos e das capacidades de TI em resposta s necessidades do negcio.
Objetivos de Processo: atender aos requisitos de tempo de resposta dos acordos de
nveis de servios estabelecidos; minimizar os perodo da indisponibilidade dos servios;
e proporcionar melhorias contnuas no desempenho e na capacidade de TI.
Objetivos de Atividade: planejar a capacidade de e disponibilidade dos sistemas; monitorar e informar o desempenho dos sistemas; modelar e prever o desempenho dos sistemas.
Mtricas Chaves: quantidade de horas perdidas pelo usurio por ms devido ao planejamento insuficiente da capacidade; percentual de picos onde a utilizao desejada
excedida; percentual de tempo de resposta em que os SLAs no so alcanadas.
128

O processo DS3 tem o objetivo gerenciar o desempenho e capacidade dos recursos de TI. Ento, o modelo de maturidade deste processo referencia planos de capacidade e desempenho e
ferramentas de acordo com os nveis de maturidade mostrados na Tabela 3.2.
129
Nmero
Nome
DS3.1
Desempenho e Planejamento de Capacidade
DS3.2
Capacidade e Desempenho Atuais
DS3.3
Capacidade e Desempenho Futuros
DS3.4
Disponibilidade de Recursos de TI
DS3.5
Monitoramento e Relatrios
DS4 - Assegurar a Continuidade dos Servios

Descrio Geral: este processo visa prover a continuidade dos servios de TI essenciais
para o negcio no caso de interrupes dos servios de TI. Para que isso seja possvel:
um plano de continuidade de TI deve ser desenvolvido, mantido e testado; backups em
instalaes remotas; e treinamentos peridicos.
Benefcios: minimiza a probabilidade e o impacto de uma interrupo de um servio
chave de TI nos processos crticos de negcio.
Objetivos de TI: garantir um mnimo de impacto nos negcios no caso de interrupo
dos servios de TI.
Objetivos de Processo: desenvolver, manter e testar o plano de continuidade; elaborar
solues automatizadas para facilitar a capacidade de recuperao dos servios.
Objetivos de Atividade: desenvolver, manter e melhorar a contingncia de TI; treinar e
testar os planos de contingncia de TI; realizar backups em instalaes remotas.
Mtricas Chaves: quantidade de horas perdidas por usurios por ms devido inoperncia no planejada de sistemas; quantidade de processos crticos de negcio dependentes
da TI e no contemplados no plano de continuidade de TI.
130

O processo DS4 tem o objetivo de assegurar a continuidade dos servios de TI. Ento, o modelo de maturidade deste processo referencia as responsabilidades, planos de continuidade e
padres para garantir a continuidade dos servios de acordo com os nveis de maturidade
131
Nmero
Nome
DS4.1
Estrutura de Continuidade
DS4.2
Planos de Continuidade de TI
DS4.3
Recursos Crticos de TI
DS4.4
Manuteno do Plano de Continuidade de TI
DS4.5
Teste do Plano de Continuidade de TI
DS4.6
Treinamento do Plano de Continuidade de TI
DS4.7
Distribuio do Plano de Continuidade
DS4.8
Recuperao e Retomada dos Servios de TI
DS4.9
Armazenamento de Cpias de Segurana em Locais Remotos
DS4.10
Reviso Ps-Retomada dos Servios
DS5 - Garantir a Segurana dos Sistemas

Descrio Geral: este processo requer a implementao de uma gesto de segurana
com objetivo de manter a integridade da informao e proteger os ativos de TI. Nesta
gesto, deve-se estabelecer papis, responsabilidades, polticas, padres e procedimentos
de segurana de TI, bem como, monitorar, realizar testes peridicos e implantar aes
corretivas das deficincias ou dos incidentes de segurana.
Benefcios: protege todos os ativos de TI; e minimiza o impacto sobre os negcios de
vulnerabilidades e incidentes de segurana.
Objetivos de TI: manter a integridade da infraestrutura de informao e de processamento; minimizar o impacto de vulnerabilidades e incidentes de segurana.
Objetivos de Processo: definir padres, polticas e padres de segurana de TI; e monitorar, detectar, reportar e solucionar vulnerabilidades e incidentes de segurana.
Objetivos de Atividade: entender os requisitos, vulnerabilidades e ameaas de segurana; padronizar o gerenciamento das entidades e autorizao de usurios; realizar
testes peridicos de segurana.
Mtricas Chaves: quantidade de incidentes que prejudicam a reputao pblica da organizao; quantidade de sistemas onde os requisitos de segurana no so atendidos; e
quantidade de violaes na segregao de funes.
132

O processo DS5 tem o objetivo garantir a segurana de TI. Ento, o modelo de maturidade
deste processo referencia as polticas, as responsabilidades e procedimentos de segurana de
133
Nmero
Nome
DS5.1
Gesto da Segurana de TI
DS5.2
Plano de Segurana de TI
DS5.3
Gesto de Identidade
DS5.4
Gesto de Contas de Usurio
DS5.5
Teste de Segurana, Vigilncia e Monitoramento
DS5.6
Definio de Incidente de Segurana
DS5.7
Proteo da Tecnologia de Segurana
DS5.8
Gesto de Chave Criptogrfica
DS5.9
Preveno, Deteco e Correo de Software Malicioso
DS5.10
Segurana de Rede
DS5.11
Comunicao de Dados Confidenciais
DS6 - Identificar e Alocar Custos

Descrio Geral: este processo requer a construo e a operao de um sistema para
capturar, alocar e reportar os custos de TI aos usurios dos servios a fim de que a organizao tome decises mais embasadas sobre o uso dos servios.
Benefcios: permite a empresa tomar decises mais embasadas sobre o uso dos servios.
Objetivos de TI: prover entendimento e transparncia dos custos de TI; melhorar a relao custo-benefcio por meio de informaes sobre os servios de TI.
Objetivos de Processo: coletar os custos de TI; utilizar um sistema de alocao com
aceitao pelos usurios de negcio; utilizar um sistema de reporte do uso da TI e dos
custos alocados.
Objetivos de Atividade: alinhar os valores cobrados qualidade e quantidade de servios
oferecidos; construir um modelo de custo completo; e implementar um sistema de cobrana de valores conforme poltica acordada.
Mtricas Chaves: percentual de faturas de servios de TI aceitas/pagas pelo gestor de
negcio; percentual de variao entre oramentos, previses e custos reais; e percentual
dos custos gerais de TI que so alocados de acordo com os modelos de custo combinados.
134

O processo DS6 tem o objetivo de mapear e controlar os custos de TI. Ento, o modelo de
maturidade deste processo referencia a identificao, alocao e a gesto de custos de acordo
135
Nmero
Nome
DS6.1
Definio de Servios
DS6.2
Contabilidade de TI
DS6.3
Modelagem de Custo e Cobrana
DS6.4
Manuteno do Modelo de Custo
DS7 - Educar e Treinar os Usurios

Descrio Geral: neste processo definido e executado uma estratgia eficaz de treinamento e medio de resultados em cima das necessidades identificadas de treinamento
dos usurios finais e da prpria equipe de TI.
Benefcios: aumenta o uso efetivo da tecnologia por meio da reduo dos erros de
usurio; e aumento da produtividade e aumento da conformidade com os controles principais.
Objetivos de TI: conformidade do usurio com as polticas e procedimentos; e utilizao
efetiva e eficiente das aplicaes e solues.
Objetivos de Processo: identificar as necessidades de treinamento em TI; executar uma
estratgia de treinamento e medio de resultados.
Objetivos de Atividade: estabelecer uma grade de treinamento; organizar e disponibilizar treinamento; monitorar a eficcia do treinamento.
Mtricas Chaves: quantidade de chamadas ao centro de atendimento devido falta
de treinamento dos usurios; percentual de partes interessadas satisfeitas com o treinamento recebido; e tempo entre a identificao da necessidade de treinamento e a realizao do mesmo.
136

O processo DS7 tem o objetivo de definir programas de ensino e treinamentos. Ento, o modelo
de maturidade deste processo referencia um programa de ensino e treinamento de acordo com
137
Nmero
Nome
DS7.1
Identificao das Necessidades de Ensino e Treinamento
DS7.2
Entrega de Treinamento e Ensino
DS7.3
Avaliao do Treinamento Recebido
DS8 - Gerenciar a Central de Servio e os Incidentes

Descrio Geral: este processo requer a implantao de uma central de servios para
atendimento a dvidas e problemas de usurios de TI, tratamento de incidentes, registro,
encaminhamento, anlise de tendncia, anlise de causa-raiz e resoluo.
Benefcios: resposta efetiva e em tempo adequado a dvidas e problemas dos usurios
de TI; aumento de produtividade por meio de resoluo rpida dos chamados dos usurios;
e as reas de negcio podem tratar as causas-raiz com base nos relatrios.
Objetivos de TI: permitir a utilizao eficaz dos sistemas de TI por meio de solicitaes,
incidentes e anlise e resoluo.
Objetivos de Processo: prover uma central de servios profissional que garanta respostas rpidas, procedimentos de escalonamento, resoluo e anlise de tendncia.
Objetivos de Atividade: instalar e operar uma central de servios; monitorar e registrar
incidentes; e definir critrios e procedimentos de escalonamento.
Mtricas Chaves: satisfao do usurio com o primeiro nvel de atendimento; percentual
de incidentes resolvidos no tempo estipulado/aceitvel; e ndice de desistncia dos chamados.
138

O processo DS8 tem o objetivo de definir uma central de servios e gerenciar os incidentes.
Ento, o modelo de maturidade deste processo referencia a central de servios e a gesto de
incidentes de acordo com os nveis de maturidade mostrados na Tabela 3.2.
139
Nmero
Nome
DS8.1
Central de Servio
DS8.2
Registro dos Chamados dos Clientes
DS8.3
Escalonamento de Incidentes
DS8.4
Encerramento de Incidente
DS8.5
Relatrios e Anlises de Tendncias
DS9 - Gerenciar a Configurao

Descrio Geral: este processo requer o estabelecimento e manuteno de um repositrio
de configurao preciso e completo para assegurar a integridade das configuraes de
hardware e software na organizao.
Benefcios: facilita uma maior disponibilidade dos sistemas; minimiza as questes de
produo e soluciona problemas com mais rapidez.
Objetivos de TI: otimizar a infraestrutura, os recursos e as capacidades de TI e responder
pelos ativos de TI.
Objetivos de Processo: estabelecer e manter um repositrio com atributos e perfis mnimos dos ativos de TI; e comparar o repositrio com a configurao atual dos ativos.
Objetivos de Atividade: identificar e manter os itens de configurao; estabelecer um
repositrio central dos itens de configurao; revisar a integridade dos dados nesse repositrio.
Mtricas Chaves: quantidade de problemas de conformidade de negcio causados pela
configurao imprpria dos recursos; quantidade de desvios identificados entre o repositrio
de configurao e as configuraes reais dos ativos; e percentual de licenas adquiridas
e no contabilizadas no repositrio.
140

O processo DS9 tem objetivo de gerenciar a configurao de infraestrutura de TI . Ento, o
modelo de maturidade deste processo referencia o controle da configurao de TI de acordo
141
Nmero
Nome
DS9.1
Repositrio de Configurao e Perfis Bsicos
DS9.2
Identificao e Manuteno dos Itens de Configurao
DS9.3
Reviso da Integridade de Configurao
DS10 - Gerenciar Problemas

Descrio Geral: este processo requer uma efetiva gesto de problemas que identifique e
classifique o problema, anlise as causas-raiz, prove solues, identifica a recomendao
de melhorias, realiza a manuteno dos registros de problemas e revisa a situao das
aes corretivas.
Benefcios: melhora os nveis de servio; reduz os custos; e aumenta a convenincia e a
satisfao do cliente.
Objetivos de TI: reduzir a entrega de servios e solues com problemas e retrabalhos; e
garantir a satisfao dos usurios finais.
Objetivos de Processo: registrar, rastrear e resolver problemas; investigar a causa-raiz
de todos os problemas importantes; e definir solues para os problemas identificados.
Objetivos de Atividade: analisar a causa-raiz do problema reportado; analisar tendncias; e monitorar o progresso da resoluo.
Mtricas Chaves: quantidade de problemas recorrentes com impacto sobre os negcios;
percentual de problemas resolvidos dentro do perodo de tempo requerido; e frequncia
dos reportes ou atualizaes de problemas existentes com base na gravidade do problema.
142

O processo DS10 tem o objetivo de gerenciar os problemas relacionados a TI. Ento, o modelo
de maturidade deste processo referencia a gesto de problemas de acordo com os nveis de
maturidade mostrados na Tabela 3.2.
143
Nmero
Nome
DS10.1
Identificar e Classificar os Problemas
DS10.2
Rastreamento e Resoluo de Problemas
DS10.3
Encerramento do Problema
DS10.4
Integrao de Gerenciamento de Mudanas, Configurao e Problemas

DS11 - Gerenciar os Dados

Descrio Geral: este processo requer uma gesto dos dados que identifique os requisitos de dados, estabelea procedimentos efetivos para controlar mdia, backups, recuperao de dados e dispensa de mdias.
Benefcios: assegurar a qualidade, a rapidez e disponibilidade dos dados de negcio.
Objetivos de TI: otimizar o uso da informao; e garantir que a informao esteja disponvel
quando solicitada.
Objetivos de Processo: manter a preciso, disponibilidade, proteo e completude dos
dados.
Objetivos de Atividade: realizar backups dos dados e testes de recuperao; gerenciar
o armazenamento local e remoto dos sites; descartar de forma segura os dados e equipamentos.
Mtricas Chaves: satisfao do usurio com a disponibilidade dos dados; percentual de
restauraes de dados bem-sucedidas; e volume de incidentes nos quais dados confidenciais foram recuperados com sucesso aps descarte da mdia.
144

O processo DS11 tem o objetivo gerenciar os dados de toda a organizao. Ento, o modelo de
maturidade deste processo referencia a gesto de dados de acordo com os nveis de maturidade
145
Nmero
Nome
DS11.1
Requisitos de Negcio para o Gerenciamento de Dados
DS11.2
Arranjos de Armazenamento e Reteno
DS11.3
Sistema de Gerenciamento de Biblioteca de Mdia
DS11.4
Descarte de Dados e Equipamentos
DS11.5
Backup e Restaurao
DS11.6
Requisitos de Segurana para o Gerenciamento de Dados
DS12 - Gerenciar o Ambiente Fsico

Descrio Geral: neste processo so definidos requisitos do local fsico, instalaes apropriadas, questes acessos fsicos e monitoramento dos fatores ambientes a fim de prover
instalaes fsicas planejadas e gerenciadas para a proteo de pessoas e dos equipamentos.
Benefcios: reduz as interrupes nos negcios provocadas por danos causados a equipamentos ou pessoas.
Objetivos de TI: minimizar os riscos de interrupo de negcio; proteger os ativos de TI
e os dados.
Objetivos de Processo: prover e manter um ambiente fsico adequado para proteo dos
recursos de TI contra acessos indevidos, roubos e danos.
Objetivos de Atividade: implementar medidas de segurana fsica; e selecionar e gerenciar as instalaes fsicas.
Mtricas Chaves: tempo de indisponibilidade devido a incidentes no ambiente fsico;
quantidade de incidentes causados por falhas ou violao da segurana fsica; e frequncia das avaliaes e revises de riscos fsicos.
146

O processo DS12 tem o objetivo controlar e monitorar o ambiente computacional. Ento, o
modelo de maturidade deste processo referencia um ambiente computacional controlado de
147
Nmero
Nome
DS12.1
Seleo do Local e Layout
DS12.2
Medidas de Segurana Fsica
DS12.3
Acesso Fsico
DS12.4
Proteo contra Fatores Ambientais
DS12.5
Gerenciamento de Instalaes Fsicas
DS13 - Gerenciar as Operaes

Descrio Geral: este processo requer a definio de polticas e procedimentos de operaes para a gerncia eficaz de processamentos agendados, proteo de resultados sigilosos, monitoramento de infraestrutura e manuteno preventiva de hardware.
Benefcios: ajuda a manter a integridade dos dados; e reduzir atrasos e custos de operao de TI.
Objetivos de TI: manter a integridade dos dados; garantir que a infraestrutura de TI
possa resistir e se recuperar de falhas e erros.
Objetivos de Processo: monitorar e manter a infraestrutura de TI; proteger a sada de
dados crticos; atingir nveis de servios para processamento programado dos dados.
Objetivos de Atividade: manter a infraestrutura de TI; e alinhar o ambiente de TI com
os acordos de nveis de servio e instrues definidas;
Mtricas Chaves: quantidade de nveis de servio impactados por incidentes operacionais; quantidade de horas de paradas no programadas causadas por incidentes operacionais; percentual de ativos de hardware includos na programao de manuteno
preventiva.
148

O processo DS13 tem o objetivo de estruturar as as atividades de operao de TI. Ento, o
modelo de maturidade deste processo referencia a gesto de operaes de TI de acordo com os
149
Nmero
Nome
DS13.1
Procedimentos e Instrues de Operaes
DS13.2
Agendamento de Jobs
DS13.3
Monitoramento da Infraestrutura de TI
DS13.4
Documentos Confidenciais e Dispositivos de Sada
DS13.5
Manuteno Preventiva de Hardware
3.9.4
Monitorar e Avaliar
ME1 - Monitorar e Avaliar o Desempenho de TI

Descrio Geral: este processo requer a definio e monitoramento de indicadores de
desempenho relevantes, informes de desempenhos e aes para os desvios encontrados.
Benefcios: assegura que as atividades esto sendo feitas corretamente; e as atividades
esto alinhadas com as polticas e diretrizes estabelecidas.
Objetivos de TI: entender e ser transparente nos custos, benefcios, estratgias, polticas
de nveis de servios de TI em conformidade com os requisitos de Governana.
Objetivos de Processo: monitorar e entregar relatrios sobre mtricas dos processos de
TI; e identificar e implementar aes de melhoria de desempenho.
Objetivos de Atividade: agrupar e traduzir os relatrios de desempenho dos processos
para relatrios gerenciais; e realizar anlises crticas de desempenho de acordo com as
metas acordadas; e adotar aes corretivas necessrias.
Mtricas Chaves: satisfao da Alta Direo e das entidades de governana com os relatrios de desempenho; quantidade de aes de melhoria resultantes das atividades de
monitoramento; e percentual de processos crticos monitorados.
Os objetivos de controle do processo ME1 so mostrados na Tabela 3.34.
150

processo ME1. Fonte: ISACA.
O processo ME1 tem o objetivo de definir um processo de monitoramento. Ento, o modelo de
maturidade deste processo referencia o monitoramento do desempenho de TI de acordo com
151
Nmero
Nome
ME1.1
Abordagem de Monitoramento
ME1.2
Definio e Coleta dos Dados de Monitoramento
ME1.3
Mtodo de Monitoramento
ME1.4
Avaliao de Desempenho
ME1.5
Relatrios para a Alta Direo
ME1.6
Aes Corretivas
Tabela 3.34: objetivos de controle detalhados para o processo ME1.
ME2 - Monitorar e Avaliar os Controles Internos

Descrio Geral: este processo monitora os controles internos de TI e reporta as excees
de controle, os resultados de auto-avaliao e avaliao de terceiros.
Benefcios: os controles internos asseguram uma operao eficaz e eficiente e a conformidade com as leis e os regulamentos aplicveis.
Objetivos de TI: assegurar que os objetivos de TI sejam atingidos; e garantir a conformidade com as leis e os regulamentos relacionados TI.
Objetivos de Processo: monitorar os processos de controle interno de atividades de TI;
e identificar aes de melhoria.
Objetivos de Atividade: definir um sistema de controles interno integrados aos processos de TI; monitorar e reportar sobre a eficcia dos controles internos de TI; e reportar
excees de controle internos.
Mtricas Chaves: quantidade de falhas crticas nos controles internos; quantidade de
aes de melhoria nos controles internos; e quantidade e abrangncia das auto-avaliaes
nos controles internos.
152

O processo ME2 tem o objetivo de monitorar e avaliar os controles internos de TI. Ento, o
modelo de maturidade deste processo referencia o monitoramento e a avaliao de controles
internos de TI de acordo com os nveis de maturidade mostrados na Tabela 3.2.
153
Nmero
Nome
ME2.1
Monitoramento da Estrutura de Controles Internos
ME2.2
Reviso Gerencial
ME2.3
Excees aos Controles
ME2.4
Autoavaliao dos Controles
ME2.5
Garantia dos Controles Internos
ME2.6
Controles Internos Aplicados a Terceiros
ME2.7
Aes Corretivas
ME3 - Assegurar a Conformidade com Requisitos Externos

Descrio Geral: este processo requer a identificao e superviso de requisitos em conformidade com leis, regulamentaes e contratos. Alm disso, o processo assegura que
os requisitos so atendidos e integra os relatrios de conformidade de TI com o das rea
de negcio.
Benefcios: aes rpidas aos requisitos externos; e integra os relatrios de conformidade
de TI com o das rea de negcio.
Objetivos de TI: estar em conformidade com leis, regulamentaes e contratos.
Objetivos de Processo: identificar leis, regulamentaes e contratos aplicveis; identificar o nvel necessrio de conformidade de TI; e otimizar os processos de TI para reduzir
riscos de no-conformidade.
Objetivos de Atividade: identificar leis, regulamentaes e contratos relacionados a TI;
avaliar o impacto dos requisitos de conformidade; e monitorar e gerenciar relatrios sobre a conformidade.
Mtricas Chaves: custo da no-conformidade da TI, incluindo multas e penalidades;
intervalo entre a identificao dos problemas de conformidade externa e sua resoluo;
e frequncia das revises de conformidade.
154

O processo ME3 tem o objetivo de assegurar a conformidade com requisitos externos. Ento,
o modelo de maturidade deste processo referencia a conformidade da TI com os requisitos
externos de acordo com os nveis de maturidade mostrados na Tabela 3.2.
155
Nmero
Nome
ME3.2
Identificao dos Requisitos de Conformidade

com Leis, Regulamentaes e Contratos Externos
Otimizao da Resposta aos Requisitos Externos
ME3.3
Avaliao da Conformidade com Requisitos Externos
ME3.4
Assegurar a Conformidade
ME3.5
Informes Integrados
ME3.1
ME4 - Prover Governana de TI

Descrio Geral: este processo define estruturas organizacionais, processos, lideranas,
papis e responsabilidades para assegurar que investimentos em TI estejam alinhados e
sendo entregues em conformidade com as estratgias e objetivos da organizao.
Benefcios: estabelecimento de uma estrutura de governana de TI.
Objetivos de TI: integrar a governana de TI aos objetivos de governana de TI; e ter
conformidade com leis, regulamentaes e contratos.
Objetivos de Processo: preparar relatrios sobre a estratgia, desempenho e riscos da
TI; e atender os requisitos de governana alinhados com as diretrizes da Alta Direo.
Objetivos de Atividade: estabelecer uma estrutura de governana de TI integrada
governana corporativa; e realizar auditoria independente do status da governana de
TI.
Mtricas Chaves: frequncia dos relatrios gerenciais sobre TI para as partes interessadas; frequncia dos relatrios de TI para a Alta Direo; e frequncia das revises independentes da conformidade de TI.
156

O processo ME4 tem o objetivo prover a governana de TI. Ento, o modelo de maturidade
deste processo referencia a estrutura de governana de TI de acordo com os nveis de maturidade mostrados na Tabela 3.2.
157
Nmero
Nome
ME4.1
Estabelecimento de uma Estrutura de Governana de TI
ME4.2
Alinhamento Estratgico
ME4.3
Entrega de Valor
ME4.4
Gerenciamento de Recursos
ME4.5
Gesto de Riscos
ME4.6
Medio de Desempenho
ME4.7
Avaliao Independente
158
Captulo 4. Normas para Qualidade de Software
Captulo 4
Normas para Qualidade de Software

4.1
Conceitos Bsicos
O IEEE (Institute of Electrical and Electronics Engineers) define a qualidade de software de

duas maneiras:
1. O grau em que um determinado sistema, componente ou processo atinge os requisitos
especificados.
2. O grau em que um determinado sistema, componente ou processo atinge as necessidades
e as expectativas do cliente ou do usurio.
Para Pressman, um software de qualidade aquele que apresenta:
Conformidade com os requisitos funcionais e de desempenho explicitamente definidos,
padres de desenvolvimento explicitamente documentados, e caractersticas implcitas
que so esperadas de qualquer software desenvolvido profissionalmente.
J um Processo de Software um conjunto coerente de atividades, estruturas organizacionais,
procedimentos e artefatos para a concepo, desenvolvimento, disposio e manuteno de
um produto de software.
A necessidade e a evoluo das pesquisas acerca do processo de software surgiu com o reconhecimento de que o desenvolvimento um processo complexo que no se restringe apenas
criao de linguagens de programao e de ferramentas auxiliares.
Alm disso, no lgico definir processos para um projeto sem um arcabouo inicial. Ao
reinventarmos a roda, estaremos gastando um tempo desnecessrio e dificultando a organizao e a comunicao, que so fatores primordiais para o sucesso dos empreendimentos. Sendo
assim, desejvel estabelecer um conjunto de processos padro em uma organizao e utilizlo em situaes adequadas.
Idealmente, os elementos de um processo de software devem seguir normas e modelos de
qualidade. O primeiro passo para definirmos um processo de qualidade de software escolhermos o seu ciclo de vida, tambm conhecido como Modelo de Processo. Nesse passo, as
macro atividades bsicas so construdas e organizadas atravs de relaes de precedncia e
dependncia entre elas.
159

Cada processo define um conjunto de atividades que devem ser conduzidas no projeto. Por
exemplo: anlise de requisitos, projeto, codificao, teste, instalao, recursos (pessoas, software, hardware) etc. Essas atividades principais so subdivididas em diversas outras e podem
se comunicar e operar sobre artefatos de entrada para a produo de artefatos de sada.
O processo de software deve ser adequado ao domnio de aplicao em que ser utilizado.
Ou seja, o processo escolhido deve ser ajustado para atender s especificidades do projeto, tais
como a tecnologia de construo, rea de aplicao, equipe de desenvolvedores e usurios finais.
Uma das principais maneiras de produzirmos um software de qualidade atravs de um
processo de software de qualidade. Falando mais claramente: a qualidade de um sistema
ou produto altamente influenciada pela qualidade do processo utilizado para desenvolv-lo
e mant-lo. Para que uma organizao tenha sua qualidade reconhecida, ela deve respeitar
padres de qualidade definidos pela comunidade de software.
As principais normas e modelos de software que vamos discutir neste Captulo so:
ISO 9000
ISO/IEC 12207
ISO/IEC 15504
CMMI
MPS.BR
4.2
4.2.1
Normas da ISO
ISO 9000:2000
As normas publicadas pela Organizao Internacional de Normalizao (International Organization for Standardization), a ISO, tm uma grande aceitao no mercado. Um exemplo
disso a norma ISO 9001:2000, que trata da Gesto da Qualidade, considerada como a mais
difundida norma de qualidade do mundo.
As normas da famlia NBR ISO 9000:2000 foram desenvolvidas para apoiar organizaes de
todos os tipos e tamanhos, no somente as de software, nas atividades de implementao e na
operao de sistemas de gesto da qualidade.
A norma ISO 9000 apresenta a plataforma bsica dos sistemas de gesto da qualidade que
constituem o objeto da famlia NBR ISO 9000.
A famlia NBR ISO 9000 composta de uma srie de normas, sendo a ISO 9001 a mais completa, abrangendo todo o ciclo de vida de um produto ou servio, cobrindo os requisitos para
a garantia da qualidade em projetos, desenvolvimento, produo, instalao e servios associados.
Os princpios bsicos da famlia ISO 9000:2000 baseada na experincia de vrias organizaes e so listadas abaixo:
160

1. Foco no cliente: necessrio atender as necessidades atuais e futuras dos clientes, inclusive, excedendo suas expectativas, visto que eles so o motivo da existncia da organizao.
2. Liderana: Os lderes estabelecem o rumo da organizao. Para os lderes, fica a responsabilidade de envolver pessoas em um propsito comum.
3. Envolvimento de pessoas: Pessoas de todos os nveis so a essncia de uma organizao.
Seu envolvimento possibilita o aproveitamento de suas habilidades por toda a organizao.
4. Abordagem de processo: O gerenciamento de atividades e recursos em forma de processos a maneira mais eficiente de alcanar um resultado desejado.
5. Abordagem sistmica para a gesto: Identificar, entender e gerenciar os processos interrelacionados como um sistema, contribui para a eficcia e eficincia da organizao no
sentido desta atingir os seus objetivos.
6. Melhoria contnua: O objetivo permanente de uma organizao a melhoria contnua
de seu desempenho global.
7. Abordagem factual para tomada de deciso: Decises eficazes so baseadas na anlise
de dados e informaes.
8. Benefcios mtuos nas relaes com os fornecedores: A organizao e os seus fornecedores so interdependentes. Uma relao de benefcios mtuos aumenta a capacidade
de ambos em agregar valor.
4.2.2
ISO 9001:2000
O sistema de gesto da qualidade de uma empresa deve possuir um conjunto de diretrizes que
permite aos clientes avaliarem a capacidade da organizao em fornecer produtos e servios,
que atendam aos requisitos especificados de forma consistente, fornecendo ainda uma estrutura para melhoria contnua do desempenho da organizao. A ISO 9001 define o padro no
s para sistemas de gesto da qualidade, mas para sistemas de gesto em geral. Ela a norma
de qualidade mais difundida, sendo utilizada, atualmente, por mais de 750 mil organizaes
em 161 pases.
A ISO 9001 adequada para qualquer organizao independente do seu porte ou setor. Entretanto, as companhias que esto preparadas para implement-la em toda a organizao, ao
invs de faz-lo em localidades especficas, tendem a conseguir resultados mais eficientes.
A norma ISO 9001:2000 exige a elaborao de seis procedimentos: Controle de Documentos, Controle de Registros, Auditoria Interna, Controle da No-Conformidade de Produtos,
Ao Corretiva e Ao Preventiva.
A existncia de procedimentos, instrues e registros de trabalho formalizam todas as atividades que afetam a qualidade. Isso exige a participao de todos os indivduos da organizao, aumentando o comprometimento com a qualidade, uma vez que todos participam diretamente da implementao do sistema da qualidade. A Figura 4.1 uma representao grfica
da norma ISO 9001:2000.
161
Figura 4.1: representao grfica da norma ISO 9001:2000.
4.2.3
ISO/IEC 12207
Na dcada de 90, houve uma grande preocupao com modelagem e melhorias no processo
de software. Para tratar o tema, entre as iniciativas abordadas, foi criada a norma internacional
ISO/IEC 12207 Tecnologia da Informao Processos de Ciclo de Vida de Software, que
foi publicada em agosto de 1995. A verso brasileira foi encaminhada para votao na ABNT
em junho de 1997 e publicada em 1998.
A norma ISO/IEC 12207 possui o objetivo de fornecer uma estrutura nica para ser executada
durante os processos de aquisio, fornecimento, operao, desenvolvimento e manuteno
de software, utilizando uma linguagem comum.
Essa estrutura nica serve como referncia no desenvolvimento de produtos e servios de
software, abordando a sistematizao e a gesto dos processos de apoio ao ciclo de vida do
software. No entanto, os seguintes elementos ficam fora do escopo da norma: detalhes de
implementao, detalhes de documentao, definio do modelo de ciclo de vida e o mtodo
de desenvolvimento de software. Alm disso, a norma internacional ISO/IEC 12207 no
passvel de certificao, funcionando apenas como um referencial de mercado.
O pblico alvo da norma so compradores, fornecedores, operadores, desenvolvedores, mantenedores, gerentes, profissionais de qualidade e usurios. Entre as suas aplicaes esto:
Aquisio de sistemas e produtos ou servios de software;
fornecimento, desenvolvimento, operao e manuteno de software;
relaes contratuais entre as partes envolvidas em um projeto de software.
A arquitetura da norma ISO/IEC 12207 composta por processos, atividades e tarefas. Possui
a vantagem de ser flexvel, modular e adaptvel s necessidades da organizao que deseja
162

utiliz-la. Basicamente, so dois os princpios bsicos da norma:
Modularidade: Ciclo de vida dividido em vrios mdulos bem definidos. Processos com
mxima coeso.
Responsabilidade: Um responsvel nico por cada processo.
A norma organiza os processos do ciclo de vida de software em trs classes:
Processos Principais;
Processos de Suporte;
Processos Organizacionais.
Nos processos principais esto enquadrados os clientes, fornecedores, operadores, utilizadores
e a equipe de desenvolvimento. J a equipe de suporte est inserida nos processos de suporte
e organizacionais.
Os Processos Primrios do ciclo de vida do software so os seguintes:
1. Processo de Aquisio: define as atividades de aquisio da organizao;
2. Processo de Fornecimento: define as atividades do fornecedor da organizao;
3. Processo de Desenvolvimento: define as atividades da equipe de desenvolvimento da
organizao;
4. Processo de Operao: define as atividades de operao da organizao (isto , atividades de quem vai operar os sistemas);
5. Processo de Manuteno: define as atividades de manuteno do software da organizao (isto , gerir as modificaes do produto de software para mant-lo atualizado e
operacional).
Os processos de suporte tm como objetivo auxiliar outros processos, visando principalmente
a qualidade e o sucesso do projeto. So eles:
1. Processo de Documentao: define as atividades para registrar a informao produzida
por um processo do ciclo de vida;
2. Processo de Gesto de Configuraes: define as atividades de gesto de configurao;
3. Processo de Garantia da Qualidade: define as atividades para assegurar de forma objetiva que os produtos e os processos de software; esto conforme com os requisitos especificados e conforme o planeado. As revises conjuntas, as auditorias, a verificao, e
a validao podem ser usadas como tcnicas da garantia de qualidade;
4. Processo de Verificao: define as atividades (para o cliente, o fornecedor, ou parte interessada) para verificar os produtos de software;
5. Processo de Validao: define as atividades (para o cliente, o fornecedor, ou parte interessada) para validar os produtos de software;
163

6. Processo de Reviso: define as atividades para avaliar o estado e os produtos de uma
atividade;
7. Processo de Auditoria: define as atividades para determinar a conformidade com os
requisitos, planejamento e contrato;
8. Processo de Resoluo de problemas: define um processo para analisar e resolver problemas (incluindo no conformidades), qualquer que seja a sua natureza ou fonte detectadas no decorrer do desenvolvimento, operao, manuteno ou outro processo.
Os processos organizacionais tm como objetivo garantir e melhorar os processos dentro da
organizao. So eles:
1. Processo de Gesto: define as atividades bsicas de gesto, incluindo a gesto de projeto,
durante o ciclo de vida.
2. Processo de Infraestrutura: define as atividades bsicas para estabelecer a infraestrutura.
3. Processo de Melhoria: define as atividades bsicas ao desempenho da organizao (quer
seja cliente, fornecedor, equipas de desenvolvimento e manuteno, ou gestor de outro
processo) para estabelecer a medio, controle e melhoria do ciclo de vida.
4. Processo de Formao: define as atividades para proporcionar a formao adequada aos
colaboradores.
Figura 4.2: representao grfica da norma ISO 12207.
164
4.2.4
ISO/IEC 15504 (SPICE)
Em 1993, a ISO (International Organization for Standardization) realizou um estudo sobre

as necessidades e os requisitos de um padro internacional para avaliao de processos de
software. Como resultado do estudo, resolveram criar o projeto SPICE (Software Process Improvement and Capability Determination). SPICE era, basicamente, uma equipe responsvel
pelo desenvolvimento das verses iniciais da nova norma e por coordenar a sua utilizao na
comunidade. O projeto se desdobrou conforme abaixo.
1993: estudo da ISO sobre as necessidades e os requisitos de um padro internacional
para avaliao de processos de Software;
1993-1994: criao do projeto SPICE e elaborao da verso inicial; Realizao de trials
Fase 1 (35 avaliaes);
1996: verso PDTR (Previous Draft Technical Report);
1997: verso DTR (Draft Technical Report), Trials Fase 2 (70 avaliaes);
1998: verso TR (Technical Report), denominada de ISO/IEC TR 15504: Information Technology Software Process Assessment;
1999-2005: transformao em norma ISO/IEC 15504;
2003: iniciada a publicao como norma, denominada de ISO/IEC 15504: Information
Technology - Process Assessment. Publicao da parte 2;
2004: publicao das partes 1, 3 e 4;
2006: publicao da parte 5;
2008: publicao da parte 6.
ISO/IEC 15504, Information Technology Software Process Assessment, em portugus: Tecnologia de Informao Avaliao de Processo de Software, um padro para avaliao de
processos de software relativo aquisio, desenvolvimento, suporte e outros. Na prtica,
utilizado como Modelo de Referncia para Melhoria de Processo. O padro tem a influncia
do SW-CMM, o precursor do CMMI, adotando os seus Nveis de Capacidade. Alm disso,
fortemente alinhado com a norma ISO/IEC 12207. Esta ltima fornece um enquadramento
geral dos processos do ciclo de vida de software mas est limitada para as necessidades
especficas e no inclui o detalhe necessrio para uma avaliao de processos.
A composio do padro ISO/IEC 15504 a seguinte:
15504-1 - Conceitos e Vocabulrio (Concepts and Vocabulary): Prov uma introduo
geral aos conceitos de avaliao de processos e um glossrio de termos relacionados
avaliao.
15504-2 - Executando uma Avaliao (Performing an Assessment): Define os requisitos mnimos para a realizao de uma avaliao. Alm disso, define um arcabouo de
medio para avaliar a capacidade do processo. Essa infra-estrutura define nove atributos de processo, agrupados em seis nveis de capacidade.
165

15504-3 - Guia sobre Executando uma Avaliao (Guidance on performing an assessment): Guia para a realizao de avaliaes (informativa): prov orientaes para interpretar os requisitos para a realizao de uma avaliao.
15504-4 - Guia sobre Utilizao do Resultado de Avaliao (Guidance on using assessment results): Identifica a avaliao de processo como uma atividade que pode ser realizada tanto como parte de uma iniciativa de melhoria de processo quanto parte de uma
abordagem de determinao da capacidade.
15504-5 - Um Exemplo de Modelo de Avaliao de Processo (An exemplar process assessment model): Um exemplo de modelo de avaliao de processo baseado na ISO/IEC
12207 e suas emendas 1 e 2 (informativas).
15504-6 - Um Exemplo de Modelo de Avaliao de Processo de Ciclo de Vida de Sistema: Um exemplo de modelo de avaliao que baseado no modelo de processo definido
na ISO/IEC 15288, que uma norma parecida com a ISO/IEC 12207, mas cujo foco descrever processos no nvel de sistemas (ISO/IEC 12207 possui foco no nvel de software).
Figura 4.3: as influncias do padro ISO/IEC 15504.

Note que apenas as partes 1 e 2 so normativas, as restantes so orientadoras. A parte 5
a parte que desperta maior interesse de quem est definindo um processo de software, pois
oferece um modelo de referncia disposto a guiar a definio de um processo de software de
qualidade.
Um Modelo de Referncia de Processo define um conjunto de processos que representam
melhores prticas de um determinado domnio. Um exemplo de um modelo de referncia de
processo a a norma ISO/IEC 12207.
Um Modelo para Avaliao de Processo deve ser baseado em um Modelo de Referncia de
Processo, e detalhar os processos (todos ou alguns) de forma a viabilizar uma avaliao de processo e tambm detalhar a estrutura de medio. Alguns exemplos so: CMMI, ISO 15504-5,
OOSpice e MR-MPS (Modelo de referncia para melhoria do processo de software).
166

Um mtodo de avaliao de processo para ser conforme com a ISO/IEC 15504, deve satisfazer
trs requisitos bsicos:
ser verificada por um avaliador competente;
ter como referncia um modelo de avaliao de processo compatvel (ex. 15504-5);
ser realizada seguindo um processo compatvel.
Alguns exemplos de mtodos de avaliao de processo so QuickLocus, SCAMPI e MA-MPS.
O QuickLocus um mtodo de avaliao do processo de desenvolvimento de software destinado a pequenas e mdias empresas, que no tm recursos para custear os caros processos de
avaliao e certificao existentes no mercado. SCAMPI (Standard CMMI Appraisal Method for
Process Improvement) um dos produtos do projeto CMMI e um mtodo de avaliao com
objetivo de determinar o nvel de aderncia de um processo, ou conjunto de processos, um
modelo de referncia. MA-MPS (Mtodo de avaliao para melhoria do processo de software)
o mtodo de avaliao utilizado no modelo de qualidade de processo MPS.Br.
Figura 4.4: ISO 15504-2 define os nveis de capacidade e os requisitos para os modelos e mtodos de avaliao.
Os nveis de capacidade do ISO/IEC 15504 so descritos na Figura 4.5 e so baseados nos
nveis de capacidade do SW-CMM.
167
Figura 4.5: os nveis de capacidade da ISO/IEC 15504.

Os Atributos de Processo (APs) avaliados so os seguintes:
Atributo de Desempenho do Processo (AP 1.1): o propsito do processo atingido?
Atributo de Gerncia do Desempenho (AP 2.1): o desempenho do processo gerenciado?
Atributo de Gerncia de Produto de Trabalho (AP 2.2): os produtos de trabalho produzidos pelo processo so adequadamente gerenciados?
Atributo de Definio de Processo (AP 3.1): um processo padro mantido para apoiar
a instanciao (deployment) de processos de projeto?
Atributo de Instanciao de Processo (AP 3.2): o processo padro efetivamente instanciado como um processo de projeto para atingir seus resultados?
Atributo de Medio de Processo (AP 4.1): os resultados de medio so usados para
garantir que o desempenho do processo apoia a obteno de objetivos de desempenho
de processo relevantes no apoio a metas de negcio definidas?
Atributo de Controle de Processo (AP 4.2): o processo quantitativamente gerenciado
para produzir um processo estvel, capaz e previsvel dentro de limites?
Atributo de Inovao de Processo (AP 5.1): as alteraes no processo so identificadas
a partir da anlise de causas comuns de variao no desempenho e a partir de investigaes de abordagens inovadoras para a definio e instanciao do processo?
168

Atributo de Otimizao de Processo (AP 5.2): as alteraes na definio, no gerenciamento e no desempenho do processo resultam em efetivo impacto que atinge os objetivos
de melhoria de processo relevantes?
No processo de avaliao, um valor deve ser atribudo a cada atributo de processo e pode
assumir os seguintes valores:
N: o atributo no foi atingido pelo processo;
P: o atributo foi atingido apenas parcialmente pelo processo;
L: o atributo foi atingido largamente pelo processo;
F: o atributo foi atingido completamente (em ingls, fully) pelo processo.
Para estar em um nvel de capacidade, um processo deve ter notas L ou F nos atributos do
nvel e F em todos os atributos dos nveis anteriores.
A arquitetura do modelo de referncia ISO/IEC 15504 para processos e capacidade de processos composta de duas dimenses:
Dimenso de Processo definida pelos propsitos do processo e cujos resultados indicam o trmino bem sucedido do processo, ou seja, se limita verificao da execuo
ou no dos processos;
Dimenso da Capacidade do Processo a dimenso em que os resultados so utilizados
para o gerenciamento do processo e para a melhoria de sua capacidade. Trabalha com
atributos de processo e nveis de capacidade.
Os processos do ISO/IEC 15504-5, que um exemplo de modelo de avaliao de processo,
podem ser divididos assim:
Processos Primrios ou Fundamentais: categorias de Engenharia de Software e de Relao Cliente-Fornecedor;
Processos Modelo ou de Apoio: agrega atividades de apoio;
Processos Organizacionais: categorias de processos de Gesto e Organizacionais.
A Figura 4.6 apresenta os processos ISO/IEC 15504-5 classificados em suas categorias.
169
Figura 4.6: os processos da ISO/IEC 15504-5.
4.3
4.3.1
CMMI
Histrico e Objetivos do CMMI
Um modelo de maturidade uma coleo bem estruturada de elementos cujo objetivo descrever determinados aspectos da maturidade de uma organizao.
Em 1986, deu-se incio a um modelo de capacitao de processos de software, conhecido como
SW-CMM, desenvolvido pelo SEI (Software Engineering Institute Carnegie Mellon University) e patrocinado pelo Departamento de Defesa Americano (DoD). A verso 1.0 foi publicada em agosto de 1991. E j em fevereiro de 1993, foi publicada a verso 1.1. Este modelo
no contemplava outras reas importantes das organizaes, tais como Recursos Humanos e
Engenharia de Sistemas, pois era especfico para a rea de software.
Desde o incio, o SW-CMM descrevia os princpios e prticas que formam a base da maturidade
do processo de software, tendo por objetivo auxiliar as organizaes de software a melhorar
a maturidade de seus processos em termos de um caminho evolutivo partindo de processos
caticos e eventuais em direo a processos de software maduros e disciplinados. Neste contexto, o SW-CMM no pode ser classificado como uma metodologia, j que indica apenas o que
deve ser efeito para alcanar a maturidade dos processos, sem indicar como efetuar as atividades necessrias para atingir esse intento. Ou seja, ele no descreve processo algum, apenas
orienta.
170

Almejando o sucesso adquirido pelo SW-CMM, outros modelos semelhantes foram criados
para outras reas, tais como Gesto de Recursos Humanos (People-CMM), Aquisio de Software (SACMM) e Engenharia de Sistemas (SE-CMM), S.E. Capability Assessment Model (SECAN)
e EIA 731. Uma vez que os diversos modelos apresentavam estruturas, formatos e termos
diferentes, tornava-se difcil a aplicao conjunta destes modelos por qualquer organizao. A
Figura 4.7 apresenta a relao entre os diversos modelos de maturidade.
Figura 4.7: relao entre os modelos de maturidade.

O CMMI (Capability Maturity Model Integration) foi criado, ento, com a finalidade de integrar os diversos modelos CMM. Em 1999, foi publicado o esboo (draft), verso 0.2: CMMISE/SW (Capability Maturity Model -Integrated System / Software Engineering). As verses
do CMMI so:
Verso 1.0: Agosto de 2000;
Verso 1.1: Maro de 2002;
Verso 1.2: Agosto de 2006 (CMMI for Development);
Verso 1.3: Outubro de 2010.
O objetivo principal do CMMI guiar organizaes a conhecerem e melhorarem seus processos de software. Ele identifica prticas para um processo de software maduro, definindo
as caractersticas de um processo de software efetivo e descreve como as prticas de engenharia de software evoluem sob certas condies. Alm da integrao dos modelos e reduo
dos custos com melhorias de processo, os seguintes objetivos tambm fazem parte do projeto
CMMI:
aumento do foco das atividades;
171

integrao dos processos existentes;
eliminar inconsistncias;
reduzir duplicaes;
fornecer terminologia comum;
assegurar consistncia com a norma ISO/IEC 15504;
flexibilidade e extenso para outras disciplinas.
4.3.2
Conceitos Bsicos de CMMI
Alguns conceitos bsicos devem ser explicados no escopo do CMMI:

rea de Processo AP (Process Area - PA): prticas relacionadas em uma rea que,
quando executadas de forma coletiva, satisfazem um conjunto de metas consideradas
importantes para trazer uma melhoria nessa rea.
Prticas Especficas: atividades que so consideradas importantes na satisfao de uma
meta especfica associada;
Metas Especficas: aplicam-se a uma AP e tratam de caractersticas que descrevem o
que deve ser implementado para satisfazer essa AP. So utilizadas nas avaliaes para
auxiliar a determinar se a AP est sendo satisfeita;
Metas Genricas: so vinculadas aos nveis de capacidade dos processos. Para cada um
desses nveis, h uma meta que determina o que deve atingido para que a rea do Processo merea estar naquele nvel. As metas genricas so aplicveis indistintamente a
todos os processos do modelo.
Prticas Genricas: oferecem uma institucionalizao que assegura que os processos associados com a AP sero eficientes, repetveis e durveis e que a meta genrica associada
seja atingida.
Avaliao Objetiva: significa revisar atividades e produtos de trabalho contra critrios
que minimizem a subjetividade e influncias do revisor. Um exemplo de uma avaliao objetiva uma auditoria contra os requisitos, padres ou procedimentos para uma
funo de garantia da qualidade independente;
Caractersticas Comuns: so atributos pr-definidos que agrupam as prticas genricas
em categorias. As caractersticas comuns so componentes de modelo que no so avaliados de nenhuma forma. Elas so simples agrupamentos que oferecem uma maneira de
apresentar as prticas genricas.
Produtos de Trabalho Tpicos: exemplos de sadas de uma prtica especfica ou genrica.
Subprticas: descries detalhadas que fornecem um direcionamento para a interpretao de prticas especficas ou genricas.
Aos iniciantes, faz-se a necessidade de exemplificar como se d a relao entre uma rea de
Processo (AP) e suas prticas e metas. Na rea de Processo Gerncia de Requisitos, por exemplo, temos a seguinte meta especfica:
172

Gerenciar Requisitos: Requisitos so gerenciados e inconsistncias com planos de projeto e produtos de trabalho so identificados.
Continuando o exemplo, a prtica especfica para a rea de Processo Gerncia de Requisitos
:
Manter rastreabilidade bidirecional entre requisitos: Manter rastreabilidade bidirecional entre requisitos.
Os seus produtos de trabalho tpico so:
Matriz de Rastreabilidade;
Sistema de Acompanhamento de Requisitos.
J a meta genrica, advinda do Nvel 2 de capacidade :
Institucionalizar um processo gerenciado.
Sendo a prtica genrica correspondente meta genrica:
Estabelecer uma poltica organizacional.
A meta especfica, assim como a meta genrica, um componente exigido, ou seja, deve ser
atingida pelos processos planejados e implementados por uma organizao. J o que normalmente uma organizao deve implementar para satisfazer um componente exigido so os
componentes esperados. As prticas especficas e as prticas genricas so exemplos de componentes esperados. Subprticas, produtos de trabalho tpicos, entre outros, so componentes
informativos e fornecem detalhes que auxiliam os usurios do modelo.
O CMMI possui duas formas de representao: uma contnua e outra por estgios. Essas representaes oferecem flexibilidade para as organizaes poderem utilizar diferentes meios para
obterem melhorias de acordo com as suas realidades. A seguir, explicaremos o funcionamento
de cada uma dessas representaes.
4.3.3
Representao Contnua
A representao contnua tem como foco a capacidade do processo e oferece um caminho

flexvel para a implementao de melhorias. Permite que uma organizao escolha reas especficas do processo para implementao de melhorias e implementao de nveis diferentes
de capacidade para diferentes processos.
Na representao contnua, as reas de Processos so organizadas por categorias, so elas:
Gerenciamento de Processos;
Gerenciamento de Projetos;
Engenharia;
Suporte.
possvel classificar o nvel de capacidade de cada processo em seis nveis, de zero a cinco:
173

Nvel 0 Incompleto: um processo parcialmente realizado ou no realizado, e um ou
mais objetivos do processo no esto satisfeitos;
Nvel 1 Realizado (ou Executado): um processo realizado atende todos os objetivos
especficos da rea de processo e produz algum trabalho;
Nvel 2 Gerenciado: um processo gerenciado um processo realizado (nvel 1) que
tambm planejado e executado de acordo com as polticas pr-definidas;
Nvel 3 Definido: um processo definido um processo gerenciado (nvel 2) e ajustado
de acordo com o conjunto de processos da organizao;
Nvel 4 Gerenciado quantitativamente: um processo neste nvel definido e controlado com ajuda de tcnicas estatsticas e quantitativas;
Nvel 5 Otimizado: um processo otimizado gerenciado quantitativamente, alterado
e adaptado para atender os objetivos dos negcios atuais.
Abaixo explicada cada uma das categorias da Representao Contnua.
Gerenciamento de Processos
O Gerenciamento de Processos rene as atividades relativas definio, planejamento, distribuio de recursos, aplicao, implementao, monitoramento, controle, avaliao, medio
e melhoria de processos.
As reas de Processos pertencentes categoria so:
Foco no Processo Organizacional (bsica);
Definio do Processo Organizacional (bsica);
Treinamento Organizacional (bsica);
Desempenho do Processo Organizacional (avanada);
Inovao e Desenvolvimento Organizacional (avanada).
Gerenciamento de Projetos
O Gerenciamento de Projetos rene as atividades de gerncia de projetos relacionadas ao
planejamento, monitoramento e controle do projeto.
Gerncia de Requisitos;
Planejamento de Projetos (bsica);
Monitoramento e Controle de Projetos (bsica);
Gerncia de Acordos com Fornecedores (bsica);
Gerncia Integrada de Projetos (avanada);
Gerncia de Riscos (avanada);
Gerncia Quantitativa de Projetos (avanada).
174

Engenharia
A Engenharia envolve as atividades de desenvolvimento e manuteno que so compartilhadas entre as disciplinas de engenharia (por exemplo, engenharia de sistemas e engenharia
de software).
Desenvolvimento de Requisitos;
Soluo Tcnica;
Integrao de Produtos;
Verificao;
Validao.
Suporte
O Suporte envolve as atividades que apoiam o desenvolvimento e a manuteno de produtos.
Gerncia de Configurao (bsica);
Garantia da Qualidade do Processo e do Produto (bsica);
Medio e Anlise (bsica);
Ambiente Organizacional para Integrao (avanada);
Anlise de Decises e Resolues (avanada);
Anlise de Causas e Resolues (avanada).
4.3.4
Representao em Estgios
A Representao em Estgios, que mais utilizada, tem foco na maturidade da organizao

e prov um caminho evolutivo para a melhoria do processo. As reas de Processos so agrupadas por nvel de maturidade, que devem ser atendidas na sua totalidade para permitir um
estgio definido de melhorias. A representao em estgios possui apenas um tipo de prtica
especfica. Note que a representao contnua tem mais prticas especficas que a representao em estgios, porque tem dois tipos de prticas especficas: as bsicas e as avanadas. A
representao de estgio divide as reas de Processo em cinco nveis de maturidade:
Nvel 1 Inicial: neste nvel, os processos so caticos e informais. A organizao no
possui um ambiente estvel. Apesar deste ambiente informal e catico, organizaes
neste nvel muitas vezes produzem produtos e servios que funcionam; entretanto, frequentemente excedem o oramento e o cronograma de seus projetos;
Nvel 2 Gerenciado: neste nvel, os projetos da organizao asseguraram que os requisitos so gerenciados e que os processos so planejados, executados, medidos e controlados. No nvel 2, uma organizao garante que atingiu todas as metas especficas e
genricas das reas de processos do nvel 2 de maturidade;
175

Nvel 3 - Definido: neste nvel, os processos so bem caracterizados e entendidos e esto
descritos em padres, procedimentos, ferramentas e mtodos. O conjunto de processos
padro da organizao estabelecido e melhorado ao longo do tempo e so usados para
estabelecer a consistncia em toda a organizao. No nvel 3, uma organizao atingiu
todas as metas especficas e genricas das reas de processos definidas para os nveis de
maturidade 2 e 3;
Nvel 4 Gerenciado Qualitativamente: neste nvel, so selecionados os subprocessos
que contribuem significativamente para o desempenho geral do processo. Estes subprocessos selecionados so controlados utilizando estatsticas e outras tcnicas quantitativas.
No nvel 4, uma organizao atingiu todas as metas especficas das reas de processos
atribudas aos nveis de maturidade 2, 3 e 4 e as metas genricas atribudas aos nveis de
maturidade 2 e 3;
Nvel 5 Otimizado: neste nvel, concentra-se no melhoramento contnuo do desempenho de processos atravs de melhorias tecnolgicas incrementais e inovadoras. No
nvel 5, uma organizao atingiu todas as metas especficas das reas de processos atribudas aos nveis de maturidade 2, 3, 4 e 5 e as metas genricas atribudas aos nveis de
maturidade 2 e 3.
Figura 4.8: nveis de maturidade do CMMI.

Acrescentamos que, na representao contnua, as prticas genricas existem para os nveis de
capacitao de 1 a 5, e no para o nvel 0, enquanto que, na representao por estgios, somente
aparecem prticas genricas para os nveis de maturidade 2 e 3.
Na representao em nveis de maturidade, existem quatro caractersticas comuns que organizam as prticas genricas de cada AP:
Compromisso: agrupa as prticas genricas relacionadas criao de polticas e garantia de patrocnio;
Habilitao: agrupa as prticas genricas relacionadas a assegurar que o projeto e/ou
organizao possuem os recursos que necessitam;
176

Implementao: agrupa as prticas genricas relacionadas gerncia do desempenho
do processo, gerncia da integridade de seus produtos de trabalho e envolvimento dos
stakeholders relevantes;
Verificao da Implementao: agrupa as prticas genricas relacionadas s revises
pelo nvel mais alto de gerenciamento e a avaliaes objetivas de conformidade a descries de processos, procedimentos e padres.
As reas de Processos so divididas nos nveis de maturidade da seguinte maneira:
reas de Processos do Nvel 2:
Gerncia de Requisitos;
Planejamento de Projeto;
Monitorao e Controle de Projeto;
Garantia da Qualidade do Processo e do Produto;
Gerncia de Acordo com Fornecedores;
Gerncia de Configurao;
Medio e Anlise.
Gerncia de Projeto Integrada;
Definio do Processo Organizacional;
Foco no Processo Organizacional;
Treinamento Organizacional;
Desenvolvimento de Requisitos;
Soluo Tcnica;
Integrao do Produto;
Verificao;
Validao;
Gerncia de Riscos;
Anlise de Deciso e Resoluo.
Gerncia Quantitativa do Projeto;
Desempenho do Processo Organizacional.
Anlise de Causas e Resoluo
Inovao e Implantao na Organizao
177
4.3.5
Comparao entre as Formas de Representao
A Representao Contnua apresentas as seguintes vantagens:

Foca em reas de processo especficas, aumentando a flexibilidade;
Permite a comparao, no nvel de reas de Processos, entre diferentes organizaes;
Estrutura herdada da comunidade de engenharia de sistemas, facilitando a vida de quem
vem dessa rea;
Permite separar os riscos de cada rea de Processo, fazendo com que a organizao determine seu foco corretamente;
Estrutura compatvel com a ISO/IEC 15504.
Vale salientar que o desenvolvimento de determinadas reas de processos, um determinado
nvel de maturidade pode ser atingido por quem usa a representao contnua, se todas as
reas de processo relevantes para tal nvel tiverem atingido a capacidade mnima para o nvel
de maturidade.
Figura 4.9: na representao contnua, cada rea de processo pode se localizar em um nvel de
capacidade.
Por outro lado, a representao por estgios possui as seguintes vantagens:
Fornece uma rota de implementao por meio de: grupos de rea de processo e implementao em sequncia;
Progride por um caminho pr-definido e comprovado de nveis sucessivos, cada um
servindo de base para o prximo.
Estrutura herdada do SW-CMM, facilitando a vida de quem vem dessa rea;
Habilidade de gerenciar processos ao longo da organizao.
Em uma avaliao, atribui um nvel de maturidade em que a organizao se encontra,
permitindo, assim, comparar organizaes de forma direta.
178
Figura 4.10: na representao por estgios, todas as reas de processos de determinado nvel
de maturidade devem ser satisfeitas.
4.3.6
Constelaes
A partir da verso 1.2, foi criado o conceito de constelaes. Constelao uma coleo de
componentes que inclui modelo, material de treinamento e documentos de avaliao para uma
rea de interesse.
Na verso 1.3, so trs as constelaes: desenvolvimento (CMM for Development); servios
(CMM for Services) e aquisio (CMM for Acquisition). Os componentes includos em uma
determinada constelao dependem do seu propsito.
O CMMI para Desenvolvimento (CMMI-DEV) um modelo de maturidade destinado ao desenvolvimento de produtos e servios, e composto pelas melhores prticas associadas a atividades de desenvolvimento e de manuteno que cobrem o ciclo de vida do produto desde a
concepo at a entrega e manuteno.
Os setores que mais utilizam o CMMI-DEV so os setores de software, bancrio, aeroespacial, hardware de computador, defesa, indstria automobilstica entre outros.
O CMMI para Servios (CMMI-SVC) um modelo de referncia CMMI que cobre as atividades de prestao e gesto de servios de qualquer natureza. Organizaes de setores importantes como sistema financeiro, telecomunicaes, hotelaria so o pblico-alvo do CMMI para
Servios.
O CMMI para Aquisio (CMMI-ACQ) um modelo de referncia CMMI que cobre as atividades de aquisio de desenvolvimento de produtos e de prestao de servios. O modelo
CMMI for Acquisition engloba, alm das prticas comuns, prticas especficas tais como as de
aquisio e de gesto de fornecedores.
O CMMI Model Foundation (CMF) fornece um conjunto consistente de componentes que
deve estar presente em qualquer modelo CMMI. Ou seja, engloba os componentes que esto
envolvidos com as reas de Processos aplicveis em qualquer propsito, seja ele de desenvolvimento, de servios ou de aquisio.
179
Figura 4.11: reas de processos do CMMI for Development v1.3.

As constelaes so ampliaes do CMF e no podem apagar ou modificar qualquer um dos
seus contedos. As constelaes somente adicionam reas de Processos, Metas Especficas,
Prticas Especficas, Subprticas Especficas, Produtos de Trabalho Tpicos, Prticas Genricas
entre outros.
Entretanto, embora haja caractersticas genricas no CMF, algumas reas de processo do ncleo podem ter comportamentos e esperar resultados diferentes dependendo da constelao.
Por exemplo: PP Planejamento de Projetos pode ter uma prtica especfica na constelao de
servios que est ausente na verso de desenvolvimento.
180
Figura 4.12: reas de processos do CMMI for Services v1.3.
181
Figura 4.13: reas de processos do CMMI for Acquisition v1.3.
182
Figura 4.14: relao entre as constelaes e o CMMI Model Foundation.
183
4.4
MPS.Br
Um dos principais problemas para a adeso do CMMI nas empresas brasileiras o alto custo
para a realizao das avaliaes do modelo para obter a certificao. Geralmente o custo fica
entre 200 mil reais e um milho de reais dependendo da complexidade do processo. Alm
disso, para se chegar a um nvel de maturidade mais alto gasta-se em mdia de 4 a 8 anos.
Essas dificuldades contrastam com a realidade das empresas brasileiras.
Devido a essas dificuldades, foi criada uma parceria entre a Softex (Associao para Promoo
da Excelncia do Software Brasileiro), o governo e as universidades. Assim, surgiu o projeto
MPS.Br (melhoria de processo de software brasileiro), que a soluo brasileira compatvel
com o modelo CMMI e em conformidade com as normas ISO/IEC 12207 e 15504, alm de ser
adaptada ao mercado brasileiro.
Embora tenha sido criado com o mesmo propsito que o CMMI, o foco de atuao dos modelos so diferentes. O MPS.Br foi criado em funo das mdias e pequenas empresas, enquanto
o CMMI possui um foco global e mais voltado para as empresas de grande porte.
Abaixo, um breve histrico do desenvolvimento do MPS.Br:
Dezembro de 2003: Incio do programa mobilizador;
Maio de 2005: lanada verso 1.0;
Maio de 2006: lanada verso 1.1;
Junho de 2007: lanada verso 1.2;
Junho de 2009: lanada verso :2009;
Junho de 2011: lanada verso :2011.
O MPS.Br dividido em 3 componentes:
MR-MPS Modelo de referncia para melhoria do processo de software;
MA-MPS Mtodo de avaliao para melhoria do processo de software;
MN-MPS Modelo de negcio para melhoria do processo de software.
Na Figura 4.15, podemos identificar a estrutura do modelo MPS.Br:
O Guia Geral do MPS.Br descreve o Modelo de Referncia para Melhoria do Processo de
Software (MR-MPS) e fornece uma viso geral sobre os demais guias que apoiam os processos
de avaliao e de aquisio.
O Guia de Aquisio do MPS.Br descreve um processo de aquisio de software e servios
correlatos. Apoia organizaes que desejem adquirir produtos e servios possuindo como base
o MR-MPS.
O Guia de Avaliao do MPS.Br descreve o processo e o mtodo de avaliao MA-MPS, os
requisitos para avaliadores lderes, avaliadores adjuntos e Instituies Avaliadoras (IA).
O Guia de Implementao do MPS.Br uma srie de onze documentos que fornecem orientaes para implementar os nveis de maturidade descritos no Modelo de Referncia MR-MPS.
184
Figura 4.15: estrutura do modelo MPS.Br.
4.4.1
MR-MPS
Segundo o Guia Geral do MPS.Br: O modelo de referncia MR-MPS contm os requisitos que
os processos das unidades organizacionais devem atender para estar em conformidade com
o MR-MPS. Ele contm as definies dos nveis de maturidade, processos e atributos do processo. Alm disso, o guia cita que o MR-MPS est em conformidade com os requisitos da
Norma Internacional ISO/IEC 15504-2.
O MPS.Br apresenta sete nveis de maturidade, conforme Figura 4.16, e so eles: A (Em Otimizao), B (Gerenciado Quantitativamente), C (Definido), D (Largamente Definido), E (Parcialmente Definido), F (Gerenciado) e G (Parcialmente Gerenciado).
Para alcanar um nvel de maturidade, necessrio que os atributos dos processos (AP), dos
processos do nvel correspondente, tenham seus resultados esperados atingidos. A possibilidade de se realizar avaliaes com mais nveis permite uma visibilidade dos resultados de
melhoria de processos em prazos mais curtos. A Figura 4.17 apresenta uma comparao entre
os nveis de maturidade do MPS.Br e do CMMI. Em ambos os casos, os nveis so acumulativos, ou seja, se a organizao est no nvel F, ela atende os resultados esperados de todos os
processos dos nveis G e F.
A capacidade do processo expressa o grau de refinamento e institucionalizao com que o
processo executado, ou seja, est relacionada com o atendimento dos atributos associados
aos processos de cada nvel de maturidade. Os diferentes nveis de capacidade dos processos
so descritos por nove Atributos de Processo (APs) em acordo com a ISO/IEC 15504-2, so
eles: AP 1.1 (O processo executado), AP 2.1 (O processo gerenciado), AP 2.2 (Os produtos
de trabalho do processo so gerenciados), AP 3.1 (O processo definido), AP 3.2 (O processo
est implementado), AP 4.1 (O processo medido), AP 4.2 (O processo controlado), AP 5.1
(O processo objeto de melhorias incrementais e inovaes) e AP 5.2 (O processo otimizado
continuamente). Nas Figuras 4.18 e 4.19 so listados os processos e atributos de processos em
cada um dos nveis de maturidade descritos no Guia Geral.
185
Figura 4.16: nveis de maturidade do MPS.Br.
186
Figura 4.17: comparao entre os nveis de maturidade do MPS.Br:2009 e do CMMI for Development 1.2.
187
Figura 4.18: nveis de maturidade A, B, C, D e E do MPS.Br:2011 e seus respectivos processos

e atributos de processo.
Figura 4.19: nveis de maturidade F e G do MPS.Br:2011 e seus respectivos processos e atributos

de processo.
188
4.4.2
MA-MPS
O MA-MPS orienta a realizao de avaliaes, em conformidade com a norma ISO/IEC 15504,

em empresas e organizaes que implementaram o MR-MPS. O objetivo verificar a maturidade da unidade organizacional (UO) na execuo de seus processos de software.
Uma avaliao nos moldes do MA-MPS envolve uma equipe de avaliao de 3 a 8 pessoas
e dura de 2 a 4 dias. A avaliao possui validade de 3 anos, aps isso necessrio fazer uma
avaliao para outro nvel MR-MPS ou para manter o mesmo nvel.
A empresa que deseja ser avaliada entra em contato com a Softex ou com uma Instituio
Avaliadora (IA). A avaliao conduzida nas seguintes fases (ou subprocessos): Planejar e
Preparar Avaliao, Conduzir Avaliao, Relatar Resultados e Registrar e Publicar Resultados.
Na etapa de Planejar e Preparar Avaliao, so preparados o Plano de Avaliao e o Acordo
de Confidencialidade. No plano de avaliao, so definidos o cronograma, a equipe envolvida
e os projetos a serem avaliados (normalmente uma amostra de 2 a 4 projetos). Nesta fase, a
Planilha de Indicadores, a partir de um template Softex, preenchida. Os indicadores podem
ser diretos (artefatos de processo), indiretos (no so artefatos, mesmo assim demonstram que
a organizao tem condies de implementar um resultado) e afirmaes (obtidas em entrevistas).
Segundo o Guia Geral, alguns processos podem ser excludos, total ou parcialmente, do escopo de uma avaliao MPS por no serem pertinentes ao negcio da unidade organizacional
que est sendo avaliada. Cada excluso deve ser justificada no Plano de Avaliao.
Na etapa conhecida como Conduzir Avaliao, a avaliao conduzida e chega-se ao seu resultado. Em uma Avaliao Inicial, ao critrio do avaliador, a avaliao pode ser feita a distncia
para o nvel G de maturidade. Nesse caso, o avaliador completa o plano de avaliao indicando os ajustes requeridos e, em at seis meses, a avaliao em si pode ser realizada. Durante
esse perodo, a unidade organizacional deve realizar os ajustes obrigatrios indicados pelo
avaliador. Mais detalhadamente, o subprocesso de Conduzir Avaliao consiste nos seguintes
passos:
realizar reunio inicial;
completar assinaturas do acordo de confidencialidade;
treinar equipe de avaliao (inclui a formao de mini-equipes);
apresentar os processos da Unidade Organizacional (UO);
verificar evidncias;
realizar entrevistas;
registrar afirmaes na planilha de indicadores;
caracterizar o grau de implementao de cada resultado nos projetos;
caracterizar, inicialmente, o grau de cada resultado na UO;
189

caracterizar o grau de cada resultado na UO em reunio de consenso;
caracterizar o grau de implementao dos processos na UO;
apresentar pontos fortes, pontos fracos e oportunidades de melhoria;
rever caracterizao e finalizar redao de pontos fortes, pontos fracos e oportunidades
de melhoria;
atribuir nvel do MR-MPS;
comunicar resultado da avaliao ao patrocinador;
comunicar resultado da avaliao aos colaboradores da UO.
O grau de implementao de cada resultado esperado do processo e de cada resultado de
atributo de processo em cada projeto deve ser caracterizado. Existem os seguintes graus de
implementao a serem atribudos:
no implementado (N);
parcialmente implementado (P);
largamente implementado (L);
totalmente implementado (T);
no avaliado (NA);
fora do escopo (F).
Ao preencher esses resultados em uma tabela conhecida como Tabela de caracterizao de
atributos do processo, chega-se atribuio do nvel de maturidade: todos os processos pertinentes ao nvel atribudo foram satisfeitos. Aps a avaliao os resultados so relatados,
registrados e publicados no banco de dados Softex (portal MPS.Br).
4.4.3
MN-MPS
Segundo o Guia Geral, o Modelo de Negcio MN-MPS descreve regras de negcio para implementao do MR-MPS pelas Instituies Implementadoras (II), avaliao seguindo o MAMPS pelas Instituies Avaliadoras (IA), organizao de grupos de empresas pelas Instituies
Organizadoras de Grupos de Empresas (IOGE) para implementao do MR-MPS e avaliao
MA-MPS, certificao de Consultores de Aquisio (CA) e programas anuais de treinamento
do MPS.BR por meio de cursos, provas e workshops.
Ou seja, o MN-MPS descreve as relaes de negcios que envolvem as atividades de difuso
do MPS.Br com a orquestrao da Softex (Associao para Promoo da Excelncia do Software Brasileiro), um sistema de empresas que rene mais de 1600 empresas de todo o territrio
nacional e integrado com uma ampla rede de agentes regionais. A Figura 4.20 apresenta um
organograma do modelo de negcio.
190
Figura 4.20: organograma do MN-MPS.
191
Captulo 5. Tpicos Especiais em Governana de TI
Captulo 5
Tpicos Especiais em Governana de TI

5.1
Arquitetura Corporativa
Segundo a norma ANSI/IEEE 1471:2000, arquitetura : A organizao fundamental de um

sistema com seus componentes incorporados, suas relaes uns com os outros e o ambiente e
os princpios que regem a sua concepo e evoluo.
A Arquitetura Corporativa a arquitetura em que o sistema toda a empresa, em especial, os
processos de negcio, as tecnologias e os sistemas de informao da organizao.
O desenvolvimento da arquitetura corporativa foi iniciado em 1987, com a publicao de um
artigo cujo ttulo era A Framework for Information Systems Architecture (Um framework
para a arquitetura dos sistemas de informao), de autoria de J.A. Zachman. J estava claro na
poca que gerenciar a complexidade dos sistemas cada vez mais distribudos era um desafio,
como Zachman disse: O custo envolvido e o sucesso do negcio dependendo cada vez mais
de seus sistemas de informao exigem uma abordagem disciplinada do gerenciamento desses
sistemas.
Zachman sugeriu uma abordagem de perspectiva mltipla dos sistemas atravs de uma viso
holstica dos negcios, seus objetivos estratgicos e inter-relaes. A primeira tentativa de se
criar uma arquitetura corporativa foi realizada pelo Departamento de Defesa dos EUA (DoD)
e ficou conhecida como TAFIM (Technical Architecture Framework for Information Management) com verso inicial liberada em 1994, mas descontinuada na mesma dcada. Entretanto,
essa iniciativa influenciou a criao de uma lei. Dada a importncia de se criar um melhor
alinhamento entre os projetos tcnicos e as necessidades de negcio, o Congresso Americano
aprovou a Lei Clinger-Cohen em 1996, tambm conhecida como Lei de Reforma do Gerenciamento da Tecnologia de Informao, que conduziu as organizaes a aprimorar a eficincia
dos respectivos investimentos em TI.
O Open Group, um consrcio formado por empresas da indstria de informtica para estabelecer padres abertos para a infra-estrutura de computao, aproveitou o trabalho realizado
pelo TAFIM, modificando seu contedo, para criar o The Open Group Architecture Framework
(TOGAF). J o Gartner, uma empresa conceituada na rea de consultoria, tambm desenvolveu
o seu framework de arquitetura corporativa, mas aproveitando o trabalho de uma empresa que
foi adquirida em 2005 e que j estava estabelecida na rea: a Meta Group.
Atualmente, a grande maioria das organizaes utiliza uma das quatro metodologias seguintes:
192

framework Zachman para arquiteturas corporativas, The Open Group Architecture Framework
(TOGAF), Federal Enterprise Architecture (FEA) e metodologia Gartner. Outras metodologias
conhecidas, mas pouco utilizadas, no so discutidas aqui: United States Department of Defense
Architectural Framework (DoDAF), United Kingdom Ministry of Defence Architectural Framework
(MODAF) e French Dlgation Gnrale pour lArmement Atelier de Gestion de lArchiTEcture des
systmes dinformation et de communication (AGATE).
5.1.1
Framework Zachman
Para construir uma casa, precisamos de diversas plantas de arquitetura, por exemplo: eltrica,
hidrulica e estrutura. Alm do mais, seria ideal que cada uma dessas plantas fosse voltada
a cada um de seus pblicos, por exemplo: os engenheiros envolvidos, o mestre de obras, o
cliente que encomendou a casa e a prefeitura que vai liberar o Habite-se. Zachman enxergou
que, com as organizaes, as necessidades no so diferentes.
O framework Zachman representado, principalmente, por uma tabela bidimensional onde
constam 36 clulas (6 linhas x 6 colunas). As colunas correspondem s clssicas perguntas
5W1H (What/Who/Where/When/Why/How), que so voltadas organizao e detalhadas
a seguir:
What: Qual informao necessria para organizao? Normalmente, so as informaes mantidas pela organizao.
How: De que maneira funciona a organizao? Como seus dados so processados? Ou
seja, quais so os processos e como eles funcionam?
Where: Onde as tarefas da organizao so executadas? Basicamente, so informaes
geogrficas (localizao).
Who: Quem so as pessoas que pertencem organizao e quais os seu papis? Engloba
informaes sobre pessoas e estruturas organizacionais.
When: Quando ocorrem as atividades?
Why: Qual o motivo da execuo dessas atividades? Permeia as motivaes da organizao como, por exemplo, resultantes de seu plano estratgico.
As linhas da tabela representam os pontos de vista e nveis de detalhe da informao:
A primeira linha representa o escopo e o contexto. Basicamente, so informaes de mais
alto nvel necessrias para a realizao de um planejamento estratgico da organizao,
por exemplo.
A segunda linha representa os conceitos de negcio. a viso do lder executivo e com
descrio tipicamente detalhada no nvel de processos de negcio.
A terceira linha representa informaes sobre os sistemas de informao em um nvel
compatvel com a viso dos arquitetos de sistemas.
A quarta linha representa informaes sobre a infraestrutura tecnolgica da organizao.
Basicamente, a viso dos engenheiros enquanto construtores.
A quinta linha representa a descrio dos componentes utilizados pela a organizao
para operar. a viso dos tcnicos que vo implementar os sistemas.
193

A sexta linha refere-se s operaes da organizao, realizadas pelos seus colaboradores
participantes.
A Rede de Zachman apresentada na Figura 5.1.
Figura 5.1: Rede de Zachman.

Formalmente, o framework de Zachman uma ontologia, que aplicada na prtica como uma
taxonomia para organizar os artefatos de uma arquitetura empresarial. Artefatos podem ser,
por exemplo, diagramas, listas e modelos. Os modelo de negcio, de sistemas e de tecnologia
so exemplos de modelos que compem a lista de artefatos do framework de Zachman.
No framework de Zachman, todos os artefatos devem residir em uma e apenas uma clula. Se
houver dvida em qual clula deve residir um artefato, problemas futuros com esse artefato
tornam-se bem provveis.
Outra afirmao do framework que a arquitetura s pode ser considerada completa quando
cada clula estiver completa. Uma clula considerada completa quando todos os artefatos suficientes para descrever plenamente o sistema, em sua viso correspondente, estiverem definidos.
No framework de Zachman, deve ser garantida a existncia de ligaes entre as linhas do modelo. Por exemplo, se mudssemos uma meta estratgica (linha 1), poderamos, rapidamente,
identificar quais so os processos de negcio (linha 2) e os sistemas de informao (linha 3) que
seriam afetados e, com isso, obtermos uma boa anlise de impacto em relao a mudana da
meta.
Entretanto, o framework Zachman no nos detalha quais passos devem ser executados para
194

criarmos uma nova arquitetura corporativa. A Rede (tabela) de Zachman limitada em prover
uma estruturao da informao e comumente considerada como um metamodelo ou taxonomia e no como um framework ou metodologia. Sendo assim, os arquitetos corporativos
recorrem a outros frameworks, devido a ausncia de mtodos (processos) na Rede de Zachman, para construrem uma arquitetura corporativa de fato.
5.1.2
The Open Group Architecture Framework (TOGAF)
O The Open Group Architecture Framework (TOGAF) um framework para o desenvolvimento de uma arquitetura corporativa e foi desenvolvido pelos mesmbros do Open Group. A
verso 1 foi lanada em 1995 e se baseou no Technical Architecture Framework for Information
Management (TAFIM), inicialmente desenvolvido pelo Departamento de Defesa Americano.
O TOGAF nos permite criar, avaliar e construir a arquitetura correta para nossa organizao.
A Figura 5.2 representa a viso de uma arquitetura corporativa segundo o TOGAF.
Figura 5.2: arquitetura corporativa do TOGAF. Imagem retirada de http://msdn.

microsoft.com/pt-br/library/bb466232.aspx.
Como apresentado na figura, o TOGAF divide uma arquitetura corporativa em quatro categorias, como segue:
Arquitetura de negcio: engloba a estratgia empresarial, governana, organizao e
processos de negcio-chave;
Arquitetura de aplicativo: descreve como aplicativos especficos so programados e
como interagem com os processos principais do negcio;
Arquitetura de dados: define a estrutura de ativos fsicos e lgicos de uma organizao
de dados e os recursos para gerenci-los;
Arquitetura tcnica: diz respeito s infraestruturas de hardware e software que suportam os aplicativos e suas interaes, tais como redes, normas, processamento, comunicaes e middleware.
O TOGAF complementa a Rede Zachman: a Rede Zachman categoriza os artefatos, j o TOGAF oferece um processo para a criao desses artefatos. Alm disso, o TOGAF enxerga a arquitetura corporativa como um continuum de arquiteturas, partindo de arquiteturas extremamente genricas para arquiteturas altamente especficas. Esse continuum conhecido como
195

Continuum Corporativo. Os nveis de especificidade partindo dos mais genricos para os
mais especficos so: arquiteturas de fundamento, arquiteturas de sistemas comuns, arquiteturas setoriais e arquiteturas organizacionais.
Figura 5.3: o continuum corporativo do TOGAF. Imagem retirada de http://msdn.

microsoft.com/pt-br/library/bb466232.aspx.
A arquitetura de fundamento, uma arquitetura de servios gerais e funes para a criao de
arquiteturas mais especficas, inclui:
TOGAF Technical Reference Model (TRM): fornece um modelo e uma taxonomia de
plataforma de servios genrica;
TOGAF Standards Information Base (SIB): um banco de dados de padres abertos utilizados para definir servios e outros componentes de arquiteturas mais especficas.
O TOGAF composto por trs partes principais:
TOGAF Architecture Development Method (ADM): Prov uma maneira confivel e
comprovada do desenvolvimento da arquitetura. a parte maior visibilidade dentro do
TOGAF.
Continuum Enterprise: um repositrio virtual de todos os ativos de arquitetura tais
como padres, modelos, descries de arquitetura entre outros.
TOGAF Resource Base: um conjunto de recursos tais como diretrizes, modelos e antecedentes utilizados para ajudar o arquiteto no manuseio do ADM.
O ADM do TOGAF compreende oito fases cclicas aps um perodo conhecido como fase preliminar. As fases esto descritas em termos de objetivos, abordagem, entradas, atividades e
sadas. A Figura 5.4 apresenta essas fases, que so um pouco mais explicadas a seguir:
Fase P - Preliminary: Prepara a empresa para projetos de arquitetura corporativa.
Fase A Architecture Vision: Estabelece um projeto e inicia um ciclo de ADM, definindo
escopo, regras e expectativas para cada iterao.
196

Fase B Business Architeture: Documenta a organizao de um negcio representado
em seus processo e pessoas, seus relacionamentos e ambiente. Tambm estabelece os
princpios que governam o seu desenho e a sua evoluo. Essa fase possui a obrigao
de esclarecer como a organizao alcana seus objetivos.
Fase C Information System Architecture: Documenta a organizao de TI, representando os principais sistemas e informaes processados, de maneira inteligvel para os
stakeholders.
Fase D Technology Architecture: Documenta arquitetura tecnolgica que servir como
base para os trabalhos de implementao e migrao, representando os hardware, software e tecnologias de comunicao.
Fase E Opportunities and Solutions: a primeira fase focada na implementao. Os
parmetros de mudana so identificados, tais como os incrementos e projetos que esto
por vir.
Fase F Migration Planning: Descreve como ser o movimento entre a arquitetura
inicial e a arquitetura alvo. Envolve finalizar um plano detalhado de implementao
e de migrao. Aps o trmino desta fase, a preparao para a implementao estar
completa.
Fase G Implementation Governance: Define como a arquitetura regula a implementao de projetos, monitorando a construo e produzindo um Contrato de Arquitetura
assinado. Esta fase envolve a etapa de governar a arquitetura, conduzindo revises e
monitoramento de risco.
Fase H - Architecture Change Management: Assegura que as mudanas na arquitetura
so gerenciadas de uma maneira controlada.
Fase R Requirement Management: Identifica e mantm requisitos de arquitetura em
todas as fases do ciclo ADM.
Figura 5.4: Architecture Development Method (ADM) do TOGAF. Imagem retirada de http:
//msdn.microsoft.com/pt-br/library/bb466232.aspx.
197

Informaes mais completas sobre o TOGAF podem ser obtidas no website oficial http://
www.opengroup.org/architecture/togaf9-doc/arch.
5.1.3
Federal Enterprise Architecture (FEA)
Federal Enterprise Architecture (FEA) a mais completa de todas as metodologias para se criar
uma arquitetura corporativa. Entretanto, ela ainda est em fase inicial, visto que a maior parte
dos seus itens est disponvel desde 2006, apenas. FEA possui uma taxonomia abrangente,
como Zachman, e um processo arquitetural, como o TOGAF. Ela foi concebida para abranger
tudo o que necessrio para a construo de uma arquitetura corporativa para o governo
norte-americano.
Um Segmento de rea de Misso Central aquele segmento que fundamental para a misso da empresa. Ou seja, o segmento da rea-fim da empresa. Um Segmento de Servios do
Negcio engloba atividades que so essenciais, mas que no fazem parte do negcio principal. Por exemplo, o servio de gerncia financeira essencial em qualquer empresa. Servio
corporativo um servio que trabalha de maneira unificada em todas as sees da empresa,
por exemplo: o servio de gerenciamento de segurana. Na Figura 5.5 podemos notar a organizao dos segmentos do governo federal dos EUA.
Figura 5.5: mapa segmentado do governo federal dos EUA. Imagem retirada de http://
msdn.microsoft.com/pt-br/library/bb466232.aspx.
198

Constam na FEA, cinco modelos de referncia, cujo objetivo oferecer termos e definies
padronizados para os domnios da arquitetura corporativa e, assim, facilitar a colaborao e o
compartilhamento. Os cinco modelos de referncia so os seguintes:
Modelo de referncia do negcio (BRM - business reference model): fornece uma viso
do negcio das funes que devem ser desempenhadas pelo governo federal dos EUA
ou, analogamente, pela organizao;
Modelo de referncia de componentes (CRM - components reference model): descreve
os sistemas que do suporte ao negcio, mas com o ponto de vista de TI;
Modelo de referncia tcnica (TRM - Technical Reference Model): oferece a definio
de vrias normas e tecnologias que podem ser usadas na construo de sistemas de TI;
Modelo de referncia de dados (DRM - Data Reference Model): define a maneira em
que os dados devem ser descritos, padronizando-os;
Modelo de referncia de desempenho (PRM - performance reference model): fornece
formas padronizadas para descrever as vantagens obtidas pela utilizao da arquitetura
corporativa.
O processo de desenvolvimento da arquitetura de segmentos do FEA, em alto nvel, consiste
nas seguintes etapas:
1. Anlise arquitetural: descreve o segmento de uma maneira simples e concisa, relacionandoo com o plano organizacional;
2. Definio arquitetural: desenvolve uma arquitetura corporativa para o segmento, englobando as arquiteturas de negcios, dados, servios e tecnologia. Ou seja, define seu
estado arquitetural desejado e documenta suas metas de desempenho;
3. Estratgias de investimento e custeio: decide-se como o projeto ser custeado;
4. Plano do programa de gerenciamento e projetos executivos: criao de um plano para
gerenciar e executar o projeto.
Na FEA, as agncias federais so classificadas, de acordo com os respectivos nveis globais de
maturidade, em trs categorias principais: perfeio arquitetural (quo boa a arquitetura),
uso arquitetural (o quanto a arquitetura utilizada) e resultados arquiteturais (os benefcios
do uso da arquitetura). De acordo com a avaliao dessas categorias, a organizao recebe uma
nota cumulativa, que pode ser vermelha, amarela ou verde, em cada uma das categorias.
5.1.4
Metodologia Gartner
A metodologia Gartner no considerada uma taxonomia (como Zachman), nem um processo

(como TOGAF), tampouco uma metodologia completa (como a FEA). a prtica da arquitetura corporativa de uma das mais conhecidas organizaes de pesquisa e consultoria de TI do
mundo. Alm de contar com especialistas bem qualificados, o Gartner desenvolve uma comunidade que incentiva a colaborao e as melhores prticas.
O Gartner acredita que a arquitetura corporativa deve agrupar, para o sucesso da arquitetura,
trs componentes: proprietrios do negcio, especialistas em informaes e implementadores
de tecnologia. Alm disso, acreditam que o sucesso deve ser medido em termos pragmticos,
199

tais como gerar rentabilidade, no apenas marcando os itens em uma matriz de processo. Em
sua viso, a arquitetura corporativa deve alcanar as metas de maneira objetiva: Apenas o
necessrio de arquitetura corporativa, no momento certo.
Em suma, a metodologia Gartner uma maneira mais pragmtica de implementar a arquitetura corporativa.
5.2
Marcos de Regulao
Os marcos de regulao so leis, acordos e tratados governamentais que representam restries ao negcio da organizao. O termo compliance tambm utilizado para descrever a
aderncia a esses marcos de regulao.
5.2.1
Foreign Corrupt Practices Act of 1977 (FCPA)
Foreign Corrupt Practices Act of 1977 (FCPA) uma lei pioneira em relao ao combate a corrupo. Foi promulgada em 1977 e motivada por um escndalo de corrupo conhecido como
Caso Watergate.
A FCPA criou sanes penais e cveis para empregados, administradores e representantes de
empresas que pratiquem atos de corrupo no estrangeiro, quer realizados diretamente pelas
matrizes das empresas americanas ou por suas subsidirias em qualquer pas.
As subsidirias de multinacionais americanas esto sujeitas FCPA tanto quanto suas matrizes. Assim, sob a FCPA, uma empresa no pode dar, oferecer, prometer ou autorizar que
se d qualquer coisa de valor a uma autoridade estrangeira, quer diretamente ou por meio de
intermedirio, tal como um agente, procurador ou advogado, a fim de influenciar a ao do
funcionrio para obter vantagens imprprias.
O que faz com que a FCPA tenha um grande impacto na prtica que ela responsabiliza a
empresa por atos praticados por terceiros que ajam em nome dela. E, na aplicao da FCPA,
as autoridades americanas no admitem o argumento de que a empresa desconhecia a ao do
terceiro. Para evitar essa situao, as empresas devem se assegurar que seus agentes cumpram
o que est estabelecido na lei. comum a realizao de Due Diligence para investigar as
atividades e a reputao de terceiros que tenham ou que possam vir a ter relaes com a empresa.
Alm disso, as empresas sob o FCPA so obrigadas a manter sistemas de controle que ofeream garantias de que as transaes sero registradas em conformidade com os princpios
contbeis. Em vista disso, os auditores independentes do AICPA (American Institute of Certified
Public Accountants) pregam que a administrao deve estabelecer uma estrutura de controle
interna composta por trs elementos: Ambiente de Controle, Sistema Contbil e Procedimento
de Controle. No sentido de desenvolver uma definio comum de controle interno com diretrizes processuais, criou-se o COSO, Comit das Organizaes Patrocinadoras. O COSO foi
responsvel pelo desenvolvimento de um dos mais importantes modelos de controle interno.
200
5.2.2
Lei Sarbanes-Oxley
A Sarbanes-Oxley (SOx), uma lei criada nos Estados Unidos para aperfeioar os controles
financeiros das empresas que possuem capital na Bolsa de Nova York. Ela foi criada em decorrncia dos escndalos financeiros das empresas Enron, Worldcom entre outras no incio do
sculo 21. A lei prev multas que variam de um milho a cinco milhes de dlares e penas de
recluso entre 10 e 20 anos para os CEOs (Chief Executive Officer) e CFOs (Chief Finance Officer) das empresas que no a respeitarem. Segundo a maioria dos analistas, esta lei representa a
maior reforma do mercado de capitais americano desde a introduo de sua regulamentao,
logo aps a crise financeira de 1929.
A SOx se aplica a todas as empresas, sejam elas americanas ou estrangeiras, que tenham aes
registradas na SEC (Securities and Exchange Comission, o equivalente americano da CVM
brasileira). Ela afeta dezenas de empresas brasileiras que mantm ADRs (American Depositary Receipts) negociadas na Bolsa de Nova York, como a Petrobras, a GOL Linhas Areas, a
Sabesp,a CPFL (Companhia Paulista de Fora e Luz),a TAM Linhas Areas, a Brasil Telecom,
Ultrapar (Ultragaz), a Companhia Brasileira de Distribuio (Grupo Po de Acar), Banco
Ita, TIM, Vale S.A., Vivo Participaes S.A. Companhia Energtica de Minas Gerais (Cemig)
e a Natura Cosmticos S.A..
Dividida em onze ttulos (captulos) e perfazendo um total de 69 sees (artigos), a SOx define
por lei uma sries de medidas que j eram consideradas boas prticas de governana corporativa. A lei obriga as organizaes a reestruturarem seus processos para aumentar os controles,
a segurana e a transparncia na conduo dos negcios, na administrao financeira, nas escrituraes contbeis e na gesto e divulgao das informaes.
Em particular, a Seo 302 determina a responsabilidade dos diretores das empresas, que devem assinar os relatrios certificando que as demonstraes e outras informaes financeiras
includas no relatrio do perodo, apresentam todos os fatos materiais e que no contm nenhuma declarao falsa ou que fatos materiais tenham sido omitidos. Tambm devem declarar
que divulgaram todas e quaisquer deficincias significativas de controles, insuficincias materiais e atos de fraude ao seu Comit de Auditoria.
J a Seo 404 determina uma avaliao anual dos controles e procedimentos internos para
a emisso de relatrios financeiros. Alm disso, o auditor independente deve emitir um relatrio distinto que ateste a assero da administrao sobre a eficcia dos controles internos e
dos procedimentos executados para a emisso dos relatrios financeiros.
A rea de Tecnologia da Informao uma fonte de risco para a continuidade do negcio e
para o atendimento das Sees 302 e 404 da SOx. A Seo 404 do Ato Sarbanes-Oxley o
principal foco de ateno das empresas, por trazer as determinaes sobre os controles de processos internos e sistemas contbeis.
A conformidade Sarbanes-Oxley apresenta um impacto significativo sobre a rea de TI da
maioria das empresas. A rea de TI deve cobrir todos os aspectos de segurana e controle
das informaes digitais da empresa, devendo desenhar processos de controle das aplicaes
para assegurar a confiabilidade do sistema operacional, a veracidade dos dados de sada e a
proteo de equipamentos e arquivos. Para cumprir essas exigncias, os CIOs devem rever
todos os processos internos cobrindo desde as metodologias de desenvolvimento de sistemas
201

at as reas de operaes de computadores. Alm disso, promover uma conscientizao nas
reas usurias de seus recursos sobre os aspectos de segurana e cuidados na manipulao das
informaes, tais como: e-mails, compartilhamento de diretrios nos PCs, compartilhamento
de senhas de acesso aos aplicativos, etc.
Na SOx, no existem especificaes sobre quais controles que devem ser estabelecidos dentro da rea de TI para a conformidade. Sendo assim, a Governana Corporativa em TI, embora
j estivesse sido desenvolvida, ganhou grande impulso com o advento da lei, que deu prazo
at dezembro de 2006 para a implementao dos requisitos. As empresas, em grande parte,
passaram a adotar COSO e COBIT para atingir a conformidade.
A SOx tambm criou o Public Company Accounting Oversight Board (PCAOB), ou seja, Conselho de Auditores de Companhias Abertas, que possui a misso de estabelecer as normas de
auditoria, controle de qualidade, tica e independncia em relao aos processos de inspeo e
a emisso dos relatrios de auditoria. O PCAOB, criou o Auditing Standard No. 2, mais tarde
substitudo pelo Auditing Standard No. 5, como um padro que fornece requisitos e orientaes para o auditor avaliar a eficcia dos controles internos sobre os relatrios financeiros.
Na Figura 5.6, podemos ver a relao que existe entre a Sox, o COSO e o COBIT.
Figura 5.6:
relao entre SOx, COSO e COBIT. Imagem retirada de http://
separationofduties.com/it-relation-between-sox-404-coso-and-cobit.
Logo depois da criao, em 2002, nos EUA, da lei Sarbanes-Oxley (SOx), a Unio Europia
resolveu enfrentar o mesmo assunto. A chamada E-SOx, ou Euro-SOx, um conjunto de normas que dizem respeito aos assuntos tratados pela SOx dos EUA. Da mesma maneira, o Japo
tambm decidiu fazer sua lei sobre o tema. J-SOx o nome informal dado a um conjunto de
normas japonesas relativas a controles internos e divulgao de relatrios financeiros (ICFR)
que fazem parte da Lei Japonesa sobre Instrumentos Financeiros e Bolsas (Japanese Financial
Instruments and Exchange Law).
202

J no Brasil, tivemos o avano da regulamentao promovido pela Comisso de Valores Mobilirios (CVM), atravs de suas instrues. Todavia no existe at o momento um conjunto de
leis capaz de garantir aos investidores brasileiros o mesmo grau de segurana que foi conferido
nos mercados de capitais estrangeiros. Apesar de existirem diversos esforos legislativos em
andamento no Brasil, eles ocorrem de forma dispersa e ainda no obtm o devido reflexo no
mbito do direito penal.
5.2.3
Acordo de Basileia II e a Resoluo 3380/2006 do CMN
Em 1988, foi introduzido um acordo de capital ratificado por mais de 100 pases, visando a internacionalizao da atividade bancria. Inicialmente, o acordou visou fixar limites mnimos
de solvabilidade dos bancos. Para tanto, fixou limites mximos de alavancagem e mecanismos
de mensurao de riscos de crdito. Esse acordo hoje conhecido como Acordo de Basileia I.
Devido s deficincias que foram identificadas no primeiro acordo, em janeiro de 2001, foi
divulgado um acordo mais complexo e extenso que o anterior conhecido como Acordo de
Basileia II. As principais mudanas esto no fim da padronizao generalizada por um enfoque mais flexvel. Por ser mais sensvel ao risco que os bancos assumem, o acordo admite
que os limites podem variar de acordo o risco do capital. O prazo para o cumprimento do
acordo foi 2007 para os pases do G10. No Brasil, a previso da implementao total do acordo
2013.
O Acordo de Basileia II estruturado em trs pilares:
Capital: Determinao dos requisitos mnimos de fundos prprios para a cobertura dos
riscos de crdito, de mercado e operacional;
Reviso pela Superviso: Convergncia das polticas e prticas de superviso, regulando a participao e o papel do regulador (no Brasil, o Banco Central) no processo de
superviso bancria e de avaliao da governana de risco das instituies e como estas
gerenciam o capital para fazer frente aos riscos incorridos;
Disciplina de Mercado: Prestao de informao ao mercado e ao pblico em geral,
de modo a assegurar maior transparncia sobre a situao financeira e a solvabilidade
das instituies. Sendo necessrio criar instrumentos e condies para reduzir o risco
sistmico gerado pela assimetria da informao, estimulando e favorecendo a disciplina
de mercado.
Sob o ponto de vista da Governana Corporativa de TI, o Acordo Basileia II se aplica exigncia da criao de polticas de gerenciamento de riscos para garantir total segurana e confidencialidade dos dados de clientes. Isso exige que as empresas do setor alterem processos e
sistemas para cumprir as regras do acordo. Basicamente, os pilares Reviso pela Superviso
e Disciplina de Mercado acabam obrigando os bancos a adotarem polticas de governana
mais srias.
A implantao de um gerenciamento de riscos sofisticado fora uma srie de alteraes nos
diversos sistemas existentes dentro das organizaes e exige o mapeamento de riscos nos processos operacionais. Ou seja, exige das instituies financeiras considerveis investimentos
em tecnologia da informao, desenvolvimento de ferramentas de gesto, governana corporativa, cultura de risco e ajustes nas prticas de gesto. Por exemplo, os seguintes riscos
operacionais devem ser avaliados:
203

Capacidade de armazenamento de dados;
Integridade das transaes;
Integridade de informaes sobre clientes/operaes;
Segurana;
Contingncia na operao;
Planejamento da capacidade;
Planejamento de recuperao de desastres;
Integridade do processo de emisso de relatrios.
Visto que as duas rodadas de regulao internacional, Basileia I e II, no foram suficientes para
impedir as prticas arriscadas dos bancos, que culminaram em uma profunda crise no sistema financeiro mundial em 2008 e 2009, est em anlise a terceira verso do Acordo, chamada
Basileia III. A proposta apresentada em 12 de setembro de 2010 pelo Comit da Basileia aumenta as exigncias de capital dos bancos, mas principalmente, melhora sua qualidade, para
ampliar a capacidade das instituies absorverem perdas e resistirem mais a apertos de liquidez.
Junto aos esforos para cumprir o Acordo de Basileia II, foi criada a resoluo 3380/2006 do
Conselho Monetrio Nacional (CMN). A publicao define que todas as instituies financeiras implementem sua prpria estrutura de gerenciamento do risco operacional. Segundo a
prpria resoluo, Risco Operacional a possibilidade de ocorrncia de perdas resultantes
de falha, deficincia ou inadequao de processos internos, pessoas e sistemas, ou de eventos
externos.
A resoluo 3380/2006 representa a primeira etapa de uma srie de medidas ligadas gesto
do risco operacional. Obriga as instituies a efetuarem uma gesto integrada de seus processos, atividades, riscos e controles internos. Requer tambm a criao de Bases de Dados de
Perdas Operacionais e o estabelecimento de Planos de Continuidade de Negcios.
Basicamente, a resoluo determina que sejam tomadas as seguintes providncias:
Identificar, monitorar e mitigar riscos operacionais;
Implementar plano de continuidade;
Gerenciar riscos de fornecedores.
Ainda de acordo com a resoluo 3380/2006, esses processos de mitigao de riscos devem ser
reavaliados com periodicidades mnimas de um ano.
5.3
5.3.1
Arquitetura de Controle Interno

Frameworks de controles internos
Um framework pode ser definido como um arcabouo de conceitos, modelos, processos, tcnicas, documentos, relatrios e outros artefatos que podem ser aplicados em um determinado
204

contexto. No contexto de desenvolvimento de software, por exemplo, um framework pode ser
composto por um conjunto de classes e mdulos que podem ser utilizados para a implementao de um sistema ou subsistema, ou para a resoluo de problemas de uma determinada
categoria. Podemos ter, por exemplo, um framework para desenvolvimento de problemas de
pesquisa textual em grandes quantidades de arquivos, ou um framework para desenvolvimento de sistemas de controle de cadeia de suprimentos etc.
No mbito de controles internos, tambm existe uma grande quantidade de frameworks, alguns mais genricos, sendo possvel sua aplicao em diversas localidades e tipos de organizaes, e outros menos abrangentes, sendo restritos a cenrios mais especficos.
Os frameworks de controles internos so, primordialmente, compostos por processos e por um
conjunto de artefatos (templates, relatrios de auditorias etc). Um dos frameworks de controle
interno mais conhecidos o COSO, que ser detalhado mais adiante neste Captulo. Trata-se
de um framework que surgiu em um contexto de uma maior necessidade de preveno contra
fraudes financeiras, tendo sido proposto conjuntamente por diversas associaes de contadores nos Estados Unidos.
Em outras partes do mundo surgiram frameworks semelhantes com a mesma motivao:
prover maior governana e diminuir o risco de fraudes financeiras e prejuzos para os acionistas.
Para fins de exemplificao, podemos citar o Turnbull Report (Inglaterra) e o King Report
(frica do Sul).
Um outro framework de controle interno que merece ser mencionado o COCO, que foi criado no Canad em 1995 e, assim como o COSO e os demais frameworks citados, foi idealizado
por associaes de contadores no intuito de diminuir o risco de fraudes financeiras. O COCO
estruturado em 4 dimenses que so: Purpose, Commitment, Capability e Monitoring and
Learning. A dimenso Purpose foca no propsito dos controles, enquanto a Commitment enfatiza o estabelecimento e disseminao de valores, diretrizes e polticas pela organizao, de
modo a gerar comprometimento pela causa do controle interno. A dimenso Capability trata
das competncias necessrias para a implementao dos controles, e por fim a dimenso Monitoring and Learning se encarrega de assegurar que os controles esto de fato implementados
e sendo melhorados continuamente para atender as necessidades da organizao e fazer frente
aos novos riscos e desafios.
A seguir, vamos conhecer com um pouco mais de detalhes o COSO.
5.3.2
COSO
O tema controle interno tem um marco regulatrio importante nos Estados Unidos em dezembro de 1987, quando foi aprovado pelo Congresso Americano o Foreign Corrupt Practices Act
(FCPA). Este ato que passou a obrigar as sociedades annimas abertas (com aes comercializadas em bolsas de valores americanas) a criar, implementar e manter sistemas de controle
para garantir a correo e a conformidade legal de seus relatrios contbeis.
Foi neste contexto que comeou a surgir o Committee of Sponsoring Organizations of the
Treadway Commission (COSO), uma organizao voluntria do setor privado dedicada a
prover um guia para o gerenciamento e governana da tica nos negcios, dos controles internos, do gerenciamento de riscos corporativos, da preveno de fraudes e dos relatrios fi-
205

nanceiros.
O COSO foi conjuntamente fundado e patrocinado pelas cinco maiores associaes de contadores profissionais:
American Institute of Certified Public Accountants (AICPA)
American Accounting Association (AAA)
Financial Executives International (FEI)
Institute of Internal Auditors (IIA)
Institute of Management Accountants (IMA)
Em 1992, o COSO apresentou a primeira verso do framework, que mais tarde ficou conhecido
como COSO 1. Nele, definiu-se controle interno e foram elaborados critrios para a avaliao
de sistemas de controles internos. Um outro aspecto marcante do COSO o fato de ele responsabilizar diretamente o Board (Conselho Diretor, ou Conselho de Administrao), os diretores,
e os funcionrios das organizaes envolvidos diretamente com os processos de controles internos.
O framework COSO se baseia em uma srie de conceitos chave, entre os quais merecem
destaque os seguintes:
Controle interno um processo que busca alcanar um fim, no sendo o fim por si s.
Controle interno est relacionado a pessoas, no sendo composto apenas por polticas,
manuais, procedimentos ou formulrios.
Controle interno pode proporcionar garantias razoveis, mas no absolutas, aos diretores
e ao board da empresa.
Ainda segundo o COSO, os controles internos so processos implementados pelo board, pelos
diretores e pelos funcionrios das empresas para prover garantias razoveis de alcance de
objetivos nas seguintes categorias:
Eficcia e eficincia das operaes;
Confiabilidade dos relatrios financeiros;
Conformidade com as leis e regulamentos aplicveis.
Para alcanar tais objetivos, o COSO se estrutura em cinco componentes inter-relacionados
que o permitem descrever e analisar os sistemas de controle internos implementados pelas
organizaes com vistas ao atendimento das exigncias regulatrias aplicveis. Os cinco componentes do COSO so os seguintes:
1. Ambiente de Controle: a base para todos os demais componentes, dizendo respeito
a fatores como tica, estrutura da organizao, formas de conduta, forma de atuao
e patrocnio do Board e da alta administrao para a cultura de controle. Tambm
enfatizada a atribuio adequada de autoridade e responsabilidade das pessoas pelos
processos de controle;
206

2. Avaliao de Risco: Consiste da identificao e anlise de riscos, internos e externos, que
so relevantes para os objetivos da empresa, levando-se em considerao a probabilidade
e os impactos de cada um dos riscos, bem como a postura e as aes da empresa para
tratar e cada um dos riscos;
3. Atividade de Controle: So as diretrizes, polticas e procedimentos que garantem que os
objetivos definidos indicados pela alta administrao sero atingidos em todos os seus
nveis;
4. Informao e Comunicao: Diz respeito aos sistemas de informao a partir dos quais
so produzidos relatrios contendo informaes operacionais, financeiras e de conformidade, tornando possvel o controle do negcio. So englobadas informaes geradas e
publicadas internamente ou externamente, devendo ainda existir a preocupao com o
fluxo adequado de informaes por todos os nveis hierrquicos da empresa;
5. Monitoramento: Refere-se ao contnuo monitoramento da operao do sistema de controle interno, garantindo que este esteja sempre rodando corretamente.
Diante dos novos desafios impostos pelos mercados e com o objetivo de no apenas atender
exigncias regulatrias, mas tambm de preservar a gerao de valor nas empresas, em 2001 o
COSO props uma reviso tcnica chamada ERM (Enterprise Risk Management Framework),
que ficou conhecido como COSO 2 ou COSO ERM. Como o prprio nome j sugere, no COSO
ERM, a preocupao principal do COSO passou a ser a gesto de riscos.
Assim como no COSO 1, o framework se estrutura para o provimento de garantias razoveis
do alcance de objetivos, porm, desta vez organizados em quatro categorias, e no mais trs.
No entanto, a nica diferena nessa organizao a categoria de objetivos estratgicos, j que
as outras 3 j estavam presentes no COSO 1.
Objetivos Estratgicos (Strategic)
Objetivos de Operaes (Operations)
Objetivos de Comunicao (Reporting)
Objetivos de Conformidade (Compliance)
No COSO ERM, o gerenciamento de riscos corporativos constitudo de oito componentes
que so:
Ambiente Interno
Fixao de Objetivos
Identificao de Eventos
Avaliao de Riscos
Resposta a Risco
Atividades de Controle
Informaes e Comunicaes
Monitoramento
207

As oito componentes do COSO ERM possuem nomes auto-explicativos, e o detalhamento de
cada uma delas foge doe escopo deste texto. No entanto, possvel obter informaes abundantes sobre o tema na Internet.
A despeito de todos os benefcios advindos do gerenciamento de riscos corporativos, o COSO
enftico ao dizer que o framework possui limitaes. Por isso, desde a sua primeira verso,
utiliza-se a expresso garantias razoveis, e no garantias absolutas. As limitaes originamse do fato de que as pessoas envolvidas no processo podem falhar (por erro ou por engano), e
os controles podem ser burlados pelo conluio entre duas ou mais pessoas. Alm disso, a alta
administrao pode se recusar a aceitar as decises de gesto de riscos por motivos diversos.
Por fim, apresentamos a Figura 5.7 que contrape as duas verses do COSO, para que as
categorias e componentes dos dois modelos possam ser visualizados conjuntamente, dando
a noo de complementaridade objetivada pelos idealizadores do framework.
Figura 5.7: COSO v1 vs COSO ERM.
5.4
Metodologias para Outsourcing de TI
Observa-se no mercado uma forte tendncia de terceirizao (ou Sourcing, ou e-Sourcing) dos
chamados servios de TI, sendo este movimento motivado, em grande parte das vezes, pela
reduo de custos e aumento da eficincia. Para que estes objetivos sejam alcanados, o processo de terceirizao deve ser marcado pela estabilidade na prestao dos servios, respeitando ainda o custo, a qualidade, a segurana e os SLAs definidos no contrato.
No entanto, alcanar este objetivo no uma tarefa trivial, e muitas organizaes tem en208

frentado problemas para administrar o processo de terceirizao dos servios de TI. Como
decorrncia desta dificuldade enfrentada pelas organizaes, surgiu uma forte demanda no
mercado por padres e melhores prticas de gesto e operao dos servios de TI terceirizados.
O cerne do problemas est no fato de que a deciso de fazer ou comprar (make or buy), no
so suficientes por si s, sendo necessria a reflexo sobre uma srie de outras questes. Estas questes esto relacionadas, por exemplo, responsabilidade pela execuo dos servios,
propriedade dos ativos, responsabilidade pela gesto do servio, localizao do prestador do servio, forma e ao tipo do contrato estabelecido com os prestadores. Para um bom
processo de terceirizao, todas essas questes devem ser respondidas e as solues escolhidas devem trabalhar harmoniosamente, uma vez que tais questes so dependentes umas das
outras.
A questo fazer ou comprar tambm no to trivial quanto parece primeira vista. Os
critrios de deciso pela terceirizao ou no devem ser embasados em reflexes a respeito
das seguintes questes:
Existe incerteza sobre o ambiente tecnolgico?
Existe capacidade de mensurao dos servios de TI?
Existe capacidade de previso do comportamento do fornecedor?
Existe ou possvel definir o nvel esperado dos servios de TI?
Existe disponibilidade de informaes sobre o mercado fornecedor?
Alm disso, para tomar uma boa deciso de fazer ou comprar necessrio ponderar as ameaas
de um processo de terceirizao mal implementado. Entre elas podemos listar as seguintes:
Atrasos na entrega do servio;
Custos acima do esperado;
Dependncia extrema do fornecedor;
Diminuio da qualidade do servio;
No conformidade com os requisitos originais do servio e
Violaes de segurana da informao.
Como podemos ver, o processo de decidir por fazer ou comprar, bem como o processo de
gesto e operao dos servios contratados esto longe de serem simples e diretos. Adiante,
apresentaremos algumas metodologias que tm por objetivo suportar o processo de terceirizao de servios de TI, tanto por parte dos fornecedores, quanto por parte dos clientes.
5.4.1
eSCM-SP - eSourcing Capability Model for Service Providers
O eSCM-SP (eSourcing Capability Model for Service Providers) um modelo de referncia que foi
desenvolvido pela Carnegie Mellon University (CMU) e que tem por objetivo estabelecer um
209

conjunto de requisitos para o bom desempenho na prestao de servios de TI 1 .
Este conjunto de requisitos engloba as etapas de iniciao, entrega, finalizao e gesto da
prestao de servios pelo provedor, visando aumentar a previsibilidade e capacidade de entrega, alm de oferecer uma forma objetiva de avaliao dos fornecedores pelos clientes.
Agora, vamos conhecer um pouco mais de detalhes sobre a estrutura do eSCM-SP. Este modelo
por 84 prticas que endeream as capacidades crticas necessrias aos prestadores de servios
de TI. Tais prticas so distribudas em trs dimenses, a saber:
Sourcing Life-cycle
Capability Area
Capability Level
Na dimenso Sourcing Life-cycle (ciclo de vida do fornecimento) enfatizada em que ponto
do ciclo de vida cada uma das prticas mais importante. Este ciclo divido nas seguintes
etapas:
Initiation
Ongoing
Delivery
Completion
J a dimenso Capability Area proporciona um agrupamento lgico de prticas para ajudar os
usurios a gerenciar e usar o modelo eSCM-SP. Ao total, o modelo traz dez reas de capacidade
que so:
1. Knowledge Management
2. People Management
3. Performance Management
4. Relationship Management
5. Technology Management
6. Threat Management
7. Service Transfer
8. Contracting
9. Service Design & Deployment
10. Service Delivery
1
Usamos a expresso servios de TI como traduo da expresso em ingls IT enabled services, cujo uso se
tornou comum em diversas normas e metodologias escritas em ingls. Embora a expresso servios habilitados
em TI ainda no tenha se difundido no mercado, vale a pena atentar para esta possibilidade
210

A terceira dimenso do modelo, Capability Level, desempenha no eSCM-SP um papel semelhante aos nveis de maturidade do modelo CMMI. Os cinco capability levels so os seguintes:
Level 1: Providing services
Level 2: Consistently meeting requirements
Level 3: Managing organizational performance
Level 4: Proactively enhancing value
Level 5: Sustaining excellence
Por fim, o modelo eSCM-SP traz as suas 84 prticas, relacionando-as com cada uma das trs
dimenses do modelo. Obviamente, este estes relacionamentos e todas as suas particularidades seriam extensos demais para este texto. Portanto, para os que se interessarem em mais
detalhes sobre os meandros do modelo, sugerimos que visitem o site da Carnegie Mellon University, ou ento sites especializados em governana de TI. No momento da redao deste
texto, existiam uma grande quantidade de informaes a respeito deste tema, por exemplo, no
site http://www.itsqc.org/index.html.
5.4.2
eSCM-CL - eSourcing Capability Model for Clients
O eSCM-CL (eSourcing Capability Model for Clients), assim como o eSCM-SP, foi desenvolvido
pela Carnegie Mellon University e tem por objetivo estabelecer um conjunto de requisitos para
o bom desempenho na contratao de servios de TI. Este conjunto de requisitos que permite
ao cliente avaliar e melhorar sua capacidade desenvolver e gerir relacionamentos de terceirizao de servios de TI.
As dimenses do modelo so as mesmas do eSCM-SP: Sourcing Life-cycle, Capability Area
e Capability Level. Os modelos so iguais entre si na dimenso Capability Level. Ou seja, os
capability levels nos dois modelo so os mesmos. Na dimenso Sourcing Life-cycle, o eSCMCL difere do modelo irmo, tendo a seguinte estrutura de fases:
1. Analysis
2. Initiation
3. Delivery
4. Completion.
J na dimenso Capability Areas, o eSCM-CL traz 17 delas:
1. Sourcing Strategy Management
2. Government Management
3. Relationship Management
4. Value Management
5. Organizational Change Management
6. People Management
211

7. Knowledge Management
8. Technology Management
9. Threat Management
10. Sourcing Opportunity Analysis
11. Sourcing Approach
12. Sourcing Planning
13. Service Provider Evaluation
14. Sourcing Agreements
15. Service Transfer
16. Sourced Services Management
17. Sourcing Completion
A esta altura do campeonato, se voc imaginava que terceirizar servios de TI com qualidade
era uma tarefa simples, os modelos da famlia eSCM acabam de te provar o contrrio! Por fim,
o eSCM-CL traz o seu conjunto de 95 prticas, que so relacionando-as com cada uma das trs
dimenses do modelo, seguindo a mesma ideia do modelo eSCM-SP. Para obter mais informaes sobre este modelo, as mesmas fontes citadas anteriormente podem ser consultadas.
5.4.3
SAS 70
O Statement on Auditing Standards 70 Service Organizations (SAS 70) um padro de auditoria do American Institute of Certified Public Accountants (AICPA), o instituto americano
de contadores pblicos certificados.
Este padro prov um guia para a elaborao de relatrios de auditorias em organizaes
prestadoras de servio, sendo um relevante instrumento de governana em virtude crescente
movimento de terceirizao nas empresas. Destaque-se que, originalmente, o SAS 70 era
chamado de Reports on the Processing of Transactions by Service Organizations, pelo fato
de se tratar de um padro voltado para a auditoria de servios.
Exemplos de organizaes prestadoras de servios de TI so os datacenters, os application
service providers (ASPs), operadoras de carto de crdito e outros servios de pagamento etc.
Como os servios de TI prestados por estes e outros tipos de empresas guardam relao direta
com o core-business das organizaes, faz-se necessrio utilizar instrumentos de controle to
rigorosos quanto os utilizados para os processos e servios executados no mbito da organizao. este, portanto, o contexto de aplicao da SAS 70 ao mundo da tecnologia da informao.
Alm disso, com a introduo da Lei Sarbanes-Oxley (SOx), em 2002, o SAS 70 assumiu
ainda mais importncia, uma vez que esta lei deu ainda mais nfase nos controles internos
dos processos que pudessem vir a comprometer os relatrios financeiros das empresas. Nesse
contexto, o mercado identificou que o SAS 70 como mtodo aceitvel para garantir controles
relacionados a servios terceirizados.
212

Os principais produtos gerados pela SAS 70 so os relatrios de auditoria, que podem ser
dos seguintes tipos:
Tipo I: Um relatrio do tipo I apresenta a opinio do auditor sobre a imparcialidade da
descrio dos controles e sobre a adequao dos controles para o alcance dos objetivos
de controle definidos. Este relatrio tambm indica se os controles estavam em vigor em
uma determinada data, no garantindo, portanto, que os controles estejam efetivamente
implantados de forma continua;
Tipo II: Um relatrio do tipo II apresenta inclui as informaes contidas em um relatrio
do tipo I e mais a opinio do auditor sobre a eficcia da implementao dos controles
durante um perodo de seis meses ou mais.
Embora o SAS 70 seja um padro americano, em um cenrio de globalizao dos mercados
financeiros mundiais, ele encontra aplicao prtica no Brasil para empresas nacionais que
possuam aes negociadas em bolsas de valores americanas, como a Petrobras 2 , ou que simplesmente desejem transmitir uma maior segurana a investidores estrangeiros que buscam o
mercado brasileiro.
5.5
5.5.1
Metodologias de Qualidade e Desempenho

Seis Sigma
O Seis Sigma um processo de controle e melhoria de qualidade que foi desenvolvido pela
Motorola em meados de 1986, quando a empresa lutava para competir com empresas estrangeiras, e havia o reconhecimento da alta administrao de que a qualidade de seus processos e de seus produtos estava baixa. Nesse contexto, o presidente da Motorola estabeleceu
a ambiciosa meta de melhorar a qualidade dos produtos em dez vezes para atingir a satisfao
dos clientes, tudo isso dentro de um prazo de 5 anos.
Para cumprir esta meta, os engenheiros de qualidade da Motorola, liderados por Bill Smith,
criaram o que chamaram de Seis Sigma, um processo de melhoria de qualidade de forte embasamento estatstico voltado para a reduo de defeitos a nveis considerados aceitveis. O
nome do processo Seis Sigma faz aluso ao conceito estatstico de desvio padro, que
simbolizado pela letra grega sigma (), e uma medida de como os valores de uma amostra
ou populao esto dispersos em torno da mdia.
Um importante conceito do Seis Sigma o de Oportunidades de Defeito, que leva em considerao trs variveis importantes:
1. Todos os diferentes defeitos que ocorrem em um produto;
2. O nmero de lugares em que os defeitos podem ocorrer no produto;
3. Todos os passos de produo que poderiam causar um ou mais desses defeitos no produto.
2
Na verdade, as aes da Petrobras so negociadas nos Estados Unidos atravs das chamadas ADRs - American
Depositary Receipts, e no diretamente. No entanto, para fins de auditoria e conformidade com as leis americanas
e para atendimento das exigncias dos investidores, a Petrobras segue em suas operaes globais partes da Lei
Sarbanes-Oxley e, por consequncia, pode ter que seguir a SAS 70, como fazem as empresas americanas.
213

Para fins de exemplificao, imaginemos estar tratando de um software. Suponhamos que:
1. 3 tipos de defeitos que podem ocorrer no produto: funcionalidades no implementadas,
funcionalidades implementadas de forma errada e baixo desempenho;
2. Os defeitos podem ocorrer em 4 partes do produto: interface com o usurio, banco de
dados, mdulos de negcio, interfaces com outros sistemas;
3. 3 etapas do processo produtivo que podem causar defeitos no produto: levantamento de
Requisitos, implementao e testes.
Neste cenrio, para obtermos o total de oportunidades de defeitos basta multiplicarmos os
fatores. Logo, teremos 3 4 3 = 36 oportunidades de defeito. Ainda neste mesmo cenrio,
suponhamos que tenham sido encontrados defeitos em 15% dos software produzidos por esta
fbrica de software, o nmero de defeitos por oportunidade ser 0, 15/36 = 0, 00416667, ou,
ento, 4, 16667 defeitos por milhar de software produzidos.
Saindo do nosso exemplo contextualizado para o mundo do software e voltando s origens
do Seis Sigma, os engenheiros da Motorola concluram que a mtrica de defeitos por milhar
no era sensvel ao que buscavam, e decidiram que os o mais adequado para eliminar os erros associados a pequenos tamanhos das amostra, seria melhor utilizar a mtrica Defeitos por
Milho de Oportunidades (DPMO). No nosso exemplo, o DPMO seria de 4166, 67.
No entanto, isoladamente, estes nmeros no do uma indicao clara do nvel de defeitos.
Para dar-lhes significados, a Motorola formulou uma escala para avaliar a qualidade de um
processo baseado nos resultados desses defeitos. No topo desta escala est o Seis Sigma, que
equivale a 3.4 DPMO, ou 99,9997% livre de defeitos. Em outras palavras, se voc tem um processo funcionando com o Seis Sigma, ter eliminado quase a totalidade do defeitos. A escala
completa definida pela metodologia mostrada na Tabela 5.1.
Nvel
Seis Sigma
Cinco Sigma
Quatro Sigma
Trs Sigma
Dois Sigma
Um Sigma
DPMO
3.4 DPMO
233 DPMO
6.210 DPMO
66.807 DPMO
308.538 DPMO
691.462 DPMO
Livre de Defeitos
99,9997%
99,98% livre de defeitos
Tabela 5.1: escala da metodologia Seis Sigma.
214

Apresentados os princpios bsicos do Seis Sigma e compreendido o objetivo da aplicao
desta metodologia, vamos agora analisar um pouco o arcabouo matemtico que a suporta.
Como mencionamos, o nome sigma () vem do fato de a medida estatstica desvio padro
ser representada por esta letra grega. Esta medida informa o quo agrupados (ou dispersos)
ao redor da mdia (ou significado, como de costume dizer na metodologia Seis Sigma) esto
os dados. Quanto mais dispersos os dados estiverem, maior ser o desvio padro.
Como a metodologia Seis Sigma considera que os dados esto distribudos segundo uma distribuio normal (representada pela famosa curva em forma de sino, tambm conhecida como
Curva de Gauss), temos o intervalo definido por um desvio padro ao redor da mdia engloba cerca de 68% dos dados. Com dois desvios, este valor j passa a cerca de 96%, e com trs
desvios padro, j so englobados quase 100% dos dados. A Figura 5.8 ilustra esta propriedade
das distribuies normais.
Figura 5.8: Curvas de Gauss.

O cerne da metodologia Seis Sigma est em calcular o valor da pontuao Sigma, tambm
conhecida como Pontuao Z, de acordo com a seguinte frmula:
SL Xm
Na frmula, SL o limite de especificao, ou seja, o valor alvo. Se pensarmos no tamanho de

uma pea que est sendo produzida, o limite de especificao seria o tamanho da pea perfeita.
J o Xm o valor mdio observado na amostra analisada. A Tabela 5.2 mostra alguns valores
de Z com seus respectivos DPMOs.
Z=
Por fim, para complementar os conhecimentos quantitativos apresentados sobre o Seis Sigma,
vamos agora nos ater um pouco do processo DMAIC, que vastamente utilizado no mercado
para a implementao desta metodologia. DMAIC um acrnimo para:
D: Definio de oportunidade
M: Medio de desempenho
215

A: Anlise de oportunidade
I: Implementao de melhoria de desempenho
C: Controle de desempenho
Z
0.0
0.5
1.0
1.5
2.0
2.5
3.0
3.5
4.0
4.5
5.0
5.5
6.0
DPMO
933193
841345
691492
500000
308538
158655
66807
22750
6210
1350
233
32
3.4
Tabela 5.2: Pontuao Z versus DPMO.

O DMAIC auto-explicativo, consistindo em um fluxo para identificao das oportunidades
de melhoria de qualidade, medio, anlise, implementao das melhorias e, por fim, controle
do desempenho, o que permite que a melhoria contnua. Alm do DMAIC, o Seis Sigma
suportado por uma srie de outras ferramentas que no sero apresentadas em detalhe neste
Captulo, mas que merecem ser mencionadas para que os leitores mais interessados nesse assunto possam se aprofundar. Exemplos dessas ferramentas so:
Envio de Funo Qualidade (QFD)
Diagrama de Espinha de Peixe
Matrizes de Causa-Efeito
Modos de falha de anlise dos efeitos (FMEA)
T-Teste
Desenhos de Experimentos (DOE)
5.5.2
BSC
O (Balanced Scorecard, ou simplesmente BSC, uma metodologia de medio e gesto estratgica de desempenho. O aspecto balanceado se deve ao fato de a escolha dos indicadores de uma organizao no se restringirem unicamente no foco econmico-financeiro,
englobando tambm aspectos mais intangveis como o desempenho junto aos clientes, desempenhos dos processos internos e das pessoas, inovao e tecnologia. Acredita-se que a somatria destes fatores o que permite alavancar o desempenho desejado pelas organizaes,
criando valor futuro.
216

Os requisitos para definio desses indicadores tratam dos processos de um modelo da administrao de servios e busca da maximizao dos resultados baseados em quatro perspectivas
que refletem a viso e estratgia empresarial:
1. Financeira;
2. Clientes;
3. Processos Internos;
4. Aprendizado e Crescimento.
A metodologia do BSC reflete o equilbrio entre os objetivos de curto e longo prazos; entre
medidas financeiras e no-financeiras; entre indicadores de tendncia e ocorrncias; entre perspectiva interna e externa do desempenho.
O BSC no um fim em si mesmo, mas uma ferramenta de gesto sob a qual orbita um modelo
organizacional chamado de Organizao Orientada para a Estratgia. Nessas organizaes, o
BSC utilizado para alinhar as unidades de negcio, as unidades de servio compartilhado,
as equipes e os indivduos em torno das metas organizacionais gerais, ou seja, alinh-los estratgia da empresa. Em uma leitura mais detalhada de cada uma das quatro perspectivas do
BSC, temos o que segue:
1. Financeira: A elaborao do BSC dever funcionar como um estmulo para que as diferentes unidades de negcio da empresa estabeleam objetivos financeiros, sempre de
acordo com a estratgia global da empresa. Os objetivos e indicadores da perspectiva financeira do BSC devem ser definidos tendo em conta a fase em que se encontra a empresa
e as suas unidades de negcio. Esta perspectiva tambm conhecida como perspectiva
do acionista, em virtude de serem eles os principais interessados na empresa, procurando a melhor rentabilidade para o capital investido e dando uma maior importncia
s questes financeiras.
2. Clientes: Deve ser utilizado um conjunto de indicadores relativos ao mercado, aos clientes
e aos potenciais clientes, devendo estabelecer-se entre eles uma cadeia de relaes: quota
de mercado; reteno de clientes; aquisio de clientes; satisfao de clientes e retorno
de clientes. O objetivo desta perspectiva preparar a organizao para oferecer aos seus
clientes um mix de produtos, preos, servios, relacionamento e imagem, no sentido de
ir ao encontro das suas necessidades, procurando conquist-los e fideliz-los.
3. Processos Internos: O BSC considera os processos internos de toda a cadeia de valor da
empresa e inclui o processo de inovao, de operaes e de ps-venda. Na perspectiva
do BSC, a empresa deve identificar quais as atividades e quais os processos necessrios
para assegurar a satisfao das necessidades dos clientes. Os indicadores internos do
BSC devem focar-se nos processos internos que tero maior impacto na satisfao dos
clientes e tambm na satisfao dos objetivos financeiros da empresa.
4. Aprendizagem e Crescimento: Essa perspectiva apresenta objetivos voltados capacidade dos funcionrios e dos sistemas de informao e motivao e ao alinhamento
destes com os objetivos da organizao. de grande importncia, pois cr-se que as habilidades de uma organizao para aprender, melhor e inovar relacionam-se diretamente
em seu valor.
217

Responder aos desafios colocados por estas quatro questes permite ajustar continuamente a
estratgia e mud-la quando necessrio.
O BSC equilibra indicadores externos para acionistas e indicadores internos de processos, inovao, aprendizagem e crescimento; equilibra os resultados do esforo passado e os indicadores dos desempenhos futuros; equilibra indicadores quantificveis e indicadores subjetivos de desempenho.
O BSC pode ser dividido nos seguintes componentes:
Mapa Estratgico: Descreve a estratgia da empresa atravs de objetivos relacionados
entre si e distribudos nas quatro perspectivas;
Objetivo Estratgico: O que deve ser alcanado e o que crtico para o sucesso da organizao;
Indicador: Como ser medido e acompanhado o sucesso do alcance do objetivo.
Por fim, merecem destaque os seguintes benefcios do uso do BSC nas organizaes:
Concilia diferentes interesses na anlise e execuo da estratgia;
Promove a comunicao da estratgia;
Considera o planejamento estratgico um ser vivo a ser testado e monitorado continuamente;
Promove o alinhamento da organizao com a estratgia;
Promove a sinergia organizacional;
Constri um sistema de gesto estratgica e vincula a estratgia com planejamento e
oramento;
Alinha indicadores de resultado com indicadores de tendncia.
5.6
5.6.1
Outros Frameworks de Governana em TI

ISO/IEC 38500
A ISO/IEC 38500 uma norma voltada para a definio de princpios e prticas para a boa
governana de TI, promovendo o uso efetivo, eficiente e aceitvel dos recursos de tecnologia
da informao nas organizaes. Ainda conforme esta norma, estes objetivos so alcanados:
atravs da garantia aos stakeholders de que, caso a norma seja seguida, eles podem confiar na governana de TI da organizao;
informando e guiando os diretores para uma boa governana de TI na organizao;
provendo uma base para a avaliao da governana de TI na organizao.
218

Em termos mais detalhados, podemos dizer que a norma ISO/IEC 38500 auxilia os diretores a
assegurar a conformidade da organizao com suas obrigaes regulatrias, legais e contratuais relativas ao uso de TI. Alm disso, a norma auxilia os diretores a garantir que a TI contribui
de forma positiva para o desempenho geral da organizao.
Entre os aspectos relativos conformidade que podem ser endereados pela norma, podemos
listar padres de segurana, legislaes especficas de spams, privacidade e prticas comerciais, legislaes relativas a direitos autorais, entre outras. No que se refere ao desempenho da
organizao, a norma ajuda a enderear aspectos como alinhamento da TI com os requisitos
de negcio, eficiente alocao de recursos, reduo dos custos da organizao por meio da TI,
implementao de boas prticas no relacionamento com os stakeholders etc.
Uma vez apresentados os benefcios oferecidos pela utilizao da ISO/IEC 38500, vamos agora
conhecer os seis princpios em que se baseiam a norma.
1. Responsabilidade: Os indivduos e grupos na organizao devem compreender e aceitar
as suas responsabilidades no fornecimento e na demanda de TI. Alm disso, os indivduos responsveis por aes devem ter a autoridade para as desempenharem;
2. Estratgia: A estratgia de negcio da organizao leva em conta as capacidades atuais
e futuras de TI, e os planos estratgicos para a TI satisfazem as necessidades atuais e
continuadas da estratgia de negcio da organizao;
3. Aquisies: As aquisies de TI so feitas por razes vlidas, com base e anlise apropriada e continua, atravs de decises claras e transparentes. H um equilbrio adequado
entre os benefcios, oportunidades, custos e riscos, tanto no curto como no longo prazo;
4. Desempenho: A TI adequada finalidade de suporte da organizao, disponibilizao de servios e aos nveis e qualidade dos servios necessrios para responder aos
requisitos atuais e futuros do negcio;
5. Conformidade: A TI encontra-se em conformidade com a legislao e regulamentos
aplicveis. As polticas e as prticas esto claramente definidas, encontram-se implementadas e so aplicadas;
6. Comportamento Humano: As polticas, prticas e decises nas TI revelam respeito pelo
comportamento humano, incluindo as necessidades atuais e a evoluo das necessidades
de todas os envolvidos no processo.
Alm de definir estes seis princpios, a norma ISO/IEC 38500 ainda define explicitamente,
por meio de um modelo, a forma que os diretores devem governar a TI da organizao. Este
modelo se baseia na execuo de trs tarefas que so:
1. Avaliar: Nesta tarefa, os diretores devem fazer julgamentos sobre a uso e adequao
atuais e futuros da TI, levando em considerao presses internas e externas, como mudanas tecnolgicas, tendncias econmicas e sociais, e influncias polticas;
2. Dirigir: Os diretores devem direcionar a preparao e implementao de planos e polticas para garantir que o uso da TI atenda os requisitos de negcio. Para alcanar isso,
devem definir a direo dos investimentos, garantir o bom gerenciamento dos projetos e
da operao da TI, alm de encorajar as boas prticas de governana;
219

3. Monitorar: Os diretores devem monitorar a conformidade das polticas e o desempenho
delas contra o planejado, levando em conta, principalmente, a aderncia dos planos e
seu atendimento aos requisitos de negcio. Nesta tarefa, os diretores tambm devem assegurar que a TI est cumprindo suas obrigaes externas, sejam elas legais, regulatrias
ou contratuais.
Para ilustrar como so orquestrados os princpios e as tarefas dos diretores da organizao, a
norma ISO/IEC 38500 apresenta a Figura 5.9.
Figura 5.9: ISO/IEC 38500.
5.6.2
Val IT
O Val IT um framework de governana que tem por objetivo permitir a criao de valor para
o negcio a partir de investimentos em TI, ou como o mercado gosta de dizer, a partir dos
chamados IT-enabled services. Assim como o COBIT, o Val IT foi desenhado pela ISACA (Information Systems Audit and Control Association).
Segundo esta associao, o Val IT foi projetado para se alinhar e para complementar o COBIT, sendo constitudo de um conjunto de princpios prticos e comprovados de governana,
processos, e diretrizes para auxiliar os lderes das organizaes a otimizar a criao de valor a
partir de investimentos em TI.
Segundo o documento que define o Val IT, entender o relacionamento entre estes dois frameworks (Val IT e COBIT) uma tarefa vital. Da sua parte, o Val IT ajuda os lderes da organizao
a se focarem em duas das quatro questes fundamentais relacionadas a governana de TI:
220

Estamos fazendo as coisas corretas? (A questo Estratgia)
Estamos obtendo benefcios? (A questo Valor)
J o COBIT, permite que os lderes se concentrem nas outras duas questes que so:
Estamos fazendo as coisas do modo certo? (A questo Arquitetura)
Estamos cumprindo nossos objetivos bem? (A questo Entrega)
A Figura 5.10 foi retirada da especificao do Val IT, e ilustra as quatro questes fundamentais
da governana de TI e como elas interagem entre si de forma cclica.
Figura 5.10: as quatro questes da governana.

Um outro conceito chave para o entendimento do Val IT o conceito de valor. Dentro do
framework, valor definido como o total de benefcios lquidos gerados a partir dos custos
relacionados, ajustados ao risco e, no caso de valores financeiros, ajustados tambm pelo valor
do dinheiro no tempo. Por total de benefcios deve se entender o conjunto de benefcios
gerados durante todo o ciclo de vida do recurso ou servio de TI no qual o investimento foi
realizado.
221

Obviamente, os diversos stakeholders possuem diferentes pontos de vista sobre o que representa valor. Diante disso, um dos objetivos do gerenciamento do valor otimiz-lo atravs da
conciliao destas diferenas permitindo que a organizao:
defina e comunique o que constitui valor;
selecione e execute investimentos;
gerencie seus ativos e otimize seu valor a partir de uma utilizao econmica e a um
nvel de risco aceitvel.
Assim como o COBIT, o Val IT tambm organizado em domnios e processos. Os trs
domnios do Val IT so mostrados a seguir com suas nomenclaturas originais em ingls:
1. Value governance (VG): O objetivo deste domnio assegurar que as prticas de gerenciamento de valor faam parte da organizao, permitindo que se alcance o valor timo
para os investimentos de TI durante todo o seu ciclo de vida econmico;
2. Portfolio management (PM): O objetivo deste domnio , no contexto do framework Val
IT, garantir que a organizao assegure o valor ideal em toda a sua carteira de investimentos de TI;
3. Investment management (IM): O objetivo deste domnio garantir que os investimentos
de TI individualmente contribuam para o alcance do valor ideal.
Cada um dos trs domnios se desdobram em uma srie de processos, que sero apresentados
a seguir tambm em sua nomenclatura original:
Value Governance
VG1 Establish informed and committed leadership.
VG2 Define and implement processes.
VG3 Define portfolio characteristics.
VG4 Align and integrate value management with enterprise financial planning.
VG5 Establish effective governance monitoring.
VG6 Continuously improve value management practices
Portfolio Management
PM1 Establish strategic direction and target investment mix.
PM2 Determine the availability and sources of funds.
PM3 Manage the availability of human resources.
PM4 Evaluate and select programmes to fund.
PM5 Monitor and report on investment portfolio performance.
PM6 Optimise investment portfolio performance.
222

Investment Management
IM1 Develop and evaluate the initial programme concept business case.
IM2 Understand the candidate programme and implementation options.
IM3 Develop the programme plan.
IM4 Develop full life-cycle costs and benefits.
IM5 Develop the detailed candidate programme business case.
IM6 Launch and manage the programme.
IM7 Update operational IT portfolios.
IM8 Update the business case.
IM9 Monitor and report on the programme.
IM10 Retire the programme.
Figura 5.11: domnio e processos do Val IT.

Para cada um dos trs domnios do Val IT, o framework define regras para a classificar a implementao do Val IT na organizao em termos de sua maturidade. Esse modelo de maturidade
baseado no modelo CMMI, e para cada um dos domnios so definidos, portanto, 6 nveis
de maturidade que so:
1. No existente
2. Inicial
223

3. Repetitivo
4. Definido
5. Gerenciado
6. Otimizado
Para obter mais detalhes dos requisitos para que a a implementao do Val IT para cada um
dos domnios sejam classificado em cada um dos nveis de maturidade, recomendamos que a
documentao oficial do framework seja consultada. Embora os requisitos para se enquadrar
em cada um dos nveis sejam definidos em apenas um pargrafo no framework, ainda assim
so detalhados demais para o objetivo deste texto.
Um outra caracterstica de grande importncia no framework Val IT a diviso de papis e
responsabilidades, que exemplificada na norma atravs de uma Matriz RACI (responsible,
accountable, consulted and informed). Como o seu prprio nome sugere, a Matriz RACI define o nvel de envolvimento que cada um dos papis possui em cada um dos processos. A
Figura 5.12, trazida pela documentao oficial do Val IT, exemplifica uma Matriz RACI.
Concluindo esta breve apresentao sobre o Val IT, merecem ser destacadas algumas de suas
caractersticas. O Val IT um framework de governana de TI que fornece uma viso mais
estratgica e menos operacional que o COBIT. , portanto, um framework mais voltado para a
alta administrao da empresa, j que est est preocupada mais com os retornos dos investimentos em TI, e no com questes de baixo nvel que digam respeito ao modo de operao da
TI.
Outro trao importante do Val IT a nfase no conceito de valor, que representa os benefcios lquidos financeiros ou no que os investimentos em TI so capazes de oferecer
organizao durante todo o seu ciclo de vida. No caso de anlises financeiras, fatores como
custo, risco e o valor do dinheiro no tempo so tambm enfatizados, j que estes so conceitos
em que se baseiam boa parte das decises estratgicas das organizaes.
224
Figura 5.12: Matriz RACI - Val IT.
225
ndice Remissivo
ndice Remissivo
reas de Processos, 173
1st Level Support, 39
2nd Level Support, 39
3rd Level Support, 39
4 Ps da Estratgia de Servio, 24
4 Ps do Desenho de Servio, 27
Ao Corretiva, 161
Ao Preventiva, 161
Access Management, 39
Access Manager, 39
ACn, 82
Acordo de Basileia, 203
Acordo de Confidencialidade, 189
Acquire and Implement, 71
AGATE, 193
Alinhamento estratgico, 88
American Accounting Association (AAA), 206
American Institute of Certified Public Accountants (AICPA), 206
An exemplar process assessment model, 166
ANSI/IEEE 1471:2000, 192
APM Group Ltd, 20
Application Management, 18
Application Portfolio, 48
Arquitetura Corporativa, 71, 192
Atributo de Controle de Processo (AP 4.2), 168
Atributo de Definio de Processo (AP 3.1),
168
Atributo de Desempenho do Processo (AP 1.1),
168
Atributo de Gerncia de Produto de Trabalho
(AP 2.2), 168
Atributo de Gerncia do Desempenho (AP 2.1),
168
Atributo de Inovao de Processo (AP 5.1), 168
Atributo de Instanciao de Processo (AP 3.2),
168
Atributo de Medio de Processo (AP 4.1), 168
Atributo de Otimizao de Processo (AP 5.2),
169
Atributos de Processo (APs), 168, 185

Auditoria Interna, 161
Availability Management, 19, 28
Availability Manager, 30
Availability Plan, 48
Balanced Scorecard, 216
Baseline, 48
Benchmark, 49
Brainstorming, 49
BS 15000, 17
Business Continuity Management (BCM), 49
Business Continuity Plan (BCP), 29, 49
Business Continuity Strategy, 49
Business Impact Analysis (BIA), 29, 50
Business Relationship Manager (BRM), 26, 50
Call Center, 50
Capability Maturity Model Integration, 171
Capacity Management, 19, 28
Capacity Management Information System (CMIS),
28, 50
Capacity Manager, 30
Capacity Plan, 28, 50
Carnegie Mellon, 209
Caso Watergate, 200
CCTA (Central Computer and Telecommunications Agency), 14
Change Advisory Board (CAB), 34, 51
Change Authority, 34
Change Management, 19, 31
Change Manager, 34
Change Model, 51
Change Proposal, 51
Change Record, 51
Chief Sourcing Officer (CSO), 26
CMM for Acquisition, 179
CMM for Development, 179
CMM for Services, 179
CMMI, 18, 165167, 171, 179, 223
CMMI Model Foundation (CMF), 179
226
ndice Remissivo
CMMI-ACQ, 179
CMMI-DEV, 179
CMMI-SVC, 179
COBIT, 17, 63
COCO, 205
Comisso de Valores Mobilirios (CVM), 203
Comit das Organizaes Patrocinadoras, 200
Concepts and Vocabulary, 165
Confiabilidade, 68
Confidencialidade, 68
Configuration Item (CI), 51
Configuration Management, 19
Configuration Management Database (CMDB),
51
Configuration Management System (CMS), 52
Configuration Manager, 34
Configuration Record, 52
Conformidade, 68
Conselho Monetrio Nacional (CMN), 204
Constelaes, 179
Consultores de Aquisio, 190
Continual Service Improvement, 40
Continuum Corporativo, 196
Continuum Enterprise, 196
Contract Portfolio, 52
Controle da No-Conformidade de Produtos,
161
Controle de Documentos, 161
Controle de Registros, 161
Controle Interno, 69
COSO, 69, 200, 205
COSO 2, 207
COSO ERM, 207
Cost Center, 52
Critical Success Factor (CSF), 53
Critical Success Factors (CSFs), 43
CSI Manager, 43
Customer Agreement Portfolio, 53
Customer Portfolio, 53
Definitive Media Library (DML), 53
Definitive Software Library (DSL), 53
Deliver and Support, 71
Demand Management, 26
Dimenso da Capacidade do Processo, 169
Dimenso de Processo, 169
Disciplina de Mercado, 203
Disponibilidade, 68
DMAIC, 215
DoDAF, 193
DOE, 216
DPMO, 214
DTR (Draft Technical Report), 165
Due Diligence, 200
e-Sourcing, 208
E-SOx, 202
Efetividade, 68
Effectiveness, 53
Efficiency, 54
Eficincia, 68
EIA 731, 171
Emergency Change, 54
Emergency Change Advisory Board (ECAB),
34, 54
Entrega de valor, 89
eSCM-CL, 211
eSCM-SP, 209
Evaluation, 34
Event Management, 35
Facilities Manager, 40
Federal Enterprise Architecture (FEA), 193, 198
Financial Executives International (FEI), 206
Financial Management, 19, 25
Financial Manager, 26
FMEA, 216
Foreign Corrupt Practices Act (FCPA), 205
Framework Zachman, 193
Functional Escalation, 54
Gartner, 192
Gerenciamento de Processos, 174
Gerenciamento de Projetos, 174
Gerenciamento de Servios de TI, 14
Gerenciar Requisitos, 173
Gesto da Qualidade, 160
Gesto de recursos, 89
Gesto de risco, 89
Governana, 12
Governana Corporativa, 12
Governana de TI, 12, 63
Guidance on performing an assessment, 166
Guidance on using assessment results, 166
Hierarchic Escalation, 54
ICT Infrastructure Management, 18
Identity Management, 39
Incident Management, 19, 36
227
ndice Remissivo
Incident Manager, 40
Indicadores de Performance, 86
Information Security Management, 29, 54
Information Security Policy, 54
Instituio Avaliadora, 189
Instituies Organizadoras de Grupos de Empresas (IOGE), 190
Institute of Internal Auditors (IIA), 206
Institute of Management Accountants (IMA),
206
Integridade, 68
International Organization for Standardization,
160
Investment management (IM), 222
ISACA (Information Systems Audit and Control Association), 17
Ishikawa Diagram, 54
ISO (International Organization for Standardization), 17, 165
ISO 20000, 17
ISO 9000:2000, 160
ISO 9001:2000, 161
ISO/IEC 12207, 162, 165
ISO/IEC 15288, 166
ISO/IEC 15504, 165, 189
ISO/IEC TR 15504, 165
IT Designer/Architect, 30
IT Operations Manager, 40
IT Operator, 40
IT Planner, 30
IT Service Continuity Management, 29
IT Service Continuity Manager, 30
IT Service Continuity Plan, 55
IT Steering Group (ISG), 26
ITIL Expert Level, 47
ITIL Foundation, 47
ITIL Intermediate Level, 47
ITIL Master Qualification, 48
ITIL Original, 18
ITIL V2, 18
ITIL V3, 14
itSMF, 21
J-SOx, 202
Kano Model, 55
Kepner and Tregoe Analysis, 55
Key Goal Indicators (KGI), 86
Key Performance Indicators (KPI), 43, 86
King Report, 205
Knowledge Management, 33
Knowledge Manager, 34
Known Error Database (KEDB), 55
Lei de Reforma do Gerenciamento da Tecnologia de Informao, 192
MA-MPS, 167, 184, 189
Maintenance Plan, 55
Major Incident Team, 40
Major Problem Review, 38
Management Information System (MIS), 55
Matriz de Rastreabilidade, 173
Matriz RACI, 88, 224
Mean Time Between Failures (MTBF), 55
Mean Time Between Service Incidents (MTBSI),
56
Mean Time to Repair (MTTR), 56
Mean Time to Restore Service (MTRS), 56
Medidas de Resultados, 86
Mensurao de desempenho, 89
Minor Change Deployment, 32
MN-MPS, 190
MODAF, 193
Modelo de Maturidade, 83
Modelo de Processo, 159
Modelo de Referncia de Processo, 166
Modelo de Referncia para Melhoria de Processo, 165
Modelo para Avaliao de Processo, 166
Modelos de Provimento de Servio, 25
Modularidade, 163
Monitor and Evaluate, 71
MPS.Br, 167
MR-MPS, 166, 184, 185
Nveis de Capacidade, 165
NBR ISO 9000:2000, 160
Objetivos de Atividade, 67
Objetivos de Controle, 67
Objetivos de Negcio, 66
Objetivos de Processo, 67
Objetivos de TI, 67
OGC (Office for Government Commerce), 14
OOSpice, 166
Open Group, 192
Operational Level Agreement (OLA), 56
Oportunidades de Defeito, 213
Organizao Orientada para a Estratgia, 217
228
ndice Remissivo
Pareto Principle, 56
PCAOB, 202
PCn, 81
PDTR (Previous Draft Technical Report), 165
People-CMM, 171
Performing an Assessment, 165
Plan and Organise, 71
Plan, Do, Check and Act (PDCA), 56
Planejar e Preparar Avaliao, 189
Planning to Implement Service Management,
19
Plano de Avaliao, 189
Pontuao Z, 215
Portfolio management (PM), 222
Post-implementation Review (PIR), 57
Problem Management, 19, 37
Problem Manager, 40
Process Manager, 57
Processo de Aquisio, 163
Processo de Auditoria, 164
Processo de Desenvolvimento, 163
Processo de Documentao, 163
Processo de Formao, 164
Processo de Fornecimento, 163
Processo de Garantia da Qualidade, 163
Processo de Gesto, 164
Processo de Gesto de Configuraes, 163
Processo de Infraestrutura, 164
Processo de Manuteno, 163
Processo de Melhoria, 164
Processo de Operao, 163
Processo de Resoluo de problemas, 164
Processo de Reviso, 164
Processo de Software, 159
Processo de Validao, 163
Processo de Verificao, 163
Processos de Ciclo de Vida de Software, 162
Processos de Suporte, 163
Processos de TI, 70
Processos Organizacionais, 163
Processos Primrios, 163
Processos Principais, 163
Product Manager, 26
Profit Center, 57
Project Charter, 57
Project Manager, 34
Project Plan, 57
Project Portfolio, 57
Public Company Accounting Oversight Board,

202
QFD, 216
Qualidade de Software, 159
QuickLocus, 167
Recovery Plan, 57
Recursos de TI, 68
Release and Deployment Management, 33
Release and Deployment Manager, 34
Release Management, 19
Release Policy, 58
Representao Contnua, 174, 178
Representao em Estgios, 175
Request for Change (RFC), 58
Request Fulfillment, 38
Request Model, 58
Resoluo 3380/2006, 203
Responsabilidade, 163
Return on Investment (ROI), 58
Reviso pela Superviso, 203
Rights Management, 39
Risco Operacional, 204
Risk Management, 29
Root Cause Analysis (RCA), 58
SACMM, 171
Sarbanes-Oxley (SOx), 64, 201, 212
SAS 70, 212
SCAMPI, 167
SE-CMM, 171
SECAN, 171
Security Management, 18
Security Management Information System (SMIS),
58
Security Manager, 30
Segmento de rea de Misso Central, 198
Segmento de Servios do Negcio, 198
Seis Sigma, 213
Servio corporativo, 198
Servio de TI, 14
Service Asset and Configuration Management,
32, 58
Service Catalogue, 59
Service Catalogue Management, 27
Service Catalogue Manager, 30
Service Charter, 59
Service Continuity Management, 19
Service Delivery, 18
229
ndice Remissivo
Service Design, 26
Service Design Manager, 30
Service Design Package (SDP), 23, 59
Service Desk, 59
Service Desk Manager, 40
Service Desk Supervisor, 40
Service Improvement Plan (SIP), 60
Service Knowledge Management System, 23,
60
Service Level Agreement (SLA), 60
Service Level Management, 19, 27
Service Level Manager, 30
Service Level Package (SLP), 23, 60
Service Level Report (SLR), 61
Service Level Requirement (SLR), 61
Service Lifecycle, 61
Service Manager, 43
Service Measurement, 42
Service Operation, 35
Service Owner, 30
Service Portfolio, 61
Service Portfolio Management, 25
Service Portfolio Manager, 26
Service Reporting, 43
Service Request Fulfilment Group, 40
Service Specsheet, 61
Service Strategy, 23
Service Support, 18
Service Transition, 31
Service Transition Manager, 35
Service Transition Plan, 57
Service Utility, 25
Service Validation and Testing, 33
Service Warranty, 25
Sistema de Acompanhamento de Requisitos,
173
Softex, 190
Software Asset Management, 18
Software Engineering Institute (SEI), 18
Software Process Assessment, 165
Software Process Improvement and Capability Determination, 165
Sourcing, 208
SPICE, 165
Strategy Generation, 25
Supplier and Contract Database (SCD), 61
Supplier and Contract Management Information System (SCMIS), 62
Supplier Management, 30
Supplier Manager, 30
SW-CMM, 165, 171, 178
T-Teste, 216
Tabela de caracterizao de atributos do processo, 190
TAFIM, 192
Technical Architecture Framework for Information Management, 192
Test Manager, 35
The 7 Improvement Process, 40
The Business Perspective, 18
The Open Group Architecture Framework, 192,
195
Tipos de Provedores de Servio, 25
TOGAF, 195
TOGAF Architecture Development Method (ADM),
196
TOGAF Resource Base, 196
TOGAF Standards Information Base (SIB), 196
TOGAF Technical Reference Model (TRM), 196
TR (Technical Report), 165
Transition Planning and Support, 31
Turnbull Report, 205
Underpinning Contract (UC), 62
Value governance (VG), 222
Vital Business Function (VBF), 62
Workaround, 62
230

Governança TI concursos

Încărcat de

Informații document

Descriere originală:

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Governança TI concursos

Încărcat de

Drepturi de autor:

Formate disponibile

Governana de TI

ITIL V3 - Information Technology Infrastructure Library

Service Transition (Transio de Servio) . . . . . . . . . . . . . . . . . .

COBIT 4.1 - Control Objectives for Information and related Technology

3.5.4 Monitorar e Avaliar (ME) . . . . . . . . . . . . . . . . . . . . . . . . . .

Normas para Qualidade de Software

Tpicos Especiais em Governana de TI

4.2.3 ISO/IEC 12207 . . . . . . . . . . . . . . . . . . .

A Srie de Volumes Tericos

A Srie de Volumes Tericos

Captulo 1. Princpios de Governana de TI

Governana o conjunto de processos, costumes, polticas, leis, regulamentos e instituies

Captulo 1. Princpios de Governana de TI

Captulo 2. ITIL V3 - Information Technology Infrastructure Library

ITIL V3 - Information Technology

Captulo 2. ITIL V3 - Information Technology Infrastructure Library

Captulo 2. ITIL V3 - Information Technology Infrastructure Library

Figura 2.1: capas dos livros oficiais da ITIL V3.

Captulo 2. ITIL V3 - Information Technology Infrastructure Library

Padres Relacionados ITIL

Captulo 2. ITIL V3 - Information Technology Infrastructure Library

Histrico e Principais Diferenas entre as Verses do ITIL

Captulo 2. ITIL V3 - Information Technology Infrastructure Library

Figura 2.2: interfaces entre os volumes da ITIL V2.

Captulo 2. ITIL V3 - Information Technology Infrastructure Library

Principais Instituies Envolvidas com a ITIL

Captulo 2. ITIL V3 - Information Technology Infrastructure Library

Os Livros da ITIL V3 e as suas Disciplinas

So descritas nesta Seo todas as 26 disciplinas (processos) da terceira verso da ITIL. Em

Captulo 2. ITIL V3 - Information Technology Infrastructure Library

Figura 2.3: resumo grfico dos livros da ITIL V3.

Captulo 2. ITIL V3 - Information Technology Infrastructure Library

Service Strategy (Estratgia de Servio)

Captulo 2. ITIL V3 - Information Technology Infrastructure Library

Captulo 2. ITIL V3 - Information Technology Infrastructure Library

Captulo 2. ITIL V3 - Information Technology Infrastructure Library

Service Design (Desenho de Servio)

O Volume Service Design fornece orientaes para a concepo e o desenvolvimento de servios

Captulo 2. ITIL V3 - Information Technology Infrastructure Library

Captulo 2. ITIL V3 - Information Technology Infrastructure Library

Captulo 2. ITIL V3 - Information Technology Infrastructure Library

Captulo 2. ITIL V3 - Information Technology Infrastructure Library

Captulo 2. ITIL V3 - Information Technology Infrastructure Library

Service Transition (Transio de Servio)

O Volume Service Transition fornece orientaes para o desenvolvimento e a melhoria de

Captulo 2. ITIL V3 - Information Technology Infrastructure Library

Figura 2.5: escopo do processo Gerenciamento de Mudana. Figura retirada do documento

Captulo 2. ITIL V3 - Information Technology Infrastructure Library

Captulo 2. ITIL V3 - Information Technology Infrastructure Library

Captulo 2. ITIL V3 - Information Technology Infrastructure Library

Service Operation (Operao de Servio)

Captulo 2. ITIL V3 - Information Technology Infrastructure Library

Captulo 2. ITIL V3 - Information Technology Infrastructure Library

Figura 2.6: ciclo de vida de incidente.

Captulo 2. ITIL V3 - Information Technology Infrastructure Library

Captulo 2. ITIL V3 - Information Technology Infrastructure Library

Captulo 2. ITIL V3 - Information Technology Infrastructure Library

Continual Service Improvement (Melhoria Contnua de Servio)

Captulo 2. ITIL V3 - Information Technology Infrastructure Library

Figura 2.7: ilustrao do Processo de Melhoria em 7 Etapas. Figura retirada do documento

Captulo 2. ITIL V3 - Information Technology Infrastructure Library

Captulo 2. ITIL V3 - Information Technology Infrastructure Library