RAD: DESARROLLO RÁPIDO DE APLICACIONES Definición de

RAD: DESARROLLO RÁPIDO DE APLICACIONES
Definición de RAD
Proceso de desarrollo de software que permite construir sistemas utilizables en poco
tiempo, normalmente de 60 a 90 días, frecuentemente con algunas concesiones.
Principios tras la definición



En ciertas situaciones, una solución utilizable al 80% puede producirse en el 20% de
tiempo que se hubiera requerido para la solución completa.
En ciertas situaciones, los requisitos de negocio de un sistema pueden satisfacerse
aun cuando algunos de sus requisitos operacionales no se satisfagan.
En ciertas situaciones, la aceptabilidad de un sistema puede determinarse en base a
un conjunto mínimo de requisitos consensados en lugar de la totalidad de los
requisitos.
Problemas atendidos por RAD



Con los métodos convencionales pasa un gran lapso de tiempo antes de que el
cliente vea resultados..
Con los métodos convencionales el desarrollo llega a tardar tanto que para cuando
el sistema está listo para utilizarse los procesos del cliente han cambiado
radicalmente.
Con los métodos convencionales no hay nada hasta que el 100% del proceso de
desarrollo se ha realizado, entonces se entrega el 100% del software.
¿Por qué usar RAD?
Malas razones


Prevenir presupuestos rebasados (RAD necesita un equipo disciplinado en manejo
de costos).
Prevenir incumplimiento de fechas (RAD necesita un equipo disciplinado en
manejo de tiempo).
Buenas razones



Convergir tempranamente en un diseño aceptable para el cliente y posible para los
desarrolladores.
Limitar la exposición del proyecto a las fuerzas de cambio.
Ahorrar tiempo de desarrollo, posiblemente a expensas de dinero o de calidad del
producto.
Calendario vs Presupuesto vs Calidad



Las concesiones determinan el ritmo de desarrollo.
Negociar algo que no sea el calendario de trabajo.
Una o más metas pueden ser inalcanzables.
Las concesiones determinan el ritmo de desarrollo



Desarrollo eficiente: equilibra calendario, presupuesto y calidad.
o Calendario: más rápido que el promedio
o Presupuesto: cuesta menos que el promedio
o Calidad: mejor calidad que el promedio
RAD razonable: inclina la balanza hacia el tiempo más corto.
o Calendario: mucho más rápido que el promedio
o Presupuesto: cuesta poco menos que el promedio
o Calidad: calidad poco mejor que el promedio
RAD a fondo: "programar a lo bestia".
o Calendario: más corto posible
o Presupuesto: cuesta más que el promedio
o Calidad: menor calidad que el promedio
Negociar algo que no sea el programa de trabajo



RAD tiene una buena posibilidad de éxito si el cliente está dispuesto a negociar
precio o calidad.
RAD tiene una mejor posibilidad de éxito si el cliente está dispuesto a negociar
precio y calidad.
Negociar la calidad no significa una mayor tasa de fallas sino un producto con
menos funciones o menos eficiente.
Una o más metas pueden ser inalcanzables



El menor número posible de fallas: los desarrolladores pueden no tener la
posibilidad de corregir fallas en algunos componentes de terceros.
Nivel más alto de satisfacción del cliente: algunos requisitos secundarios pueden ser
sacrificados en aras del calendario.
El menor costo de desarrollo: comprar herramientas y componentes puede ser más
caro que desarrollarlos.
Características de RAD




Equipos Híbridos
Herramientas Especializadas
"Timeboxing"
Prototipos Iterativos y Evolucionarios.
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.
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.
Prototipos Iterativos y Evolucionarios



Reunión JAD (Joint Application Development):
o Se reunen los usuarios finales y los desarrolladores.
o Lluvia de ideas para obtener un borrador inicial de los requisitos.
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.
El Facilitador
Mantiene al grupo enfocado:





Tiene claras las metas sobre la información que se necesita recabar.
Prepara una agenda de asuntos antes de la reunión.
Asegura que la discusión adecuada cubra cada asunto.
Asegura que todos participen.
Escribe un reporte al final de la reunión.
Restricciones Importantes








El "ajuste a un propósito de negocios" tiene que ser el criterio de aceptación de los
entregables.
Todas las areas que pueden afectar los requisitos debe estar involucradas a lo largo
del proceso.
Clientes, desarrolladores y gerencia deben aceptar entregables informales:
o Prototipos en papel en lugar de sistemas a gran escala.
o Notas de las reuniones con usuarios en lugar de documentos de requisitos
formales.
o Notas de las reuniones de los diseñadores en lugar de documentos de diseño
formales.
o Principio: crear el mínimo de documentación necesaria para facilitar el
desarrollo futuro y el mantenimiento.
El equipo de desarrollo tiene que poder tomar decisiones tradicionalmente dejadas a
la gerencia.
La escala de tiempo de punta a punta tiene que ser de seis meses o menos.
La iteración debe usarse de manera que se converja a una solución de negocio
aceptable.
Los prototipos tienen que incorporar rápidamente los requisitos en evolución, en
tiempo real, y lograr consenso pronto.
Debe haber una tendencia a "comprar antes que construir".
RAD tiende a funcionar cuando:
1. La aplicación funcionará de manera independiente.
2. Se pueden usar mayormente bibliotecas existentes.
3. Desempeño no crítico.
4. Distribución limitada, interna o vertical.
5. Alcance del proyecto limitado.
6. Confiabilidad no crítica.
7. El sistema puede dividirse en muchos módulos independientes.
8. El producto está dirigido a un mercado altamente especializado.
9. El proyecto cuenta con fuertes limitantes de tiempos parciales (timeboxes).
10. La tecnología requerida tiene más de un año en el mercado.
RAD tiende a fallar cuando:
1. La aplicación debe interoperar con sistemas existentes.
2. Existen pocos componentes reutilizables.
3. Alto desempeño crítico.
4.
5.
6.
7.
El desarrollo no puede aprovechar herramientas de alto nivel.
Distribución amplia, horizontal o masiva.
RAD se convierta en QADAD (Quick And Dirty Application Development).
Métodos RAD para desarrollar sistemas operativos (confiabilidad demasiado alta) o
juegos (desempeño demasiado alto).
8. Riesgos técnicos de tecnología de punta.
9. El producto pone en riesgo la misión o la vida.
10. El producto no puede ser modularizado.
Ventajas de RAD
1. Comprar puede ahorrar dinero en comparación con construir.
2. Los entregables pueden ser facilmente trasladados a otra plataforma.
3. El desarrollo se realiza a un nivel de abstracción mayor.
4. Visibilidad temprana.
5. Mayor flexibilidad.
6. Menor codificación manual.
7. Mayor involucramiento de los usuarios.
8. Posiblemente menos fallas.
9. Posiblemente menor costo.
10. Ciclos de desarrollo más pequeños.
11. Interfaz gráfica estándar.
Desventajas de RAD
1. Comprar puede ser más caro que construir.
2. Costo de herramientas integradas y equipo necesario.
3. Progreso más difícil de medir.
4. Menos eficiente.
5. Menor precisión científica.
6. Riesgo de revertirse a las prácticas sin control de antaño.
7. Más fallas (por síndrome de "codificar a lo bestia").
8. Prototipos pueden no escalar, un problema mayúsculo.
9. Funciones reducidas (por "timeboxing").
10. Dependencia en componentes de terceros: funcionalidad de más o de menos,
problemas legales.
11. Requisitos que no convergen.
12. Interfaz gráfica estándar.
13. Difícil de repetir experiencias exitosas.
14. Funciones no deseadas.
Resumen
"Con el fin de asegurar gran interacción, los proyectos se diseñan con calendarios fijos y se
sacrifica la funcionalidad si es necesario. Esto permite que el equipo de desarrollo se
enfoque en las piezas de funcionalidad que tienen el mayor valor de negocio y en entregar
dicha funcionalidad rápidamente. Los cambios son frecuentemente la razón de los retrasos
en el desarrollo de una aplicación. En los largos procesos lineales de desarrollo, los
cambios en los requisitos funcionales o en el alcance del proyecto, particularmente cuando
gran cantidad de tiempo se ha invertido en la planeación, diseño, desarrollo y pruebas,
provocan que se pierdan meses de trabajo y se incurra en grandes gastos por rediseño y
redesarrollo. RAD ataca la infiltración de cambios de alcance y requisitos al limitar la
exposición del proyecto al cambio, acortando el ciclo de desarrollo y limitando el costo de
los cambios al incorporarlos desde el inicio, antes de que grandes inversiones se hayan
hecho en desarrollo y pruebas."