Comparativa entre metodologías SCRUM y RUP

Hugo Eduardo Carvajalino Solano

Ingenieria de sistemas
Universidad Francisco De Paula Santander, Ocaña
hecarvajalinos@ufpso.edu.co
 Resumen- Las metodologías
de desarrollo de software ágil
y flexible a medida que pasa
el tiempo han tomado una
gran importancia en el
desarrollo de objetivos para
cubrir las necesidades
planteadas y en la ejecución
de las labores de la ingeniería
de sistemas específicamente,
en especial en el campo de
desarrollo de software y/o
ingeniería de software, ya sea
para beneficio del equipo de
desarrollo como para el
cliente. De manera general
se puede definir a la
metodología de desarrollo
ágil como un marco de
trabajo conceptual de la
ingeniería de software que
promueve interacciones en el
desarrollo a lo largo de todo
el ciclo de vida del proyecto.
Dentro de las metodologías de
desarrollo ágil encontramos la
metodología SCRUM, la cual
es considerada por los
desarrolladores como la más
flexible y compatible ya que
cumple con las necesidades y
requisitos que se requieren en
la ejecución del trabajo; se
puede mencionar que este tipo
de metodología está más
enfocada a personas y no a
procesos, al funcionamiento
del sistemas y no a la
documentación, a la
colaboración y no al
contrato(esto refiriéndose a la
relación con el cliente), y en la
adaptación y no al
seguimiento de planes. Por
otra parte se halla la
metodología RUP,
considerada como la más
tradicional o estándar usada
para el análisis,
implementación y objetivos de la ingeniería de
documentación de sistemas
enfocados a objetos.
Palabras Clave-
Metodología, RUP, SCRUM,
Desarrollo de software,
Ingeniería de software.
INTRODUCCIÓN
La ingeniería de software es
una disciplina de la informática
que aporta métodos y técnicas
para desarrollar y diseñar
software de calidad que estén al
frente en la solución de
problemas que se presenten.
Actualmente las compañías
dependen de gran manera del
software, donde se almacena
toda la información en bases de
datos, aplicaciones móviles, y
haciendo uso en su gran
mayoría de aparatos
electrónicos.
Entre los objetivos de la
ingeniería de software están:
● Mejorar el diseño de
aplicaciones o software de
tal modo que se adapten
de mejor manera a las
necesidades de las
organizaciones o
finalidades para las cuales
fueron creadas.
● Promover mayor calidad al
desarrollar aplicaciones
complejas.
● Brindar mayor exactitud
en los costos de proyectos
y tiempo de desarrollo de
los mismos.
● Aumentar la eficiencia de
los sistemas al introducir
procesos que permitan
medir mediante normas
específicas, la calidad del
software desarrollado,
buscando siempre la mejor
calidad posible según las
çnecesidades y resultados
que se quieren generar.
● Una mejor organización de
equipos de trabajo, en el
área de desarrollo y
mantenimiento de
software.
● Detectar a través de
pruebas, posibles mejoras
para un mejor
funcionamiento del
software desarrollado.
Para dar cumplimiento a los
software y poder desarrollar de
manera eficiente aplicaciones
móviles y software, se hace
necesario implementar
metodologías de desarrollo ágil
que permitan llevar a cabo la
ejecución y producción de
software de manera flexible y
compatible, cumpliendo con las
necesidades y requisitos
necesarios para su realización.
Cada metodología existente
tiene un enfoque diferente para
la captura de requerimientos y
para su proceso de desarrollo,
algunas se basan primero en
analizar y documentar los
detalles del sistema, para así
realizar el diseño, desarrollo y
pruebas de éste.
Otros métodos proponen
centrarse en la organización del
equipo de trabajo, incluir al
cliente activamente y en arrojar
resultados satisfactorios más
rápidamente.
Independientemente de la
metodología es conveniente
saber que éstas se eligen e
implementan de acuerdo a la
naturaleza del proyecto,
direccionando todas las
metodologías para cumplir con
un mismo fin, llegando incluso
a combinarse entre sí para
lograr mejores resultados. [1]
En el desarrollo de este artículo
se encontrará una presentación
de la metodología Rational
Unified Process (RUP) de IBM
que a pesar de su rigurosidad y
alta documentación, es un
estándar altamente usado en el
desarrollo de software, también
se expondrá la disciplina
SCRUM basada en la rapidez y
flexibilidad de métodos de
desarrollos ágiles ampliamente
usados en la industria de
productos comerciales.
Luego se realizará una
comparación de ambas
metodologías (SCRUM- RUP),
teniendo en cuenta las ventajas
y desventajas de cada una de
ellas, dando así a conocer la
propuesta híbrida, tomando
como referencia la construcción
de proyectos con las mejores
prácticas de las dos
metodologías contrastadas.
Finalmente se darán unas
conclusiones analizando el
proceso llevado a cabo durante
este trabajo.
CONTENIDO
METODOLOGÍAS
AGILES
Las metodologías ágiles surgen
como una alternativa a las
metodología tradicionales las
cuales, tal y como acabamos de
ver en los apartados anteriores
son demasiado burocráticas y
por tanto rígidas para las
actuales características del
mercado.
Años atrás la evolución de los
productos era lenta y se
producía siempre en un entorno
estable el que apenas había
variaciones.
Hoy en día sin embargo el
entorno en el que se mueve el
software es demasiado inestable
y cambiante por lo que estas
metodologías no se adaptan, ya
que hay que reducir el tiempo
de creación pero sin dejar de
todo la calidad del software.
Las metodologías
convencionales presentan para
este tipo de proyectos los
siguientes inconvenientes:
1. Es necesario conocer desde el
inicio qué desea el cliente.
2. No se deben de cambiar los
requisitos iniciales puesto que a
medida que se sigue
construyendo el proyecto las
modificaciones y la corrección
de los errores es más costosa.
Además todos los cambios que
se produzcan los sufrirá
económicamente el cliente.
Fig. 1. Modelo costo del
cambio vs tiempo.
Fuente:
https://mail.google.com/mail
/u/0/?
ui=2&view=btop&ver=17cyo
9bg6h587&q=scrum&qs=tru
e&search=query&th=14cc35
ee6f95bdd1&qt=scrum.1.scr
ums.1&cvid=2
3. Se establecen mecanismos
de control para el proyecto
que a veces dan sensación de
inflexibilidad a posibles
cambios y que de hacerlo
incrementaría el coste.
4. Excesiva documentación
que a veces incluso no es
útil.
5. Quizás este sería el punto
más importante, “la lentitud”
del desarrollo. Hoy en día
para ser competitivos es
necesario la agilidad y
flexibilidad a la hora de la
creación de los productos.
6. Las metodologías
tradicionales se encuentran
con las dificultades al final
del proyecto, lo que termina
retrasando las entregas.

Fig. 2. Modelo impacto del
riesgo vs tiempo.
Fuente:
https://mail.google.com/mail
/u/0/?
ui=2&view=btop&ver=17cyo
9bg6h587&q=scrum&qs=tru
e&search=query&th=14cc35
ee6f95bdd1&qt=scrum.1.scr
ums.1&cvid=2
Todos estos inconvenientes
han hecho que las
metodologías clásicas no
hayan sido capaces de
eliminar los fallos y que
haya una explosión de
creación de software
orientado a la Web, en la que
se requieren cambios
constantes, y que los tiempos
de desarrollo sean más
cortos hacen que aparezca el
concepto de “metodología
ágil” como una alternativa
atractiva.
El desarrollo ágil está
centrado en la iteración,
comunicación y en reducir
elementos intermedios.
El desarrollo con
interacciones se realiza
normalmente en porciones
de tiempo pequeñas
denominadas “timeboxes” y
se ocupará de desarrollarlas
un equipo multidisciplinar
auto organizado, ellos
mismo decidirán como
realizar las tareas de la
iteración.
Además el método de
desarrollo ágil fomenta la
comunicación entre los
miembros del equipo lo que
previene problema que en
otra metodología quedan
escondidos.
Esta comunicación no solo
se establece de forma cerrada
entre los miembros del
equipo sino que también se
realiza con la figura que
representa al cliente.
El representante del cliente
es necesario como elemento
de apoyo para los
desarrolladores puesto que
será la persona a la que se
podrán hacer las preguntas
necesarias y que junto con el
resto de personas
involucradas en el negocio
comprobarán si se cumplen
los objetivos.
Por lo tanto trabajar con una
buena comunicación permite
que se puedan tomar las
decisiones de forma más
rápida y aplicarlas.
La característica realmente
nueva que aportan estas
metodologías es reconocer a
las personas como el
principal valor para que un
proyecto consiga terminarse
de forma correcta. “El factor
más importante en el
desarrollo de software no son
las técnicas y las
herramientas que emplean
los programadores, sino la
calidad de los
programadores.” (Robert. L.
Class).
Podemos deducir que las
metodologías ágiles a resulta de una combinación de
diferencia de las
metodologías tradicionales o
clásicas son más adecuadas
cuando el entorno presenta
una cierta incertidumbre o es
cambiante. [2]
En este contexto se podrían
definir las siguientes
ventajas:
1. Gran capacidad de
respuesta ante los cambios,
los cuales no se entienden
como un problema sino
como algo necesario para
que el producto sea mejor y
satisfaga al cliente.
Los cambios formarán parte
del proceso de desarrollo.
2. Las entregas no se hacen
al final sino que se hacen
pequeñas entregas. Estas
entregas permiten al cliente
valorar el producto además
de ir trabajando con algunas
funcionalidades.
3. Los ciclos cortos de
entrega ayudarán a como por ejemplo, los modelo
disminuir los riesgos sobre
todo al principio del
proyecto.
4. Se trabaja en equipo entre
el cliente y los
desarrolladores mediante
una comunicación casi diaria
para evitar errores y
documentación innecesaria.
5. Eliminar el trabajo que no
es necesario y que realmente
no aporta un valor al
negocio.
6. Buscar la mejor técnica y
el mejor diseño para
conseguir productos de
calidad.
7. Mejorar los procesos y al
equipo que realiza el
desarrollo.
METODOLOGÍA RUP
(RATIONAL UNIFIED
PROCES)
RUP fue desarrollado por
Rational Software y ahora
perteneciente a IBM. Se basa en
un marco de procesos de trabajo
que pueden ser adaptados por
las organizaciones que hagan el
desarrollo y por los
desarrolladores, seleccionando
los elementos más apropiados
del proceso.
El proceso Unificado Rational
varias metodologías y se vio
influenciado por otros métodos
como el espiral. Es una
metodología que está basada en
Objectory, metodología que fue
creada por Ivan Jacobson, y el
proceso fue desarrollado con la
mismas técnicas que el equipo
de creadores y desarrollo usaba
para el diseño del software. Se
usaría UML (Unified Modeling
Language).
RUP se basa en tres
módulos principales que
contestan a las preguntas de:
quién hace el proceso, qué
productos de trabajo se van a
realizar, qué documentos y
modelos se van a producir y
cómo se van a realizar las
tareas. [3]
Fig. 3. Metodología RUP.
Fuente:
http://rupmetodologia.blogsp
ot.com/
La metodología RUP se destaca
por:
● Forma disciplinada de
asignar tareas y
responsabilidades
(quién hace qué,
cuándo y cómo)
● Pretende implementar
las mejores prácticas
en Ingeniería de
Software.
● Desarrollo iterativo
● Administración de
requisito
● Uso de arquitectura
basada en
componentes
● Control de cambios
● Modelado visual del
software
● Verificación de la
calidad del software
En esta metodología lo que se
pretende es el desarrollo de un
software, en el cual se aplicará
el PSP (Personal Software
Process) Proceso de software
personal y el CMMI (Capability
Maturity Model for Integration)
Modelo de Madurez de la
Capacidad Integrado, en todas
y cada una de sus fases, que
están en la realización de los
procesos.
El RUP es un producto
desarrollado por Rational
(IBM), el cual se caracteriza por
tener un modelo iterativo e
incremental, al estar centrado
en la arquitectura y guiado por
los casos de uso. Incluye
artefactos (los cuales son los
productos tangibles del proceso
de casos de uso, el código
fuente, etc.) y los roles (papel
que desempeña cada persona en
un determinado momento, una
persona puede desempeñar
distintos roles a lo largo de todo
el proceso de la
implementación de la
metodología y por lo tanto del
desarrollo del software).
Fig. 4. Modelo iterativo e
incremental.
Fuente:
https://www.emaze.com/@A
IZQZZZZ
FASES DE LA
METODOLOGÍA RUP
Las fases que forman el ciclo de
vida de RUP se dividen en
cuatro:
1. Inicio: Se establece el
objetivo del sistema y se
recogen los requisitos del
usuario.
2. Elaboración: Se busca reducir
riesgos y cumplir con la
planificación y coste indicado.
Se genera una estructura
arquitectónica que se puede
ejecutar y que servirá de punto
de partida para después permitir
desarrollar la disciplina de
diseñar, implementar y probar.
3. Fase de construcción:
Partiendo de la arquitectura
elaborada en la fase anterior se
realizará casi toda la
implementación, creando
versiones totalmente
funcionales para comprobar que
satisface las necesidades del
usuario.
4. Transición: Se comprueba
que el software cumple con
todas las necesidades y se
realizan feedback con el cliente
para ajustar el software, dado
una de estas fases contiene
interacciones necesarias para
alcanzar los objetivos del
producto y cada fase tiene un
objetivo y un hito que indicará
que el objetivo se ha alcanzado.
Fig. 5. Fases de la
metodología RUP.
Fuente:https://procesosdesoft
ware.wikispaces.com/METO
DOLOGIA+RUP
Cada una de estas fases se
desarrollará mediante un ciclo
de interacciones, éstas consisten
en hacer un ciclo de vida en
cascada reducido, en la que el
flujo de trabajo irá variando
según la fase en la que se
encuentre. Estas interacciones
son llevadas a cabo bajo las
disciplinas de:
1) Disciplina de desarrollo
 Requerimientos: Se
trasladan las
necesidades del
negocio a un sistema
automatizado.
 Análisis y diseño: Los
requerimientos se
trasladan a una
arquitectura software.
 Implementación: Se
crea el software
adaptándolo a las
necesidades.
 Pruebas: Se
comprueba que el
software actúa de
forma adecuada.
2) Disciplina de soporte:
 Configuración y RUP se define por una serie de
administración de los
cambios.
 Administración de los
horarios y recursos.
 Ambiente de
desarrollo y su
administración.
Los roles que se definen en
RUP indican las tareas que
tiene que hacer cada uno de los
miembros del proyecto y el
objetivo que se debe de
conseguir.
Anthony Crain nos da una
visión de los roles según su
grado de detalle, donde en
primera instancia se tiene una
visión global de la solución y el
rol asociado, y en una nueva
iteración se obtiene el rol
específico:
Tab. 1. Roles de RUP
(Fuente: Blog de Anthony
Crain).
SCRUM
En el año 1986 Takeuchi y
Nonaka publicaron el artículo
“The New Product
Developroent Game” el cual
dará a conocer una nueva forma
de gestionar proyectos en la que
la agilidad, flexibilidad, y la
incertidumbre son los elementos
principales.
Nonaka y Takeuchi se fijaron en
empresas tecnológicas que,
estando en el mismo entorno en
el que se encontraban otras
empresas, realizaban productos
en menos tiempo, de buena
calidad y menos costes.
Observando a empresas como
Honda, HP, Canon...etc., se
dieron cuenta de que el
producto no seguía unas fases
en las que había un equipo
especializado en cada una de
ellas, si no que se partía de
unos requisitos muy generales y
el producto lo realizaba un
equipo multidisciplinar que
trabajaba desde el comienzo del
proyecto hasta el final.
Se comparó esta forma de
trabajo en equipo, con la
colaboración que hacen los
jugadores de Rugby y la
utilización de una formación
características denominadas
denominada SCRUM. [4]
prácticas y que vienen definidas
en “RUP, Best Software
practices development”.

Fig. 6. Funcionamiento de
metodología de trabajo
Scrum.
Fuente:
Fuente:
https://platzi.com/blog/meto
dologia-scrum-fases/
Scrum aparece como una
práctica destinada a los
productos tecnológicos y será en
1993 cuando realmente Jeff
Sutherland aplique un modelo
de desarrollo de Software en
Ease/Corporation.
En 1996, Jeff Sutherland y Ken
Schwaber presentaron las
prácticas que se usaban como
proceso formal para el
desarrollo de software y que
pasarían a incluirse en la lista
de Agile Alliance.
Scrum es adecuado para
aquellas empresas en las que el
desarrollo de los productos se
realiza en entornos que se
caracterizan por tener:
1. Incertidumbre: Sobre esta
variable se plantea el objetivo
que se quiere alcanzar sin
proporcionar un plan detallado
del producto.
Esto genera un reto y da una
autonomía que sirve para
generar una “tensión” adecuada
para la motivación de los
equipos.
2. Auto-organización: Los
equipos son capaces de
organizarse por sí solos, no
necesitan roles para la gestión
pero tienen que reunir las
siguientes características:
 Autonomía: Son los
encargados de
encontrar la solución
usando la estrategia
que encuentren
adecuada.
 Auto-superación: Las
soluciones iniciales
sufrirán mejoras.
 Auto-enriquecimiento:
Al ser equipos
multidisciplinares se
ven enriquecidos de
forma mutua,
aportando soluciones
que puedan
complementarse.
3. Control moderado: Se
establecerá un control suficiente
para evitar descontroles. Se
basa en crear un escenario de
“autocontrol entre iguales” para
no impedir la creatividad y
espontaneidad de los miembros
del equipo.
4. Transmisión del
conocimiento: Todo el mundo
aprende de todo el mundo. Las
personas pasan de unos
proyectos a otros y así
comparten sus conocimientos a
lo largo de la organización.
Scrum al ser una metodología
de desarrollo ágil tiene como
base la idea de creación de
ciclos breves para el desarrollo,
que comúnmente se llaman
iteraciones y que en Scrum se
llamarán
“Sprints”.
Para entender el ciclo de
desarrollo de Scrum es
necesario conocer las 5 fases
que definen el ciclo de
desarrollo ágil:
1. Concepto: Se define de forma
general las características del
producto y se asigna el equipo
que se encargará de su
desarrollo.
2. Especulación: en esta fase se
hacen disposiciones con la
información obtenida y se
establecen los límites que
marcarán el desarrollo del
producto, tales como costes y
agendas.
Se construirá el producto a
partir de las ideas principales y
se comprueban las partes
realizadas y su impacto en el
entorno.
Esta fase se repite en cada
iteración y consiste, en rasgos
generales, en:
 Desarrollar y revisar
los requisitos
generales.
 Mantener la lista de
las funcionalidades
que se esperan.
 Plan de entrega. Se
establecen las fechas
de las versiones, hitos
e iteraciones.
 Medirá el esfuerzo
realizado en el
proyecto.
3. Exploración: Se incrementa
el producto en el que se añaden
las funcionalidades de la fase de
especulación.
4. Revisión: El equipo revisa
todo lo que se ha construido y
se contrasta con el objetivo
deseado.
5. Cierre: Se entregará en la
fecha acordada una versión del
producto deseado. Al tratarse de
una versión, el cierre no indica
que se ha finalizado el proyecto,
sino que seguirá habiendo
cambios, denominados
“mantenimiento”, que hará que
el producto final se acerque al
producto final deseado.
Fig. 7. Ciclo de desarrollo
ágil.
Fuente:
https://mail.google.com/mail
/u/0/?
ui=2&view=btop&ver=17cyo
9bg6h587&q=scrum&qs=tru
e&search=query&th=14cc35
ee6f95bdd1&qt=scrum.1.scr
ums.1&cvid=2
Scrum gestiona estas iteraciones
a través de reuniones diarias,
uno de los elementos
fundamentales de esta
metodología.
Fig. 8. Ciclo principal de
SCRUM.
Fuente:
https://mail.google.com/mail
/u/0/?
ui=2&view=btop&ver=17cyo
9bg6h587&q=scrum&qs=tru
e&search=query&th=14cc35
ee6f95bdd1&qt=scrum.1.scr
ums.1&cvid=2
COMPONENTES DE
SCRUM
Para entender todo el proceso
de desarrollo del Scrum, se
describirá de forma general las
fases y los roles. Estas fases y
roles se detallarán de forma más
concisa más adelante.
Scrum se puede dividir de
forma general en 3 fases, que
podemos entender como
reuniones. Las reuniones
forman parte de los artefactos
de esta metodología junto con
los roles y los elementos que lo
forman.
REUNIONES
1. Planificación del Backlog
Se definirá un documento en el
que se reflejarán los requisitos
del sistema por prioridades.
En esta fase se definirá también
la planificación del Sprint 0, en
la que se decidirá cuáles van a
ser los objetivos y el trabajo que
hay que realizar para esa
iteración.
Se obtendrá además en esta
reunión un Sprint Backlog, que
es la lista de tareas y que es el
objetivo más importante del
Sprint.
2. Seguimiento del Sprint
En esta fase se hacen reuniones
diarias en las que las 3
preguntas principales para
evaluar el avance de las tareas retroalimentación dé la salida
serán: del proceso y así poder revisar y
 ¿Qué trabajo se planear cada sprint.
realizó desde la
reunión anterior?
 ¿Qué trabajo se hará
hasta una nueva
reunión?
 Inconvenientes que
han surgido y qué hay
que solucionar para
poder continuar.
3. Revisión del Sprint
Cuando se finaliza el Sprint se
realizará una revisión del
incremento que se ha generado.
Se presentarán los resultados
finales y una demo o versión,
esto ayudará a mejorar el
feedback con el cliente.
ROLES
1. LOS CERDOS
Son las personas que están
comprometidas con el proyecto
y el proceso de Scrum.
 Product Owner: Es la
persona que toma las
decisiones, y es la que
realmente conoce el https://jeronimopalacios.com
negocio del cliente y
su visión del
producto. Se encarga
ELEMENTOS DE SCRUM
de escribir las ideas
del cliente, las ordena Los elementos que forman a
por prioridad y las Scrum son:
coloca en el Product
Backlog.
 ScrumMaster: Es el
encargado de
comprobar que el
modelo y la
metodología funciona.
Eliminará todos los
inconvenientes que
hagan que el proceso
no fluya e interactuará
con el cliente y con
los gestores.
 Equipo De Desarrollo:
suele ser un equipo
pequeño de unas 5-9
personas y tienen
autoridad para
organizar y tomar
decisiones para
conseguir su objetivo.
Está involucrado en la
estimación del
esfuerzo de las tareas
del Backlog.
2. LAS GALLINAS
Aunque no son parte del Fig. 10. Ciclo de desarrollo
proceso de Scrum, es necesario
que parte de la
Fuente: ser modificado, y en caso de
https://jeronimopalacios.com ser necesario introducir
/scrum/ cambios estos se harán una
 Usuarios: Es el vez concluido el periodo a
destinatario final del Definición del proyecto través de la definición de
producto. (Product Backlog): Consiste otro sprint backlog.
 Stakeholders: Las en un documento que recoge
personas a las que el el conjunto de Entrega: Una vez concluida
proyecto les producirá
un beneficio.
requerimientos que se la ejecución del sprint, se
Participan durante las asocian al proyecto. Es dispondrá de una porción de
revisiones del Sprint. responsabilidad del Product la aplicación potencialmente
 Managers: Toma las Owner realizar esta definitiva.
decisiones finales definición y establecer las
participando en la prioridades de cada Evolución del proyecto
selección de los requerimiento. Es un (Burn down): Es un
objetivos yde los documento de alto nivel, que documento que refleja el
requisitos. contiene descripciones estado del proyecto,
genéricas (no detalladas), y indicando el volumen de
que está sujeto a
requerimientos que en ese
modificaciones a lo largo del momento se encuentran
desarrollo. pendientes de ser abordados
(en el product backlog), los
Definición del Sprint requerimientos que en ese
(Sprint Backlog): Un sprint momento se están
debe entenderse como un desarrollando (sprint
subconjunto de backlog) y los
requerimientos, extraídas del requerimientos cuyo
product backlog, para ser desarrollo ya se ha
Fig. 9. Conformación ejecutadas durante un completado en su totalidad.
equipo Scrum. periodo entre 1 y 4 semanas
Fuente: de trabajo. El sprint backlog Para analizar la evolución
sería el documento que del desarrollo del trabajo, la
/scrum/ describa las tareas que son metodología implementa
necesario realizar para unas reuniones o eventos de
abordar los dicho trabajo enfocadas en un
subconjunto de contexto SCRUM.
requerimientos. Está es la
característica principal que  Planificación de
 Product Backlog: lista
marca la diferencia entre sprint: Se realiza al
de necesidades del
Scrum y otros modelos para
cliente. principio de cada
el desarrollo ágil. Es una
 Sprint Backlog: lista ciclo de sprint, y
simple iteración llevada a
de tareas que se está encaminada a
realizan en un Sprint. cabo por los miembros del seleccionar el
 Incremento: parte equipo. Un equipo puede conjunto de
añadida o desarrollada completar varios sprints requerimientos del
en un Sprint, es un durante el desarrollo del
product backlog que
parte terminada y proyecto. Un Sprint inicia
serán abordado, el
totalmente operativa. con un equipo que se
equipo de trabajo
compromete a realizar el que será necesario y
trabajo y finaliza con la el tiempo que se
demostración de un estima (entre 1 y 4
entregable. [5] semanas) para su
desarrollo.
Ejecución del Sprint: Sería  Reunión diaria:
el periodo de entre 1 y 4 Conocida como
semanas (periodo definido daily scrum, se
previamente en base a las realiza al comienzo
tareas recogidas en el sprint de cada día en que
backlog) durante el cual el se esté ejecutando
equipo de trabajo abordaría un sprint. Es una
las tareas de desarrollo reunión corta, por
correspondientes. Una vez lo general de 15
iniciada la ejecución de un
Scrum. minutos o más (no
sprint definido, este no podrá más de 30 minutos)
 en la que los gran escala que requieren de En la metodología SCRUM
integrantes del interacciones complejas con se realizan reuniones diarias
equipo responden otros sistemas, debido a que las cuales son llamadas
las siguientes estos sistemas requieren de "Daily Scrum" y es donde se
preguntas: un nivel de precisión sostiene una pequeña charla
● ¿Qué has bastante alto y tienen un sobre el estado del proyecto.
hecho desde gran riesgo de construcción. En particular muestran los
la última No sería conveniente impedimentos para progresar
reunión? implementar una que se atraviesan y que la
● ¿Qué metodología ágil para el gerencia debe resolver. [1]
problemas desarrollo de un sistema
has crítico en el cual es necesario
encontrado el análisis detallado de todos
para realizar los requerimientos para
el trabajo comprender su complejidad
previsto? Fig. 11. Eventos de la e implicaciones, debido a la
metodología Scrum. complejidad y la extrema
● ¿Qué planeas precisión que pueda tener la
hacer antes Fuente:
https://www.slideshare.net/li captura de requerimientos,
de la próxima en los cuáles las
reunión?. zandroluzon/scrum-
70358857 metodologías ágiles como
SCRUM ofrecen demasiada
 Revisión de sprint: flexibilidad.
Una vez concluido La metodología Scrum
Con respecto a la
el ciclo de sprint se inicialmente fue desarrollada
planificación, RUP tiene un
mantiene una para la gestión y desarrollo
plan de proyecto formal,
reunión en la que se de software; pero Fig. 12. Metodología Scrum
asociada a múltiples
define qué parte del actualmente también aplica vs metodología Scrum.
iteraciones, el plan es
trabajo previsto se para las siguientes Fuente:
impulsado y definido por
ha completado y actividades: http://www.unbugalavez.net/
una fecha final y también
qué parte 2008/08/scrum-y-rup.html
cuenta con hitos
permanece  Investigar e intermedios; por otro lado,
pendiente. En identificar en scrum no se define
cuanto al trabajo mercados viables, completamente el proyecto CONCLUSIONES
completado se tecnologías y antes de iniciarlo, sino que
realiza una revisión capacidades de Como conclusión general
cada plan de la siguiente podemos decir que cada
(demo) del mismo productos iteración se determina al
al product owner y  Desarrollar metodología es diferente,
final de la iteración actual, posee sus principios, su
otros usuarios que productos y mejoras además el cliente es quien
pudiesen estar modelo de ciclo de vida y
 Liberar productos y determina el momento en
involucrados. por ende sus ventajas y/o
mejoras tantas veces que el proyecto se lleva a desventajas. Por eso, es
como sea posible cabo.
Retrospectiva de sprint: Es importante tener en cuenta
durante el día
una reunión en la que todos Otro punto de comparación qué aspectos se van a
 Desarrollar y necesitar de una metodología
los miembros del equipo entre las dos metodologías
mantener ambientes y de esta forma aplicarla a
realizan una valoración del de software es que el tipo de
en la Nube (en un proyecto tomando los
trabajo realizado en el documentación de RUP hace
línea, seguros, bajo componentes que sean
último sprint, identificando referencia a las
demanda) y otros necesarios para el mismo
puntos de mejora de cara a comunicaciones formales
entornos adaptándolas y aplicándolas.
los siguientes a realizar. El con la finalidad de ser más
operacionales para
objetivo principal es predictivos, mientras que en Por otra parte, es importante
el uso de productos
introducir un componente de SCRUM se enfoca en las
 Mantener y renovar resaltar que dos
mejora continua en el comunicaciones informales metodologías distintas y con
productos. continuas y a la adaptación
proceso. [6] distintos principios pueden
al cambio, con la finalidad convivir, como es el caso del
COMPARATIVA
de ser más adaptivas.
METODOLOGIAS proyecto que presentamos,
Otra diferencia está donde fusionamos las
Ambas metodologías tanto relacionada con las características más
SCRUM como RUP, tienen iteraciones de desarrollo, convenientes de cada una
sus limitaciones y mientras que en RUP tienden para sacar el mayor
debilidades, así pues las a ser pocas y largas que provecho de las mismas y
metodologías ágiles son las finalizan con la entrega de optimizar un nuevo proceso
más adecuadas para un artefacto, en SCRUM de desarrollo de software
proyectos pequeños y tienden a ser muchas pero combinado.
medianos, no son las más frecuentes, llamadas sprints.
adecuadas para sistemas de
 I. Referencias

[1] J. S. Villanueva, «Scrum y RUP: Comparativa y propuesta

Metodologica,» ISSN, pp. 39-48, 2014.
[2] M. T. Gallego, «Gestio de proyectos informaticos,»
p. 18, 2015.
[3] F. Lopez, «Metodologías ágiles para gestión de
proyectos,» 11 12 2014. [En línea]. Available:
http://www.conasa.es/blog/metodologias-agiles-para-
gestion-de-proyectos/.
[4] P. agiles, «Scrum,» [En línea]. Available:
https://proyectosagiles.org/que-es-scrum/.
[5] W. Lara, «Platzi,» Platzi, 2015. [En línea]. Available:
https://platzi.com/blog/metodologia-scrum-fases/.
[6] Nateevo, «Nateevo,» 20 09 2012. [En línea]. Available:
http://www.nateevo.com/scrum-la-metodologia-de-
desarrollo-agil-por-excelencia/.
[7] J. S. Villanueva, «Scrum y Rup: Comparativa y propuesta
Metodologica,» ISSN, pp. 39-48, 2014.