sábado, 1 de agosto de 2009

DEFINICION


Pertenece a los modelos de desarrollo evolutivo, se inicia con la definición de los objetivos globales para el software, luego se identifican los requisitos conocidos y las áreas del esquema en donde es necesaria más definición. Entonces se plantea con rapidez una iteración de construcción de prototipos y se presenta el modelado.

CLASES DE PROTOTIPO




PROTOTIPADO RAPIDO


PROTOTIPADO EVOLUTIVO


Construcción de una implementación parcial que cubre losrequisitos conocidos, para ir aprendiendo el resto y,paulatinamente, incorporarlos al sistema

  1. Reduce el riesgo y aumenta la probabilidad de éxito
  2. No se conocen niveles apropiados de calidad ydocumentación
  3. Problemas de gestión de configuración.

Construir software para que pueda ser modificado fácilmentees un “arte desconocido”.


PROTOTIPADO OPERACIONAL

CONSTRUCCION

Otro modelo adicional, como alternativa a los mencionados o bien como complemento a los mismos es la construcción de prototipos, que consiste en construir un modelo en computadora, que describa la interacción sistema - usuario y que implemente un subconjunto de la función requerida, sometiendolo a la revisión por parte del usuario en un proceso iterativo y evolutivo. Los pasos necesarios para la construcción de prototipos son los siguientes:




  1. Evaluar la solicitud del software para determinar si el sistema es candidato para la construcción de un prototipo. Considerando si es necesario presentar la interacción usuario-sistema y tomando en cuenta la complejidad del desarrollo del propio prototipo.
  2. Elaborar una representación abreviada de los requisitos. Utilizando alguno de los modelos mencionados anteriormente.
  3. Crear un conjunto de especificaciones de diseño para el prototipo. Centrandose en los aspectos de mas alto nivel y no en el detalle.
  4. Crear y probar el software del prototipo. De ser posible utilizar herramientas automatizadas para tal efecto, como lenguajes de cuarta generación, módulos de código reusables, herramientas RAD o paquetes especializados en prototipos.
  5. Presentar el prototipo al usuario y orientarlo a que sea él quien lo “opere”. Aquí es donde el usuario podrá validar sus propios requerimientos y sugerir las modificaciones necesarias.
  6. Repetir los pasos 4 y 5 hasta que todos los requisitos queden formalizados. El modelo de construcción de prototipos se recomienda especialmente cuando los requerimientos cambian frecuentemente, cuando no se tiene la suficiente participación del usuario o cuando no se tienen suficientemente especificados los requerimientos. Una ventaja importante es que el usuario va “viendo” la evolución del sistema.


El principal inconveniente es que se desconoce el tiempo que se tardará en crear un producto aceptable. No se sabe cuantas iteraciones se tendrán que realizar. Otro inconveniente es que se pueden adoptar prácticas de programación de prueba-y-error, sin un análisis y diseño formales previos.

VENTAJAS

Este modelo es útil cuando el cliente conoce los objetivos generales para el software, pero no identifica los requisitos detallados de entrada, procesamiento o salida.

  • También ofrece un mejor enfoque 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 que debería tomar la interacción humano-máquina.
  • La 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 contexto de cualquiera de los modelos del proceso expuestos.

Sin importar la forma en que éste se aplique, el paradigma de construcción de prototipos ayuda al desarrollador de software y al cliente a entender de mejor manera cuál será el resultado de la construcción cuando los requisitos estén satisfechos. De esta manera, este ciclo de vida en particular, involucra al cliente más profundamente para adquirir el producto.

DESVENTAJAS

  • El usuario tiende a crearse unas expectativas cuando ve el prototipo de cara al sistema final. A 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 que obliga en la mayor parte de los casos a reconstruirlo una vez que el prototipo ha cumplido su función.
  • Es frecuente que el usuario se muestre reacio a ello y pida que sobre ese prototipo se construya el sistema final, lo que lo convertiría en un prototipo evolutivo, pero partiendo de un estado poco recomendado.
  • En areas de desarrollar rápidamente el prototipo, el desarrollador suele tomar algunas decisiones de implementación poco convenientes (por ejemplo, elegir un lenguaje de programación incorrecto porque proporcione un desarrollo más rápido). Con el paso del tiempo, el desarrollador puede olvidarse de la razón que le llevó a tomar tales decisiones, con lo que se corre el riesgo de que dichas elecciones pasen a formar parte del sistema final.
  • Por que es muy dificil y complejo realizarlo.

CONCLUSIONES

A pesar de que tal vez surjan problemas, la construcción de prototipos puede ser un paradigma efectivo para la ingeniería del software. La clave es definir las reglas del juego desde el principio; es decir, el cliente y el desarrollador se deben poner de acuerdo en:
  • Que el prototipo se construya y sirva como un mecanismo para la definición de requisitos.
  • Que el prototipo se descarte, al menos en parte.
  • Que después se desarrolle el software real con un enfoque hacia la calidad.