Comenzando con las ideas de Barry Boehm y Scott Shultz, James Martin desarrolló el Rapid Application Development durante los años 1980 en IBM y finalmente.

Presentación del tema: "Comenzando con las ideas de Barry Boehm y Scott Shultz, James Martin desarrolló el Rapid Application Development durante los años 1980 en IBM y finalmente."— Transcripción de la presentación:

1

2 Comenzando con las ideas de Barry Boehm y Scott Shultz, James Martin desarrolló el Rapid Application Development durante los años 1980 en IBM y finalmente lo formalizó publicando un libro en 1990. Equipos Híbridos Herramientas Especializadas Timeboxing Prototipos Iterativos y Evolucionarios Proceso de desarrollo de software que permite construir sistemas utilizables en poco tiempo, normalmente de 60 a 90 días

3 Planificación de Necesidades Diseño de Usuario ContruccionCutover Modelado de Negocios Modelado de Datos Modelado de Procesos Generacion de Aplicaciones Pruebas

4 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. El producto está dirigido a un mercado altamente especializado. El proyecto cuenta con fuertes limitantes de tiempos parciales (timeboxes). La tecnología requerida tiene más de un año en el mercado. 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. Métodos RAD para desarrollar sistemas operativos (confiabilidad demasiado alta) o juegos (desempeño demasiado alto). Riesgos técnicos de tecnología de punta. El producto pone en riesgo la misión o la vida. El producto no puede ser modularizado.

5 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. Posiblemente menos fallas. Posiblemente menor costo. Ciclos de desarrollo más pequeños. Interfaz gráfica estándar. 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 Prototipos pueden no escalar, un problema mayúsculo. Funciones reducidas (por "timeboxing"). Dependencia en componentes de terceros: funcionalidad de más o de menos, problemas legales.

6

7