Modelo de prototipos

En Ingeniería de software

El Modelo de construcción de prototipos que pertenece a los modelos de desarrollo

evolutivo, El prototipo debe ser construido en poco tiempo, usando los programas
adecuados y no se debe utilizar mucho dinero pues a partir de que éste sea aprobado
nosotros podemos iniciar el verdadero desarrollo del software.

Etapas
 Comunicación
 Plan rápido
 Modelado, diseño rápido
 Construcción del Prototipo
 Desarrollo, entrega y retroalimentación

El paradigma de construcción de prototipos se inicia con la

Comunicación. El ingeniero de software y el cliente encuentran y definen los objetivos
globales para el software, identifican los requisitos conocidos y las áreas del esquema
en donde es necesaria más definición.
Entonces se plantea con rapidez esto es el plan rrapido, es cuando después de
hablar del uso general del prototitpo se empieza con una iteración de construcción de
prototipos y se presenta el modelado (en la forma de un diseño rápido). El diseño
rápido se centra en una representación de aquellos aspectos del software que serán
visibles para el usuario final. El diseño rápido conduce a la
Construcción de un prototipo. el prototipo lo evalúa el usuario y con la
retroalimentación se refinan los requisitos del software que se desarrollará.
El desarrollo la entrega y la retroalimentación ocurre cuando el prototipo se ajusta
para satisfacer las necesidades del cliente. Esto permite que al mismo tiempo el
desarrollador entienda mejor lo que se debe hacer.
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.
Inconvenientes
 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.

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.
Modelo Desarrollo Rápido Aplicaciones RAD en ingles

El modelo de desarrollo rápido de aplicaciones o RAD (acrónimo en inglés de rapid

application development) es un proceso de desarrollo de software, desarrollado
inicialmente por James Martin en 1980

Definición de RAD

Proceso de desarrollo de software que permite construir sistemas utilizables en poco

tiempo, normalmente de 60 a 90 días, frecuentemente con algunas concesiones.

 En ciertas situaciones, una solución utilizable al 80% puede producirse en el

20% de tiempo que se hubiera requerido para la solución completa.
 En ciertas situaciones, los requisitos de negocio de un sistema pueden
satisfacerse aun cuando algunos de sus requisitos operacionales no se
satisfagan.

Problemas atendidos por RAD y que se sulucionan… son los sig.

 Con los métodos convencionales pasa un gran lapso de tiempo antes de que el
cliente vea resultados..
 Con los métodos convencionales el desarrollo llega a tardar tanto que para
cuando el sistema está listo para utilizarse los procesos del cliente han
cambiado radicalmente.
 Con los métodos convencionales no hay nada hasta que el 100% del proceso de
desarrollo se ha realizado, entonces se entrega el 100% del software.

Algunas razones de el por qué utilizar RAD?

Primero las Malas razones

 Prevenir presupuestos rebasados (RAD necesita un equipo disciplinado en

manejo de costos).
 Prevenir incumplimiento de fechas (RAD necesita un equipo disciplinado en
manejo de tiempo).

Buenas razones

 Convertir tempranamente en un diseño aceptable para el cliente y posible para

los desarrolladores.
 Limitar la exposición del proyecto a las fuerzas de cambio.
 Ahorrar tiempo de desarrollo, posiblemente a expensas de dinero o de calidad
del producto.

Negociar algo que no sea el programa de trabajo

 RAD tiene una mejor posibilidad de éxito si el cliente está dispuesto a negociar
precio y calidad.
  Negociar la calidad no significa una mayor tasa de fallas sino un producto con
menos funciones o menos eficiente.

Una o más metas pueden ser inalcanzables

 El menor número posible de fallas: los desarrolladores pueden no tener la

posibilidad de corregir fallas en algunos componentes de terceros.
 Nivel más alto de satisfacción del cliente: algunos requisitos secundarios
pueden ser sacrificados en aras del calendario.
 El menor costo de desarrollo: comprar herramientas y componentes puede ser
más caro que desarrollarlos.

Características de RAD

 Equipos Híbridos
 Herramientas Especializadas
 Prototipos Iterativos y Evolucionarios.

Equipos Híbridos

 Equipos compuestos por alrededor de seis personas, incluyendo

desarrolladores y usuarios de tiempo completo del sistema así como aquellas
personas involucradas con los requisitos.
 Los desarrolladores de RAD deben ser "renacentistas": analistas, diseñadores y
programadores en uno.

Herramientas Especializadas

 Desarrollo "visual"
 Creación de prototipos falsos (simulación pura)
 Creación de prototipos funcionales
 Múltiples lenguajes
 Calendario grupal
 Herramientas colaborativas y de trabajo en equipo
 Componentes reusables
 Interfaces estándares (API)
 Control de versiones

Prototipos Iterativos y Evolucionarios

 Reunión JAD
o Se reunen los usuarios finales y los desarrolladores.
o Lluvia de ideas para obtener un borrador inicial de los requisitos.
 Iterar hasta acabar:
o Los desarrolladores construyen y depuran el prototipo basado en los
requisitos actuales.
o Los diseñadores revisan el prototipo.
o Los clientes prueban el prototipo, depuran los requisitos.
 o Los clientes y desarrolladores se reunen para revisar juntos el producto,
refinar los requisitos y generar solicitudes de cambios.
o Los cambios para los que no hay tiempo no se realizan. Los requisitos
secundarios se eliminan si es necesario para cumplir el calendario.
 Notas:
o Cada iteración dura entre un día y tres semanas.
o Reuniones de 2 horas con facilitador que mantiene enfocado al grupo.

Ventajas de RAD

1. Comprar puede ahorrar dinero en comparación con construir.

2. Los entregables pueden ser fácilmente trasladados a otra plataforma.
3. El desarrollo se realiza a un nivel de abstracción mayor.
4. Visibilidad temprana.
5. Mayor flexibilidad.
6. Menor codificación manual.
7. Mayor involucramiento de los usuarios.
8. Posiblemente menos fallas.
9. Posiblemente menor costo.
10. Ciclos de desarrollo más pequeños.
11. Interfaz gráfica estándar.

Desventajas de RAD

1. Comprar puede ser más caro que construir.

2. Costo de herramientas integradas y equipo necesario.
3. Progreso más difícil de medir.
4. Menos eficiente.
5. Menor precisión científica.
6. Riesgo de revertirse a las prácticas sin control de antaño.
7. Más fallas (por síndrome de "codificar a lo bestia").
8. Prototipos pueden no escalar, un problema mayúsculo.
9. Funciones reducidas
10. Dependencia en componentes de terceros: funcionalidad de más o de menos,
problemas legales.
11. Requisitos que no convergen.
12. Interfaz gráfica estándar.
13. Difícil de repetir experiencias exitosas.
14. Funciones no deseadas.