ITIL

IT Service Management Foundations

1
 El contenido de esta presentación es
protegido por leyes de derecho de autor

2
Agenda del Curso
 Sesión 1 Martes 29 de Noviembre de 2005
 Gestión por Procesos e Introducción a ITIL
 Gestión de la Configuración
 Service Desk

 Sesión 2 Jueves 1 de Diciembre de 2005

 Gestión de Incidentes
 Gestión de Problemas
 Gestión de Cambios

 Sesión 3 Martes 6 de Diciembre de 2005

 Gestión de Releases

3
Agenda del Curso
 Sesión 4 Lunes 12 de Diciembre de 2005
 Gestión de Niveles de Servicio
 Gestión Financiera para los Servicios de IT

 Sesión 5 Martes 13 de Diciembre de 2005

 Gestión de la Continuidad del Servicio
 Gestión de la Disponibilidad

 Sesión 6 Miércoles 16 de Diciembre de 2005

 Gestión de la Capacidad
 Gestión de la Seguridad
 Examen de Prueba

4
Agenda del Curso

 Horario: 5:00 PM a 9:00 PM.

 Cupo de 20 personas.

5
Objetivos del Curso
 Proporcionar la información necesaria para
entender los siguientes aspectos:
 El marco ITIL
 Los procesos ITIL de soporte y Entrega de
Servicios y la Función “Centro de Servicio al
Cliente”
 Conceptos ITIL, objetivos de los procesos,
actividades y relaciones entre procesos
 Preparar participantes para el examen “ITIL
Foundation Certification Exam”
6
Formato del Curso
 Para cada proceso o función ITIL:
 Objetivo del Proceso
 Terminología Básica
 Actividades
 Relación con otros Procesos
 Ejercicios – Afinando tu conocimiento

7
 ITIL

Introducción

8
Qué es ITIL?
 ITIL: Information Technology Infrastructure
Library
 Un Conjunto documentado de mejores
prácticas, orientadas a la administración de
los servicios TI a través de un enfoque basado
en procesos:

Adicional
 Descripción completa de los procesos necesarios
para administrar la infraestructura de TI.
 Provee servicio óptimo a un costo justificado y
9
Que es ITIL?
 Alinea los servicios de TI con los requerimientos
del negocio.
 Considerado el marco referencial, a lo que se
refiere a la Administración de Servicios de TI.
 Lenguaje común y dominio público (igual
metodología de trabajo).
 Provee guía, no es un manual con pasos a
seguir.
 Es independiente de la infraestructura
tecnológica utilizada, sector del negocio y la
estructura organizacional.
 Aplicable a organizaciones grandes y pequeñas.

10
ITIL - Historia
 Desarrollado a finales de 1980 en el Reino
Unido
 Por la Oficina de Gobierno (Office of
Govermment Commerce (OGC).
 Comenzó como guía para mejorar los
servicios de TI en el sector Gobierno.
 Adoptado por muchas empresas como base
para la administración de servicios TI.
 Marco estándar de referencia para la
Administración de servicios TI en Europa.
11
ITIL - Organizaciones
 Office of Government Commerce (OGC)
 EXIN – Examination Institute for Infomation
Science.
 ISEB – Information Systems Examinations
Board, British Computer Society.
 Loyalist College.
 Information Technology Service Management
Forum – itSMF.
 Proveedores importantes de tecnologia.
12
ITIL - Certificaciones

13
Perspectiva Conceptual
 Cliente – Persona (generalmente gerente de alto
rango), quién solicita, paga y es dueño de uno o
varios servicios que TI ofrece. Autorizado a negociar
con TI por parte del negocio.

 Usuario – Persona que utiliza el servicio de manera

cotidiana.

 Servicio TI – Conjunto de facilidades TI & no-TI que

cubren necesidades a clientes, apoya los objetivos
del negocio y es percibido por el cliente como un
producto.
14
Perspectiva Conceptual
 Administración de Servicios – Todo lo referente a la
entrega y soporte de servicios TI orientados al cliente
bajo un enfoque de procesos y alineados con los
objetivos del negocio.

 Administración de Sistemas vs. Administración de

Servicios
 Orientación Técnica vs Orientación Clientes
 Orientación a Departamento vs Orientación a procesos
 Monitoreo de Componentes vs Monitoreo de Servicios

15
16
17
Perspectiva Conceptual
 Proceso – Es una serie de actividades lógicamente
relacionadas dirigidas hacia un objetivo definido

 Convierte la entrada en salida o resultado

 ¿Qué se tiene que hacer?
 ¿Cuáles son los resultados esperados?
 ¿Cómo medimos si los procesos entregan el resultado
esperado?
 ¿Cómo los resultados de un proceso afectan a otro
proceso?

18
Perspectiva Conceptual
 Procedimiento – La descripción de actividades
logicamente relacionadas y quienes la realizan.

 Iniciado por un disparador externo (entrada)

 Puede tener conexiones con otros procedimientos.
 Describe Quién, Qué, Cuándo, Dónde

 Instrucciones de Trabajo – detalle “Cómo” hacer

algo, paso por paso.

19
20
21
22
23
24
25
Afinando tu conocimiento
 ¿Qué papel juega ITIL en la Administración
de Servicios?

A. Proporciona un enfoque basado en las

mejores prácticas
B. Sirve como un estándar internacional de
itSM
C. Sirve como un estándar en el modelo de
entrega de servicios TI
D. Sirve como marco teórico para el diseño de
procesos
26
Afinando tu conocimiento
 ¿Cuál de los siguientes no es un
componente de un proceso?

A. Servicio
B. Actividad
C. Regla – Lineamiento
D. Salida

27
 SECCION 2

PROCESOS ITIL DE SOPORTE DE

SERVICIOS

28
29
 ITIL

Administración de la Configuración

30
Objetivo
 Administración de la configuración
proporciona un modelo lógico de la
infraestructura o servicio identificando:

 Controlando
 Manteniendo
 y verificando las versiones de los
Elementos de Configuración (CI´s –
Configuration Item) en existencia.

31
Terminología Básica
 Infraestructura TI – La suma referida al
hardware, software, facilidades de
telecomunicación de datos, procedimientos, y
documentación de una organización TI.

 Elemento de Configuración (CI –

Configuration Item) – Un elemento asociado
con una infraestructura TI- que está o estará
bajo el control de la administración de la
configuración.

32
Terminología Básica
 Base de Datos de la Administración de la
Configuración (CMDB – Configuration
Managament Database) – contiene todos los
detalles pertinentes de cada CI (Configuration
Item) y sus relaciones importantes entre CI´s.

 Atributos – detalles que identifican

exclusivamente un CI:
 Nombre de CI, Numero de Serial, Ubicación,
etc.

33
Terminología Básica
 Nivel del Elemento de Configuración (CI
Level) – El grado de detalle utilizado para
describir un CI.
 ¿Se incluye el mouse, unidad de
procesamiento central (CPU) y el teclado para
un PC?
 Alcance – El área ó cobertura de
responsabilidad que cubre la administración
de la configuración y amplitud del CMDB.

34
Terminología Básica
 ¿Qué parte de la infraestructura TI debe de ser
controlada por la Administración de la Configuración?
 ¿Incluimos teléfonos, faxes, y documentación?

 Relaciones – La descripción de las interfaces entre

CI´s
 Un CI forma parte de otro CI
 Un CI esta conectado a otro CI
 Un CI utiliza otro CI

35
36
Terminología Básica
 Línea de Referencia – Configuración de un
producto o sistema establecido en un tiempo
específico

 Permite a un producto o sistema ser

reconstruido
 Fotografía de un grupo de CI´s en un tiempo
especifico (ejemplo: estándar desktop, punto
de regreso)

37
Terminología Básica
 Administración de Activos Vs. Configuración

Admon.. Activos Admon.. Configuración

¿Qué tenemos? ¿Quién lo utiliza?

¿Dónde se encuentra? ¿Qué depende de esto?

¿En qué estado? ¿De qué depende?

¿Quién es responsable? ¿De qué forma parte?

38
39
40
41
42
43
44
 Afinando tu conocimiento
 ¿Cuál es la diferencia entre la administración de activos y la
administración de la configuración?

A. Administración de activos se ocupa solo del inventario existente; la

administración de la configuración se ocupa de toda la
infraestructura

B. La administración de activos es un subconjunto de la

administración de la configuración porque incluye activos no-TI,
tales como, sillas y mesas

C. Administración de activos se ocupa de los aspectos financieros de

elementos de configuración; administración de la configuración se
ocupa solo de detalles técnicos de la infraestructura

D. Administración de la configuración es mucho más amplia que la

administración de activos, porque define también las relaciones
45 entre activos
Afinando tu conocimiento
 ¿Cuál de los siguientes, NO es un ejemplo
de un elemento de configuración?

A. Manual del Usuario

B. Red Local
C. Número de Versión
D. Estación de Trabajo

46
 ITIL

Centro de Servicio al Cliente

47
Objetivo
 Proporcionar un punto único de contacto
(SPOC) para cliente y usuarios finales de los
Servicios TI

 Facilitar la restauración del servicio normal de

operaciones con un impacto mínimo al
negocio del cliente, dentro de los niveles de
servicio acordados y las prioridades del
negocio.

48
Terminología Básica
 Punto Único de Contacto (SPOC)

 Punto de entrada de incidentes

 Punto de entrada de solicitudes de servicio
 Punto de entrada de preguntas o inquietudes
 Proporciona recomendaciones, guía &
restauración rápida del servicio

49
Terminología Básica
 Solicitud de Servicio – Todo Incidente que no
constituye una falla en la infraestructura de
TI:
 Solicitudes para la mudanza de equipos,
instalaciones y consumibles
 Preguntas sobre aplicaciones
 Solicitud de cambios (RFC – Request for
Change)
 Reponer contraseña

50
Terminología Básica
 Centro de Llamadas
 Registra, descripción llamada.
 Maneja un gran volumen de llamadas de usuarios
 Las llamadas se re-direccionan (no se provee
solución)

 Escritorio o Mesa de Ayuda

 Registra, coordina, resuelve y hace seguimiento a los
incidentes
 No recibe solicitudes de servicio
 No realiza actividades que pertenecen a otros
procesos

51
Terminología Básica
 Centro de Servicio al Cliente

 Extiende la gama de servicios y ofrece un

enfoque global, permitiendo a los procesos del
negocio ser integrados a la administración de
servicios de infraestructura

52
Terminología Básica
 Centro No Calificado de Servicio al Cliente
 Habilidades y experiencia limitada
 Soporte limitado
 Registra y re-direcciona llamadas

 Centro Calificado de Servicio al Cliente

 Mayor habilidad y experiencia
 Más alta tasa de resolución a la primera llamada
 Algunos incidentes se dirigen a equipos de soporte

53
Terminología Básica
 Centro Experto de Servicio al Cliente

 Especialistas
 Soluciona la mayoría de los incidentes
independientemente

54
Centro de Servicio al Cliente -
Modelos
 Centro Local de Servicio al Cliente
 Centros de soporte local para satisfacer
necesidades locales del negocio
 Centro de Servicio al cliente por localidad,
sitio, región

 Centro de Servicio al Cliente Centralizado

 Ubicación física y central que toma las
llamadas & las solicitudes de usuarios
provenientes de múltiples localidades
55
Centro de Servicio al Cliente -
Modelos
 Centro Virtual de Servicio al Cliente

 La ubicación no importa (múltiples países,

diferente horarios), utiliza comunicaciones
para re-direccionar las llamadas
 Accesa y comparte información a través de
procesos centralizados y herramientas

56
57
58
59
Actividades
 Recibir llamadas
 Registrar y hacer seguimiento a incidentes
 Informar a clientes sobre el estado de solicitudes y su progreso
 Evaluación inicial de solicitudes
 Seguimiento y procedimiento de escalamiento
 Administrar ciclo de vida de solicitudes
 Coordinar grupos de soporte de segundo y tercer nivel
 Proporcionar información gerencial y recomendaciones para
mejorar el servicio
 Cierre de Incidentes y confirmación con el cliente
 Contribuir a la identificación de problemas

60
61
Afinando tu conocimiento
 Nuestro Centro de Servicio al Cliente es inundado
de repente con llamadas telefónicas de clientes que
no pueden trabajar; después de preguntar a las
personas que llaman, pronto se aclara que una
aplicación importante en un servidor ha fallado.

¿Para cuál de las siguientes acciones, el Centro de

Servicio al cliente NO es responsable?

A. La categorización de las llamadas entrantes

B. Identificar la causa de la falla
C. Priorizar las llamadas entrantes
D. El escalamiento de incidentes

62
Afinando tu conocimiento
 ¿Qué incidentes deben de ser registrados
por el Centro de Servicio al Cliente?

A. Sólo incidentes no resueltos al registrarse

B. Sólo incidentes de clientes registrados
C. Todos los incidentes excepto preguntas
sencillas
D. Todos los incidentes

63
 ITIL

Administración de Incidentes

64
Objetivo
 Restaurar la operación normal del servicio
tan rápido como sea posible y minimizar el
impacto adverso en las operaciones del
negocio

65
Terminología Básica
 Incidente – Cualquier evento que no forma parte de la
operación normal de un servicio y que causa, o puede causar,
una interrupción o una reducción en la calidad de ese servicio

 Solicitud de Servicio – todo incidente que no representa una

falla en la infraestructura TI.

 Solicitudes para mudanzas de equipos, instalaciones,

consumibles.
 Solicitud de información
 Preguntas sobre algún servicio de TI
 Solicitudes de Cambio (RFC´s)
 Reponer contraseña

66
Terminología Básica
 El Impacto del Incidente – La magnitud o
alcance de la desviación del servicio con
respecto a su nivel normal respresentado en
términos del número de usuarios, CI´s o
procesos del negocio afectados (cuánto
daño)

 La Urgencia del Incidente – La demora

aceptable para el usuario o el proceso del
negocio (velocidad requerida para resolver el
incidente)
67
Terminología Básica
 Prioridad – La secuencia en que un
incidente, problema, o cambio necesita ser
resuelto, basado en Impacto sobre el negocio
y la urgencia.

 Esfuerzo Esperado – La cantidad anticipada

de recursos, tiempo y costos requeridos para
restaurar los servicios, despues que un
incidente ocurre.

68
69
70
71
Actividades
 Propiedad, Monitoreo, Seguimiento & Comunicación

 Centro de Servicio al Cliente

 Dueño de todos los incidentes

 Responsable del seguimiento al progreso
 Informe al usuario acerca del estado del incidente
 Primera Línea de Administración de Incidentes
 Seguimiento al ciclo entero del incidente. En caso de
que el incidente no pueda ser resuelto el mismo se
reporta a otro nivel (escalonamiento)

72
Actividades
 Detección y Registro del incidente
 Incidentes pueden ser detectados vía:
 Centro de Servicio al Cliente
 Usuario
 Sistemas (administración de eventos)
 Alguien en el departamento de TI

 Todo incidente debe registrarse inmediatamente

 Asignar numero de referencia la incidente
 Registrar información básica para el diagnóstico
 Suplementar información del incidente
 Alertar a otros usuarios y departamento si es necesario

73
Actividades
 Clasificación y Soporte Inicial
 Asignación de Categoría al Incidente
 Procesamiento Central, Redes, Procedimientos, etc.

 Asignación de Prioridad al Incidente

 Identificar

 Servicio relacionado con el incidente

 Tiempos de Escalamiento por SLA
 Grupo de Soporte (basado en la categoría)
 Numero de referencia del incidente
 Posición del Incidente en el flujo de trabajo (estado de
incidente)

74
Actividades
 Vinculación de Incidentes
 Determinar si han ocurrido incidentes similares

(usando clasificación)
 Determinar si existe una solución definitiva o temporal

 Reportar Incidentes No vinculados a la Administración

de Problemas
 Proporcionar soporte inicial
 Cierre o re-direccionamiento del incidente a grupo de
soporte pertinente e informar al usuario

75
Actividades
 Investigación y Diagnóstico
 Centro de servicio al cliente o equipo de soporte re-
direcciona a otro grupo de soporte aquellos incidentes
que no tienen solución o requieren la intervención de
otros especialistas

 Nuevo grupo de soporte investiga y resuelve o dirige a

otro grupo

 Actualizar registro del incidente (estado actual, nueva

información)

76
Actividades
 Resolución y Recuperación
 Se registra resolución en el sistema
 RFC´s, si es requerido
 Si no hay resolución, el incidente permanece abierto

 Cierre del incidente

 Una vez resuelto, el grupo de soporte re-direcciona el
incidente al Centro de Servicio al Cliente
 Centro de Servicio al cliente confirma cierre con el
usuario
 Actualizar registro con categoría final, prioridad, CI´s

77
78
Afinando tu conocimiento
 Los pasos en el proceso completo de
Administración de Incidentes, podrían ser mejor
descritos, como:

A. Registro del Incidente y alerta, soporte inicial y

clasificación, investigación y diagnóstico, resolución
y recuperación, cierre.
B. Registro del Incidente, clasificación inicial y
asignación, mantener contacto con el cliente y la
recuperación del servicio.
C. Primer nivel de soporte del incidente, contacto con
usuarios día a día, soporte a sistemas del negocio,
reportes gerenciales sobre la calidad del servicio TI
79
Afinando tu conocimiento
 Considere las siguientes declaraciones:

1) Por definición, un incidente urgente tiene la prioridad

más alta
2) Un incidente tiene un impacto bajo, si solo causa una
degradación menor del nivel normal del servicio para
un número pequeño de usuarios

¿Son estas declaraciones correctas?

A. Solo la primera
B. Solo la segunda
C. Ambas
D. Ninguna

80
 ITIL

Administración de Problemas

81
Objetivo
 Minimizar el impacto adverso de incidentes y
problemas en el negocio, que son causados
por errores dentro de la infraestructura TI y
prevenir la reaparición de incidentes
relacionados con estos errores

 Para lograr este objetivo, la Administración

de Problemas procura determinar la causa de
origen de los incidentes y entonces iniciar las
acciones para mejorar o corregir esta
situación
82
Terminología Básica
 Problema:
 Una condición identificada como resultado de
múltiples incidentes que exhiben síntomas
comunes.

 El problema podría derivarse, también de un

solo incidente significativo, indicativo de un
solo error, cuya causa es desconocida.

83
Terminología Básica
 Error Conocido:
 Un problema que ha sido diagnosticado exitosamente
(la causa de origen es conocida) y para el cual se ha
identificado una solución temporal.

 Solución Temporal
 Método utilizado para evitar un incidente o problema
bien sea a través de una alternativa temporal o de una
técnica que permita al cliente no depender de un
aspecto particular del servicio, del cual se conoce que
tiene un problema.

84
Actividades
 Control de Problemas
 Se concentra en transformar los problemas en
errores conocidos (determinar la causa de
origen del problema).

 Control de Errores
 Se concentra en resolver los errores
conocidos, vía el proceso de administración
de cambios.

85
Actividades
 Administración Proactiva de Problemas
 Se concentra en prevenir la ocurrencia de
problemas, errores e incidentes mejorando la
infraestructura TI.

 Administración de Información
 Produce información general

86
87
Actividades

88
Actividades
 Administración Proactiva de Problemas

 Identificar y resolver problemas y errores conocidos

antes que los incidentes ocurran, minimizando el
impacto en el servicio y costos relacionados con el
negocio.
 Centrada en la calidad de la infraestructura.
 Aprender de experiencias pasadas/historia
 Mejorar procesos & procedimientos.
 Sub-actividades:
 Análisis de tendencias

 Encausar acciones preventivas

 Revisiones de problemas mayores

89
90
Afinando tu conocimiento
 ¿Cómo la Administración de Problemas brinda
soporte a función de Centro de Servicio al Cliente?

A. Resuelve los incidentes graves para Centro de

Servicio al Cliente
B. Estudia todos los incidentes resueltos por el Centro
de Servicio al Cliente
C. Comunica la resolución directamente al usuario
D. Hace que la información sobre un error conocido sea
disponible para el Centro del Servicio al Cliente

91
Afinando tu conocimiento
 ¿Cuál de las tareas mencionadas son consideradas como
proactivas?

1. Control de errores conocidos

2. Revisar el incidente y el informe del análisis del problema
para identificar las tendencias
3. Prevenir en un servicio problemas que ya han ocurrido en
otros servicios
4. Identificar la causa de origen de los incidentes

A. 1y4
B. 1, 2 y 3
C. 2y3
D. 1y3

92
 ITIL

Administración de Cambios

93
Objetivo
 Asegurar el uso de métodos y procedimientos
estandarizados para el manejo eficiente y
oportuno de todos los cambios, con la
finalidad de minimizar el impacto en los
servicios, originado por incidentes
relacionados con los cambios.

“No todo cambio es una mejora, pero cada

mejora es un cambio”

94
Terminología Básica
 Cambio – Una acción que tiene como resultado un
nuevo estado, para uno o más CI´s.

 Cambio Estándar
 Un cambio a la infraestructura que sigue un camino
establecido
 Tareas comunes, bien conocidas & probadas
 Aprobación otorgada previamente
 Puede ser iniciado por el Centro de Servicio al Cliente

95
Terminología Básica
 Solicitud de Cambio (RFC – Request for
Change)
 Formato o pantalla, utilizada para registrar
detalles de cambio para cualquier CI.

 Autoridades – Aprobación de Cambios

 Gerente de Administración de Cambios
 Filtra, acepta & clasifica RFC´s
 Planifica & coordina la implementación de
cambios
96
Terminología Básica
 Autoridades – Aprobación de Cambios
 Comité Asesor de Cambios (CAB)
 Cuerpo que aprueba y participa en la evaluación, la
priorización, y la planificación de cambios selectivos,
 Compuesto por representantes de organizaciones TI y del
negocio.

 Comité Asesor de Cambios de Emergencia (CAB/EC)

 Subconjunto del CAB que atiende las solicitudes urgentes
de cambios.

 Comité Gerencial
 Grupo responsable por la aprobación de cambios mayores
 Comité de Dirección/Comité Ejectivo
97
Terminología Básica
 Calendario de Cambios Futuros (FSC – Forward
Schedule of Changes) – Programación de todos los
cambios aprobados y la fecha de implementación
propuesta.

 Proyección de la Disponibilidad de Servicios (PSA)

 Documento que contiene detalles de los cambios a los
SLAs acordados y a la disponibilidad de servicio,
debido al calendario de cambios futuros (FSC).

98
99
100
101
102
103
104
Afinando tu conocimiento
 ¿Considere los enunciados siguientes; cuál NO es
correcto?

A. La Administración de Cambios es responsable de

proporcionar un especificación detallada del efecto
de un cambio autorizado sobre CI´s.
B. La Administración de Cambios mantiene un registro
de todos los cambios.
C. La Administración de Cambios recibe, registra y
ayuda asignar prioridades a todos RFC´s.
D. La Administración de Cambios asegura que planes
de retorno sean preparados antes que los cambios
sean implementados.
105
Afinando tu conocimiento
 ¿Cuál de los enunciados siguientes es cierto? El Comité
Asesor de Cambios (CAB) debe asegurar que los cambios
propuestos sean evaluados para determinar:

1. El impacto probable en planes de contingencia.

2. El efecto de no implementar el cambio.
3. Los recursos requeridos para implementación del cambio.
4. El impacto probable sobre la capacidad y el rendimiento.

A. 1, 2 y 3
B. 2, 3 y 4
C. 1, 2 y 4
D. Todas las anteriores

106
 ITIL

Administración de Release

107
Objetivo
 La Administración de Release considera una
perspectiva holística de un cambio a un
servicio de TI y debe asegurar que tanto el
aspecto técnico y no técnico de un release
sea contemplado de manera conjunta.

108
Terminología Básica
 Biblioteca de Software Definitiva (DSL –
Definitive Software Library)

 Recinto seguro donde las versiones

autorizadas de todos CI´s de software son
almacenados & protegidos.
 Uno o más bibliotecas de software o archivos.
 Software propio & tercerceros con sus
licencias y documentación.

109
Terminología Básica
 Almacén de Hardware Definitivo (DHS – Definity
Hardware Store)
 Área física exclusiva para almacenar de manera
segura los componentes de módulos de repuesto de
hardware.
 Corresponden con el nivel de los sistemas y productos
operando en producción.
 Registrado en CMDB

 Release
 Conjunto de cambios autorizados a un servicio de TI.
 Típicamente consta de un numero de soluciones a
problemas y/o mejoras al servicio.

110
Terminología Básica
 Unidad de Release
 La porción de la infraestructura de TI que es
liberada normalmente en forma conjunta.
 Puede variar dependiendo del tipo (s) de
software y hardware.
 Utilizada para definir el nivel más apropiado
para administrar la unidad de release.
 Cambios de software – sistema, programa o
modulo.

111
Terminología Básica
 Tipos de Release
 Release Delta
 Incluye solo aquellos CI´s dentro de la Unidad de
Release que han cambiado o son nuevos desde
el último release completo o release delta.

 Release Completo
 Todos los componentes de la unidad release se
construyen, prueban, distribuyen e implementan
en forma conjunta.

112
Terminología Básica
 Paquete de Release
 Release individuales (pueden ser completo, delta
o ambos) que son agrupados para formar un
paquete de release.

 Release de emergencia
 Correcciones para un pequeño numero de
errores conocidos.

113
Terminología Básica
 Política de Release – documento que cubre:

 Roles y responsabilidades para la Administración de

Release.
 Definición de Releases (mayor y menor), políticas para el
manejo de release de emergencia.
 Nomenclatura para nombre y numeración de releases
 Release Mayor: Sistema_Nómina v.1, v.2, v3…
 Release Menor: Sistema_Nómina v.1.1, v.1.2, …
 Release Emergencia: Sistema_Nómina v.1.1.1, v1.1.2..

 Frecuencia de Release
 Nivel de Release
 Guías, directrices y detalles para cada sistema o servicio TI
soportado.

114
115
Actividades
 Política de Release
 Política de Release instaurada (nomeclantura,
frecuencia, nivel, etc.)

 Planificación de Release
 Acordar procedimientos a ser utilizados,
determinar roles y responsabilidades,
planificar los niveles de recursos,
programación o plan de alto nivel, etc.

116
Actividades
 Diseño, Desarrollo y Configuración de Release
 Planificar y documentar procedimientos para construir
releases, compilar y vincular los módulos de las
aplicaciones, preparar rutinas automáticas de
instalación.

 Aceptación del Release

 Pruebas realizadas por personal del negocio
involucrando el personal de TI para verificar
procedimientos de soporte que hallan cambiado.
Cualquier procedimiento de recuperación debe ser
probado como parte de esta actividad.
117
Actividades
 Planificación de Lanzamiento
 Plan detallado de eventos, incluyendo
responsabilidades y tareas, documentando planes de
acción por sitio, desarrollo del plan de compras.

 Comunicación, Preparación y Entrenamiento

 Involucra clientes y personal de soporte en secciones
de entrenamiento, actividades de aceptación de
release y reuniones de planificación de lanzamiento e
implementación con la finalidad de comunicar lo
planificado y como esto podría afectar las diferentes
áreas.
118
Actividades
 Distribución e Instalación

 Distribución de releases de software desde el

ambiente de desarrollo hacia el ambiente de
prueba controlado para luego distribuirse al
ambiente de producción (acompañado del
hardware y cambios necesarios).

119
120
Afinando tu conocimiento
 ¿Cuál de los siguientes NO es un objetivo del
proceso de la Administración de Release?

A. Evaluar el impacto de cambios de software

B. Acordar el contenido de releases de software a
través de la relación con la Administración del
Cambio
C. Diseñar e Implementar procedimientos efectivos
para la distribución de cambios de software a lo
largo de la organización
D. Prevenir que virus de software entran en la
organización

121
Afinando tu conocimiento
 ¿Cuál proceso de ITIL coordina la
implementación de release nuevo de
software?

A. Administración de Cambios
B. Administración de la Configuración
C. Administración del Release
D. Administración del Nivel de Servicio

122
123