MODELO DE DESARROLLO

RAPIDO DE APLICACIONES
(DRA)
INTEGRANTES: CRISTHIAN RIVERO LAZO
UGARTE CANAZA GUSTAVO ENRIQUE
QUE ES DRA?

• Es un proceso de desarrollo de software, desarrollado inicialmente por James

Martin en 1980. El método comprende el desarrollo iterativo, la construcción
de prototipos y el uso de utilidades CASE. Tradicionalmente, el desarrollo
rápido de aplicaciones tiende a englobar también la usabilidad, utilidad y la
rapidez de ejecución.
Cuando se utiliza principalmente para aplicaciones de sistemas de información,
el enfoque DRA comprende las siguientes fases:
• Modelado de gestión
• Modelado de datos
• Modelado de proceso
• Generación de aplicaciones
• Pruebas de entrega
CARACTERÍSTICAS DE DRA

1. Equipos Híbridos
2. Herramientas Especializadas
3. "Timeboxing"
4. Prototipos Iterativos y Evolucionarios
HERRAMIENTAS ESPECIALIZADAS

• Desarrollo "visual“
 Creación de prototipos funcionales
• Múltiples lenguajes
 Calendario grupal
 Interfaces estándares (API)
PROTOTIPOS ITERATIVOS Y EVOLUCIONARIOS

 Reunión JAD (Joint Application Development):

 Iterar hasta acabar:
 Los desarrolladores construyen y depuran el prototipo basado en los requisitos actuales.
 Los diseñadores revisan el prototipo.
 Los clientes prueban el prototipo, depuran los requisitos.
 Los clientes y desarrolladores se reúnen para revisar juntos el producto, refinar los requisitos y generar
solicitudes de cambios.
 Los cambios para los que no hay tiempo no se realizan.
 Los requisitos secundarios se eliminan si es necesario para cumplir el calendario.
VENTAJAS DEL DRA

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

• Los entregables pueden ser fácilmente trasladados a otra plataforma.
• El desarrollo se realiza a un nivel de abstracción mayor.
• Mayor flexibilidad.
• Menor codificación manual.
• Mayor involucramiento de los usuarios.
• Posiblemente menos fallas.
• Posiblemente menor costo.
• Ciclos de desarrollo más pequeños.
• Interfaz gráfica estándar.
DESVENTAJAS DE DRA

• Comprar puede ser más caro que construir.

• Costo de herramientas integradas y equipo necesario.
• Progreso más difícil de medir.
• Menos eficiente.
• Más fallas (por síndrome de “codificar a lo bestia”).
• Funciones reducidas (por “timeboxing”).