archivo

Archivo de la etiqueta: Victor Basili

La primera de las situaciones que Barry Boehm y Victor Basili citan en su artículo “Software Defect Reduction Top 10 List” en la revista IEEE Computer en enero de 2001, está muy en consonancia con el objetivo Lean de cero defectos y con una realidad que los que nos dedicamos a esta profesión conocemos y que sin embargo sigue siendo demasiado habitual: “Encontrar y arreglar un problema del software después de la entrega es a menuda 100 veces más caro que encontrarlo y arreglarlo durante las fases de toma de requisitos o diseño”.

Encontrar un defecto en producción implica el tiempo necesario en corregirlo, la realización de una nueva entrega y el coste que tiene sobre el proceso productivo hasta que se corrige. No todos los defectos son iguales y, por tanto, su impacto puede ser desde prácticamente nulo hasta dejar sin funcionamiento una parte de la aplicación o provocar daños intangibles como una mala imagen ante los clientes.

Con lo que tenemos que quedarnos es que efectivamente se tiene que ser más riguroso en el proceso de desarrollo de manera que los programadores se habitúen a probar mejor el software que están desarrollando, siendo extensible esto a las personas que tengan una visión más global del producto conforme se van integrando los componentes.

Y esto no solo debe tenerse en cuenta en la construcción ya que se tiene que tratar que las especificaciones sean de la mayor calidad e intención posible, de manera que se consiga reducir el número de iteraciones necesarias para tener depurada una determinada funcionalidad.

“Entre el 40% y el 50% de los programas de usuario contienen defectos no triviales”.

Se trata de errores que tienen un impacto entre moderado y sensible para los usuarios de un determinado sistema o lo que es lo mismo, se trata de defectos en secciones del programa más o menos críticas pero que suponen un bloqueo en el trabajo del usuario o que producen resultados erróneos que son complicados de detectar por los mismos a simple vista, por ejemplo, aquellos que son el resultado de cálculos matemáticos complejos o del cruce de datos de diversas fuentes.

Puestos en una balanza, en muchos casos, estos segundos tipos de errores son más peligrosos y relevantes que los primeros porque se corre el riesgo de entregar resultados o hacer interpretaciones sobre la información que son erróneos al tomarse como base cifras, valores o datos que se consideran ciertos, solo por el hecho de que se confía en que el sistema los ha calculado bien.

No basta solo con revisar fórmulas o métodos de cálculo, también es necesario conocer el negocio para detectar cálculos que no resultan lógicos, ¿cuántas veces le has dado numerosas vueltas a un algoritmo y no has visto errores y un usuario experto nada más ver el resultado del cálculo ha sospechado que había algo mal?, pero también, ¿cuántas veces el usuario tampoco ha detectado la existencia del problema? ya que lo mismo el juego de datos utilizado produce un resultado correcto pero con otro el resultado puede ser incorrecto.

Por ese motivo los sistemas críticos deben tener un testing acorde a sus necesidades, requieren un tratamiento especial y eso se debe tener en cuenta desde el punto de vista presupuestario porque se entiende que en sistemas de estas características hay mucho en juego y se debe ser especialmente riguroso ante el riesgo de que lleguen a producción defectos importantes que como dicen Boehm y Basili no resultan en la mitad de los casos triviales de detectar.

En el artículo de enero de 2001 en la revista IEEE Computer, que Barry Boehm y Victor R. Basili publicaron con el título: “Software Defect Reduction Top 10 List” y que ya mencioné en la entrada: “El impacto del esfuerzo evitable“, hay otra estimación que me pareció muy interesante: “Las prácticas personales disciplinadas pueden reducir la tasa de introducción de defectos en más de un 75%”.

Boehm y Basili en su artículo indican algunos datos empíricos en la aplicación de determinados tipos de metodologías como la PSP de Watts Humphrey, si bien lo importante no es realmente que el término medio sea un 75% o no, sino que todos sabemos en base a nuestra propia experiencia que si se siguen buenas prácticas y una cierta disciplina a la hora no solo de programar sino de probar lo que se desarrolla tanto a nivel de componente, de integración y de sistema el número de errores que se introducen es mucho menor, permitiendo además, detectarlos gran parte de ellos de forma temprana.

Pese a eso, sabemos que existe un mal endémico en los desarrolladores y es que “no se prueba” y eso no es siempre problema de actitud, sino más bien un problema cultural, algo que está ahí, que parece normal y que, sin embargo, provoca un sobrecoste en los proyectos, problemas en el entorno de producción, un desgaste en las relaciones con el usuario, etc…

Alguien resolutivo no es quien te codifica antes un determinado artefacto sino quién es capaz de hacerlo, dentro de un tiempo razonable con el menor número de defectos posible. Es preferible tardar más y hacer un trabajo limpio, que hacerlo en menos tiempo y después estar arreglando problemas mucho más tiempo que el que se entendió que se ganó por hacer el desarrollo tan deprisa.

El cambio de enfoque se puede hacer de manera progresiva, incluyendo esas buenas prácticas y controles de manera paulatina, de manera que las decisiones adoptadas se vayan ajustando a lo que el proyecto necesita. Conforme se vayan consolidando, se considerarán prácticas del trabajo diario, independientemente de que haya proyectos que, por sus condiciones especiales, requieran una mayor exhaustividad.

En enero de 2001 en la revista IEEE Computer, Barry Boehm y Victor R. Basili publicaron un interesante artículo con el título: “Software Defect Reduction Top 10 List”.

En el mismo me llamó mucho la atención el siguiente dato (o estimación) que daban: “Entre el 40 y el 50% del esfuerzo en los proyectos se consume en retrabajo evitable”.

Es cierto que ha llovido mucho desde entonces pero también lo es que muchas malas prácticas siguen totalmente vigentes, entre otras cosas porque aunque el desarrollo de software trata de evolucionar conociendo y tratando los errores del pasado, el mensaje no llega en muchos casos ni en la etapa formativa ni en la laboral, ya que se enfocan las prioridades en otros objetivos.

Según los autores, este esfuerzo adicional es provocado por errores que se podían haber evitado desde el principio o que se deberían haber tratado lo más próximo posible a su origen.

En otra cita del mismo artículo, consideran que “aproximadamente el 80% del trabajo evitable proviene de un 20% de los defectos”. Como podéis ver es una aplicación del principio de Pareto a los defectos y al esfuerzo necesario para corregirlos.

Se trata por tanto, de trabajar con la detección de defectos cuanto antes, sabiendo que es prácticamente imposible detectarlos todos, prestando principal atención a los posibles defectos en áreas críticas del sistema tanto a nivel funcional como a nivel de arquitectura, y tratar de comenzar con su corrección lo antes posible, con el objeto de que su impacto sea el menor posible, no llegando a producción o no realizándose desarrollos sobre ellos que obliguen a rehacer o a retocar una mayor cantidad de código.

Muchos proyectos ven afectados su alcance final y su valor por el hecho de tener que invertir esfuerzo en actividades que perfectamente se podían haber evitado, seguro que personalmente conocéis muchos de ellos en los que llegado el momento habéis echado en falta algo más de presupuesto que os hubiera permitido darle a los mismos un mejor acabado.