El objetivo de este trabajo es conocer el R.A.

D el acrnimo en ingls seria

RAPID APLICATION DEVELOPED o en espaol seria DESARROLLO RAPIDO DE
APLICACIONES, este es un proceso de desarrollo de software inicialmente
creado por James Martin en el ao de 1980, el mtodo comprende el
desarrollo interactivo, la construccin de prototipo y el uso de las utilidades de
Computer Aided Software Engineering

o mas conocidos como las

herramientas CASE.
Tradicionalmente el desarrollo rpido de aplicaciones tiende a englobar la
tambin la usabilidad, la utilidad de la rapidez de la ejecucin. Hoy en da se
suele utilizar para referirnos al desarrollo rpido de interfaces grficos de
usuarios tales como glaces o entorno de desarrollo integrados. Alguna de la
plataformas para este tipo de emitir documentos es el lazarus, foxpro y las ms
conocidos son visual studio, asi mismo tambin podemos hablar de la
exigencias

de

las

pginas

web

actuales,

entre

estas

encontramos

ESTANDARIZACION , MANTENIMIENTO, ESTABILIDAD, USABILIDAD para que sea

algo optimo con el fin de que pueda adaptarse con el menor esfuerzo a un
nuevo requerimiento y que nos permita facilitar la solucin viable de los errores
en un corto plazo .
Tambin en el RAD existe un trmino conocido como FRAMEWORK, define
generalmente

en

trminos

generales

un

conjunto

estandarizado

de

conceptos, prcticas y criterios para enfocar un tipo de problema en

particular que sirve como referencia para enfrentar y resolver nuevos
problemas de ndole similar. El desarrollo de software, un FRAMEWORK o
infraestructura digital, es una estructura conceptual y tecnolgica de soporte
definido normalmente con artefactos o mdulos de software concretos, con
base a lo cual otro proyecto de software puede ser ms fcilmente
organizado y desarrollado. Tpicamente esto puede incluir un soporte de
programas, bibliotecas y un lenguaje interpretado entre otras herramientas
para as ayudar a desarrollar y unir los

diferentes componentes de un

proyecto. Tambin de igual forma podemos decir que FRAMEWORK una

arquitectura de software que modela las relaciones generales de las entidades
del dominio y provee una especial metodologa de trabajo, la cual extiende o
utiliza las aplicaciones del dominio. Esta definicin fue tomada de WIKIPEDIA o
enciclopedia libro.
En nuestro tema un FRAMEWORK es un marco de trabajo diseado para
facilitar el desarrollo proporcionado de tareas, recurrente, abrumadoras,
aburridas de una manera para que sea ms fcil u automatizada.

SYMFONY es un framework para desarrollar todas la aplicaciones en PHP.

Algunas herramientas que encontramos en la utilizacin del desarrollo rpido
de aplicaciones son: El sistema de control de versiones, las herramientas case
de modelados,

sistemas de gestin online, framework de desarrollo y

framework de diseo.
Ahora voy a realizar en la pizarra de forma de cascada de los diferentes
modelos que se utilizaran en ello encontramos primero la palabra
MODELADO
Modelo de Gestin
Modelo de Datos
Modelo de Proceso
Generacin de aplicaciones
Pruebas y volmenes
Vamos a explicar que significa cada uno de estos componentes:
EL MODELADO DE GESTION, tambin pude ser el modelado de negocios, es el
flujo de informacin entre las funciones de las empresas, se define
respondiendo a preguntas como QUE INFORMACION, es el motor de procesos
del negocio para poder saber qu es lo que se genera o donde va la
informacin y cul es el proceso y as sucesivamente.
EL MODELADO DE DATOS, aqu encontramos la informacin recogida a partir
de un modelo de negocio para que pueda ser refinado en un conjunto de
objetos de datos a las cuales podemos llamarlas entidades que se necesitan
para apoyar el negocio, los atributos o los caracteres de cada entidad se
identifican y la relacionan entre esos objetos de datos (entidades).
EL MODELADO DE PROCESOS, el objetivo de datos definidos en la parte de
modelados de datos se transforman para lograr el flujo de informacin
necesaria para implementar una funcin de negocio, descripcin de
procesamiento y de all se crea para aadir, modificar , eliminar , o recuperar
un objeto de datos.
GENERACION

DE

APLICACIONES,

aqu

utilizamos

las

herramientas

automatizadas que se utilizan para facilitar la construccin del software.

PRUEBAS Y VOLUMENES, decimos que muchos componentes de programacin
ya han sido sometidos a prueba desde la reutilizacin de en el nfasis del
desarrollo rpido de aplicaciones. Esto reduce el tiempo real de los ensayos,

pero los nuevos componentes deben ser probados y todas la interfaces deben
entenderse plenamente.
Entonces en este proceso en cascada es un proceso de desarrollo de software
que permiten construir sistemas utilizables en poco tiempo normalmente esto
se puede desarrollar entre 60 a 90 das.
PROBLEMAS QUE PUEDE SER TENDIDOS POR EL DESARROLLO RPIDO DE
APLICACIONES
Son tres puntos vamos hablar de los Mtodos tradicionales, con estos pasan un
gran lapso de tiempo antes que el cliente vea el resultado. Por ejemplo el
cliente solicita realizar una aplicacin y si no usamos el desarrollo rpido de
aplicaciones el cliente se cansara de esperar y buscar a otro ingeniero que si
lo aplique y le d una solucin pronta incluso a un menor costo. Segundo el
desarrollo llega a tardar tanto que para cuando el sistema est listo para
usarse los procesos del cliente han cambiado radicalmente, podemos tomar
del ejemplo anterior y agregar que como no le hemos entregado nada al
cliente los requerimientos del mismo puede variar radicalmente. Y tercero no
hay nada hasta que el 100% del proceso del desarrollo se ha aplicado. De
igual forma no se puede entregar por partes el software sino hasta que este
est terminado al 100% .
EL DESARROLLO RPIDO DE APLICACIONES TIENE UNA MAYOR POSIBILIDAD DE
XITO, si el cliente est dispuesto a negociar precio y calidad, pero hay que
tener en cuenta que negociar calidad no significa una mayor tasa de fallas si
no un producto con menos funciones o que sea menos eficiente por eso
decimos que no todo puede ser excelente pues tambin encontramos una o
ms metas de las cuales pueden ser inalcanzables, el menor nmero de fallas
los programadores pueden no tener la posibilidad de corregir en algunos
componentes de terceros, el nivel ms alto de satisfaccin del cliente algunos
requisitos secundarios pueden ser sacrificados en aras de calendario y el
menor costo de desarrollo pues comprar herramientas y componentes pueden
ser ms caras que desarrollarlos.
CUATRO CARACTERISTICAS DEL DESARROLLO RPIDO DE APLICACIONES, que
son EQUIPOS HIBRIDOS, compuesto por alrededor de 6 personas, incluyendo los
desarrolladores y usuarios pero tienen que ser de tiempo completo del sistema
as como aquellas personas involucradas con los requisitos, los programadores
de RAD, deben ser analistas, diseadores y programadores todo en uno.
HERRAMIENTAS ESPECIALIZADAS, aqu encontramos el desarrollo visual la
creacin de prototipos falsos y los componentes de resultados TIMEBOXING,

son las opciones secundarias que son eliminadas como den lugar para cumplir
con el calendario
DESARROLLO RPIDO DE APLICACIONES, tiende a funcionar cuando una
aplicacin funcionara de manera independiente se pueden usar bibliotecas
mayormente ya existentes.
EL DESARROLLO RPIDO DE APLICACIONES, tiende a fallar cuando la aplicacin
debe inter operar como sistemas ya existente.
Las etapas de un ciclo de vida de un software son:

Inicio: ste es el nacimiento de la idea. Aqu definimos los objetivos del

proyecto y los recursos necesarios para su ejecucin. Hacia dnde
queremos ir, y no cmo queremos ir. Las caractersticas implcitas o
explcitas de cada proyecto hacen necesaria una etapa previa destinada
a obtener el objetivo por el cual se escribirn miles o cientos de miles de
lneas de cdigo. Un alto porcentaje del xito de nuestro proyecto se
definir en estas etapas que, al igual que la etapa de debugging, muchos
lderes de proyecto subestiman.

Planificacin: idearemos un planeamiento detallado que gue la gestin

del proyecto, temporal y econmicamente.

Implementacin: acordaremos el conjunto de actividades que componen

la realizacin del producto.

Puesta en produccin: nuestro proyecto entra en la etapa de definicin, all

donde se lo presentamos al cliente o usuario final, sabiendo que funciona
correctamente y responde a los requerimientos solicitados en su momento.
Esta etapa es muy importante no slo por representar la aceptacin o no
del proyecto por parte del cliente o usuario final sino por las mltiples
dificultades

que

suele

presentar

en

la

prctica,

alargndose

excesivamente y provocando costos no previstos.

Control en produccin: control del producto, analizando cmo el proceso

difiere o no de los requerimientos originales e iniciando las acciones
correctivas si fuesen necesarias. Cuando decimos que hay que corregir el
producto,

hacemos

referencia

pequeas

desviaciones

de

los

requerimientos originales que puedan llegar a surgir en el ambiente

productivo. Si nuestro programa no realiza la tarea para lo cual fue creada,
esta etapa no es la adecuada para el rediseo. Incluimos tambin en esta

etapa el liderazgo, documentacin y capacitacin, proporcionando

directivas a los recursos humanos, para que hagan su trabajo en forma
correcta y efectiva.
Objetivos de cada etapa:

Expresin de necesidades: Esta etapa tiene como objetivo el armado de

un documento en el cual se reflejan los requerimientos y funcionalidades
que ofrecer al usuario el sistema a implementar (qu, y no cmo, se va a
implementar).

Especificaciones: Formalizamos los requerimientos; el documento obtenido

en la etapa anterior se tomar como punto de partida para esta etapa.

Anlisis: Determinamos los elementos que intervienen en el sistema a

desarrollar, su estructura, relaciones, evolucin temporal, funcionalidades,
tendremos una descripcin clara de qu producto vamos a construir, qu
funcionalidades aportar y qu comportamiento tendr.

Diseo: Ya sabemos qu hacer, ahora tenemos que determinar cmo

debemos hacerlo (cmo debe ser construido el sistema en cuestin?);
definimos en detalle entidades y relaciones de las bases de datos,
seleccionamos el lenguaje que vamos a utilizar, el Sistema Gestor de Bases
de Datos, entre otros).

Implementacin: Empezamos a codificar algoritmos y estructuras de datos,

definidos en las etapas anteriores, en el correspondiente lenguaje de
programacin o para un determinado sistema gestor de bases de datos. En
muchos proyectos se pasa directamente a esta etapa; son proyectos muy
arriesgados que adoptan un modelo de ciclo de vida de code & fix
(codificar y corregir) donde se eliminan las etapas de especificaciones,
anlisis y diseo con la consiguiente prdida de control sobre la gestin del
proyecto.

Debugging (Depuracin): El objetivo de esta etapa es garantizar que

nuestro programa no contiene errores de diseo o codificacin. En esta
etapa no deseamos saber si nuestro programa realiza lo que solicit el
usuario, esa tarea le corresponde a la etapa de implementacin. En sta
deseamos encontrar la mayor cantidad de errores. Todas los programas
contienen errores: encontrarlos es cuestin de tiempo. Lo ideal es encontrar

la mayora, si no todos, en esta etapa. Tambin se pueden agregar

pruebas de rendimiento.

Validacin: Esta etapa tiene como objetivo la verificacin de que el

sistema

desarrollado

cumple

con

los

requerimientos

expresados

inicialmente por el cliente y que han dado lugar al presente proyecto. En

muchos proyectos las etapas de validacin y debugging se realizan en
paralelo por la estrecha relacin que llevan. Sin embargo, tenemos que
evitar la confusin: podemos realizarlos en paralelo, pero no como una
nica etapa.

Evolucin: En la mayora de los proyectos se considera esta etapa como

Mantenimiento y evolucin, y se le asigna, no slo el agregado de nuevas
funcionalidades (evolucin); sino la correccin de errores que surgen
(mantenimiento). En la prctica esta denominacin no es del todo errnea,
ya que es posible que aun luego de una etapa de debugging y validacin
exhaustiva, se filtren errores.

Etapas
La ingeniera de software requiere llevar a cabo numerosas tareas, dentro de etapas
como las siguientes:
Anlisis de requisitos
Extraer los requisitos de un producto software es la primera etapa para crearlo.
Mientras que los clientes piensan que ellos saben lo que el software tiene que hacer,
se requiere habilidad y experiencia en la ingeniera del software para reconocer
requisitos incompletos, ambiguos o contradictorios. El resultado del anlisis de
requisitos con el cliente se plasma en el documento Especificacin de Requisitos.
Asimismo, se define un diagrama de entidad/relacin, en el que se plasman las
principales entidades que participarn en el desarrollo de software.
La captura, anlisis y especificacin de requisitos (incluso pruebas de ellos), es una parte
crucial; de esta etapa depende en gran medida el logro de los objetivos finales. Se han ideado
modelos y diversos procesos de trabajo para estos fines. Aunque an no est formalizada, se
habla de la Ingeniera de Requisitos.
La IEEE Std. 830-1998 normaliza la creacin de las especificaciones de requisitos
software.
Especificacin

Es la tarea de escribir detalladamente el software a ser desarrollado, en una forma

matemticamente rigurosa. En la realidad, la mayora de las buenas especificaciones
han sido escritas para entender y afinar aplicaciones que ya estaban desarrolladas.
Las especificaciones son ms importantes para las interfaces externas, que deben
permanecer estables.
Diseo y arquitectura
Se refiere a determinar cmo funcionar el software de forma general sin entrar en
detalles. Consisten en incorporar consideraciones de la implementacin tecnolgica,
como el hardware, la red, etc. Se definen los casos de uso para cubrir las funciones
que realizar el sistema, y se transformarn las entidades definidas en el anlisis de
requisitos en clases de diseo, obteniendo un modelo cercano a la programacin
orientada a objetos.
Programacin
Reducir un diseo a cdigo puede ser la parte ms obvia del trabajo de ingeniera del
software, pero no necesariamente es la que demanda mayor trabajo ni la ms
complicada. La complejidad y la duracin de esta etapa est ntimamente relacionada
al o a los lenguajes de programacin utilizados, as como al diseo previamente
realizado.
Prueba
Consiste en comprobar que el software realice correctamente las tareas indicadas en
la especificacin del problema. Una tcnica de prueba es probar por separado cada
mdulo del software y luego probarlo de forma integral, para as llegar al objetivo. Se
considera una buena prctica que las pruebas sean efectuadas por alguien distinto al
desarrollador que la program.
Mantenimiento
Mantener y mejorar el software para solventar errores descubiertos y tratar con nuevos
requisitos. El mantenimiento puede ser de cuatro tipos: perfectivo (mejorar la calidad
interna de los sistemas), evolutivo (incorporaciones, modificaciones y eliminaciones
necesarias en un producto software para cubrir la expansin o cambio en las
necesidades del usuario), adaptativo (modificaciones que afectan a los entornos en los
que el sistema opera, por ejemplo, cambios de configuracin del hardware, software
de base, gestores de base de datos, comunicaciones) y correctivo (correccin de
errores).