You are on page 1of 18

MODELO RAD

Arely Daniela Sandoval Quiñones Rigoberto Ramos Robles

 Desarrollado  Proceso DEFINICIÓN . inicialmente por James Martin en 1980. frecuentemente con algunas concesiones. El desarrollo rápido de aplicaciones o RAD (acronimo en inglés de rapid application development) es un proceso de desarrollo de software. la construcción de prototipos y el uso de utilidades CASE (Computer Aided Software Engineering). El método comprende el desarrollo iterativo. de desarrollo de software que permite construir sistemas utilizables en poco tiempo. normalmente de 60 a 90 días.

"planificación" de software desarrollado usando RAD se intercala con la escritura del propio software.  La ¿QUÉ ES? . Es una metodología de desarrollo de software que utiliza una planificación mínima a favor de la creación rápida de prototipos.

Etapa Etapa de planificación de los requisitos de diseño Construcción Implementación ETAPAS .

las restricciones y los requisitos del sistema. elementos de las fases de planeación del sistema y análisis del sistema. ETAPA DE PLANIFICACIÓN DE LOS REQUISITOS . el alcance del proyecto. y miembros del departamento de TI discuten y se ponen de acuerdo sobre las necesidades del negocio. Combina  Usuarios. administradores.

 Se desarrollan modelos y prototipos que representan todos los procesos del sistema. utiliza una combinación de técnicas JAD y Joint herramientas CASE para traducir las Application Development necesidades del usuario en modelos (JAD) funcionales. es un proceso interactivo con los usuarios Herramientas CASE  Se  Este ETAPA DE DISEÑO . entradas y salidas.

de ideas para obtener un borrador inicial de los requisitos Joint Application Development (JAD) Lluvia .Se reúnen los usuarios finales y los desarrolladores.

.

CONSTRUCCIÓN .  Los usuarios tienen la oportunidad de afirmar los requisitos y repasar los resultados.  También se crea la documentación y las instrucciones necesarias para manejar la nueva aplicación.  Las pruebas al sistema se llevan a cabo durante esta etapa. El equipo de desarrolladores trabajando cerca con los usuarios finalizan el diseño y la construcción del sistema. rutinas y procedimientos para operar el sistema.

IMPLEMENTACIÓN . Se hacen pruebas comprensivas y se adiestran los usuarios. Comparado  Esta con métodos tradicionales. el proceso entero es comprimido. etapa envuelve la instalación del nuevo producto y el manejo del cambio del viejo al nuevo sistema.

.

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 “Timeboxing” • Las funciones secundarias son eliminadas como sea necesario para cumplir con el calendario. diseñadores y programadores en uno.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. CARACTERÍSTICAS .

Se pueden usar mayormente bibliotecas existentes. Desempeño no crítico. El sistema puede dividirse en muchos módulos independientes.APLICABLE EN PROYECTOS DONDE: La aplicación funcionará de manera independiente. . Confiabilidad no crítica. Alcance del proyecto limitado.

actualmente. Hace cinco años un proyecto para desarrollar una aplicación tomaba un periodo de entre 18 a 24 meses. El desarrollo de aplicaciones enfrenta una transformación fundamental. ¿POR QUÉ UTILIZAR RAD? . con la práctica del modelo RAD toma entre 1 a 3 meses.

• Convergir tempranamente en un diseño aceptable para el cliente y posible para los desarrolladores. posiblemente a expensas de dinero o de calidad del producto. • Limitar la exposición del proyecto a las fuerzas de cambio. • Prevenir incumplimiento de fechas (RAD necesita un equipo disciplinado en manejo de tiempo). • Ahorrar tiempo de desarrollo.Malas razones • Prevenir presupuestos rebasados (RAD necesita un equipo disciplinado en manejo de costos). Buenas razones ¿POR QUÉ UTILIZAR RAD? .

desempeño del producto no siempre es el óptimo. asegura la máxima confiabilidad.  No DESVENTAJAS . Producto  El resultante de baja calidad (en cuanto a funcionalidad).

¿CUÁNDO NO ES CONVENIENTE UTILIZAR RAD? .Cuando se trate de desarrollar sistemas que no requieran una confiabilidad demasiado alta. o un desempeño crítico.