Metodología RAD

Modulo 304

Metodología RAD

Es el desarrollo rápido de aplicaciones

Antecedentes y creadores

Creadores

La idea principal era continuar con el desarrollo de sistemas de información en una muy deliberada, estructurada y metódica manera, reiterando cada una de las etapas del ciclo de vida del desarrollo. Se tenía que resolver el tiempo de ejecución en rutinas de cálculo y procesamiento de datos en torno a las actividades pesadas.

Definición

Es una metodología que se centra en desarrollar aplicaciones rápidamente por medio de iteraciones frecuentes y aprobaciones con comentarios continuos de los clientes. Al priorizar los lanzamientos de prototipos ágiles y rápidos, RAD incide en la usabilidad del software.

Proceso de desarrollo de software que permite construir sistemas utilizables en poco tiempo, normalmente de 60 a 90 días, frecuentemente con algunas concesiones.

Fases del RAD

1.Modelado de Gestión

2.Modelado de Datos

3.Modelado de Procesos

4.Generación de Aplicaciones

5.Pruebas de Entrega

¿Por qué usar RAD?

El objetivo de RAD es reducir el tiempo de planificación y centrarse en la construcción y creación de un producto.

Características

Los beneficios clave de la metodología RAD son:

• Reducción del tiempo de desarrollo y aceleración de la entrega.

• Mejora de la flexibilidad y la adaptabilidad.
• Mejor gestión de riesgos.
• Menos programación manual y tiempos de prueba más cortos.
• Comentarios de los usuarios constantes, relevantes y en tiempo real.

VENTAJAS DE RAD

• 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.

Antecedentes

Concebido en la década de 1970 pero presentado oficialmente por James Martin en 1991

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?

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.

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.

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.

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.

Debido a que RAD utiliza un repositorio de componentes para su reutilización, a menudo hay menos errores en el código, lo que suele hacer que el tiempo de prueba también sea más corto. El producto final ya será probado y tendrá menos defectos que otros métodos. ¡