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 desarrollo rápido de aplicaciones fue una respuesta a los procesos en cascada basados en planes , desarrollados en los años 1970 y 1980, como el método de análisis y diseño de sistemas estructurados (SSADM). Uno de los problemas con 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 obtenido del 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 de RAD de este tipo fue desarrollada por Barry Boehm y se la conoció como el modelo espiral . Boehm y otros enfoques de 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 podría probar algunas de las partes potenciales más difíciles del sistema al comienzo 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 demasiado complejas o que requieran mucho tiempo para implementarse. Este beneficio de encontrar problemas al comienzo del ciclo de vida en lugar de más tarde fue un beneficio clave del enfoque RAD. Cuanto antes se pueda encontrar un problema, más barato será abordarlo.
Los usuarios son mejores en el uso y la reacción que en la creación de 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, de repente se daba cuenta de que a un diseño determinado le faltaban 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 final. 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 el sistema final completo. La ventaja de esto, además de las dos ventajas anteriores, fue que los usuarios podían obtener una funcionalidad comercial útil 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 durante la década de 1980 en IBM y finalmente lo formalizó con la publicación de un libro en 1991, Rapid Application Development . Esto ha dado lugar a cierta confusión sobre el término RAD incluso entre los 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 adaptó a los sistemas empresariales intensivos en conocimiento e interfaz de usuario.
Estas ideas fueron desarrolladas y mejoradas por pioneros de RAD como James Kerr y Richard Hunter, quienes juntos escribieron el libro seminal sobre el tema, Inside RAD, [3] que siguió el viaje de un gerente de proyectos de RAD mientras impulsaba y refinaba la metodología RAD en tiempo real en un proyecto RAD real. Estos profesionales, y otros como ellos, ayudaron a que RAD ganara 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 empresariales era repensar radicalmente los procesos empresariales básicos, como las ventas y la atención al cliente, teniendo en cuenta las nuevas capacidades de la tecnología de la información. El RAD era a menudo una parte esencial de los programas de reingeniería empresarial más grandes. El enfoque de creación rápida de prototipos del RAD era una herramienta clave para ayudar a los usuarios y analistas a "pensar fuera de la caja" sobre formas innovadoras en que la tecnología podría reinventar radicalmente un proceso empresarial central. [4] [5]
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 de RAD exitosos en Australia y Hong Kong.
Un éxito que llevó a Scott Shultz y a 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 RAD de James Martin
Fases del enfoque de James Martin para 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 del desarrollo de sistemas (SDLC). Los usuarios, gerentes y miembros del personal de TI discuten y acuerdan las necesidades de negocios , el alcance del proyecto , las limitaciones y los requisitos del sistema. Finaliza cuando el equipo se pone de acuerdo sobre los problemas clave y obtiene la autorización de la gerencia 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 de trabajo. El diseño del usuario es un proceso interactivo continuo que permite a los usuarios comprender, modificar y, finalmente, aprobar un modelo de trabajo del sistema que satisfaga sus necesidades.
Fase de construcción : se centra en la tarea de desarrollo de programas y aplicaciones, similar al 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 reales. Sus tareas son la programación y el desarrollo de aplicaciones, la codificación , la integración de unidades y las pruebas del sistema .
Fase de transición : se asemeja a las tareas finales de la fase de implementación del ciclo de vida del desarrollo de software (SDLC), que incluyen 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]
Ventajas
En los entornos de tecnología de la información modernos, muchos sistemas se construyen 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 racional se utilizan a menudo para el desarrollo RAD.
Las supuestas ventajas del RAD incluyen:
Mejor calidad. Al permitir que los usuarios interactúen con prototipos en evolución, la funcionalidad empresarial de un proyecto RAD puede ser a menudo 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 los problemas empresariales que son críticos para los usuarios finales en lugar de los problemas técnicos de interés para los desarrolladores. Sin embargo, esto excluye otras categorías de lo que normalmente se conoce como requisitos no funcionales (también conocidos como restricciones o atributos de calidad), entre los que se incluyen la seguridad y la portabilidad .
Control de riesgos. Aunque 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 realizado 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 en los factores de riesgo clave desde el principio y ajustarse a ellos en función de 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 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 habitual 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 consecuencia en una etapa más temprana del proceso. [2] [8]
Desventajas
Las supuestas desventajas del RAD incluyen:
El riesgo de un nuevo enfoque. Para la mayoría de las empresas de TI, el RAD era un nuevo enfoque que requería que profesionales experimentados repensaran su forma de trabajar. Los humanos prácticamente siempre son reacios al cambio y cualquier proyecto que se emprenda 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 la operación normal.
Requiere tiempo y 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 desaparecerían a medida que 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 la aplicación. La paradoja es que cuanto mejor sea el experto, cuanto más familiarizado esté con su dominio, más se le exigirá que dirija realmente la empresa y puede resultar difícil convencer a sus supervisores de que inviertan su tiempo. Sin esos compromisos, los proyectos de 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 una inevitable disyuntiva entre flexibilidad y control: más de uno significa menos del otro. Si un proyecto (por ejemplo, un software crítico para la vida ) valora más el control que la agilidad, RAD no es adecuado.
Diseño deficiente. En algunos casos, el enfoque en los prototipos puede ser excesivo, lo que da como resultado una metodología de "modificación y prueba" en la que los desarrolladores realizan constantemente cambios menores en componentes individuales e ignoran cuestiones de arquitectura del sistema que podrían dar como resultado un mejor diseño general. Esto puede ser especialmente un problema para metodologías como la de Martin, que se centran tanto en la interfaz de usuario del sistema. [9]
Falta de escalabilidad. El RAD se centra normalmente en equipos de proyectos de tamaño pequeño a mediano. Los otros problemas citados anteriormente (menor diseño y control) presentan desafíos especiales cuando se utiliza un enfoque RAD para sistemas de escala muy grande. [10] [11] [12]
^ Brooks, Fred (1986). Kugler, HJ (ed.). No Silver Bullet Essence and Accidents of Software Engineering (PDF) . Procesamiento de la información '86. Elsevier Science Publishers BV (Holanda del Norte). ISBN 0-444-70077-3. Recuperado el 2 de julio de 2014 .
^ ab Boehm, Barry (mayo de 1988). "Un modelo espiral de desarrollo de software" (PDF) . IEEE Computer . 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.; Hunter, 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 postcapitalista. Libros electrónicos de Harper Collins. ISBN978-0887306204.
^ Martin, James (1991). Desarrollo rápido de aplicaciones. Macmillan. ISBN0-02-376775-8.
^ Martin, James (1991). Desarrollo rápido de aplicaciones. Macmillan. Págs. 81-90. ISBN.0-02-376775-8.
^ "La desintegración de AD: cómo volver a armarlo" (PDF) . gartner.com.br . Consultado el 13 de abril de 2010 .
^ Beck, Kent (2000). Explicación de la programación extrema. Addison Wesley. págs. 3–7. ISBN0201616416.
^ Gerber, Aurona; Van Der Merwe, Alta; Alberts, Ronell (16–18 de noviembre de 2007). "Implicaciones prácticas de las metodologías de desarrollo rápido". Actas de la Conferencia de Educación en Ciencias de la Computación y Tecnología de la Información, CSITEd-2007 . Conferencia de Educación en Ciencias de la Computación y Tecnología de la Información. 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 ágil de software en un contexto industrial: un estudio exploratorio" (PDF) . Primer Simposio Internacional sobre Ingeniería y Medición de Software Empírico (ESEM 2007) . pp. 255–264. doi :10.1109/esem.2007.12. ISBN978-0-7695-2886-1. Número de identificación del sujeto 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 . pp. 564–569. doi :10.1109/icse.2003.1201238. ISBN .0-7695-1877-X.S2CID16919353 .
^ 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.S2CID29042153 .
Kerr, James M.; Hunter, 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: Beyond the Hype to How RAD Really Works" Tendencias de desarrollo de aplicaciones
Steve McConnell (2003). Desarrollo de software profesional: plazos más breves, productos de mayor calidad, proyectos más exitosos, carreras profesionales mejoradas , Addison-Wesley, ISBN 978-0-321-19367-4
Dean Leffingwell (2007). Escalado de 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 los desarrolladores de software"
