Modelos de Desarrollo

	MODELO SECUENCIAL LINEAL	MODELO DE CONSTRUCCION DE PROTOTIPOS	MODELOS EVOLUTIVOS	MODELO INCREMENTAL	MODELO EN ESPIRAL	MODELO WINWIN	MODELO DE DESARROLLO CONCURRENTE
	Este es también llamado "Modelo Clásico", "Modelo Tradicional" o "Modelo en Cascada". Este es el más básico de todos los modelos, y sirve como bloque de construcción para los demás modelos de ciclo de vida. La visión del modelo cascada del desarrollo de software es muy simple; dice que el desarrollo de software puede ser a través de una secuencia simple de fases.	El prototipado de requerimientos es la creación de una implementación parcial de un sistema, para el propósito explícito de aprender sobre los requerimientos del sistema. Un prototipo es construido de una manera rápida tal como sea posible.	Se adaptan más fácilmente a los cambios introducidos a lo largo del desarrollo.   Iterativos.   En cada iteración se obtienen versiones más completas del SW.	En este modelo se debe especificar con precisión todo lo que el sistema va a hacer antes de desarrollarlo. Lo cual lo hace  manejable y disminuiría los costos.	Este es un modelo de proceso de software evolutivo, el cual enlaza la naturaleza iterativa de la construcción de prototipos, pero conservado aquellas propiedades del modelo en cascada.   El modelo de desarrollo en espiral es un generador de modelo de proceso guiado por el riesgo que se emplea para conducir sistemas intensivos de ingeniería de software concurrente y a la vez con muchos usuarios.	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: 1 - Identificación del sistema o subsistemas clave de los directivos(*) (saber qué quieren). 2 - Determinación de "condiciones de victoria" de los directivos (saber qué necesitan y los satisface) 3 - Negociación de las condiciones "victoria" de los directivos para obtener condiciones "Victoria & Victoria" (negociar para que ambos ganen).	el modelo concurrente provee una meta-descripción del proceso software. Mientras que la contribución primaria del modelo espiral es en realidad que esas actividades del software ocurran repetidamente, la contribución del modelo concurrente es su capacidad de describir las múltiples actividades del software ocurriendo simultáneamente.
Ventaja	Una de las contribuciones más importantes del modelo cascada es para los administradores, posibilitándoles avanzar en el desarrollo, aunque en una escala muy bruta.	Diferente del modelo evolutivo donde los requerimientos mejor entendidos están incorporados, un prototipo generalmente se construye con los requerimientos entendidos más pobremente.		Construir un sistema pequeño es siempre menos riesgoso que construir un sistema grande. Al ir desarrollando parte de las funcionalidades, es más fácil determinar si los requerimientos planeados para los niveles subsiguientes son correctos. Si un error importante es realizado, sólo la última iteración necesita ser descartada. Reduciendo el tiempo de desarrollo de un sistema (en este caso en incremento del sistema) decrecen las probabilidades que esos requerimientos de usuarios puedan cambiar durante el desarrollo. Si un error importante es realizado, el incremento previo puede ser usado. Los errores de desarrollo realizados en un incremento, pueden ser arreglados antes del comienzo del próximo incremento.	Este sistema es muy utilizado en proyectos largos como pueden ser la creación de un Sistema Operativo. Y que necesitan constantes cambios. Al ser un modelo de Ciclo de Vida orientado al riesgo se dice que uno de los aspectos fundamentales de su éxito radica en que el equipo que lo aplique sea capaz de detectar y catalogar correctamente dicho riesgo.	El modelo WinWin hace énfasis en la negociación inicial, también introduce 3 hitos en el proceso llamados "puntos de fijación", que ayudan a establecer la completitud de un ciclo de la espiral, y proporcionan hitos de decisión antes de continuar el proyecto de desarrollo del software.	Los requerimientos son usualmente "líneas de base", cuando una mayoría de los requerimientos comienzan a ser bien entendidos, en este tiempo se dedica un esfuerzo considerable al diseño. Sin embargo, una vez que comienza el diseño, cambios a los requerimientos son comunes y frecuentes (después de todo, los problemas reales cambian, y nuestro entendimiento de los problemas desarrollados también).
Desventajas	Los cambios introducidos durante el desarrollo pueden confundir al equipo profesional en las etapas tempranas del proyecto. Si los cambios se producen en etapa madura (codificación o prueba) pueden ser catastróficos para un proyecto grande. No es frecuente que el cliente o usuario final explicite clara y completamente los requisitos (etapa de inicio); y el modelo lineal lo requiere. La incertidumbre natural en los comienzos es luego difícil de acomodar. El cliente debe tener paciencia ya que el software no estará disponible hasta muy avanzado el proyecto. Un error detectado por el cliente (en fase de operación) puede ser desastroso, implicando reinicio del proyecto con altos costos.	Cliente cree que es el sistema. Peligro de familiarización con malas elecciones iniciales (quick and dirty).		Los riesgos asociados con el desarrollo de sistemas largos y complejos son enormes.   Una forma de reducir los riesgos es construir sólo una parte del sistema, reservando otros aspectos para niveles posteriores.	Requiere mucha experiencia y habilidad para la evaluación de los riesgos, lo cual es requisito para el éxito del proyecto. Es difícil convencer a los grandes clientes que se podrá controlar este enfoque evolutivo.	En este modelo las actividades que se definen son  importantes como lo son: la identificación del sistema, la determinación de las condiciones y la negociación de estas.	Es desaconsejado detener el diseño en este camino cuando los requerimientos cambian; en su lugar, existe una necesidad de modificar y rehacer líneas de base de los requerimientos mientras progresa el diseño. Por supuesto, dependiendo del impacto de los cambios de los requerimientos el diseño puede no ser afectado, medianamente afectado o se requerirá comenzar todo de nuevo.
Características	Planear un proyecto antes de embarcarse en él. Definir el comportamiento externo deseado del sistema antes de diseñar su arquitectura interna. Documentar los resultados de cada actividad. Diseñar un sistema antes de codificarlo. Testear un sistema después de construirlo.	El prototipado puede ser usado como parte de la fase de requerimientos (determinar requerimientos) o justo antes de la fase de requerimientos (como predecesor de requerimientos). En otro caso, el prototipado puede servir su papel inmediatamente antes de algún o todo el desarrollo incremental en modelos incremental o evolutivo.			Un enfoque cíclico para el crecimiento incremental del grado de definición e implementación de un sistema, mientras que disminuye su grado de riesgo.   Un conjunto de puntos de fijación para asegurar el compromiso del usuario con soluciones de sistema que sean factibles y mutuamente satisfactorias.		Este modelo se utiliza  cuando las actividades están ocurriendo simultáneamente así, se posibilita el conocimiento del estado real en el que se encuentra el proyecto.