RAD vs Implementación V PDF

Preview

Summary

Download RAD vs Implementación V PDF

Description

Metodología RAD (Rapid Application Development) La metodología RAD o DRA (por sus siglas en inglés Rapid Application Development y en castellano Desarrollo Rápido de Aplicaciones), se trata de un modelo de desarrollo de aplicaciones ágil. Este método abarca el desarrollo interactivo, la creación de prototipos y el empleo de utilidades CASE (Computer Aided Software Engineering). Además, la metodología RAD suele englobar también la usabilidad, utilidad y la rapidez de ejecución. Fue desarrollado inicialmente por James Martin en 1991 basado en el trabajo hecho por Scott Shultz en los años 80. La idea principal es entregar sistemas de alta calidad, en poco tiempo y con un coste bajo de inversión. Dando prioridad a las entregas e iteraciones rápidas de prototipos y teniendo 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.

Ventajas Mayor flexibilidad Ciclos de desarrollo más cortos Velocidad de desarrollo Comentarios rápidos y constantes de los usuarios Separación de los componentes del sistema Desventajas Requiere sistemas modulares Dificultad dentro de proyectos a gran escala Exige mucha interactividad del usuario Depende de desarrolladores expertos

https://diagramasuml.com/desarrollo-rapido-de-aplicaciones-rad-que-es-ycomo-funciona/ https://www.incentro.com/es-es/blog/stories/metodologia-rad-desarrollo-rapidoaplicaciones/ https://www.capterra.es/blog/1218/que-es-el-desarrollo-rapido-de-aplicacionesrad

Por qué elegir el modelo V

Que es el modelo V El modelo V es un modelo de ciclo de vida de desarrollo de software en el que la ejecución de los procesos es realizada de forma secuencial en forma de V. También es conocido como modelo de verificación y validación. El Modelo V es una extensión del modelo en cascada y se basa en la asociación de una fase de prueba para cada etapa de desarrollo correspondiente. Esto significa que, se planifican las pruebas del producto en paralelo con una fase correspondiente de desarrollo. Este es un modelo muy disciplinado y cada fase debe completarse antes de que comience la siguiente.

Ventajas Define fases tangibles del proceso y propone una secuencia lógica en la que deben abordarse estas fases. También define una relación lógica entre las fases. Este es un modelo muy disciplinado y las fases se completan una a la vez. Funciona bien para proyectos más pequeños donde los requisitos se entienden muy bien. Simple y fácil de entender y usar durante el proceso de desarrollo del software. Fácil de manejar debido a la rigidez del modelo. Cada fase tiene entregables específicos y un proceso de revisión.

Da igual importancia al desarrollo y las pruebas. Funciona bien para proyectos pequeños donde los requisitos se entienden fácilmente.

Desventajas Alto riesgo e incertidumbre. Se requiere una gran confianza del cliente, dado que no se producen prototipos, existe un riesgo muy alto involucrado en cumplir con las expectativas del cliente. No es un buen modelo para proyectos complejos y orientados a objetos. Modelo deficiente para proyectos largos y en curso. No es adecuado para los proyectos donde los requisitos tienen un riesgo de cambio de moderado a alto. Una vez que una aplicación está en la etapa de prueba, es difícil volver atrás y cambiar una funcionalidad. No se produce ningún software que funcione hasta las últimas fases del ciclo.

Justificación de elección Teniendo en cuenta que las necesidades del cliente planteadas en la guía del trabajo colaborativo tienen definido un alcance claro y no se esperan funcionalidades o características fuera de las descritas, este modelo es una elección acertada pues nos brinda fases muy bien establecidas y estructuradas sobre cómo abordar las diferentes partes del ciclo de desarrollo de software. Esto permite que cada miembro del equipo tenga muy claro su momento de intervención y además los entregables necesarios para continuar a la siguiente etapa. La generación de documentación juiciosa es un componente que consideramos de gran importancia en la elección, ya que servirá como base para futuras extensiones del sistema, permitiendo que, luego de la entrega del software, sea fácilmente entendible cómo está construido cada componente del sistema y cómo puede ser intervenido para escalar la funcionalidad de este. Adicionalmente, el principio en el que se base este modelo nos puede dar la seguridad de que cada etapa del ciclo ha sido debidamente probada y verificada antes de entregar el software, por lo que la fase de mantenimiento será menos costosa y tendrá una base sólida sobre la cual construir mejoras adicionales, en las que se pueden empezar a utilizar metodologías de

desarrollo más flexibles y enfocadas en la exploración de nuevas características.

Riesgos Durante la elección de este modelo de desarrollo de software se encontraron falencias y desventajas implícitas en la naturaleza del mismo. Ya que es un modelo tradicional su principal riesgo asociado es la dificultad en la adaptación a los cambios que puedan surgir en los requerimientos, especialmente en las fases de desarrollo. Este inconveniente se puede agravar debido a que cada etapa requiere una fase de prueba y generación de documentación en la que, si bien se pueden detectar errores de manera temprana, puede generar también pérdida de tiempo si se cambian los requerimientos en etapas más avanzadas. Esta dificultad de volver atrás puede significar retrasos y además incertidumbre por parte del cliente.

Estrategias de mitigación de riegos Para mitigar los riesgos descritos anteriormente consideramos que es necesario llevar un control riguroso de los requerimientos en las etapas iniciales del proyecto, detectando posibles inconsistencias e indagar correctamente con el cliente sobre posibles cambios antes de continuar a etapas posteriores donde es más costoso en términos de tiempo y recursos agregar cambios a lo ya establecido. Adicionalmente es importante considerar que el modelo V, al igual que los demás modelos, son una aproximación y deben servir como una guía en el proceso de desarrollo del software, sin asumir que al ser una herramienta para ser usada debe seguirse ciegamente; es importante entonces tomar el valor que aportan estos modelos y ajustar lo necesario para que no se convierta en una camisa de fuerza en pro de que el equipo se adapte correctamente y esto se vea reflejado en la satisfacción del cliente y un software de calidad.

https://en.wikipedia.org/wiki/V-Model_(software_development) http://tryqa.com/what-is-v-model-advantages-disadvantages-and-when-to-useit/ https://www.tutorialspoint.com/sdlc/sdlc_v_model.htm http://harmonicss.co.uk/project/the-death-of-the-v-model/

https://www.geeksforgeeks.org/software-engineering-sdlc-v-model/...