MODELO CASCADA

Se cree que este modelo fue el primer modelo de proceso introducido.

Este modelo metodologico ordena rigurosamente las etapas del ciclo de
vida del software, de forma que el inicio de cada etapa debe esperar a la
finalizacin de la inmediatamente anterior.
El modelo en cascada es un proceso de desarrollo secuencial.
Muy til para los sistemas grandes y que no requieren de muchos
cambios. En cambio para sistemas pequeos es una desventaja ya que
no es muy flexible.
Por ejemplo, los clientes pueden no ser conscientes exactamente de los
requisitos que quieren antes de ver un prototipo del trabajo; pueden
cambiar los requisitos constantemente, y los diseadores e
implementadores pueden tener poco control sobre esto. Si los clientes
cambian sus requisitos despus de que el diseo est terminado, este
diseo deber ser modificado para acomodarse a los nuevos requisitos,
invalidando una buena parte del esfuerzo.

MODELO INCREMENTAL
El modelo incremental combina elementos del modelo en cascada con la
filosofa interactiva de construccin de prototipos. Se basa en la filosofa
de construir incrementando las funcionalidades del programa.
* Mediante este modelo se genera software operativo de forma rpida y
en etapas tempranas del ciclo de vida del software.
* Es un modelo ms flexible, por lo que se reduce el coste en el cambio de
alcance y requisitos.

MODELO ESPIRAL
La distincin ms destacada entre el modelo en espiral es la tarea
explcita de evaluacin de riesgos. Aunque la gestin de riesgos es parte
de otros procesos tambin, no tiene una representacin propia en el
modelo de proceso. Para otros modelos la evaluacin de riesgos es una
subtarea. Adems no hay fases fijadas para la especificacin de
requisitos, diseo y pruebas en el modelo en espiral. Se puede usar

prototipado para encontrar y definir los requisitos.

La diferencia entre este modelo y el modelo de ciclo incremental es que
en el incremental se parte de que no hay incertidumbre en los requisitos
iniciales; en este, en cambio, se es consciente de que se comienza con
un alto grado de incertidumbre. En el incremental suponemos que
conocemos el problema y lo dividimos. Este modelo gestiona la
incertidumbre.
Si el cliente quiere seguir haciendo mejoras en el software, se vuelven a
evaluar las nuevas alternativas y riesgos y se realiza otra vuelta de la
espiral, as hasta que llegue un momento en el que el producto software
desarrollado sea aceptado y no necesite seguir mejorndose con otro
nuevo ciclo
Este sistema es muy utilizado en proyectos grandes y complejos como
puede ser, por ejemplo, la creacin de un sistema operativo.
Al ser un modelo de ciclo de vida orientado a la gestin de riesgos 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 riesgos.

MODELO BASADO EN COMPONENTES

Este modelo ofrece un prototipo, siendo este un documento vivo de
buen funcionamiento del producto final a corto plazo. El cliente
reacciona mucho mejor ante el prototipo, sobre el que puede
experimentar, que no sobre una especificacin escrita.
Ofrece visibilidad del producto desde el inicio del ciclo de vida con el
primer prototipo. Esto puede ayudar al cliente a definir mejor los
requisitos y a ver las necesidades reales del producto. Permite introducir
cambios en las iteraciones siguientes del ciclo. Permite la realimentacin
continua del cliente
Reduce el riesgo de construir productos que no satisfagan las
necesidades de los usuarios

PROCESO UNIFICADO
Los creadores y desarrolladores del proceso se centraron en el
diagnstico de las caractersticas de diferentes proyectos de software
fallidos. De esta forma intentaron reconocer las causas raz de tales
fallos. Tambin se fijaron en los procesos de ingeniera del software
existentes y sus soluciones para estos sntomas.
El proceso fue diseado con las mismas tcnicas con las que el equipo
sola disear software; tena un modelo orientado a objetos subyacente,
usando UML (Unified Modeling Language)

METODOLOGIAS AGILES
Los mtodos giles se caracterizan a veces como diametralmente
opuestos a mtodos orientados a pruebas o disciplinados. Esta distincin
es errnea, ya que esto implica que los mtodos giles no son
planificados ni disciplinados. Una distincin ms exacta es que los
mtodos pueden ser desde adaptativos a predictivos. Los mtodos
giles se acercan ms al lado adaptativo.
Los mtodos adaptativos se centran en la adaptacin rpida a los
cambios. Cuando las necesidades de un proyecto cambian, un equipo
adaptativo cambia tambin. Un equipo adaptativo tendr dificultades
para describir lo que pasar en el futuro. Cuanto ms lejana sea una
fecha, ms vago ser un mtodo adaptativo en cuanto a saber qu
pasar en esa fecha. Un equipo adaptativo puede informar exactamente
de las tareas que se realizarn la semana que viene, pero slo las
caractersticas planificadas para el prximo mes. Cuando se pregunta
por una versin de dentro de seis meses, un equipo adaptativo slo
podr ser capaz de reportar la declaracin de la misin de las versiones
o una declaracin de la relacin valor coste esperada.
Los mtodos giles tienen mucho en comn con las tcnicas de RAD
(desarrollo rpido de aplicaciones).