MODELO DE DESARROLLO RÁPIDO DE APLICACIONES
El desarrollo rápido de aplicaciones o DRA
(Rapid Application Development) 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.
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 enfoque de 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?
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.
Obviamente la limitación de tiempo
impuesto en un proyecto DRA demanda "ámbito en escalas". Si una
aplicación de gestión puede modularse se forma que permita completarse cada una
de las funciones principales en menos de tres meses (utilizando el enfoque
descrito anteriormente), es un candidato del DRA. Cada una de las funciones
puede ser afrontada por un equipo DRA diferente y ser integradas en un solo
conjunto.
Ø Para
proyectos grandes aunque por escalas, el DRA requiere recursos humanos
suficientes como para crear el número correcto de equipos DRA.
Ø DRA
requiere clientes y desarrolladores comprometidos en las rápidas actividades
necesarias para completar un sistema en un marco de tiempo abreviado. Si no hay
compromiso, por ninguna de las partes constituyentes, los proyectos DRA
fracasaran.
No todos los tipos de aplicaciones son
apropiados para DRA. Si un sistema no se puede modular adecuadamente. La
construcción de los componentes necesarios para DRA será problemático. Si está
en juego el alto rendimiento, y se va a conseguir el rendimiento convirtiendo
interfaces en componentes de sistema, el enfoque DRA puede que no funcione.
DRA no es adecuado cuando Ingeniería de
Software los riesgos técnicos son altos. Esto ocurre cuando una nueva
aplicación hace uso de tecnologías nuevas, o cuando el nuevo software requiere
un alto grado de interoperabilidad con programas de computadora ya existentes.
DRA enfatiza el desarrollo de componentes de programas reutilizables. La reutilización
es la piedra angular de las tecnologías de objetos, y se encuentra en el modelo
de proceso de ensamblaje.
Características De Rad
Entre
las principales características del RAD tenemos:
1. 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.
2. 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
3. "Timeboxing"
Ø Las
funciones secundarias son eliminadas como sea necesario para cumplir con el
calendario.
Prototipos Iterativos y Evolucionarios
Ø 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.
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 de DRA
Ø 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.
Ø 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.
Ø Menor
precisión científica.
Ø Es
difícil para los clientes proporcionar todos los requisitos de una sola vez,
siendo esto necesario para este modelo.
Ø Más
fallas (por síndrome de "codificar a la ligera").
Ø Los
Prototipos pueden no escalar, un problema mayúsculo.
Ø Se
requiere más desarrolladores, ya que múltiples equipos trabajan concurrentemente
No hay comentarios:
Publicar un comentario