Desarrollo rápido de aplicaciones - Rapid application development

El desarrollo de aplicaciones rápidas ( RAD ), también llamado construcción de aplicaciones rápidas ( 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 énfasis en un proceso de adaptación. Los prototipos se utilizan a menudo además o, a veces, incluso en lugar de las especificaciones de diseño.

RAD es especialmente adecuado para (aunque no se limita a) el desarrollo de software que se basa en 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 proceso de desarrollo en sí puede retroalimentar los requisitos y el diseño de la solución. Los enfoques basados en planes intentan definir de manera rígida 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 proporciona 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 RAD posteriores enfatizaron el desarrollo de prototipos, así como o en lugar de rigurosas especificaciones de diseño. 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 al principio 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 de implementación. Este beneficio de encontrar problemas más temprano en el ciclo de vida que 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 firmara un conjunto de requisitos, pero luego, cuando se le presentaba un sistema implementado, se daba cuenta de repente 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 brindan comentarios mucho más útiles cuando pueden experimentar un prototipo del sistema en ejecución en lugar de definir de manera abstracta cuál debería ser ese sistema.
Los prototipos se pueden utilizar y pueden evolucionar hasta convertirse en el producto terminado. 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 para el sistema final completado. La ventaja de esto, además de las dos ventajas anteriores, era que los usuarios podían obtener funcionalidades comerciales útiles 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ó con la publicación de un libro en 1991, Desarrollo rápido de aplicaciones . Esto ha provocado 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 de cascada y RAD como el método específico creado por Martin. El método Martin se diseñó para sistemas de negocios 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 fundamental sobre el tema, Inside RAD, que siguió el viaje de un gerente de proyecto de RAD mientras manejaba y refinaba la Metodología RAD en condiciones reales. -tiempo en 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 mayor interés en la reingeniería empresarial . La idea de la reingeniería de los procesos comerciales era repensar radicalmente los procesos comerciales centrales, como las ventas y la atención al cliente, con las nuevas capacidades de la tecnología de la información en mente. 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 de RAD fue una herramienta clave para ayudar a los usuarios y analistas a "pensar fuera de la caja" sobre formas innovadoras en las que la tecnología podría reinventar radicalmente un proceso empresarial 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 de 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ó a Scott Shultz y James Martin a pasar 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 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 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 restricciones y los requisitos del sistema. Termina cuando el equipo acuerda los temas 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 RAD suelen utilizar una combinación de técnicas de desarrollo de aplicaciones conjuntas (JAD) y herramientas CASE para traducir las necesidades del usuario en modelos de trabajo. 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 la tarea de desarrollo de programas y aplicaciones similar al SDLC. En RAD, sin embargo, 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 la programación y el desarrollo de aplicaciones, la codificación, la integración de unidades y las pruebas de sistemas.
Fase de transición : se asemeja a las tareas finales en la fase de implementación de SDLC, incluida la conversión de datos, las pruebas, el cambio al nuevo sistema y la capacitación del usuario. En comparación con los métodos tradicionales, todo el proceso está comprimido. Como resultado, el nuevo sistema se construye, se entrega y se pone en funcionamiento mucho antes.

Pros y contras del desarrollo rápido de aplicaciones

En los entornos modernos de tecnología de la información, muchos sistemas ahora se construyen utilizando algún 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 racional 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 comercial de un proyecto RAD a menudo puede ser mucho más alta que la lograda a través de 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 (restricciones AKA o atributos de calidad), incluida 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 realizada correctamente es la mitigación de riesgos. Vale la pena recordar que Boehm inicialmente caracterizó el modelo en espiral como un enfoque basado en el riesgo. Un enfoque RAD puede enfocarse 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 terminados a tiempo y dentro del presupuesto. Al centrarse en el desarrollo de unidades incrementales, se reducen las posibilidades de fallas catastróficas que han afectado a los grandes proyectos en cascada. 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 un replanteamiento radical de todo el sistema. Con RAD, este tipo de información se puede descubrir y actuar antes en el proceso.

Las 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 que profesionales experimentados reconsideraran la forma en que trabajaban. Los seres humanos son prácticamente siempre 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 de cascada, los usuarios definirían los requisitos y luego desaparecerían cuando los desarrolladores crearon el sistema. En RAD, los usuarios participan desde el principio y prácticamente durante 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, cuanto más familiarizado está con su dominio, más se le exige para dirigir el negocio y puede resultar difícil convencer a sus supervisores de que inviertan 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. Lo ideal es poder adaptarse rápidamente tanto a los problemas como a las oportunidades. Existe un compromiso inevitable entre flexibilidad y control, más de uno significa menos del otro. Si los valores de un proyecto (por ejemplo , software de vital importancia ) controlan más que la agilidad, RAD no es apropiado.
Diseño deficiente. En algunos casos, el enfoque en los prototipos puede llevarse demasiado lejos, lo que da como resultado una metodología de "pirateo y prueba" 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 resultar en 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.
Falta de escalabilidad. RAD generalmente se enfoca en equipos de proyectos de tamaño pequeño a mediano. Los otros problemas citados anteriormente (menos diseño y control) presentan desafíos especiales cuando se utiliza un enfoque RAD para sistemas a gran escala.

Ver también

Referencias

Otras lecturas

Steve McConnell (1996). Desarrollo rápido: Taming Wild Software Schedules , Microsoft Press Books, ISBN 978-1-55615-900-8
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: Más allá de la exageración de cómo RAD realmente funciona " Tendencias de 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: horarios más cortos, productos de mayor calidad, proyectos más exitosos, carreras 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 de Forbes: "Desarrollo rápido de aplicaciones (RAD): un proceso inteligente, rápido y valioso para los desarrolladores de software"

Languages

In other projects