archivo

Archivo de la etiqueta: prototipos

Esta estrategia de desarrollo de software se basa en la construcción de un prototipo preliminar que se utilizará como apoyo para la toma de requisitos del sistema.

Para que el proyecto se mantenga dentro de los parámetros económicos y plazos establecidos, la construcción del prototipo tiene que ser rápida y en el caso de sistemas de información de gran tamaño, se debe de centrar en aquellos aspectos donde resulta más complicado obtener los requerimientos por parte del usuario y en aquellas funcionalidades que sean más críticas.

El prototipo puede ser modificado si con eso se ayuda a seguir perfilando los requisitos.

Una vez catalogados los requisitos y se tenga clara la operativa de funcionamiento de la aplicación, se iniciaría el desarrollo del sistema de información desde su fase de análisis, desechando el prototipo que quedará simplemente a modo de recordatorio, por si hay algunos aspectos que considera de interés recordar.

Este tipo de ciclo de vida tiene como principal ventaja que es más sencillo obtener las especificaciones de los usuarios si ven algo en funcionamiento (aunque no tenga todas las funcionalidades implementadas, se hayan descuidado algunos aspectos del diseño o tengan algunos errores).

También presenta varios inconvenientes:

– Se puede caer en la tentación de realizar la construcción del sistema utilizando el prototipo, realizando evoluciones sobre el mismo. Hay que tener en cuenta que si el prototipo se ha desarrollado de forma rápida, muy probablemente se hayan descuidado bastantes aspectos relacionados con la calidad del software, esto implica que el producto final heredará muy probablemente muchos de esos defectos.

– Puede crear falsas expectativas al cliente u usuario del sistema, ya que en un tiempo razonablemente corto, ven un sistema funcionando (aunque sea parcialmente y con errores) y una vez terminado el propósito de los prototipos, tardan bastante tiempo en ver una primera versión utilizable del producto.

– Si el prototipo es modificado varias veces, se incrementará el riesgo de caer en el primer inconveniente descrito o de salirse de la estimación de tiempo y esfuerzo prevista inicialmente.

Antoni Gaudí utilizaba los planos, sus modelos en yeso y otro tipo de abstracciones de lo que posteriormente serían sus obras como un instrumento de trabajo, posteriormente estaba a pie de obra y se encargaba personalmente de solicitar modificaciones sobre el proyecto base.

No hace mucho escuché una entrevista a Achero Mañas donde comentaba la necesidad de adaptar los guiones en el propio proceso de rodaje de la película porque lo que parecía funcionar en papel, no conseguía transmitir lo que él quería cuando se llevaba a cámara.

En el desarrollo de software lo especificado en el análisis podría perfectamente adaptarse a lo que he comentado en los dos párrafos anteriores, es decir, por mucha capacidad de abstracción que se tenga, posteriormente (puede que en el diseño, en la construcción o en el mantenimiento) será necesario realizar modificaciones sobre la propuesta base, ya que la falta de flexibilidad en estos casos, puede ir a favor de la agilidad y la rentabilidad en el proceso de desarrollo pero en contra del éxito en la implantación del sistema de información.

¿Hasta dónde se puede ser flexible? Salvo que el proyecto cuente con un presupuesto muy por encima del necesario para desarrollar el producto y además se cuente con unos plazos de entrega holgados es necesario establecer ciertos límites, no obstante, pienso que muchos problemas se podrían solucionar mediante la aplicación de una metodología adecuada, es decir, seguirá siendo necesaria la flexibilidad pero el objetivo será reducir el número de casos en proceso de desarrollo.

Cada vez soy más partidario de realizar el análisis utilizando como base prototipos, ya que los usuarios nos tienen que especificar lo que quieren y a través de los prototipos les resulta mucho más sencillo. También soy cada vez más proclive a que el proceso de desarrollo (más concretamente el diseño y construcción) sea iterativo, es decir, vamos liberando y pasando a explotación módulos de la aplicación (aunque partiendo de un análisis global realizado a partir del trabajo con el prototipo), tal vez las primeras versiones todavía no tengan funcionalidad suficiente para que el sistema entre efectivamente en producción, pero hará más sencillo la localización de errores, simplificará los posteriores pasos a explotación del resto de módulos y también permitirá que el usuario pueda empezar a familiarizarse con el sistema y a poder solicitar cambios (ahí es donde entra en funcionamiento la flexibilidad) que modificarán el análisis y en consecuencia futuras iteraciones.