miércoles, 5 de noviembre de 2008

MODELOS DE INGENIERIA DE SOFTWRE

Modelos de desarrollo de software
La ingeniería de software tiene varios modelos o paradigmas de desarrollo en los cuales se puede apoyar para la realización de software, de los cuales podemos destacar a éstos por ser los más utilizados y los más completos:

  • Modelo en cascada o Clásico (modelo tradicional)
  • Modelo en espiral (modelo evolutivo)
  • Modelo de prototipos
  • Desarrollo por etapas
  • Desarrollo iterativo y creciente o Interativo Incremental
  • RAD (Rapid Application Development)

MODELO EN CASCADA


En Ingeniería de software el desarrollo en cascada, también llamado modelo en cascada, es el enfoque metodológico que ordena rigurosamente las etapas del ciclo de vida del software, de forma tal que el inicio de cada etapa debe esperar a la finalización de la inmediatamente anterior.

Un ejemplo de una metodología de desarrollo en cascada es:


  • Análisis de requisitos
  • Diseño del Sistema
  • Diseño del Programa
  • Codificación
  • Pruebas
  • Implantación
  • Mantenimiento

De esta forma, cualquier error de diseño detectado en la etapa de prueba conduce necesariamente al rediseño y nueva programación del código afectado, aumentando los costes del desarrollo. La palabra cascada sugiere, mediante la metáfora de la fuerza de la gravedad, el esfuerzo necesario para introducir un cambio en las fases más avanzadas de un proyecto. Si bien ha sido ampliamente criticado desde el ámbito académico y la industria, sigue siendo el paradigma más seguido al día de hoy.


Fases del modelo.

Análisis de requisitos

Se analizan las necesidades de los usuarios finales del software para determinar qué objetivos debe cubrir. De esta fase surge una memoria llamada SRD (documento de especificación de requisitos), que contiene la especificación completa de lo que debe hacer el sistema sin entrar en detalles internos. Es importante señalar que en esta etapa se deben consensuar todo lo que se requiere del sistema y será aquello lo que seguirá en las siguientes etapas, no pudiéndose requerir nuevos resultados a mitad del proceso de elaboración del software.
Diseño del Sistema

Se descompone y organiza el sistema en elementos que puedan elaborarse por separado, aprovechando las ventajas del desarrollo en equipo. Como resultado surge el SDD (Documento de Diseño del Software), que contiene la descripción de la estructura relacional global del sistema y la especificación de lo que debe hacer cada una de sus partes, así como la manera en que se combinan unas con otras..

Diseño del Programa

Es la fase en donde se realizan los algoritmos necesarios para el cumplimiento de los requerimientos del usuario así como también los análisis necesarios para saber que herramientas usar en la etapa de Codificación.
Codificación

Es la fase de programación o implementación propiamente dicha. Aquí se implementa el código fuente, haciendo uso de prototipos así como pruebas y ensayos para corregir errores. Dependiendo del lenguaje de programación y su versión se crean las librerías y componentes reutilizables dentro del mismo proyecto para hacer que la programación sea un proceso mucho más rápido.

Pruebas

Los elementos, ya programados, se ensamblan para componer el sistema y se comprueba que funciona correctamente antes de ser puesto en explotación.

Implantación

El software obtenido se pone en producción. Se implantan los niveles software y hardware que componen el proyecto. La implantación es la fase con más duración y con más cambios en el ciclo de elaboración de un proyecto.

Mantenimiento

Es una de las fases finales del proyecto Durante la explotación del sistema software pueden surgir cambios, bien para corregir errores o bien para introducir mejoras. Todo ello se recoge en los Documentos de Cambios.




Variantes

Existen variantes de este modelo; especialmente destacamos la que hace uso de prototipos y en la que se establece un ciclo antes de llegar a la fase de mantenimiento, verificando que el sistema final este libre de fallos.

Desventajas
  1. En la vida real, un proyecto rara vez sigue una secuencia lineal, esto crea una mala implementación del modelo, lo cual hace que lo lleve al fracaso.
  2. Difícilmente un cliente va a establecer al principio todos los requerimientos necesarios, por lo que provoca un gran atraso trabajando en este modelo, ya que este es muy restrictivo y no permite movilizarse entre fases.
  3. Los resultados y/o mejoras no son visibles, el producto se ve recién cuando este esté finalizado, lo cual provoca una gran inseguridad por parte del cliente que anda ansioso de ver avances en el producto. Esto también implica toparse con requerimientos que no se habian tomado en cuenta, y que surgieron al momento de la implementación, lo cual provocara que se regrese nuevamente a la fase de requerimientos.

Ventajas

Se tiene todo bien organizado y no se mezclan las fases. Es perfecto para proyectos que son rígidos, y además donde se especifiquen muy bien los requerimientos y se conozca muy bien la herramienta a utilizar.


MODELO EN ESPIRAL

El Desarrollo en Espiral es un modelo de ciclo de vida desarrollado por Barry Boehm en 1985, utilizado generalmente en la Ingeniería de software. Las actividades de este modelo se conforman en una espiral, cada bucle representa un conjunto de actividades. Las actividades no están fijadas a priori, sino que las siguientes se eligen en función del análisis de riesgo, comenzando por el bucle interior.


En cada vuelta o iteración hay que tener en cuenta Los Objetivos:
  1. Que necesidad debe cubrir el producto.
  2. Alternativas: Las diferentes formas de conseguir los objetivos de forma exitosa, desde diferentes puntos de vista como pueden ser:
    Características: experiencia del personal, requisitos a cumplir, etc.
    Formas de gestión del sistema.
    Riesgo asumido con cada alternativa.
    Desarrollar y Verificar:
    Programar y probar el software.

    Si el resultado no es el adecuado o se necesita implementar mejoras o funcionalidades Se planificaran los siguientes pasos y se comienza un nuevo ciclo de la espiral.




La espiral tiene una forma de caracola y se dice que mantiene dos dimensiones, la radial y la angular:

  • Angular: Indica el avance del proyecto software dentro de un ciclo.
  • Radial: Indica el aumento del coste del proyecto, ya que con cada nueva iteración se pasa más tiempo desarrollando.
Este sistema es muy utilizado en proyectos grandes y complejos como puede ser, por ejemplo, la creación de un Sistema Operativo.
Al ser un modelo de Ciclo de Vida orientado a la gestión de riesgo se dice que uno de los aspectos fundamentales de su éxito radica en que el equipo que lo aplique tenga la necesaria experiencia y habilidad para detectar y catalogar correctamente los riesgos.

Tareas Para cada ciclo habrá cuatro actividades:

Determinar o fijar objetivos
Fijar también los productos definidos a obtener: requerimientos, especificación, manual de usuario.
Fijar las restricciones.

Identificación de riesgos del proyecto y estrategias alternativas para evitarlos.
Hay una cosa que solo se hace una vez: planificación inicial o previa.

Análisis del riesgo

Se estudian todos los riesgos potenciales y se seleccionan una o varias alternativas propuestas para reducir o eliminar los riesgos.

Desarrollar, verificar y validar (probar)

-Tareas de la actividad propia y de prueba.
-Análisis de alternativas e identificación resolución de riesgos.
-Dependiendo del resultado de la evaluación de los riesgos, se elige un modelo para el desarrollo, el que puede ser cualquiera de los otros existentes, como formal, evolutivo, cascada, etc. Así si por ejemplo si los riesgos en la interfaz de usuario son dominantes, un modelo de desarrollo apropiado podría ser la construcción de prototipos evolutivos. Si lo riesgos de protección son la principal consideración, un desarrollo basado en transformaciones formales podría ser el más apropiado.

Planificar

Revisamos todo lo hecho, evaluándolo, y con ello decidimos si continuamos con las fases siguientes y planificamos la próxima actividad.

Mecanismos de control

La dimensión radial mide el coste.
La dimensión angular mide el grado de avance del proyecto.

Variaciones del Modelo En Espiral

Modelo en Espiral Típico de seis regiones.
Modelo en espiral WIN WIN.

Ventajas

-El análisis del riesgo se hace de forma explícita y clara. Une los mejores elementos de los restantes modelos.
-Reduce riesgos del proyecto
I-ncorpora objetivos de calidad
-Integra el desarrollo con el mantenimiento, etc.
-Además es posible tener en cuenta mejoras y nuevos requerimientos sin romper con la metodología, ya que este ciclo de vida no es rígido ni estático.

Desventajas

-Genera mucho tiempo en el desarrollo del sistema
-Modelo costoso
-Requiere experiencia en la identificación de riesgos

Inconvenientes

Genera mucho trabajo adicional, y eso causa muchos problemas sobre todo si la compañía que esta produciendo el software es floja y holgazan. Cuando un sistema falla se pierde tiempo y coste dentro de la empresa. Exige una cierta habilidad en los analistas (es bastante difícil). El IEEE lo pone como modelo no operativo en sus clasificaciones de MCV.


MODELO DE PROTOTIPOS

En Ingeniería de software el desarrollo con prototipación, también llamado modelo de prototipos que pertenece a los modelos de desarrollo evolutivo, se inicia con la definición de los objetivos globales para el software, luego se identifican los requisitos conocidos y las áreas del esquema en donde es necesaria más definición. Entonces se plantea con rapidez una iteración de construcción de prototipos y se presenta el modelado (en forma de un diseño rápido).
El diseño rápido se centra en una representación de aquellos aspectos del software que serán visibles para el cliente o el usuario final (por ejemplo, la configuración de la interfaz con el usuario y el formato de los despliegues de salida). El diseño rápido conduce a la construcción de un prototipo, el cual es evaluado por el cliente o el usuario para una retroalimentación; gracias a ésta se refinan los requisitos del software que se desarrollará. La iteración ocurre cuando el prototipo se ajusta para satisfacer las necesidades del cliente. Esto permite que al mismo tiempo el desarrollador entienda mejor lo que se debe hacer y el cliente vea resultados a corto plazo.

Contenido


-Este modelo es útil cuando el cliente conoce los objetivos generales para el software, pero no identifica los requisitos detallados de entrada, procesamiento o salida.
-También ofrece un mejor enfoque cuando el responsable del desarrollo del software está inseguro de la eficacia de un algoritmo, de la adaptabilidad de un sistema operativo o de la forma que debería tomar la interacción humano-máquina.
-La construcción de prototipos se puede utilizar como un modelo del proceso independiente, se emplea más comúnmente como una técnica susceptible de implementarse dentro del contexto de cualquiera de los modelos del proceso expuestos. Sin importar la forma en que éste se aplique, el paradigma de construcción de prototipos ayuda al desarrollador de software y al cliente a entender de mejor manera cuál será el resultado de la construcción cuando los requisitos estén satisfechos. De esta manera, este ciclo de vida en particular, involucra al cliente más profundamente para adquirir el producto.

Inconvenientes

El usuario tiende a crearse unas expectativas cuando ve el prototipo de cara al sistema final. A causa de la intención de crear un prototipo de forma rápida, se suelen desatender aspectos importantes, tales como la calidad y el mantenimiento a largo plazo, lo que obliga en la mayor parte de los casos a reconstruirlo una vez que el prototipo ha cumplido su función. Es frecuente que el usuario se muestre reacio a ello y pida que sobre ese prototipo se construya el sistema final, lo que lo convertiría en un prototipo evolutivo, pero partiendo de un estado poco recomendado.
En aras de desarrollar rápidamente el prototipo, el desarrollador suele tomar algunas decisiones de implementación poco convenientes (por ejemplo, elegir un lenguaje de programación incorrecto porque proporcione un desarrollo más rápido). Con el paso del tiempo, el desarrollador puede olvidarse de la razón que le llevó a tomar tales decisiones, con lo que se corre el riesgo de que dichas elecciones pasen a formar parte del sistema final.

Conclusiones

A pesar de que tal vez surjan problemas, la construcción de prototipos puede ser un paradigma efectivo para la ingeniería del software. La clave es definir las reglas del juego desde el principio; es decir, el cliente y el desarrollador se deben poner de acuerdo en:
Que el prototipo se construya y sirva como un mecanismo para la definición de requisitos.
Que el prototipo se descarte, al menos en parte.
Que después se desarrolle el software real con un enfoque hacia la calidad.


Desarrollo por etapas

El modelo de desarrollo de software por etapas es similar al Modelo de prototipos ya que se muestra al cliente el software en diferentes estados sucesivos de desarrollo, se diferencia en que las especificaciones no son conocidas en detalle al inicio del proyecto y por tanto se van desarrollando simultáneamente con las diferentes versiones del código.


Pueden distinguirse las siguientes fases:
  • Especificación conceptual
  • Análisis de requerimientos
  • Diseño inicial
  • Diseño detallado, codificación, depuración y liberación
  • Estas diferentes fases se van repitiendo en cada etapa del diseño

Desarrollo iterativo y creciente

Desarrollo iterativo y creciente (o incremental) es un proceso de desarrollo de software, creado en respuesta a las debilidades del modelo tradicional de cascada.
Para apoyar el desarrollo de proyectos por medio de este modelo se han creado frameworks (entornos de trabajo), de los cuales los dos más famosos son el Rational Unified Process y el Dynamic Systems Development Method. El desarrollo incremental e iterativo es también una parte esencial de un tipo de programación conocido como Extreme Programming y los demás frameworks de desarrollo rápido de software.
Contenido

La idea principal detrás de mejoramiento iterativo es desarrollar un sistema de programas de manera incremental, permitiéndole al desarrollador sacar ventaja de lo que se ha aprendido a lo largo del desarrollo anterior, incrementando, versiones entregables del sistema. El aprendizaje viene de dos vertientes: el desarrollo del sistema, y su uso (mientras sea posible). Los pasos claves en el proceso eran comenzar con una implementación simple de los requerimientos del sistema, e iterativamente mejorar la secuencia evolutiva de versiones hasta que el sistema completo esté implementado. En cada iteración, se realizan cambios en el diseño y se agregan nuevas funcionalidades y capacidades al sistema.
El proceso en sí mismo consiste de:
Etapa de inicialización
Etapa de iteración
Lista de control de proyecto


Etapa de inicialización

Se crea una versión del sistema. La meta de esta etapa es crear un producto con el que el usuario pueda interactuar, y por ende retroalimentar el proceso. Debe ofrecer una muestra de los aspectos claves del problema y proveer una solución lo suficientemente simple para ser comprendida e implementada fácilmente. Para guiar el proceso de iteración, una lista de control de proyecto se crea, y esta lista contiene un historial de todas las tareas que necesitan ser realizadas. Incluye cosas como nuevas funcionalidades para ser implementadas, y areas de rediseño de la solución ya existente. Esta lista de control se revisa periódica y constantemente como resultado de la fase de análisis.

Etapa de iteración

Esta etapa involucra el rediseño e implementación de una tarea de la lista de control de proyecto, y el análisis de la versión más reciente del sistema. La meta del diseño e implementación de cualquier iteración es ser simple, directa y modular, para poder soportar el rediseño de la etapa o como una tarea añadida a la lista de control de proyecto. El código puede, en ciertos casos, representar la mayor fuente de documentación del sistema. El análisis de una iteración se basa en la retroalimentación del usuario y en el análisis de las funcionalidades disponibles del programa. Involucra el análisis de la estructura, modularidad, usabilidad, confiabilidad, eficiencia y eficacia (alcanzar las metas). La lista de control del proyecto se modifica bajo la luz de los resultados del análisis.
Las guías primarias que guían la implementación y el análisis incluyen:
Cualquier dificultad en el diseño, codificación y prueba de una modificación debería apuntar a la necesidad de rediseñar o recodificar.
Las modificaciones deben ajustarse fácilmente a los módulos fáciles de encontrar y a los aislados. Si no es así, entonces se requiere algún grado de rediseño.
Las modificaciones a las tablas deben ser especialmente fáciles de realizar. Si dicha modificación no ocurre rápidamente, se debe aplicar algo de rediseño.
Las modificaciones deben ser más fáciles de hacer conforme avanzan las iteraciones. Si no es así, hay un problema primordial usualmente encontrado en un diseño débil o en la proliferación excesiva de parches al sistema.
Los parches normalmente deben permanecer solo por una o dos iteraciones. Se hacen necesarios para evitar el rediseño durante una fase de implementación.
La implementación existente debe ser analizada frecuentemente para determinar que tan bien se ajusta a las metas del proyecto.
Las facilidades para analizar el programa deben ser utilizadas cada vez para ayudar en el análisis de implementaciones parciales.
La opinión del usuario debe ser solicitada y analizada para indicar deficiencias en la implementación referida por él.

Caso práctico

La mejora iterativa fue exitosamente aplicada al desarrollo de una familia extensa de compiladores para una familia de lenguajes de programación en una gama de arquitecturas de hardware. Un conjunto de 17 versiones del sistema se desarrollaron en un lugar, generando 17 mil líneas de código fuente de lenguaje de alto nivel (6500 de código ejecutable). El sistema posteriormente fue desarrollado en dos sitios diferentes, llegando a dos versiones diferentes del lenguaje base: una versión esencialmente se enfocaba en aplicaciones matemáticas, añadiendo números reales y varias funciones matemáticas, y la otra se centró en añadir capacidades para escribir del compilador. Cada iteración fue analizada del punto de vista de los usuarios (las capacidades del lenguaje fueron determinadas en parte por las necesidades del usuario) y el punto de vista del desarrollador (el diseño del compilador evolucionó para ser más fácilmente modificable, por ejemplo, para añadir nuevos tipos de datos). Mediciones tales como acoplamiento y modularización fueron seguidas sobre múltiples versiones.

Características

Usando análisis y mediciones como guías para el proceso de mejora es una diferencia mayor entre las mejoras iterativas y el desarrollo rápido de aplicaciones, principalmente por dos razones:
Proveé de soporte para determinar la efectividad de los procesos y de la calidad del producto.
Permite estudiar y después mejorar y ajustar el proceso para el ambiente en particular.
Estas mediciones y actividades de análisis pueden ser añadidas a los métodos de desarrollo rápido existentes.
De hecho, el contexto de iteraciones múltiples conlleva ventajas en el uso de mediciones. Las medidas a veces son difíciles de comprender en lo absoluto, aunque en los cambios relativos en las medidas a través de la evolución del sistema puede ser muy informativo porque proveén una base de comparación. Por ejemplo, un vector de medidas m1, m2,..., mn puede ser definido para caracterizar varios aspectos del producto en cierto punto, como pueden ser el esfuerzo total realizado, los cambios, los defectos, los atributos lógico, físico y dinámico, consideraciones del entorno, etcétera. Así el observador puede decir como las carácterísticas del producto como el tamaño, la complejidad, el acoplamiento y la cohesión incrementan o disminuyen en el tiempo. También pude monitorearse el cambio relativo de varios aspectos de un producto o pueden proveer los límites de las medidas para apuntar a problemas potenciales y anomalías.

Debilidades de este modelo de desarrollo

Debido a la interacción con los usuarios finales, cuando sea necesaria la retroalimentación hacia el grupo de desarrollo, utilizar este modelo de desarrollo puede llevar a avances ser extremadamente lento.
Por la misma razón no es una aplicación ideal para desarrollos en los que de antemano se sabe que serán grandes en el consumo de recursos y largos en el tiempo.
Al requerir constantemente la ayuda de los usuario finales, se agrega un costo extra a la compañía, pues mientras estos usuarios evalúan el software dejan de ser directamente productivos para la compañía.


Desarrollo rápido de aplicaciones

Rapid application development (RAD) es un proceso de desarrollo de software (en inglés, software development process), 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.
Hoy en día se suele utilizar para referirnos al desarrollo rápido de GUIs tal como Glade, o IDEs de desarrollo completas como Delphi, Foxpro o Anjuta. Uno de los programas más usados para hacer aplicaciones rápidamente es el Visual Basic.

Historia
Comenzando con las ideas de Barry Boehm y Scott Shultz, James Martin desarrolló el Rapid Application Development durante los años 1980 en IBM y finalmente lo formalizó publicando un libro en 1991.

Ventajas y desventajas


El desarrollo rápido tiene dos ventajas primarias:
Velocidad del desarrollo: Los aumentos de la velocidad son debido al uso de la herramienta CASE.
Calidad: según lo definido por el RAD, es el grado al cual un uso entregado resuelve las necesidades de usuarios así como el grado al cual un sistema entregado tiene costes de mantenimiento bajos. El RAD aumenta calidad con la implicación del usuario en las etapas del análisis y del diseño.
El RAD tiene dos desventajas primarias:
Características reducidas.
Escalabilidad reducida: debido a que el RAD se desarrolló como prototipo.

Herramientas RAD Multiplataforma

Icaria La plataforma MDA desarrollada por netZima. El analista que trabaja con Icaria® tiene conocimientos de diseño de sistemas y de los procesos de negocio que debe implantar. Sin embargo, no necesita conocimiento alguno de la tecnología en la que finalmente se generará el sistema.
NetBeans Herramienta Open Source
Eclipse Herramienta Open Source
WaveMaker WaveMaker Herramienta Open Source para aplicaciones Web2.0
Revolution Studio Es una avanzada herramienta cross-platform RAD que deriva ejecutables sobre Windows, Linux, Solaris, MacOS X Universal Binary and MacOS Classic.
Lazarus Es un IDE cross-platform similar a Borland Delphi.
Real Basic Es un IDE cross-platform similar a Visual Basic.
Leonardi Es una herramienta avanzada cross-platform RAD que deriva ejecutables sobre Windows, Linux, MacOs.
Microsoft Visual Studio 2005 / 2008
ycube RAD Plus Herramienta Open Source para aplicaciones comerciales multiplataforma (Windows, Linux, Unix, MAC OSX).

Herramientas RAD para Escritorio
AppBuilder 1 2 3
Automated Architecure's Blue Ink
Borland C++Builder
Borland Delphi
Gambas
WinDev
Visual Basic
Ultimate++
NConstruct - .NET RAD herramienta para Winforms & Web

Herramientas RAD para Bases de Datos

Clarion Es una herramienta (ARAD) Advanced Rapid Application
FileMaker Pro Advanced
Omnis Studio
Oracle Forms
Oracle Application Express o APEX
Sybase PowerBuilder
WinDev
Magic Software uniPaaS
Servoy
NConstruct - .NET RAD herramienta para Winforms & Web
Microsoft Access
c++ builder
oracle 2000
power builder

Herramientas RAD Orientadas a la WEB WaveMaker [1] Herramienta Open Source para aplicaciones Web2.0
Django WebFramework para el desarrollo de aplicaciones web sobre Python.
37 Signals Ruby on Rails
Adobe ColdFusion
Symfony (PHP)
iRise 1
WebDev
Velneo
Leonardi
Microsoft Visual Studio 2005
ycube RAD Plus Herramienta Open Source para aplicaciones comerciales.
NConstruct - .NET RAD herramienta para Winforms & Web

Historia [editar]
Comenzando con las ideas de Barry Boehm y Scott Shultz, James Martin desarrolló el Rapid Application Development durante los años 1980 en IBM y finalmente lo formalizó publicando un libro en 1991.

Ventajas y desventajas [editar]
El desarrollo rápido tiene dos ventajas primarias:
Velocidad del desarrollo: Los aumentos de la velocidad son debido al uso de la herramienta CASE.
Calidad: según lo definido por el RAD, es el grado al cual un uso entregado resuelve las necesidades de usuarios así como el grado al cual un sistema entregado tiene costes de mantenimiento bajos. El RAD aumenta calidad con la implicación del usuario en las etapas del análisis y del diseño.
El RAD tiene dos desventajas primarias:
Características reducidas.
Escalabilidad reducida: debido a que el RAD se desarrolló como prototipo.

Herramientas RAD Multiplataforma [editar]
Icaria La plataforma MDA desarrollada por netZima. El analista que trabaja con Icaria® tiene conocimientos de diseño de sistemas y de los procesos de negocio que debe implantar. Sin embargo, no necesita conocimiento alguno de la tecnología en la que finalmente se generará el sistema.
NetBeans Herramienta Open Source
Eclipse Herramienta Open Source
WaveMaker WaveMaker Herramienta Open Source para aplicaciones Web2.0
Revolution Studio Es una avanzada herramienta cross-platform RAD que deriva ejecutables sobre Windows, Linux, Solaris, MacOS X Universal Binary and MacOS Classic.
Lazarus Es un IDE cross-platform similar a Borland Delphi.
Real Basic Es un IDE cross-platform similar a Visual Basic.
Leonardi Es una herramienta avanzada cross-platform RAD que deriva ejecutables sobre Windows, Linux, MacOs.
Microsoft Visual Studio 2005 / 2008
ycube RAD Plus Herramienta Open Source para aplicaciones comerciales multiplataforma (Windows, Linux, Unix, MAC OSX).

Herramientas RAD para Escritorio [editar]
AppBuilder 1 2 3
Automated Architecure's Blue Ink
Borland C++Builder
Borland Delphi
Gambas
WinDev
Visual Basic
Ultimate++
NConstruct - .NET RAD herramienta para Winforms & Web

Herramientas RAD para Bases de Datos [editar]
Clarion Es una herramienta (ARAD) Advanced Rapid Application
FileMaker Pro Advanced
Omnis Studio
Oracle Forms
Oracle Application Express o APEX
Sybase PowerBuilder
WinDev
Magic Software uniPaaS
Servoy
NConstruct - .NET RAD herramienta para Winforms & Web
Microsoft Access
c++ builder
oracle 2000
power builder

Herramientas RAD Orientadas a la WEB [editar]
WaveMaker [1] Herramienta Open Source para aplicaciones Web2.0
Django WebFramework para el desarrollo de aplicaciones web sobre Python.
37 Signals Ruby on Rails
Adobe ColdFusion
Symfony (PHP)
iRise 1
WebDev
Velneo
Leonardi
Microsoft Visual Studio 2005
ycube RAD Plus Herramienta Open Source para aplicaciones comerciales.
NConstruct - .NET RAD herramienta para Winforms & Web

Véase también

Entorno de desarrollo integrado

Referencias externas

blueink.biz - Rapid Application Development - Más detalles sobre RAD y herramientas de desarrollo.
Información sobre RAD
What is Application Development?.
Obtenido de "http://es.wikipedia.org/wiki/Desarrollo_r%C3%A1pido_de_aplicaciones"Entorno de desarrollo integrado

Referencias externas blueink.biz - Rapid Application Development - Más detalles sobre RAD y herramientas de desarrollo.
Información sobre RAD
What is Application Development?.