Un documento clásico de IBM muestra cómo redujeron sistemáticamente los defectos analizando la causa raíz. El coste de aplicar esta práctica es menor que el coste de corregir los defectos que tendrá si no la aplica, por lo que siempre debería aplicarse.
1. En primer lugar, comprenda su arquitectura y de dónde proceden los fallos por tipo, gravedad, componente y punto de inyección durante el ciclo de vida de desarrollo.
2. Descubrirá que 80% de los fallos proceden de 20% del código. El mapeo de estos defectos en una arquitectura de componentes mostrará enjambres de errores en torno a componentes específicos.
3. Aplique un pulverizador de errores mediante una estrategia de pruebas automatizadas cuidadosamente priorizada. Encuentre el mayor problema que se produce al realizar las pruebas de regresión finales antes del despliegue. Implemente una prueba automatizada que haga imposible que este problema vuelva a ocurrir utilizando el conocimiento detallado desarrollado sobre la infestación de bugs en su producto. Escriba una sola prueba que pueda prevenir 100 problemas comunes. A continuación, pase al siguiente problema de mayor prioridad y repita la operación. Hacer unas cuantas pruebas automatizadas a la semana hará que su construcción sea a prueba de balas con muy pocas pruebas.
En tres meses, una de nuestras empresas de riesgo redujo un ciclo de despliegue de 4-6 semanas a 2 semanas con sólo 120 pruebas. Una persona tardó tres semanas en escribir la prueba y se eliminaron varias semanas de trabajo de todo un equipo. Se redujeron las derrotas, disminuyeron radicalmente las llamadas al servicio de asistencia y a los clientes les gustó la nueva versión lo suficiente como para comprar más producto, lo que aumentó los ingresos.
Todo el mundo debería ponerlo en práctica. El retorno de la inversión es astronómico. Pensaba que era algo básico, pero nuestros inversores dicen que casi ninguna de sus empresas lo había implantado hasta que invertimos en ellas. Los desarrolladores suelen ser junior, recién salidos de la universidad, y los directivos son expertos en la materia, no en ingeniería. Tenemos que enseñarles lo básico.
por R. G. Mays, C. L. Jones, G. J. Holloway, D. P. Studinski
IBM SISTEMAS REVISTA. VOL 29, NO 1, 1990
La prevención de defectos es el proceso de mejora de la calidad y la productividad evitando la inyección de defectos en un producto. Consta de cuatro elementos integrados en el proceso de desarrollo(: 1) análisis causal reuniones para identificar la causa raíz de los defectos y suggestar acciones preventivas; (2) un equipo de acción para aplicar las acciones preventivas; (3) reuniones iniciales para aumentar la concienciación sobre cuestiones de calidad específicas a cada fase de desarrollo; y (4) recogida y seguimiento de datos de los datos asociados. El proceso de prevención de defectos se ha aplicado con éxito en diversos oganizaciones en IBM, algunos desde hace más de seis años. En este documento se analizan los pasos necesarios a implementar este proceso y los resultados que puedan sea obtenido. Datos sobre calidad, costes del proceso, beneficios y prácticas experiencias. Las ideas sobre la naturaleza de errores de programación y la aplicación a diversos entornos de trabajo.
Spanish 
English 
French