El arte del desarrollo de software

El rapid prototyping es un método de desarrollo de software que busca aclarar lo antes posible las preguntas abiertas al inicio de un proyecto de software. Se usa para encontrar la base más sólida posible para los desarrollos posteriores al menor costo posible y para descubrir las “incógnitas desconocidas”.

Distintas estrategias de gestión de producto

Al inicio de un proyecto de software, muchos aspectos suelen estar poco claros, sobre todo los relacionados con el software mismo. Las preguntas sobre eficiencia, arquitectura, volumen de datos y las propias estructuras de datos a menudo solo pueden responderse durante la implementación. Esto ya se sabía en los primeros días de la ingeniería de software, como explicó Winston Royce en su presentación del modelo en cascada (Royce, Winston (1970), “Managing the Development of Large Software Systems” (PDF), Proceedings of IEEE WESCON, 26), donde se agregan numerosos ciclos y mecanismos de retroalimentación al flujo ingenuo de un proyecto de desarrollo. Sin embargo, cuanto antes se encuentra (y se corrige) un problema, menos cuesta. Si, por ejemplo, un error fundamental solo se reconoce durante la operación, puede ser necesario un redesarrollo largo y costoso. Muchos métodos modernos de desarrollo, en especial el desarrollo ágil, buscan reconocer y responder los problemas y las preguntas abiertas en una etapa temprana e incorporar al proceso de desarrollo la nueva información obtenida de este modo.

Además, en el transcurso de todo proyecto de software se descubren cuestiones desconocidas, es decir, cuestiones que no eran visibles durante la planeación y que por lo tanto no podían resolverse. Esto puede deberse a propiedades del entorno, a los componentes utilizados, a la arquitectura, a las expectativas de los usuarios o simplemente a las propiedades fundamentales del problema por resolver.

Primero la estructura

Uno de esos métodos es el rapid prototyping. Consiste en determinar el estado de un desarrollo y formular preguntas abiertas: “¿Cómo puede ser la estructura de datos?”, “¿Qué vistas o análisis necesita el usuario?” o “¿Qué datos deben registrarse para crear beneficios adicionales?”. Con estas preguntas se desarrolla luego, en el menor tiempo posible y excluyendo todos los demás aspectos, un prototipo que pueda dar claridad al respecto. Las dos características ya mencionadas en el nombre son centrales: “rapid”, es decir, en el menor tiempo posible; y “prototype”, es decir, no un sistema completo sino solo un patrón de diseño, un modelo de plantilla. Ambos aspectos de este método indican que otros criterios no importan: mantenibilidad, extensibilidad, propiedades operativas, seguridad, capacidad de prueba, documentación, etc. Aquí solo importa responder rápidamente las preguntas formuladas (y descubrir, de paso, preguntas nuevas y desconocidas). El conocimiento y las respuestas obtenidos pueden fluir después hacia un diseño o una implementación, informarlos y asegurar así que una implementación “correcta” evite los errores y problemas encontrados.

Si un prototipo no puede responder las preguntas, por supuesto no vale nada; el desarrollo de un prototipo rápido debe apuntar siempre a la meta de preguntas claramente formuladas y no debe desviarse de ellas ni ir más allá. Es demasiado fácil caer en esta trampa y desarrollar un prototipo que pueda hacerlo todo, pero que al mismo tiempo no responda nada y genere muchos costos. Por desgracia, los equipos sin experiencia a menudo carecen de la disciplina necesaria para desarrollar un prototipo de manera enfocada, eficiente y eficaz.

Ahora bien, con un prototipo así en la mano, producido en muy poco tiempo, resulta tentador preguntar qué falta todavía. Desde el punto de vista de un usuario ya hay una “solución” al problema en forma de software, y a un costo fantásticamente bajo. Pero así como nadie querría volar en el prototipo de un avión, nadie debería usar un prototipo de software como producto terminado. Los aspectos ya mencionados de seguridad, mantenibilidad, capacidad de prueba, documentación, etc. son todos importantes. Esto falta aquí, a propósito, y en consecuencia falta en situaciones de producto. Estas facetas del desarrollo de software son sumamente importantes para un software de alta calidad, pero aquí se omiten específicamente para lograr claridad.

De nuevo: se requiere un equipo con experiencia y disciplina entrenada para usar las lecciones aprendidas de un prototipo, pero no el prototipo mismo.

Así, el método de rapid prototyping fortalece un proyecto de software, conduce a una calidad considerablemente mayor en el producto final y asegura con ello menores costos en general.