El modelo DRA o RAD (Rapid Aplication Development)

El modelo "DRA"

Según (GONZÁLEZ, (2001)) 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.

El desarrollo rápido de aplicaciones o RAD (Rapid Aplication 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. Tradicionalmente, el desarrollo rápido de aplicaciones tiende a englobar también la usabilidad, utilidad y la rapidez de ejecución. Él Desarrollo Rápido de Aplicaciones (DRA) (Rapid Explication Development RAD) es un modelo de proceso del desarrollo del software lineal secuencial que enfatiza un ciclo de desarrollo extremadamente corto.

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.

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. Al igual que todos los modelos de proceso, el enfoque DRA tiene 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 Ingeniería de software 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.

¿QUÉ ES 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.

CARACTERÍSTICAS DEL MODELO DRA

Según (De Armas Ramírez, (2003)) Afirma que Debido a que el software o aplicación se requiere lo más pronto posible no existe una especificación del sistema detallada.

• El software no se desarrolla y utiliza en su totalidad, sino en una serie de incrementos, donde en cada incremento se incluyen nuevas funcionalidades al sistema.

• A menudo se desarrollan las interfaces de usuario del sistema utilizando un sistema de desarrollo interactivo que permite que el diseño de la interfaz se cree rápidamente dibujando y colando iconos en la interfaz.

• Para su desarrollo se utilizan herramientas de desarrollo visual para agilizar el proceso.

• Se necesitan equipos compuestos por alrededor de seis personas, incluyendo desarrolladores y usuarios de tiempo completo, así como aquellas personas involucradas en los requisitos.

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

FASES DEL DRA

Según (March, (2010)) Afirma que Las Fases Son.

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 la 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 Procesos

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 DRA asume la utilización de técnicas de cuarta generación. En lugar de crear software con lenguajes de programación de tercera generación, el proceso DRA trabaja para volver a utilizar componentes de programas ya existentes (cuando es posible) o a crear componentes reutilizables (cuando sea necesario).

Pruebas de Entrega

Como el proceso DRA enfatiza la reutilización, ya se han comprobado muchos de los componentes de los programas. Esto reduce tiempo de pruebas.

Sin embargo, se deben probar todos los componentes nuevos y se deben ejercitar todas las interfaces a fondo.

Ventajas y desventajas del "DRA"

Según (Lorences González, (2003)) Afirma Que Las: Los entregables pueden ser fácilmente trasladados a otra plataforma, El desarrollo se realiza a un nivel de abstracción mayor, Entrega temprana al cliente, Compromiso del cliente con el sistema, 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.

Y sus Desventajas son: Tiene inconvenientes para proyectos grandes, necesita suficientes recursos humanos para crear el número correcto de equipos, Si los desarrolladores y clientes no se comprenden con las actividades necesarias para completar el sistema, los proyectos fallarán, Un alto costo de herramientas integradas y equipo necesario, Progreso más difícil de medir, Menos eficiente y con menor precisión científica.

Modelo de proceso evolutivo del software

MODELOS EVOLUTIVOS

¿Qué es un modelo de desarrollo?

Según (Pressman, (1988)) Afirma que un modelo de desarrollo es una representación abstracta de un proceso de software, cada modelo representa el proceso de desarrollo de software de una manera en particular. A pesar de estar definidos claramente, no representan necesariamente la realidad de cómo se debe desarrollar el software, sino que establece un enfoque común. Un modelo puede ser modificado y adaptado de acuerdo a las necesidades del software en desarrollo.

En forma general podemos clasificar los modelos de desarrollo en 3 grupos:

1. El modelo en cascada. Considera las actividades fundamentales del proceso de especificación, desarrollo, validación y evolución, y los representa como fases separadas del proceso, tales como la especificación de requerimientos, el diseño del software, la implementación, las pruebas, etcétera.

2. Desarrollo evolutivo. Este enfoque entrelaza las actividades de especificación, desarrollo y validación. Un sistema inicial se desarrolla rápidamente a partir de especificaciones abstractas. Éste se refina basándose en las peticiones del cliente para producir un sistema que satisfaga sus necesidades.

3. Ingeniería del software basada en componentes. Este enfoque se basa en la existencia de un número significativo de componentes reutilizables. El proceso de desarrollo del sistema se enfoca en integrar estos componentes en el sistema más que en desarrollarlos desde cero.

Aunque existen muchos tipos de modelos de desarrollo, de forma genérica la mayoría está clasificada en una de estas 3 categorías, y estos a pesar de ser diferentes a veces son usados de manera simultáneamente especialmente en sistemas grandes.

DESARROLLO EVOLUTIVO

Según (Sommerville, (2005)) Afirma que el desarrollo evolutivo consta del desarrollo de una versión inicial que luego de exponerse se va refinando de acuerdo de los comentarios o nuevos requerimientos por parte del cliente o del usuario final. Las fases de especificación, desarrollo y validación se entrelazan en vez de separarse.

Existen dos tipos de desarrollo evolutivo:

1. Desarrollo exploratorio donde el objetivo del proceso es trabajar con el cliente para explorar sus requerimientos y entregar un sistema final. El desarrollo empieza con las partes del sistema que se comprenden mejor. El sistema evoluciona agregando nuevos atributos propuestos por el cliente.

2. Prototipos desechables donde el objetivo del proceso de desarrollo evolutivo es comprender los requerimientos del cliente y entonces desarrollar una definición mejorada de los requerimientos para el sistema. El prototipo se centra en experimentar con los requerimientos del cliente que no se comprenden del todo.

Desde el punto de vista de desarrollo de sistema el enfoque evolutivo suele traer más ventajas en comparación con un enfoque en cascada ya que el sistema se va ajustando a las necesidades del cliente, a la vez que él mismo entiende mejor sus propios requerimientos. Sin embargo el enfoque evolutivo desde una perspectiva de ingeniería y gestión suele tener dos grandes problemas:

1. El proceso no es visible. Los administradores tienen que hacer entregas regulares para medir el progreso. Si los sistemas se desarrollan rápidamente, no es rentable producir documentos que reflejen cada versión del sistema.

2. A menudo los sistemas tienen una estructura deficiente. Los cambios continuos tienden a corromper la estructura del software. Incorporar cambios en él se convierte cada vez más en una tarea difícil y costosa.

Aunque supone grandes ventajas el desarrollo evolutivo solo es recomendado para sistemas pequeños y medianos. En los sistemas grandes, los constantes cambios en el desarrollo solo dificultan la estabilidad y la integración de los avances de los distintos grupos de trabajo que puedan existir. La mayoría de las empresas que desarrollan grandes sistemas usan un modelo mixto que usa las mayores fortalezas de los enfoques evolutivos y de cascada.

Tipos de modelos evolutivos del software

MODELO ESPIRAL

Según (Barajas Saavedra, (2007)) Afirma que es un modelo de desarrollo evolutivo propuesto por Barry Boehm, que utiliza prototipos como apoyo. La forma de espiral representa una iteración (repetición) de procesos que, a medida que se van entregando prototipos y éstos son revisados por los clientes o usuarios finales, el tiempo empleado para desarrollar la próxima versión es cada vez mayor. Cada división recibe el nombre de región de tareas.

Aunque el modelo espiral representa ventajas por sobre el desarrollo lineal, el cálculo de los riesgos puede ser muy complicado y no es tan usado en la realidad.

MODELO ESPIRAL WINWIN (GANA & GANA)

Una variante interesante del Modelo Espiral es el Modelo espiral Win-Win. El Modelo Espiral previo (clásico) sugiere la comunicación con el cliente para fijar los requisitos, en que simplemente se pregunta al cliente qué necesita y él proporciona la información para continuar, sin embargo, esta es una situación que rara vez ocurre. Normalmente el cliente y desarrollador entran en una negociación, se negocia coste frente a funcionalidad, rendimiento, calidad, etc.

Las mejores negociaciones se fuerzan en obtener «Victoria & Victoria» (Win & Win), es decir que el cliente gane obteniendo el producto que lo satisfaga, y el desarrollador también gane consiguiendo presupuesto y fecha de entrega realista. Evidentemente, este modelo requiere fuertes habilidades de negociación.

MODELO DE DESARROLLO CONCURRENTE

Es un modelo de tipo de red donde todas las personas actúan simultáneamente o al mismo tiempo.

Davis Sitaram ha descrito el modelo de desarrollo concurrente, llamado algunas veces ingeniería concurrente, de la siguiente forma:

Los gestores de proyectos que siguen los pasos del estado del proyecto en lo que se refiere a las fases importantes [del ciclo de vida clásico] no tiene ideal del estado de sus proyectos. Estos son ejemplos de un intento por seguir los pasos extremadamente simples. Tenga en cuenta que aunque un proyecto [grande] este en la fase de codificación, hay personal de ese proyecto implicado en actividades asociadas generalmente a muchas fases de desarrollo simultáneamente. Por ejemplo,…el personal está escribiendo requisitos diseñando, codificando, haciendo pruebas y probando la integración (todo al mismo tiempo). Los modelos de proceso de ingeniería del software de Humphrey y Kellner han mostrado la concurrencia que existe para actividades que ocurren para cualquier fase. El trabajo más reciente de Kellner utiliza diagramas de estado para representar la relación concurrente que existe entre actividades asociadas a un acontecimiento especifico, pero falla en capturar la riqueza de la concurrencia que existe en todas las actividades del desarrollo y de gestión del software en mi proyecto…La mayoría de los modelos de procesos de desarrollo del software son dirigido por el tiempo; cuanto más tarde sea, más atrás se encontrara en el proceso de desarrollo. (Un modelo de proceso concurrente) está dirigido por las necesidades del usuario, las decisiones de la gestión y los resultados de las revisiones.

MODELO INCREMENTAL

El modelo incremental es una unión de las mejores funcionalidades del modelo de cascada y del modelo de prototipos. A medida que se presenta un prototipo se produce un "incremento", que es una iteración del proceso anterior pero aplicando las experiencias aprendidas del proceso anterior. A diferencia del modelo de prototipos, los prototipos de este modelo están orientados a ser operacionales en cada incremento y no ser solo una "previa" de cómo sería el sistema en su versión final.

TIPOS DE DESARROLLO

Los evolutivos son modelos iterativos, permiten desarrollar versiones cada vez más completas y complejas, hasta llegar al objetivo final deseado; incluso evolucionar más allá, durante la fase de operación. Los modelos "Iterativo Incremental" y "Espiral" (entre otros) son dos de los más conocidos y utilizados del tipo evolutivo.

La idea detrás de este modelo es el desarrollo de una implantación del sistema inicial, exponerla a los comentarios del usuario, refinarla en N versiones hasta que se desarrolle el sistema adecuado. Una ventaja de este modelo es que se obtiene una rápida realimentación del usuario, ya que las actividades de especificación, desarrollo y pruebas se ejecutan en cada iteración.

EXISTEN DOS TIPOS DE DESARROLLO EVOLUTIVO

Según (Gil, (2006)) Afirma que existen 2 tipos de desarrollo evolutivo

Desarrollo Exploratorio: El objetivo de este enfoque es explorar con el usuario los requisitos hasta llegar a un sistema final. El desarrollo comienza con las partes que se tiene más claras. El sistema evoluciona conforme se añaden nuevas características propuestas por el usuario.

Enfoque utilizando prototipos: El objetivo es entender los requisitos del usuario y trabajar para mejorar la calidad de los requisitos. A diferencia del desarrollo exploratorio, se comienza por definir los requisitos que no están claros para el usuario y se utiliza un prototipo para experimentar con ellos. El prototipo ayuda a terminar de definir estos requisitos.

VENTAJAS

• La especificación puede desarrollarse de forma creciente.

• Los usuarios y desarrolladores logran un mejor entendimiento del sistema. Esto se refleja en una mejora de la calidad del software.

• Es más efectivo que el modelo de cascada, ya que cumple con las necesidades inmediatas del cliente.

DESVENTAJAS

• Proceso no Visible: Los administradores necesitan entregas para medir el progreso. Si el sistema se necesita desarrollar rápido, no es efectivo producir documentos que reflejen cada versión del sistema.

• Sistemas pobremente estructurados: Los cambios continuos pueden ser perjudiciales para la estructura del software haciendo costoso el mantenimiento.

• Se requieren técnicas y herramientas: Para el rápido desarrollo se necesitan herramientas que pueden ser incompatibles con otras o que poca gente sabe utilizar.

Bibliografía

GONZÁLEZ, M. D. ((2001)). Convivencia de la prensa escrita y la prensa on line en su transición hacia el modelo de comunicación multimedia. Estudios sobre el mensaje periodístico, 7, 71-78.

De Armas Ramírez, N. L. ( (2003)). Caracterización y diseño de los resultados científicos como aportes de la investigación educativa. Evento Internacional Pedagogía, 40.

March, A. F. ((2010)). La evaluación orientada al aprendizaje en un modelo de formación por competencias en la educación universitaria. REDU: Revista de Docencia Universitaria, 8(1), 11-35.

Lorences González, J. &. ( (2003)). Caracterización y diseño de los resultados científicos como aportes de la investigación educativa. Evento Internacional Pedagogía, 40.

Pressman, R. S. ((1988)). Ingeniería del software.

Sommerville, I. ((2005)). Ingeniería del software. Pearson Educación.

Gil, R. A. ( (2006)). Estructura básica del proceso unificado de desarrollo de software. Sistemas & Telemática, 2(3).

Autor:

Luiggi Macias Parrales.

Efrain Mero Delgado.

Edison Yosa Segovia.

Marjorie Parrales Pincay.