La Oficina de Proyectos de Informtica

oficinaproyectosinformatica.blogspot.com

Los pasos para resolver incidentes en el perodo de estabilizacin de un desarrollo de software

Por: Ricardo Arturo Rodrguez Morillo Sgueme en Twitter: PMOInformatica Mi Blog: http://oficinaproyectosinformatica.blogspot.com

Resumen En este artculo se describen las medidas de preparacin para atender incidentes luego de ejecutar la implementacin de un desarrollo de software en el ambiente de produccin, durante el perodo de estabilizacin del sistema. Se discuten algunas medidas tales como mantener un equipo en horario establecido por el cliente (para aplicaciones crticas este ser 7 x24), con roles, responsabilidades y canales de comunicacin establecidos de antemano. Asimismo, se presentan los pasos a seguir en caso que suceda lo peor y se deba dar respuesta ante un incidente.

Introduccin Luego de varias semanas, meses o aos de arduo trabajo en el desarrollo y pruebas de un nuevo software, llega el gran da de la puesta en produccin del sistema. En esta etapa es comn preguntarse estar todo listo?, se habr omitido algn escenario?, podra ocurrir algn imprevisto en la configuracin? Ests preguntas no deberan representar mayor preocupacin si se ha desarrollado con estndares de calidad y cumpliendo todos los ciclos de pruebas con participacin de todos los implicados. Sin embargo, podran presentarse errores (incidentes) en el ambiente de produccin, a pesar de todas las acciones preventivas aplicadas, por lo que es necesario estar preparados. Las medidas que se exponen a continuacin estn pensadas para un ambiente de produccin, en el cual existen mltiples sistemas y plataformas interactuando, por lo que existen mayores controles de cambio y las funciones de soporte, equipo de pruebas y desarrollo poseen responsabilidades delimitadas. Asimismo, est pensado para cuando existen mltiples equipos de proyectos, por lo que requiere mayores controles de cambio.

Copyright La Oficina de Proyectos de Informtica (http://oficinaproyectosinformatica.blogspot.com)

La Oficina de Proyectos de Informtica

oficinaproyectosinformatica.blogspot.com

Medidas preventivas a establecer antes del pase a produccin

Definir equipo de soporte posproduccin:

o o o

No necesita estar constituido por la totalidad del equipo de desarrollo. Debe tener integrantes de todas las reas de pruebas y reas de desarrollo (tcnicas). La cantidad de integrantes del equipo depender de la magnitud del proyecto, cantidad de incidentes esperados y el grado de interoperacin con otros sistemas y plataformas. Por ejemplo, para un sistema con dos grandes mdulos transaccionales y desarrollados en tres capas (Presentacin, Middleware y Base de datos), se podra contar con un analista de pruebas de cada mdulo y un desarrollador de cada capa. Del lado del equipo de proyecto, debe establecerse un contacto primario para recibir las notificaciones de incidentes. Por lo general es una persona del rea tcnica (por ejemplo lder de desarrollo), con escalamiento al Jefe de proyecto u otros niveles en caso de ser localizado. Las notificaciones de los incidentes sern realizadas por un nico contacto designado en la organizacin cliente (que puede ser cliente interno si se est en la misma organizacin o externo si se es un proveedor). Definir la va de comunicacin, es recomendable que sea escrita (por correo electrnico) para poder enviar toda la informacin del incidente, pero tambin va telefnica para alertar de inmediato al contacto primario. El horario de atencin depender de la criticidad del sistema sobre las operaciones de la organizacin. Podra ser abarcar guardias en horario nocturno si el cliente (interno o externo) as lo establece. Si la atencin es 24 horas, deben establecerse relevos tanto en el contacto primario como niveles de escalamiento. Establecer de antemano el protocolo de atencin de incidentes, roles y responsabilidades.

Establecer canal de comunicacin primario:

o o

Mantener contacto permanente:

o o o o

Copyright La Oficina de Proyectos de Informtica (http://oficinaproyectosinformatica.blogspot.com)

La Oficina de Proyectos de Informtica

oficinaproyectosinformatica.blogspot.com

Definir con quien se comunica el contacto primario y bajo que protocolo o procedimiento.
o

Debe existir uno o ms responsables en: Gestin tcnica, que puede ser un lder tcnico o analista programador; Gestin de pruebas, que puede ser el lder de pruebas (QA) y el Jefe de Proyecto como nivel de escalamiento. Para proyectos ms grandes pueden requerirse Lderes tcnicos, de pruebas y de proyectos de varias reas, segn la magnitud. Definir con antelacin el procedimiento a seguir para replicar incidentes, diagnosticarlo y aplicar correctivos. El equipo debe contar con las herramientas necesarias, por ejemplo acceso a ambientes y herramientas de diagnstico. Establecer de antemano el formato y datos que deben incluirse en el reporte de la incidencia, asegurando que se incluyan todas las caractersticas de los datos involucrados en el incidente, para asegurar que puedan conseguirse datos similares en ambiente de pruebas para la rplica.

o o o

Cuando sucede lo peor: Los pasos a seguir para atender el incidente. El siguiente procedimiento se aplica durante el perodo de posimplantacin de un nuevo desarrollo, los responsables de replicar y corregir los incidentes son el equipo de proyecto, al no haberse est entregado an al equipo de soporte. Los pasos son los siguientes: 1. Movilizar a los responsables (Responsable: Contacto Primario): Cuando se trata de incidentes posproduccin, la respuesta rpida y efectiva es crtica, considerando que el incidente podra estar dejando sin servicio a todos o algunos usuarios, u otras consecuencias como el registro de informacin errnea en base de datos. Revisin inicial (Responsable: Equipo de Pruebas): En primer lugar, debe verificarse si realmente se trata de un incidente, en especial si se trata de un sistema nuevo que los usuarios an estn aprendiendo a utilizar. Los incidentes descartados por uso inadecuado de la aplicacin deben analizarse tambin para determinar donde se origin la confusin del usuario y evaluar posibles mejoras. Replicar el incidente en un ambiente homologado con produccin (Responsable: Equipo de Pruebas): Utilizar el ambiente de calidad (en el cual se realizaron las pruebas de aceptacin del usuario) para intentar replicar el incidente, descartando si este no logra replicarse. Capturar las evidencias del incidente (Responsable: Equipo de Pruebas): Si se confirma que el incidente ocurre en ambiente de calidad,

2.

3.

4.

Copyright La Oficina de Proyectos de Informtica (http://oficinaproyectosinformatica.blogspot.com)

La Oficina de Proyectos de Informtica

oficinaproyectosinformatica.blogspot.com

tomar las evidencias para la documentacin (Capturas de pantalla que muestran el incidente). 5. Determinar si el incidente est relacionado con el desarrollo (Responsable: Equipo de desarrollo primario): La primera parte del diagnstico consiste en descartar que el incidente pueda estar ocasionado por factores externos al desarrollo (fallas en la plataforma u otros sistemas con los que se tiene interfaces). De ser el caso se deriva al departamento responsable quien contina el proceso. De confirmar que es aplicable al proyecto, se deriva al equipo de desarrollo responsable segn protocolo. Diagnosticar el incidente (Responsable: Equipo de desarrollo de rea): Haciendo uso de herramientas de diagnstico automatizadas o manuales, el equipo de desarrollo identifica la causa raz del error en ambiente de produccin. En este paso, es comn que el analista programador solicite apoyo al equipo de pruebas que realiz la rplica del incidente. Aplicar el correctivo y probarlo en ambiente de desarrollo (Responsable: Equipo de desarrollo de rea): La correccin del incidente debe cumplir el ciclo de desarrollo, es decir, debe elaborarse una especificacin tcnica que debe ser aprobada, luego realizar el desarrollo y las pruebas unitarias. Transferir correccin a ambiente de pruebas e informar a equipo (Responsable: Equipo de desarrollo de rea): Una vez se compruebe el xito de las pruebas unitarias, se realiza un control de cambio para transferir la correccin al ambiente de pruebas. Una vez liberado se notifica al equipo de pruebas y se cambia el estado de la incidencia a corregido / volver a probar. Realizar pruebas de verificacin de correccin y capturar evidencias (Responsable: Equipo de pruebas): Utilizando guion de pruebas, se verifica la correccin y se registra la documentacin (capturas de pantalla), si las pruebas no son superadas se retorna incidencia al equipo de desarrollo. Pruebas de aceptacin de la correccin: Se convoca al usuario o cliente que reporto la incidencia, se le presentan las evidencias del antes con la rplica del incidente y de las evidencias de correccin. Luego se procede a realizar una prueba en vivo para demostrar que ha concluido. Finalmente se obtiene la aceptacin formal del usuario. Transferir correccin a ambiente de produccin: Se ejecuta control de cambios de la correccin y se transfiere esta a ambiente de produccin. Verificar correccin en produccin: El usuario o cliente que reporto el error ejecuta la verificacin poscambio y con eso cierra el caso.

6.

7.

8.

9.

10.

11. 12.

Copyright La Oficina de Proyectos de Informtica (http://oficinaproyectosinformatica.blogspot.com)

La Oficina de Proyectos de Informtica

oficinaproyectosinformatica.blogspot.com

Conclusin El procedimiento descrito en este artculo pretende definir un protocolo que puede distribuirse a los equipos de proyecto, encargados de atender los incidentes que se reporten en el perodo de posimplantacin. La mejor forma de atender este tipo de incidentes es estar preparados con equipos, roles, responsabilidades, canales de comunicacin y procedimientos previamente definidos. Y qu opina usted?, Qu procedimiento aplicara para resolver incidentes en el perodo posimplantacin?, Cules han sido sus resultados? Le invitamos a participar en nuestro foro (en la oficinaproyectosinformatica.blogspot.com) y a suscribirse al blog por los distintos canales, tales como lista de correo, RSS y Twitter. Otros artculos en La Oficina de Proyectos de Informtica Las Habilidades y conocimientos ms buscados en el rea de Tecnologa de Informacin (TI)
http://oficinaproyectosinformatica.blogspot.com/2012/09/habilidades-mas-buscadas-tecnologia.html

Las reuniones de trabajo: ms productividad, menos reuniones

http://oficinaproyectosinformatica.blogspot.com/2012/09/las-reuniones-trabajo-productivas.html

Ambientes de pruebas integrales de software: Buenas prcticas

http://oficinaproyectosinformatica.blogspot.com/2012/09/pruebas-software-ambientes.html

Ambientes de desarrollo de software: Buenas prcticas

http://oficinaproyectosinformatica.blogspot.com/2012/09/ambientes-de-desarrollo-de-software.html

Algunas prcticas de desarrollo de aplicaciones web para asegurar calidad, mantenibilidad, escalabilidad y seguridad
http://oficinaproyectosinformatica.blogspot.com/2012/08/algunas-practicas-de-desarrollo-de.html

Herramientas de software para gestin de proyectos de desarrollo gil

http://oficinaproyectosinformatica.blogspot.com/2012/08/herramientas-de-software-paragestion.html

Acciones preventivas para evitar retraso y retrabajo en proyectos de tecnologa de informacin (TI)
http://oficinaproyectosinformatica.blogspot.com/2012/08/acciones-preventivas-para-evitar.html

Las preguntas que debe hacer al encargarse de un proyecto de Tecnologa de Informacin (TI) en ejecucin
http://oficinaproyectosinformatica.blogspot.com/2012/08/las-preguntas-que-debe-al-hacersecargo.html

Copyright La Oficina de Proyectos de Informtica (http://oficinaproyectosinformatica.blogspot.com)