RADDesarrollo Rápido de Aplicaciones       Por: Jenyfer Utitiaja
DEFINICIÓN• Proceso de desarrollo de software que permite  construir sistemas utilizables en poco tiempo,  normalmente de ...
CARACTERÍSTICAS• Equipos Híbridos• Herramientas Especializadas• "Timeboxing“• Prototipos Iterativos y Evolucionarios.
EQUIPOS HÍBRIDOSEquipos compuestos por alrededor de seis personas, incluyendo desarrolladores y usuarios de tiempo comple...
HERRAMIENTAS         ESPECIALIZADASDesarrollo "visual"Creación de prototipos falsos (simulación pura)Creación de protot...
"TIMEBOXING“• Las funciones secundarias son eliminadas  como sea necesario para cumplir con el  calendario.
PROTOTIPOS ITERATIVOS Y       EVOLUCIONARIOS•   Reunión JAD (Joint Application Development):     – Se reunen los usuarios ...
MODELO DE DESARROLLO RAPIDO DE APLICACIONESModelado de gestiónModelado de datosModelado de procesoGeneración de aplica...
MODELADO DE GESTIÓNEl flujo de información entre las funciones de gestión semodela de forma que responda a las siguientes ...
MODELADO DE DATOSEl flujo de información definido como partede la fase de modelado de gestión se refinacomo un conjunto de...
MODELADO DE PROCESOLos objetos de datos definidos en la fase demodelado de datos quedan transformados paralograr el flujo ...
GENERACIÓN DE           APLICACIONESEl DRA asume la utilización de técnicas de cuartageneración. En lugar de crear softwar...
PRUEBAS DE ENTREGAComo el proceso DRA enfatiza lareutilización, ya se han comprobado muchosde los componentes de los progr...
RAD tiende a funcionar cuando:• La aplicación funcionará de manera  independiente.• Se pueden usar mayormente bibliotecas ...
RAD tiende a fallar cuando:• La aplicación debe interoperar con sistemas existentes.• Existen pocos componentes reutilizab...
Ventajas de RAD• Comprar puede ahorrar dinero en comparación con  construir.• Los entregables pueden ser fácilmente trasla...
Desventajas de RAD•   Comprar puede ser más caro que construir.•   Costo de herramientas integradas y equipo necesario.•  ...
Próxima SlideShare
Cargando en…5
×

Rad (desarrollo rápido de aplicaciones)

9.941 visualizaciones

Publicado el

JENYFER UTITIAJA
RAD(DESARROLLO RAPIDO DE APLICACIONES)

0 comentarios
2 recomendaciones
Estadísticas
Notas
  • Sé el primero en comentar

Sin descargas
Visualizaciones
Visualizaciones totales
9.941
En SlideShare
0
De insertados
0
Número de insertados
62
Acciones
Compartido
0
Descargas
263
Comentarios
0
Recomendaciones
2
Insertados 0
No insertados

No hay notas en la diapositiva.

Rad (desarrollo rápido de aplicaciones)

  1. 1. RADDesarrollo Rápido de Aplicaciones Por: Jenyfer Utitiaja
  2. 2. DEFINICIÓN• Proceso de desarrollo de software que permite construir sistemas utilizables en poco tiempo, normalmente de 60 a 90 días, frecuentemente con algunas concesiones.
  3. 3. CARACTERÍSTICAS• Equipos Híbridos• Herramientas Especializadas• "Timeboxing“• Prototipos Iterativos y Evolucionarios.
  4. 4. 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.
  5. 5. HERRAMIENTAS ESPECIALIZADASDesarrollo "visual"Creación de prototipos falsos (simulación pura)Creación de prototipos funcionalesMúltiples lenguajesCalendario grupalHerramientas colaborativas y de trabajo en equipoComponentes reusablesInterfaces estándares (API)
  6. 6. "TIMEBOXING“• Las funciones secundarias son eliminadas como sea necesario para cumplir con el calendario.
  7. 7. PROTOTIPOS ITERATIVOS Y EVOLUCIONARIOS• Reunión JAD (Joint Application Development): – Se reunen 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 diseñadores revisan el prototipo. – Los clientes prueban el prototipo, depuran los requisitos. – Los clientes y desarrolladores se reunen 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.
  8. 8. MODELO DE DESARROLLO RAPIDO DE APLICACIONESModelado de gestiónModelado de datosModelado de procesoGeneración de aplicacionesPruebas de entrega
  9. 9. MODELADO DE GESTIÓNEl flujo de información entre las funciones de gestión semodela de forma que responda a las siguientes preguntas: ¿Qué información conduce el proceso de gestión? ¿Qué información se genera? ¿Quién la genera? ¿A dónde va la información? ¿Quién la proceso?
  10. 10. MODELADO DE DATOSEl flujo de información definido como partede la fase de modelado de gestión se refinacomo un conjunto de objetos de datosnecesarios para apoyar la empresa. Se definenlas características (llamadas atributos) de cadauno de los objetos y las relaciones entre estosobjetos.
  11. 11. MODELADO DE PROCESOLos objetos de datos definidos en la fase demodelado de datos quedan transformados paralograr el flujo de información necesario paraimplementar una función de gestión. Lasdescripciones del proceso se crean paraañadir, modificar, suprimir, o recuperar unobjeto de datos. Es la comunicación entre losobjetos.
  12. 12. GENERACIÓN DE APLICACIONESEl DRA asume la utilización de técnicas de cuartageneración. En lugar de crear software con lenguajesde programación de tercera generación, el procesoDRA trabaja para volver a utilizar componentes deprogramas ya existentes (cuando es posible) o a crearcomponentes reutilizables (cuando sea necesario).En todos los casos se utilizan herramientasautomáticas para facilitar la construcción delsoftware.
  13. 13. PRUEBAS DE ENTREGAComo el proceso DRA enfatiza lareutilización, ya se han comprobado muchosde los componentes de los programas. Estoreduce tiempo de pruebas. Sin embargo, sedeben probar todos los componentes nuevos yse deben ejercitar todas las interfaces a fondo
  14. 14. RAD tiende a funcionar cuando:• La aplicación funcionará de manera independiente.• Se pueden usar mayormente bibliotecas existentes.• Desempeño no crítico.• Distribución limitada, interna o vertical.• Alcance del proyecto limitado.• Confiabilidad no crítica.• El sistema puede dividirse en muchos módulos independientes.
  15. 15. RAD tiende a fallar cuando:• La aplicación debe interoperar con sistemas existentes.• Existen pocos componentes reutilizables.• Alto desempeño crítico.• El desarrollo no puede aprovechar herramientas de alto nivel.• Distribución amplia, horizontal o masiva.• RAD se convierta en QADAD (Quick And Dirty Application Development).• Métodos RAD para desarrollar sistemas operativos (confiabilidad demasiado alta) o juegos (desempeño demasiado alto).
  16. 16. Ventajas de RAD• Comprar puede ahorrar dinero en comparación con construir.• Los entregables pueden ser fácilmente trasladados a otra plataforma.• El desarrollo se realiza a un nivel de abstracción mayor.• Visibilidad temprana.• Mayor flexibilidad.• Menor codificación manual.• Mayor involucramiento de los usuarios.
  17. 17. Desventajas de RAD• Comprar puede ser más caro que construir.• Costo de herramientas integradas y equipo necesario.• Progreso más difícil de medir.• Menos eficiente.• Menor precisión científica.• Riesgo de revertirse a las prácticas sin control de antaño.• Más fallas (por síndrome de "codificar a lo bestia").

×