Cómo medir el ROI en la actividad de testing Mediante la reducción de errores y costes asociados es posible establecer el Retorno de Inversión (ROI) en las pruebas de software, marcarse objetivos de rentabilidad y controlar su cumplimiento, incluso limitando el impacto económico al ahorro generado. En particular, una unidad de pruebas de certificación software permite obtener retornos que superan el 200% Pablo Rivera Moreno Director de operaciones de Panel Sistemas l 53
La calidad en el software, por fin, es un objetivo tanto en el proceso de creación como en el de puesta en producción. Nos hemos acostumbrado a la calidad, y los fallos habituales en los sistemas y aplicaciones han dejado de ser considerados un mal necesario asociado al desarrollo. La mejora de la calidad del software continúa aumentando su relevancia en el desarrollo de aplicaciones. Se invierte alrededor de $50bn al año en pruebas de software y sistemas de redes y, según diversos estudios, un gran número de empresas en España y Latinoamérica (91%) consideran los procesos de testing durante el ciclo de vida del software fundamentales para la continuidad de sus negocios. Cada vez más organizaciones están convencidas de que esta actividad no es una pérdida de tiempo ni de dinero. Sabemos que es un proceso lento, que requiere una inversión y un esfuerzo continuado en el tiempo, pero siempre es más barato que la no calidad. Sin embargo, el escenario actual ha cambiado. Existe hoy en día una enorme presión sobre los costes de las áreas de SI de las organizaciones y la calidad es un factor muy comprometido por esta presión. Además, en muchas ocasiones, resulta imposible determinar y demostrar cuál ha sido la eficiencia de las actividades de testing y cómo podrían haberse mejorado, si no resuelto, los problemas de calidad surgidos durante el desarrollo del producto. En definitiva, es necesario disponer de modelos empíricos que aporten un nuevo enfoque para medir la eficiencia, en términos de coste y rendimiento, de las actividades de aseguramiento de la calidad del software, demostrando así que es posible obtener un ROI de las pruebas de software. INTRODUCCIÓN El sector de las Tecnologías de la Información (TI) es un sector muy maduro en lo relativo a construcción o mantenimiento de aplicaciones. Sin embargo, en el ámbito de la calidad software, todavía hay mucho camino por recorrer. Antes del año 2012, el mercado era muy distinto. El negocio del software testing estaba focalizado en el segmento de gran cliente. Fruto de una pobre planificación en muchos procesos de creación de software, y a la falta de metodologías basadas en el aseguramiento de la calidad, se realizaban proyectos de testing de gran volumen, con continuidad en el tiempo y demanda estable, y siguiendo modelos clásicos de gestión de las pruebas basados en criterios teórico-predictivos. Asimismo, la industria de las pruebas de software todavía es un hervidero disjunto de modelos y criterios. Por la tipología de este servicio se tiende a aceptar que el beneficio obtenido, al invertir en la actividad de testing, es un bien intangible solo apreciable para creyentes en la calidad del software. Pero el escenario actual ha cambiado. Existe una enorme presión sobre los costes de las áreas de SI de las organizaciones, y la calidad es un factor muy comprometido por esta presión. De hecho, sigue habiendo empresas que optan por procesos de creación de software sin controles de calidad, o muy pocos y muy específicos. Este constante ajuste presupuestario en el que viven todos los departamentos de TI, se cobra muchas veces una víctima: las pruebas. En muchos casos, se exige al propio proveedor de software que implemente los procesos que garanticen un rendimiento perfecto, asumiendo que haya más penalizaciones al área de desarrollo, hasta que el software funcione o sea de la calidad esperada. Parece algo simple y lógico pero, sin embargo, no es tan sencillo. En entornos poco complejos o no críticos para el negocio es habitual que las organizaciones aún no hayan entendido la necesidad de trabajar su software con calidad. Pero en organizaciones maduras y con unos modelos de outsourcing ya intrincados en la misma, el ritmo de implantación de evolutivos de aplicaciones hace inviable simplificaciones como estas. A poco que se persiga la eficiencia y la mejora de la calidad, se está impactando en todo el modelo organizativo relacionado con TI. Por tanto, se requieren estructuras organizativas, metodologías y prácticas de operación como la actividad de testing, que permitan prever comportamientos y contingencias ante el despliegue del nuevo software. En definitiva, no es que ya no haya vocación por la calidad software. Simplemente, las menores inversiones, las mejores herramientas de creación de software y las nuevas metodologías de testing ágil, nos obligan a cambiar los planteamientos de cara a nuestros clientes. Y esto nos lleva en muchos casos a cuestionarnos si un proceso de verificación y validación independiente del software implicará un sobrecoste innecesario. Ya no es suficiente con creer en los beneficios de la calidad software. Ahora más que nunca hay que demostrarlo. DESARROLLANDO EL MODELO DE CÁLCULO DEL ROI EN TESTING En la actualidad, más del 80% de los costes en servicios profesionales relacionados con el ciclo de vida de los sistemas software, son costes de mantenimiento de los sistemas existentes. Pues bien, a pesar de lo que pueda aparentar (ingeniería, investigación e innovación), en el testing priman precisamente dos objetivos: reducir errores y reducir costes de mantenimiento del software. Y en una época en que las inversiones se miran con lupa, es necesario demostrar este ahorro. Para ello, se requieren modelos empíricos que sustenten estos ahorros por la implantación de modelos de software testing, utilizando modelos de estimación aplicables al sector TI en el que nos movemos, realimentándolo con la experiencia diaria 54 l Estrategia Financiera Nº 315 Abril 2014
de cada negocio, y teniendo en cuenta las siguientes consideraciones previas: Las pruebas de software no son un proceso terminal, asociado a la concepción tradicional de la calidad. El testing actual es un proceso iterativo que debe ser realimentado durante todo el ciclo de desarrollo de las aplicaciones, y que lleva implícito mejoras de rendimiento de procesos que deben ser medibles y optimizables. Recordemos que el coste de eliminar un defecto del software crece exponencialmente por cada fase del ciclo de vida en la cual permanece sin descubrir. Por tanto, el valor relativo del coste medio de eliminación de un defecto, en función de la parte del ciclo de vida en el que se detecta, es predecible (ver figura 1). Alinear la actividad de desarrollo y la de pruebas es más que necesario, es imprescindible. Por ello es necesaria hoy en día una metodología organizativa (tipo DTA Methodology o Metodología de Alineamiento de Desarrollo y Testing), de creciente importancia por la aplicación de prácticas Agile o esquemas de proceso V-model. Se puede medir la eficiencia de las actividades de aseguramiento de la calidad del software, demostrando que es posible obtener un ROI de las pruebas de software Gráfico 1. Curva coste eliminación defecto Coste de eliminación relativo 70 60 50 40 30 20 Es fundamental optimizar el esfuerzo realizado en pruebas, focalizando los recursos de testing donde pueden proporcionar más valor, y definiendo una frontera a través de una unidad de certificación independiente que garantice el equilibrio. 10 0 Rq Diseño Construcción Coste de eliminación defectos por Fase Certif. e Impl. Acep. Usuario En definitiva, toda actividad debe generar resultados medibles, como base para analizar, mejorar y controlar su comportamiento. Y las pruebas de software no son una excepción. Para ello, existen modelos que aúnan las mejores prácticas para la gestión de la calidad del software y para la valoración del Retorno de la Inversión (ROI) en pruebas de software. Estos modelos están basados en diferentes teorías de modelización y simulación que tipifican escenarios de aplicaciones software diversos, predicen comportamientos de inyección y eliminación de errores y su proyección en ahorros de costes. Nuestro modelo de cálculo del ROI mide la eficiencia, en términos de coste y rendimiento, de las actividades de aseguramiento de la calidad del software, apoyándose en el cálculo de la Eficiencia en la Eliminación de Errores (DRE, Defect Removal Efficiency ) y creando los sistemas de información necesarios para sustentarlo y permitir la toma de decisiones. Esta tasa DRE se define (para cada fase de desarrollo) como Siendo: DRE = E / (E+D) E: el número de errores encontrados antes de la entrega al usuario final. D: el número de errores encontrados después de la entrega. El modelo considera que el valor relativo del coste medio de eliminación de un error es predecible en función de la parte del ciclo de vida en el que se detecta dicho error. Sin embargo, los niveles de eficiencia exigibles a los modelos de pruebas de software no son una ciencia exacta, puesto que dependen del nivel de madurez de procesos. También hay que tener muy en cuenta que las pruebas de software no son una bala de plata y no conseguirán un software de alta calidad por sí mismas. Aplicar técnicas de ingeniería de software sólidas mejora siempre el software antes de empezar cualquier tipo de pruebas, siendo muy eficaces económicamente encontrando o limitando ciertos tipos de incidencias. Para el cálculo de la Eficiencia en Eliminación de Errores (DRE) debemos cuantificar primero los Defectos Potenciales (DPs) de nuestra aplicación. La tasa de Defecto Potencial es el número de errores más probable que será encontrado durante una fase del ciclo de vida del software. Su valor ha sido consensuado l 55
En el testing priman dos objetivos: reducir errores y reducir costes de mantenimiento del software. Y en esta época es necesario demostrar este ahorro mediante sucesivos estudios(1) sobre datos de diversos proyectos software, medidos en Puntos Función (PF). Podemos afirmar incluso que partiendo de los defectos potencialmente presentes en el código generado establecemos la eficiencia de una organización según su madurez. Asimismo, se puede aproximar la cuantificación de los Defectos Potenciales, de modo que éstos sean dependientes del tamaño de la aplicación, modelándose con la siguiente ecuación(2). DP = PF ^ 1,25 (relación exponencial) Donde PF son los Puntos Función (medida del tamaño de una aplicación software). En resumen, los estudios realizados permiten establecer algunas conclusiones. Por ejemplo, se considera que las organizaciones con más de 7 Defectos Potenciales por Punto Función y con una DRE de menos del 75% ofrecen al mercado unos procesos de construcción de mala calidad. Y por el contrario, conseguir menos de 2,5 Defectos Potenciales por Punto Función en el software y DRE de más del 95% es casi misión imposible. Está además demostrado que los porcentajes de Eficiencia en la Eliminación de Errores (DRE%) se relacionan con el nivel de madurez de las organizaciones. Así, organizaciones con niveles de madurez 1-2 según el modelo CMMi (Capacity Maturity Model) tienen una DRE% de entre el 85% y el 89%, mientras que organizaciones con niveles de madurez de 3 o superior, superan el 91% en tasa de DRE%. En la práctica, no obstante, es muy complicado en nuestro sector trabajar con DREs de más del 85%. Además, cada punto porcentual de mejora es exponencial con respecto al coste de implantación de dicha mejora. Como referencia, un DRE de más del 95% sólo es planteable en sistemas críticos en los que el plazo para llegar a producción ( timeto-market ) no es un objetivo estratégico y priman (1) Referencia obtenida a partir de una distribución de errores según simplificación de las fases del ciclo de vida P1-P7 y sobre datos del año 2008 de muestras en EEUU. Los datos se miden sobre PF y no sobre líneas de código. (2) Estudios que establecen la relación entre PFs y DPs, simulando el comportamiento de inyección de errores/resolución por fases, con funciones de distribución, simulando los efectos de la latencia hasta la eliminación de errores. otros objetivos estratégicos como la seguridad del software ( safety, caso de los Sistemas de Control de Tráfico Aéreo ATM ). Por ello, podemos establecer como un objetivo alcanzable conseguir un DRE (%) mayor del 80%. Por último, para poder calcular el ROI en términos económicos, el modelo alinea los indicadores de producción para desarrollo software con indicadores de producción para pruebas ( testing ) e implantación. Así, mientras que en el desarrollo de software el tamaño funcional se establece en Puntos Función (PFs), para las pruebas y certificación establecemos la unidad conceptual de productividad para las pruebas (CEP),como una función de los casos de uso (CUs) probados por persona y jornada. Con esta relación es posible calcular el ratio entre el coste de ambas actividades: pruebas frente a desarrollo, asignando un coste estimado a cada PF y CEP, de tal forma que un ratio coste certificación / coste desarrollo de un 17,8%, aproximadamente, es un dato bastante habitual en el sector. El método, además, establece el cálculo del ROI desde dos vertientes, como contraposición de escenarios. De esta forma, presenta tanto el cálculo del ROI financiero, que es el más usado habitualmente, como el ROI schedule, muy apreciado en departamentos de ingeniería de SW. CONCLUSIONES Con este modelo, tras desgranar todos estos ingredientes y establecer distintos escenarios en función de la madurez del proceso de pruebas y de su tasa de eliminación de errores (DRE), podemos concluir que el Retorno de la Inversión (ROI) en una Unidad de Pruebas de Certificación Software, supera el 200% para ROI Financiero o el 40% para el ROI Schedule. La comparativa entre el Retorno de la Inversión de una organización con esta Unidad de Pruebas de Certificación y un equipo de desarrollo con madurez CMMI nivel 3-4, frente a ejecutar el mismo proyecto con un equipo poco maduro y sin unidad de Pruebas de Certificación es de un 261% para el ROI Financiero y de un 48% para el ROI Schedule. De este modelo de cálculo del ROI se extraen otras conclusiones muy importantes, como el hecho de que contar con una unidad de certificación alivia muy significativamente la presión sobre la carga que tiene que asumir la parte usuaria en eliminación de defectos, pasando de ratios del 57% hasta el 14%. También se pueden observar que ligeros incrementos de la tasa DRE afectan ostensiblemente el ROI, y que cuanto más productivo es el equipo de desarrollo software, más rentable es la inversión en una unidad de pruebas de certificación. El modelo demuestra también que, por regla general, cuanto mayor es una aplicación (más Puntos Función), mejores ROI se obtienen con la actividad de pruebas, y que aumentos en la inversión dedicada a herramientas de automatización de las pruebas permiten acelerar significativamente el ROI. 56 l Estrategia Financiera Nº 315 Abril 2014
Nuestro modelo, amén de ser sólido empírica y conceptualmente, está verificado en los principales contextos de testing a nivel nacional (España) y es adaptable a escenarios de negocio específicos para cada realidad empresarial. Además, permite ajustar el intervalo de determinación de coste de eliminación de errores y establecer una realidad de fases del ciclo de vida distinta. También puede adaptarse a los criterios de productividad y costes por Punto Función propios de cada caso, incluyendo correctores de inversión por sinergias de volumen. en definitiva, hay muchos argumentos a favor para afirmar que la actividad de pruebas y aseguramiento de la calidad del software es relevante y necesaria, destacando entre ellos que es posible y demostrable la obtención de importantes retornos de la inversión de esta actividad gracias a la reducción de errores y de costes, pudiendo marcarse objetivos de rentabilidad y controlar su cumplimiento, incluso limitando el impacto económico al ahorro generado. Organizaciones con más de 7 Defectos Potenciales por Punto Función y con una DRE de menos del 75% ofrecen unos procesos de construcción de mala calidad BIBLIOGRAFÍA Panel Sistemas Informáticos: Return on Testing Investment. Technical White Paper about the model for calculating the Return On Investment (ROI) in Software Testing activities. http://blog. panel.es/index.php/centro-de-descargas/ Galin D: Software Quality Assurance: From theory to implementation, Pearson Education Limited. LIM, S. so, Y, Cha, S. D. and kwon, Y. R.: An empirical Study on Software Error Detection: Voting, Instrumentation, and Fagan Inspection. Jones, C.: Estimating SW Costs, McGraw-Hill. Lazic, Lj., Mastorakis, N.: Orthogonal Array Application for optimal combination of SW defect detection techniques choices. Lazic, Lj., Mastorakis, N.: The Integrated and Optimized Software Testing Process. Lazic, Lj., Mastorakis, N.: Applying simulation and design of experiments to the embebed software testing process. Müller, M.: About the Return on Investment of Test-Driven Development. Rodríguez, P.: Independent verification and validation to ensure higher confidence in the software controlling critical systems, Latin American congress on requirements engineering & software testing, lacrest Medellín 2012, Colombia. http://www.lacrest.org/2012/images/memorias/ dia1/15.pdf International SW Benchmarking standard group: The Sw Metrics Compendium. Moral, S.: Mantenimiento del software, Grupo de investigación Kybele, Universidad Rey Juan Carlos, Madrid 2012 http://www.kybele.etsii. urjc.es/docencia/is4/2012-2013/material/ IS4.11.12.Tema.XIII.MantenimientoSW.pdf SÓLO EN http://estrategiafinanciera.wke.es Acceda a: Por qué se debe probar un sistema software? Testing de software para la modernización de infraestructuras Todo lo publicado sobre #testing de software l 57