Establecer el flujo del proceso de validación de una mejora o una incidencia antes de su despliegue en un entorno productivo.

Alcance

Este proceso aplica a los productos de tipo aplicación que se gestionan en JIRA.

Roles

Los roles que intervienen en este proceso son

Flujo del proceso

Validación de mejoras e incidencias que están en una versión

Una vez que el proveedor desarrolla las mejoras que constituyen el alcance de una versión, es necesario que sean validadas normalmente por el Responsable Funcional/Responsable de producto de la aplicación.

Si en la validación se encuentran incidencias, al tratarse de entornos no productivos, no pueden ser consideradas incidencias como tale, por lo que deben ser consideradas no conformidades. Pueden ser de tipo de diferentes tipos:

•  funcional,
• técnica,
• de regresión
• de documentación
• de accesibilidad
• de usabilidad

 Si son originadas por una mejora concreta de la versión desarrollada, puede indicarse.

Podrán ser detectadas por el Responsable Funcional, el Responsable del producto o el propio Proveedor, así como por los usuarios de la Oficina de Calidad

.

Cuando se detecta una no conformidad no podrá validarse la mejora/incidencia afectada hasta que:

• Se corrija por parte del proveedor la no conformidad y sea validada

• favorablemente su resolución por quien la detecte
• Se decida que la no conformidad no va a ser corregida en la misma versión en la que se implanta la mejora/incidencia que la origina.

Identificación de una no conformidad

Como ya hemos indicado, las no conformidades

se detectan por cualquier usuario que participe en la validación funcional del alcance de una versión. Esto implica que siempre deben estar relacionadas no sólo con una versión, sino con una entrega y que si se tienen que corregir antes de desplegar la versión en producción, deberán ser corregidas en otra entrega, lo que implicará una nueva SVE y una nueva PL para desplegarla normalmente en el entorno de preproducción.

Una vez que la no conformidad ha sido registrada será necesario que sea analizada por el proveedor de desarrollo quien podrá aceptarla para su corrección o bien rechazarla, lo que implicará que tendrá que ser analizada de nuevo bien por el Responsable funcional o por el Responsable de la OCA para determinar finalmente si debe ser cerrada o si por el contrario debe ser corregida independientemente de lo que haya dicho inicialmente el proveedor.

Corrección de no conformidades

Una vez que se determina que la no conformidad debe ser corregida, será necesario determinar si debe ser corregida en esa versión o si por el contrario puede ser corregida en una versión posterior del producto. En este último caso, el Responsable de producto será el encargado de desasignar la no conformidad de la versión, asumiendo la responsabilidad de que la versión se va a implantar en Producción con ese fallo.

En el caso en que se decida que debe ser corregida en esa versión, el Proveedor comenzará su resolución, indicando la entrega en la que

pretende hacerlo.

A partir de ahí, se establece un pequeño ciclo de vida para la no conformidad pasando por los siguientes estados:

• En desarrollo. En ese estado puede ocurrir que el proveedor decida no corregir en ese momento la no conformidad y dejarla de nuevo como aceptada a la espera de decidir de nuevo con el Responsable de producto si se corrige en esa o en versiones posteriores del producto.
• En testing
• Pdte. validar: la no conformidad está resuleta por el proveedor a la espera de su validación.

Validación de no conformidades

Una vez que la no conformidad está resuelta debe ser validad por el Responsable funcional, por la Oficina de Calidad o por ambas partes (en el caso de que se haya detectado por ambas). Si una de las partes no valida la corrección hecha, la no conformidad vuelve al estado Aceptada en espera de decidir si se va a corregir de nuevo en otra entrega de esa misma versión o en una versión posterior. La entrega en la que el proveedor creía haber corregido la no conformidad pasará a ser una entrega afectada, puesto que en ella también se dará el fallo.

Convertir no conformidades en mejoras o incidencias

Es posible que se detecte una no conformidad que no sea tal, y que tras ser analizada se llegue a la conclusión de que realmente no lo sea y que se trate de una mejora o de una incidencia. En el caso de que sea una mejora, podría convertirse en una entidad de ese tipo en el mismo estado en el que estuviera la no conformidad origen. Para ello será necesario indicar la urgencia de la futura mejora y explicar el o los motivos que llevan a este cambio.

Si la no conformidad por el contrario se decide que es una incidencia, se cerrará directamente para poder registrar la incidencia por los canales reglamentarios.

No conformidades en versiones en Producción

A veces se da la circunstancia de tener que hacer revisiones de accesibilidad en versiones que están en Producción por parte de la Ofician de Calidad. En esos casos, las no conformidades no podrán ser registradas como tales, con lo que como consecuencia del servicio que hace la OCA se hará un informe para que el Responsable de producto registre lo detectado por la OCA como mejoras o incidencias.

Para acceder al manual de JIRA en el que se detalla el flujo de mejoras, incidencias y no conformidades, pincha aquí.