Metodologia Rad

FASES DEL RAD
Modelado de gestin: el flujo de informacin entre las funciones de gestin se modela de forma que responda a las siguientes preguntas: Qu informacin conduce el proceso de gestin? Qu informacin se genera? Quin la genera? A dnde va la informacin? Quin la proceso? Modelado de datos: el flujo de informacin definido como parte de la fase de modelado de gestin se refina como un conjunto de objetos de datos necesarios para apoyar la empresa. Se definen las caractersticas (llamadas atributos) de cada uno de los objetos y las relaciones entre estos objetos. Modelado de proceso: los objetos de datos definidos en la fase de modelado de datos quedan transformados para lograr el flujo de informacin necesario para implementar una funcin de gestin. Las descripciones del proceso se crean para aadir, modificar, suprimir, o recuperar un objeto de datos. Es la comunicacin entre los objetos. Generacin de aplicaciones: El DRA asume la utilizacin de tcnicas de cuarta generacin. En lugar de crear software con lenguajes de programacin de tercera generacin, el proceso DRA trabaja para volver a utilizar componentes de programas ya existentes (cuando es posible) o a crear componentes reutilizables (cuando sea necesario). En todos los casos se utilizan herramientas automticas para facilitar la construccin del software. Pruebas de entrega: Como el proceso DRA enfatiza la reutilizacin, ya se han comprobado muchos de los componentes de los programas. Esto reduce tiempo de pruebas. Sin embargo, se deben probar todos los componentes nuevos y se deben ejercitar todas las interfaces a fondo.
La figura 3 muestra de forma grfica las etapas del modelo RAD.
1) Etapa de Planificacin de Requisitos: Esta etapa requiere que los usuarios con un vasto conocimiento de los procesos de la compaa determinen cules sern las funciones del sistema. Debe darse una discusin estructurada sobre los problemas de la compaa que necesitan solucin. 2) Etapa de Diseo: Esta consiste de un anlisis detallado de las actividades de la compaa en relacin al sistema propuesto. Los usuarios participan activamente en talleres bajo la tutela de los profesionales de la informtica. En ellos descomponen funciones y definen entidades asociadas con el sistema. Una vez se completa el anlisis se crean los diagramas que definen las alteraciones entre los procesos y la data. 3) Construccin: En la etapa de construccin el equipo de desarrolladores trabajando de cerca con los usuarios finalizan el diseo y la construccin del sistema. La construccin de la aplicacin consiste de una serie de pasos donde los usuarios tienen la oportunidad de afirmar los requisitos y repasar los resultados. 4) Implementacin: Esta etapa envuelve la implementacin del nuevo producto y el manejo de cambio del viejo al nuevo sistema. Se hacen pruebas comprensivas y se adiestran los usuarios.
Desarrollo rpido de aplicaciones (RAD)

Enfoque para el desarrollo de software dirigido a la entrega rpida de este. A menudo implica el uso de la programacin de base de datos y herramientas de apoyo al desarrollo como los generadores de informes y pantallas.
Las herramientas que se incluyen en un entorno RAD son:

1. Un lenguaje de programacin de base de datos, que contiene conocimiento de la estructura de la base de datos y que incluye las operaciones bsicas de manipulacin de base de datos. El lenguaje estndar de programacin de base de datos es SQL (Groffet al., 2002). Los comandos SQL se pueden introducir directamente o generar de forma automtica a partir de formularios rellenados por usuarios finales. 2. Un generador de interfaces, que se utilizan para crear formularios de introduccin y visualizacin de datos. 3. Enlaces a aplicaciones de oficina, como una hoja de clculo para el anlisis y manipulacin de informacin numrica o un procesador de texto para la creacin de plantillas de informes. 4. Un generador de informes, que se utiliza para definir y crear informes a partir de la informacin de la base de datos. Los sistemas RAD tienen xito debido a que las aplicaciones de negocio tienen muchas cosas en comn. Esencialmente, a menudo estas aplicaciones comprenden la actualizacin de una base de datos y la produccin de informes a partir de la informacin existente en ella. Se utilizan formularios estndar para las entradas y salidas. Los sistemas RAD estn dirigidos a la produccin de aplicaciones interactivas que se apoyan la abstraccin de la informacin en una base de datos organizacional, presentndola a los usuarios finales en su terminal o estacin de trabajo, y actualizando la base de datos con los cambios hechos por los usuarios. Muchas de las aplicaciones de negocio se apoyan en formularios estructurados para las entradas y salidas, por lo que los entornos RAD proporcionan recursos potentes para la definicin de pantallas y generacin de informes. A menudo, las pantallas se definen como una serie de formularios vinculados (en una aplicacin que estudiamos, hubo 137 definiciones de formularios), por lo que el sistema de generacin de pantallas debe proporcionar: 1. Definicin de formularios interactivos que permitan al desarrollador definir los campos a visualizar y la manera en que estos deben organizarse. 2. Vinculacin de formularios que permitan al desarrollador especificar que ciertas entradas provocan la visualizacin de formularios adicionales. 3. Verificacin de campos que permitan al desarrollador definir los rangos permitidos para los valores de entrada en los campos de los formularios.
Definicin de RAD
Proceso de desarrollo de software que permite construir sistemas utilizables en poco tiempo, normalmente de 90 a 120 das, frecuentemente con algunas concesiones.
Principios tras la definicin

En ciertas situaciones, una solucin utilizable al 80% puede producirse en el 20% de tiempo que se hubiera requerido para la solucin completa. En ciertas situaciones, los requisitos de negocio de un sistema pueden satisfacerse aun cuando algunos de sus requisitos operacionales no se satisfagan. En ciertas situaciones, la aceptabilidad de un sistema puede determinarse en base a un conjunto mnimo de requisitos consensados en lugar de la totalidad de los requisitos.
Problemas atendidos por RAD

Con los mtodos convencionales pasa un gran lapso de tiempo antes de que el cliente vea resultados.. Con los mtodos convencionales el desarrollo llega a tardar tanto que para cuando el sistema est listo para utilizarse los procesos del cliente han cambiado radicalmente. Con los mtodos convencionales no hay nada hasta que el 100% del proceso de desarrollo se ha realizado, entonces se entrega el 100% del software.
PORQU USAR RAD?

Malas razones

Prevenir presupuestos rebasados (RAD necesita un equipo disciplinado en manejo de costos). Prevenir incumplimiento de fechas (RAD necesita un equipo disciplinado en manejo de tiempo).
Buenas razones

Convergir tempranamente en un diseo aceptable para el cliente y posible para los desarrolladores. Limitar la exposicin del proyecto a las fuerzas de cambio. Ahorrar tiempo de desarrollo, posiblemente a expensas de dinero o de calidad del producto.
CARACTERSTICAS DE RAD
Equipos Hbridos

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, diseadores y programadores en uno.
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 Interfaces estndares (API)
"Timeboxing" Las funciones secundarias son eliminadas como sea necesario para cumplir con el calendario. Prototipos Iterativos y Evolucionarios.
Reunion JAD (Joint Application Development):

o o o o o o o o
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 el calendario.
VENTAJAS
1. 2. 3. 4. 5. 6. 7. 8. 9. Comprar puede ahorrar dinero en comparacin con construir. Los entregables pueden ser fcilmente trasladados a otra plataforma. El desarrollo se realiza a un nivel de abstraccin mayor. Visibilidad temprana. Mayor flexibilidad. Menor codificacin manual. Mayor involucramiento de los usuarios. Posiblemente menos fallas. Posiblemente menor costo.
10. Ciclos de desarrollo ms pequeos. 11. Interfaz grfica estndar.
DESVENTAJAS
1. 2. 3. 4. 5. 6. 7. 8. 9. Comprar puede ser ms caro que construir. Costo de herramientas integradas y equipo necesario. Progreso ms difcil de medir. Menos eficiente. Menor precisin cientfica. 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. Funciones reducidas (por timeboxing). 10. Dependencia en componentes de terceros: funcionalidad de ms o de menos, problemas legales.
Resumen "Con el fin de asegurar gran interaccin, los proyectos se disean con calendarios fijos y se sacrifica la funcionalidad si es necesario. Esto permite que el equipo de desarrollo en este caso yo solo me enfoque en las piezas de funcionalidad que tienen el mayor valor de negocio y en entregar dicha funcionalidad rpidamente. Los cambios son frecuentemente la razn de los retrasos en el desarrollo de una aplicacin. En los largos procesos lineales de desarrollo, los cambios en los requisitos funcionales o en el alcance del proyecto, particularmente cuando gran cantidad de tiempo se ha invertido en la planeacin, diseo, desarrollo y pruebas, provocan que se pierdan meses de trabajo y se incurra en grandes gastos por rediseo y redesarrollo. RAD ataca la infiltracin de cambios de alcance y requisitos al limitar la exposicin del proyecto al cambio, acortando el ciclo de desarrollo y limitando el costo de los cambios al incorporarlos desde el inicio, antes de que grandes inversiones se hayan hecho en desarrollo y pruebas."

Metodologia Rad

Cargado por

Información del documento

Descripción original:

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Metodologia Rad

Cargado por

Copyright:

Formatos disponibles

FASES DEL RAD

La figura 3 muestra de forma grfica las etapas del modelo RAD.

Desarrollo rpido de aplicaciones (RAD)

Las herramientas que se incluyen en un entorno RAD son:

Principios tras la definicin

Problemas atendidos por RAD

PORQU USAR RAD?

Reunion JAD (Joint Application Development):

10. Ciclos de desarrollo ms pequeos. 11. Interfaz grfica estndar.

También podría gustarte