De forma recurrente me sorprendo por el (aparentemente) poco interés en aplicar técnicas “ancestrales” al desarrollo del software que en otras áreas han dado tan buenos resultados. La estadística y el cálculo de probabilidades (desde el genial conde de Buffon) se aplica con enorme éxito en sistemas complejos de analizar de forma determinista. Desde hace bastante tiempo me pregunto por qué no veo cosas como “Si la P d q cualquier código tuyo tenga bugs es dl 50% y la d q tu test los descubra es dl 50%, tu código es buggy en ~38% pues P≈B(1-D+DB)” 🐦 .

En el desarrollo de software sin duda hay muchas opiniones, pero no muchas técnicas contrastadas con una sólida base teórica que ayuden (sobre todo a grandes equipos de desarrollo) a medir y dirigir los recursos hacia los “puntos calientes” de la aplicación. Ya no digamos para técnicas más sofisticadas como “¿Te imaginas un lenguaje que te pidiera anotaciones (ej. de tipo) basándose en la probabilidad de bug (rojo) o de optimización (naranja)?” 🐦 .

Como son pocos y éste me ha gustado, me apetecía tenerlo traducido.

Título original: “Gauging Software Readiness With Defect Tracking” (Vol. 14, No. 3, May/June 1997)

En el competitivo mercado de software comercial, las empresas de software se sienten obligadas a lanzar software en el momento en que está listo. Su tarea es traicionera, pisando la línea divisoria entre liberar software de mala calidad temprano y software de alta calidad tarde. Una buena respuesta a la pregunta “¿Es el software lo suficientemente bueno para lanzarlo ahora?” puede ser crítico para la supervivencia de una empresa. La respuesta a veces se basa en el instinto visceral, pero varias técnicas pueden poner este juicio sobre una base más firme.

Densidad de bugs

Una de las maneras más fáciles de juzgar si un programa está listo para ser liberado es medir su densidad de bugs - el número de bugs por línea de código. Suponga que la primera versión de su producto, GigaTron 1.0, consistiera en 100.000 líneas de código, que usted detectó 650 bugs antes de la publicación del software, y que se reportaron 50 bugs más después de la publicación del software. Por lo tanto, el software tenía un número total de 700 bugs, y una densidad de bugs de 7 bugs por cada mil líneas de código (KLOC).

Supongamos que GigaTron 2.0 consistió en 50.000 líneas de código adicionales, que usted detectó 400 bugs antes de la liberación, y otros 75 después de la liberación. La densidad total de bugs de esa liberación sería de 475 bugs totales divididos entre 50.000 nuevas líneas de código, o 9.5 bugs por KLOC.

Ahora suponga que está tratando de decidir si GigaTron 3.0 es lo suficientemente confiable como para entregarlo. Consta de 100.000 nuevas líneas de código, y ha detectado 600 bugs hasta ahora, o 6 bugs por KLOC. A menos que tenga una buena razón para pensar que su proceso de desarrollo ha mejorado con este proyecto, su experiencia le llevará a esperar entre 7 y 10 bugs por KLOC. El número de bugs que usted debe intentar encontrar variará dependiendo del nivel de calidad que está buscando. Si desea eliminar el 95 por ciento de todos los bugs antes de la liberación, deberá detectar entre 650 y 950 bugs antes del lanzamiento. Esta técnica sugiere que el producto no está listo para su envío.

Cuantos más datos de proyecto históricos tenga, más confianza tendrá en sus objetivos de densidad de bugs previos a la liberación. Si usted tiene datos de sólo dos proyectos y el rango es tan amplio como 7 a 10 bugs por KLOC, eso deja mucho espacio para un juicio experto sobre si el tercer proyecto será más parecido al primero o segundo. Pero si usted ha rastreado los datos de bugs para 10 proyectos y ha encontrado que su tasa promedio de bugs de por vida es de 7.4 bugs por KLOC con una desviación estándar de 0.4 bugs, usted puede tener confianza en esos datos.

Agrupación de bugs

Otra técnica sencilla de predicción de bugs consiste en separar los informes de bugs en dos grupos. Llámelos grupo A y grupo B. A continuación, realice un seguimiento de los bugs en estos dos grupos por separado. La distinción entre los dos grupos es arbitraria. Podría poner todos los bugs descubiertos los lunes, miércoles y fines de semana en el grupo A, y el resto de los bugs en el grupo B. O podrías dividir a su equipo de pruebas por el medio y poner la mitad de sus bugs reportados en un grupo, la mitad en el otro. No importa realmente cómo se haga la división, siempre y cuando ambos grupos de informes operen independientemente y ambos prueben el alcance completo del producto.

Una vez que se crea una distinción entre los dos grupos, se realiza un seguimiento del número de bugs notificados en el grupo A, el número en el grupo B y (aquí está la parte importante) el número de bugs que se notifican tanto en el grupo A como en el grupo B. El número de bugs únicos notificados en un momento dado es:

bugsÚnicos = bugsA + bugsB - bugsAyB

El número de bugs totales puede entonces ser aproximado por la fórmula:

bugs Total = (bugsA * bugsB) / bugsAyB

Si el proyecto GigaTron 3.0 tiene 400 bugs en el grupo A, 350 bugs en el grupo B y 150 de los bugs en ambos grupos, el número de bugs únicos detectados sería de 400 + 350 - 150 = 600. Si el proyecto GigaTron 3.0 tiene 400 bugs en el grupo A, 350 bugs en el grupo B y 150 de los bugs en ambos grupos, el número de bugs únicos detectados sería de 400 + 350 - 150 = 600. El número aproximado de bugs totales sería 400 * 350 / 150 = 933. Esta técnica sugiere que quedan por detectar aproximadamente 333 bugs (aproximadamente un tercio de los bugs totales estimados); el aseguramiento de la calidad en este proyecto todavía tiene un largo camino por recorrer.

Sembrado de bugs

La siembra de bugs es una práctica en la que un grupo inserta intencionadamente bugs en un programa para su detección por otro grupo. La relación entre el número de bugs detectados y el número total de bugs sembrados proporciona una idea aproximada del número total de bugs no sembrados que se han detectado.

Suponga que en GigaTron 3.0 ha introducido intencionalmente el programa con 50 errores. Para obtener el mejor efecto, los errores sembrados deben cubrir la totalidad de la funcionalidad del producto y toda la gama de severidades, desde errores de colisión hasta errores cosméticos.

Suponga que en un punto del proyecto, cuando usted crea que las pruebas están casi completas, mira el informe del bug sembrado. Usted encuentra que se han reportado 31 bugs sembrados y 600 bugs “reales”. Se puede estimar el número total de bugs con la fórmula:

realesTotales = (sembradosTotales / sembradosEncontrados) * realesEncontrados

Esta técnica sugiere que GigaTron 3.0 tiene aproximadamente 50 / 31 * 600 = 967 bugs totales.

Para utilizar la siembra de bugs, debe sembrar los bugs antes del comienzo de las pruebas cuya eficacia desea determinar. Si su prueba utiliza métodos manuales y no tiene una manera sistemática de cubrir el mismo campo de pruebas dos veces, usted debe sembrar bugs antes de que comience la prueba. Si su prueba utiliza pruebas de regresión completamente automatizadas, usted puede sembrar bugs virtualmente en cualquier momento para determinar la efectividad de las pruebas automatizadas.

Un problema común con los programas de sembrado de bugs es el olvido de eliminar los bugs sembrados. Otro problema común es que la eliminación de los bugs sembrados introduce nuevos errores. Para prevenir estos problemas, asegúrese de eliminar todos los bugs sembrados antes de las pruebas finales del sistema y la liberación del producto. Un estándar de implementación útil para los errores sembrados es exigir que sólo se implementen añadiendo una o dos líneas de código que crean el error; este estándar garantiza que puede eliminar los errores sembrados de forma segura simplemente eliminando las líneas de código erróneas.

Modelado de bugs

Un colega mío recientemente agregó varios cientos de líneas de código a un programa existente en una sola sesión. La primera vez que compiló el código, obtuvo una compilación limpia sin errores. Su codificación inicial parecía ser perfecta. Sin embargo, cuando intentó probar la nueva funcionalidad, descubrió que no existía. Cuando reexaminó su nuevo código, descubrió que su trabajo había sido incrustado entre un preprocesador de macros que desactivaba el nuevo código. Cuando movió el nuevo código fuera del alcance de la macro, produjo el número habitual de errores del compilador.

Con los bugs de software, ninguna noticia suele ser mala noticia. Si el proyecto ha llegado a una etapa tardía con pocos bugs reportados, hay una tendencia natural a pensar: “Finalmente lo hicimos bien y creamos un programa con casi ningún bug” En realidad, ninguna noticia es más a menudo el resultado de pruebas insuficientes que de prácticas superlativas de desarrollo.

Algunas de las herramientas más sofisticadas de estimación y control de proyectos de software contienen una funcionalidad de modelado de bugs que puede predecir el número de bugs que se espera encontrar en cada punto del proyecto. Comparando los bugs realmente detectados con el número pronosticado, usted puede evaluar si su proyecto se mantiene al día con la detección de bugs o si se queda rezagado.

Combinaciones

Evaluar las combinaciones de densidad de bugs, grupos de bugs y siembra de bugs le dará más confianza de la que podría tener en cualquiera de las técnicas individualmente. Examinando la densidad del bug solo en GigaTron 3.0 sugirió que usted debe esperar 700 a 1000 bugs totales, y que usted debe quitar 650 a 950 antes de la liberación del producto para alcanzar el 95 por ciento de eliminación del bug antes de la liberación. Si usted ha detectado 600 bugs, la información de densidad de bugs por sí sola podría llevarle a declarar el producto “casi listo para enviar”, pero el análisis de agrupación de bugs calcula que GigaTron 3.0 producirá aproximadamente 933 bugs totales. Comparando los resultados de esas dos técnicas sugiere que usted debe esperar un conteo total de bugs hacia el extremo superior del rango de densidad de bugs en lugar del extremo inferior. Debido a que la técnica de siembra de bugs también estima un número total de bugs en los 900s, GigaTron 3.0 parece ser un programa relativamente defectuoso.

Recursos

La literatura popular no tiene mucho que decir sobre la predicción de bugs. Una excepción notable es el libro de Glenford Myers de 1976, Software Reliability (Wiley). Lawrence H. Putnam y Ware Myers discuten el tema específico del modelado de bugs con cierta profundidad en Measures for Excellence (Yourdon Press 1992).

Referencias