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:
· 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
Referencias
· 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.
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
Post originalmente publicado en http://excelza.blogspot.com.ar/ - 11-10-2011
Referencias
1.
www.iso.org
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.
