jueves, 4 de julio de 2013

¿Hace falta un terremoto?

Al leer tiempo atrás conceptos de BCM (Business Continuity Management) y de ITSCM (IT Service Continuity Management), no pude dejar de relacionar el tema con algunos aspectos de las pruebas de software, la evaluación y mitigación de riesgos y la gestión de servicios en general. 
Esos aspectos están relacionados también con las características / sub-características / métricas de calidad de producto descriptas en los estándares ISO/IEC 25000 SQuaRE de calidad de productos de software y su predecesor ISO 9126, el que pueden evaluarse según el proceso descripto por la norma ISO 14598, con los estándares ISO 20000 que especifican los requisitos de implementación de la gestión de servicios de TI y con la evaluación de expectativas vs percepciones de la calidad de los servicios que analiza ServQual (Ver Referencias [5]).

En definitiva, esos aspectos se relacionan con los requisitos o requerimientos no funcionales (RNFs) de las aplicaciones que construimos y probamos, que deberían reflejar las expectativas de clientes y otros interesados y deberían ser posibles de cumplir vía el diseño de las aplicaciones. 
Lamentablemente, en muchas ocasiones, estos aspectos son ignorados o postergados en los proyectos de construcción de software, hasta que ocurren desastres, accidentes, ataques u otros incidentes más o menos críticos, que no siempre necesitan ser de la gravedad de un terremoto, pero que afectan a la disponibilidad de los servicios de TI, o incluso a la posibilidad o forma de restaurar esos servicios luego de algún evento que ha afectado a su continuidad.

¿Por qué digo que lamentablemente estos aspectos son ignorados o postergados?
Porque suele ocurrir que:

·         Los RNFs no están especificados, detallados y/o cuantificados.
·         Se considera que no es momento de probarlos, porque se puede hacer más adelante, o no son riesgosos, o no hay tiempo antes de salir a producción.
·         Se considera que no es momento de incluirlos en el análisis o diseño de la solución, porque se pueden agregar más adelante.
·         No se ha considerado qué puede ocurrir en ambientes productivos, con mayor interacción de componentes de HW / SW que en los ambientes de prueba.
·         No se ha previsto qué pasa con el crecimiento de tamaño de entidades de datos, y/o no se han previsto mecanismos de depuración de las mismas.
·         No se han previsto mecanismos de recuperación ante caídas, o lo más grave aún, no se ha analizado o diseñado para gestionar transacciones en las aplicaciones que lo requieren. También se considera que esto es algo que puede agregarse más tarde, o que lo provee el software.
·         No se ha planificado quién, cuándo, cómo se actúa ante algún incidente o desastre, o cómo se restaurará la operación normal del sistema, o en qué condiciones de pérdida de información podrá hacerse, o se desconoce incluso si toda la información necesaria está respaldada.
·         No se ha analizado si en función a las características y tipo de solución de software o de servicio ofrecido, existen disposiciones legales o regulatorias que apliquen a la misma.
·         Se considera que todo se resuelve agregando más o mejores servidores / disco / memoria / hardware de comunicaciones.
·         … y seguramente cada uno tiene un conjunto más de ítems que agregar a esta lista, a partir de su experiencia en diversos proyectos y organizaciones…


Mi opinión


Desde nuestro rol en las áreas de Calidad o como líderes de práctica, líderes de equipos, o como testers, es nuestra responsabilidad llamar la atención sobre estos temas al líder de proyecto, cuando consideramos que pueden haber sido descuidados, o no los encontramos representados en los planes de proyecto y/o de prueba. Al menos preguntar. 
Hacen a la calidad de los productos y servicios que estamos colaborando a entregar, y finalmente a la satisfacción de las expectativas de los interesados.
 
Está claro que los requerimientos no los ponemos nosotros, ni podemos constituirnos en los "guardianes de la calidad" impidiendo que se entreguen a producción productos que creemos no están totalmente probados o todavía presentan defectos… por algo hablamos de pruebas basadas en riesgos, de entregar productos con un nivel suficiente de calidad, de priorizar defectos y no corregirlos, de involucrar a referentes usuarios en esa priorización, etc…
Pero también considero que está totalmente en línea con nuestra misión como testers, capacitarnos y "evangelizar" sobre estos conceptos… antes de que nos golpee algún terremoto.

Post originalmente publicado en http://excelza.blogspot.com.ar/ - 11-10-2011

Referencias

1.    www.iso.org
2.    ISO/IEC 25000 SQuaRE
Software Engineering - Software product Quality Requirements and Evaluation
3.    www.itil.org
4.    Implementing ISO/IEC 20000 Certification - The Roadmap (ITSM Library) - Van Haren Publishing
5.    SERVQUAL: A Multiple-Item  Scale for Measuring Customer Perceptions of Service Quality  
6.    ISO/IEC TR 9126-3:2003 - Software engineering — Product quality — Part 3: Internal metrics.

No hay comentarios:

Publicar un comentario