¿Por qué necesitamos prototipos desechables?

9

¿Qué es el modelo de prototipos desechables en ingeniería de software y por qué lo necesitamos? ¿Cómo se diferencia del prototipo evolutivo?

Asmat Ali
fuente
55
Hay una vieja broma / directriz que todo el software apesta hasta la versión 3. La primera versión está descubriendo lo que necesita, la segunda está descubriendo cómo hacerlo (bueno).
Telastyn
2
Puede leer más al respecto en un libro llamado "Desarrollo rápido", Steve McConnell. Y tal vez el "Mes del hombre mítico" si le interesa la historia del desarrollo de software.
andrew.fox
2
@ andrew.fox "Build One to Throw Away" es útil para tener en contexto ( wired.com/2010/07/ff_fred_brooks ) - "Cuando escribí The Mythical Man-Month en 1975, aconsejé a los programadores que" lanzaran el primer versión ", luego construya una segunda".
@MichaelT, sí, por lo que recuerdo, está en el apéndice del libro (la última edición).
andrew.fox
1
@Telastyn No creo que sea una broma.
RubberDuck

Respuestas:

21

Prototipos desechables

La creación de prototipos desechables se trata de crear, lo más rápido posible, una parte de la aplicación futura para garantizar que una función sea técnicamente factible o para mostrarla a las partes interesadas o usuarios potenciales con el fin de obtener comentarios de ellos.

Dado que el código fuente de este prototipo no se reutiliza más tarde cuando se desarrolla la aplicación en sí, lo convierte en un prototipo desechable. Saber que es un código desechable ayuda a enfocarse en la característica real, dejando de lado aspectos como la capacidad de mantenimiento del código, el estilo, los patrones de diseño o las pruebas. Esto permite terminar el prototipo muy rápido, sin afectar negativamente la deuda técnica del producto final.

La creación de prototipos desechables es diferente de dibujar . El boceto es más gráfico y está orientado hacia las interfaces de usuario y la experiencia del usuario, y no consiste en escribir código de programación. Los prototipos desechables generalmente se usan cuando el boceto no es suficiente (por ejemplo, cuando necesita mostrar cómo funcionará una función en diferentes teléfonos inteligentes o cuando necesita mostrar el rendimiento y la capacidad de respuesta reales).

Los prototipos desechables pueden presentar un riesgo cuando se trata con partes interesadas sin antecedentes técnicos y en un contexto de plazos ajustados y recursos muy limitados: las partes interesadas pueden tratar de convencerlo de que reutilice en el producto final el código fuente del prototipo. Es natural creer que acortará el tiempo requerido para liberar el producto, pero en realidad, solo retrasará la fecha de envío. Una forma de evitar esto es usar para el prototipo un lenguaje que no se puede usar en producción (por ejemplo, use C # cuando sepa que el producto final estará alojado en servidores Linux con solo Python instalado).

ingrese la descripción de la imagen aquí

Fig. 1: Creación de prototipos y bocetos desechables : los prototipos ayudan a recopilar comentarios tempranos antes de comenzar a desarrollar la característica real.

Prototipos evolutivos

La creación de prototipos evolutivos consiste en construir un prototipo que luego se refina en función de los comentarios regulares de los interesados ​​o usuarios potenciales.

Aquí, la capacidad de mantenimiento del código, el estilo, los patrones de diseño o las pruebas cuentan desde el principio, lo que hace posible que el prototipo se convierta en un producto de nivel empresarial con todas las funciones. Los pasos anteriores del prototipo contienen solo la parte central del producto futuro, y luego, las características se agregan progresivamente.

ingrese la descripción de la imagen aquí

Fig. 2: Creación de prototipos evolutivos : las características se agregan al prototipo para construir el producto final.

La creación de prototipos evolutivos es diferente de la creación de prototipos incrementales . La creación de prototipos incrementales consiste en construir varios prototipos, cada uno de los cuales representa una parte del sistema futuro, y luego combinarlos. La creación de prototipos evolutivos está más cerca de Agile: a menudo, podrá obtener pronto un producto funcional con características limitadas y extenderlo hasta que las partes interesadas tengan dinero. La creación de prototipos incrementales, por otro lado, es más adecuada para grandes proyectos con muchos equipos contribuyentes, cada equipo trabajando en un prototipo separado.

ingrese la descripción de la imagen aquí

Fig. 3: Creación de prototipos incrementales : se combinan varios prototipos para formar el producto final.

La creación de prototipos evolutivos también es diferente de las metodologías ágiles . Agile se trata de iteraciones e hitos frecuentes en los que se puede lanzar un producto completamente funcional a la fabricación. Si tiene un producto que funciona todos los jueves, está haciendo Agile. En la creación de prototipos evolutivos, expande el prototipo, pero nada lo obliga a tener un producto completamente funcional regularmente. Puede pasar dos meses creando el primer prototipo, luego expandirlo con algunas funciones en dos y tres días respectivamente, y luego pasar tres meses en otra función. No puede tener este tipo de patrones irregulares en Agile.

Las metodologías ágiles específicas imponen reglas adicionales. Por ejemplo, si no realiza la programación de pares, no puede afirmar que está haciendo la Programación extrema. Si su equipo no tiene reuniones diarias, no está haciendo Scrum.

Arseni Mourzenko
fuente
Entonces, ¿la principal diferencia entre los prototipos ágiles y evolutivos es que en los prototipos ágiles siguen el ciclo de liberación con una longitud fija?
Giorgio
@Giorgio: como expliqué en mi respuesta, las diferencias son: (1) ciclo de lanzamiento con una longitud fija, (2) iteraciones cortas, (3) producto completamente funcional al final de cada iteración y (4) reglas adicionales para Metodologías ágiles específicas. En mi opinión, no hay una diferencia "principal" entre esos cuatro.
Arseni Mourzenko
Dado que las reglas adicionales se aplican solo a metodologías específicas de Agile, (4) no caracteriza a Agile. Por ejemplo, la programación de pares no caracteriza a Agile. Además, para mí (1) parece implicar (3): si liberas algo, debe ser un producto totalmente funcional, ¿o es posible liberar un prototipo no completamente funcional en la creación de prototipos evolutivos? (2) también es importante: las iteraciones deben ser cortas, mientras que supongo que en la creación de prototipos evolutivos hay libertad para elegir iteraciones largas o cortas. Entonces, me parece que (1) y (2) caracterizan a Agile (había olvidado (2) en mi comentario anterior).
Giorgio
Pero tal vez estoy equivocado porque he interpretado (3) y (4) de manera incorrecta.
Giorgio
@Giorgio: "si liberas algo, debe ser un producto totalmente funcional" No necesariamente. Cuando lanza un prototipo, no es un producto totalmente funcional, ya que algunas características realmente disponibles para los usuarios finales pueden estar completamente rotas. En cuanto a (4), estoy de acuerdo con usted, no caracteriza a Agile.
Arseni Mourzenko
4

La creación de prototipos se usa por muchas razones. Tal vez desee evaluar la experiencia del usuario con una nueva aplicación para estimar si vale la pena construirla, sin incurrir en el gasto de construirla realmente . Quizás necesite algo que se comunique con un programa existente en la red para realizar pruebas de integración o carga en su red, antes de que haya tenido tiempo de finalizar el software real que se ejecuta en su nodo. Tal vez necesite mostrarle a sus inversionistas algo que se parezca casi a un programa terminado para que estén más dispuestos a aportar la inversión necesaria para realmenteterminar el programa (Esto no tiene nada que ver con el engaño. Los usuarios y gerentes juzgan el software únicamente por su interfaz, por lo que es importante presentarles una buena interfaz para que crean que el proyecto está tan avanzado como realmente está).

Un prototipo desechable es simplemente uno que no se transformará gradualmente en la solución real, sino que será reemplazado por uno nuevo. Obviamente, hay un desperdicio involucrado en tirar el código que ya hace al menos algo de lo que desea, pero la mejor integridad arquitectónica del código adecuado puede compensar fácilmente esa desventaja.

Kilian Foth
fuente