La semana pasada hablamos de que mientras más computadoras se ofrecen en el mundo, más frecuentes se hacen las fallas en el software que les da vida. Y tras leer la columna, de inmediato me puse a pensar en cómo se podría arreglar este tema. De hecho, cabe preguntarse si hay forma de hacerlo…
Por eso, me lanzo en la iniciativa, riesgosa por cierto, de hacer un check list que permita ver qué hay que mirar y cuidar, para evitar que nuevamente los software vuelvan a fallar.
Gracias a que he participado en el desarrollo de programas, desde papeles secundarios, por cierto, sé cómo se desarrollan algunos de estos proyectos. Grosso modo, se inicia con un interesado (persona o empresa) en un sistema que le ayude a enfrentar o resolver un problema determinado, con la ayuda de los computadores.
Este le da a conocer a un analista lo que desea, quien hace un diseño que tras varias discusiones y rectificaciones, es aprobado y entregado a un programador. Este, finalmente, es quien va traduciendo esas necesidades en el lenguaje de programación, mediante el cual va generando programas que pasan diferentes pruebas y se muestran al cliente. Tras los cambios y mejoras que se vayan solicitando, el programador deben ir mejorando su producto hasta llegar al programa final que entra en operaciones… y falla cuando menos se espera.
De hecho, hay que recordar que en torno a la computación es donde se hicieron más conocidas las leyes de Murphy. Una de ellas, aunque tiene un fin humorístico, normalmente se enseña como un axioma en clases de programación: cualquier proyecto de software se demorará tres veces el tiempo máximo calculado y costará el doble de lo presupuestado.
Para evitar que este axioma se haga realidad, se ha trabajado mucho diseñando nuevas formas de enfrentar el desarrollo de programas, pero como se puede ver habitualmente en las noticias, lo normal es que las fallas ocurran y que las empresas de desarrollo deban correr con el parche correspondiente, para hacerle frente.
Entre las cosas que se han aprendido, es que donde más tiempo se debe gastar, es en el lado del cliente. Mientras más claramente se haya especificado sus necesidades, menor necesidad habrá de modificar lo que ya se esté programando.
La segunda etapa en que se debe invertir tiempo, es en la forma en que se plasmará en la pantalla lo que se desea programar. Y esto significa que hay que ver en la práctica, cómo un usuario promedio –ni tan experto, ni tan novato- utiliza el programa que se está desarrollando… si toma más minutos que lo esperado, hay que comenzar de nuevo. Porque si el software funciona, pero retrasa la operación, su aparente ventaja no sirve de nada.
Y, finalmente, hay que probar lo que ya se ha programado. Idealmente, hay que hacerlo a través de personas que ni siquiera conozcan a quien está programando, para que no se influencien por el gasto extra de energías que deberá hacer para reparar lo que se encuentre que no está caminando como se debe.
Como se ve, la posibilidad de que haya fallas en el desarrollo de software (y por lo tanto, culpables), son bastante amplias, ya que el listado de personas que participan en su generación es igualmente amplio. De allí que la necesidad de hacer más profesional el trabajo de desarrollo es crucial, para avanzar desde un estado de artesanía mecanizada que hemos vivido hasta ahora, a uno de eficiencia que permita confiar en lo que hay dentro del computador.