El Modelo en Espiral se divide en regiones de tareas que incluyen comunicación con el cliente, planificación, análisis de riesgos, ingeniería, construcción y adaptación, y evaluación del cliente. El modelo proporciona el desarrollo rápido de versiones incrementales del software a través de iteraciones que comienzan con prototipos y terminan con versiones completas del sistema.

1. MODELO EN ESPIRAL
Este modelo, propuesto por Bohem en 1988 [BOE88], es un modelo de proceso de software evolutivo
que acompaña la naturaleza evolutiva de con los aspectos controlados y sistemáticos del ciclo de vida
tradicional. Proporciona el potencial para el desarrollo rápido de versiones incrementales del software.
En este modelo, el sistema se desarrolla en una serie de versiones incrementales. Durante las
primeras iteraciones, la versión incremental podría ser un modelo en papel o un prototipo. Durante las
últimas iteraciones se producen versiones cada vez más completas de ingeniería del sistema. .
El Modelo en Espiral se divide en un número de actividades estructurales, también llamadas "regiones
de tareas". Generalmente existen entre tres y seis regiones de tareas:
Comunicación con el cliente.- Las tareas requeridas para establecer comunicación entre el
desarrollador y el cliente, sea revisar especificaciones, plantear necesidades, etc.
Planificación.- Las tareas requeridas para definir recursos, tiempos e información relacionada con el
proyecto.
Análisis de riesgos.- Las tareas requeridas para evaluar riesgos técnicos y de gestión.
Ingeniería.- Las tareas requeridas para construir una o más representaciones de la aplicación
Construcción y adaptación.- Las tareas requeridas para construir, probar, instalar y proporcionar
soporte al usuario.
Evaluación del cliente.- Las tareas requeridas para obtener la reacción del cliente, según la evaluación
de las representaciones del software creadas durante la etapa de ingeniería e implementada durante la
etapa de instalación

2. MODELO EN CASCADA
También conocido como modelo clásico, modelo tradicional o modelo lineal secuencial. Él método de
la cascada es considerado como el enfoque clásico para el ciclo de vida del desarrollo de sistemas, se
puede decir que es un método puro que implica un desarrollo rígido. está es una secuencia de
actividades(o etapas) que consisten en el análisis de requerimientos, él diseño ,la implementación, la
integración y las pruebas .
El análisis de requerimientos: consiste en reunir las necesidades del producto y casi siempre su salida
es texto.
El diseño: describe la estructura interna del producto y suele representarse con diagramas y texto.
La implementación: significa programación. Producto de esta etapa es el código en cualquier nivel,
incluido el producido por sistemas de generación automática.
La integración: es el proceso de integración es el proceso de ensamblar las partes para completar el
producto.

3. MODELO DE PROTOTIPO
El modelo de prototipos permite que todo el sistema, o algunos de sus partes, se construyan
rápidamente para comprender con facilidad y aclarar ciertos aspectos en los que se aseguren que el
desarrollador, el usuario, el cliente estén de acuerdo en lo que se necesita así como también la
solución que se propone para dicha necesidad y de esta forma minimizar el riesgo y la incertidumbre
en el desarrollo, este modelo se encarga del desarrollo de diseños para que estos sean analizados y
prescindir de ellos a medida que se adhieran nuevas especificaciones, es ideal para medir el alcance
del producto, pero no se asegura su uso real.

4. Metodologías Tradicionales Metodologías Ágiles
- Rigidez ante los cambios, de manera
lentos o moderada
- Los clientes interactúan con el equipo
de desarrollo mediante reuniones
- Grupos de gran tamaño y varias
veces distribuidos en diferentes sitios
- Dependencia de la arquitectura de
software mediante modelos
- Poco Feedback lo que extiende el
tiempo de entrega
- Mínimos roles
- Basadas en normas de estándares de
desarrollo
- Procesos muy controlados por
políticas y normas
- Seguimiento estricto del plan inicial
de desarrollo
- Flexibilidad ante los cambios del
proyecto de forma moderada a rápida
- Los clientes hacen parte del equipo
de desarrollo
- Grupos pequeños (promedio 10
participantes in situ) en el mismo lugar.
- Menor dependencia de la arquitectura
de software
- Continuo Feedback acortando el
tiempo de entrega
- Diversidad de roles
- Basadas en heurísticas a partir de
prácticas de producción de código
- Procesos menos controlados,
pocas políticas y normas
- Capacidad de respuesta ante los
cambios

5. METOLOGIAS AGILES
XP
HISTORIA
La programación extrema o eXtreme Programming (XP) es un enfoque de la ingeniería de software formulado
por Kent Beck, autor del primer libro sobre la materia, Extreme Programming Explained: Embrace Change
(1999). Es el más destacado de los procesos ágiles de desarrollo de software. Al igual que éstos, la
programación extrema se diferencia de las metodologías tradicionales principalmente en que pone más
énfasis en la adaptabilidad que en la previsibilidad. Los defensores de XP consideran que los cambios de
requisitos sobre la marcha son un aspecto natural, inevitable e incluso deseable del desarrollo de proyectos.
Creen que ser capaz de adaptarse a los cambios de requisitos en cualquier punto de la vida del proyecto es
una aproximación mejor y más realista que intentar definir todos los requisitos al comienzo del proyecto e
invertir esfuerzos después en controlar los cambios en los requisitos.
Es una metodología ágil centrada en potenciar las relaciones interpersonales como clave para el éxito en
desarrollo de software, promoviendo el trabajo en equipo, preocupándose por el aprendizaje de los
desarrolladores, y propiciando un buen clima de trabajo. XP se basa en realimentación continua entre el
cliente y el equipo de desarrollo, comunicación fluida entre todos los participantes, simplicidad en las
soluciones implementadas y coraje para enfrentar los cambios. XP se define como especialmente adecuada
para proyectos con requisitos imprecisos y muy cambiantes, y donde existe un alto riesgo técnico.
¿QUÉ ES PROGRAMACIÓN EXTREMA O XP?
Metodología liviana de desarrollo de software
Conjunto de practicas y reglas empleadas para desarrollar software
Basada en diferentes ideas acerca de cómo enfrentar ambientes muy cambiantes
Originada en el proyecto C3 para Chrysler
En vez de planificar, analizar y diseñar para el futuro distante, hacer todo esto un poco cada vez, a través de
todo el proceso de desarrollo

6. METODOLIGIA SCRUM
¿Qué es SCRUM?
Scrum es un proceso en el que se aplican de manera regular un conjunto de buenas prácticas para trabajar
colaborativamente, en equipo, y obtener el mejor resultado posible de un proyecto. Estas prácticas se apoyan
unas a otras y su selección tiene origen en un estudio de la manera de trabajar de equipos altamente
productivos.
En Scrum se realizan entregas parciales y regulares del producto final, priorizadas por el beneficio que
aportan al receptor del proyecto. Por ello, Scrum está especialmente indicado para proyectos en entornos
complejos, donde se necesita obtener resultados pronto, donde los requisitos son cambiantes o poco
definidos, donde la innovación, la competitividad, laflexibilidad y la productividad son fundamentales.
Scrum también se utiliza para resolver situaciones en que no se está entregando al cliente lo que necesita,
cuando las entregas se alargan demasiado, los costes se disparan o la calidad no es aceptable, cuando se
necesita capacidad de reacción ante la competencia, cuando la moral de los equipos es baja y la rotación alta,
cuando es necesario identificar y solucionar ineficiencias sistemáticamente o cuando se quiere trabajar
utilizando un proceso especializado en el desarrollo de producto.
Ver en detalle cuales son los beneficios de Scrum, sus fundamentos y sus requisitos.
El proceso
En Scrum un proyecto se ejecuta en bloques temporales cortos y fijos (iteraciones de un mes natural y hasta
de dos semanas, si así se necesita). Cada iteración tiene que proporcionar un resultado completo, un
incremento de producto final que sea susceptible de ser entregado con el mínimo esfuerzo al cliente cuando lo
solicite.

7. METODOLOGIA KANBAN
Kanban se basa en un sistema de producción que dispara trabajo solo cuando existe capacidad para
procesarlo. El disparador de trabajo es representado por tarjetas kanban de las cuales se dispone de una
cantidad limitada.
Cada tarjeta Kanban acompaña a un item de trabajo durante todo el proceso de producción, hasta que éste,
es empujado fuera del sistema, liberando una tarjeta. Un nuevo ítem de trabajo, solo podrá ser
ingresado/aceptado si se dispone de una tarjeta kanban libre.
Este proceso de producción, donde un trabajo se introduce al sistema solo cuando existe disponibilidad para
procesarlo, se denomina pull (tirar) en contrapartida al mecanismo push (empujar), donde el trabajo se
introduce en función de la demanda.
En el desarrollo de Software, Kanban fue introducido por David Anderson de la Unidad de Negocios XIT de
Microsoft, en 2004, reemplazando el sistemas de tarjetas por un tablero visual similar al de Scrum, pero con
características extendidas que veremos a continuación.
Las tres reglas de Kanban
Con tan solo tres simples reglas, Kanban demuestra ser una de las metodologías adaptativas que menos
resistencia al cambio presenta. Dichas reglas son:
Regla #1: Mostrar el proceso
Consiste en la visualización de todo el proceso de desarrollo, mediante un tablero físico, generalmente,
públicamente asequible. El objetivo de mostrar el proceso, consiste en:
Entender mejor el proceso de trabajo actual;
Conocer los problemas que puedan surgir y tomar decisiones;
Mejorar la comunicación entre todos los interesados/participantes del proyecto;
Hacer los futuros procesos más predecibles.
Regla #2: Limitar el trabajo en curso (WIP)
Los límites del WIP (work in progress – trabajo en curso -) consisten en acordar anticipadamente, la cantidad
de ítems que pueden abordarse por cada proceso (es decir, por columnas del tablero).
El principal objetivo de establecer estos límites, es el de detectar cuellos de botella.
Regla #3: Optimizar el flujo de trabajo
El objetivo una la producción estable, continua y previsible. Midiendo el tiempo que el ciclo completo de
ejecución del proyecto demanda (por ejemplo, cantidad de días desde el inicio del análisis hasta el fin del
deploy – según el ejemplo del tablero anterior), se obtiene el CycleTime.
Al dividir, el CycleTime por el WIP, se obtiene el "rendimiento de trabajo", denominado Throughput, es decir, la
cantidad de ítems que un equipo puede terminar en un determinado período de tiempo.