You are on page 1of 7

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. o Calendario: ms rpido 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 ms corto. o Calendario: mucho ms rpido 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: ms corto posible o Presupuesto: cuesta ms 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 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): 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 diseadores 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 iteracin dura entre un da 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 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 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. o Notas de las reuniones con usuarios en lugar de documentos de requisitos formales. o Notas de las reuniones de los diseadores en lugar de documentos de diseo formales. o 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 rapidamente los requisitos en evolucin, en tiempo real, y lograr consenso pronto. Debe haber una tendencia a "comprar antes que contruir".
o

RAD tiende a funcionar cuando:


1. La aplicacin funcionar de manera independiente. 2. Se pueden usar mayormente bibliotecas existentes. 3. Desempeo no crtico. 4. Distribucin limitada, interna o vertical. 5. Alcance del proyecto limitado. 6. Confiabilidad no crtica. 7. El sistema puede dividirse en muchos mdulos independientes. 8. El producto est dirigido a un mercado altamente especializado. 9. El proyecto cuenta con fuertes limitantes de tiempos parciales (timeboxes). 10. La tecnologa requerida tiene ms de un ao en el mercado.

RAD tiende a fallar cuando:


1. 2. 3. 4. 5. 6. 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). 7. Mtodos RAD para desarrollar sistemas operativos (confiabilidad demasiado alta) o juegos (desempeo demasiado alto).

8. Riesgos tcnicos de tecnologa de punta. 9. El producto pone en riesgo la misin o la vida. 10. El producto no puede ser modularizado.

Ventajas de RAD
1. Comprar puede ahorrar dinero en comparacin con construir. 2. Los entregables pueden ser facilmente trasladados a otra plataforma. 3. El desarrollo se realiza a un nivel de abstraccin mayor. 4. Visibilidad temprana. 5. Mayor flexibilidad. 6. Menor codificacin manual. 7. Mayor involucramiento de los usuarios. 8. Posiblemente menos fallas. 9. Posiblemente menor costo. 10. Ciclos de desarrollo ms pequeos. 11. Interfaz grfica estndar.

Desventajas de RAD
1. Comprar puede ser ms caro que construir. 2. Costo de herramientas integradas y equipo necesario. 3. Progreso ms difcil de medir. 4. Menos eficiente. 5. Menor precisin cientfica. 6. Riesgo de revertirse a las prcticas sin control de antao. 7. Ms fallas (por sndrome de "codificar a lo bestia"). 8. Prototipos pueden no escalar, un problema maysculo. 9. Funciones reducidas (por "timeboxing"). 10. Dependencia en componentes de terceros: funcionalidad de ms o de menos, problemas legales. 11. Requisitos que no convergen. 12. Interfaz grfica estndar. 13. Difcil de repetir experiencias exitosas. 14. 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."

You might also like