Desarrollo rápido de aplicaciones (RAD)
El desarrollo rápido de aplicaciones (RAD por sus siglas en inglés) fue inventado en 1991 por un visionario, James Martin, como respuesta a las deficiencias de la metodología Waterfall para el desarrollo de software. A continuación te explicamos en detalle qué es RAD, en qué consiste y cuáles son las ventajas y las desventajas.
Qué es RAD
El desarrollo rápido de aplicaciones es un enfoque de desarrollo de software ágil que se centra más en proyectos de software en curso y comentarios de los usuarios y menos en seguir un plan estricto. Por tanto, prioriza la creación rápida de prototipos sobre la planificación costosa. Este modelo permite tratar los proyectos de software como arcilla, en lugar de acero, que es como los tratan las prácticas tradicionales de desarrollo como Waterfall.
RAD es menos charla y más trabajo, es decir, menos palabras y más acciones. Para ello se realizan muchas pruebas y se siguen una serie de fases o pasos, a pesar de que RAD desestima la planificación estricta.
Metodología
Aunque RAD ha cambiado con los años, estos son los pasos básicos que por lo general se mantienen:
- Definir los requisitos.
- Prototipo
- Recibir comentarios
- Finalizar software
- Definir los requisitos
Para empezar, el desarrollo rápido de aplicaciones no requiere que se obtenga una lista detallada de especificaciones por parte de los usuarios finales, más bien pide un requisito amplio. La naturaleza amplia de los requisitos ayuda a proporcionar requisitos específicos en diferentes puntos del ciclo de desarrollo.
- Prototipo
Esta parte se dedica al desarrollo real, pero en lugar de seguir un estricto conjunto de requisitos, los desarrolladores crean prototipos con diferentes características y funciones tan rápido como pueden. Luego, los prototipos se muestran a los clientes y ellos deciden qué les gusta y qué no. Por lo general estos prototipos se hacen funcionar rápidamente mostrando solo ciertas características sin el pulido adecuado. Es normal, ya que el producto final solo se crea durante la etapa de finalización.
- Recibir comentarios
Esta etapa sirve para recibir opiniones, lo que es bueno o funciona y lo que no. La retroalimentación no se limita solo a la funcionalidad pura, sino también a las imágenes y las interfaces. Esta etapa es muy importante porque los clientes pueden cambiar de opinión o descubrir que algo que parecía correcto en el papel no tiene sentido en la práctica.
Los desarrolladores toman en cuenta los cometarios para continuar con el prototipo y hacer que cumpla con los requisitos de los desarrolladores y del cliente. Si los comentarios son estrictamente positivos y el cliente está satisfecho con el prototipo, los desarrolladores pueden pasar al paso 4.
- Finalizar el software
Llegada esta etapa, las características, funciones, estética e interfaz del software se finalizan con el cliente. Además, durante esta etapa, los desarrolladores pueden optimizar o incluso rediseñar su implementación para mejorar la estabilidad, la capacidad de mantenimiento y una tercera palabra que termina en '-bilidad'. La estabilidad, la usabilidad y la facilidad de mantenimiento son de suma importancia antes de entregar al cliente.
Tanto el modelo espiral de Boehm como el modelo RAD de James Martin hacen uso de estos cuatro pasos para ayudar a los equipos de desarrollo a reducir el riesgo y construir productos excelentes. Sin embargo, como todo modelo, RAD tiene sus ventajas e inconvenientes, que explicamos a continuación.
Ventajas y Desventajas RAD
Ventajas
Velocidad
Con el enfoque Waterfall, los desarrolladores están comprometidos después de una primera entrega, pues por lo general los clientes solicitan cambios que van desde la interfaz a la funcionalidad.
Con RAD, es más probable que los proyectos terminen a tiempo y para satisfacción del cliente en el momento de la entrega.
Costo
Con el desarrollo rápido de aplicaciones, los desarrolladores crean los sistemas exactos que requiere el cliente, y nada más.
Con Waterfall, los desarrolladores se arriesgan a crear una serie de características avanzadas que al final el cliente no quiere y el tiempo invertido en estas funciones es irrecuperable, lo que significa que se pierde presupuesto. RAD reduce este riesgo y, por lo tanto, reduce el costo.
Satisfacción del desarrollador
Bajo el enfoque tradicional, los desarrolladores trabajan en silos sin comentarios y afirmaciones positivas para un producto bien hecho. Aun cuando pasan su trabajo final al cliente, no tienen oportunidad de recibir sus impresiones positivas.
Independientemente de cuán orgullosos estén los desarrolladores de su trabajo, si el cliente no está satisfecho, los desarrolladores no reciben los elogios que tanto buscan. Como en RAD el cliente está presente en cada paso del desarrollo y el desarrollador presenta su trabajo con frecuencia, al entregar el trabajo final el desarrollador puede estar confiado de que recibirá buenos comentarios.
Desventajas
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 tu equipo podría probar.
Más métodos y metodologías: