Desarrollo rápido de aplicaciones

El desarrollo rápido de aplicaciones ( RAD , por sus siglas en inglés), también conocido como construcción rápida de aplicaciones ( RAB , por sus siglas en inglés), es tanto un término general para los enfoques de desarrollo de software adaptativo como el nombre del método de desarrollo rápido de James Martin . En general, los enfoques RAD para el desarrollo de software dan menos importancia a la planificación y más a un proceso adaptativo. Los prototipos se utilizan a menudo como complemento, o incluso en lugar, de las especificaciones de diseño.

RAD es especialmente adecuado para (aunque no se limita a) el desarrollo de software impulsado por los requisitos de la interfaz de usuario . Los creadores de interfaces gráficas de usuario suelen denominarse herramientas de desarrollo rápido de aplicaciones. Otros enfoques para el desarrollo rápido incluyen los modelos adaptativo , ágil , espiral y unificado .

El desarrollo rápido de aplicaciones fue una respuesta a los procesos en cascada basados ​​en la planificación , desarrollados en las décadas de 1970 y 1980, como el Método de Análisis y Diseño de Sistemas Estructurados (SSADM). Uno de los problemas de estos métodos es que se basaban en un modelo de ingeniería tradicional utilizado para diseñar y construir cosas como puentes y edificios. El software es un tipo de artefacto intrínsecamente diferente. El software puede cambiar el proceso utilizado para resolver un problema. Como resultado, el conocimiento adquirido durante el propio proceso de desarrollo puede retroalimentar los requisitos y el diseño de la solución. ^{[ 1 ]} Los enfoques basados ​​en la planificación intentan definir los requisitos, la solución y el plan de implementación, y tienen un proceso que desalienta los cambios. Los enfoques RAD, por otro lado, reconocen que el desarrollo de software es un proceso intensivo en conocimiento y proporcionan procesos flexibles que ayudan a aprovechar el conocimiento adquirido durante el proyecto para mejorar o adaptar la solución.

La primera alternativa RAD de este tipo fue desarrollada por Barry Boehm y se conoció como el modelo espiral . Boehm y otros enfoques RAD posteriores enfatizaron el desarrollo de prototipos, además de, o en lugar de, especificaciones de diseño rigurosas. Los prototipos tenían varias ventajas sobre las especificaciones tradicionales:

• Reducción de riesgos. Un prototipo permite probar algunas de las partes potencialmente más difíciles del sistema en las primeras etapas de su ciclo de vida . Esto proporciona información valiosa sobre la viabilidad del diseño y evita que el equipo busque soluciones demasiado complejas o que requieran demasiado tiempo para su implementación. Esta ventaja de detectar problemas en una etapa temprana del ciclo de vida, en lugar de en etapas posteriores, fue un beneficio clave del enfoque RAD. Cuanto antes se detecte un problema, más económico será solucionarlo.
• Los usuarios son mejores utilizando y reaccionando que creando especificaciones. En el modelo de cascada, era común que un usuario aprobara un conjunto de requisitos, pero luego, al ver el sistema implementado, se diera cuenta de repente de que un diseño determinado carecía de algunas características críticas o era demasiado complejo. En general, la mayoría de los usuarios proporcionan comentarios mucho más útiles cuando pueden experimentar un prototipo del sistema en funcionamiento, en lugar de definir abstractamente cómo debería ser ese sistema.
• Los prototipos pueden ser utilizables y evolucionar hasta convertirse en el producto final. Un enfoque empleado en algunos métodos RAD consistía en construir el sistema como una serie de prototipos que evolucionaban desde una funcionalidad mínima hasta una funcionalidad moderadamente útil y, finalmente, al sistema completo. La ventaja de esto, además de las dos ventajas anteriores, era que los usuarios podían obtener funcionalidades útiles para el negocio mucho antes en el proceso. ^{[ 2 ]}

Partiendo de las ideas de Barry Boehm y otros, James Martin desarrolló el enfoque de desarrollo rápido de aplicaciones (RAD) durante la década de 1980 en IBM y finalmente lo formalizó con la publicación del libro " Rapid Application Development " en 1991. Esto ha generado cierta confusión en torno al término RAD, incluso entre profesionales de TI. Es importante distinguir entre RAD como una alternativa general al modelo en cascada y RAD como el método específico creado por Martin. El método Martin se diseñó específicamente para sistemas empresariales intensivos en conocimiento e interfaz de usuario.

Estas ideas fueron desarrolladas y perfeccionadas por pioneros de RAD como James Kerr y Richard Hunter, quienes escribieron juntos el libro fundamental sobre el tema, Inside RAD, ^{[ 3 ]} que narra la experiencia de un gestor de proyectos RAD mientras aplicaba y refinaba la metodología RAD en tiempo real en un proyecto RAD real. Estos profesionales, y otros como ellos, contribuyeron a que RAD ganara popularidad como alternativa a los enfoques tradicionales del ciclo de vida de los proyectos de sistemas.

El enfoque RAD también maduró durante el período de mayor interés en la reingeniería de procesos de negocio . La idea de la reingeniería de procesos de negocio era repensar radicalmente los procesos centrales del negocio, como las ventas y la atención al cliente, teniendo en cuenta las nuevas capacidades de la tecnología de la información. RAD solía ser una parte esencial de los programas de reingeniería de procesos de negocio más amplios. El enfoque de prototipado rápido de RAD fue una herramienta clave para ayudar a usuarios y analistas a pensar de forma innovadora sobre cómo la tecnología podría reinventar radicalmente un proceso central del negocio. ^{[ 4 ] [ 5 ]}

Gran parte de la familiaridad de James Martin con RAD provenía de la división de Ingeniería de la Información de Dupont y de su líder, Scott Schultz, y de sus respectivas relaciones con John Underwood, quien dirigía una empresa de desarrollo RAD a medida que fue pionera en muchos proyectos RAD exitosos en Australia y Hong Kong.

Entre los proyectos exitosos se incluyen ANZ Bank , Lendlease , BHP , Coca-Cola Amatil , Alcan , Hong Kong Jockey Club y muchos otros.

Este éxito llevó a que tanto Scott Shultz como James Martin pasaran un tiempo en Australia con John Underwood para comprender los métodos y los detalles de por qué Australia tuvo un éxito desproporcionado en la implementación de importantes proyectos RAD de misión crítica.

El enfoque de James Martin para RAD divide el proceso en cuatro fases distintas:

1. La fase de planificación de requisitos combina elementos de las fases de planificación y análisis del sistema del ciclo de vida del desarrollo de sistemas (SDLC). Usuarios, gerentes y personal de TI discuten y acuerdan las necesidades del negocio , el alcance del proyecto , las restricciones y los requisitos del sistema. Finaliza cuando el equipo llega a un acuerdo sobre los puntos clave y obtiene la autorización de la gerencia para continuar.
2. Fase de diseño de usuario : durante esta fase, los usuarios interactúan con los analistas de sistemas y desarrollan modelos y prototipos que representan todos los procesos, entradas y salidas del sistema . Los grupos o subgrupos RAD suelen utilizar una combinación de técnicas de diseño conjunto de aplicaciones (JAD) y herramientas CASE para traducir las necesidades del usuario en modelos funcionales. El diseño de usuario es un proceso interactivo continuo que permite a los usuarios comprender, modificar y, finalmente, aprobar un modelo funcional del sistema que satisfaga sus necesidades.
3. Fase de construcción : se centra en el desarrollo de programas y aplicaciones, similar al ciclo de vida del desarrollo de software (SDLC). Sin embargo, en RAD, los usuarios siguen participando y pueden sugerir cambios o mejoras a medida que se desarrollan las pantallas o los informes. Sus tareas incluyen la programación y el desarrollo de aplicaciones, la codificación , la integración unitaria y las pruebas del sistema .
4. Fase de transición : se asemeja a las tareas finales de la fase de implementación del SDLC, incluyendo la conversión de datos, las pruebas, el cambio al nuevo sistema y la capacitación de los usuarios. En comparación con los métodos tradicionales, todo el proceso se comprime. Como resultado, el nuevo sistema se construye, se entrega y se pone en funcionamiento mucho antes. ^{[ 6 ]}

En los entornos de tecnología de la información modernos, muchos sistemas se construyen actualmente utilizando algún grado de desarrollo rápido de aplicaciones ^{[ 7 ]} (no necesariamente el enfoque de James Martin). Además del método de Martin, los métodos ágiles y el Proceso Unificado de Rational se utilizan con frecuencia para el desarrollo RAD.

Las supuestas ventajas de RAD incluyen:

• Mejor calidad. Al permitir que los usuarios interactúen con prototipos en constante evolución, la funcionalidad empresarial de un proyecto RAD suele ser mucho mayor que la que se logra con un modelo en cascada. El software puede ser más fácil de usar y tiene más posibilidades de centrarse en problemas empresariales críticos para los usuarios finales, en lugar de problemas técnicos de interés para los desarrolladores. Sin embargo, esto excluye otras categorías de lo que se conoce como requisitos no funcionales (también llamados restricciones o atributos de calidad), como la seguridad y la portabilidad .
• Control de riesgos. Si bien gran parte de la literatura sobre RAD se centra en la velocidad y la participación del usuario, una característica fundamental de un RAD bien implementado es la mitigación de riesgos. Cabe recordar que Boehm caracterizó inicialmente el modelo espiral como un enfoque basado en riesgos. Un enfoque RAD puede centrarse desde el principio en los factores de riesgo clave y ajustarse a ellos en función de la evidencia empírica recopilada en la fase inicial del proceso. Por ejemplo, la complejidad del prototipado de algunas de las partes más complejas del sistema.
• Más proyectos se completan a tiempo y dentro del presupuesto. Al centrarse en el desarrollo de unidades incrementales, se reducen las posibilidades de fallos catastróficos que han afectado a los grandes proyectos en cascada. En el modelo en cascada, era común llegar a la conclusión, tras seis meses o más de análisis y desarrollo, de que se requería una revisión radical de todo el sistema. Con RAD, este tipo de información se puede descubrir y abordar antes en el proceso. ^{[ 2 ] [ 8 ]}

Las supuestas desventajas de la RAD incluyen:

• El riesgo de un nuevo enfoque. Para la mayoría de las empresas de TI, RAD representaba un enfoque novedoso que exigía a profesionales experimentados replantearse su forma de trabajar. Los seres humanos suelen ser reacios al cambio, y cualquier proyecto que emprenda con nuevas herramientas o métodos tiene más probabilidades de fracasar en el primer intento, simplemente por la necesidad de que el equipo aprenda.
• Falta de énfasis en los requisitos no funcionales , que a menudo no son visibles para el usuario final en el funcionamiento normal.
• Requiere tiempo y recursos limitados. Prácticamente todos los enfoques de RAD tienen en común una mayor interacción entre usuarios y desarrolladores a lo largo de todo el ciclo de vida. En el modelo en cascada, los usuarios definen los requisitos y luego se desentienden mientras los desarrolladores crean el sistema. En RAD, los usuarios participan desde el principio y prácticamente durante todo el proyecto. Esto exige que la empresa esté dispuesta a invertir el tiempo de expertos en el dominio de la aplicación. La paradoja es que cuanto mejor sea el experto, más familiarizado esté con su dominio, más se le requerirá para la gestión del negocio y puede resultar difícil convencer a sus supervisores de que inviertan su tiempo. Sin este compromiso, los proyectos RAD no tendrán éxito.
• Menor control. Una de las ventajas de RAD es que proporciona un proceso flexible y adaptable. Lo ideal es poder adaptarse rápidamente tanto a los problemas como a las oportunidades. Existe una compensación inevitable entre flexibilidad y control: a mayor flexibilidad, menor control. Si un proyecto (por ejemplo, software crítico para la vida ) valora más el control que la agilidad, RAD no es apropiado.
• Diseño deficiente. En algunos casos, el enfoque en los prototipos puede ser excesivo, lo que resulta en una metodología de "hackeo y prueba" donde los desarrolladores realizan constantemente cambios menores en componentes individuales e ignoran problemas de arquitectura del sistema que podrían resultar en un mejor diseño general. Esto puede ser especialmente problemático para metodologías como la de Martin, que se centran tanto en la interfaz de usuario del sistema. ^{[ 9 ]}
• Falta de escalabilidad. RAD generalmente se centra en equipos de proyecto pequeños y medianos. Los otros problemas mencionados anteriormente (menor diseño y control) presentan desafíos especiales al utilizar un enfoque RAD para sistemas de muy gran escala. ^{[ 10 ] [ 11 ] [ 12 ]}

Conceptos prácticos para implementar RAD:

• Creador de interfaces gráficas de usuario , donde se representan las principales herramientas de software para RAD.
• Lenguaje de programación de cuarta generación , por ejemplo FileMaker , 4th Dimension , dBase y Visual FoxPro.

Otros conceptos similares:

• Programación basada en flujo
• Desarrollo de software Lean
• Plataforma como servicio
• Plataformas de desarrollo de bajo código
• Plataforma de desarrollo sin código

• Steve McConnell (1996). Desarrollo rápido: Cómo controlar los cronogramas de software descontrolados , Microsoft Press Books, ISBN 978-1-55615-900-8
• Kerr, James M.; Hunter, Richard (1993). Inside RAD: How to Build a Fully Functional System in 90 Days or Less . McGraw-Hill. ISBN 0-07-034223-7.
• Ellen Gottesdiener (1995). " Realidades de RAD: Más allá de la publicidad, cómo funciona realmente RAD " Tendencias en el desarrollo de aplicaciones
• Ken Schwaber (1996). Gestión ágil de proyectos con Scrum , Microsoft Press Books, ISBN 978-0-7356-1993-7
• Steve McConnell (2003). Desarrollo de software profesional: plazos más cortos, productos de mayor calidad, proyectos más exitosos, carreras profesionales mejoradas , Addison-Wesley, ISBN 978-0-321-19367-4
• Dean Leffingwell (2007). Escalando la agilidad del software: Mejores prácticas para grandes empresas , Addison-Wesley Professional, ISBN 978-0-321-45819-3
• Scott Stiner (2016). Lista Forbes: "Desarrollo rápido de aplicaciones (RAD): un proceso inteligente, rápido y valioso para desarrolladores de software".

• Desafíos de trabajar con el modelo RAD
• ¿Qué proyectos son adecuados para el desarrollo rápido de aplicaciones?
• Ejemplos reales de implementación de RAD