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

NO RENOVABLES

INGENIERIA EN SISTEMAS
MODELO DE DESARROLLO RÁPIDO
DE APLICACIONES

INTEGRANTES:

* DIANA AMAY
* MARICELA CAMACHO
* XIMENA QUEVEDO
* VERONICA SOTO
* MILTON VARGAS

MODULO:
NOVENO “B”

AÑO LECTIVO:
2010
 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
 "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 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
 Evitar los errores clásicos
 Aplicar las bases del desarrollo
 Gestionar los riesgos para evitar un retorno
catastrófico
Métodos orientados a la
planificación
 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