Técnicas de cuarta generación

• Facilita al ingeniero desarrollador del software la especificación de las características del software a alto nivel, con el fin de generar automáticamente el código a partir de allí. 
• Existencia de herramientas CASE (Computer Aide Software Engineering) Ingeniería de software asistida por computador

RUP (Rational Unified Process) Proceso Unificado de Modelado

• Surge a mediados de los 90s junto con UML 
• Así como el CDM es ampliamente documental 
• Se basa en UML y es iterativo e incremental 
• El punto de partida es la elicitación de requisitos del software

CDM (Custom Development Method) Método de desarrollo adaptable

• Creado por ORACLE Corporation 
• Permite hacer un seguimiento intensivo de las diferentes fases del desarrollo (Definición, Análisis, Diseño, Construcción, Transición y Producción). Para ello, realizan un conjunto de tareas que se agrupan en procesos. Cada proceso hace parte de cada una de las fases del desarrollo y se reporta mediante un documento denominado “entregable”. 
• Genera mucha documentación

Modelo Espiral WIN & WIN (Victoria&Victoria)

El Modelo Espiral previo (clásico) sugiere la comunicación con el cliente para fijar los requisitos, en que simplemente se pregunta al cliente qué necesita y él proporciona la información para continuar; pero esto es en un contexto ideal que rara vez ocurre. Normalmente cliente y desarrollador entran en una negociación, se negocia coste frente a funcionalidad, rendimiento, calidad, etc.

«Es así que la obtención de requisitos requiere una negociación, que tiene éxito cuando ambas partes ganan».

Las mejores negociaciones se fuerzan en obtener «Victoria & Victoria» (Win & Win), es decir que el cliente gane obteniendo el producto que lo satisfaga, y el desarrollador también gane consiguiendo presupuesto y fecha de entrega realista. Evidentemente, este modelo requiere fuertes habilidades de negociación.

El modelo Win-Win define un conjunto de actividades de negociación al principio de cada paso alrededor de la espiral; se definen las siguientes actividades:
Identificación del sistema o subsistemas clave de los directivos(*) (saber qué quieren).
Determinación de «condiciones de victoria» de los directivos (saber qué necesitan y los satisface)
Negociación de las condiciones «victoria» de los directivos para obtener condiciones «Victoria & Victoria» (negociar para que ambos ganen).

Modelo Espiral

En el modelo Espiral el software se construye en una serie de versiones incrementales. En las primeras iteraciones la versión incremental podría ser un modelo en papel o bien un prototipo. En las últimas iteraciones se producen versiones cada vez más completas del sistema diseñado.

El modelo se divide en un número de Actividades de marco de trabajo, llamadas «regiones de tareas». En general existen entre tres y seis regiones de tareas (hay variantes del modelo). En la Figura  se muestra el esquema de un Modelo Espiral . En este caso se explica una variante del modelo original de Boehm, expuesto en su tratado de 1988; en 1998 expuso un tratado más reciente.

El modelo espiral consta de 4 cuadrantes que son sus fases y se dividen de la siguiente forma:

1.- Planificación

2.- Análisis de Riesgos

3.- Ingeniería

4.- Evaluación

Modelo Incremental

El Modelo Incremental combina elementos del MLS con la filosofía interactiva de construcción de prototipos.
En una visión genérica, el proceso se divide en 4 partes: Análisis, Diseño, Código y Prueba. Sin embargo, para la producción del Software, se usa el principio de trabajo en cadena o “Pipeline”, utilizado en muchas otras formas de programación. Con esto se mantiene al cliente en constante contacto con los resultados obtenidos en cada incremento. Es el mismo cliente el que incluye o desecha elementos al final de cada incremento a fin de que el software se adapte mejor a sus necesidades reales. El proceso se repite hasta que se elabore el producto completo.
De esta forma el tiempo de entrega se reduce considerablemente.
Al igual que los otros métodos de modelado, el Modelo Incremental es de naturaleza interactiva pero se diferencia de aquellos en que al final de cada incremento se entrega un producto completamente operacional.
El Modelo Incremental es particularmente útil cuando no se cuenta con una dotación de personal suficiente. Los primeros pasos los pueden realizar un grupo reducido de personas y en cada incremento se añade personal, de ser necesario. Por otro lado los incrementos se pueden planear para gestionar riesgos técnicos.
El Modelo Incremental se puede ver aquí en forma grafica:




- Se evitan proyectos largos y se entrega algo de valor a los usuarios con cierta frecuencia.
- El usuario se involucra más.
- Difícil de evaluar el coste total.
- Difícil de aplicar a los sistemas transaccionales que tienden a ser integrados y a operar como un todo.
- Requiere gestores experimentados.
- Los errores en los requisitos se detectan tarde.
- El resultado puede ser muy positivo.

Modelos Evolutivos

Los requisitos del usuario y del producto suelen cambiar conforme se desarrolla el mismo. Las fechas de mercado y la competencia hacen que no sea posible esperar a poner en el mercado un producto absolutamente completo, por lo que se aconsejable introducir una versión funcional limitada de alguna forma para aliviar las presiones competitivas.

En esas u otras situaciones similares los desarrolladores necesitan modelos de progreso que estén diseñados para acomodarse a una evolución temporal o progresiva, donde los requisitos centrales son conocidos de antemano, aunque no estén bien definidos a nivel detalle.

En el modelo cascada y cascada realimentado no se tiene demasiado en cuenta la naturaleza evolutiva del software, se plantea como estático, con requisitos bien conocidos y definidos desde el inicio.

Los evolutivos son modelos iterativos, permiten desarrollar versiones cada vez más completas y complejas, hasta llegar al objetivo final deseado; incluso evolucionar más allá, durante la fase de operación.

Modelo lineal secuencial o Cascada

• Desarrollado entre 1960-1980 
• Basado en el modelo en cascada de Winston Royce
• Se conoce como el ciclo de vida básico 
• Secuencia de actividades, donde la estrategia principal es seguir el progreso del desarrollo de software hacia puntos de revisión bien definidos mediante entregas calendarizadas.
  
  es uno de los actualmente más utilizados, por su eficacia y simplicidad, más que nada en software de pequeño y algunos de mediano porte; pero nunca (o muy rara vez) se lo usa en su "forma pura", como se dijo anteriormente. En lugar de ello, siempre se produce alguna realimentación entre etapas, que no es completamente predecible ni rígida; esto da oportunidad al desarrollo de productos software en los cuales hay ciertas incertezas, cambios o evoluciones durante el ciclo de vida. Así por ejemplo, una vez capturados y especificados los requisitos (primera etapa) se puede pasar al diseño del sistema, pero durante esta última fase lo más probable es que se deban realizar ajustes en los requisitos (aunque sean mínimos), ya sea por fallas detectadas, ambigüedades o bien por que los propios requisitos han cambiado o evolucionado
  
  
  
  

Modelos del Proceso de Software

Es la estrategia que a menudo se llama modelo de proceso o paradigma de ingeniería del software.

Se selecciona un modelo de proceso para la ingeniería del software según la naturaleza del proyecto y de la aplicación, los métodos y las herramientas a utilizarse, y los controles y entregas que se requieren, los controles y entregas que se requieren.