Modelo de Proceso de Desarrollo Dra

INGENIERÍA DE SOFTWARE
MODELO DE PROCESO DE DESARROLLO DRA (DESARROLLO

Título RÁPIDO DE APLICACIÓNES)
Nombres y Apellidos Código de estudiantes
Arturo Fabián Ledezma Romero 201207708
Autor/es
Fecha 06/09/2017
Carrera Ingeniería de Sistemas

Asignatura Ingeniería de Software
Grupo A
Docente Lic. Iván Félix Fernández Daza
Periodo Académico II/2017
Subsede
Copyright © (2017) por (Arturo Fabián). Todos los derechos reservados.
.
Título: Modelo de Proceso de Desarrollo por Prototipos
Autor/es: Arturo Fabián Ledezma Romero
RESUMEN:
En este pequeño trabajo de investigación hablare un poco acerca de uno de los tantos
modelos de proceso de desarrollo de software que existe hoy en día, tal es el caso del modelo de
la Metodología RAD (desarrollo rápido de aplicaciones), se hablara un poco de su historia,
características, tipos, también de su ciclo de vida, además de mencionar sus ventajas y
desventajas de dicho modelo.
Palabras clave: investigación, modelo, prototipo
ABSTRACT:
In this small research paper I will talk a little about one of the many models of software
development process that exists today, such as the RAD Methodology (rapid application
development) model, we will talk a little its history, characteristics, types, also of its life cycle, in
addition to mentioning its advantages and disadvantages of said model.
Key words: research, model, prototype
Asignatura: Ingeniería de Software

Carrera: Ingeniería de Sistemas Página 4 de 17
Tabla De Contenidos
Tabla de Ilustraciones..................................................................................................................4
Introducción................................................................................................................................5
MODELO DE PROCESO DE DESARROLLO RÁPIDO DE APLICACIÓNES (DRA)........6
1.1. Historia......................................................................................................................6
1.2. Características............................................................................................................7
1.3. Ciclo de vida de un Sistema basado en el modelo RAD...........................................9
1.4. Fases del Modelo RAD............................................................................................10
1.5. Normativa del Modelo RAD...................................................................................12
1.6. RAD Tiende A Funcionar Cuando:..........................................................................13
1.7. RAD Tiende A Fallar Cuando:.................................................................................13
1.8. ¿Cuándo aplicar el enfoque RAD?..........................................................................14
1.9. Ventajas de un Sistema basado en el Modelo de Desarrollo Rápido de Aplicaciones
14
1.10. Desventajas de un Sistema basado en el Modelo de Desarrollo Rápido de
Aplicaciones..............................................................................................................................15
1.11. ¿Por qué Usar RAD?...............................................................................................15
1.12. Conclusiones............................................................................................................15
1.13. Bibliografía..............................................................................................................17

Tabla de Ilustraciones
Ilustración 1 Fases del Modelo RAD........................................................................................11

Introducción
El Proceso para el desarrollo de software, también denominado ciclo de vida del desarrollo de
software es una estructura aplicada al desarrollo de un producto de software. Hay varios modelos
a seguir para el establecimiento de un proceso para el desarrollo de software, cada uno de los
cuales describe un enfoque diferente para diferentes actividades que tienen lugar durante el
proceso.
La gran cantidad de organizaciones de desarrollo de software implementan metodologías para
el proceso de desarrollo. Muchas de estas organizaciones pertenecen a la industria
armamentística, que en los Estados Unidos necesita un certificado basado en su modelo de
procesos para poder obtener un contrato.
Entre los varios tipos de modelos para el proceso de desarrollo de software está el modelo de
Desarrollo Rápido De Aplicaciones (DRA). Es el proceso de desarrollo de software diseñado
para facilitar y acelerar la creación de aplicaciones, que permite construir sistemas utilizables en
poco tiempo, normalmente de 60 a 90 días. En conclusión, es una adaptación a "Alta velocidad"
en el que se logra el desarrollo rápido utilizando un enfoque de construcción basado en
componentes. Si se comprenden bien los requisitos y se limita el ámbito del proyecto, el proceso
DRA permite al equipo de desarrollo crear un "sistema completamente funcional" dentro de
periodos cortos de tiempo.

MODELO DE PROCESO DE DESARROLLO RÁPIDO DE APLICACIÓNES (DRA)
El desarrollo rápido de aplicaciones o RAD (acrónimo en inglés de rapid application

development) es un proceso de desarrollo de software, desarrollado inicialmente por James
Martin en1980. El método comprende el desarrollo interactivo, la construcción de prototipos y el
uso de utilidades CASE (Computer Aided Software Engineering). Tradicionalmente, el
desarrollo rápido de aplicaciones tiende a englobar también la usabilidad, utilidad y la rapidez de
ejecución.
Hoy en día se suele utilizar para referirnos al desarrollo rápido de interfaces gráficas de
usuario tales como Glade, o entornos de desarrollo integrado completos. Algunas de las
plataformas más conocidas son Visual Studio, Lazarus, Gambas, Delphi,Foxpro , Anjuta, Game
Maker, Velneo o Clarion. En el área de la autoría multimedia, software como Neosoft Neoboo y
MediaChance Multimedia Builder proveen plataformas de desarrollo rápido de aplicaciones,
dentro de ciertos límites.
1.1. Historia
El desarrollo de los sistemas tradicionales de ciclo de vida se originó en la década de 1960

para desarrollar a gran escala funcional de sistemas de negocio en una época de grandes
conglomerados empresariales. La idea principal era continuar el desarrollo de los sistemas de
información en una muy deliberada, estructurada y metódica, reiterando cada una de las etapas
del ciclo de vida. Los sistemas de información en torno a las actividades resueltas pesadas para el
procesamiento de datos y rutinas de cálculo.
El desarrollo rápido de aplicaciones o RAD (acronimo en inglés de rapid application
development) es un proceso de desarrollo de software, desarrollado inicialmente por James
Martin en 1980. El método comprende el desarrollo iterativo, la construcción de prototipos y el
uso de utilidades CASE (Computer Aided Software Engineering). Tradicionalmente, el
desarrollo rápido de aplicaciones tiende a englobar también la usabilidad, utilidad y la rapidez de
ejecución.

1.2. Características
Entre las principales características del RAD tenemos:

 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:
Ingeniería de Software:
 Los desarrolladores construyen y depuran el prototipo basado en los requisitos actuales.
 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 con el calendario.
 Bajos costos: RAD, por lo general, resulta en costos más bajos. Esto se debe a que se
forman pequeños equipos de profesionales quienes utilizan herramientas de alta
capacidad para generar los sistemas. Estas herramientas conocidas como "CASE"
(Computer Aided Systems Engineering) permiten que se aligere el proceso, lo cual ayuda
a que los costos aún sean más bajos sin sacrificar la calidad del producto. El método
RAD utiliza estas herramientas computadorizadas y talento humano para cumplir con las
metas requeridas rápida y efectivamente.
Las herramientas integradas "CASE" proveen para que la planificación, análisis e itinerarios se
creen gráficamente. Los analistas de sistemas interactúan con estas herramientas por medio de
diagramas.
 Calidad: La calidad de un sistema se mide en términos de hasta qué punto ese sistema, al
momento que se implementa, cumple con los requisitos de la compañía y sus usuarios.
El uso de herramientas "CASE" tiene el propósito de integrar diagramas para representar la
información y crear modelos del sistema. Se crean diseños y estructuras bien detalladas. Cuando
es apropiado, los diagramas ayudan a visualizar los conceptos. Estas herramientas
computadorizadas refuerzan la exactitud de los diagramas.
Las herramientas "CASE" junto con generadores de códigos y otros instrumentos para
crear prototipos proveen un medio para asegurar la calidad del producto cuando se emplean
utilizando la metodología adecuada. Un término apropiado para definir la calidad de una
aplicación desarrollada con el modelo RAD es satisfacer los requisitos de los usuarios lo más
eficazmente posible al momento que el sistema se implementa. Mientras menos tiempo
transcurre en el desarrollo del sistema menos habrán cambiado las necesidades de los usuarios.
En compañías donde se ha utilizado el método tradicional de diseño de aplicaciones, al
momento de instalar el sistema ha pasado tanto tiempo que las funciones definidas por los
usuarios al comienzo del desarrollo han cambiado. Este significa volver a emplear tiempo y
recursos humanos en modificar esos cambios lo que resulta en una pobre calidad del producto.

NOTA:
 Cada iteración dura entre un día y tres semanas.
 Reuniones de 2 horas con facilitador que mantiene enfocado al grupo.
1.3. Ciclo de vida de un Sistema basado en el modelo RAD.
Etapa de planificación de los requisitos: Esta etapa requiere que usuarios con un vasto
conocimiento de los procesos de la compañía determinen cuáles serán las funciones del sistema.
Debe darse una discusión estructurada sobre los problemas de la compañía que necesitan
solución. Por lo general esta etapa se completa rápidamente cuando se crean equipos que
envuelven usuarios y ejecutivos con un conocimiento amplio sobre las necesidades de la
institución la planificación de los requisitos se da en modalidad de taller conocido como Junta de
Planificación de Requisitos (JRP por sus siglas en inglés).
Etapa de diseño: Esta consiste de un análisis detallado de las actividades de la compañía en
relación al sistema propuesto. Los usuarios participan activamente en talleres bajo la tutela de
profesionales de la informática. En ellos descomponen funciones y definen entidades asociadas
con el sistema. Una vez se completa el análisis se crean los diagramas que definen las
alteraciones entre los procesos y la data. Al finalizar el análisis se traza el diseño del sistema. Se
desarrollan los procedimientos y los esquemas de pantallas. Los prototipos de procedimientos
críticos se construyen y se repasan y el plan para implementar el sistema se prepara.
Construcción: En la etapa de construcción el equipo de desarrolladores trabajando de cerca
con los usuarios finaliza el diseño y la construcción del sistema. La construcción de la aplicación
consiste de una serie de pasos donde los usuarios tienen la oportunidad de afirmar los requisitos
y repasar los resultados. Las pruebas al sistema se llevan a cabo durante esta etapa. También se
crea la documentación y las instrucciones necesarias para manejar la nueva aplicación, rutinas y
procedimientos para operar el sistema.
Implementación: Esta etapa envuelve la instalación del nuevo producto y el manejo del
cambio del viejo al nuevo sistema. Se hacen pruebas comprensivas y se adiestran los usuarios.
Los cambios organizacionales y la operación del nuevo sistema se hacen en paralelo con el viejo
sistema hasta que el nuevo se establezca completamente.

1.4. Fases del Modelo RAD
Modelado de gestión: el flujo de información entre las funciones de gestión se modela 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 lo proceso?
Modelado de datos: el flujo de información definido como parte de la fase de modelado de
gestión se refina como un conjunto de objetos de datos necesarios para apoyar la empresa. Se
definen las características (llamadas atributos) de cada uno de los objetos y las relaciones entre
estos objetos.
Modelado de proceso: los objetos de datos definidos en la fase de modelado de datos
quedan transformados para lograr el flujo de información necesario para implementar una
función de gestión. Las descripciones del proceso se crean para añadir, modificar, suprimir, o
recuperar un objeto de datos. Es la comunicación entre los objetos.
Generación de aplicaciones: El RAD usa técnicas de cuarta generación. En lugar de crear
software con lenguajes de programación de tercera generación, el proceso RAD trabaja para
volver a utilizar componentes de programas ya existentes (cuando es posible) o a crear
componentes reutilizables (cuando sea necesario). En todos los casos se utilizan herramientas
automáticas para facilitar la construcción del software.
Pruebas de entrega: El proceso RAD enfatiza la reutilización de los componentes de los
programas ya comprobados. Esto reduce tiempo de pruebas. Sin embargo, se deben probar todos
los componentes nuevos y ejercitar todas las interfaces a fondo.
Obviamente la limitación de tiempo impuesto en un proyecto DRA demanda “ámbito en
escalas”. Si una aplicación de gestión puede modularse se forma que permita completarse cada
una de las funciones principales en menos de tres meses (utilizando el enfoque descrito
anteriormente), es un candidato del DRA. Cada una de las funciones puede ser afrontada por un
equipo DRA diferente y ser integradas en un solo conjunto.

Algunos inconvenientes:
 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.
No todos los tipos de aplicaciones son apropiados para DRA. Si un sistema no se puede
modulizar adecuadamente. La construcción de los componentes necesarios para DRA será
problemático. Si está en juego el alto rendimiento, y se va a conseguir el rendimiento
convirtiendo interfaces en componentes de sistema, el enfoque DRA puede que no funcione.
DRA no es adecuado cuando los riesgos técnicos son altos. Esto ocurre cuando una nueva
aplicación hace uso de tecnologías nuevas, o cuando el nuevo software requiere un alto grado de
interoperabilidad con programas de computadora ya existentes. DRA enfatiza el desarrollo de
componentes de programas reutilizables. La reutilización es la piedra angular de las tecnologías
de objetos, y se encuentra en el modelo de proceso de ensamblaje.
Ilustración 1 Fases del Modelo RAD

1.5. Normativa del Modelo RAD.
Norma ISO 12207-1 Actividades del Ciclo de Vida se agrupan en 5 procesos principales, 8
procesos de soporte y 4 procesos generales ISO/IEC 12207 establece un proceso de ciclo de vida
para el software que incluye procesos y actividades que se aplican desde la definición de
requisitos, pasando por la adquisición y configuración de los servicios del sistema, hasta la
finalización de su uso. Este estándar tiene como objetivo principal proporcionar una estructura
común para que compradores, proveedores, desarrolladores, personal de mantenimiento,
operadores, gestores y técnicos involucrados en el desarrollo de software usen un lenguaje
común. Este lenguaje común se establece en forma de procesos bien definidos.
La estructura del estándar ha sido concebida de manera que pueda ser adaptada a las
necesidades de cualquiera que lo use. Para conseguirlo, el estándar se basa en dos principios
fundamentales: Modularidad y responsabilidad. Con la modularidad se pretende conseguir
procesos con un mínimo acoplamiento y una máxima cohesión. En cuanto a la responsabilidad,
se busca establecer un responsable para cada proceso, facilitando la aplicación del estándar en
proyectos en los que pueden existir distintas personas u organizaciones involucradas, no
importando el uso que se le dé a este.
Los procesos se clasifican en tres tipos: Principales, de soporte y de la organización. Los
procesos de soporte y de organización deben existir independientemente de la organización y del
proyecto ejecutado. Los procesos principales se instancian de acuerdo con la situación particular.
Procesos principales.
 Adquisición.
 Suministro.
 Desarrollo.
 Operación.
 Mantenimiento.
Procesos de soporte.
 Documentación
 Gestión de la configuración.
 Aseguramiento de calidad.

 Verificación.
 Validación.
 Revisión conjunta.
 Auditoría.
 Resolución de problemas.
Procesos de la organización.
 Gestión.
 Infraestructura.
 Mejora.
 Recursos Humanos.
1.6. 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.
1.7. 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).
 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.
1.8. ¿Cuándo aplicar el enfoque RAD?
La metodología conocida como diseño rápido de aplicaciones (RAD según sus siglas en
inglés) ha tenido mucho auge recientemente en el mundo de la informática. Esta metodología
propone un proceso de desarrollo de "software" que permite que se creen sistemas de
computadoras utilizables en un periodo de tiempo entre 60 a 90 días. RAD es un ciclo de
desarrollo diseñado para crear aplicaciones de computadoras de alta calidad de las que acontecen
en corporaciones grandes.
El desarrollo de aplicaciones enfrenta una transformación fundamental. Hace cinco años un
proyecto para desarrollar una aplicación tomaba un periodo de entre 18 a 24 meses; actualmente,
con la práctica del modelo RAD toma entre 1 a 3 meses.
1.9. Ventajas de un Sistema basado en el Modelo de Desarrollo Rápido de Aplicaciones
 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.

1.10. Desventajas de un Sistema basado en el Modelo de Desarrollo Rápido de

Aplicaciones
 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").
 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.
1.11. ¿Por qué Usar RAD?
Malas razones
 Prevenir presupuestos rebasados (RAD necesita un equipo disciplinado en manejo de
costos).
 Prevenir incumplimiento de fechas (RAD necesita un equipo disciplinado en manejo de
tiempo).
Buenas razones
 Convergir tempranamente en un diseño aceptable para el cliente y posible para los
desarrolladores.
 Limitar la exposición del proyecto a las fuerzas de cambio.
 Ahorrar tiempo de desarrollo, posiblemente a expensas de dinero o de calidad del
producto.
1.12. Conclusiones
DRA es un modelo de proceso de software incremental que resalta un ciclo de desarrollo

corto. Es una adaptación de "alta velocidad" del modelo de cascada. El proceso de DRA permite

que un equipo de desarrollo cree un sistema completamente funcional dentro de un periodo muy
corto de 60 a 90 días.
DRA es una adaptación de “Alta velocidad" en el que se logra el desarrollo rápido utilizando
un enfoque de construcción basado en componentes. Si se comprenden bien los requisitos y se
limita el ámbito del proyecto, el proceso DRA permite al equipo de desarrollo crear un "sistema
completamente funcional" dentro de periodos cortos de tiempo.

1.13. Bibliografía
 http://modelo-dra-ing-de-sistemas.blogspot.com/
 http://gestionrrhhusm.blogspot.com/2011/05/ingenieria-de-software-ingenieria-de.html
 https://curiosisimos.wordpress.com/linux/modelo-de-desarrollo-rapido-de-aplicaciones/
 http://metodologiarad.weebly.com/


Modelo de Proceso de Desarrollo Dra

Caricato da

Informazioni sul documento

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Modelo de Proceso de Desarrollo Dra

Caricato da

Copyright:

Formati disponibili

INGENIERÍA DE SOFTWARE

MODELO DE PROCESO DE DESARROLLO DRA (DESARROLLO

Carrera Ingeniería de Sistemas

Palabras clave: investigación, modelo, prototipo

Key words: research, model, prototype

Asignatura: Ingeniería de Software

Asignatura: Ingeniería de Software

Ilustración 1 Fases del Modelo RAD........................................................................................11

Asignatura: Ingeniería de Software

Asignatura: Ingeniería de Software

MODELO DE PROCESO DE DESARROLLO RÁPIDO DE APLICACIÓNES (DRA)

El desarrollo rápido de aplicaciones o RAD (acrónimo en inglés de rapid application

El desarrollo de los sistemas tradicionales de ciclo de vida se originó en la década de 1960

Asignatura: Ingeniería de Software

Entre las principales características del RAD tenemos:

 Prototipos Iterativos Y Evolucionarios:

Asignatura: Ingeniería de Software

Asignatura: Ingeniería de Software

1.3. Ciclo de vida de un Sistema basado en el modelo RAD.

Asignatura: Ingeniería de Software

1.4. Fases del Modelo RAD

Modelado de gestión: el flujo de información entre las funciones de gestión se modela de

Asignatura: Ingeniería de Software

Ilustración 1 Fases del Modelo RAD

Asignatura: Ingeniería de Software

1.5. Normativa del Modelo RAD.

Asignatura: Ingeniería de Software

1.6. RAD Tiende A Funcionar Cuando:

Asignatura: Ingeniería de Software

 Métodos RAD para desarrollar sistemas operativos (confiabilidad demasiado alta) o

1.8. ¿Cuándo aplicar el enfoque RAD?

Asignatura: Ingeniería de Software

1.10. Desventajas de un Sistema basado en el Modelo de Desarrollo Rápido de

DRA es un modelo de proceso de software incremental que resalta un ciclo de desarrollo

Asignatura: Ingeniería de Software

Asignatura: Ingeniería de Software

Asignatura: Ingeniería de Software

Potrebbero piacerti anche