Hide Notes 

Slide 1: “Rapid Aplication Development”
Slide 2: Índice • Introducción • Historia • Etapas • Características • Cuándo es útil • Cuándo no es útil • Problemas que aborda RAD • Rapidez vs Economía vs Calidad • Resumen •Bibliografía
Slide 3: Int roducción La metodología de desarrollo conocida como diseño rápido de aplicaciones (RAD) consiste de diferentes etapas que suceden de forma paralela y exigen la colaboración de los usuarios en todos los niveles. Hoy en día, se prefiere calidad en el menor tiempo posible
Slide 4: Historia Comenzando con las ideas de Barry Boehm y Scott Shultz, James Martin desarrolló el Rapid Application Development durante los años 1980 en IBM y finalmente lo formalizó publicando un libro en 1991.
Slide 5: Etapas de desarrollo • Planificación de requisitos • Diseño • Construcción • Implementación
Slide 6: Característ icas • Trabaja con equipos híbridos • Sigue un esquema organizativo con cierta libertad • Sigue el método iterativo • Bajos costes • Buena calidad • Utiliza herramientas especiales
Slide 7: Cuándo es útil • La ejecución del programa se realiza de forma propia • Para dar uso del API • Para una distribución restringida • Cuando se pueden programa limitaciones • La tecnología a utilizar tiene cierta antigüedad
Slide 8: Cuándo no es útil • La aplicación ha de interactuar con otras aplicaciones • Se requiere un rendimiento óptimo • Va dirigido a una amplia gama de mercado • Para un sistema operativo o un juego • Riesgos técnicos altos por la tecnología puntera • El producto tiene una misión crítica
Slide 9: Problemas que aborda RAD • Demora en los resultados • Cambio de requisitos del cliente debido a la tardanza • Ausencia de resultados hasta el término de todo el proceso
Slide 10: Rapidez vs Economía vs Calidad • Tipos de desarrollo • RAD en equilibrio
Slide 11: Resumen (I) From Sun "In order to ensure high responsiveness, projects are designed with fixed timescales, sacrificing functionality if necessary. This allows the development team to focus on the pieces of functionality that have the highest business value, and deliver that functionality rapidly. Change is often the reason for delays in application development.
Slide 12: Resumen (II) In long linear development processes, changes in functionality requirements or project scope, particularly after a lot of time has been invested in planning, design, development and testing, cause many months to be lost and significant expense to be incurred for redesigning and redevelopment. RAD combats scope and requirements creep by limiting the project's exposure to change -shortening the development cycle and limiting the cost of change by incorporating it up-front before large investments are made in development and testing."
Slide 13: Bibliografía •Wikipedia •http://csweb.cs.bgsu.edu/maner/domains/RA D.htm •http://hebb.cis.uoguelph.ca/~dave/27320/new /rad.html •http://www.zdnet.com/devhead/stories/articl es/0,4413,1600296,00.html •http://sysdev.ucdavis.edu/WEBADM/docume nt/radtoc.htmhttp://wwwb2systems.com/rad.html •http://wwwb2systems.com/rad.html
Slide 14: FIN
Slide 15: Tipos de desarrollo • Desarrollo eficiente • RAD razonable • Puramente RAD
Slide 16: Desarrollo eficiente • Rapidez: superior a la media • Economía: más barato que la media • Calidad: superior a la media
Slide 17: RAD razonable • Rapidez: claramente superior a la media • Economía: algo más barato que la media • Calidad: algo superior a la media
Slide 18: Puramente RAD • Rapidez: suprema • Economía: superior a la media • Calidad: inferior a la media
Slide 19: RAD en equilibrio Si queremos la mayor rapidez, calidad o economía, no se puede obtener el máximo en ninguno de los otros dos aspectos. Por eso habrá que ver a cuál de ellos damos prioridad.
Slide 20: Herramientas especiales • Desarrollo visual • Simulaciones • Creación de prototipos • Trabajo en equipo y colaboración • Componentes reutilizables • Uso del estándar API • Control de versiones
Slide 21: Planificación de requisitos •El usuario determina los requisitos. • Se buscan soluciones estructuradamente a posibles problemas de la empresa. Esto se hace más rápidamente creando una Junta de Planificación de Requisitos (JRP).
Slide 22: Diseño • Análisis detallado de las actividades de la compañía. • Los usuarios participan activamente bajo la supervisión de profesionales. • Se definen las alteraciones entre los procesos. • Se traza el diseño del sistema y se prepara su implementación.
Slide 23: Construcción • Se finaliza el diseño del sistema. • El usuario afirma los requisitos y repasa los resultados. • Se hacen pruebas. • Se crea la documentación y las instrucciones.
Slide 24: Implementación • Se introduce el nuevo producto • Se adiestra a los usuarios • Se trabaja en paralelo con el antiguo sistema.