SOFTWARE

¿Qué es?
El software de computadora es el producto que construyen los programadores
profesionales y al que después le dan mantenimiento durante un largo tiempo. Incluye
programas que se ejecutan en una computadora de cualquier tamaño y arquitectura,
contenido que se presenta a medida de que se ejecutan los programas de cómputo e
información descriptiva tanto en una copia dura como en formatos virtuales que
engloban virtualmente a cualesquiera medios electrónicos.

INGENIERÍA DE SOFTWARE

La ingeniería de software está formada por un proceso, un conjunto de métodos

(prácticas) y un arreglo de herramientas que permite a los profesionales
elaborar software de cómputo de alta calidad.

La ingeniería de software es importante porque nos permite construir sistemas

complejos en un tiempo razonable y con alta calidad.

Según Fritz Bauer [Nau69] la define así:

La ingeniería de software es el establecimiento y uso de principios fundamentales de la

ingeniería con objeto de desarrollar en forma económica software que sea confiable y
que trabaje con eficiencia en máquinas reales.

El IEEE ha desarrollado una definición más completa, como sigue:

La ingeniería de software es: 1) La aplicación de un enfoque sistemático, disciplinado y

cuantificable al desarrollo, operación y mantenimiento de software; es decir, la
aplicación de la ingeniería al software.

Características del software

1. El software se desarrolla o modifica con intelecto; no se manufactura en el

sentido clásico.
2. El software no se “desgasta”.
3. Aunque la industria se mueve hacia la construcción basada en componentes, la
mayor parte del software se construye para un uso individualizado.
Dominios de aplicación del software
Actualmente, hay siete grandes categorías de software de computadora que plantean
retos continuos a los ingenieros de software:

Software de sistemas:
Conjunto de programas escritos para dar servicio a otros programas. Determinado
software de sistemas (por ejemplo, compiladores, editores y herramientas para
administrar archivos) procesa estructuras de información complejas pero
deterministas.

Software de aplicación:
Programas aislados que resuelven una necesidad específica de negocios.

Software de ingeniería y ciencias:

Se ha caracterizado por algoritmos “devoradores de números”. Las aplicaciones van
de la astronomía a la vulcanología, del análisis de tensiones en automóviles a la
dinámica orbital del transbordador espacial, y de la biología molecular a la
manufactura automatizada.

Software incrustado:
Reside dentro de un producto o sistema y se usa para implementar y controlar
características y funciones para el usuario final y para el sistema en sí.

Software de línea de productos:

Es diseñado para proporcionar una capacidad específica para uso de muchos
consumidores diferentes.

Aplicaciones web:
Llamadas “webapps”, esta categoría de software centrado en redes agrupa una amplia
gama de aplicaciones. En su forma más sencilla, las webapps son poco más que un
conjunto de archivos de hipertexto vinculados que presentan información con uso de
texto y gráficas limitadas.

Software de inteligencia artificial:

Hace uso de algoritmos no numéricos para resolver problemas complejos que no son
fáciles de tratar computacionalmente o con el análisis directo. Las aplicaciones en
esta área incluyen robótica, sistemas expertos, reconocimiento de patrones (imagen y
voz), redes neurales artificiales, demostración de teoremas y juegos.
EL PROCESO DEL SOFTWARE

La estructura del proceso establece el fundamento para el proceso completo de la

ingeniería de software por medio de la identificación de un número pequeño de
actividades estructurales que sean aplicables a todos los proyectos de software, sin
importar su tamaño o complejidad. Además, la estructura del proceso incluye un
conjunto de actividades sombrilla que son aplicables a través de todo el proceso del
software. Una estructura de proceso general para la ingeniería de software consta de
cinco actividades:

Comunicación. Antes de que comience cualquier trabajo técnico, tiene importancia

crítica comunicarse y colaborar con el cliente (y con otros participantes).11 Se busca
entender los objetivos de los participantes respecto del proyecto, y reunir los
requerimientos que ayuden a definir las características y funciones del software.

Planeación. Cualquier viaje complicado se simplifica si existe un mapa. Un proyecto

de software es un viaje difícil, y la actividad de planeación crea un “mapa” que guía al
equipo mientras viaja. El mapa —llamado plan del proyecto de software— define el
trabajo de ingeniería de software al describir las tareas técnicas por realizar, los
riesgos probables, los recursos que se requieren, los productos del trabajo que se
obtendrán y una programación de las actividades.

Modelado. Ya sea usted diseñador de paisaje, constructor de puentes, ingeniero

aeronáutico, carpintero o arquitecto, a diario trabaja con modelos. Crea un “bosquejo”
del objeto por hacer a fin de entender el panorama general —cómo se verá
arquitectónicamente, cómo ajustan entre sí las partes constituyentes y muchas
características más—. Si se requiere, refina el bosquejo con más y más detalles en un
esfuerzo por comprender mejor el problema y cómo resolverlo. Un ingeniero de
software hace lo mismo al crear modelos a fin de entender mejor los requerimientos
del software y el diseño que los satisfará.

Construcción. Esta actividad combina la generación de código (ya sea manual o

automatizada) y las pruebas que se requieren para descubrir errores en éste.
Despliegue. El software (como entidad completa o como un incremento parcialmente
terminado) se entrega al consumidor que lo evalúa y que le da retroalimentación,
misma que se basa en dicha evaluación.
 MODELOS DE PROCESO

Modelo en Cascada
El modelo de la cascada, a veces llamado ciclo de vida clásico, sugiere un enfoque
sistemático y secuencial6 para el desarrollo del software, que comienza con la
especificación de los requerimientos por parte del cliente y avanza a través de
planeación, modelado, construcción y despliegue, para concluir con el apoyo del
software terminado.

Modelo en V
Modelos de proceso incremental

El modelo incremental combina elementos de los flujos de proceso lineal y paralelo.

En relación con la figura 2.5, el modelo incremental aplica secuencias lineales en
forma escalonada a medida que avanza el calendario de actividades. Cada secuencia
lineal produce “incrementos” de software susceptibles de entregarse de manera
parecida a los incrementos producidos en un flujo de proceso evolutivo.

Modelos de proceso evolutivo

Los modelos evolutivos son iterativos. Se caracterizan por la manera en la que
permiten desarrollar versiones cada vez más completas del software. En los párrafos
que siguen se presentan dos modelos comunes de proceso evolutivo.

Hacer prototipos

Los modelos evolutivos son iterativos; los caracteriza la forma en que permiten que
los ingenieros de software desarrollen versiones cada vez más completas del
software.

El diseño rápido se basa 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.

Construcción de Prototipos

A menudo un cliente define un conjunto de objetivos generales para el software, pero

no identifica los requisitos detallados de entrada, procesamiento o salida. 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 humana – máquina, entonces en este caso cuando utilizamos la
construcción de prototipos.
El modelo espiral

El modelo espiral es un modelo evolutivo del proceso del software y se acopla con la
naturaleza iterativa de hacer prototipos con los aspectos controlados y sistémicos del
modelo de cascada. Tiene el potencial para hacer un desarrollo rápido de versiones
cada vez más completas.

El modelo de desarrollo espiral es un generador de modelo de proceso impulsado por el

riesgo, que se usa para guiar la ingeniería concurrente con participantes múltiples de
sistemas intensivos en software.

Tiene dos características distintivas principales. La primera es el enfoque cíclico para el

crecimiento incremental del grado de definición de un sistema y su implementación,
mientras que disminuye su grado de riesgo. La otra es un conjunto de puntos de
referencia de anclaje puntual para asegurar el compromiso del participante con
soluciones factibles y mutuamente satisfactorias.

DESARROLLO ÁGIL

La ingeniería de software ágil combina una filosofía con un conjunto de lineamientos

de desarrollo. La filosofía pone el énfasis en: la satisfacción del cliente y en la entrega
rápida de software incremental, los equipos pequeños y muy motivados para efectuar
el proyecto, los métodos informales, los productos del trabajo con mínima ingeniería
de software y la sencillez general en el desarrollo.
Programación extrema (xp)

La programación extrema usa un enfoque orientado a objetos (véase el apéndice 2)

como paradigma preferido de desarrollo, y engloba un conjunto de reglas y prácticas
que ocurren en el contexto de cuatro actividades estructurales: planeación, diseño,
codificación y pruebas.

Otros modelos ágiles

 Desarrollo adaptativo de software (DAS)
 Scrum
 Método de desarrollo de sistemas dinámicos (MDSD)
 Cristal
 Desarrollo impulsado por las características (DIC)
 Desarrollo esbelto de software (DES)
 Modelado ágil (MA)
 Proceso unificado ágil (PUA)
SCRUM

Los principios Scrum son congruentes con el manifiesto ágil y se utilizan para guiar
actividades de desarrollo dentro de un proceso de análisis que incorpora las
siguientes actividades estructurales: requerimientos, análisis, diseño, evolución y
entrega. Dentro de cada actividad estructural, las tareas del trabajo ocurren con un
patrón del proceso (que se estudia en el párrafo siguiente) llamado sprint. El trabajo
realizado dentro de un sprint (el número de éstos que requiere cada actividad
estructural variará en función de la complejidad y tamaño del producto) se adapta al
problema en cuestión y se define —y con frecuencia se modifica— en tiempo real por
parte del equipo Scrum.
ANÁLISIS DE LOS REQUERIMIENTOS

El análisis de los requerimientos da como resultado la especificación de las

características operativas del software, indica la interfaz de éste y otros elementos del
sistema, y establece las restricciones que limitan al software. El análisis de los
requerimientos permite al profesional (sin importar si se llama ingeniero de software,
analista o modelista) construir sobre los requerimientos básicos establecidos durante
las tareas de concepción, indagación y negociación, que son parte de la ingeniería de
los requerimientos.

Durante el modelado de los requerimientos, la atención se centra en qué, no en cómo.

¿Qué interacción del usuario ocurre en una circunstancia particular?, ¿qué objetos
manipula el sistema?, ¿qué funciones debe realizar el sistema?, ¿qué comportamientos
tiene el sistema?, ¿qué interfaces se definen? y ¿qué restricciones son aplicables?
La ingeniería de requerimientos ayuda a los Ingenieros de Software a entender mejor
el problema en cuya solución trabajarán. Incluye un conjunto de tareas que conducen
a comprender cuál será el impacto del software sobre el negocio, qué es lo que el
cliente quiere y cómo interactúan los usuarios finales con el software.

Determinación de los requerimientos

La determinación de requerimientos se realiza mediante las tareas siguientes:

Definición del caso de estudio: Se identifica el tema central que motiva el inicio del
estudio, pudiendo ser la creación de un nuevo sistema ó la modificación a uno ya
existente.

Estudio de la organización: Se determina con precisión las áreas usuarias

participantes, su estructura orgánica, funciones, interrelaciones y compromisos con
otras.

Análisis de procedimientos: Se estudian todos los procedimientos relacionados con

el problema planteado, identificando para cada uno de ellos: los objetivos que
persiguen, las actividades que realizan, secuencia y periodicidad, responsables,
niveles de agregación, sus relaciones con otros puntos de control y situaciones
especiales que imperan.

Análisis de información: Se identificaran los flujos de información, documentos y

reportes, operaciones (de registro, validación, almacenamiento, clasificación, cálculo y
presentación), volúmenes y períodos; que se desprenden de la ejecución de los
procedimientos estudiados.

Identificación de recursos. Se hace un reconocimiento de los recursos humanos y

materiales participantes en el desarrollo de las actividades.

Determinación de puntos críticos: Consiste en identificar claramente aquellos

aspectos que entorpecen y limitan el buen funcionamiento de los procedimientos
actuales, los problemas más comunes y relevantes que se presentan, los motivos que
crean insatisfacción y aquellos que deben ser cubiertos a plenitud. Por ejemplo: ¿El
contenido de los reportes generados, satisface realmente las necesidades del usuario?
¿Los tiempos de respuesta ofrecidos, son oportunos?

Establecimiento del problema a resolver: Una vez realizadas las actividades

anteriores se está en condición de precisar el problema, su naturaleza, grado de
complejidad e implicaciones que tiene (organizaciones, económicas, etc.).
 Descripción del Sistema Propuesto

Perfil general del sistema: Se confirma el objetivo que persigue la propuesta, la

naturaleza de esta y el programa para llevarla a cabo.
Modelo organizacional. Se establece el esquema orgánico de áreas participantes,
funciones e interrelaciones.

Estructura general de información. Se crea un esquema global de los principales

flujos de información que componen el sistema, identificando sus objetivos,
interrelaciónales, participantes y periodicidades. Por ejemplo en un sistema de
nómina, aparecerían los siguientes flujos:

Descripción de los flujos de información. Por cada flujo se establecen sus

actividades, secuencia y responsable de su ejecución, también se determinan las
salidas, entradas (documentos, reportes, pantallas, etc.) y procesos de manipulación
de datos que emplean (registros, validación, acceso, almacenamiento, actualización,
clasificación, selección, decisión, etc.)

Definición de productos de información (salidas). Una vez identificadas las áreas y

personas a quienes va dirigida la información, se determina la clase y contenido de los
productos que recibirá, especificando su objetivo, periodicidad, tiempo de respuesta,
nivel de agregación, los datos y totales que aparecerán, su forma de presentación
(natural, editada, analógica: gráficas, símbolos especiales, etc.) y los medios que usará
(pantalla, papel, magnético, etc.).

Análisis de datos. Se identifican todos los datos que se van a utilizar describiendo sus
características: significado, fuente, tipo, longitud, rango de valores, código de
equivalencia, nivel de actualización, etc. Por ejemplo a continuación se presentan
ejemplos de datos y la Tabla 1 con instancias de valores.

Establecimiento de controles. Se establecen las medidas de revisión y corrección del

contenido y calidad de los datos y documentos manejados; también se definen los
niveles de confidencialidad en el acceso de la información.

Definición de recursos. Se precisan requerimientos de personal, equipo y material

del sistema.

Equipo de Trabajo

 Ejecutivos: que definen los aspectos del negocio que usualmente tienen una
influencia significativa en el proyecto.
  Técnicos: quienes planifican, motivan, organizan y controlan a los
profesionales que realizan el trabajo de software
 Profesionales: quienes proporcionan las habilidades técnicas necesarias para
realizar la ingeniería de algún producto o aplicación
 Clientes: quienes especifican los requisitos para la ingeniería de software y
otros elementos que tienen un interés mínimo en el resultado
 Usuarios Finales: quienes interactúan con el software una vez que se libera
para su uso productivo

Factores que deben considerarse cuando se planifican los equipos de trabajo:

 La dificultad del problema que se resolverá
 El tamaño del sistema (módulos) resultante y en cuanto al tamaño de
líneas de código
 El tiempo que el equipo estará junto
 El grado en el que el problema puede separarse en módulos
 La calidad y confiabilidad requerida del sistema que se construirá.
 La rigidez de la fecha de entrega
 El grado de sociabilidad (comunicación) que requiere el proyecto.

 El plan del proyecto fija los recursos disponibles, divide el trabajo y crea un
calendario de trabajo. En algunas organizaciones, el plan del proyecto es un
único documento que incluye todos los diferentes tipos de planes.

 En otros casos, este plan solo se refiere al proceso del desarrollo

Muchos planes incluyen las siguientes secciones:

1. Introducción.
2. Organización del proyecto.
3. Análisis de riesgo.
4. Requerimientos de recursos de HW. y SW.
5. División del trabajo.
6. Programa del proyecto.
7. Mecanismos de supervisión e informe.
El Diagrama Gantt ilustra la duración y las relaciones de tiempo entre las
actividades de un proyecto en forma gráfica. Esta herramienta está bastante
relacionada con la Malla Pert, en cuanto ayuda a tener una visión más clara de las
actividades a realizar y de la duración del proyecto.

La Malla Pert es utilizada como una herramienta cuantitativa de planificación y

control, lo que permite a los administradores contar con un modelo de optimización
que entregue la solución óptima de una secuencia de actividades en el tiempo,
que deben realizarse para finalizar el plan de acción. También permite al
administrador programar un proyecto por adelantado y a la vez calcular el tiempo
necesario para completarlo. Como herramienta de control, la Malla Pert facilita las
actividades de control, permitiendo la comparación del tiempo real con el
planificado.

Para ilustrar el Diagrama Gantt y Malla Pert, es muy importante identificar

primero las distintas actividades del proceso, con las respectivas secuencias y
tiempos de cada actividad.
CALIDAD DEL SOFTWARE
Incluso los desarrolladores de software más experimentados estarán de acuerdo en
que obtener software de alta calidad es una meta importante. Pero, ¿cómo se define la
calidad del software? En el sentido más general se define1 como: Proceso eficaz de
software que se aplica de manera que crea un producto útil que proporciona valor
medible a quienes lo producen y a quienes lo utilizan.

Factores de calidad que se persiguen:

Intuitiva. Grado en el que la interfaz sigue patrones esperados de uso, de modo que
hasta un novato la pueda utilizar sin mucha capacitación.

Eficiencia. Grado en el que es posible localizar o iniciar las operaciones y la

información.

Robustez. Grado en el que el software maneja entradas erróneas de datos o en el que

se presenta interacción inapropiada por parte del usuario.

Riqueza. Grado en el que la interfaz provee un conjunto abundante de características.

MÉTRICAS DE REVISIÓN Y SU EMPLEO

Las revisiones técnicas son una de las muchas acciones que se requieren como parte
de las buenas prácticas de la ingeniería de software. Cada acción requiere un esfuerzo
humano dirigido. Como el esfuerzo disponible para el proyecto es finito, es importante
que una organización de software comprenda la eficacia de cada acción, definiendo un
conjunto de métricas que puedan utilizarse para evaluar esa eficacia.

SEGURIDAD DEL SOFTWARE

La seguridad del software es una actividad del aseguramiento del software que se
centra en la identificación y evaluación de los peligros potenciales que podrían
afectarlo negativamente y que podrían ocasionar que falle todo el sistema. Si los
peligros se identifican al principio del proceso del software, las características de su
diseño se especifican de modo que los eliminen o controlen.
UN ENFOQUE ESTRATÉGICO PARA LA PRUEBA DE
SOFTWARE

La prueba es un conjunto de actividades que pueden planearse por adelantado y

realizarse de manera sistemática. Por esta razón, durante el proceso de software, debe
definirse una plantilla para la prueba del software: un conjunto de pasos que incluyen
métodos de prueba y técnicas de diseño de casos de prueba específicos.

FUNDAMENTOS DE LAS PRUEBAS DEL SOFTWARE

La meta de probar es encontrar errores, y una buena prueba es aquella que tiene una
alta probabilidad de encontrar uno. Por tanto, un sistema basado en computadora o
un producto debe diseñarse e implementarse teniendo en mente la
“comprobabilidad”. Al mismo tiempo, las pruebas en sí mismas deben mostrar un
conjunto de características que logren la meta de encontrar la mayor cantidad de
errores con el mínimo esfuerzo.

El primer enfoque de pruebas considera una visión externa y se llama prueba de caja
negra. El segundo requiere una visión interna y se denomina prueba de caja blanca.

La prueba de caja negra se refiere a las pruebas que se llevan a cabo en la interfaz del
software. Una prueba de caja negra examina algunos aspectos fundamentales de un
sistema con poca preocupación por la estructura lógica interna del software. La
prueba de caja blanca del software se basa en el examen cercano de los detalles de
procedimiento. Las rutas lógicas a través del software y las colaboraciones entre
componentes se ponen a prueba al revisar conjuntos específicos de condiciones y/o
bucles.

PRUEBA DE CAJA BLANCA

La prueba de caja blanca, en ocasiones llamada prueba de caja de vidrio, es una
filosofía de diseño de casos de prueba que usa la estructura de control descrita como
parte del diseño a nivel de componentes para derivar casos de prueba. Al usar los
métodos de prueba de caja blanca, puede derivar casos de prueba que: 1) garanticen
que todas las rutas independientes dentro de un módulo se revisaron al menos una
vez, 2) revisen todas las decisiones lógicas en sus lados verdadero y falso, 3) ejecuten
todos los bucles en sus fronteras y dentro de sus fronteras operativas y 4) revisen
estructuras de datos internas para garantizar su validez.

PRUEBA DE RUTA BÁSICA

La prueba de ruta o trayectoria básica es una técnica de prueba de caja blanca. El
método de ruta básica permite al diseñador de casos de prueba derivar una medida de
complejidad lógica de un diseño de procedimiento y usar esta medida como guía para
definir un conjunto básico de rutas de ejecución.

UML
DIAGRAMAS DE CLASE
Para modelar clases, incluidos sus atributos, operaciones, relaciones y asociaciones
con otras clases,2 el UML proporciona un diagrama de clase, que aporta una visión
estática o de estructura de un sistema, sin mostrar la naturaleza dinámica de las
comunicaciones entre los objetos de las clases.

DIAGRAMAS DE IMPLEMENTACIÓN
Un diagrama de implementación UML se enfoca en la estructura de un sistema de
software y es útil para mostrar la distribución física de un sistema de software entre
plataformas de hardware y entornos de ejecución.

DIAGRAMAS DE USO DE CASO

Los casos de uso (capítulos 5 y 6) y el diagrama de uso de caso UML ayudan a
determinar la funcionalidad y características del software desde la perspectiva del
usuario.
DIAGRAMAS DE SECUENCIA
Un diagrama de secuencia se usa para mostrar las comunicaciones dinámicas entre
objetos durante la ejecución de una tarea. Este tipo de diagrama muestra el orden
temporal en el que los mensajes se envían entre los objetos para lograr dicha tarea.
Puede usarse un diagrama de secuencia para mostrar las interacciones en un caso de
uso o en un escenario de un sistema de software.

DIAGRAMAS DE COMUNICACIÓN

El diagrama de comunicación UML (llamado “diagrama de colaboración” en UML 1.X)

proporciona otro indicio del orden temporal de las comunicaciones, pero enfatiza las
relaciones entre los objetos y clases en lugar del orden temporal.
DIAGRAMAS DE ACTIVIDAD
Un diagrama de actividad UML muestra el comportamiento dinámico de un sistema o
de parte de un sistema a través del flujo de control entre acciones que realiza el
sistema. Es similar a un diagrama de flujo, excepto porque un diagrama de actividad
puede mostrar flujos concurrentes. El componente principal de un diagrama de
actividad es un nodo acción, representado mediante un rectángulo redondeado, que
corresponde a una tarea realizada por el sistema de software. Las flechas desde un
nodo acción hasta otro indican el flujo de control; es decir, una flecha entre dos nodos
acción significa que, después de completar la primera acción, comienza la segunda
acción. Un punto negro sólido forma el nodo inicial que indica el punto de inicio de la
actividad. Un punto negro rodeado por un círculo negro es el nodo final que indica el
fin de la actividad.
DIAGRAMAS DE ESTADO
El comportamiento de un objeto en un punto particular en el tiempo con frecuencia
depende del estado del objeto; es decir, de los valores de sus variables en dicho
momento.

Herramientas CASE
Se puede definir a las Herramientas CASE como un conjunto de programas y ayudas
que dan asistencia a los analistas, ingenieros de software y desarrolladores, durante
todos los pasos del Ciclo de Vida de desarrollo de un Software.

El empleo de herramientas Case permiten integrar el proceso de ciclo de vida:

 Análisis de datos y procesos integrados mediante un repositorio.

 Generación de interfaces entre el análisis y el diseño.
 Generación del código a partir del diseño.
 Control de mantenimiento.

Beneficios de las Herramientas CASE

Entre los beneficios más significativos de las herramientas CASE se enumeran los
siguientes:

1. Facilidad para la revisión de aplicaciones

2. Soporte para el desarrollo de prototipos de sistemas
3. Generación de código
4. Mejora en la habilidad para satisfacer los requerimientos del usuario
5. Soporte interactivo para el proceso de desarrollo

Ejemplos de Herramientas CASE.

2. Microsoft Project
3. Racional Rose
4. JDeveloper
5. MagicDraw
6. Visual Paradigm
7. Microsoft Visio
8. Enterprise Architect

Proceso de desarrollo de software que permite construir sistemas utilizables en poco

tiempo, normalmente de 60 a 90 días

Es un modelo de proceso de software incremental que resalta un ciclo de desarrollo

corto y además se adapta en alta velocidad al tradicional modelo de cascada, enfocado
en la construcción basada en componentes.

Herramientas RAD para Bases de Datos

* FileMaker Pro Advanced
* Omnis Studio
* Oracle Forms
* Oracle Application Express o APEX
* Sybase PowerBuilder

Herramientas RAD Orientadas a la WEB

* 37 Signals Ruby on Rails
* Adobe ColdFusion
* Symfony (PHP)
* iRise 1
* WebDev
Herramientas RAD para Escritorio
* AppBuilder 1 2 3
* Automated Architecure's Blue Ink
* Borland C++Builder

Herramientas RAD Multiplataforma

* NetBeans
* 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.