Los pasos para resolver incidentes en el período de estabilización de un desarrollo de software

Imagen de: www.ClipartOf.com/15065

Luego de varias semanas, meses o años de arduo trabajo en el desarrollo y pruebas de un nuevo software, llega el gran día de la puesta en producción del sistema. En esta etapa es común preguntarse ¿estará todo listo?, ¿se habrá omitido algún escenario?, ¿podría ocurrir algún imprevisto en la configuración?

Estás preguntas no deberían representar mayor preocupación si se ha desarrollado con estándares de calidad y cumpliendo todos los ciclos de pruebas con participación de todos los implicados. Sin embargo, podrían presentarse errores (incidentes) en el ambiente de producción, a pesar de todas las acciones preventivas aplicadas, por lo que es necesario estar preparados.

En este artículo se describen las medidas de preparación para atender estos incidentes en el período de estabilización del sistema, abarcando el mantener un equipo en horario establecido por el cliente (para aplicaciones críticas este será 7 x24), con roles, responsabilidades y canales de comunicación establecidos de antemano. Adicionalmente, se presentan los pasos a seguir en caso que suceda lo peor y se deba dar respuesta ante un incidente.

Las medidas están pensadas para un ambiente de producción, en el cual existen múltiples 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 múltiples equipos de proyectos, por lo que requiere mayores controles de cambio.

Medidas preventivas a establecer antes del pase a producción

• Definir equipo de soporte posproducción: 
• No necesita estar constituido por la totalidad del equipo de desarrollo. 
• Debe tener integrantes de todas las áreas de pruebas y áreas de desarrollo (técnicas). 
• La cantidad de integrantes del equipo dependerá de la magnitud del proyecto, cantidad de incidentes esperados y el grado de interoperación con otros sistemas y plataformas. 
• Por ejemplo, para un sistema con dos grandes módulos transaccionales y desarrollados en tres capas (Presentación, Middleware y Base de datos), se podría contar con un analista de pruebas de cada módulo y un desarrollador de cada capa. 

• Establecer canal de comunicación primario:
• 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 técnica (por ejemplo líder de desarrollo), con escalamiento al Jefe de proyecto u otros niveles en caso de ser localizado. 
• Las notificaciones de los incidentes serán realizadas por un único contacto designado en la organización cliente (que puede ser cliente interno si se está en la misma organización o externo si se es un proveedor). 
• Definir la vía de comunicación, es recomendable que sea escrita (por correo electrónico) para poder enviar toda la información del incidente, pero también vía telefónica para alertar de inmediato al contacto primario. 

• Mantener contacto permanente: 
• El horario de atención dependerá de la criticidad del sistema sobre las operaciones de la organización. 
• Podría ser abarcar guardias en horario nocturno si el cliente (interno o externo) así lo establece. 
• Si la atención es 24 horas, deben establecerse relevos tanto en el contacto primario como niveles de escalamiento. 
• Establecer de antemano el protocolo de atención de incidentes, roles y responsabilidades: 

• Definir con quien se comunica el contacto primario y bajo que protocolo o procedimiento. 
• Debe existir uno o más responsables en: Gestión técnica, que puede ser un líder técnico o analista programador; Gestión de pruebas, que puede ser el líder de pruebas (QA) y el Jefe de Proyecto como nivel de escalamiento. Para proyectos más grandes pueden requerirse Líderes técnicos, de pruebas y de proyectos de varias áreas, según la magnitud. 
• Definir con antelación 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 diagnóstico. 
• Establecer de antemano el formato y datos que deben incluirse en el reporte de la incidencia, asegurando que se incluyan todas las características de los datos involucrados en el incidente, para asegurar que puedan conseguirse datos similares en ambiente de pruebas para la réplica. 

Cuando sucede lo peor: Los pasos a seguir para atender el incidente

El siguiente procedimiento se aplica durante el período de posimplantación de un nuevo desarrollo, los responsables de replicar y corregir los incidentes son el equipo de proyecto, al no haberse esté entregado aún al equipo de soporte. Los pasos son los siguientes:

1. Movilizar a los responsables (Responsable: Contacto Primario): Cuando se trata de incidentes posproducción, la respuesta rápida y efectiva es crítica, considerando que el incidente podría estar dejando sin servicio a todos o algunos usuarios, u otras consecuencias como el registro de información errónea en base de datos.
2. Revisión 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 aún están aprendiendo a utilizar. Los incidentes descartados por uso inadecuado de la aplicación deben analizarse también para determinar donde se originó la confusión del usuario y evaluar posibles mejoras.
3. Replicar el incidente en un ambiente homologado con producción (Responsable: Equipo de Pruebas): Utilizar el ambiente de calidad (en el cual se realizaron las pruebas de aceptación del usuario) para intentar replicar el incidente, descartando si este no logra replicarse. 
4. Capturar las evidencias del incidente (Responsable: Equipo de Pruebas): Si se confirma que el incidente ocurre en ambiente de calidad, tomar las evidencias para la documentación (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 diagnóstico 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 continúa el proceso. De confirmar que es aplicable al proyecto, se deriva al equipo de desarrollo responsable según protocolo.
6. Diagnosticar el incidente (Responsable: Equipo de desarrollo de área): Haciendo uso de herramientas de diagnóstico automatizadas o manuales, el equipo de desarrollo identifica la causa raíz del error en ambiente de producción. En este paso, es común que el analista programador solicite apoyo al equipo de pruebas que realizó la réplica del incidente.
7. Aplicar el correctivo y probarlo en ambiente de desarrollo (Responsable: Equipo de desarrollo de área): La corrección del incidente debe cumplir el ciclo de desarrollo, es decir, debe elaborarse una especificación técnica que debe ser aprobada, luego realizar el desarrollo y las pruebas unitarias. 
8. Transferir corrección 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 corrección 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.
9. Realizar pruebas de verificación de corrección y capturar evidencias (Responsable: Equipo de pruebas): Utilizando guion de pruebas, se verifica la corrección y se registra la documentación (capturas de pantalla), si las pruebas no son superadas se retorna incidencia al equipo de desarrollo.
10. Pruebas de aceptación de la corrección: Se convoca al usuario o cliente que reporto la incidencia, se le presentan las evidencias del antes con la réplica del incidente y de las evidencias de corrección. Luego se procede a realizar una prueba en vivo para demostrar que ha concluido. Finalmente se obtiene la aceptación formal del usuario.
11. Transferir corrección a ambiente de producción: Se ejecuta control de cambios de la corrección y se transfiere esta a ambiente de producción.
12. Verificar corrección en producción: El usuario o cliente que reporto el error ejecuta la verificación poscambio y con eso cierra el caso. 

Conclusión

El procedimiento descrito en este artículo pretende definir un protocolo que puede distribuirse a los equipos de proyecto, encargados de atender los incidentes que se reporten en el período de posimplantación. La mejor forma de atender este tipo de incidentes es estar preparados con equipos, roles, responsabilidades, canales de comunicación y procedimientos previamente definidos.

¿Y qué opina usted?, ¿Qué procedimiento aplicaría para resolver incidentes en el período posimplantación?, ¿Cuáles han sido sus resultados? Déjanos un comentario en el foro.

¿Buscas más información de gerencia de informática?

¿Quieres obtener completamente gratis y directamente en tu correo electrónico plantillas, artículos y otros recursos de gerencia de informática?, entonces presiona "suscríbete" a continuación.

Suscríbete a la lista de correo electrónico:


Vía FeedBurner, se abrirá una nueva ventana

También puedes seguirnos al Twitter @PMOInformatica, página de Facebook o perfil de Linkedin.

Otros artículos

>> Las Habilidades y Conocimientos más buscados en el área de Tecnología de Información (TI)

>> Las reuniones de trabajo: más productividad, menos reuniones

>> Ambientes de pruebas integrales de software: Buenas prácticas

>> Ambientes de desarrollo de software : Buenas prácticas

>> Algunas prácticas de desarrollo de aplicaciones web para asegurar calidad, mantenibilidad, escalabilidad y seguridad