Rapid Aplication Development
Introducción
Este
documento contiene información a cerca del método RAD por su acrónimo en ingles
de Rapid Aplication Development en español Desarrollo Rápido de Aplicaciones,
esto es importante conocerlo para la introducción al estudio de ingeniería de
software.
Este
método fue desarrollado inicialmente por James Martin en 1980, hoy en día se
suele utilizar para referirnos al desarrollo rápido de interfaces graficas de
usuario tales como Glade o entornos de desarrollo integrados completos. Algunas
plataformas comunes son Visual Studio, Delphi, Anjunta entre otros.
También
este documento se introdujo una breve historia de lo que fue RAD, así como
también ventajas y desventajas, la apreciación global, la efectividad del RAD,
una crítica sobre este modelo y las implicaciones prácticas con las
metodologías rápidas de desarrollo.
El modelo RAD o DRA
El
Desarrollo Rápido de Aplicaciones (DRA) (rapid application 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 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. Cuando se utiliza principalmente para aplicaciones
de sistemas de información, el enfoque DRA comprende las siguientes fases:
- 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 al 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 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). En todos los casos se utilizan herramientas automáticas para facilitar la construcción del software.
Apreciación global
El
Desarrollo de la Aplicación rápido es una metodología de desarrollo de software
que involucra las técnicas gusta el desarrollo reiterativo y prototyping del
software. Según Whitten (2004), es una fusión de varias técnicas estructuradas,
el Información Diseñando sobre todo datos-manejado, con las técnicas del
prototyping para acelerar el desarrollo de sistemas de software.
En el
Desarrollo de la Aplicación Rápido, se usan técnicas estructuradas y
prototyping sobre todo definir los requisitos de usuarios y diseñar el último
sistema. Las salidas de proceso de desarrollo con el desarrollo de datos
preliminares planean y modelos del proceso comerciales que usan las técnicas
estructuradas. En la próxima fase, se verifican los requisitos usando el
prototyping, en el futuro refinar a los datos y modelos del proceso. Estas
fases se repiten el iteratively; más allá los resultados de desarrollo en
"un requisitos comerciales combinados y la declaración del plan técnica
ser usado por construir los nuevos sistemas".
Los
acercamientos de RAD pueden traer consigo los compromisos en la funcionalidad y
actuación en cambio de por habilitar desarrollo más rápido y el mantenimiento
de la aplicación facilitando el desarrollo.
Historia
del RAD
El
Desarrollo de la Aplicación rápido es originalmente que un término usó para
describir un proceso de desarrollo de software introducido por James Martin en
1991. La metodología de Martin involucra el desarrollo reiterativo y la
construcción de prototipos. Más recientemente, el término y su sigla han
llegado a ser usadas en un sentido más ancho, genérico que abarca una variedad
de técnicas apuntado a acelerar el desarrollo de la aplicación, como el uso de
armazones de aplicación de tejido y otros tipos de armazones del software.
El
desarrollo de la aplicación rápido era una contestación a procesos non-ágiles
desarrollados en los años setenta, como el Análisis de los Sistemas
Estructurado y Método del Plan y otros modelos de la Cascada. Un problema con
las metodologías anteriores era que las aplicaciones tomaron tan largo
construir que los requisitos habían cambiado antes del sistema que estaba
completo, mientras resultando en inadecuado o incluso los sistemas
inutilizables. Otro problema era la asunción que una fase de análisis de
requisitos metódica identificaría todos los requisitos críticos exclusivamente.
La amplia evidencia atesta al hecho que éste raramente es el caso, incluso para
los proyectos con los profesionales muy experimentados en absoluto los niveles.
Empezando
con las ideas de Brian Gallagher, Alex Balchin, Barry Boehm y Scott Shultz,
James Martin desarrolló el acercamiento de Desarrollo de Aplicación Rápido
durante los años ochenta a IBM y finalmente lo formalizó publicando un libro en
1991, el Desarrollo de la Aplicación Rápido.
Efectividad del RAD
El cambio
del desarrollo del client/server sesión-basado tradicional para abrir
sessionless y el desarrollo colaborador como Tejido 2.0 ha aumentado la
necesidad por las iteraciones más rápidas a través de las fases del SDLC. Esto,
acoplado con la utilización creciente de armazones de la fuente abiertos y
productos en el centro el desarrollo comercial, tiene, para muchos diseñadores,
interés vuelto a encender encontrando una bala color de plata la metodología de
RAD.
Aunque la
mayoría de las metodologías de RAD el software adoptivo re-usa, estructura del
equipo pequeña y desarrollo del sistema distribuido, la mayoría de los
practicantes de RAD reconoce que, hay finalmente, ningún solo “el rápido”
metodología que puede proporcionar un orden de mejora de magnitud encima de
cualquier otra metodología de desarrollo.
Todos
condimentan de RAD tiene el potencial por proporcionar a un armazón bueno para
el desarrollo del producto más rápido la calidad del código mejorada, pero la
aplicación exitosa y beneficios ponen goznes a menudo en el tipo del proyecto,
fije, ciclo de descargo de software y cultura de la sociedad. También puede ser
de interés que algunos de los vendedores del software más grandes como
Microsoft e IBM no utilizan RAD extensivamente en el desarrollo de sus
productos del buque insignia y por la mayor parte, ellos confían en las
metodologías de la cascada tradicionales todavía principalmente con algún grado
de moverse en espiral.
Critica del RAD
Desde que
el desarrollo de la aplicación rápido es un proceso reiterativo e incremental,
puede llevar a una sucesión de prototipos que nunca culminan en una aplicación
de la producción satisfactoria. Pueden evitarse los tales fracasos si las
herramientas de desarrollo de aplicación son robustas, flexibles, y puede
ponerse al uso apropiado. Esto se dirige en los métodos como el 2080 método de
Desarrollo u otras variantes poste-ágiles.
Implicaciones prácticas con las metodologías de desarrollo rápidas
Cuando las
organizaciones adoptan las metodologías de desarrollo rápidas, el cuidado debe
tenerse para evitar papel y confusión de responsabilidad y avería de
comunicación dentro del equipo de desarrollo, y entre el equipo y el cliente.
Además, sobre todo en casos dónde el cliente está ausente o no capaz para
participar con la autoridad en el proceso de desarrollo, el analista del
sistema debe ser dotado de esta autoridad en nombre del cliente para asegurar
prioritisation apropiado de requisitos non-funcionales. Además, ningún
incremento del sistema debe desarrollarse sin un completo y formalmente
documentó la fase del plan.
Bibliografía
Páginas de internet:
Enciclopedias:
"DRA" Microsoft® Student 2009
[DVD]. Microsoft Corporation, 2008.
Comentarios
Publicar un comentario