Prototipos evolutivos versus desechables [cerrado]

Question

¿Quién está ganando en el debate "creación de prototipos de baja o alta fidelidad"?¿Debería ser el prototipo cero (P0) la primera versión del producto final?¿O debería ser P-0 siempre desechable?¿Qué enfoque está favoreciendo la industria?

Excelente artículo de wikipedia: creación de prototipos de software

Answer 1

Un prototipo debe ser siempre una de usar y tirar - un prototipo se utiliza para probar rápidamente un concepto e influir en el diseño del producto real. Como tal, una gran cantidad de cosas que son importantes para un producto real (una arquitectura y un diseño bien pensado, fiabilidad, seguridad, mantenimiento, etc.) quedan en el camino. Si lo hace tomar estas cosas en cuenta al construir su prototipo, usted no está realmente la construcción de un prototipo más.

Mi experiencia con prototipos donde el código evolucionado directamente en un producto real muestra que el resultado final sufre a causa de ella - la falta de una verdadera arquitectura dio lugar a una gran cantidad de código-juntos adoquinada que tuvo que ser cortado constantemente para añadir nuevas características. Incluso he visto un caso de la tecnología original elegido para el rápido desarrollo del prototipo no era la mejor opción para el producto real, y una completa re-escritura era necesario para V2.

Answer 2

Escribir el prototipo, a continuación, mantener refactorización hasta que se convierte en el producto. La clave está en no dude en refactorizar cuando sea necesario.

Es útil tener pocas personas que trabajan en ella inicialmente. Con demasiada gente trabajando en algo, refactorización se vuelve más difícil.

Answer 3

Creo que nosotros, los pedantes, hemos perdido esta batalla particular, - la supuesta "prototipos" (que por definición debería ser reescrito desde cero !!! -) son de hecho ser "evolucionado" en (a menudo "betas" medio-al horno), etc.

Incluso hoy en día, he aplaudido en el intento inteligente por parte de un colega mío de recuperar la concepto , aunque el término es una batalla perdida: él está la creación de una forma de pruebas del concepto pequeños proyectos a desarrollar (y, si el concepto se vuelve a probarse, trasladados a los ingenieros de software para la creación de un prototipo real, entonces el desarrollo).

La idea es que, en nuestro departamento, tenemos muchas personas que no lo son (y no son, de hecho, supone a ser -!) Los desarrolladores de software, pero son muy inteligentes, comprensión de la computadora y en contacto diario con la realidad "en las trincheras" - que son los que tienen más probabilidades de oler una oportunidad para que alguna innovación potencial que podría tener un impacto real una vez implementado como un "producción- "proyecto de software listo. Vendedores, gerentes de cuentas, analistas de negocios, gerentes de tecnología - en nuestra empresa, todos ellos a menudo se ajustan a esta descripción

.

Pero no vamos a programar en C ++, casi nada en Java, tal vez en Python pero lejos de "productionized" - en realidad son mucho más propensos a preparar una prueba de concepto inteligente en php, Javascript, perl, golpe, Excel VBA +, y otras tecnologías "rápido y sucio" diversos que no quiero ni a sueño sobre productionizing y apoyar para siempre! -)

Así llamando a sus prototipos "pruebas de concepto", esperamos animarles a incorporar sus conceptos atrevidos en forma concreta (blabberings de lenguaje natural vaga y mucho agitar de manos que son menos útiles, y ajeno a la cultura de la compañía de todos modos; -) y sin embargo, indican fuertemente que este tipo de proyectos, si se promueven a existir entre los objetivos y las prioridades de los ingenieros de software, tiene que ser programado desde cero - la prueba de concepto-sirve, a lo sumo, como un buen proyecto de especificaciones / boceto por lo que los ingenieros están apuntando a, definitivamente no es para ser enriquecido de forma incremental, pero hecho de nuevo de la raíz hacia arriba -.)

Es pronto para decir qué tan bien funciona esta idea - me pregunta en tres meses, cuando evaluamos los esfuerzos del trimestre (en este momento, sólo estamos proporcionando un modelo para ellos, pisando los talones de evaluar última empresas de cuartos Department- y sabia por la compañía -!)

.

Answer 4

Respuesta de BUNDALLAH, HAMISI

Un prototipo normalmente simula sólo algunos aspectos de las características del programa final y puede ser completamente diferente de la implementación final.Al contrario de lo que mis otros colegas han sugerido anteriormente, NO recomendaría a mi jefe que opte por el modelo prototipo desechable.Estoy con Anita en esto.Dados los dos modelos prototipo y las circunstancias dadas, recomendaría encarecidamente a la dirección (mi jefe) que opte por el modelo prototipo evolutivo.Como la empresa es grande y se tienen en cuenta todas las demás variables, como la complejidad del código y la novedad del lenguaje de programación que se utilizará, no utilizaría un modelo de prototipo desechable.El modelo prototipo desechable se convierte en el punto de partida desde el cual los usuarios pueden reexaminar sus expectativas y aclarar sus requisitos.Cuando esto se ha logrado, el modelo prototipo se "desecha" y el sistema se desarrolla formalmente basándose en los requisitos identificados (Crinnion, 1991).Pero en esta situación, es posible que los usuarios no conozcan todos los requisitos a la vez debido a la complejidad de los factores dados en esta situación particular.La creación de prototipos evolutivos es el proceso de desarrollar un sistema informático mediante un proceso de refinamiento gradual.Cada refinamiento del sistema contiene una especificación del sistema y una fase de desarrollo de software.A diferencia del enfoque tradicional en cascada y de la creación de prototipos incrementales, que requerían que todos hicieran todo bien la primera vez, este enfoque permite a los participantes reflexionar sobre las lecciones aprendidas en los ciclos anteriores.Es habitual pasar por tres de estos ciclos de refinamiento gradual.Sin embargo, no hay nada que detenga un proceso de evolución continua que suele ocurrir en muchos sistemas.Según Davis (1992), un prototipo evolutivo reconoce que no entendemos todos los requisitos (como nos han dicho anteriormente que el sistema es complejo, la empresa es grande, el código será complejo y el lenguaje es bastante nuevo para nosotros). el equipo de programación).El objetivo principal al utilizar prototipos evolutivos es construir un prototipo muy robusto de manera estructurada y perfeccionarlo constantemente.La razón de esto es que el prototipo evolutivo, una vez construido, forma el corazón del nuevo sistema, y ​​las mejoras y requisitos adicionales se construirán.Esta técnica permite al equipo de desarrollo agregar funciones o realizar cambios que no se pudieron concebir durante la fase de requisitos y diseño.Para que un sistema sea útil, debe evolucionar mediante su uso en el entorno operativo previsto.Un producto nunca está "hecho"; Siempre está madurando a medida que cambia el entorno de uso.Los desarrolladores a menudo intentan definir un sistema utilizando su marco de referencia más familiar: dónde se encuentran actualmente (o más bien, el estado actual del sistema).Hacen suposiciones sobre la forma en que se llevarán a cabo los negocios y la base tecnológica sobre la cual se implementará el negocio.Se promulga un plan para desarrollar la capacidad y, tarde o temprano, se entrega algo parecido al sistema previsto.(PEC, 1997).Los prototipos evolutivos tienen la ventaja sobre los prototipos desechables de que son sistemas funcionales.Aunque es posible que no tengan todas las funciones que los usuarios han planeado, se pueden utilizar de forma provisional hasta que se entregue el sistema final.En Evolutionary Prototyping, los desarrolladores pueden concentrarse en desarrollar partes del sistema que entienden en lugar de trabajar en el desarrollo de un sistema completo.Para minimizar el riesgo, el desarrollador no implementa funciones poco conocidas.El sistema parcial se envía a los sitios del cliente.A medida que los usuarios trabajan con el sistema, detectan oportunidades para nuevas funciones y solicitan estas funciones a los desarrolladores.Luego, los desarrolladores toman estas solicitudes de mejora junto con las suyas propias y utilizan prácticas sólidas de gestión de la configuración para cambiar la especificación de los requisitos del software, actualizar el diseño, recodificar y volver a probar.(Bersoff y Davis, 1991).Sin embargo, los principales problemas de la creación de prototipos evolutivos se deben a una mala gestión:Falta de hitos definidos, falta de logros (siempre posponiendo lo que estaría en el prototipo actual hasta el siguiente), falta de evaluación adecuada, falta de claridad entre un prototipo y un sistema implementado, falta de compromiso continuo por parte de los usuarios.Este proceso requiere un mayor grado de compromiso sostenido por parte de los usuarios durante un período de tiempo más largo que el requerido tradicionalmente.Los usuarios deben estar constantemente informados de lo que está pasando y ser plenamente conscientes de las expectativas de los 'prototipos'.

Referencias

Bersoff, E., Davis, A.(1991).Impactos de los modelos de ciclo de vida de la gestión de la configuración de software.Com.ACM.

Crinnion, J. (1991).Desarrollo de sistemas evolutivos, una guía práctica para el uso de prototipos dentro de una metodología de sistemas estructurados.Plenum Press, Nueva York.

Davis, A.(1992).Prototipos operativos:Un nuevo enfoque de desarrollo.Software IEEE.

Consorcio de Productividad de Software (SPC).(1997).Desarrollo rápido evolutivo.Documento SPC SPC-97057-CMC, versión 01.00.04.