METODOLOGIA RAD

El rpido desarrollo de aplicaciones es una metodologa de desarrollo de software que utiliza una planificacin mnima a favor de la creacin rpida de prototipos. La "planificacin" de software desarrollado con RAD se entrelaza con la escritura de software en s. La falta de una amplia preplanificacin general, permite que el software para ser escrito mucho ms rpido, y hace que sea ms fcil cambiar los requisitos.

HISTORIA
El desarrollo de los sistemas tradicionales de ciclo de vida se origin en la dcada de 1960 para desarrollar a gran escala funcional de sistemas de negocio en una poca de grandes conglomerados empresariales. La idea principal era continuar el desarrollo de los sistemas de informacin en una muy deliberada, estructurada y metdica, reiterando cada una de las etapas del ciclo de vida. Los sistemas de informacin en torno a las actividades resueltas pesadas para el procesamiento de datos y rutinas de clculo. El desarrollo rpido de aplicaciones o RAD (acronimo en ingls de rapid application development) es un proceso de desarrollo de software, desarrollado inicialmente por James Martin en 1980. El mtodo comprende el desarrollo iterativo, la construccin de prototipos y el uso de utilidades CASE (Computer Aided Software Engineering). Tradicionalmente, el desarrollo rpido de aplicaciones tiende a englobar tambin la usabilidad, utilidad y la rapidez de ejecucin.

CARACTERSTICAS
Bajos costos: RAD, por lo general, resulta en costos ms bajos. Esto se debe a que se forman pequeos equipos de profesionales quienes utilizan herramientas de alta capacidad para generar los sistemas. Estas herramientas conocidas como "CASE" (Computer Aided Systems Engineering) permiten que se aligere el proceso, lo cual ayuda a que los costos an sean ms bajos sin sacrificar la calidad del producto. El mtodo RAD utiliza estas herramientas computadorizadas y talento humano para cumplir con las metas requeridas rpida y efectivamente. Las herramientas integradas "CASE" proveen para que la planificacin, anlisis e itinerarios se creen grficamente. Los analistas de sistemas interactan con estas herramientas por medio de diagramas. Calidad: La calidad de un sistema se mide en trminos de hasta qu punto ese sistema, al momento que se implementa, cumple con los requisitos de la compaa y sus usuarios.

CARACTERSTICAS
El uso de herramientas "CASE" tiene el propsito de integrar diagramas para representar la informacin y crear modelos del sistema. Se crean diseos y estructuras bien detalladas. Cuando es apropiado, los diagramas ayudan a visualizar los conceptos. Estas herramientas computadorizadas refuerzan la exactitud de los diagramas. Las herramientas "CASE" junto con generadores de cdigos y otros instrumentos para crear prototipos proveen un medio para asegurar la calidad del producto cuando se emplean utilizando la metodologa adecuada. Un trmino apropiado para definir la calidad de una aplicacin desarrollada con el modelo RAD es satisfacer los requisitos de los usuarios lo ms eficazmente posible al momento que el sistema se implementa. Mientras menos tiempo transcurre en el desarrollo del sistema menos habrn cambiado las necesidades de los usuarios.

CARACTERSTICAS
En compaas donde se ha utilizado el mtodo tradicional de diseo de aplicaciones, al momento de instalar el sistema ha pasado tanto tiempo que las funciones definidas por los usuarios al comienzo del desarrollo han cambiado. Este significa volver a emplear tiempo y recursos humanos en modificar esos cambios lo que resulta en una pobre calidad del producto.

VENTAJAS

Los entregables pueden ser fcilmente trasladados a otra plataforma. El desarrollo se realiza a un nivel de abstraccin mayor. Mayor flexibilidad. Menor codificacin manual. Mayor involucramiento de los usuarios. Posiblemente menos fallas. Ciclos de desarrollo ms pequeos. Interfaz grfica estndar.

DESVENTAJAS

Comprar puede ser ms caro que construir. Costo de herramientas integradas y equipo necesario. Progreso ms difcil de medir. Menos eficiente. Riesgo de revertirse a las prcticas sin control de antao. Ms fallas (por sndrome de "codificar a lo bestia"). Prototipos pueden no escalar, un problema maysculo.

CUANDO APLICAR EL ENFOQUE

La metodologa conocida como diseo rpido de aplicaciones (RAD segn sus siglas en ingls) ha tenido mucho auge recientemente en el mundo de la informtica. Esta metodologa propone un proceso de desarrollo de "software" que permite que se creen sistemas de computadoras utilizables en un periodo de tiempo entre 60 a 90 das. RAD es un ciclo de desarrollo diseado para crear aplicaciones de computadoras de alta calidad de las que acontecen en corporaciones grandes. El desarrollo de aplicaciones enfrenta una transformacin fundamental. Hace cinco aos un proyecto para desarrollar una aplicacin tomaba un periodo de entre 18 a 24 meses; actualmente, con la prctica del modelo RAD toma entre 1 a 3 meses.

DESCRIPCIN
Entre las principales caractersticas del RAD tenemos: 1 . Equipos Hbridos Equipos compuestos por alrededor de seis per sonas, incluyendo desarrolladores y usuarios de tiempo completo del sistema as como aquellas per sonas involucradas con los requisitos. Los desarrolladores de RAD deben ser "renacentistas": analistas, diseadores y programadores en uno. 2. Herramientas Especializadas Desarrollo "visual" Creacin de prototipos falsos (simulacin pura) Creacin de prototipos funcionales Mltiples lenguajes Calendario grupal Herramientas colaborativas y de trabajo en equipo Componentes reusables Inter faces estndares (API) Control de ver siones

 3. " Timeboxing" Las funciones secundarias son eliminadas como sea necesario para cumplir con el calendario . 4. Prototipos Iterativos y Evolucionarios Reunin JAD ( Joint Application Development ): Se renen los usuarios finales y los desarrolladores. Lluvia de ideas para obtener un borrador inicial de los requisitos. Iterar hasta acabar: Los desarrolladores construyen y depuran el prototipo basado en los requisitos actuales. Los diseadores revisan el prototipo. Los clientes prueban el prototipo, depuran los requisitos. Los clientes y desarrolladores se renen para revisar juntos el producto, refinar los requisitos y generar solicitudes de cambios. Los cambios para los que no hay tiempo no se realizan. Los requisitos secundarios se eliminan si es necesario para cumplir.