El Modelo de prototipos, prototipos, en Ingeniería de software, software , pertenece a los modelos de desarrollo evolutivo. El prototipo debe ser construido en poco tiempo, usando los programas adecuados y no se debe utilizar u tilizar muchos recursos. El diseño rápido se centra en una representación de auellos aspectos del software ue serán visibles para el cliente o el usuario final. Este diseño conduce a la construcción de un prototipo, el cual es evaluado por el cliente para una retroalimentación! gracias a "sta se refinan los reuisitos del software ue se desarrollará. #a interacción ocurre cuando el prototipo se a$usta para satisfacer las necesidades del cliente. Esto permite ue al mismo tiempo el desarrollador entienda me$or lo ue se debe hacer y el cliente vea resultados a corto plazo. El modelo de prototipos permite ue todo el sistema, o algunos de sus partes, se construyan rápidamente para comprender con facilidad y aclarar ciertos aspectos en los ue se aseguren ue el desarrollador, el usuario, el cliente est"n de acuerdo en lo ue se necesita así como tambi"n la solución ue se propone para dicha necesidad y de esta forma minimizar el riesgo y la incertidumbre en el desarrollo, este modelo se encarga del desarrollo de diseños para ue estos sean analizados y prescindir de ellos a medida ue se adhieran nuevas especificaciones, es ideal para medir el alcance del producto, pero no se asegura su uso real. Este modelo principalmente se lo aplica cuando un cliente define un con$unto de ob$etivos generales para el software a d esarrollarse sin delimitar detalladamente los reuisitos de entrada procesamiento y salida, es decir cuando el responsable no está seguro de la eficacia de un algoritmo, de la adaptabilidad del sistema o de la forma en ue interact%a el hombre y la máuina. Este modelo se encarga principalmente de ayudar al ingeniero de sistemas y al cliente a entender de me$or manera cuál será el resultado de la construcción cuando los reuisitos est"n satisfechos. El paradigma de construcción de prototipos tiene tres pasos:
Escuchar al cliente. Recolección de requisitos. Se encuentran y definen los objetivos globales, se identifican los requisitos conocidos y las reas donde es obligatorio ms definición.
!onstruir y revisar la maqueta "prototipo#. El cliente prueba la maqueta "prototipo# y lo utili$a para refinar los requisitos del soft%are.
Este modelo es &til cuando:
El cliente no identifica los requisitos detallados.
El responsable del desarrollo no est seguro de la eficiencia de un algoritmo, sistema operativo o de la interface hombre'mquina.
Etapas para la elaboración del Modelo de (rototipo.
Etapas •
&lan rápido.
•
'odelado, diseño rápido
•
(onstrucción del &rototipo
•
)esarrollo, entrega y retroalimentación
•
(omunicación
•
Entrega del desarrollo final
Ventajas Este modelo es %til cuando el cliente conoce los ob$etivos generales para el software,
•
pero no identifica los reuisitos detallados de entrada, procesamiento o salida. *ambi"n ofrece un me$or enfoue cuando el responsable del desarrollo del software
•
está inseguro de la eficacia de un algoritmo, de la adaptabilidad de un sistema operativo o de la forma ue debería tomar la interacción humano+máuina e puede reutilizar el código
•
•
Este modelo es %til cuando el cliente conoce los ob$etivos generales para el software, pero no identifica los reuisitos detallados de entrada, procesamiento o salida. *ambi"n ofrece un me$or enfoue cuando el responsable del desarrollo del software está inseguro de la eficacia de un algoritmo, de la adaptabilidad de un sistema operativo o de la forma ue debería tomar la interacción humano+máuina.
#a construcción de prototipos se puede utilizar como un modelo del proceso independiente, se emplea más com%nmente como una t"cnica susceptible de implementarse dentro del conte-to de cualuiera de los modelos del proceso e-puestos. in importar la forma en ue "ste se apliue, el paradigma de construcción de prototipos ayuda al desarrollador de software y al cliente a entender de me$or manera cuál será el resultado de la construcción cuando los reuisitos est"n satisfechos. )e esta manera, este ciclo de vida en particular, involucra al cliente más profundamente para aduirir el producto.
Inconvenientes •
El usuario tiende a crearse unas e-pectativas cuando ve el prototipo de cara a l sistema final. causa de la intención de crear un prototipo de forma rápida, se suelen desatender aspectos importantes, tales como la calidad y el mantenimiento a largo plazo,
lo ue obliga en la mayor parte de los casos a reconstruirlo una vez ue el prototipo ha cumplido su función. Es frecuente ue el usuario se muestre reacio a ello y pida ue sobre ese prototipo se construya el sistema final, lo ue lo convertiría en un prototipo evolutivo, pero partiendo de un estado poco recomendado. En aras de desarrollar rápidamente el pr ototipo, el desarrollador suele tomar algunas
•
decisiones de implementación poco convenientes /por e$emplo, elegir un lengua$e de programación incorrecto porue proporcione un desarrollo más rápido0. (on el paso del tiempo, el desarrollador puede olvidarse de la razón ue le llevó a tomar tales decisiones, con lo ue se corre el riesgo de ue dichas elecciones pasen a formar parte del sistema final... •
u principal desventa$a es ue una vez ue el cliente ha dado su aprobación final al prototipo y cree ue está a punto de recibir el proyecto final, se encuentra con ue es necesario reescribir buena parte del prototipo para hacerlo funcional, porue lo más seguro es ue el desarrollador haya hecho compromisos de implementación para hacer ue el prototipo funcione rápidamente. Es posible ue el prototipo sea muy lento, muy grande, no muy amigable en su uso, o incluso, ue est" escrito en un lengua$e de programación inadecuado.
•
El cliente ve funcionando lo ue para "l es la primera versión del prototipo ue ha sido construido con 1plastilina y alambres1, y puede desilusionarse al decirle ue el sistema a%n no ha sido construido. El desarrollador puede ampliar el prototipo para construir el sistema final sin tener en cuenta los compromisos de calidad y de mantenimiento ue tiene con el cliente.
Conclusiones pesar de ue tal vez sur$an problemas, la construcción de prototipos puede ser un paradigma efectivo para la ingeniería del software. #a clave es definir las reglas del $uego desde el principio! es decir, el cliente y el desarrollador se deben poner de acuerdo en2 •
3ue el prototipo se construya y sirva como un mecanismo para la definición de requisitos.
•
3ue el prototipo se descarte, al menos en parte.
•
3ue despu"s se desarrolle el software real con un enfoue hacia la calidad.
Ciclo de Vida de un Sistema basado en Prototipo.
Una maqueta o prototipo de pantallas muestra la interfaz de la aplicación, su cara externa, pero dicha interfaz está a, estática, no procesa datos. !l prototipo no tiene desarrollada una ló"ica interna, sólo muestra las pantallas por las que irá pasando la futura aplicación. Por su parte, el prototipo funcional e#oluti#o desarrolla un comportamiento que satisface los requisitos $ necesidades que se han entendido claramente. %ealiza, por tanto, un un proceso real de datos, para contrastarlo con el usuario. Se #a modicando $ desarrollando sobre la marcha, se"&n las apreciaciones del cliente. !sto ralentiza el proceso de desarrollo $ disminu$e la abilidad, puesto que el soft'are está constantemente #ariando, pero, a la lar"a, "enera un producto más se"uro, en cuanto a la satisfacción de las necesidades del cliente. Cuando un prototipo se desarrolla con el sólo propósito de precisar meor las necesidades del cliente $ despu(s no se #a a apro#echar ni total ni parcialmente en la implementación del sistema nal se habla de un prototipo desechable. Para que la construcción de prototipos sea posible se debe contar con la participación acti#a del cliente.
El desarrollo orientado a prototipos i bien algunos autores consideran ue esto es parte del ciclo de vida clásico /4oehm, 56770, es tambi"n posible verlo como un m"todo independiente. 8na definición de un prototipo en software podría ser2 "...es un modelo del comportamiento del sistema que pu ede ser usado para entenderlo completamente o ciertos aspectos de él y así clarificar los requerimientos... Un prototipo es una representación de un sistema, aunque no es un sistema completo, posee las características del sistema final o parte de ellas" #as fases ue comprende el m"todo de desarrollo orientado a prototipos serían2 Investigación preliminar . #as metas principales de esta fase son2 determinar el problema y su ámbito, la importancia y sus efectos potenciales sobre la organización por una parte y, por otro lado, identificar una idea general de la solución para realizar un estudio de factibilidad ue determine la factibilidad de una solución software. Definición de los requerimientos del sistema. El ob$etivo de esta etapa es registrar todos los reuerimientos y deseos ue los usuarios tienen en relación al proyecto ba$o desarrollo. Esta etapa es la más importante de todo el ciclo de vida, es auí donde el desarrollador determina los reuisitos mediante la construcción, demostración y retroalimentaciones del prototipo. &or lo mismo esta etapa será revisada con más detalle luego de esta descripción. Diseño técnico. )urante la construcción del prototipo, el desarrollador ha obviado el diseño detallado. El sistema debe ser entonces rediseñado y documentado seg%n los estándares de la organización y para ayudar a las mantenciones futuras. Esta fase de diseño t"cnico tiene dos etapas2 por un lado, la producción de una documentación de diseño ue especifica y describe la estructura del software, el control de flu$o, las interfaces de usuario y las funciones y, como segunda etapa, la producción de todo lo reuerido para promover cualuier mantención futura del software. 9 Programación y prueba. Es donde los cambios identificados en el diseño t"cnico son implementados y probados para asegurar la corrección y completitud de los mismos con respecto a los reuerimientos. Operación y mantención. #a instalación del sistema en ambiente de e-plotación, en este caso, resulta de menor comple$idad, ya ue se supone ue los usuarios han traba$ado con el sistema al hacer las pruebas de prototipos. demás, la mantención tambi"n debería ser una fase menos importante, ya ue se supone ue el refinamiento del prototipo permitiría una me$or claridad en los reuerimientos, por lo cual las mantenciones perfectivas se reducirían. i eventualmente se reuiriese una mantención entonces el proceso de prototipado es repetido y se definirá un nuevo con$unto de reuerimientos.
#a fase más importante corresponde a la definición de reuerimientos, la cual correspondería a un proceso ue busca apro-imar las visiones del usuario y del desarrollador mediante sucesivas iteraciones. #a definición de reuerimientos consiste de cinco etapas entre dos de las cuales se establece un ciclo iterativo2 Análisis grueso y especificación. El propósito de esta subfase es desarrollar un diseño básico para el prototipo inicial. Diseño y construcción. El ob$etivo de esta subfase es obtener un prototipo inicial. El desarrollador debe concentrarse en construir un sistema con la má-ima funcionalidad, poniendo "nfasis en la interface del usuario. Evaluación. Esta etapa tiene dos propósitos2 e-traer a los usuarios la especificación de los reuerimientos adicionales del sistema y verificar ue el prototipo desarrollado lo haya sido en concordancia con la definición de reuerimientos del sistema. i los usuarios identifican fallas en el prototipo, entonces el desarrollador simplemente corrige el prototipo antes de la siguiente evaluación. El prototipo es repetidamente modificado y evaluado hasta ue todos los reuerimientos del sistema han sido satisfechos. El proceso de evaluación puede ser dividido en cuatro pasos separados2 preparación, demostración, uso del prototipo y discusión de comentarios. En esta fase se decide si el prototipo es aceptado o modificado. : odificación. Esto ocurre cuando la definición d e reuerimientos del sistema es alterada en la sub+fase de evaluación. El desarrollador entonces debe modificar el prototipo de acuerdo a los comentarios hechos por los usuarios. !érmino. 8na vez ue se ha desarrollado un prototipo estable y completo, es necesario ponerse de acuerdo en relación a aspectos de calidad y de representación del sistema. En la siguiente figura se puede ver un esuema en ue estas etapas se realizan, note ue la especificación de reuerimientos está claramente diferenciada de las demás. Es en ella donde se utiliza el prototipado, ya ue permite entregar al usuario lo ue sería una visión la solución final en etapas tempranas del desarrollo, reduciendo tempranamente los costos de especificaciones erróneas.
; 'odelo de desarrollo orientado a prototipos #as venta$as de un enfoue de desarrollo orientado a prototipos están dadas por2 reducción de la incertidumbre y del riesgo, reducción de tiempo y de costos, incrementos en la aceptación del nuevo sistema, me$oras en la administración de proyectos, me$oras en la comunicación entre desarrolladores y clientes, etc. i bien, el desarrollo orientado a prototipos tiene considerables venta$as, tambi"n presenta desventa$as como2 la dependencia de las herramientas de software para el "-ito ya ue la necesidad de disminución de incertidumbre depende de las iteraciones del prototipo, entre más iteraciones e-ista me$or y esto %ltimo se logra mediante el uso de me$ores herramientas lo ue hace a este proceso dependiente de las mismas. *ambi"n, no es posible aplicar la metodología a todos los proyectos de software y, finalmente, la mala interpretación ue pueden hacer los usuarios del prototipo, al cual pueden confundir con el sistema terminado.
desarrollador, lo cual representa el beneficio de establecer una base com%n de comunicación! tambi"n, el hacer e-plícita la posibilidad de iterar sobre estos dominios permitiría ue la convergencia de los mismos sea una posibilidad cierta. &ero lo anterior no asegura el "-ito, por e$emplo, u" certeza e-iste e n ue esta iteración sea en la dirección correcta y lleve a la convergencia de los dominios! no se puede desconocer las diferencias ue e-isten entre la prueba de un prototipo de software en la fase de definición de reuerimientos y el uso del mismo ya como un producto terminado. &ara e-plicar esto, podemos hablar de dos dominios en el usuario, uno ue es el ue se establece cuando se prueba el prototipo y otro, distinto por cierto, el ue ocurre cuando el usuario hace uso del software en ambiente de e-plotación. &or %ltimo, el proceso de iteración para ue sea efectivo debería ser infinito, lo ue lo hace poco efectivo. Es decir, mediante este m"todo acercamos la problemática de los usuarios a los dominios de los desarrolladores y vice versa, pero no sería posible lograr un pareamiento uno a uno entre estos dominios, lo ue sería el ideal.
http://html.rincondelvago.com/desarrollo-orientado-a-prototipos.html
