Tabla comparativa metodologías de desarrollo de software
agiles y rígidas
RIGIDOS
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.
Pasos:
 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:
 Inicio (también llamado Incepción o Concepción).
 Elaboración.
 Desarrollo (también llamado Implementación, Construcción).
 Cierre (también llamado Transición).
AGILES/ FLEXIBLES
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.
 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.
 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
Pasos:
 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 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.
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.
Pasos:
 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:
 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
pizarra (Scrum Taskboard).
 Cada miembro del equipo inspecciona el trabajo que el
 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 refina 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:
 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.
 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
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
no lo sería, ya que se dispone de una completa planificación y
documentación que permite suplir este tipo de pérdidas.
De esta forma, un nuevo diseñador puede fácilmente tomar la
posición vacante siguiendo el plan de desarrollo sin ningún
problema. B/ Ágil: aunque altamente flexible, el enfoque ágil no
tiene la estructura que tiene la metodología en cascada, lo que
implica algunos inconvenientes. Los más significativos son los que
tienen que ver con la dificultad para predecir los presupuestos a
partir de líneas de tiempo. Y es que, sin una planificación completa,
todos los aspectos quedan vagamente definidos y son susceptibles
de generar confusión.
Pasos:
 Análisis de requisitos.
 Diseño del sistema.
 Diseño del programa.
 Codificación.
 Pruebas.
 Implementación del programa.
 Mantenimiento.
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.
Pasos:
 Comunicación con el cliente: Las tareas requeridas para
establecer comunicación entre el desarrollador y el cliente.
 Planificación: Las tareas requeridas para definir recursos, el
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
unas 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
del equipo del proyecto, El Mismo lugar de trabajo à Disminuye el
coste de la comunicación y Mejora individual à Mejora global del
equipo, de esta forma se tienen en cuenta las políticas de equipo
“Se utilizarán políticas diferentes para equipos diferentes” Codificación
por colores de Crystal: esto Dependiendo del tamaño del equipo.
Pasos:
 Entregas frecuentes, en base a un ciclo de vida iterativo e
incremental. En función del proyecto puede haber desde
entregas semanales hasta trimestrales. Para los que conozcan
Scrum: en Scrum las entregas son, máximo, cada 4 semanas,
en las Crystal se contemplan muchas más opciones.
 Mejora reflexiva. Que viene a ser mejora continua. Las
iteraciones ayudan a ir ajustando el proyecto, a ir mejorándolo.
 Comunicación osmótica. Traducido al castellano, que el equipo
esté en una misma ubicación física, para lograr la
comunicación cara a cara.
 Seguridad personal. Todo el mundo puede expresar su opinión
sin miedos, teniéndosele en cuenta, considerándose su
opinión, etc.
 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).
 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.
 Entorno técnico con pruebas automatizadas, gestión de la
configuración e integración continua.
tiempo y otra información relacionadas 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 acción: Las tareas requeridas para construir,
probar, instalar y proporcionar soporte al usuario (por ejemplo:
documentación y práctica).
 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.
 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:
 Seleccionar las referencias que se van a producir mediante
Kanban.
 Calcular la cantidad de piezas por kanban (tamaño del lote).
 Escoger el tipo de señal y el tipo de contenedor estándar. El
contenedor puede variar por referencia.
 Calcular el número de contenedores por referencia (curva de
producción) y la secuencia pitch.
 Dar seguiemiento (WIP o SWIP).