Desarrollo rápido de aplicaciones

Desarrollo rápido de aplicaciones (RAD), también llamado creación rápida de aplicaciones (RAB), es a la vez 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 énfasis 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.

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

Historia

El desarrollo rápido de aplicaciones fue una respuesta a los procesos en cascada impulsados por 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 con estos métodos es que se basaron 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. Los enfoques basados en planes intentan definir rígidamente los requisitos, la solución y el plan para implementarlos, 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 conocía como el modelo en espiral. Boehm y otros enfoques posteriores de RAD 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 del riesgo. Un prototipo podría probar algunas de las partes potenciales más difíciles del sistema a principios del ciclo de vida. Esto puede proporcionar información valiosa sobre la viabilidad de un diseño y puede impedir que el equipo siga buscando soluciones que resulten demasiado complejas o con mucho tiempo para implementar. This benefit of finding problems earlier in the life-cycle rather than later was a key benefit of the RAD approach. Cuanto antes se puede encontrar un problema más barato es abordar.
• Los usuarios son mejores en usar y reaccionar que en crear especificaciones. En el modelo de cascada era común que un usuario firmara un conjunto de requisitos, pero luego cuando se presentaba con un sistema implementado para darse cuenta repentinamente de que un diseño dado carecía de algunas características críticas o era demasiado complejo. En general, la mayoría de los usuarios dan una retroalimentación mucho más útil cuando pueden experimentar un prototipo del sistema de funcionamiento en lugar de definir abstractamente lo que debe ser ese sistema.
• Los prototipos pueden ser utilizables y pueden evolucionar hacia el producto completado. One approach used in some RAD methods was to build the system as a series of prototipos that evolve from minimal function to moderately useful to the final completed system. La ventaja de esto además de las dos ventajas anteriores era que los usuarios podían obtener funcionalidad de negocio útil mucho antes en el proceso.

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ó mediante la publicación de un libro en 1991, Desarrollo rápido de aplicaciones. Esto ha resultado en 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 comerciales intensivos en conocimiento y de 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, 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 de ciclo de vida de proyectos de sistemas tradicionales.

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 comerciales era repensar radicalmente los procesos comerciales centrales, como las ventas y la atención al cliente, teniendo en cuenta las nuevas capacidades de la tecnología de la información. RAD a menudo era una parte esencial de los programas de reingeniería de negocios más grandes. El enfoque de creación rápida de prototipos de RAD fue 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 comercial central.

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.

Proyectos exitosos que incluyeron ANZ Bank, Lend Lease, BHP, Coca-Cola Amatil, Alcan, Hong Kong Jockey Club y muchos otros.

Éxito que llevó tanto a Scott Shultz como a James Martin a pasar 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 método RAD de James Martin

Fases en el enfoque James Martin de RAD

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

1. Fase de planificación de las necesidades – combina elementos de las fases de planificación de sistemas y análisis de sistemas del ciclo de vida de desarrollo de sistemas (SDLC). Los usuarios, administradores y funcionarios de TI examinan y aceptan las necesidades empresariales, el alcance de los proyectos, las limitaciones y las necesidades de los sistemas. Termina cuando el equipo acepta las cuestiones clave y obtiene autorización de gestión para continuar.
2. Fase de diseño de usuario – durante esta fase, los usuarios interactúan con analistas de sistemas y desarrollan modelos y prototipos que representan todos los procesos, insumos y productos del sistema. Los grupos o subgrupos 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. 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.
3. Fase de construcción – se centra en la tarea de desarrollo de programas y aplicaciones similar al SDLC. En RAD, sin embargo, los usuarios continúan participando y todavía pueden sugerir cambios o mejoras a medida que se desarrollan pantallas o informes reales. Sus tareas son la programación y desarrollo de aplicaciones, codificación, integración unitaria y pruebas del sistema.
4. Fase de corte – se asemeja a las tareas finales en la fase de implementación de SDLC, incluyendo la conversión de datos, pruebas, cambio al nuevo sistema y entrenamiento de usuarios. Comparado con métodos tradicionales, todo el proceso es comprimido. Como resultado, el nuevo sistema es construido, entregado y puesto en funcionamiento mucho antes.

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 (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 a menudo 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 de negocio de un proyecto RAD puede ser a menudo mucho más alta que la obtenida mediante un modelo de cascada. El software puede ser más utilizable y tiene una mejor oportunidad de enfocarse en problemas empresariales 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 conocen como requisitos no funcionales (premios AKA o atributos de calidad) incluyendo seguridad y 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 crítica de RAD hecho correctamente es la mitigación de riesgos. Vale la pena recordar que Boehm caracterizó inicialmente el modelo espiral como un enfoque basado en el riesgo. A RAD approach can focus in early on the key risk factors and adapt to them based on empirical evidence collected in the early part of the process. Por ejemplo, la complejidad de prototipar 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 fallas catastróficas que han marcado grandes saltos de agua. En el modelo Waterfall era común llegar a una realización después de seis meses o más de análisis y desarrollo que requería una repensación radical de todo el sistema. Con RAD este tipo de información se puede descubrir y actuar sobre el anterior proceso.

Desventajas

Las supuestas desventajas de RAD incluyen:

• El riesgo de un nuevo enfoque. Para la mayoría de las tiendas de TI RAD era un nuevo enfoque que requería profesionales experimentados para repensar la forma en que trabajaban. Los seres humanos son prácticamente siempre inversos para cambiar y cualquier proyecto emprendido con nuevas herramientas o métodos será más probable que falle la primera vez simplemente debido al requisito 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 escasos recursos. Una cosa virtualmente 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 de cascada, los usuarios definirían los requisitos y luego, sobre todo, desaparecerían a medida que los desarrolladores crearan el sistema. En RAD los usuarios están involucrados desde el principio y a través de prácticamente todo el proyecto. Esto requiere que el negocio está dispuesto a invertir el tiempo de los expertos de dominio de aplicaciones. La paradoja es que cuanto mejor sea el experto, más familiaricen con su dominio, más se requieren para dirigir realmente el negocio y puede ser difícil convencer a sus supervisores de invertir su tiempo. Sin tales compromisos, los proyectos de RAD no tendrán éxito.
• Menos control. Una de las ventajas de RAD es que proporciona un proceso adaptable flexible. El ideal es poder adaptarse rápidamente a los problemas y oportunidades. Hay un inevitable cambio entre la flexibilidad y el control, más de un medio menos del otro. Si un proyecto (por ejemplo, software crítico para la vida) controla más que la agilidad RAD no es apropiado.
• Pobre diseño. El enfoque en los prototipos puede ser tomado demasiado lejos en algunos casos, lo que resulta en una metodología de "hack and test" donde los desarrolladores están constantemente haciendo cambios menores en los componentes individuales e ignorando los problemas de arquitectura del sistema que podrían dar lugar a 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.
• Falta de escalabilidad. RAD normalmente se centra en equipos de proyectos pequeños a medianos. Las otras cuestiones mencionadas anteriormente (sin diseño y control) presentan desafíos especiales al utilizar un enfoque RAD para sistemas de gran escala.