INTRODUCCIÓN

La metodología de desarrollo conocida como diseño rápido de aplicaciones RAD (por

sus siglas en inglés) ha tomado gran auge debido a la necesidad que tienen las
instituciones de crear aplicaciones funcionales en un plazo de tiempo corto. Esta
modalidad de desarrollo consiste de diferentes etapas que suceden de forma paralela y
exigen la colaboración de los usuarios en todos los niveles. Por el contario, en la
metodología de diseño tradicional, las etapas suceden de forma lineal y el usuario es
excluido del proceso, lo que hace que esta modalidad sea más lenta y poco eficiente.
Hoy día la competencia en el mercado demanda calidad lo más pronto posible y RAD se
enfoca en estas características.

LA METODOLOGÍA DE DISEÑO RÁPIDO DE APLICACIONES

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.

LAS CUATRO ETAPAS DEL CICLO 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 cuales 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 finalizan 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 implementació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.

CARACTERÍSTICAS DE RAD

• 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. 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 interactuan con estas herramientas por
medio de diagramas.

El propósito de las herramientas "CASE" es aligerar el proceso

de diseño y a su vez disminuir los costos de desarrollo sin
sacrificar la calidad del producto.

• Calidad

La calidad de un sistema se mide en términos de hasta qué

punto ese sistema cumple con los requisitos de la compañía y
sus usuarios al momento que se implementa. 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.

ITINERARIO vs ECONOMÍA vs CALIDAD DE PRODUCTO

Una aplicación desarrollada con el método RAD es muy

probable que se instale con éxito si el cliente está dispuesto a
negociar economía, calidad o ambas. Negociar la calidad del
producto no significa aceptar un producto con un porciento
más alto de defecto sino que el sistema se desarrollará con
menos características especiales y diseños particulares. Si el
cliente es capaz de negociar uno o ambos componentes es
muy probable que se desarrolle un sistema eficiente que
cumpla con las funciones del usuario en poco tiempo.

La reducción en tiempo de desarrollo una vez se ha negociado

la calidad del sistema debe representar una reducción en el
costo por labor de los recursos humanos.

Por el contrario, el diseño de sistemas bajo la metodología

tradicional envuelve una intensa labor de profesionales de la
informática para crear sistemas altamente específicos que por
lo general toman años en completar y los costos son muy
altos. El hecho de que bajo esta metodología los sistemas se
creen justo al diseño del comprador, no significa que el
producto sea exitoso. Al momento de implementar el sistema
por lo general, ha pasado tanto tiempo que las necesidades
del cliente han cambiado considerablemente.

CONCLUSIÓN

Sin duda, hoy día el uso de la metodología de diseño rápido

de aplicaciones ha adquirido mucha popularidad en el campo
de la informática. Es posible asegurar un resultado exitoso si
los proyectos se desarrollan para cumplir con un itinerario
estricto y sacrificando algún tipo de funcionalidad. Esto le
permite al equipo de desarrolladores enfocarse en las
funciones realmente importantes de la institución y trabajar
con ellas rápidamente.

Los cambios son la razón principal por la cual hay tantos

atrasos. Bajo el diseño lineal o tradicional, los cambios de
enfoque y funciones luego que se ha invertido mucho tiempo
en la planificación, diseño, desarrollo y pruebas causan que
muchos meses de trabajo se pierdan. Por consecuente, los
costos aumentan al tener que invertir tiempo adicional
rediseñado.

La metodología RAD integra los usuarios y ejecutivos de una

institución en los equipos de analistas para que los diseños,
modificaciones y pruebas de los sistemas se den durante todo
el proceso. De esta manera se acorta el ciclo de desarrollo y
se disminuyen los costos asociados con los cambios.

LISTA DE REFERENCIA

Maner, Walter. "Rapid Application Development". Revisado el

15 de marzo de 1997. URL:
http://www.fortunecity.com/banners/interstitial.html?
http://csweb.cs.bgsu.edu/maner/domains/RAD.htm (1 de
octubre de 2000).

Calvert, David. "Rapid Application Development". Revisado el

5 de junio de 1996.
URL:http://www.fortunecity.com/banners/interstitial.html?
http://hebb.cis.uoguelph.ca/~dave/27320/new/rad.html (1 de
octubre de 2000).

Tate, Priscilla. " Shooting the Application Development Rapid".

eWeek. 26 de septiembre de 1998.
URL:http://www.fortunecity.com/banners/interstitial.html?
http://www.zdnet.com/devhead/stories/articles/0,4413,1600296,00.ht
ml (1 de octubre de 2000).

University of California, Davis. "Application Development

Methology-Rapid Application Development". 16 de abril de
2000.

URL: http://www.fortunecity.com/banners/interstitial.html?
http://sysdev.ucdavis.edu/WEBADM/document/rad-toc.htm (1
de octubre de 2000).
B2 Systems, Inc. "Rapid Application Development". 1999.

URL: http://www.fortunecity.com/banners/interstitial.html?
http://wwwb2systems.com/rad.html (24 de septiembre de
2000).