RAD: Desarrollo Rpido de

Aplicaciones

Definicin de RAD

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

Principios tras la definicin

En ciertas situaciones, una solucin utilizable al 80%
puede producirse en el 20% de tiempo que se hubiera
requerido para la solucin 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 mnimo de
requisitos consensados en lugar de la totalidad de los
requisitos.


Problemas atendidos por RAD
Con los mtodos convencionales pasa un gran lapso de
tiempo antes de que el cliente vea resultados..
Con los mtodos 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 mtodos 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 diseo aceptable para el cliente y
posible para los desarrolladores.
Limitar la exposicin 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 ms metas pueden ser
inalcanzables.

Las concesiones determinan el
ritmo de desarrollo
Desarrollo eficiente: equilibra calendario, presupuesto y calidad.
Calendario: ms rpido que el promedio
Presupuesto: cuesta menos que el promedio
Calidad: mejor calidad que el promedio
RAD razonable: inclina la balanza hacia el tiempo ms corto.
Calendario: mucho ms rpido que el promedio
Presupuesto: cuesta poco menos que el promedio
Calidad: calidad poco mejor que el promedio
RAD a fondo: "programar a lo bestia".
Calendario: ms corto posible
Presupuesto: cuesta ms que el promedio
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 ms metas pueden ser
inalcanzables
El menor nmero posible de fallas: los
desarrolladores pueden no tener la posibilidad
de corregir fallas en algunos componentes de
terceros.
Nivel ms alto de satisfaccin del cliente:
algunos requisitos secundarios pueden ser
sacrificados en aras del calendario.
El menor costo de desarrollo: comprar
herramientas y componentes puede ser ms
caro que desarrollarlos
Caractersticas de RAD
Equipos Hbridos
Herramientas Especializadas
"Timeboxing"
Prototipos Iterativos y Evolucionarios.
Equipos Hbridos
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, diseadores y
programadores en uno.
Herramientas Especializadas
Desarrollo "visual"
Creacin de prototipos falsos (simulacin pura)
Creacin de prototipos funcionales
Mltiples lenguajes
Calendario grupal
Herramientas colaborativas y de trabajo en equipo
Componentes reusables
Interfaces estndares (API)
Control de versiones
"Timeboxing"
Las funciones secundarias son eliminadas
como sea necesario para cumplir con el
calendario.
Prototipos Iterativos y Evolucionarios
Reunin JAD (Joint Application Development):
Se renen 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 diseadores revisan el prototipo.
Los clientes prueban el prototipo, depuran los requisitos.
Los clientes y desarrolladores se renen 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.
Notas:
Cada iteracin dura entre un da y tres semanas.
Reuniones de 2 horas con facilitador que mantiene enfocado al grupo.
El Facilitador
Mantiene al grupo enfocado:
Tiene claras las metas sobre la informacin que
se necesita recabar.
Prepara una agenda de asuntos antes de la
reunin.
Asegura que la discusin adecuada cubra cada
asunto.
Asegura que todos participen.
Escribe un reporte al final de la reunin
Restricciones Importantes
El "ajuste a un propsito de negocios" tiene que ser el criterio de aceptacin de los
entregables.
Todas las reas que pueden afectar los requisitos debe estar involucradas a lo largo del
proceso.
Clientes, desarrolladores y gerencia deben aceptar entregables informales:
Prototipos en papel en lugar de sistemas a gran escala.
Notas de las reuniones con usuarios en lugar de documentos de requisitos formales.
Notas de las reuniones de los diseadores en lugar de documentos de diseo formales.
Principio: crear el mnimo de documentacin 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 iteracin debe usarse de manera que se converja a una solucin de negocio aceptable.
Los prototipos tienen que incorporar rpidamente los requisitos en evolucin, en tiempo
real, y lograr consenso pronto.
Debe haber una tendencia a "comprar antes que construir".
RAD tiende a funcionar cuando:
La aplicacin funcionar de manera independiente.
Se pueden usar mayormente bibliotecas existentes.
Desempeo no crtico.
Distribucin limitada, interna o vertical.
Alcance del proyecto limitado.
Confiabilidad no crtica.
El sistema puede dividirse en muchos mdulos independientes.
El producto est dirigido a un mercado altamente especializado.
El proyecto cuenta con fuertes limitantes de tiempos parciales
(timeboxes).
La tecnologa requerida tiene ms de un ao en el mercado.
RAD tiende a fallar cuando:
La aplicacin debe interoperar con sistemas existentes.
Existen pocos componentes reutilizables.
Alto desempeo crtico.
El desarrollo no puede aprovechar herramientas de alto nivel.
Distribucin amplia, horizontal o masiva.
RAD se convierta en QADAD (Quick And Dirty Application
Development).
Mtodos RAD para desarrollar sistemas operativos (confiabilidad
demasiado alta) o juegos (desempeo demasiado alto).
Riesgos tcnicos de tecnologa de punta.
El producto pone en riesgo la misin o la vida.
El producto no puede ser modularizado
Ventajas de RAD
Comprar puede ahorrar dinero en comparacin con construir.
Los entregables pueden ser fcilmente trasladados a otra
plataforma.
El desarrollo se realiza a un nivel de abstraccin mayor.
Visibilidad temprana.
Mayor flexibilidad.
Menor codificacin manual.
Mayor involucramiento de los usuarios.
Posiblemente menos fallas.
Posiblemente menor costo.
Ciclos de desarrollo ms pequeos.
Interfaz grfica estndar.

Desventajas de RAD
Comprar puede ser ms caro que construir.
Costo de herramientas integradas y equipo necesario.
Progreso ms difcil de medir.
Menos eficiente.
Menor precisin cientfica.
Riesgo de revertirse a las prcticas sin control de antao.
Ms fallas (por sndrome de "codificar a lo bestia").
Prototipos pueden no escalar, un problema maysculo.
Funciones reducidas (por "timeboxing").
Dependencia en componentes de terceros: funcionalidad de ms o de
menos, problemas legales.
Requisitos que no convergen.
Interfaz grfica estndar.
Difcil de repetir experiencias exitosas.
Funciones no deseadas.
Resumen
"Con el fin de asegurar gran interaccin, los proyectos se disean 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
rpidamente. Los cambios son frecuentemente la razn de los retrasos en
el desarrollo de una aplicacin. 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 planeacin, diseo, desarrollo y pruebas, provocan que se pierdan
meses de trabajo y se incurra en grandes gastos por rediseo y
redesarrollo. RAD ataca la infiltracin de cambios de alcance y requisitos al
limitar la exposicin 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."

-Sun Microsystems