Requisitos y la importancia del diseño

Revisando documentación, he encontrado esta imagen que resume la importancia de:

• Los requisitos
• El diseño de la solución
• La coherencia en las comunicaciones hacia el cliente
• La importancia del prototipo
• Las carencias en la documentación, soporte e implementación

Como la considero un clásico que todos los que nos dedicamos al desarrollo de software deberíamos conocer, ahí va para los que no la conozcáis.

Los que decís que lo teníais muy visto...más os valdría recordarlo de vez en cuando (me incluyo), porque cometemos de forma constante errores como estos, y algún día habrá que dejar de echar la culpa a los demás.

Para este tipo de problemas, existen varias soluciones o técnicas que nos pueden servir:

• Prototipado. El cliente puede ver con anticipación, la solución final o partes de la misma. Sin embargo, esto se queda simplemente para formación teórica, ya que en la práctica, los programas de software son mucho más complejos que lo mostrado en la figura. El cliente, hasta que no USE realmente en su día a día el producto, no será capaz de detectar lo buen o mal diseñado que estará.
• Ciclos de vida iterativos en general. Prometen tener soluciones parcialmente construidas, que el cliente puede validar. Tiene los mismos problemas que el prototipado.
• Metodologías ágiles. Normalmente, las metodologías ágiles incluyen entregas frecuentes y un ciclo de vida iterativo que facilita evitar estos problemas. Sin embargo, en absoluto son garantía de evitar los problemas descritos en la imagen. Tiene también problemas

Como vemos, no hay balas de plata. Al final, la mejor herramienta es la experiencia. Conocer el negocio del cliente, y conocer el negocio del desarrollo de software.

Como ejemplo, voy a dar un caso real. Para una empresa, se solicitó una aplicación para rellenar unos formularios tipo. La primera aproximación que se tomó, y que coincidía con lo que pedía literalmente el cliente, fue mostrar en pantalla "el formulario tal cual". Así se hizo, y resultó un fracaso. El trasladar a la pantalla el formulario produjo múltiples problemas, ya que la metáfora usada (el mostrar el formulario tal cual), contradecía las metáforas de usabilidad que había en el resto de aplicaciones, y a las que estaban acostumbrados los usuarios. Además, resultó que cualquier cambio en el formulario físico (el report), obligaba a cambiar la pantalla de inserción de datos.