P. 1
Modelo de Desarrollo Rápido de Aplicaciones (DRA)

Modelo de Desarrollo Rápido de Aplicaciones (DRA)

|Views: 2.338|Likes:
Publicado porDiana

More info:

Categories:Types, School Work
Published by: Diana on Nov 24, 2010
Copyright:Attribution Non-commercial

Availability:

Read on Scribd mobile: iPhone, iPad and Android.
download as PPTX, PDF, TXT or read online from Scribd
See more
See less

08/06/2013

pdf

text

original

MODELO DE DESARROLLO RÁPIDO DE APLICACIONES

El desarrollo rápido de aplicaciones o RAD (Rapid Application Development) es un proceso de desarrollo de software, desarrollado inicialmente por James Martin en 1980.

RAD es un desarrollo secuencial lineal modelo de proceso de software que el énfasis de un ciclo de desarrollo extremadamente corto utilizando un enfoque basado en el componente de construcción.

€ €

€

€

€ € €

Objetivo clave es un rápido desarrollo y entrega de una alta calidad en un sistema de relativamente bajo coste de inversión. Intenta reducir los riesgos inherentes del proyecto partiéndolo en segmentos más pequeños y proporcionar más facilidad de cambio durante el proceso de desarrollo. Hace especial hincapié en el cumplimiento de la necesidad comercial, mientras que la ingeniería tecnológica o la excelencia es de menor importancia. Control de proyecto implica el desarrollo de prioridades y la definición de los plazos de entrega. Si el proyecto empieza a aplazarse, se hace hincapié en la reducción de requisitos para el ajuste, no en el aumento de la fecha límite. La participación activa de los usuarios es imprescindible. Iterativamente realiza la producción de software, en lugar de colgarse de un prototipo. Produce la documentación necesaria para facilitar el futuro desarrollo y mantenimiento

o

€

€

€

€

Modelado de gestión o Negocios: El flujo de información entre las funciones de las empresas se define respondiendo a preguntas como qué información es el motor del proceso de negocio, lo que se genera, que la genera, donde va la información, que lo proceso y así sucesivamente. Modelado de datos: La información recogida a partir del modelo de negocio se refina en un conjunto de objetos de datos (entidades) que se necesitan para apoyar el negocio. Modelado de procesos: El objeto de datos definidos en la fase de modelado de datos se transforman para lograr el flujo de información necesario para implementar una función de negocio. descripciones de procesamiento se crean para añadir, modificar, eliminar o recuperar un objeto de datos. Generación de aplicaciones: Las herramientas automatizadas que se utilizan para facilitar la construcción del software, e incluso que utilizan las técnicas GL cuarto. Pruebas de entrega: Muchos de los componentes de programación ya han sido sometidos a pruebas desde reutilización énfasis RAD. Esto reduce el tiempo global de los ensayos. Pero los nuevos componentes debe ser probado y todas las interfaces debe ejercerse plenamente.

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

¾ 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) Control de versiones

¾ Las funciones secundarias son eliminadas

como sea necesario para cumplir con el calendario.

¾ Reunión JAD (Joint Application

Development): ¾ Se reúnen los usuarios finales y los desarrolladores. ¾ Lluvia de ideas para obtener un borrador inicial de los requisitos.

¾ 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 reúnen 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.

¾ Cada iteración dura entre un día y tres

semanas. ¾ Reuniones de 2 horas con facilitador que mantiene enfocado al grupo.

€ Evitar

los errores clásicos € Aplicar las bases del desarrollo € Gestionar los riesgos para evitar un retorno catastrófico

€ Métodos

que mejoran la velocidad de desarrollo € Métodos que reducen el riesgo de retrasarse € Métodos que hacen visible el progreso

€ € € € € € € € € €

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 inter-operar 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). 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.

€

€ € € € € € € € € € €

RAD reduce el tiempo de desarrollo y reutilización de componentes ayudan a acelerar el desarrollo. Todas las funciones son modulares por lo que es fácil trabajar con él. 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. 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 (por síndrome de "codificar a lo bestia"). 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. Para proyectos grandes aunque por escalas, el DRA requiere recursos humanos suficientes como para crear el número correcto de equipos DRA. DRA requiere clientes y desarrolladores comprometidos en las rápidas actividades necesarias para completar un sistema en un marco de tiempo abreviado. Si no hay compromiso, por ninguna de las partes constituyentes, los proyectos DRA fracasaran.

You're Reading a Free Preview

Descarga
scribd
/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->