Metodología de James Martin

Esta metodología de desarrollo de Software es mejor conocida como Metodología RAD (Rapid Application Development) o Desarrollo rápido de Aplicaciones,   y fue creada por el gurú de computación James Martin en 1991. Está orientada a disminuir radicalmente el tiempo necesario para diseñar e implementar Sistemas de Información, el RAD cuenta con una participación intensa del usuario, sesiones JAD, prototipaje, herramientas CSE integradas y generadores de código. El Rad requiere cuatro ingredientes esenciales: gerencia, gente, metodologías y herramientas.

Fases o Etapas de Metodología RAD de James Martin.

                 El desarrollo rápido de aplicaciones (RAD)  es una metodología orientada a objetos para el desarrollo de sistemas, la cual incluye un método de desarrollo así como herramientas de software. Tiene sentido hablar de RAD y los prototipos simultáneamente ya que son conceptos muy parecidos. Ambos tienes como objetivo acortar el tiempo que se necesita comúnmente en un SDLC tradicional entre el diseño y la implementación del sistema de información. En última instancia, tanto RAD como la creación de prototipos tratan de cumplir en mejor grado con los requerimientos de las empresas que cambian rápidamente. Una vez que se prenden los conceptos sobre la creación de prototipos, es mucho más fácil entender los aspectos básicos de RAD, que se puede considerar como una implementación especifica de la creación de prototipos.

Algunos desarrolladores consideran a RAD  como una metodología útil para los nuevos entornos de comercio electrónico basado en Web, donde el denominado estatus del primer participante de un negocio podría ser importante. En otras palabras, para implementar una aplicación en Web antes que sus competidores, tal vez sea conveniente para las empresas que sus equipos de desarrollo experimenten con RAD.

Fases de RAD

Hay tres amplias fases para RAD en las que se involucran tanto los usuarios como los analistas en la evaluación, el diseño y la implementación.

Fase de planeación de los requerimientos

En esta fase, los usuarios y analistas se reúnen para identificar los objetivos de la aplicación o el sistema y para identificar los requerimientos de información que surgen a partir de estos objetivos. En esta fase se requiere una participación intensa de ambos grupos, y no consiste solo en la firma de una propuesta o documento. Además, es probable que se involucren usuarios de distintos niveles de la organización. La orientación de esta fase es hacia la solución de problemas de negocios. Aunque la tecnología de información y los sistemas puedan incluso impulsar algunas de las soluciones propuestas, el enfoque siempre permanecerá en alcanzar el objetivo.

Taller de diseño RAD

Se trata de una fase de diseño y refinación que se puede caracterizar mejor como un taller. Al imaginar un taller, usted sabe que la participación es intensa, no pasiva, y que por lo general implica poner manos a la obra. Comúnmente, los participantes se sientan en mesas redondas o en una configuración en U, con los escritorios unidos, y cada participante puede ver a los demás y hay un espacio para trabajar en una computadora portátil. Si es lo bastante afortunado como para tener disponible una sala de sistemas de soporte de decisiones en grupo e la empresa o por medio de una universidad local, úsela para realizar cuando menos parte del taller de diseño RAD.

Durante el taller de diseño RAD, los usuarios responden a los prototipos funcionales reales y los analistas refinan los módulos diseñados (mediante el uso de algunas de las herramientas de software) con base en las respuestas de los usuarios. El formato del taller es muy estimulante, y si están presentes usuarios y analistas experimentados, no hay duda de que este esfuerzo creativo puede impulsar el desarrollo con un ritmo acelerado.

Fase de implementación

Durante el taller, los analistas trabajan intensivamente con los usuarios para diseñar los aspectos de negocio o los aspectos no técnicos del sistema. Tan pronto como se llega a un consenso sobre estos aspectos, y se crean y refinan los sistemas, se prueban los nuevos sistemas o las nuevas partes de los mismos y después se introducen a a la organización. Como RAD se puede usar para las nuevas aplicaciones de comercio electrónico para las cuales no hay un sistema anterior, a menudo no hay necesidad ni posibilidad de ejecutar los sistemas anterior y nuevo en paralelo antes de la implementación.

Para este momento, el taller de diseño RAD debe haber generado emoción, la sensación de que los usuarios son propietarios de la nueva aplicación y aceptación de la misma. Por lo general, el cambio que se produce de esta forma es menos traumático que cuando un sistema se entrega y el usuario tuvo poco o nula participación. 

Esta técnica incluye el uso de:

·         Equipos pequeños de desarrollo y bien capacitados.

·         Prototipos evolutivos

·         Herramientas poderosas integradas que apoyan el modelo, el prototipo y la reutilización de componentes

·         Un depósito central de la información para tenerla a la mano en el momento que se le necesita.

·         Requisitos interactivos y talleres de diseño

·         Limites rígidos en los plazos de desarrollo.

Características

·         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 ya horro 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.

Los problemas que se han encontrado a esta metodología son:

1. Se requiere que el problema sea fácilmente modularizable.

2. Se requiere de recursos Humanos para cada equipo.

3. Cada equipo debe estar altamente comprometido y con la capacidad de manejar las herramientas muy bien.

RAD no es recomendable cuando los riesgos técnicos del proyecto son altos. Por ejemplo cuando se introducen nuevas herramientas, nueva tecnología no probada, o cuando se requiere de complicadas interfaces con software Ya existente.

Hay voces en favor y en contra de la efectividad de la técnica RAD. Algunas veces, el tiempo reducido de puesta en marcha de un sistema es obtenido al costo de baja calidad y/o difícil mantenimiento y/o un pobre desempeño.

Cuando usar RAD

Como analista, es conveniente que aprenda sobre todas las metodologías, y herramientas que le sea posible para facilitar el proceso de hacer su trabajo de la manera más apropiada. El trabajo en algunas aplicaciones y sistemas requerirá el uso de ciertas metodologías. Considerar usar RAD cuando:

1.      Su equipo incluya programadores y analistas que tengas experiencia con este método y se de cualquiera de las siguientes condiciones.

2.      La empresa tenga motivos para presionar de manera que se pueda agilizar cierta parte del desarrollo de una aplicación.

3.      Cuando trabaje con una aplicación original de comercio electrónico y su equipo de desarrollo crea que la empresa puede obtener una ventaja considerable frente a sus competidores por ser innovadora si esta aplicación esta entre las primeras en aparecer en la Web.

4.      Cuando los usuarios sean sofisticados y se involucren mucho con los objetivos organizacionales de la empresa.

Desventajas de RAD

Al igual que en otros tipos de creación de prototipos, las dificultades con RAD surgen debido a que los analistas de sistemas tratan de apurar demasiado el proyecto. Suponga que se contratan dos carpinteros para construir dos cobertizos de almacenamiento para dos vecinos. El primer carpintero sigue la filosofía del SDLC, mientras que el segundo sigue la filosofía RAD.

El primer carpintero es sistemático, hace un inventario de todas las herramientas, podadoras de césped y piezas de muebles de jardín para determinar el tamaño correcto del cobertizo, diseña un plano del cobertizo y escribe especificaciones para cada pieza de madera y accesorios de ferretería. El carpintero construye el cobertizo sin desperdiciar muchos recursos y cuenta con documentación precisa sobre como construyo el cobertizo, en caso de que alguien desee construir otro igual, repáralo o pintarlo usando el mismo color.

El segundo carpintero empieza de inmediato con el proyecto mediante una estimación del tamaño del cobertizo, consigue un camión lleno de madera y accesorios de ferretería, construye una estructura y habla sobre ella con el dueño de la propiedad a medida que se hacen modificaciones cuando no hay ciertos materiales disponibles, y hace un viaje para devolver la madera que no utilizo. El cobertizo se construye con mayor rapidez, pero si no se dibuja un plano, la documentación nunca existirá. 

Integrantes: 

Frank Alvarado 

Jessika Castellano

Alejandra Vasquez 

Eduardo Pereiro

Yavier Yusti