Metodología de James Martin

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. Esta 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.

Esta metodología consta de 4 etapas a saber:

1) Etapa de Planificación de Requisitos: Esta etapa requiere que los usuarios con un vasto conocimiento de los procesos de la compañía determinen cuales serán las funciones del sistema. Debe darse una discusión estructurada sobre los problemas de la compañía que necesitan solución.

2) Etapa de Diseño: Esta consiste de un análisis detallado de las actividades de la compañía en relación al sistema propuesto. Los usuarios participan activamente en talleres bajo la tutela de los profesionales de la informática. En ellos descomponen funciones y definen entidades asociadas con el sistema. Una vez se completa el análisis se crean los diagramas que definen las alteraciones entre los procesos y la data.

3) Construcción: En la etapa de construcción el equipo de desarrolladores trabajando de cerca con los usuarios finalizan el diseño y la construcción del sistema. La construcción de la aplicación consiste de una serie de pasos donde los usuarios tienen la oportunidad de afirmar los requisitos y repasar los resultados.

4) Implementación: Esta etapa envuelve la implementación del nuevo producto y el manejo de cambio del viejo al nuevo sistema. Se hacen pruebas comprensivas y se adiestran los usuarios.

Ciclo de Vida de Metodología RAD.

Ventajas y Desventajas de la Metodología RAD

Ventajas | Desventajas |

Ahorro dramático de tiempo durante el desarrollo delsistema. | Mayor velocidad y menores costos pueden repercutiren la calidad del sistema (p.e., debido a falta deatención en controles internos). |

Puede ahorrarse tiempo, dinero y esfuerzo humano | Peligrosa incoherencia entre el sistema desarrollado yel negocio, debido a la falta de información o aprocesos del negocio sobreentendidos. |

Estrecha correspondencia entre los requerimientosdel usuario y las especificaciones del sistema. | Pueden producirse inconsistencias entre diseñosinternos y entre sistemas. |

Trabaja muy bien cuando la velocidad de desarrolloes importante (cambios rápidos de las condicionesdel negocio), o cuando lo sistemas puedencapitalizarse en oportunidades estratégicas. | Posibles violaciones de estándares de programaciónrelacionadas con nomenclaturas inconsistentes einsuficiente documentación. |

Permite cambiar rápidamente el diseño de lossistemas cuando los usuarios lo demandan | Dificultades con el reuso de módulos para futurossistemas. |

Los

...