Published 15 years ago
(updated 12 years ago)
Resultados del 2º Concurso e-Quallity
Recientemente el proceso de prueba de software, de la empresa en la que laboro, fue certificado con un nivel muy alto tanto en el modelo estadounidense Testing Maturity
Model (TMM) como en el europeo Test
Process Improvement (TPI).
Aprovechando esta experiencia el año pasado lanzamos el Concurso e-Quallity 2007, en el que convocamos a la comunidad desarrolladora nacional de software a enviarnos productos pequeños terminados, para encontrar los productos con menor densidad de defectos (cantidad de defectos entre tamaño). Hicimos la premiación en el congreso SG’07 Conferencia y Expo, publicamos los resultados en la columna Prueba de Software
del número 20 de esta revista.
Este año llevamos a cabo el Concurso
e-Quallity 2008, del cual hicimos la premiación en el pasado congreso SG’08 Conferencia y Expo. Aquí mostraremos los resultados que se obtuvieron. Nuestro objetivo no es realizar un estudio estadístico riguroso, sino poner nuestro grano de arena en la generación de datos para cubrir el enorme hueco de información que tenemos respecto a métricas de calidad de los productos mexicanos, y su repercusión en la industria.
El Impacto de probar
inadecuadamente el Software
En la publicación de esa columna, mencionábamos que en 2003 la industria de los Estados Unidos perdió cerca del 1% de su PIB por pruebas de software inadecuadas o inexistentes, equivalente a casi 60 mil millones de dólares.
Comentamos que en México no existe una cuantificación semejante, pero que podemos pensar que en nuestro país el efecto es más nocivo, pues mientras que la industria del software estadounidense es mucho más grande y madura, la nuestra está apenas despegando, lo que dificulta ganar inercia positiva, y crea un nocivo circulo vicioso.
En The Impact of Software Testing in small Settings, publicamos datos del impacto económico de las de pruebas en dos proyectos reales en los que participamos. Puesto gráficamente tendríamos lo que se observa en la Figura 1.
Figura-1: Impacto económico de las pruebas
Aquí la curva negra muestra el consumo de los recursos al desarrollar un nuevo producto de software, considerando datos de A Guide to the Project Management Body of Knowledge; la verde los ingresos por ventas del producto; la azul los costos de mantenimiento cuando el software es probado adecuadamente antes de ser liberado y se elimina la mayoría de los defectos; y la roja los costos de mantenimiento cuando no se prueba o se prueba inadecuadamente el software. Cuando no se prueba adecuadamente el software, los costos de mantenimiento suelen mermar significativamente las utilidades (ventas – mantenimiento, grosso modo), dificultando la inversión en mercadotecnia e innovación en el producto, haciendo difícil el crecimiento de esa unidad de negocio.
El proceso y la muestra
La evaluación de servicios la realizamos en tres fases:
1. Un Diagnóstico del software: un tester experimentado realiza pruebas exploratorias y detecta una primera capa de defectos. Utilizando esa información y nuestro Modelo Predictivo, se genera una estimación de los defectos que aún se encuentran en el producto, el costo de detectarlos, y la comparación del producto contra la media de calidad de los productos que hemos probado.
2. Con esos datos del diagnóstico, el interesado puede optar por contratar las Pruebas Profundas para detectar esos defectos: si el producto está muy mal, sólo se justifica invertir en pruebas lo suficiente como para detectar una pequeña segunda capa de defectos críticos (por ejemplo, probar sólo alguna(s) sección(es)); si está muy bien, recomendamos no invertir en pruebas pues resultará muy caro detectar los defectos; si el producto tiene un estado intermedio, las pruebas profundas sí pueden ayudar a mejorar significativamente el producto.
3. Si después de estas pruebas profundas y las correspondientes pruebas regresivas, el software muestra un buen comportamiento al aplicar nuestro Modelo de Calidad de Producto, otorgamos nuestro Sello de Calidad e-Quality Approved, mismo que fue validado con apoyo del Consejo Nacional de Ciencia y Tecnología (CONACyT).
Para la ejecución del Concurso aplicamos un proceso que representa un downsizing del Diagnóstico mencionado arriba (fase 1).
Este año redujimos el número máximo de concursantes a 20. Una cantidad considerable de productos fueron rechazados, ya fuera porque se excedían en el tamaño, o porque no estaban completamente terminados.
La muestra final constó de 15 productos, provenientes de varios dominios de aplicación. Su tamaño (entre 20 y 30 meses hombre) se midió utilizando una métrica interna semejante a los puntos de función.
Resultados y Análisis
En la tabla que se muestra a continuación presenta datos sobre la calidad de los productos concursantes (KLOC = miles de líneas de código).
En un primer acercamiento, si comparamos directamente la segunda columna contra los resultados del Concurso pasado, podríamos pensar que estos productos son más estables que aquellos. Sin embargo, estos fueron más pequeños, y como dijera un autor “Size matters”: un producto de 100 KLOC con 300 defectos en realidad tiene constituyentes más confiables que un producto de 10 KLOC con 30 defectos… siempre y cuando tengan complejidad estructural semejante. (Esto es un tema en sí mismo, que buscaremos abordar en otro número.) Por tanto, la hipótesis no es concluyente.
Tabla-1: Densidad de Defectos en Productos mexicanos pequeños
Por otra parte, este año recabamos la métrica de los Defectos por KLOC (D/KLOC). En el marco del Encuentro Prosoft llevado a cabo recientemente, se anunció el impulso que se le brindará en nuestro país al modelo Team Software Process (TSP); ahí mismo Watts Humphrey (autor de ese modelo y de CMMI) declaró que con TSP se pueden alcanzar densidades de defectos de hasta 0.06 D/KLOC, contra los 7.50 para el Nivel 1 de CMMI-1, los 6.24 para el 2, los 4.73 para el 3, los 2.28 para el 4, y los 1.50 para el 5.
Los resultados obtenidos en este Concurso muestran que el 1º, 2º y 3er lugar tendrían densidades de defectos correspondientes al Nivel 4, 4 y 5 de CMMI respectivamente… lo curioso es que esas empresas no tienen tales acreditaciones.
Aquí también hay que considerar la salvedad del tamaño (size matters).
Conclusión
Un asunto pendiente que abordaremos en otro número es cómo los ganadores de los primeros lugares en el concurso lograron esos niveles de calidad.
Por otro lado: se asevera que con TSP se puede obtener densidades de defectos de hasta 0.06 D/KLOC; sin embargo, hemos encontrado empresas en nuestro país que reportan lograr densidades semejantes… lo curioso es que son los mismos programadores los que realizan las pruebas, no un equipo de testers (interno o externo) debidamente entrenado, al que se le pague por detectar defectos (a los desarrolladores no se les entrena para eso, ni se les paga por ello).
Para poder demostrar que con TSP verdaderamente se pueden alcanzar esas densidades de defectos, sería interesante ver resultados de pruebas realizadas por un tercero, no por los mismos desarrolladores de la empresa.
Habrá que esperar además, más precisión de TSP, pues no es lo mismo hablar de esas densidades de defectos para productos de 100 KLOC, que para productos de 1,000 KLOC.
Surge también la duda: ¿cuántas KLOC suelen tener los compiladores comerciales?, ¿con qué densidad de defectos? Si fuera superior a 0.06 D/KLOC, entonces los productos generados por ellos tendrían dificultad para alcanzar ese número.
Referencias
[ León-Carrillo, L.: Columna “Prueba de Software”, Software Gurú, Feb-Abr 2008 ]
[ León-Carrillo, L.: The Impact of Software Testing in small Settings, en Oktaba, H. and Piatini, M. et.al. Software Processes in small Enterprises. IGI Global. 2008 ]
[ The Project Management Institute: A Guide to the Project Management Body of Knowledge. USA, 2000 ]
[ e-quallity.net/definiciones.php ]
[ e-quallity.net ]
Acerca del Autor
Luis Vinicio León Carrillo es actualmente Director General de e-Quallity, empresa especializada en prueba de software. Fue profesorinvestigador en el ITESO durante varios años, que incluyeron una estancia de posgrado en prueba de software en Alemania, en la que abordó aspectos formales de dicha disciplina. Es autor de varias publicaciones nacionales e internacionales, e invitado frecuente en eventos
relacionados con la prueba de software.
Recientemente el proceso de prueba de software, de la empresa en la que laboro, fue certificado con un nivel muy alto tanto en el modelo estadounidense Testing Maturity
Model (TMM) como en el europeo Test
Process Improvement (TPI).
Aprovechando esta experiencia el año pasado lanzamos el Concurso e-Quallity 2007, en el que convocamos a la comunidad desarrolladora nacional de software a enviarnos productos pequeños terminados, para encontrar los productos con menor densidad de defectos (cantidad de defectos entre tamaño). Hicimos la premiación en el congreso SG’07 Conferencia y Expo, publicamos los resultados en la columna Prueba de Software
del número 20 de esta revista.
Este año llevamos a cabo el Concurso
e-Quallity 2008, del cual hicimos la premiación en el pasado congreso SG’08 Conferencia y Expo. Aquí mostraremos los resultados que se obtuvieron. Nuestro objetivo no es realizar un estudio estadístico riguroso, sino poner nuestro grano de arena en la generación de datos para cubrir el enorme hueco de información que tenemos respecto a métricas de calidad de los productos mexicanos, y su repercusión en la industria.
El Impacto de probar
inadecuadamente el Software
En la publicación de esa columna, mencionábamos que en 2003 la industria de los Estados Unidos perdió cerca del 1% de su PIB por pruebas de software inadecuadas o inexistentes, equivalente a casi 60 mil millones de dólares.
Comentamos que en México no existe una cuantificación semejante, pero que podemos pensar que en nuestro país el efecto es más nocivo, pues mientras que la industria del software estadounidense es mucho más grande y madura, la nuestra está apenas despegando, lo que dificulta ganar inercia positiva, y crea un nocivo circulo vicioso.
En The Impact of Software Testing in small Settings, publicamos datos del impacto económico de las de pruebas en dos proyectos reales en los que participamos. Puesto gráficamente tendríamos lo que se observa en la Figura 1.
Figura-1: Impacto económico de las pruebas
Aquí la curva negra muestra el consumo de los recursos al desarrollar un nuevo producto de software, considerando datos de A Guide to the Project Management Body of Knowledge; la verde los ingresos por ventas del producto; la azul los costos de mantenimiento cuando el software es probado adecuadamente antes de ser liberado y se elimina la mayoría de los defectos; y la roja los costos de mantenimiento cuando no se prueba o se prueba inadecuadamente el software. Cuando no se prueba adecuadamente el software, los costos de mantenimiento suelen mermar significativamente las utilidades (ventas – mantenimiento, grosso modo), dificultando la inversión en mercadotecnia e innovación en el producto, haciendo difícil el crecimiento de esa unidad de negocio.
El proceso y la muestra
La evaluación de servicios la realizamos en tres fases:
1. Un Diagnóstico del software: un tester experimentado realiza pruebas exploratorias y detecta una primera capa de defectos. Utilizando esa información y nuestro Modelo Predictivo, se genera una estimación de los defectos que aún se encuentran en el producto, el costo de detectarlos, y la comparación del producto contra la media de calidad de los productos que hemos probado.
2. Con esos datos del diagnóstico, el interesado puede optar por contratar las Pruebas Profundas para detectar esos defectos: si el producto está muy mal, sólo se justifica invertir en pruebas lo suficiente como para detectar una pequeña segunda capa de defectos críticos (por ejemplo, probar sólo alguna(s) sección(es)); si está muy bien, recomendamos no invertir en pruebas pues resultará muy caro detectar los defectos; si el producto tiene un estado intermedio, las pruebas profundas sí pueden ayudar a mejorar significativamente el producto.
3. Si después de estas pruebas profundas y las correspondientes pruebas regresivas, el software muestra un buen comportamiento al aplicar nuestro Modelo de Calidad de Producto, otorgamos nuestro Sello de Calidad e-Quality Approved, mismo que fue validado con apoyo del Consejo Nacional de Ciencia y Tecnología (CONACyT).
Para la ejecución del Concurso aplicamos un proceso que representa un downsizing del Diagnóstico mencionado arriba (fase 1).
Este año redujimos el número máximo de concursantes a 20. Una cantidad considerable de productos fueron rechazados, ya fuera porque se excedían en el tamaño, o porque no estaban completamente terminados.
La muestra final constó de 15 productos, provenientes de varios dominios de aplicación. Su tamaño (entre 20 y 30 meses hombre) se midió utilizando una métrica interna semejante a los puntos de función.
Resultados y Análisis
En la tabla que se muestra a continuación presenta datos sobre la calidad de los productos concursantes (KLOC = miles de líneas de código).
En un primer acercamiento, si comparamos directamente la segunda columna contra los resultados del Concurso pasado, podríamos pensar que estos productos son más estables que aquellos. Sin embargo, estos fueron más pequeños, y como dijera un autor “Size matters”: un producto de 100 KLOC con 300 defectos en realidad tiene constituyentes más confiables que un producto de 10 KLOC con 30 defectos… siempre y cuando tengan complejidad estructural semejante. (Esto es un tema en sí mismo, que buscaremos abordar en otro número.) Por tanto, la hipótesis no es concluyente.
Tabla-1: Densidad de Defectos en Productos mexicanos pequeños
Por otra parte, este año recabamos la métrica de los Defectos por KLOC (D/KLOC). En el marco del Encuentro Prosoft llevado a cabo recientemente, se anunció el impulso que se le brindará en nuestro país al modelo Team Software Process (TSP); ahí mismo Watts Humphrey (autor de ese modelo y de CMMI) declaró que con TSP se pueden alcanzar densidades de defectos de hasta 0.06 D/KLOC, contra los 7.50 para el Nivel 1 de CMMI-1, los 6.24 para el 2, los 4.73 para el 3, los 2.28 para el 4, y los 1.50 para el 5.
Los resultados obtenidos en este Concurso muestran que el 1º, 2º y 3er lugar tendrían densidades de defectos correspondientes al Nivel 4, 4 y 5 de CMMI respectivamente… lo curioso es que esas empresas no tienen tales acreditaciones.
Aquí también hay que considerar la salvedad del tamaño (size matters).
Conclusión
Un asunto pendiente que abordaremos en otro número es cómo los ganadores de los primeros lugares en el concurso lograron esos niveles de calidad.
Por otro lado: se asevera que con TSP se puede obtener densidades de defectos de hasta 0.06 D/KLOC; sin embargo, hemos encontrado empresas en nuestro país que reportan lograr densidades semejantes… lo curioso es que son los mismos programadores los que realizan las pruebas, no un equipo de testers (interno o externo) debidamente entrenado, al que se le pague por detectar defectos (a los desarrolladores no se les entrena para eso, ni se les paga por ello).
Para poder demostrar que con TSP verdaderamente se pueden alcanzar esas densidades de defectos, sería interesante ver resultados de pruebas realizadas por un tercero, no por los mismos desarrolladores de la empresa.
Habrá que esperar además, más precisión de TSP, pues no es lo mismo hablar de esas densidades de defectos para productos de 100 KLOC, que para productos de 1,000 KLOC.
Surge también la duda: ¿cuántas KLOC suelen tener los compiladores comerciales?, ¿con qué densidad de defectos? Si fuera superior a 0.06 D/KLOC, entonces los productos generados por ellos tendrían dificultad para alcanzar ese número.
Referencias
[ León-Carrillo, L.: Columna “Prueba de Software”, Software Gurú, Feb-Abr 2008 ]
[ León-Carrillo, L.: The Impact of Software Testing in small Settings, en Oktaba, H. and Piatini, M. et.al. Software Processes in small Enterprises. IGI Global. 2008 ]
[ The Project Management Institute: A Guide to the Project Management Body of Knowledge. USA, 2000 ]
[ e-quallity.net/definiciones.php ]
[ e-quallity.net ]
Acerca del Autor
Luis Vinicio León Carrillo es actualmente Director General de e-Quallity, empresa especializada en prueba de software. Fue profesorinvestigador en el ITESO durante varios años, que incluyeron una estancia de posgrado en prueba de software en Alemania, en la que abordó aspectos formales de dicha disciplina. Es autor de varias publicaciones nacionales e internacionales, e invitado frecuente en eventos
relacionados con la prueba de software.
- Log in to post comments