Published 15 years ago
(updated 12 years ago)
También Está en los Defectos
En todas las industrias tanto de productos como de servicios los defectos son el principal problema que debemos evitar. No hay nada que moleste a un cliente más que no recibir lo que esperaba debido a la falla de una máquina o un individuo, los defectos son el enemigo número uno. Pero por alguna razón esto no parece aplicar a la industria de sistemas. Tal vez se deba a nuestros orígenes, donde dos jóvenes crean una industria desde la cochera de su casa. Parece ser que en nuestro caso los defectos son ineludibles, un efecto secundario que debe esperarse; desde la liberación de gigantescos sistemas operativos que salen a la venta bajo la premisa de que continuamente se liberaran parches para resolver todos los problemas que surjan, hasta el proyecto de mantenimiento, autorizando que la corrección de un defecto detectado sea manejado como un nuevo requerimiento para facilitar el proceso.En los proyectos de software, la principal preocupación es la entrega a tiempo: gastamos una interminable cantidad de horas estimando el esfuerzo, planeando el proyecto, y dando seguimiento a cada paso. En mi experiencia, una gran cantidad de proyectos barridos no se deben a malas estimaciones sino a la cantidad de cambios en los requerimientos, la experiencia de la gente que lleva a cabo el proyecto, y la cantidad de defectos que se generaran y se tienen que resolver.
El problema de la medición
Puntos funcionales, líneas de código,
números de módulos; existe gran cantidad de formas de estimar un proyecto, pero extrañamente no parece haber tantas formas de definir un defecto. No quiero decir que medir el tamaño no es importante, ya que no es lo mismo tener 3 defectos en cien líneas de código que 3 defectos en mil líneas de código. Medir
tamaño consistentemente es básico para medir densidad de defectos. Pero necesitamos trabajar más en una definición que nos sirva para medir defectos.
Al igual que en la definición de tamaño, no podemos tener una sola métrica para toda la industria, ya que las necesidades son diferentes dependiendo del tipo y características de cada organización. Al crear una definición de defectos para tu organización, son importantes estas dos características:
1. Que sea consistente. Esto quiere decir que si seleccionamos una forma de medir defectos necesitamos poder mantener la definición congruente a través de los diferentes proyectos, con esto comparamos si estamos mejorando o no a través del tiempo.
2. Se requiere una métrica con suficiente granularidad como para darnos información útil. Por ejemplo si contamos un programa defectuoso como un solo defecto sin importar cuantas líneas tengan error y nuestro sistema tiene una pequeña cantidad de programas, no tendremos suficiente información para encontrar y mejorar nuestra salida de defectos.
Características de los defectos
Los defectos tienen diferentes características, pero hay dos especialmente importantes:
1. Crecen en forma exponencial debido a un efecto llamado “la fábrica escondida” (the hidden factory). Este fenómeno indica que si tenemos varios pasos en un proceso y cada paso tiene un porcentaje de defectos, la posibilidad de que el producto final no tenga defectos es igual a la multiplicación de las posibilidades de cada paso. Por ejemplo, si tenemos un proceso con cinco pasos y tenemos un 90% del producto bien en cada paso, al final la posibilidad de terminar sin defectos es de 90%^5 = 59%. Si consideramos la cantidad de pasos que se llevan al desarrollar software, entenderemos lo dificil que es tener un sistema sin defectos.
2. Se ha demostrado que los seres humanos tendemos a repetir errores. Cuando nos equivocamos haciendo algo, el error es parecido a errores anteriores. Nuestro cerebro teje redes que se van formando gracias a la repetición de nuestras actividades, por lo que si te equivocas en la declaración de variables de un programa en forma consistente, aumenta la posibilidad de que en el futuro te equivoques en lo mismo.
Esto nos lleva a dos estrategias que nos ayudan a reducir la cantidad de defectos en nuestros productos:
1. Revisar los productos durante sus diferentes pasos. Está demostrado que no es suficiente probar el sistema hasta el final del proyecto, sino que cada fase: análisis, diseño, programación, etc. debe considerar actividades de prueba. No sólo es importante medir la cantidad y tipo de defectos, sino la eficiencia de las pruebas mismas a través de métricas de grado de escape
(escape rate) que midan el número de defectos, la fase donde se generó el defecto y la fase donde finalmente se detectó.
2. Si acostumbramos repetir errores, entonces el utilizar checklists para hacer las revisiones es la estrategia con mayor retorno de inversión y creo que de los menos utilizados. Algunos checklists internos nos ayudan a recordar en lo que se ha equivocado otras personas, pero deben ser personales.
“Los humanos se equivocan, nadie es perfecto”, Esto es cierto pero no debería ser una excusa para no trabajar lo mejor posible. De alguna manera si queremos crecer y superarnos como industria es sumamente importante que nos hagamos responsables de lo que hacemos y aprendamos de nuestros defectos.
Acerca del Autor
Luis Cuellar es director de calidad a nivel mundial de Softtek Information Services. Luis es reconocido por la American Society for Quality(ASQ) como Certified Quality Manager,Certified Software Engineer, y Six Sigma Black Belt. En los últimos cinco años ha estado a cargo de la definición e implantación de la estrategia para CMMI5 y Six Sigma a través de las diferentes áreas del centro de desarrollo de Softtek
En todas las industrias tanto de productos como de servicios los defectos son el principal problema que debemos evitar. No hay nada que moleste a un cliente más que no recibir lo que esperaba debido a la falla de una máquina o un individuo, los defectos son el enemigo número uno. Pero por alguna razón esto no parece aplicar a la industria de sistemas. Tal vez se deba a nuestros orígenes, donde dos jóvenes crean una industria desde la cochera de su casa. Parece ser que en nuestro caso los defectos son ineludibles, un efecto secundario que debe esperarse; desde la liberación de gigantescos sistemas operativos que salen a la venta bajo la premisa de que continuamente se liberaran parches para resolver todos los problemas que surjan, hasta el proyecto de mantenimiento, autorizando que la corrección de un defecto detectado sea manejado como un nuevo requerimiento para facilitar el proceso.En los proyectos de software, la principal preocupación es la entrega a tiempo: gastamos una interminable cantidad de horas estimando el esfuerzo, planeando el proyecto, y dando seguimiento a cada paso. En mi experiencia, una gran cantidad de proyectos barridos no se deben a malas estimaciones sino a la cantidad de cambios en los requerimientos, la experiencia de la gente que lleva a cabo el proyecto, y la cantidad de defectos que se generaran y se tienen que resolver.
El problema de la medición
Puntos funcionales, líneas de código,
números de módulos; existe gran cantidad de formas de estimar un proyecto, pero extrañamente no parece haber tantas formas de definir un defecto. No quiero decir que medir el tamaño no es importante, ya que no es lo mismo tener 3 defectos en cien líneas de código que 3 defectos en mil líneas de código. Medir
tamaño consistentemente es básico para medir densidad de defectos. Pero necesitamos trabajar más en una definición que nos sirva para medir defectos.
Al igual que en la definición de tamaño, no podemos tener una sola métrica para toda la industria, ya que las necesidades son diferentes dependiendo del tipo y características de cada organización. Al crear una definición de defectos para tu organización, son importantes estas dos características:
1. Que sea consistente. Esto quiere decir que si seleccionamos una forma de medir defectos necesitamos poder mantener la definición congruente a través de los diferentes proyectos, con esto comparamos si estamos mejorando o no a través del tiempo.
2. Se requiere una métrica con suficiente granularidad como para darnos información útil. Por ejemplo si contamos un programa defectuoso como un solo defecto sin importar cuantas líneas tengan error y nuestro sistema tiene una pequeña cantidad de programas, no tendremos suficiente información para encontrar y mejorar nuestra salida de defectos.
Características de los defectos
Los defectos tienen diferentes características, pero hay dos especialmente importantes:
1. Crecen en forma exponencial debido a un efecto llamado “la fábrica escondida” (the hidden factory). Este fenómeno indica que si tenemos varios pasos en un proceso y cada paso tiene un porcentaje de defectos, la posibilidad de que el producto final no tenga defectos es igual a la multiplicación de las posibilidades de cada paso. Por ejemplo, si tenemos un proceso con cinco pasos y tenemos un 90% del producto bien en cada paso, al final la posibilidad de terminar sin defectos es de 90%^5 = 59%. Si consideramos la cantidad de pasos que se llevan al desarrollar software, entenderemos lo dificil que es tener un sistema sin defectos.
2. Se ha demostrado que los seres humanos tendemos a repetir errores. Cuando nos equivocamos haciendo algo, el error es parecido a errores anteriores. Nuestro cerebro teje redes que se van formando gracias a la repetición de nuestras actividades, por lo que si te equivocas en la declaración de variables de un programa en forma consistente, aumenta la posibilidad de que en el futuro te equivoques en lo mismo.
Esto nos lleva a dos estrategias que nos ayudan a reducir la cantidad de defectos en nuestros productos:
1. Revisar los productos durante sus diferentes pasos. Está demostrado que no es suficiente probar el sistema hasta el final del proyecto, sino que cada fase: análisis, diseño, programación, etc. debe considerar actividades de prueba. No sólo es importante medir la cantidad y tipo de defectos, sino la eficiencia de las pruebas mismas a través de métricas de grado de escape
(escape rate) que midan el número de defectos, la fase donde se generó el defecto y la fase donde finalmente se detectó.
2. Si acostumbramos repetir errores, entonces el utilizar checklists para hacer las revisiones es la estrategia con mayor retorno de inversión y creo que de los menos utilizados. Algunos checklists internos nos ayudan a recordar en lo que se ha equivocado otras personas, pero deben ser personales.
“Los humanos se equivocan, nadie es perfecto”, Esto es cierto pero no debería ser una excusa para no trabajar lo mejor posible. De alguna manera si queremos crecer y superarnos como industria es sumamente importante que nos hagamos responsables de lo que hacemos y aprendamos de nuestros defectos.
Acerca del Autor
Luis Cuellar es director de calidad a nivel mundial de Softtek Information Services. Luis es reconocido por la American Society for Quality(ASQ) como Certified Quality Manager,Certified Software Engineer, y Six Sigma Black Belt. En los últimos cinco años ha estado a cargo de la definición e implantación de la estrategia para CMMI5 y Six Sigma a través de las diferentes áreas del centro de desarrollo de Softtek
- Log in to post comments