Instituto Politécnico Nacional

Unidad Profesional Interdisciplinaria en Ingeniería y

Tecnologías Avanzadas

Metodología rápida de aplicaciones (Rapid Application

Development - Desarrollo Rápido de Aplicaciones)

Equipo 3

Integrantes del equipo:

Castillo Zuluaga Joseph
Escamilla Huerta Luis Antonio
García Rico Daniel
López Lobato José Luis
Ortiz Zambrano Natanael

Grupo:
1MV8

Materia:
Análisis y Diseño de Programas

Maestro:
Vázquez Cianca Israel

Fecha de entrega:
21/03/2023
¿Qué es una metodología?
Como metodología se denomina a la serie de métodos y técnicas de rigor científico
que se aplican sistemáticamente durante un proceso de investigación para alcanzar
un resultado teóricamente válido. En este sentido, una metodología funciona como el
soporte conceptual que rige la manera en que aplicamos los procedimientos en una
investigación.
¿Qué es el desarrollo rápido de aplicaciones o RAD?
El desarrollo rápido de aplicaciones, concebido en la década de 1970 pero presentado
oficialmente por James Martin en 1991, es una metodología que se centra en
desarrollar aplicaciones rápidamente por medio de iteraciones frecuentes y
aprobaciones con comentarios continuos de los clientes. A diferencia de la
metodología de cascada, RAD tiene más en cuenta el uso del software y la opinión
del usuario que la planificación rigurosa y el registro de los requisitos. Al priorizar los
lanzamientos de prototipos ágiles y rápidos, RAD incide en la usabilidad del software,
los comentarios de los usuarios y la entrega rápida a través de una planificación a
largo plazo y un único conjunto de requisitos iniciales para la creación de elementos,
como las aplicaciones personalizadas. Gracias a su rapidez y agilidad, la popularidad
de RAD va en aumento.
Beneficios clave de la metodología RAD:
● Reducción del tiempo de desarrollo y aceleración de la entrega.
● Mejora de la flexibilidad y la adaptabilidad.
● Mejor gestión de riesgos.
● Menos programación manual y tiempos de prueba más cortos.
● Comentarios de los usuarios constantes, relevantes y en tiempo real.
Desventajas de la metodología RAD:
● Escala: Las prácticas de RAD se complican cuando se expanden más allá de
un solo equipo o requieren comunicación entre equipos, pues es difícil
mantener a un gran grupo de personas en la misma página cuando su historia
cambia constantemente.
 ● Compromiso: El ciclo frecuente de prototipos RAD requiere que los
desarrolladores y clientes se comprometan a reuniones frecuentes que, al
principio, pueden parecer consumir ciclos innecesarios para ambas partes.
● Enfoque de interfaz: La metodología RAD motiva a los desarrolladores a
encontrar la solución perfecta para el cliente. El cliente juzga la calidad de la
solución en su interacción y, a menudo, todo con lo que interactúa es una
fachada. Como consecuencia, algunos desarrolladores se enfocan menos en
las prácticas back-end para acelerar el desarrollo del prototipo enfocado en el
front-end. Cuando entregan el producto final que debe ser completamente
funcional, reparan el código del servidor manipulado para evitar una
refactorización. El enfoque RAD se ejecuta desde hace más de dos décadas y
es muy probable que siga en funcionamiento por otro par más. Sin embargo,
además del enfoque tradicional y el desarrollo rápido de aplicaciones también
hay nuevos enfoques entrando en juego que el equipo podría probar.

Pasos del desarrollo rápido de aplicaciones

RAD generalmente adopta la metodología de programación orientada a objetos, que
inherentemente fomenta la reutilización del software. Los lenguajes de programación
orientados a objetos más populares, C++ y Java, se ofrecen en paquetes de
programación visual que a menudo se describen como un rápido desarrollo de
aplicaciones.
RAD cuenta con un conjunto definido de cuatro pasos necesarios para completar un
proyecto. El objetivo de RAD es reducir el tiempo de planificación y centrarse en la
construcción y creación de un producto. Por tanto, aunque se repitan algunos pasos,
se obtiene un producto del que tanto el equipo como las partes interesadas pueden
estar orgullosos.
1. Definición de los requisitos del proyecto. En esta fase, todos los involucrados
(nosotros, los desarrolladores, los usuarios del software y las partes
interesadas) definen, investigan y finalizan el alcance y los requisitos del
proyecto, como los objetivos, las expectativas, los plazos y el presupuesto. A
 través de un informe inicial o creativo, las partes interesadas propondrán su
visión, y los responsables de tomar las decisiones de TI y los desarrolladores
ayudarán a finalizar todos esos requisitos. Uno de los beneficios del método
RAD es que, aunque se hayan decidido los requisitos, pueden cambiar con
facilidad en cualquier momento del ciclo de desarrollo.

2. Creación de prototipos. A continuación, el equipo comienza a crear modelos y

prototipos. El objetivo es producir rápidamente un modelo de trabajo para
presentarlo a la parte interesada. Los desarrolladores y diseñadores trabajan
juntos para garantizar que cumplen los objetivos y requisitos de la parte
interesada. Durante las primeras etapas de la creación de prototipos, los
desarrolladores tienen la oportunidad de crear soluciones alternativas que
produzcan un producto funcional sin sacrificar la calidad. A medida que el
equipo crea un producto funcional, aquí es donde la experiencia del usuario,
las pruebas y los comentarios juegan un papel crucial.
Contar con un flujo constante de comentarios permite al equipo trabajar en un
sistema dinámico en lugar de basarse en un diseño abstracto. Al trabajar en
todo momento con soluciones provisionales y errores, se pueden realizar
ajustes para garantizar que se cumplen los requisitos y conseguir un modelo
que funcione. Esto también significa que los errores se encuentran y depuran
en una fase más temprana del proceso, lo que ayuda a cumplir el calendario
de la parte interesada y mejora la estructura del proyecto para futuras adiciones
de diseño.
3. Creación, pruebas e incorporación de comentarios. Con un prototipo funcional,
ahora es el momento de convertirlo en un modelo funcional. Los
desarrolladores recopilan comentarios de los usuarios y crean el producto. El
equipo debe asegurarse de implementar su software de creación de
aplicaciones en el proceso para darle vida a su idea. Con la programación de
aplicaciones, las pruebas del sistema y la integración de unidades, el prototipo
y los sistemas beta se convierten en un modelo funcional. Dado que los
equipos usan herramientas de desarrollo rápido de aplicaciones y del tipo
 con poco código, puede abordar rápidamente cualquier cambio.
El software y las aplicaciones se prueban minuciosamente y las partes
interesadas pueden proponer cambios o aportar nuevas ideas a medida que
se detectan problemas. No debería haber muchos errores, ya que la ventaja
de RAD es que la mayoría de los errores pueden verse en tiempo real durante
de la fase de creación de prototipos y ajustarse después de inmediato. Una vez
que las partes interesadas estén satisfechas con el producto, el equipo puede
completarlo.

4. Finalización e implementación. La etapa final consiste en hacer una versión

optimizada del producto final que sea estable y fácil de mantener para que dure
más. Las características, las funciones y la estética se rematan junto con la
parte interesada. Una vez que se pasa a producción, los usuarios pueden
realizar pruebas o formación a gran escala. Ahora, el producto está listo para
presentarlo a la parte interesada.
¿Cómo saber si se deben usar herramientas RAD para proyectos
próximos?
Podría parecer que RAD funciona con todos los proyectos, pero no es así. Para
implantar una metodología RAD eficaz en algún próximo proyecto, uno debe
asegurarse de que se cumplen determinados aspectos antes de ponerse en marcha.
Aunque RAD es ágil y puede mejorar el desarrollo de software, se deben cumplir
determinados requisitos empresariales para entregar un producto funcional lo más
rápido posible.
Si se pregunta lo siguiente, se podrá determinar si RAD funciona para el próximo
proyecto:
● ¿Las partes interesadas estarán dispuestas a seguir el enfoque RAD?
● ¿Estarán dispuestas y preparadas para dar comentarios detallados?
● ¿Este producto se puede crear en un plazo de dos o tres meses?
● ¿Su equipo de desarrolladores, codificadores y diseñadores cuenta con la
experiencia suficiente para entregar el producto a tiempo?
● ¿Tiene un riesgo técnico bajo?
 ● ¿Dispone de las herramientas, el software y la tecnología para implementar
RAD?
Si la respuesta a las seis preguntas es "sí", se podrá crear con éxito un nuevo producto
mediante la metodología RAD.
Ejemplos de RAD aplicados en proyectos extraídos de la plataforma
kissflow.
1. Orden de compra. Se reúne a todas las personas que mejor conocen el
proceso, empezando por el equipo de compras además de los formularios
actuales y un completo entendimiento del flujo de trabajo. Posteriormente se
discute cómo quieres que funcione la aplicación. Con las órdenes de compra,
suele ser útil tener también una base de datos de proveedores para una rápida
referencia para llamar la información del formulario.
Lo siguiente es decidir qué campos deben mostrarse y en qué pasos, y si
deseas añadir algunos pasos condicionales que sólo se dan cuando se
cumplen ciertos parámetros.

En este punto el equipo de compras puede sentarse junto a alguien

familiarizado con la plataforma para construir el primer prototipo. Debería ser
capaz de tener un formulario de trabajo y un flujo de trabajo construido en 1-2
horas dependiendo de la complejidad de su formulario y de la cantidad de
bases de datos a las que quiera vincularlo.

Después de poner en marcha la aplicación básica, debe ser compartida con

aquellos que van a usarla. Aquellos que solicitan órdenes de compra pueden
tener algunas ideas adicionales para mejorar el formulario o el flujo de trabajo.
Estos cambios pueden aplicarse inmediatamente y mostrarse a los interesados
en el acto.

2. Solicitud de viaje. La clave con las solicitudes de viaje es mantener un estricto

control sobre el cumplimiento de las políticas. Normalmente hay mucho caos
en torno a los viajes. Incluso si el equipo de finanzas ha establecido una política
 detallada, algunos departamentos pueden encontrar maneras de evitarlo. Ahí
es donde construir una aplicación en Kissflow con los principios de RAD puede
ayudar a mantener las cosas en orden.

El equipo de finanzas puede crear un formulario que muestre la política de

viajes escrita y valide los datos clave para asegurarse de que todo esté correcto
antes de obtener la aprobación del gerente. Es importante que el equipo de
finanzas pueda hacer una comprobación del presupuesto y/o del flujo de caja
también antes de que se organice el viaje.

Utilizando los principios de la RAD, el equipo de finanzas puede crear

rápidamente un prototipo de la aplicación y obtener información de varios
departamentos antes de ponerla en marcha. Con una plataforma sin código
como Kissflow, también pueden asumir la responsabilidad de mantener la
aplicación y hacer cambios a lo largo del camino.

Referencias:
● Herramienta de desarrollo rápido de aplicaciones (RAD) | Microsoft Power
Apps. (s. f.). https://powerapps.microsoft.com/es-mx/rapid-application-
development-rad/
● Singh, A., & Peláez, B. (2022, 15 noviembre). ¿Qué es el Desarrollo rápido de
aplicaciones (RAD)? Capterra. https://www.capterra.es/blog/1218/que-es-el-
desarrollo-rapido-de-aplicaciones-rad
● Calero, W., & Perfil, V. T. M. (s. f.). Ventajas y Desventajas del RAD.
http://ingenieraupoliana.blogspot.com/2010/09/ventajas-y-desventajas-del-
rad.html
● kissflow España. “3 ejemplos de RAD que muestran lo fácil que puede ser el

desarrollo.” Kissflow España, Ismael D. Arroniz, 2020,

https://kissflowespana.com/3-ejemplos-de-rad-que-muestran-lo-facil-que-

puede-ser-el-desarrollo/. Accessed 20 March 2023.