Modelo De Desarrollo Rapido De
Aplicaciones (DRA)
El Desarrollo Rápido de Aplicaciones
(DRA) (Rapid Application Development RAD) es un modelo de proceso del
desarrollo del software lineal secuencial que enfatiza un ciclo de desarrollo
extremadamente corto. DRA es una adaptación a "Alta velocidad" en el que
se logra el desarrollo rápido utilizando un enfoquede construcción basado en componentes.
Si se comprenden bien los requisitos y se limita el ámbito del proyecto, el
proceso DRA permite al equipo de desarrollo crear un "sistema
completamente funcional" dentro de periodos cortos de tiempo. Cuando se utiliza
principalmente para aplicaciones de sistemas de información, el enfoque
DRA comprende las siguientes fases: Modelado de gestión: el flujo de
información entre las funciones de gestión se modela de forma que
responda a las siguientes preguntas:
¿Qué información conduce el proceso de
gestión? ¿Qué información se genera? ¿Quién la genera? ¿A dónde va
la información? ¿Quién la proceso?
imagen: https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiRhkXpg-5tKJo_-e-GUmwHx4mLAPaECvSfWvifnYle87sZjJPuRKUpXqqKq03alZzNYwz5UTseUvrZAAJZNc7-IMXJP9id0ITm9gh9N6t_RyFB1yAvmAgxcg3g5V2AzOjGijiq8r6XZDU/s1600/rda.png
Modelado
de datos: el flujo de
información definido como parte de la fase de modelado de gestión se refina
como un conjunto de objetos de datos necesarios para apoyar la
empresa. Se definen las características (llamadas atributos) de cada uno de
los objetos y las relaciones entre estos objetos.
Modelado
de proceso: los
objetos de datos definidos en la fase de modelado de datos quedan transformados
para lograr el flujo de información necesario para implementar
una función de gestión. Las descripciones del proceso se crean
para añadir, modificar, suprimir, o
recuperar un objeto de datos. Es la
comunicación entre los objetos.
Generación
de aplicaciones: El
DRA asume la utilización de técnicas de cuarta generación. En lugar de
crear software con lenguajes de programación de tercera generación, el
proceso DRA trabaja para volver a utilizar componentes de programas ya
existentes (cuando es posible) o a crear componentes reutilizables
(cuando sea necesario). En todos los casos se utilizan herramientas
automáticas para facilitar la construcción del software.
Pruebas
de entrega: Como el
proceso DRA enfatiza la reutilización, ya se han comprobado muchos de los
componentes de los programas. Esto reduce tiempo de pruebas. Sin embargo, se deben probar todos los componentes nuevos y se deben
ejercitar todas las interfaces a fondo.
Características
De Rad
Entre las principales características
del RAD tenemos:
·
Equipos Híbridos
o
Equipos
compuestos por alrededor de seis personas, incluyendo
o
desarrolladores
y usuarios de tiempo completo del sistema así como
o
aquellas
personas involucradas con los requisitos.
o
Los
desarrolladores de RAD deben ser "renacentistas": analistas,
o
diseñadores
y programadores en uno.
·
Herramientas Especializadas
o
Desarrollo
"visual"
o
Creación
de prototipos falsos (simulación pura)
o
Creación
de prototipos funcionales
o
Múltiples
lenguajes
o
Calendario
grupal
o
Herramientas
colaborativas y de trabajo en equipo
o
Componentes
reusables
o
Interfaces
estándares (API)
o
Control
de versiones
·
"Timeboxing"
o
Las
funciones secundarias son eliminadas como sea necesario para cumplir con el
calendario.
·
Prototipos Iterativos y Evolucionarios
o
Reunión JAD (Joint Application Development):
§
Se
reúnen los usuarios finales y los desarrolladores.
§
Lluvia
de ideas para obtener un borrador inicial de los requisitos.
o
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
·
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.
·
Visibilidad
temprana.
·
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 RAD
·
Comprar
puede ser más caro que construir.
·
Costo
de herramientas integradas y equipo necesario.
·
Progreso
más difícil de medir.
·
Menos
eficiente.
·
Menor
precisión científica.
·
Riesgo
de revertirse a las prácticas sin control de antaño.
·
Más
fallas (por síndrome de "codificar a lo bestia").
·
Prototipos
pueden no escalar, un problema mayúsculo.
·
Funciones
reducidas (por "timeboxing").
·
Dependencia
en componentes de terceros: funcionalidad de más o de menos, problemas legales.
.png)
.jpg)
