ÁREA DE ENERGÍA, LAS INDUSTRIAS Y LOS RECURSOS

NATURALES NO RENOVABLES

INGENIERIA EN SISTEMAS

INTEGRANTES:

* DIANA AMAY* MARICELA CAMACHO* XIMENA QUEVEDO

* VERONICA SOTO * MILTON VARGAS

MODULO: NOVENO “B”

AÑO LECTIVO: 2010

MODELO DE DESARROLLO RÁPIDO DE APLICACIONES

Historia

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.

CONCEPTO

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.

Principios básicos

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

FASES

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.

CARACTERÍSTICAS

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.

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

Prototipos Iterativos y Evolucionarios

› Las funciones secundarias son eliminadas como sea necesario para cumplir con el calendario.

"Timeboxing”

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

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

Notas:

› Cada iteración dura entre un día y tres semanas.

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

ESTRATEGIA PARA CONSEGUIR EL RAD

Métodos orientados a la planificación

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

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

RAD TIENDE A FALLAR CUANDO

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.

VENTAJAS

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.

DESVENTAJAS

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.

GRACIAS