MODELO
DE DESARROLLO RAPIDO DE APLICACIONES
El desarrollo rápido de aplicaciones o DRA (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.
Tradicionalmente, el desarrollo rápido de aplicaciones tiende
a englobar también la usabilidad, utilidad y la rapidez de ejecución.
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 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 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.
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.
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 modular 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.
Ventajas de DRA
Ø 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. Ingeniería de Software
Ø 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 de DRA
Ø 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.
No hay comentarios:
Publicar un comentario