Metodología Rad
Estructura o Fases
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
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.
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?
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).
Pruebas de entrega
Como el proceso DRA enfatiza la reutilización, ya se han comprobado muchos de los componentes de los programas.
Ventajas
o El desarrollo se realiza a un nivel de abstracción mayor.
o Visibilidad temprana.
o Menor codificación manual.
o Posiblemente menos fallas.
o Posiblemente menor costo.
o Ciclos de desarrollo más pequeños.
¿Que es?
Qué es RAD
El desarrollo rápido de aplicaciones es un enfoque de desarrollo de software ágil que se centra más en proyectos de software en curso y comentarios de los
usuarios y menos en seguir un plan estricto.
Desventajas
Escala: Las prácticas de RAD se complican cuando se expanden más allá de un solo equipo o requieren comunicación entre equipos.
Compromiso: El ciclo frecuente de prototipos RAD requiere que los desarrolladores y clientes se comprometan a reuniones frecuentes que, al principio, pueden parecer consumir ciclos innecesarios para ambas partes.
Enfoque de interfaz: La metodología RAD motiva a los desarrolladores a encontrar la solución perfecta para el cliente.
Como consecuencia, algunos desarrolladores se enfocan menos en las prácticas back-end
Y en general:
o Progreso más difícil de medir.
o Riesgo de revertirse a las prácticas sin control de antaño.
o Más fallas (por síndrome de “codificar a lo bestia”).