Cada modelo representa un proceso particular que proporciona solo información parcial sobre ese proceso.

Modelo en cascada

El primer modelo de proceso de desarrollo de software que fue publicado se deriva de procesos de ingeniería de sistemas más generales (Royce, 1970). Debido a la cascada de una fase a otra, este modelo es conocido como modelo de cascada o como ciclo de la vida del software. Las principales etapas de este modelo se transforman en actividades fundamentales de desarrollo las cuales se explican a continuación:

• Análisis y definición de requerimientos: Los servicios, restricciones y metas del sistema se definen a partir de las consultas con los usuarios. Entonces, se
define en detalles y sirven como una especificación del sistema.
• Diseño del sistema y del software: El proceso de diseño del sistema divide los requerimientos en sistemas hardware o software. Establece una arquitectura completa del sistema. El diseño del software identifica y describe las abstracciones fundamentales del sistema software y sus relaciones.
• Implementación y prueba de unidades: En esta etapa el diseño del software se lleva a cabo como un conjunto o unidades de programas. La prueba de unidades implica verificar que cada una cumpla su especificación.
• Integración y prueba del sistema: Los programas o las unidades individuales de programas se integran y prueban como un sistema completo para asegurar que se cumplan los requerimientos del software. Después de las pruebas el sistema software se entrega al cliente.
• Funcionamiento y mantenimiento: Por lo general, esta es la fase ms larga del ciclo de vida. El sistema se instala y se pone en funcionamiento práctico. Del
ciclo de vida, mejor la implementación de las unidades del sistema y resaltar los servicios del sistema una vez que se descubren nuevos requerimientos.

Las ventajas del modelo en cascada es que la documentación se produce en cada fase y que este cuadra con otros modelos del proceso de ingeniería. Su principal problema es su inflexibilidad al dividir el proyecto en distintas etapas. Se deben hacer compromisos en las etapas iniciales, los que hace difícil responder a los cambios en los requerimientos del cliente.

Por lo que el modelo en cascada solo se recomienda ser utilizado cuando los requerimientos se comprenden bien y sea improbable que cambien radicalmente durante el desarrollo del sistema. Sin embargo, el modelo refleja el tipo de modelo de proceso usado en otros proyectos de la ingeniería. Por consiguiente, los procesos del software que se basan en este enfoque se siguen utilizando para el desarrollo de software, particularmente cuando este es parte de proyectos grandes.

Modelo de prototipos

Los modelos nacieron como un método para acelerar la definición de los requerimientos del software por construir. Un prototipo es un programa. La idea principal es hacer un modelo de la aplicación y presentársela al cliente, sobre todo a nivel de interfaces y otras salidas. El cliente hará sus observaciones sobre lo que se ve en este modelo, y el programa se modificara de acuerdo con dichas observaciones.

El proceso es repetido hasta haber logrado todos los requerimientos del producto en un software, pasando luego a construir la aplicación. Algunos problemas detectados en este modelo son los siguientes:

• El prototipo es un software en borrador no un producto de ingeniería como tal. Sin embargo, puede causar falsas expectativas al cliente en el sentido de que es un producto consolidado. En el momento en que los ingenieros tarden en hacer el software apropiado, podría darse un efecto de ansiedad en el cliente, adverso para la salud del proyecto.
• Al no establecerse claramente los alcances del producto, en cada revisión del producto se podría desbordar los requerimientos, lo cual haría tender a un proyecto sin fin. Para aplicaciones no muy complejas en procesamientos, orientadas fuertemente a presentar muchas salidas, este paradigma podría acomodarse bien.

Modelo de espiral

El modelo espiral busca pasar controladamente, y de manera cíclica, por cuatro actividades en el desarrollo de la aplicación. Estas actividades son:

• Planificación: Es donde se determinan objetos, alternativas de solución y restricciones que se dan para el proyecto. Encontramos el que de la aplicación por construir, así como aspectos de administración de proyectos y de administración de los recursos necesarios por utilizar.
• Análisis de riesgo: Aquí se identifica y resolución el riesgo que puede tener el proyecto. Estos riesgos pueden ser técnicos, administrativos, humanos, políticos, de seguridad, etc.
• Ingeniería: Es la construcción del software. Se combina el cómo y parte de la implementación.
• Evaluación del cliente: Se cumple con otra parte de la implementación. Es importante esta actividad debido al control de calidad y a la participación activa de los clientes en la construcción del producto.

El proceso de construcción del software es evolutivo. Empieza con la actividad de la planificación. Después se evaluaran los riesgos existentes. Si el riesgo de continuación del proyecto es muy grande, este se detendrá.

En caso contrario, se sigue con la actividad de ingeniería, que construirá un producto sujeto a la posterior evaluación del cliente. De las observaciones de estos últimos se hará una nueva planificación, se estudiaran los nuevos riesgos, se hará el siguiente producto de ingeniería. Una vez que el cliente de por aprobado el producto, se planificara la puesta en producción, se evaluaran sus riesgos y se concluirá, en la actividad de ingeniería, con la puesta de producción de la aplicación.

Modelo de procesos unificado racional (RUP)

En la época donde aún no existía UML. Diferentes métodos de diseños de software buscaban su propio camino, mientras que los lenguajes orientados a objetos se empezaron a utilizar en la industria informática. Una empresa, Rational, tuvo la idea de unir los trabajos de varios expertos para crear la formalización de descripción de objetos UML (Unified Modeling Language). El software encargado de traducir esta formalización en un producto comercial, se lanzó al mercado con el nombre Rose.

De esta misma manera una empresa estudio la posibilidad de patentar una metodología de desarrollo de software. Sus leyes sobre patentes, junto a las exigencias comerciales, cambiaron esta metodología en un proceso automatizado, en un software.

Rational compro esta empresa y nació el proceso de desarrollo basado en UML. Dicho esto, Rational Unified Process es, en primer lugar, una meta-modelo de desarrollo. Visto de otra manera, es de un nivel conceptual bastante alto y no se puede aplicar tal cual. De este modo, el proceso unificado (UP) construido originalmente por Rational (RUP) ha dado lugar a muchas instancias.

RUP: La empresa Rational, al ser absorbida por IBM, integro RUP con las herramientas de la gama de desarrollos IBM Rational, naciendo RAD (Rational Application Development).

XUP: Mezcla de Extreme Programming y de procesos unificado.

2TUP: Two tracks UP, modelo concebido por Valtech, pone en paralelo el estudio funcional y el técnico, antes de lanzar la fase de integración.