Los costes asociados a fallos de software y errores de código son una partida que a menudo incrementa de forma significativa el coste total de un proyecto de desarrollo. En una situación como la actual, en la que los presupuestos de TI están si cabe más ajustados y es más necesario que nunca ceñirse a lo presupuestado, la Certificación de Software se perfila como una herramienta idónea para asegurar la calidad en los desarrollos antes de su puesta efectiva en producción y así evitar costes imprevistos.
Al certificar la calidad de software se pretende fundamentalmente reducir el número de incidencias en la puesta en producción gracias a la detección temprana de defectos, reduciendo así el coste total del desarrollo. Paralelamente se pretende mejorar la percepción de los usuarios del producto final y tener un mecanismo sistematizado de control de la calidad del software entregado por los proveedores.
Se trata de buscar el punto de equilibrio óptimo entre lo que presentan los costes de inspección, que crecen a medida que se amplía la cantidad/calidad del chequeo y los costes en que se incurre a medida que crece el número de fallos. Asegurar la calidad tiene un coste, y los elementos que determinan dicho coste son tres: Prevención, Detección y Fallos. Debemos analizar el coste de cada elemento para decidir hasta dónde es rentable invertir en pruebas y en cuáles.
Ámbito de actuación
El ámbito de actuación en un proceso de certificación se enmarca en dos coordenadas fundamentales, que hacen referencia por un lado al cumplimiento por parte del aplicativo de una serie de requisitos, y por otro lado al cumplimiento con una serie de atributos de calidad establecidos en la norma ISO 9126
En cuanto a los atributos que ha de presentar el producto o aplicativo, hay que mencionar la documentación del mismo, que exista y presente el formato y contenidos obligatorios, el Control de Configuración, adecuado a la normativa de configuración de entornos, la Revisión de Normativas (Implantación de Aplicaciones, Gestión de logs), la Seguridad, en lo relativo a Gestión de Accesos y Vulnerabilidad, el análisis de código, y si éste es conforme a los estándares de desarrollo, qué grado de complejidad presenta, etc. Por último se incluyen pruebas de carga (cumplimiento de requisitos de rendimiento) y de usabilidad.
En lo que respecta a los atributos de calidad ISO 9126, hay que evaluar el grado de mantenibilidad (Testeabilidad, facilidad de cambio y análisis), la eficiencia, en relación con los tiempos de respuesta y utilización de recursos, la funcionalidad del aplicativo (idoneidad, exactitud e interoperabilidad) y la portabilidad del mismo, evaluando en qué medida es fácil de instalar, es adaptable a un entorno determinado y si es fácilmente reemplazable. Por último se evalúa la fiabilidad (madurez, tolerancia a fallos y recuperabilidad) y la usabilidad.
Optimización de costes en las actividades de pruebas
La actual coyuntura económica está motivando a su vez una reducción en los costes operativos de inspección y diagnóstico de resultados que sigue dos tendencias en función de las necesidades de cada empresa:
– Automatización de actividades de pruebas: Esta tendencia se está abordando principalmente en empresas con un ciclo de pruebas maduro o con un alto número de aplicativos a certificar. Se basa en una reingeniería del proceso de pruebas enfocado a identificar acciones que no aporten valor al proceso y que pueden ser automatizadas.
– Utilización de servicios de certificación exprés: Esta tendencia se está aplicando en empresas que no disponen de un gran número de aplicativos a certificar o que prefieren concentrar los esfuerzos de verificación y validación en los procesos de negocio principales. Se basa en una serie de pruebas estándar aplicada de forma puntual con objeto de anticipar mejoras de carácter metodológico, procedimental o de cara a medir la calidad de un aplicativo en cuestión identificando las causas de errores críticos en producción. La ejecución de una certificación exprés se realiza de forma externalizada y su duración puede oscilar de una a tres semanas en función de los requerimientos de calidad solicitados.
Resultado de la Verificación y Certificación
El resultado de las diferentes pruebas de verificación realizadas nos permitirá establecer un diagnóstico sobre el nivel de calidad que presenta el desarrollo en cuestión. En nuestra opinión, este diagnóstico debe establecer cuatro categorías o niveles de calidad, cuyo criterio fundamental es el nivel de riesgo que representa para la organización la puesta en producción de dicho desarrollo.
Así tenemos un primer nivel en el que no se aprecia desviación ni se han detectado incidencias. Se define un segundo nivel con desviación baja, no bloqueante, cuando el desarrollo no presenta problemas a la operativa actual pero puede afectar al mantenimiento futuro. Hay un tercer nivel, con desviación media y no bloqueante, que significa que puede entrar en producción pero representa un riesgo alto para la operativa del sistema. Por último, el nivel de desviación Alta, bloqueante, en el que el desarrollo presenta un número de fallos tan significativo como para suponer un grave riesgo para la Producción.
El diagnóstico anterior permite elaborar un dictamen con tres posibles recomendaciones, que están en función del nivel de desviación detectada con respecto a los estándares establecidos y de si los fallos detectados aconsejan o no la puesta en producción del desarrollo. Las recomendaciones son de:
– Aceptación – no se han detectado incidencias que desaconsejen el paso a Producción.
– Rechazo parcial – La Aplicación es apta para su paso a Producción aunque se recomienda la corrección de las incidencias en el próximo mantenimiento.
– Rechazo – se desaconseja el Paso a Producción.
Este tipo de análisis permite encontrar con rapidez las causas de los errores y el establecimiento de planes de acción de mejora a corto plazo que posibiliten desbloquear dichas desviaciones o dichos errores permitiendo mejorar la calidad del software en el entorno productivo con gran celeridad y bajo coste.
Tipología de pruebas
Hay un amplio abanico de pruebas, que tratan de analizar con exhaustividiad todos los posibles puntos de fallo, y no sólo en el momento de la puesta en producción, sino también de cara al futuro, cuando sean necesarias ampliaciones o actualizaciones de los aplicativos. Entre ellas se encuentran:
– Pruebas de Regresión, orientadas a medir el impacto que produce un evolutivo o correctivo sobre el rendimiento de las transacciones principales de un aplicativo con concurrencia de usuarios.
– Pruebas de Carga, para analizar el rendimiento del aplicativo en función de la concurrencia de usuarios e identificar el punto de ruptura del aplicativo ante exceso de carga.
– Pruebas de Usabilidad, orientadas a comprobar el cumplimiento de las normativas y estándares de usabilidad y accesibilidad definidas por la Norma UNE 139803:2004, así como de las Directrices para la Accesibilidad de los Contenidos Web (WCAG) del consorcio de la Web (W3C).
– Verificación de Normativas, en lo que respecta a la existencia de la documentación del proyecto (Especificación de Requisitos, Análisis, Diseño, Plan de Pruebas, Manual de Producción, Informe de Pruebas y Manual de Configuración, etc.)
– Verificación Estándares de Desarrollo, Análisis de Complejidades y Análisis de Sentencias Prohibidas
