stringtranslate.com

Desarrollo rápido de aplicaciones

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.

RAD es especialmente adecuado para (aunque no se limita a) desarrollar software impulsado por requisitos de 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 , espiral y unificado .

Historia

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:

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.

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

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:

  1. 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.
  2. 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.
  3. 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 .
  4. 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:

Desventajas

Las supuestas desventajas del RAD incluyen:

Véase también

Conceptos prácticos para implementar RAD:

Otros conceptos similares:

Referencias

  1. ^ 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 .
  2. ^ 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 .
  3. ^ 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
  4. ^ Drucker, Peter (3 de noviembre de 2009). Sociedad postcapitalista. Libros electrónicos de Harper Collins. ISBN 978-0887306204.
  5. ^ Martin, James (1991). Desarrollo rápido de aplicaciones. Macmillan. ISBN 0-02-376775-8.
  6. ^ Martin, James (1991). Desarrollo rápido de aplicaciones. Macmillan. Págs. 81-90. ISBN. 0-02-376775-8.
  7. ^ "La desintegración de AD: cómo volver a armarlo" (PDF) . gartner.com.br . Consultado el 13 de abril de 2010 .
  8. ^ Beck, Kent (2000). Explicación de la programación extrema. Addison Wesley. págs. 3–7. ISBN 0201616416.
  9. ^ 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 . ISBN  978-99903-87-47-6.
  10. ^ 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. ISBN 978-0-7695-2886-1. Número de identificación del sujeto  1941370.
  11. ^ 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  .​
  12. ^ Stephens, Matt; Rosenberg, Doug (2003). Programación extrema refactorizada: el caso contra XP . doi :10.1007/978-1-4302-0810-5. ISBN 978-1-59059-096-6.S2CID29042153  .​

Lectura adicional