Tabla comparativa metodologías de desarrollo de software agiles y rígidas
RIGIDOS AGILES/ FLEXIBLES
RUP
Rational Unified Process.
El Proceso Racional Unificado o RUP es un proceso de
desarrollo de software desarrollado por la empresa Rational
Software, actualmente propiedad de IBM.
Características:
RUP se utiliza para forma disciplinada de asignar tareas y
responsabilidades en una empresa de desarrollo (quién hace
qué, cuándo y cómo).
• Desarrollo iterativo
• Administración de requisitos
• Uso de arquitectura basada en componentes
• Control de cambios
• Modelado visual del software
• Verificación de la calidad del software
• Pretende implementar las mejores prácticas en
Ingeniería de Software, de forma que se adapte a
cualquier proyecto
Junto con el Lenguaje Unificado de Modelado (UML),
constituye la metodología estándar más utilizada para el
análisis, diseño, implementación y documentación de
sistemas orientados a objetos.
Fases:
• La estructura dinámica de RUP es la que permite
que éste sea un proceso de desarrollo
fundamentalmente iterativo, y en esta parte se ven
inmersas las cuatro fases:
1. Inicio (también llamado Incepción o Concepción).
2. Elaboración.
3. Desarrollo (también llamado Implementación,
Construcción).
4. Cierre (también llamado Transición).
XP
La programación extrema o Xtreme Programming (XP) es
una metodología de desarrollo de la ingeniería de software
formulada 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.
Características:
Se puede considerarla programación extrema como la
adopción de las mejores metodologías de desarrollo de
acuerdo a lo que se pretende llevar a cabo con el proyecto, y
aplicarlo de manera dinámica durante el ciclo de vida del
software.
 Se diferencia de las metodologías tradicionales
principalmente en que pone más énfasis en la
adaptabilidad que en la previsibilidad.
 Se aplica de manera dinámica durante el ciclo de
vida del software.
 Es capaz de adaptarse a los cambios de requisitos.
 Los individuos e interacciones son más importantes
que los procesos y herramientas.
 Al individuo y las interacciones del equipo de
desarrollo sobre el proceso y las herramientas
Pasos:
 Desarrollo iterativo e incremental: Pequeñas
mejoras, unas tras otras.
 Pruebas unitarias continuas: Son frecuentemente
repetidas y automatizadas, incluyendo pruebas de
regresión. Se aconseja escribir el código de la
prueba antes de la codificación.
 Programación en parejas: Se recomienda que las
tareas de desarrollo se lleven a cabo por dos
personas en un mismo puesto. Se supone que la
mayor calidad del código escrito de esta manera -el
código es revisado y discutido mientras se escribe-
es más importante que la posible pérdida de
productividad inmediata.
 Frecuente integración del equipo de programación
con el cliente o usuario: Se recomienda que un
representante del cliente trabaje junto al equipo de
desarrollo.
 Corrección de todos los errores antes de añadir
nueva funcionalidad: Hacer entregas frecuentes.
 Refactorización del código: Es decir, reescribir
ciertas partes del código para aumentar su
legibilidad y Mantenibilidad, pero sin modificar su
comportamiento. Las pruebas han de garantizar que
en la refactorización no se ha introducido ningún
fallo.

MSF
Microsoft Solutions Framework (MSF) es un enfoque
personalizable para entregar con éxito soluciones
tecnológicas de manera más rápida, con menos recursos
humanos y menos riesgos, pero con resultados de más
calidad. MSF ayuda a los equipos a enfrentarse
directamente a las causas más habituales de fracaso de los
proyectos tecnológicos y mejorar así las tasas de éxito, la
calidad de las soluciones y el impacto comercial.
Características:
Principios fundamentales y actitudes en el contexto de MSF
para orientar y guiar a los equipos y sus miembros en el
trabajo en colaboración para entregar una solución
El modelo de equipo de MSF permite escalar los proyectos,
garantiza que los equipos satisfacen diversas necesidades de
las partes interesadas y define roles y responsabilidades
controlados por objetivos
El modelo de gobernanza de MSF (llamado anteriormente
modelo de proceso de MSF) permite obtener resultados
rápidos y de alta calidad por medio de un ciclo de vida de
proyecto comprobado que identifica actividades clave del
proyecto
Procesos:
Visión
 Desarrollar un entendimiento claro sobre lo que se
necesita dentro del contexto de las restricciones del
proyecto.
 Reunir al equipo necesario para concebir soluciones
con las opciones y los enfoques más adecuados para
esas necesidades y que también satisfagan de
manera óptima esas restricciones.
Planeación
 Hacer evolucionar la solución conceptual hasta
llegar a diseños y planes tangibles para que se
pueda compilar en una pista de compilación.
Compilar
 Propiedad del código compartido: en vez de dividir
la responsabilidad en el desarrollo de cada módulo
en grupos de trabajo distintos, este método
promueve el que todo el personal pueda corregir y
extender cualquier parte del proyecto. Las
frecuentes pruebas de regresión garantizan que los
posibles errores serán detectados.
 Simplicidad del código: es la mejor manera de que
las cosas funcionen. Cuando todo funcione se podrá
añadir funcionalidad si es necesario. La
programación extrema apuesta que es más sencillo
hacer algo simple y tener un poco de trabajo extra
para cambiarlo si se requiere, que realizar algo
complicado y quizás nunca utilizarlo.
SCRUM
Proyectos de Desarrollo Ágil
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.
Características:
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,
la flexibilidad y la productividad son fundamentales.
Proceso:
Planificación de la iteración
El primer día de la iteración se realiza la reunión de
planificación de la iteración. Tiene dos partes:
1. Selección de requisitos (4 horas máximo). El
cliente presenta al equipo la lista de requisitos
priorizada del producto o proyecto. El equipo
pregunta al cliente las dudas que surgen y
selecciona los requisitos más prioritarios que se
compromete a completar en la iteración, de manera
que puedan ser entregados si el cliente lo solicita.
Planificación de la iteración (4 horas máximo). El equipo
elabora la lista de tareas de la iteración necesarias para
desarrollar los requisitos a que se ha comprometido. La
estimación de esfuerzo se hace de manera conjunta y los
miembros del equipo se autoasignan las tareas.
Ejecución de la iteración
Cada día el equipo realiza una reunión de
sincronización (15 minutos máximo), normalmente
delante de un tablero físico o pizarra (Scrum Taskboard).
Cada miembro del equipo inspecciona el trabajo que el
  Compilar los aspectos de la solución de acuerdo con
las entregas de la pista de planeación, como
diseños, planes, programaciones y requisitos.
Estabilización
 Mejorar la calidad de la solución para satisfacer los
criterios de lanzamiento para la implementación en
producción.
 Validar que la solución satisfaga las necesidades y
expectativas de las partes interesadas.
 Validar la facilidad de uso de la solución desde la
perspectiva de los usuarios.
 Maximizar el éxito y minimizar los riesgos
asociados con la implementación y las operaciones
de la solución en los entornos de destino de la
solución.
Deploy
 Integrar una solución correctamente en producción
dentro de los entornos designados.
 Transferir la responsabilidad de la entrega restante
de la solución de un equipo de proyecto a equipos
de operaciones y soporte técnico tan pronto y de
manera tan fluida como sea posible.
CASCADA
La metodología en cascada es un modelo lineal de diseño de
software que emplea un proceso de diseño secuencial.
Características:
El desarrollo fluye secuencialmente desde el punto inicial
hasta el punto final, con varias etapas diferentes:
planteamiento, iniciación, análisis, diseño, construcción,
pruebas, implementación y mantenimiento.
La metodología en cascada supera algunas de las
limitaciones de otros métodos, como: A/ Scrum: los
procesos de desarrollo que siguen la metodología en
cascada tienden a ser más seguro, ya que existe una firme
orientación al plan. A diferencia del método Scrum, donde
el abandono de uno de los miembros del equipo puede
suponer un grave problema, con la metodología en cascada
resto está realizando (dependencias entre tareas, progreso
hacia el objetivo de la iteración, obstáculos que pueden
impedir este objetivo) para poder hacer las adaptaciones
necesarias que permitan cumplir con el compromiso
adquirido. En la reunión cada miembro del equipo
responde a tres preguntas:
 ¿Qué he hecho desde la última reunión de
sincronización?
 ¿Qué voy a hacer a partir de este momento?
 ¿Qué impedimentos tengo o voy a tener?
Durante la iteración el Facilitador (Scrum Master) se
encarga de que el equipo pueda cumplir con su compromiso
y de que no se merme su productividad.
 Elimina los obstáculos que el equipo no puede
resolver por sí mismo.
 Protege al equipo de interrupciones externas que
puedan afectar su compromiso o su productividad.
Durante la iteración, el cliente junto con el equipo refinan la
lista de requisitos (para prepararlos para las siguientes
iteraciones) y, si es necesario, cambian o replanifican los
objetivos del proyecto para maximizar la utilidad de lo que
se desarrolla y el retorno de inversión.
Inspección y adaptación
El último día de la iteración se realiza la reunión de revisión
de la iteración. Tiene dos partes:
1. Demostración (4 horas máximo). El equipo
presenta al cliente los requisitos completados en la
iteración, en forma de incremento de producto
preparado para ser entregado con el mínimo
esfuerzo. En función de los resultados mostrados y
de los cambios que haya habido en el contexto del
proyecto, el cliente realiza las adaptaciones
necesarias de manera objetiva, ya desde la primera
iteración, replanificando el proyecto.
2. Retrospectiva (4 horas máximo). El equipo analiza
cómo ha sido su manera de trabajar y cuáles son los
problemas que podrían impedirle progresar
adecuadamente, mejorando de manera continua su
productividad. El Facilitador se encargará de ir
eliminando los obstáculos identificados.
CRYSTAL
esta forma se pretende obtener mayor rentabilidad en el
desarrollo de proyectos de software, Los métodos Crystal
no prescriben prácticas concretas, porque están en continuo
cambio.
Características:
Se tiene en cuenta que Crystal da vital importancia a las
personas que componen el equipo de un proyecto, y por
tanto sus puntos de estudio son: Aspecto humano del
equipo, Tamaño de un equipo (número de componentes),
Comunicación entre los componentes, Distintas políticas a
seguir, Espacio físico de trabajo. Compuesta por una
características importantes como lo son Crystal aconseja
que el tamaño del equipo sea reducido (Pocos componentes)
También La mejora de la comunicación entre los miembros
no lo sería, ya que se dispone de una completa planificación del equipo del proyecto, El Mismo lugar de trabajo à
y documentación que permite suplir este tipo de pérdidas. Disminuye el coste de la comunicación y Mejora individual
De esta forma, un nuevo diseñador puede fácilmente tomar à Mejora global del equipo, de esta forma se tienen en
la posición vacante siguiendo el plan de desarrollo sin cuenta las políticas de equipo “Se utilizarán políticas
ningún problema. B/ Ágil: aunque altamente flexible, el diferentes para equipos diferentes” Codificación por colores
enfoque ágil no tiene la estructura que tiene la metodología de Crystal: esto Dependiendo del tamaño del equipo.
en cascada, lo que implica algunos inconvenientes. Los más
significativos son los que tienen que ver con la dificultad Pasos:
para predecir los presupuestos a partir de líneas de tiempo. 1 – Entregas frecuentes, en base a un ciclo de vida
Y es que, sin una planificación completa, todos los aspectos iterativo e incremental. En función del proyecto puede
quedan vagamente definidos y son susceptibles de generar haber desde entregas semanales hasta trimestrales. Para los
confusión. que conozcan Scrum: en Scrum las entregas son, máximo,
cada 4 semanas, en las Crystal se contemplan muchas más
Pasos: opciones.
1. Análisis de requisitos. 2 – Mejora reflexiva. Que viene a ser mejora continua. Las
2. Diseño del sistema. iteraciones ayudan a ir ajustando el proyecto, a ir
3. Diseño del programa. mejorándolo.
4. Codificación. 3 – Comunicación osmótica. Traducido al castellano, que
5. Pruebas. el equipo esté en una misma ubicación física, para lograr la
6. Implementación del programa. comunicación cara a cara.
7. Mantenimiento. 4 – Seguridad personal. Todo el mundo puede expresar su
opinión sin miedos, teniéndosele en cuenta, considerándose
su opinión, etc.
5- Enfoque. Períodos de no interrupción al equipo (2h
horas), objetivos y prioridades claros, definiendo así tareas
concretas. Si llevas desde hace tiempo pasando por este
blog, recordarás ya comentábamos, tiempo a, aquello de
que el entorno físico afecta al rendimiento del desarrollador
software (te dejo aquel post).
6 – Fácil acceso a usuarios expertos. Las Crystal (a
diferencia de otras como XP) no exigen que los usuarios
estén continuamente junto al equipo de proyecto (no todas
las organizaciones pueden hacerlo), sí que, como mínimo,
semanalmente debe haber reuniones y los usuarios deben
estar accesibles.
7 – Entorno técnico con pruebas automatizadas, gestión
de la configuración e integración continua.

ESPIRAL
Inicialmente fue propuesto por un ingeniero en informática,
llamado Barry W. Boehm, dentro de un artículo publicado
en 1986, como una mejora del modelo de desarrollo en
cascada.
Características:
Cada ciclo comienza con la elaboración de objetivos
funcionales y de rendimiento y las formas posibles de
alcanzar estos objetivos.
Puede combinarse con otros modelos, como el de cascada o
el evolutivo.
Es un modelo centrado en los riesgos.
Se utiliza para sistemas complejos.
Se empieza un nuevo ciclo cada vez que el cliente quiera
hacer mejoras en el software, así, se vuelven a evaluar
nuevas alternativas y riesgos hasta que el sistema sea
aceptado.
Fases:
KANBAN
Kanban es una palabra japonesa que significa algo así como
“tarjetas visuales” (kan significa visual, y ban tarjeta). Esta
técnica se creó en Toyota, y se utiliza para controlar el
avance del trabajo, en el contexto de una línea de
producción.
Creada por Toyota para mejorar su producción usando
técnicas just-in-time (JIT).
Características:
Kanban no es una técnica específica del desarrollo software,
su objetivo es gestionar de manera general como se van
completando tareas, pero en los últimos años se ha utilizado
en la gestión de proyectos de desarrollo software, a menudo
con Scrum (lo que se conoce como Scrumban).
Pasos:
El trabajo se divide en partes, normalmente cada una de
esas partes se escribe en un post-it y se pega en una pizarra.
Los post-it suelen tener información variada, si bien, aparte
  Los Objetivos: qué necesidad debe cubrir el
producto.
 Alternativas: las diferentes formas de conseguir los
objetivos de forma exitosa, desde diferentes puntos
de vista como pueden ser:
1. Características: experiencia del personal,
requisitos a cumplir, etc.
2. Formas de gestión del sistema.
3. Riesgo asumido con cada alternativa.
 Desarrollar y Verificar: Programar y probar el
software.
PROCESO EVOLUTIVO
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. Los modelos “Iterativo
Incremental” y “Espiral” (entre otros) son dos de los más
conocidos y utilizados del tipo evolutivo.
Características:
La idea detrás de este modelo es el desarrollo de una
implantación del sistema inicial, exponerla a los
comentarios del usuario, refinarla en N versiones hasta que
se desarrolle el sistema adecuado. Una ventaja de este
modelo es que se obtiene una rápida realimentación del
usuario, ya que las actividades de especificación, desarrollo
y pruebas se ejecutan en cada iteración.
Procesos:
Para tal fin se describen, fundamentalmente, herramientas
de Análisis y Diseño Orientado a Objetos (UML), sus
diagramas, especificación, y criterios de aplicación de las
mismas. Como complemento se describirán las
metodologías de desarrollo de software que utilizan dichas
herramientas, ciclos de vida asociados y discusión sobre el
proceso de desarrollo de software más adecuado para las
diferentes aplicaciones ejemplos que se presentarán.
Principalmente, se presentará el Proceso Unificado el cual
utiliza un ciclo de vida iterativo e incremental.
de la descripción, debieran tener la estimación de la
duración de la tarea.
1. Petición de tareas.
2. Selección de tareas
3. Desarrollo
4. Prueba
5. Terminado
LEAN
Fue en los años 80 en Japón, que se comenzó a usar el
término “Lean Manufacturing “, que en español significa
manufactura magra. El objetivo era hacer que la producción
de vehículos en ese país fuera más eficiente.
Características:
Uno de los preceptos de la metodología lea es el uso de
métodos ágiles. Estos métodos utilizan dos premisas
importantes:
La primera es el concepto de iteración, que se refiere más
bien a la expresión “quick win “, es decir, pequeñas mejoras
en los procesos que se pueden obtener rápidamente, pero
que pueden aportar resultados visibles a corto plazo. Esto
anima al equipo a avanzar con cada nueva “pequeña
victoria”.
La segunda es la participación efectiva de los clientes y
usuarios finales durante el modelado de procesos y su
mejora, lo que crea importantes feedbacks y contribuciones
para que el resultado final corresponda con los intereses de
aquellos que realmente se beneficiarán del proceso (o el
desarrollo de un producto).
Pasos:
1 – Dar la debida importancia al proyecto de mejora de
procesos
Antes de empezar el trabajo, hay que tomar las mismas
medidas necesarias para que cualquier proceso funcione:
establecer las metas, el alcance del proyecto, quiénes son
los miembros del equipo y sus responsabilidades, los
recursos necesarios, los plazos de entrega y los
cronogramas.
En otras palabras, haga un plan antes de empezar.
2 – Involucre a los participantes en la búsqueda de un
cambio efectivo
No todas las personas se sienten cómodas con los cambios
en las organizaciones. Incluso trabajando con procesos
ineficientes, muchos tienen miedo de salir de la zona de
confort y enfrentar a algo nuevo.
Es muy importante involucrar a todos para que crean en la
necesidad de cambio y los beneficios que el nuevo proceso

INCREMENTAL
Se basa en la filosofía de construir incrementando las
funcionalidades del programa. Este modelo aplica
secuencias lineales de forma escalonada mientras progresa
el tiempo en el calendario. Cada secuencia lineal produce un
incremento del software.
Características:
El modelo incremental combina elementos del modelo en
cascada con la filosofía interactiva de construcción de
prototipos.
Cuando se utiliza un modelo incremental, el primer
incremento es a menudo un producto esencial, sólo con los
requisitos básicos.
Este modelo se centra en la entrega de un producto
operativo con cada incremento. Los primeros incrementos
son versiones incompletas del producto final, pero
proporcionan al usuario la funcionalidad que precisa y
también una plataforma para la evaluación.
Fases:
• Cada fase de una iteración es rígida y no se
superponen con otras.
aportará en el desempeño de las tareas y el logro de
resultados.
3- Garantice el apoyo de los líderes de la compañía
Los recursos son fundamentales, ya sean financieros, de
equipo, de espacio, de personal y en especial del tiempo que
los miembros del equipo dedican al proyecto.
Sin el apoyo de líderes de la compañía a nivel estratégico,
será imposible lograr los resultados deseados.
4- Comience con procesos sencillos
Uno de los fundamentos de la metodología lea son los
pequeños avances, iteraciones continuas y acumulativas que
se convertirán en un mejor resultado final.
Evite la tentación de comenzar con los procesos más
urgentes e ineficientes. Opte por algo simple, resuelva,
motive al equipo con los resultados y utilice este
aprendizaje para después dedicarse a los grandes desafíos de
realizar mejoras.
5. Determine un espacio físico exclusivo para las reuniones
del proyecto
Es fundamental contar con un lugar específico para realizar
las reuniones enfocadas en la mejora de los procesos. Es
muy útil tener una pizarra grande en la pared, donde dibujar
los diagramas de procesos.
Por otra parte, cuando todos perciben que hay un lugar
específico para dedicarse al proceso, eso muestra a los otros
miembros de la compañía que este es un esfuerzo serio e
importante.
FDD
(FEACTURE DRIVEN DEVELOPMENT)
Desarrollo Basado en Funciones.
Fue desarrollada por Jeff De Luca y Peter Coad a mediados
de los años 90. Esta metodología se enfoca en iteraciones
cortas, que permiten entregas tangibles del producto en un
periodo corto de tiempo, de como máximo dos semanas.
Características:
Es una metodología ágil diseñada para el desarrollo de
software, basada en la calidad y el monitoreo constante del
proyecto.
Se preocupa por la calidad
Ayuda a contrarrestar situaciones como el exceso en el
presupuesto, fallas en el programa o el hecho de entregar
menos de lo deseado.
Propone tener etapas de cierre cada dos semanas. Se
obtienen resultados periódicos y tangibles.
Proceso:
Desarrollar un modelo global
Construir una lista
Planear
 • Pueden surgir problemas referidos a la arquitectura
del sistema porque no todos los requisitos se han
reunido, ya que se supone que todos ellos se han
definido al inicio
RAD
Modelo de Desarrollo Rápido de Aplicaciones (RAD)
Es un proceso de desarrollo de software, desarrollado
inicialmente por James Martin en 1980.
Características: El método comprende el desarrollo iterativo
(que repite), la construcción de prototipos y el uso de
utilidades caso. Tradicionalmente, el desarrollo rápido de
aplicaciones tiende a englobar también la usabilidad,
utilidad y la rapidez de ejecución.
Fases:
 Modelado de gestión: el flujo de información
entre las funciones de gestión se modela de forma
que responda a las siguientes preguntas: ¿Qué
información conduce el proceso de gestión? ¿Qué
información se genera? ¿Quién la genera? ¿A
dónde va la información? ¿Quién la proceso?
 Modelado de datos: el flujo de información
definido como parte de la fase de modelado de
gestión se refina como un conjunto de objetos de
datos necesarios para apoyar la empresa. Se
definen las características (llamadas atributos) de
cada uno de los objetos y las relaciones entre
estos objetos.
 Modelado de proceso: los objetos de datos
definidos en la fase de modelado de datos quedan
transformados para lograr el flujo de información
necesario para implementar una función de
gestión. Las descripciones del proceso se crean
para añadir, modificar, suprimir, o recuperar un
objeto de datos. Es la comunicación entre los
objetos.
 Generación de aplicaciones: El DRA asume
la utilización de técnicas de cuarta generación. En
lugar de crear software con lenguajes de
programación de tercera generación, el proceso
DRA trabaja para volver a utilizar componentes
de programas ya existentes (cuando es posible) o
a crear componentes reutilizables (cuando sea
necesario). En todos los casos se utilizan
herramientas automáticas para facilitar la
construcción del software.
 Pruebas de entrega: Como el proceso DRA
enfatiza la reutilización, ya se han comprobado
muchos de los componentes de los programas.
Esto reduce tiempo de pruebas. Sin embargo, se
deben probar todos los componentes nuevos y se
deben ejercitar todas las interfaces a fondo.
Diseñar
Construir
ASD
El método ágil ASD (Adaptive Software Development)
traducido en español significa Desarrollo Adaptable de
Software es un modelo de implementación de patrones
ágiles para desarrollo de software.
Características:
Sus principales características del ASD son:
1. Iterativo.
2. Orientado a los componentes de software (la
funcionalidad que el producto va a tener,
características, etc.) más que a las tareas en las que
se va a alcanzar dicho objetivo.
3. Tolerante a los cambios.
4. Guiado por los riesgos
5. La revisión de los componentes sirve para
aprender de los errores y volver a iniciar el ciclo de
desarrollo
Ciclo de vida:
ASD utiliza un "cambio orientado hacia el ciclo de vida",
que tiene tres componentes que son: especular colaborar y
aprender.
Especular
Una primera fase de iniciación para establecer los
principales objetivos y metas del proyecto en su conjunto y
comprender las limitaciones (zonas de riesgo) con las que
operará el proyecto.
En ASD se realizan estimaciones de tiempo sabiendo que
pueden sufrir desviaciones. Sin embargo, estas son
necesarias para la correcta atención de los trabajadores que
se mueven dentro de plazos de forma que puedan priorizar
sus tareas.
Se decide el número de iteraciones para consumir el
proyecto, prestando atención a las características que
pueden ser utilizadas por el cliente al final de la iteración.
Son por tanto necesarios, marcar objetivos prioritarios
dentro de las mismas iteraciones.
Estos pasos se pueden volver a examinar varias veces antes
de que el equipo y los clientes están satisfechos con el
resultado.
Colaborar
Es la fase donde se centra la mayor parte del desarrollo
manteniendo una componente cíclica. Un trabajo importante
es la coordinación que asegure que lo aprendido por un
equipo se transmite al resto y no tenga que volver a ser
aprendido por los otros equipos.
Aprender

MODELO PROTOTIPO
También conocido como desarrollo con prototipación o
modelo de desarrollo evolutivo, se inicia con la definición
de los objetivos globales para el software, luego se
identifican los requisitos conocidos y las áreas del esquema
en donde es necesaria más definición. Este modelo se utiliza
para dar al usuario una vista preliminar de parte del
software.
Características:
Este modelo es básicamente prueba y error ya que si al
usuario no le gusta una parte del prototipo significa que la
prueba fallo por lo cual se debe corregir el error que se
tenga hasta que el usuario quede satisfecho. Además, el
prototipo debe ser construido en poco tiempo, usando los
programas adecuados y no se debe utilizar mucho dinero
pues a partir de que este sea aprobado nosotros podemos
iniciar el verdadero desarrollo del software. Pero eso si al
construir el prototipo nos asegura que nuestro software sea
de mejor calidad, además de que su interfaz sea de agrado
para el usuario. Un prototipo podrá ser construido solo si
con el software es posible experimentar.
Etapas: Etapas
 Recolección y refinamiento de requisitos
 Modelado, diseño rápido
 Construcción del Prototipo
 Desarrollo, evaluación del prototipo por el cliente
 Refinamiento del prototipo
 Producto de Ingeniería
La última etapa termina con una serie de ciclos de
colaboración, su trabajo consiste en capturar lo que se ha
aprendido, tanto positivo como negativo. Es un elemento
crítico para la eficacia de los equipos.
Jim Highsmith identifica cuatro tipos de aprendizaje en esta
etapa:
Calidad del producto desde un punto de vista del cliente. Es
la única medida legítima de éxito, pero además, dentro de
las metodologías ágiles, los clientes tienen un valor
importante.
Calidad del producto desde un punto de vista de los
desarrolladores. Se trata de la evaluación de la calidad de
los productos desde un punto de vista técnico. Ejemplos de
esto incluyen la adhesión a las normas y objetivos conforme
a la arquitectura.
La gestión del rendimiento. Este es un proceso de
evaluación para ver lo que se ha aprendido mediante el
empleo de los procesos utilizados por el equipo.
Situación del proyecto. Como paso previo a la planificación
de la siguiente iteración del proyecto, es el punto de partida
para la construcción de la siguiente serie de características.
XBRBREED
XBreed es una mezcla de ideas XP, Scrum y Alexander
desarrolladas por Mike Beedle. XBreed utiliza SCRUM
como su marco de gestión mientras adapta una versión
reducida de Extreme Programming para su proceso de
desarrollo.
Características:
Fue diseñado con la intención de desarrollar "software
reutilizable en tiempo récord". Al emplear patrones de
diseño para crear objetos reutilizables, XBreed crea una
biblioteca de componentes que, idealmente, puede
reinsertarse fácilmente en nuevos proyectos de software.
Proceso:
El proceso de desarrollo depende en gran medida de la
capacidad y el conocimiento de los miembros de su equipo,
lo que requiere una fuerte transferencia de conocimiento y
poca sobrecarga de comunicación para mantener el proyecto
funcionando sin problemas y de manera eficiente, requisitos
que son ayudados por el uso de SCRUM.
 DSDM
Dynamic Systems Development Method
Método Dinámico de desarrollo de sistemas
DSDM fue creado en los años 90 por un consorcio de
proveedores y de expertos en la materia software de
creación de sistemas de información (IS).

Características:
DSDM se centra en los proyectos de sistemas de
información que son caracterizados por presupuestos y
agendas apretadas.
DSDM se centra en:
Entornos web especialmente sensibles al tiempo.
La colaboración entre los departamentos implicados en el
proyecto web.

Iteración funcional:
Iteración funcional del modelo:
Se soluciona a detalle aspectos funcionales del negocio.
Iteración de diseño y construcción:
El producto se vuelve apto para los usuarios.
Las dos fases consisten en ciclos de 4 actividades:
Identificación
Planificación
Producción
Validación
PUA
(Proceso Unificado Ágil)
Fue desarrollado Scott Ambler.
Su objetivo es mejorar la productividad.
Tiene un enfoque intermedio XP y RUP.

Características:
Para el Proceso Unificado Ágil, hay algunas razones válidas
para crear documentación, resumidas en la siguiente lista:
Los promotores del proyecto lo requieren.
Para definir un modelo de contrato.
Como soporte a la memoria organizacional. Ya que es
necesario contar con documentación apropiada para su uso,
soporte técnico y mantenimiento a lo largo del tiempo.
Para labores de auditoría.
Para ayudar a pensar sobre algo. El simple acto de escribir
ideas en un papel puede contribuir a consolidarlas y a
descubrir problemas en ellas.

Fases:
• Cuenta con 4 fases (Son iguales que las de RUP)
 Iniciación: identificar el alcance inicial del
proyecto, una arquitectura potencial para el sistema
y obtener financiación y aceptación de los
promotores
 Elaboración: Identificar y validar arquitectura del
sistema
 Construcción
 Transición: En esta fase se valida y despliega el
sistema en el entorno de producción.