riesgos.jpgPodemos implantar un sistema de la calidad, partiendo de documentos de requerimientos y/o de casos de uso, podemos escribir los planes de pruebas, hacer el diseño y escribir al detalle todos los casos de prueba, podemos ejecutarlos en paralelo al desarrollo e ir manteniéndolos con los cambios.

Con todo eso puede valer para tener un producto de calidad, pero ¿qué pasa si añadimos un ingrediente más a la receta: el análisis y gestión de riesgos?

La actividad de la gestión de riesgos no es un trámite o formalismo a cumplimentar para superar una certificación: es algo útil. La gestión de riesgos cierra el círculo, vinculando requerimientos, riesgos y casos de prueba que controlan la mitigación de estos riesgos.

¿Qué aporta este ingrediente?

En primer lugar implica la revisión exhaustiva de los requerimientos (con la consecuente detección de incoherencias, lagunas o indefiniciones).

También nos obliga a pensar y definir el uso previsto de la aplicación, determinando exactamente el entorno de uso y los potenciales afectados en caso de fallo (operadores, clientes/pacientes, medio ambiente, empresa, etc.), así como el nivel de criticidad de la aplicación.

Tras el análisis tenemos identificados, evaluados y categorizados los riesgos. Esto nos proporciona una visión clara de cuáles son los módulos o áreas más críticas de la aplicación y de aquellas funcionalidades que implican mayores riesgos. Esto es de vital importancia a la hora de planificar cada una de las fases de verificación a lo largo del ciclo de vida de desarrollo del proyecto. Nos ayuda a priorizar nuestros casos de prueba, sobretodo en aquellas fases finales en las que los plazos se acortan, el tiempo apremia y hay que asumir ciertos riesgos con el máximo de cobertura.

Cuando decidimos atacar los riesgos que más impacto pueden tener, definimos mitigaciones para cada uno de ellos, teniendo en cuenta el balance entre el coste de la implementación de la mitigación, el beneficio que aporta esa funcionalidad y el daño o impacto real del error en caso de producirse.
Los riesgos se tienen que mitigar tanto como sea posible, dentro de lo razonablemente práctico (‘As Low As Reasonably Practicable-‘ALARP principle’).

Las mitigaciones previenen errores que podríamos haber pasado por alto en nuestros casos de prueba. Al definir nuevos casos de prueba que verifican que las mitigaciones se han implementado como se esperaba, estamos evitando que esos errores aparezcan una vez la aplicación esté en su uso final. Tenemos así enlazados los requerimientos, con los riesgos que pueden entrañar y con las pruebas que verifican las mitigaciones.

Cada vez que se introduce una petición de cambio en los requerimientos o aparece un error en la aplicación, podemos evaluar y categorizar el riesgo que implica, desde esta perspectiva, teniendo así más argumentos para decidir sobre su implementación o corrección. Y así durante toda la vida del proyecto.

Be Sociable, Share!