Varios

El Diablo no Sólo Está en los Detalles

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 haynada 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 aplicara 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, unefecto 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 losproblemas 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 desoftware, 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, unagran 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 dedefectos 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, peroextrañ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 millí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...