¿Hace falta un terremoto? …
(Publicado originalmente septiembre 2010)
Releyendo recientemente 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, y la evaluación y mitigación de riesgos, y la gestión de servicios en general, que también hemos destacado en otros artículos de este blog mis colegas y yo anteriormente.
Esos aspectos están relacionados también con las características / sub-características / métricas de calidad de producto descriptas en la norma ISO 9126 y que pueden evaluarse según el proceso descripto por la norma ISO 14598, con las más actuales ISO/IEC 25000 SQuaRE
de calidad de productos de software, y con las normas ISO 20000 que especifican los requisitos de implementación de la gestión de servicios de TI. (Ver Referencias)
En definitiva, están relacionados con los requisitos o requerimientos no funcionales (RNFs) de las aplicaciones que construimos y probamos.
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 tipo de 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 considerarlos en el análisis o diseño de la solución, porque se puede 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.
- 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, 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, 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…
Mis opiniones
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 prueba. Al menos preguntar.
Hacen a la calidad de los productos y servicios que estamos colaborando a entregar.
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.
Referencias
- ISO/IEC TR 9126-3:2003(E) - Software engineering — Product quality — Part 3: Internal metrics.
- ITIL® v3
- http://www.iso.org/iso/catalogue_detail.htm?csnumber=35683
- Implementing ISO/IEC 20000 Certification - The Roadmap (ITSM Library) - Van Haren Publishing
- http://excelza.blogspot.com/2009/12/sobre-pruebas-de-software-y-servicios.html
- http://excelza.blogspot.com/2010/03/arriesgamos-o-no-arriesgamos.html
- http://excelza.blogspot.com/2009/10/ti-servicios-de-valor-para-el-negocio.html
- http://excelza.blogspot.com/2009/10/sobre-nuestra-mision-como-testers.html
- http://excelza.blogspot.com/2009/11/pensando-que-probar.html
- http://excelza.blogspot.com/2009/12/isoiec-20000-en-pocas-palabras.html
No hay comentarios:
Publicar un comentario