TABLA DE CONTENIDOS INFORMACIÓN DEL DOCUMENTO OBJETIVO ALCANCE DEFINICIONES Y VOCABULARIO

Transcripción

1

2 TBL DE CONTENIDOS INFOMCIÓN DEL DOCUMENTO OBJETIVO LCNCE DEFINICIONES Y VOCBULIO EFEENCIS Y DOCUMENTOS ELCIONDOS ESPONSBILIDDES DIGM DE FLUJO DESCIPCIÓN DEL POCESO INDICDOES DE GESTIÓN... 10

3 F E C H D E Ú L T I M M O D I F I C C I Ó N N O M B E E L E C T Ó N I C O D E L D O C U M E N T O 06/01/2010 SUS-PO-02 Gestion de Incidentes.doc En caso de que este documento esté impreso o se encuentre en una ubicación distinta a la especificada oficialmente para copias controladas en el procedimiento SGC-PO-01 Control de Documentos, se convierte automáticamente en COPI NO CONTOLD y es solamente para información El Propósito del proceso de Gestión de Cambios es asegurar que: Métodos y procedimientos Estandarizados sean usados para el manejo pronto y eficiente para la gestión de cambios. Todos los cambios a los activos del Negocio e ítems de Configuración sean registrados en el Sistema de Gestión de Cambios. Toda la administración de riesgos del negocio sea optimizada. Los objetivos de la Gestión de Cambios son: esponder a los requerimientos de cambios en el Negocio, maximizando el valor y reduciendo el número de incidentes, corte de servicio y re-trabajo. esponder a los requerimientos de Cambio por parte de IT y de Negocio que se alinean a las necesidades del negocio. El objetivo de la Gestión de Cambios es asegurar que los cambios son registrados y evaluados, autorizados, prioriados, planificados, probados, implementados, documentados y revisados en una manera controlada. Dar una respuesta apropiada a todos los requerimientos de cambios implica considerar una aproximación a la gestión de riesgos y continuidad del negocio, impacto del cambio, requerimientos de recursos, autorización de cambios y especialmente para un beneficio del Negocio alcanzable. La Gestión de Cambios incluye: Implementar los cambios que alcancen los requerimientos de servicio acordados con el cliente, optimizando costos. egistración, evaluación y aprobación de todos los cambios antes de ser puestos en producción. Evaluación de riesgos y análisis de impacto asociados a la transición en la aplicación. educir los cambios fallidos así como también los cortes de servicio, defectos y retrabajo. Seguimiento de cambios a través del ciclo de vida del servicio y de los activos del cliente. Contribuir a la mejor estimación de la calidad, tiempo y costo del cambio. La gestión de Cambios depende de las siguientes Factores Críticos de éxito:

4 Mediante la administración de cambios, se puede administrar la mayoría de los riesgos potenciales que los cambios pueden introducir. Los riesgos top 5 indicadores de una pobre gestión de cambios son: Cambios desautorizados (mayor a cero es inaceptable) Cortes no planificados Una baja tasa de cambios exitosos. Un alto número de cambios de emergencia a partir de una pobre gestión de cambios. Implementaciones de proyectos demoradas. Este procedimiento tiene aplicación para el área de Sustain para el nivel 2 y 3 de soporte. Ver definiciones y vocabulario en SUS-PO-01 Gestión de Sustain SGC-MC-01 Manual de Calidad SUS-PO-01 Gestión de Sustain SUS-PO-03 Gestión de equerimientos SUS-PO-05 Gestión de Cambios El Sustain Leader es la responsable de la aplicación de este procedimiento, y del mantenimiento y de la distribución del mismo.

5 Gestión de Incidentes equerimiento de Cambio Gestión de Problemas 1. EGISTO DEL PEDIDO DE CMBIO. (FC) C eq de Cambio Gestión de equerimientos Lista de Elementos involucrados 2. NLISIS DE IMPCTO Casos de Prueba No Necesita probación? C eq de Cambio (actualizado) Si prueba el Cliente? No Si 3. CTULIZ MBIENTE DE DESOLLO 4. DESOLLO Standard de Codificación 5. EVISION DEL CMBIO Y Q Cambio ok? No Si 6. CTULIZ MBIENTE DE TNSICION Gestión de elease 7.CIEE DEL CMBIO 8.EVISION POST- IMPLEMENTCIÓN End

6 Estas son los principales procesos de actividades de ITIL, definidos para el proceso de Gestión de Cambios con una breve descripción. EL diagrama CI define 4 tipos de responsabilidades sobre las tareas a llevar a cabo. Estas son asignadas a diferentes roles en el proceso. L E T T I P O D E S C I P C I O N esponsable quellos que llevan adelante la tarea. probador El recurso final para establecer la correctitud y completitud de la tarea. Debe existir solo 1 aprobador. C Consultor quellos cuya opinión es requerida. I Informado quellos que son informados respecto al avance de la tarea. Comunicación establecida solo en un sentido C Ó D I G O T I P O CL Change Leader IN Iniciador esponsable de ejecutar el Cambio (Level 2/ Level 3) CB Change dvisory Board (Equipo Consultor del Cambio) US Ususario CTIVIDDES DESCIPCION DE CTIVIDDES CL IN CB US Un cambio puede ser generado por un iniciador el cual requiere que una modificación sea realizada, la cual implica una actualización en el código de la aplicación. Por ejemplo, la gestión de Problemas iniciando un requerimiento de Cambio (C) para implementar un arreglo en un código fuente en cualquier aplicación soportada 1. EGISTO DEL PEDIDO DE CMBIO (FC) Por otro lado, cada modificación cada modificación al código fuente debería tener un C asociado con la información requerida. El registro de C debe ser realizado en el documento template C_Template.doc, completando toda la información referente al cambio. Una vez que se ha detectado la necesidad de efectuar un cambio al código fuente del aplicativo soportado, el estado del caso registrado en SM debe cambiar a Transferido a Desarrollo / In Progress. Lo primero es identificar cuáles son los elementos afectados en el cambio. C C 2. NLISIS DE IMPCTO En esta actividad el análisis de impacto es realizado para determinar, de acuerdo a los elementos implicados, cuan crítico es el cambio. También, determinar los casos de prueba necesarios y documentarlos para ser ejecutados antes de la puesta en producción. Este análisis de impacto determinará el mejor momento para desplegar el nuevo release. C C C Si es necesario, en esta actividad se realiza una especificación técnica detallada del cambio a realizar. Los cambios requieren una aprobación de EDS. Hay cambios que requieren de una aprobación explísita del

7 CTIVIDDES DESCIPCION DE CTIVIDDES CL IN CB US cliente. Nota: Los cambios pre-autorizados pueden ser definidos. Estos no requieren autorización y pueden ser implementados directamente. En general se trata de ambios asociados a requerimientos rutinarios. 3. CTULIZ MBIENTE DE DESOLLO (opcional) Esta actividad apunta a garantizar que el ambiente de desarrollo ha sido actualizado con la última versión de liberada, antes que el desarrollador (el cual implementó el cambio) comience a realizar las modificaciones cobre las últimas versiones de los elementos que conforman la aplicación. Básicamente consiste en: El desarrollador obtiene la última versión de los elementos de la herramienta de Gestión de Configuraciones (CMT). La CMT bloquea física o lógicamente los elementos Fuentes. El desarrollador actualiza los elementos a modificar en el ambiente de Desarrollo. CI 4. DESOLLO En esta actividad, el programador implementa el cambio En esta actividad se realiza una revisión por Muestreo de los cambios implementados. CI 5. EVISION DEL CMBIO Y SEGUMIENTO DE L CLIDD Este control apunta a verificar que el cambio ha sido implementado como fue especificado en el C. El responsable de la revisión cuenta con el C relacionado al cambio. CI Si el resultado de la revisión es satisfactorio, ir a actividad 6. ctualización de ambiente de Transición. 6. CTULIZ MBIENTE DE TNSICION (Staging) En esta actividad el desarrollador bajo el rol de dministrador de Versiones actualiza el mbiente de Transición con la nueva versión del código fuente. Una vez que el encargado de implementar los cambios informa que la tarea de programación ha terminado, esta nueva versión se pone a disposición del Testeador para ser testeado por los casos de prueba generados a tal efecto. partir de esta actividad, el proceso de Gestión de elease es lanzado. Para más detalle referirse al Procedimiento: Gestión de elease a Producción. CI El estado del caso registrado en SM debe cambiar a Terminado y Entregado para evisión / esolved. 7. CIEE DEL CMBIO Una vez que el proceso de Gestión de elease se ha finalizado, habiendo implementadoel cambio correspondiente en Producción, el líder de Cambios cierra el cambio, completando en el C correspondiente la información del cierre del cambio. CI C I El estado del caso registrado en SM debe cambiar a Cerrado / Closed.

8 CTIVIDDES DESCIPCION DE CTIVIDDES CL IN CB US 8. EVISION POST- IMPLEMENTCIÓ N El esponsable de la Gestion de Cambios envía un mail al Usuario para verificar que el cambio ha sido satisfactorio. CTIVIDDES T I G G E S I N P U T S O U T P U T S 1. EGISTO DEL PEDIDO DE CMBIO (FC) equerimientos de negocio equerimientos de Usuario Gestión de Problemas Gestión de Incidentes Gestión de equerimientos 2. NLISIS DE IMPCTO C C equerimientos de aplicaciones Nuevas funcionalidades para aplicaciones Mejoras a aplicaciones rreglos para bugs. Solución a problemas equerimiento de Cambio (C) probación de EDS (opcional) probación del Cliente (opcional) Casos de prueba C actualizado (sección técnica + elementos afectados) 3. CTULIZ MBIENTE DE DESOLLO (opcional) probación de EDS probación del Cliente C actualizado (sección técnica + elementos afectados) mbiente de Desarrollo mbiente de Desarrollo actualizado 4. DESOLLO C C. mbiente de Desarrollo actualizado. Standard de Codificación Nueva versión del código fuente 5. EVISION DEL CMBIO Y SEGUMIENTO DE L CLIDD C Nueva versión del código fuente Standard de codificación evisión y aprobación del aseguramiento de calidad 6.CTULIZ MBIENTE DE TNSICION (Staging) evisión y aprobación del aseguramiento de calidad Nueva versión del código fuente mbiente de Testing mbiente de Testing actualizado 7.CIEE DEL CMBIO C C Cierre del C 8.EVISION POST- IMPLEMENTCIÓN Cierre del C C nálisis del C El proceso de Gestión de Cambios ha sido adaptado para servicios de soporte técnico. Estas son las actividades de procesamiento específicas definidas por EDS para el Procesamiento de Gestión de Cambios. Es importante conocer diferentes aspectos relacionados a la definición del proceso. Los siguientes son los roles de la Gestión de Problemas.

9 Toma la responsabilidad total por el liderazgo, control y toma de decisiones del equipo de soporte. Este individuo se focaliza en el proceso como un todo más que en las particularidades del mismo. Se asegura que los cambios son registrados en el log de cambios apropiadamente. Si fuera necesario, asigna equipos para conducit el análisis de impacto del C y abordaje de riesgos. naliza y prioriza Cs. evisa y evalúa el proceso de cambios. Inicializa el cambio generando un C al Líder de Cambios. Es responsable por completar el formulario C, el cual incluye la razón para el C, la fecha de implementación propuesta, los sistemas, personal afectado al cambio, entre otras cosas. Esta persona es notificada si el cambio fue aprobado y es tenido al tanto respecto al estado del C a través del proceso de cambios. Ejecuta el cambio, implementando el desarrollo, configuración, actividades de actualización, etc. ealiza la implementación del cambio en el ambiente de desarrollo. Participa en la actividad 2. nálisis de Impacto, colaborando con la estimación en el análisis de impacto del cambio. Genera los casos de prueba necesarios para testear el cambio en el ambiente de pruebas. Completa el formulario de C, principalmente en temas técnicos. Crea un registro de Problema si no existe una solución rápida. El CB es un cuerpo de toma de decisiones que evalúa y aprueba o rechaza los requerimientos de cambio. El CB deberá reunirse regularmente (deseable una vez a la semana) para analizar y aprobar los cambios a ser implementados.

10 1) Cumplimiento de fechas pactadas. Medición mensual. 2) Tasa de errores (medición mensual): Cantidad de Bugs detectados en forma interna. Cantidad de Bugs detectados en testing del cliente. Cantidad de Bugs detectados en producción. 3) Cantidad de horas previstas vs. insumidas. Medición mensual.