lunes, 14 de noviembre de 2016
INTRODUCCIÓN
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.
Modelo de
Desarrollo de Software RAD
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.
INCONVENIENTES DEL
RAD
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.
¿PORQUÉ 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.
CARACTERÍSTICAS DE
RAD
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)
"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.
VENTAJAS
ü
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
ü
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.
