El desarrollo rápido de aplicaciones ( RAD ), también llamado creación rápida de aplicaciones ( RAB ), es un término general para los enfoques de desarrollo de software adaptativo y el nombre del método de desarrollo rápido de James Martin . En general, los enfoques RAD para el desarrollo de software ponen menos énfasis en la planificación y más en un proceso adaptativo. Los prototipos se utilizan a menudo además de las especificaciones de diseño o, a veces, incluso en lugar de ellas.
El rápido desarrollo de aplicaciones fue una respuesta a los procesos en cascada basados en planes , desarrollados en las décadas de 1970 y 1980, como el Método de Diseño y Análisis 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 inherentemente diferente. El software puede cambiar radicalmente todo 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 planes intentan definir rígidamente los requisitos, la solución y el plan para implementarla, 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 modelo en 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:
La reducción de riesgos. Un prototipo podría probar algunas de las partes potenciales más difíciles del sistema en las primeras etapas del ciclo de vida . Esto puede proporcionar información valiosa sobre la viabilidad de un diseño y puede evitar que el equipo busque soluciones que resulten ser demasiado complejas o que requieran mucho tiempo para implementar. Este beneficio de encontrar problemas más temprano en el ciclo de vida y no más tarde fue un beneficio clave del enfoque RAD. Cuanto antes se pueda detectar un problema, más barato será solucionarlo.
Los usuarios saben usar y reaccionar mejor que crear especificaciones. En el modelo en cascada, era común que un usuario aprobara un conjunto de requisitos pero luego, cuando se le presentaba un sistema implementado, se daba 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 brindan comentarios mucho más útiles cuando pueden experimentar un prototipo del sistema en ejecución en lugar de definir de manera abstracta cómo debería ser ese sistema.
Los prototipos pueden ser utilizables y evolucionar hasta convertirse en el producto completo. Un enfoque utilizado en algunos métodos RAD fue construir el sistema como una serie de prototipos que evolucionan desde una funcionalidad mínima hasta una utilidad moderada hasta llegar al sistema final completo. La ventaja de esto, además de las dos ventajas anteriores, era que los usuarios podían obtener funciones comerciales útiles mucho antes en el proceso. [2]
A partir de las ideas de Barry Boehm y otros, James Martin desarrolló el enfoque de desarrollo rápido de aplicaciones durante la década de 1980 en IBM y finalmente lo formalizó publicando un libro en 1991, Rapid Application Development . Esto ha generado cierta confusión sobre el término RAD incluso entre los profesionales de TI. Es importante distinguir entre RAD como alternativa general al modelo en cascada y RAD como método específico creado por Martin. El método Martin se diseñó para sistemas empresariales intensivos en conocimiento y UI.
Estas ideas fueron desarrolladas y mejoradas por pioneros de RAD como James Kerr y Richard Hunter, quienes juntos escribieron el libro fundamental sobre el tema, Inside RAD, [3] que siguió el viaje de un gerente de proyecto de RAD mientras conducía y refinaba el RAD. Metodología en tiempo real sobre un proyecto RAD real. Estos profesionales, y otros como ellos, ayudaron a RAD a ganar popularidad como una 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 máximo interés en la reingeniería empresarial . La idea de la reingeniería de procesos de negocio era repensar radicalmente los procesos de negocio centrales, como las ventas y la atención al cliente, teniendo en mente las nuevas capacidades de la tecnología de la información. RAD era a menudo una parte esencial de programas de reingeniería empresarial más amplios. El enfoque de creación rápida de prototipos de RAD fue una herramienta clave para ayudar a los usuarios y analistas a "pensar de manera innovadora" sobre formas innovadoras en que la tecnología podría reinventar radicalmente un proceso empresarial central. [4] [5] [6]
Gran parte de la comodidad de James Martin con RAD provino de la división de Ingeniería de la Información de Dupont y su líder Scott Schultz y sus respectivas relaciones con John Underwood, quien dirigió una empresa de desarrollo de RAD a medida que fue pionera en muchos proyectos RAD exitosos en Australia y Hong Kong.
Éxito que llevó a Scott Shultz y James Martin a pasar tiempo en Australia con John Underwood para comprender los métodos y detalles de por qué Australia tuvo un éxito desproporcionado en la implementación de importantes proyectos RAD de misión crítica.
El método James Martin RAD
Fases del enfoque de James Martin hacia RAD
El enfoque de James Martin para RAD divide el proceso en cuatro fases distintas:
Fase de planificación de requisitos : combina elementos de las fases de planificación y análisis de sistemas del ciclo de vida de desarrollo de sistemas (SDLC). Los usuarios, gerentes y miembros del personal de TI discuten y acuerdan las necesidades comerciales , el alcance del proyecto , las limitaciones y los requisitos del sistema. Finaliza cuando el equipo se pone de acuerdo sobre los temas clave y obtiene la autorización de la dirección para continuar.
Fase de diseño del 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 de RAD suelen utilizar una combinación de técnicas de diseño de aplicaciones conjuntas (JAD) y herramientas CASE para traducir las necesidades de los usuarios en modelos funcionales. El diseño de usuario es un proceso interactivo continuo que permite a los usuarios comprender, modificar y eventualmente aprobar un modelo de trabajo del sistema que satisfaga sus necesidades.
Fase de construcción : se centra en tareas de desarrollo de programas y aplicaciones similares al SDLC. Sin embargo, en RAD los usuarios continúan participando y aún pueden sugerir cambios o mejoras a medida que se desarrollan pantallas o informes reales. Sus tareas son programación y desarrollo de aplicaciones, codificación , integración de unidades y pruebas de sistemas .
Fase de transición : se asemeja a las tareas finales de la fase de implementación del SDLC, incluida 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 está comprimido. Como resultado, el nuevo sistema se construye, entrega y pone en funcionamiento mucho antes. [7]
Ventajas
En los entornos modernos de tecnología de la información, muchos sistemas ahora se construyen utilizando cierto grado de desarrollo rápido de aplicaciones [8] (no necesariamente el enfoque de James Martin). Además del método de Martin, a menudo se utilizan métodos ágiles y el Proceso Unificado Racional para el desarrollo de RAD.
Las supuestas ventajas de RAD incluyen:
Mejor calidad. Al hacer que los usuarios interactúen con prototipos en evolución, la funcionalidad empresarial de un proyecto RAD a menudo puede ser mucho mayor que la que se logra mediante un modelo en cascada. El software puede ser más utilizable y tiene más posibilidades de centrarse en problemas comerciales que son 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 generalmente se conoce como requisitos no funcionales (también conocidos como restricciones o atributos de calidad), incluidas la seguridad y la portabilidad .
Control de riesgo. Aunque gran parte de la literatura sobre RAD se centra en la velocidad y la participación del usuario, una característica fundamental de RAD realizado correctamente es la mitigación de riesgos. Vale la pena recordar que Boehm inicialmente caracterizó el modelo espiral como un enfoque basado en el riesgo. Un enfoque RAD puede centrarse desde el principio en los factores de riesgo clave y ajustarse a ellos basándose en la evidencia empírica recopilada en la primera parte del proceso. Por ejemplo, la complejidad de crear prototipos de algunas de las partes más complejas del sistema.
Más proyectos completados a tiempo y dentro del presupuesto. Al centrarse en el desarrollo de unidades incrementales, se reducen las posibilidades de que se produzcan fallos catastróficos que han afectado a los grandes proyectos en cascada. En el modelo Cascada era común llegar a una conclusión después de seis meses o más de análisis y desarrollo que requería un replanteamiento radical de todo el sistema. Con RAD, este tipo de información se puede descubrir y actuar en una fase más temprana del proceso. [2] [9]
Desventajas
Las supuestas desventajas de RAD incluyen:
El riesgo de un nuevo enfoque. Para la mayoría de los departamentos de TI, RAD era un nuevo enfoque que requería que profesionales experimentados repensaran su forma de trabajar. Los seres humanos prácticamente siempre son reacios al cambio y cualquier proyecto emprendido con nuevas herramientas o métodos tendrá más probabilidades de fracasar la primera vez simplemente debido a 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 de recursos escasos. Una cosa que prácticamente todos los enfoques de RAD tienen en común es que hay mucha más interacción a lo largo de todo el ciclo de vida entre usuarios y desarrolladores. En el modelo en cascada, los usuarios definirían los requisitos y luego, en su mayoría, desaparecerían cuando los desarrolladores crearan el sistema. En RAD los usuarios participan desde el principio y durante prácticamente todo el proyecto. Esto requiere que la empresa esté dispuesta a invertir el tiempo de los expertos en el dominio de aplicaciones. La paradoja es que cuanto mejor es el experto, más familiarizado está con su dominio, más se le exige que dirija realmente el negocio y puede resultar difícil convencer a sus supervisores de que inviertan su tiempo. Sin tales compromisos, los proyectos de la RAD no tendrán éxito.
Menos 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 un equilibrio inevitable entre flexibilidad y control: más de uno significa menos del otro. Si un proyecto (por ejemplo , software crítico para la vida ) valora el control más que la agilidad, RAD no es apropiado.
Mal diseño. En algunos casos, centrarse en los prototipos puede llevarse demasiado lejos, lo que da como resultado una metodología de "hack and test" en la que los desarrolladores realizan constantemente cambios menores en los componentes individuales e ignoran los problemas de la arquitectura del sistema que podrían dar como resultado un mejor diseño general. Esto puede ser un problema especialmente para metodologías como la de Martin, que se centran tanto en la interfaz de usuario del sistema. [10]
Falta de escalabilidad. RAD normalmente se centra en equipos de proyectos pequeños y medianos. Las otras cuestiones citadas anteriormente (menor diseño y control) presentan desafíos especiales cuando se utiliza un enfoque RAD para sistemas de muy gran escala. [11] [12] [13]
^ Brooks, Fred (1986). Kugler, HJ (ed.). No hay esencia de bala de plata y accidentes de la ingeniería de software (PDF) . Procesamiento de información '86. Elsevier Science Publishers BV (Holanda Septentrional). ISBN 0-444-70077-3. Consultado el 2 de julio de 2014 .
^ ab Boehm, Barry (mayo de 1988). "Un modelo en espiral de desarrollo de software" (PDF) . Computadora IEEE . doi :10.1109/2.59. S2CID 1781829. Archivado desde el original (PDF) el 29 de marzo de 2018 . Consultado el 1 de julio de 2014 .
^ Kerr, James M.; Cazador, Richard (1993). Inside RAD: Cómo construir un sistema completamente funcional en 90 días o menos. McGraw-Hill. ISBN 0-07-034223-7 .
^ Drucker, Peter (3 de noviembre de 2009). Sociedad poscapitalista. Libros electrónicos de Harper Collins. ISBN978-0887306204.
^ Martín, James (1991). Desarrollo rápido de aplicaciones. Macmillan. ISBN0-02-376775-8.
^ servicios de desarrollo de aplicaciones de Android [ enlace muerto ]
^ Martín, James (1991). Desarrollo rápido de aplicaciones. Macmillan. págs. 81–90. ISBN0-02-376775-8.
^ "La desintegración de AD: volver a armarlo" (PDF) . gartner.com.br . Consultado el 13 de abril de 2010 .
^ Gerber, Aurona; Van Der Merwe, Alta; Alberts, Ronell (16 a 18 de noviembre de 2007). "Implicaciones prácticas de las metodologías de desarrollo rápido". Actas de la Conferencia sobre educación en informática y tecnología de la información, CSITEd-2007 . Jornada de Educación en Informática y TI. Mauricio. págs. 233–245. CiteSeerX 10.1.1.100.645 . ISBN978-99903-87-47-6.
^ Andrew Begel, Nachiappan Nagappan (septiembre de 2007). "Uso y percepciones del desarrollo de software ágil en un contexto industrial: un estudio exploratorio" (PDF) . Primer Simposio Internacional sobre Ingeniería y Medición de Software Empírico (ESEM 2007) . págs. 255–264. doi :10.1109/esem.2007.12. ISBN978-0-7695-2886-1. S2CID 1941370.
^ Maximilien, EM; Williams, L. (2003). "Evaluación del desarrollo basado en pruebas en IBM". 25ª Conferencia Internacional sobre Ingeniería de Software, 2003. Actas . págs. 564–569. doi :10.1109/icse.2003.1201238. ISBN0-7695-1877-X. S2CID 16919353.
^ Stephens, Matt; Rosenberg, Doug (2003). Programación extrema refactorizada: el caso contra XP . doi :10.1007/978-1-4302-0810-5. ISBN978-1-59059-096-6. S2CID 29042153.
Kerr, James M.; Cazador, Richard (1993). Inside RAD: Cómo construir un sistema completamente funcional en 90 días o menos . McGraw-Hill. ISBN 0-07-034223-7.
Ellen Gottesdiener (1995). "RAD Realities: Más allá de las exageraciones sobre cómo funciona realmente RAD" Tendencias de desarrollo de aplicaciones
Steve McConnell (2003). Desarrollo de software profesional: cronogramas más cortos, productos de mayor calidad, proyectos más exitosos, carreras mejoradas , Addison-Wesley, ISBN 978-0-321-19367-4
Dean Leffingwell (2007). Ampliación de la agilidad del software: mejores prácticas para grandes empresas , Addison-Wesley Professional, ISBN 978-0-321-45819-3
Scott Stiner (2016). Lista de Forbes: "Desarrollo rápido de aplicaciones (RAD): un proceso inteligente, rápido y valioso para los desarrolladores de software"
