CU_500_Cut Over_v2.0 - focusbs-cl

CU-500
Antecedentes del Caso de Uso
Caso de Uso:
Proyecto:
Código de Proyecto:
Nivel:
Contexto:
Actor Principal:
Actores Asociados:
Sistemas Externos:
Intereses:
Precondiciones:
Resultado Esperado:
Referencias:
Riesgos:
Cut Over
New Host – GPNR V2
Aún no definido
[ ] – Resumen/General
[ X ] – Usuario
[ ] – Sub Función
Cuando ocurra el cambio de Host se deben realizar una serie acciones que permitan
realizar la transición entre la información actual de reservas y las nuevas en
formato Sabre. Este caso describe la problemática de cuto ver y propone la
estrategia para realizar la transición.
Host Sabre
Usuarios Host, Equipo de proyecto, áreas de servicio IT.
Host Sabre
Actor Fuera de Escena
Intereses
Área Revenue Management
Usar esta información para cargar modelo de
gestión propio.
Área Revenue Integrity
Usar esta información para cargar modelo de
gestión propio.
Área de Clientes
Usar esta información para cargar modelo de
gestión propio.
Áeropuertos
Usar esta información para cargar modelo de
gestión propio.
Canales
Usar esta información para realizar consultas.
Existe disponibilidad de recursos para el proyecto.
Será necesario que por parte del usuario se realicen actividades de validación, estas
se realizaran de manera secuencial:
 Validación de cierre de vigencias, duración 1 día.
 Validación de carga de primer entregable, duración 1 día.
 Validación de carga inicial, duración 1 día.
 Validación cada cuatro días durante el periodo de actualización de cargas
diarias, cada una tendrá duración de 1 día.
El proceso de GPNR queda funcionando normalmente después del cambio de host
No Aplica
No Aplica, están explicados en el documento.
Descripción de los Flujos
Flujo Básico
Descripción de Alto Nivel
Tomando como supuesto principal el hecho de que las migraciones están completadas al 100%,
se inicia el proceso de cutover de Gestión PNR, se procede a congelar Gestión PNR, en el
momento en que se toma control de producción se continua con las modificaciones necesarias a
las tablas que se vieron afectadas por el cambio funcional, sigue con el cierre de vigencias,
posteriormente inicia el proceso de carga inicial de datos del nuevo host, luego comienza el
proceso de actualización de cargas diarias y una vez terminado esta última etapa se procede a
entregar el control de Gestión PNR.
Para un mejor entendimiento en la secuencia y duración de estas actividades, estas serán
representadas en un diagrama de tiempo. Ref. 001.
Caso de Uso - Cut Over | Ver. 2.0 | 19/08/2010
Página 1 de 6
Descripción Detallada (Paso a Paso)
Etapa 0: Verificación de migración completa.
1. El proceso de cutover se inicializa comprobando que la migración finalizó correctamente,
esta se podrá validar comprobando que todos los criterios de aceptación que se encuentran
en el documento de especificación de migraciones se encuentren al 100%.
2.
3.
Etapa 1: Inicio Freezing de Gestión PNR.
Se inicializa el proceso de freezing de Gestión PNR en producción, en esta etapa la base de
datos de Gestión PNR no podrá ser utilizada de manera productiva durante todo el periodo
que dure el proceso de cutover, por lo tanto, no se cargará mas información desde la
fuente original (antigua Bajada PNR’s de Resiber).
Etapa 2: Preparación del sistema
Una vez realizado el freezing de Gestión PNR, es necesario realizar dos actividades a modo
de preparación del sistema.
2.1: Actualizar estructura de datos.
 Debido a un cambio funcional del sistema es necesario realizar ALTER a tablas que
corresponden al sistema. Ref.002
Duraciones estimadas de actividad:
Optimista: 0,5 Días
Normal: 1 Día
Pesimista: 2 Días
2.2: Cierre de vigencias.
 Proceso que procederá a realizar el cierre de las vigencias, esto quiere decir que
todas las reservas que tengan como fecha fin de vigencia para el año 2050 serán
cerradas asignándoles fecha fin de vigencia el día en que se realice este cambio.
Debido que es una actividad de modificación masiva de datos, donde la duración
de esta es factor para el inicio de la siguiente etapa será parte de una
calendarización de actividades. Mayor detalle de este proceso será detallado en
el CU510-Cierre de vigencias.
Duraciones estimadas de actividad:
Optimista: 1 Día
Normal: 2 Día
Pesimista: 3 Días
Nota: Al finalizar esta actividad el usuario deberá validarla, duración de actividad 1
día.
4.
Etapa 3: Carga Inicial.
Este proceso corresponde al inicio de la carga de datos provenientes del nuevo host, debido
a la gran cantidad de información que es necesario que el proceso se realice por bloques de
datos. La etapa será parte de una calendarización de actividades. Especificado en CU520Carga inicial, ver línea de tiempo CutOver. Ref.002
Se considera para la carga inicial solo un entregable, el cual tendrá toda la información
consolidada de los entregables definidos por la migración host-to-host.
Entregables definidos por el mejor escenario de la migración hasta el día de este caso de
uso:
 Entregable N°1: 5 Días antes del cutover, 2.500.000 PNRs aprox.
Caso de Uso - Cut Over | Ver. 2.0 | 19/08/2010
Página 2 de 6





Entregable N°2: 1 Día antes del cutover, 800.000 PNRs aprox.
Entregable N°3: Día de cutover, 250.000 PNRs aprox.
Actualización N°1, 1 Día después de cutover, 500.000 PNRs aprox.
Actualización N°2, 2 Días después de cutover, 500.000 PNRs aprox.
Actualización N°3, 3 Días después de cutover, 500.000 PNRs aprox.
Toda la información de los entregables definidos por la migración quedarán consolidados en
un solo entregable con las siguientes características:

Entregable consolidado, 3 Días después de cutover, 3.100.000 PNRs aprox.
Para el entregable consolidado se consideran las siguientes estimaciones.
Entregable Consolidado:
Optimista: 5 Días
Normal: 7 Días
Pesimista: 14 Días
Nota1: Esta etapa tiene considerado una sola validación por parte del usuario, la cual se
realizará finalizando la carga inicial del entregable consolidado.
Nota2: Durante los días sábados, domingos, festivos y de validación de cargas, no se
trabajara en actualización ni carga diaria, por lo que esos días se acumulara otro archivo de
carga diaria. Este supuesto aplica para los casos Optimista y Normal.
Nota3: Para el caso pesimista se considera trabajar sábados, domingos y festivos, tanto para
carga como validación.
5.
Etapa 4: Actualización de Cargas Diarias.
Considerando los tres escenarios de las dos etapas anteriores, se provocara un desfase de
información, debido a que mientras se termina el proceso de carga inicial seguirán llegando
archivos para las cargas diarias. Es por esto que es necesario realizar un proceso de
actualización de cargas diarias, que dependerá de la cantidad de archivos diarios
acumulados hasta el final de la carga inicial. Especificado en CU520-Carga Inicial.
Duraciones estimadas de actividad:
Optimista: 7 Días
Normal: 15 Días
Pesimista: 27 Días
Nota1: Esta etapa se considera validaciones cada cuatro días, duración de cada actividad es
de 1 día, estas serán realizadas de manera secuencial.
Nota2: Durante los días sábados, domingos, festivos y de validación de cargas, no se
trabajara en actualización ni carga diaria, por lo que esos días se acumulara otro archivo de
carga diaria. Este supuesto aplica para los casos Optimistas y Normal.
Nota3: Para el caso pesimista se considera trabajar sábados, domingos y festivos, tanto para
carga como validación.
Etapa 5: Fin Freezing de Gestión PNR.
6. Se libera la nueva versión de Gestión PNR.
7. Fin del caso de uso.
Flujos Alternativos
[ ] Excepción
N/A
Descripción de Alto Nivel
Caso de Uso - Cut Over | Ver. 2.0 | 19/08/2010
Página 3 de 6
[
[
[
[
] Validación
] Búsqueda
] CRUD
] Otro
N/A
Descripción Detallada (Paso a Paso)
N/A
Integraciones
1. N/A
1.1 N/A
Precondiciones
N/A
Descripción Detallada (Paso a Paso)
1. N/A
[ ] Excepción
N/A
[ ] Validación
[ ] Búsqueda
[ ] CRUD
[X] Otro
Post condiciones
N/A
Descripción de Alto Nivel
N/A
Descripción Detallada (Paso a Paso)
N/A
Estructuras de Datos de Integraciones
1. N/A
N/A
Campo
N/A
Descripción
N/A
Tipo de Dato
N/A
Obligatoriedad
N/A
Información Complementaria
Referencias:
Ref. 001:
El proceso general se refleja por la secuencia de actividades que se muestran en el siguiente esquema:
De acuerdo a cada una de las estimaciones de tiempo el proceso general tendrá la siguiente duración según
sea el caso:
Caso de Uso - Cut Over | Ver. 2.0 | 19/08/2010
Página 4 de 6
Caso Optimista:
Caso Normal:
Caso Pesimista:
NOTA: Las fechas mencionadas son solamente referenciales, tomando como supuesta fecha de CutOver
Host el día 13 de Julio del 2012.
Ref. 002:
Las tablas afectadas por el cambio funcional son las siguientes:
Cambio de campos:
Tabla
RESERVAS
RESERVA_SEGMENTO
PFS_RES_SEG
PFS_RES_SEG
Campo Actual
Campo Nuevo
rvas_cdg_pnrpadre CHAR(5)
rssg_cdg_pnr_padre_nego CHAR(5)
pfs_fch_vuelo DATE FORMAT 'yy/mm/dd'
No existe
rvas_cdg_pnrpadre CHAR(6)
rssg_cdg_pnr_padre_nego CHAR(6)
pfs_fch_vuelo DATE FORMAT 'YYYY/MM/DD'
rvas_fch_reserva DATE FORMAT 'YYYY/MM/DD'
TITLE 'Fecha Reserva' NOT NULL
Cambio de Unique Primary Index:
Tabla
Unique Primary Index Actual
UNIQUE PRIMARY INDEX pfsr_upi ( rvas_cdg_pnr,
PFS_RES_SEG
rssg_cdg_linea
,rssg_nmr_vuelo
Caso de Uso - Cut Over | Ver. 2.0 | 19/08/2010
,pfs_fch_vuelo
Unique Primary Index Nuevo
UNIQUE PRIMARY INDEX pfsr_upi ( rvas_cdg_pnr ,
rvas_fch_reserva, rssg_cdg_linea ,rssg_nmr_vuelo
Página 5 de 6
,cdds_cdg_origen ,cdds_cdg_destino ,
pfs_cdg_clase );
,pfs_fch_vuelo,cdds_cdg_origen ,cdds_cdg_destino ,
pfs_cdg_clase );
Sugerencias:
Control de históricos.
Se recomienda que se ejecute un proceso de control de históricos posterior al proceso de CutOver, el cual se
encargue de la información histórica para Gestión PNR. Como este proceso será ejecutado por primera vez
luego del proceso de cutover, se recomienda realizarlo de forma iterativa, modificando el parámetro de
eliminación de datos históricos (ver CU_300_Control_Historicos), de tal forma de ir eliminado de manera
gradual los datos, hasta llegar a los 5 años de historia (dato propuesto para el parámetro en
CU_300_Control_Historicos).
Ej:
El dato de negocio más antiguo tiene 10 años, se modifica el parámetro de control de histórico para 9 años.
Luego de que se ejecuta el proceso control de históricos habrá eliminado un año de historia. Se vuelve a
iterar, esta vez se modifica el parámetro de control de históricos a 8 años. Luego de que se ejecuta el
proceso control de históricos se habrá eliminado otro año de historia. Asi sucesivamente, hasta llegar a lo
definido en el CU_300_Control_Historicos.
Caso de Uso - Cut Over | Ver. 2.0 | 19/08/2010
Página 6 de 6