Desarrollo de software. Controlando los fuegos en el sistema de información

Si en un sistema de información hay muchos fuegos que apagar en forma de mantenimientos correctivos y evolutivos (siendo estos por cambios en las especificaciones iniciales del usuario) y recursos muy limitados para hacerles frente, lo mejor es olvidarse de evolucionar el sistema en una línea distinta a donde se encuentran los problemas.

De no hacerse así, no solo no se solucionarán los problemas, sino que el fuego terminará consumiendo los nuevos desarrollos.

Una vez estabilizado el sistema de información (lo cual no quiere decir que se hayan eliminado todos los inconvenientes, ya que estos son como cuando un cristal se rompe, pasan meses y todavía te encuentras fragmentos por el suelo) y teniéndolo bajo control (cosa que es complicada de conseguir cuando llegan más tareas que las que se pueden afrontar, hay mucho ruido de fondo y todas son urgentes), ya se podría empezar a pensar en una evolución del mismo, sin perder de vista que la misma debe ser acorde a los recursos presentes y futuros.

Desarrollo de software. Diferentes enfoques de la calidad del software

La calidad del software puede ser contemplada desde diferentes puntos de vista en el que cada uno de ellos matice un aspecto concreto del producto software.

La crisis del software hacía especial hincapié en las principales carencias que presentaban las aplicaciones: incumplimiento de las expectativas del usuario e incumplimiento de plazos y presupuestos.

Sin embargo cada uno de nosotros tenemos una visión particular de lo que es o debe ser la calidad del software, para algunos consistirá simplemente en que funcione, para otros conseguir la calidad implica muchos más factores.

Desde mi punto de vista la calidad del software pasa por el cumplimiento de las expectivas del usuario pero también por la existencia de un umbral de errores en el producto que se sitúe por debajo de los límites admisibles para el mismo. No debe pasar por los mismos filtros un software que controle los reactores de una central nuclear que el de una aplicación de gestión (o incluso estas frente a otras donde un mal funcionamiento no impacte críticamente en el negocio o en el balance económico de la compañía).

Alistair Cockburn, en el enfoque que le da a las metodologías Crystal tiene en cuenta esa circunstancia. No todas las aplicaciones son iguales, por tanto, el proceso para desarrollarlas no tiene por qué ser el mismo.

Sin embargo, pese a considerar como aspectos más importantes los anteriores, ya que sin su cumplimiento se resta importancia a lo bien que se hayan ejecutado otros, la calidad del software también requiere una deuda técnica admisible, una documentación útil (ni poca, ni mucha, la que sea necesaria y de utilidad) y un consumo de recursos hardware acorde a las características de la aplicación.

Eso es para mi, la calidad del software, ¿qué piensas tú?.