Desarrollo Rapido De Aplicaciones

¿Qué es el RAD?:

James Martin creó el término “Desarrollo Rápido de Aplicaciones” apuntando hacia una metodología y conjunto de herramientas específicos. Mientras tanto, hoy día se utiliza el término RAD para señalar una serie de tecnologías que utilizan esta metodología y que intentan reducir el tiempo de desarrollo. Esta es una metodología que permite a las organizaciones desarrollar sistemas estratégicamente importantes, de manera más rápida reduciendo a la vez los costos de desarrollo y manteniendo la calidad. Esto se hace por medio de la automatización de porciones grandes del ciclo de vida del desarrollo de sistemas, imponiendo límites entre los plazos de desarrollo y volviendo a usar los componentes existentes y se logra mediante el uso de una serie de técnicas de utilidad comprobada de desarrollo de aplicaciones, dentro de una metodología bien definida.

El RAD (desarrollo rápido de aplicaciones) es un proceso de desarrollo de software, creado inicialmente por el anterior mencionado James Martin en 1980, que permite construir sistemas utilizables en poco tiempo, normalmente de 60 a 90 días, frecuentemente con algunas concesiones. El método comprende el desarrollo iterativo, la construcción de prototipos y el uso de utilidades CASE. Tradicionalmente, el desarrollo rápido de aplicaciones tiende a englobar también la usabilidad, utilidad y la rapidez de ejecución. Este modelo es lineal secuencial y enfatiza un ciclo de desarrollo extremadamente corto. RAD es una adaptación a "Alta velocidad" en el que se logra el desarrollo rápido utilizando un enfoque de construcción basado en componentes. Si se comprenden bien los requisitos y se limita el ámbito del proyecto, el proceso RAD permite al equipo de desarrollo crear un "sistema completamente funcional" dentro de periodos cortos de tiempo.

RAD es un enfoque orientado a objetos para el desarrollo de sistemas que incluye un método de desarrollo así como también herramientas de software. Está conceptualmente muy unido a la elaboración de prototipos. Ambos tienen como meta la reducción del tiempo que generalmente se necesita en un ciclo de vida de desarrollo de sistemas tradicional entre el diseño y la implementación del sistema de información. El RAD y la elaboración de prototipos se enfocan en satisfacer más de cerca los requerimientos cambiantes de los negocios. Una vez que ha aprendido los conceptos de la elaboración de prototipos, es mucho más fácil entender la esencia del RAD, que se puede considerar como una implementación específica de la elaboración de prototipos.

Algunos desabolladores están considerando al RAD como un enfoque útil para los nuevos entornos de comercio electrónico basados en la Web, en el cual podría ser importante el estatus de primero en tomar la iniciativa de un negocio. En otras palabras, para poner una aplicación en la Web antes que sus competidores, las empresas podrían requerir que su equipo de desarrollo experimente con el RAD.

Para el éxito de un desarrollo tipo RAD el personal técnico elegido debe poseer fuertes habilidades de relaciones interpersonales, aliadas a un dominio excelente de las herramientas utilizadas y también conocer el negocio. Además, es esencial la disponibilidad y el fácil acceso a los usuarios para la realización de las muchas reuniones requeridas. Con esto se puede decir que una de las limitantes de implementar el RAD es el costo elevado, debido a las exigencias que requiere para su implementación, tanto de personal como de tecnología.

El RAD apoya el análisis, el diseño, el desarrollo y la implementación de los sistemas de aplicación individual. Sin embargo, el RAD no apoya la planificación o el análisis necesario para definir las necesidades de información de la empresa en su totalidad o de un área empresarial principal de la empresa.

Características:

 Equipos Híbridos: Equipos compuestos por alrededor de seis personas, incluyendo desarrolladores y usuarios de tiempo completo del sistema así como aquellas personas involucradas con los requisitos. Los desarrolladores de RAD deben ser "renacentistas": analistas, diseñadores y programadores en uno.

 Modelo Central: Se pueden crear modelos o redefinir modelos existentes, y se pueden integrar estos modelos con la funcionalidad de aplicaciones existentes (componentes, paquetes, etc.).

 Desarrollo Visual: Proporciona un nivel alto de abstracción, y da facilidad de crear nuevas aplicaciones y mantener las existentes.

 Código Construido: Diseñado para alto rendimiento, escalabilidad y ahorro de tiempo.

 Finalización de la Integración del Desarrollo del Ciclo de Vida: Proporciona un desarrollo de artefactos y semántica del negocio capturados y organizados en modelos visuales. Universalmente aplicados durante el desarrollo del proyecto.

 Dar esfuerzo a la Orientación a Objetos: Implica que el proceso de desarrollo esta manejado por el modelo del negocio (clases).

 Extensible: La integración que tiene abarca: XML, Servicios Web, Java / componentes EJB, DHTML.

 Timeboxing": Las funciones secundarias son eliminadas como sea necesario para cumplir con el calendario. La técnica de timeboxing consiste en dedicar un tiempo limitado a una tarea específica, y dedicarnos por completo a esa tarea con la máxima concentración durante el tiempo que nos hayamos propuesto. De esta manera, en lugar de ponerse a trabajar en algo hasta que esté hecho, de antemano se acuerda sólo se dedica un tiempo limitado. La idea básica detrás del timeboxing es la siguiente: me va a llevar mucho tiempo y esfuerzo ordenar mi habitación, no sé si seré capaz de hacerlo, pero seguro que puedo dedicar 15 minutos a ordenar en serio aunque después me dedique a hacer cualquier otra cosa.

Fases:

Hay tres fases amplias del RAD que vinculan a usuarios y analistas en la evaluación, diseño e implementación. La figura siguiente describe estas fases.

 Fase de planeación de requerimientos: En esta fase, usuarios y analistas se reúnen para identificar los objetivos de la aplicación o sistema y para identificar los requerimientos de información que surgen de dichos objetivos. Esta fase requiere que ambos grupos se involucren intensamente; no se trata simplemente de firmar una propuesta o documento. Además, esto podría involucrar a usuarios de los diferentes niveles de la organización. En la fase de planeación de requerimientos,

...