RAD: Desarrollo Rápido de Aplicaciones

Gonzalo Mena Mendoza

Ingeniería de Software

Maestría en Ingeniería de Software Distribuido

Universidad Autónoma de Querétaro

Artículo Original

Rapid Application Development

Walter Maner

15 de marzo de 1997

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.
  • Calendario: más rápido que el promedio
  • Presupuesto: cuesta menos que el promedio
  • Calidad: mejor calidad que el promedio
• RAD razonable: inclina la balanza hacia el tiempo más corto.
  • Calendario: mucho más rápido 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: más corto posible
  • Presupuesto: cuesta más 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 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):
  • Se reunen 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 diseñadores revisan el prototipo.
  • Los clientes prueban el prototipo, depuran los requisitos.
  • Los clientes y desarrolladores se reunen 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 iteración dura entre un día y tres semanas.
  • Reuniones de 2 horas con facilitador que mantiene enfocado al grupo.

El Facilitador

• 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:
  • 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 diseñadores en lugar de documentos de diseño formales.
  • 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 rapidamente los requisitos en evolución, en tiempo real, y lograr consenso pronto.
• Debe haber una tendencia a "comprar antes que contruir".

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. El desarrollo no puede aprovechar herramientas de alto nivel.
5. Distribución amplia, horizontal o masiva.
6. RAD se convierta en QADAD (Quick And Dirty Application Development).
7. 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."

-Sun Microsystems