¿Qué es el modelo en cascada?

El desarrollo en cascada (en inglés, waterfall model) es un procedimiento lineal que se

caracteriza por dividir los procesos de desarrollo en sucesivas fases de proyecto. Al contrario
que en los modelos iterativos, cada una de estas fases se ejecuta tan solo una vez. Los
resultados de cada una de las fases sirven como hipótesis de partida para la siguiente. El
waterfall model se utiliza, especialmente, en el desarrollo de software.

¿Cómo funciona el modelo en cascada?

El desarrollo del modelo se atribuye al teórico de la informática Winston W. Royce. Sin
embargo, Royce no es el inventor de este modelo. Muy al contrario, en su ensayo de 1970
titulado Managing the Development of Large Software Systems, el teórico presenta
una reflexión crítica acerca de los procedimientos lineales. A modo de alternativa, Royce
presenta un modelo iterativo incremental en el que cada una de las fases se basa en la
anterior y verifica los resultados de esta.

Royce propone un modelo compuesto por siete fases que se ha de ejecutar en diversas
vueltas (iteraciones):

1. Requisitos de sistema
2. Requisitos de software
3. Análisis
4. Diseño
5. Implementación
6. Prueba
7. Servicio

El procedimiento popularmente conocido como waterfall model se basa en las fases definidas
por Royce, pero solo prevé una iteración.

En el ensayo publicado por Royce, el término no aparece en ningún momento.

Hecho
El modelo en cascada se popularizó a través de la norma estadounidense DoD-STD-2167.
Esta norma se basa en una versión extremadamente simplificada del procedimiento
desarrollado por Royce, que no fue lo suficientemente analizado por los autores. Tal y como
reconoció con el paso del tiempo David Maibor, uno de sus autores, el motivo fue la falta de
compresión de los modelos iterativos incrementales.
En la práctica, se aplican diversas versiones del modelo. Los más habituales son los
modelos que dividen los procesos de desarrollo en cinco fases. En ocasiones, las fases 1, 2 y
3 definidas por Royce se integran en una sola fase de proyecto a modo de análisis de los
requisitos.

1. Análisis: planificación, análisis y especificación de los requisitos.

2. Diseño: diseño y especificación del sistema.
3. Implementación: programación y pruebas unitarias.
4. Verificación: integración de sistemas, pruebas de sistema y de integración.
5. Mantenimiento: entrega, mantenimiento y mejora.
La siguiente imagen explica por qué el procedimiento lineal se denomina metodología en
cascada.

El modelo en cascada de cinco niveles, basado en las propuestas de Winston W. Royce,

divide los procesos de desarrollo en las siguientes fases de proyecto: análisis, diseño,
implementación, verificación y mantenimiento. El gráfico incluye una de las ampliaciones del
modelo planteadas por Royce: la verificación de los resultados de cada una de las fases
tomando en consideración las exigencias y especificaciones formuladas en el paso anterior.
En las ampliaciones de la metodología en cascada se añaden funciones iterativas al modelo
básico como, por ejemplo, los saltos hacia atrás, que permiten comparar los resultados de
cada una de las fases con las hipótesis obtenidas en la fase anterior, de modo que se puedan
verificar.

Las fases del desarrollo en cascada

En este modelo, las diferentes fases de un proceso de desarrollo se suceden una detrás de
otra como en una cascada. Cada una de las fases concluye con un resultado provisional
(hito) como, por ejemplo, un catálogo de requisitos en forma de pliego de condiciones, la
especificación de una arquitectura de software o una aplicación a nivel alfa o beta.
Análisis
Todo proyecto de software comienza con una fase de análisis que incluye un estudio de
viabilidad y una definición de los requisitos. En el estudio de viabilidad se evalúan los costes,
la rentabilidad y la factibilidad del proyecto de software. El estudio de viabilidad da como
resultado un pliego de condiciones (una descripción general de los requisitos), un plan y una
estimación financiera del proyecto, así como una propuesta para el cliente, si fuera necesario.

A continuación, se realiza una definición detallada de los requisitos, incluyendo un análisis

de la situación de salida y un concepto. Mientras que los análisis de salida se encargan de
describir la problemática en sí, el concepto ha de definir qué funciones y características debe
ofrecer el producto de software para cumplir con las correspondientes exigencias. La
definición de los requisitos da como resultado un pliego de condiciones, una descripción
detallada de cómo se han de cumplir los requisitos del proyecto, así como un plan para la
prueba de aceptación, entre otros.

Por último, la primera fase del waterfall model incluye un análisis de la definición de los
requisitos en el que los problemas complejos se dividen en pequeñas tareas secundarias y
se elaboran las correspondientes estrategias de resolución.

Diseño
La fase de diseño sirve para formular una solución específica en base a las exigencias, tareas
y estrategias definidas en la fase anterior. En esta fase, los desarrolladores de software se
encargan de diseñar la arquitectura de software, así como un plan de diseño detallado del
mismo, centrándose en componentes concretos, como interfaces, entornos de trabajo o
bibliotecas. La fase de diseño da como resultado un borrador preliminar con el plan de diseño
del software, así como planes de prueba para los diferentes componentes.

Implementación
La arquitectura de software concebida en la fase de diseño se ejecuta en la fase de
implementación, en la que se incluye la programación del software, la búsqueda de
errores y las pruebas unitarias. En la fase de implementación, el proyecto de software se
traduce al correspondiente lenguaje de programación. Los diversos componentes se
desarrollan por separado, se comprueban a través de las pruebas unitarias y se integran
poco a poco en el producto final. La fase de implementación da como resultado un producto
de software que se comprueba por primera vez como producto final en la siguiente fase
(prueba alfa).

Prueba
La fase de prueba incluye la integración del software en el entorno seleccionado. Por norma
general, los productos de software se envían en primer lugar a los usuarios finales
seleccionados en versión beta (pruebas beta). Las pruebas de aceptación desarrolladas en
la fase de análisis permiten determinar si el software cumple con las exigencias definidas con
anterioridad. Aquellos productos de software que superan con éxito las pruebas beta están
listos para su lanzamiento.

Servicio
Una vez que la fase de prueba ha concluido con éxito, se autoriza la aplicación
productiva del software. La última fase del modelo en cascada incluye la entrega,
el mantenimiento y la mejora del software.

Pros y contras del modelo en cascada

Esta metodología permite estructurar la organización de forma clara en aquellos proyectos
de desarrollo en los que las diversas fases de proyecto se diferencian claramente entre sí.
Como cada una de las fases concluye con un hito, el proceso de desarrollo es muy fácil de
comprender. El punto clave del modelo reside en la documentación de todos y cada uno de los
pasos de proceso. Los conocimientos adquiridos se registran en pliegos de requisitos o
borradores preliminares.

En teoría, el desarrollo en cascada pretende crear los requisitos previos para una ejecución
rápida y rentable de los proyectos a través de una cuidada planificación previa. Sin
embargo, la utilización del modelo en la práctica es controvertida. Por una parte, en el
desarrollo de software las fases de proyecto no suelen estar claramente diferenciadas entre sí.
Es precisamente en los proyectos de software más complejos donde los desarrolladores se
suelen enfrentar al hecho de que los diversos componentes de una misma aplicación se
encuentran en diferentes fases de desarrollo al mismo tiempo. Por otra parte, la secuencia
lineal del waterfall model no suele coincidir con la realidad.

En sentido estricto, el modelo en cascada no prevé la realización de ajustes a lo largo del

proyecto. Sin embargo, un proyecto de software en el que todos los detalles del desarrollo se
definieran al comienzo, solo podría concluir con éxito si desde el principio se invirtiera una
gran cantidad de tiempo y dinero en análisis y diseño. A todo esto, se añade que los proyectos
de software de más envergadura se suelen prolongar durante varios años y, de no adaptarse
a los avances más actuales, obtendrían resultados que ya estarían obsoletos en el
momento de su aplicación.

Resumen de las ventajas y desventajas del modelo en cascada

Ventajas Inconvenientes

✔ Una estructura sencilla gracias a unas fases ✘ Por norma general, los proyectos más
de proyecto claramente diferenciadas. complejos o de varios niveles no permiten su
división en fases de proyecto claramente
diferenciadas.

✔ Buena documentación del proceso de ✘ Poco margen para realizar ajustes a lo largo
desarrollo a través de unos hitos bien definidos. del proyecto debido a un cambio en las
exigencias.

✔ Los costes y la carga de trabajo se pueden ✘El usuario final no se integra en el proceso de
estimar al comenzar el proyecto. producción hasta que no termina la
programación.

✔ Aquellos proyectos que se estructuran en ✘En ocasiones, los fallos solo se detectan una
base al modelo en cascada se pueden vez finalizado el proceso de desarrollo.
representar cronológicamente de forma
sencilla.

La metodología en cascada se suele emplear, especialmente, en aquellos proyectos cuyos

requisitos y procesos se pueden describir de forma precisa durante la fase de planificación, en
los que cabe suponer que las hipótesis no van a sufrir una gran variación durante el transcurso
del proyecto. Los procedimientos estrictamente lineales se adaptan, así, especialmente bien
a proyectos de software pequeños, sencillos y claramente estructurados. A esta misma
conclusión llegó Royce en los años 1970. Por este motivo, la alternativa al procedimiento lineal
que propuso, y que más tarde se conocería como waterfall model, incluía tres ampliaciones
principales:

Verificación tras cada fase de proyecto

Según Royce, los resultados de cada una de las fases de proyecto se deben comparar y
verificar inmediatamente con los documentos elaborados previamente. Es decir,
inmediatamente después de desarrollar un módulo, por ejemplo, se debería garantizar que
este cumple con las exigencias definidas con anterioridad sin esperar a que concluya el
proceso de desarrollo.

Al menos, dos iteraciones

Según Royce, el modelo se debería ejecutar en, al menos, dos ocasiones: primero
para elaborar un prototipo y, a continuación, para desarrollar el producto de software en
sí.

Pruebas que incluyen al usuario final

La tercera ampliación del modelo en cascada propuesta por Royce en su ensayo es una
medida que, a día de hoy, se ha convertido en un procedimiento estándar en el desarrollo de
productos: la inclusión del usuario final en el proceso de producción. Royce propone incluir al
usuario en tres momentos diferentes del proceso de desarrollo de software: durante la
planificación del software en la fase de análisis, entre el diseño del software y su
implementación y en la fase de prueba que precede al lanzamiento del software.

Procedimientos alternativos al modelo en cascada

Debido a la secuencia estrictamente lineal de las fases sucesivas de proyecto, el modelo en
cascada se adaptaría, en el mejor de los casos, a proyectos de software de poca envergadura.
Por el contrario, los procesos complejos de varios niveles serían difícilmente representables
con este modelo. Por este motivo, con el paso del tiempo han ido surgiendo enfoques
alternativos.

Mientras que algunos modelos, como el modelo en espiral o el modelo en V, se consideran

una evolución del waterfall model clásico, algunos métodos, como la programación
extrema, el desarrollo ágil de software o el desarrollo iterativo, se centran en un enfoque
completamente diferente y suelen permitir una adaptación a los cambios más recientes o a las
exigencias más actuales.

Metodología RAD o DRA. El Desarrollo

Rápido de Aplicaciones.
Mónica Castro | 25 de diciembre de 2019
La metodología RAD o DRA (por sus siglas en inglés Rapid Application Development y en
castellano Desarrollo Rápido de Aplicaciones), se trata de un modelo de desarrollo de
aplicaciones ágil. Es decir, hablamos del proceso de desarrollo de software.
Este método abarca el desarrollo interactivo, la creación de prototipos y el empleo de
utilidades CASE (Computer Aided Software Engineering). Además, la metodología RAD
suele englobar también la usabilidad, utilidad y la rapidez de ejecución.

Definición de qué es una metodología RAD

Profundizando en qué es una metodología RAD, tenemos que tener claros cuales son sus
premisas básicas. La primera persona que habló del método RAD fue James Martin a
finales de los 80 y, actualmente, estamos ante uno de los métodos de desarrollo más
populares, dentro de las técnicas de desarrollo ágil. James Martin consideró que para
aplicar de forma correcta la metodología RAD tenemos que tener en cuenta 4 componentes:
Personas, herramientas, metodología y gestión.

La idea principal es entregar sistemas de alta calidad, en poco tiempo y con un coste bajo
de inversión. Para conseguir esto, hay que seguir determinadas pautas que harán que
estemos ante una auténtica metodología DRA (las siglas en castellano: Desarrollo Rápido
de Aplicaciones), que veremos más adelante.

Para qué sirve la metodología RAD

En la actualidad, las empresas invierten gran parte de sus recursos en desarrollar
aplicaciones que les permitan trabajar de forma más eficiente. Con la aparición de los
modelos de desarrollo rápido de aplicaciones, podremos crear softwares de forma rápida y
barata para satisfacer las necesidades empresariales sin invertir tanto tiempo y dinero.

Ventajas y desventajas del modelo de desarrollo

rápido de aplicaciones RAD
A la hora de adoptar la metodología DRA, deberemos tener en cuenta un buen puñado de
ventajas y desventajas de su uso y saber por qué usar RAD. Algunos de los beneficios
principales del uso de la metodología RAD serían los siguientes:

• Avances medibles: Al contar con numerosas iteraciones, componentes y prototipos

desplegados cada cierto tiempo, se podrá medir y evaluar de forma sencilla el
desarrollo del proyecto y, así, cumplir con los presupuestos.
• Productivos más pronto: La metodología DRA permitirá a los desarrolladores
adoptar roles multidisciplinares que creen prototipos y códigos de trabajo de forma
rápida, lo que supone ser productivos más rápido.
 • Separación de los componentes del sistema: La metodología RAD exige a los
diseñadores y desarrolladores a generar componentes funcionales e independientes
por sí mismos, y así poder usarlos en en una versión o prototipo iterativo. De esta
manera, cada elemento se reparte en compartimentos y se podrá modificar según
evolucionen las necesidades del software y/o usuario.
• Comentarios constantes de los usuarios: Al poder lanzar prototipos e iteraciones
ágilmente, obtendremos un feedback muy valioso por parte de los usuarios de forma
continuada.
• Integración temprana de sistemas: Los softwares desarrollados con la metodología
RAD podrán ser integrados casi desde el comienzo con otros sistemas. A diferencia
de los softwares desarrollados en cascada que deben esperar prácticamente al final
del desarrollo a ser integrados. Al poder realizar estas integraciones tempranas,
podremos identificar los posibles errores que existan en las mismas y buscar la
solución.
• Adaptabilidad: Gracias al desarrollo rápido de aplicaciones, el software es bastante
maleable, lo que nos beneficiará para poder realizar cualquier posible adaptación a
los prototipos o iteraciones.

Desventajas de RAD
Por supuesto, no todo podía ser perfecto y, como cualquier otro método de desarrollo de
software, el método RAD tiene algunas desventajas que también hay que tener en cuenta a
la hora de elegirlo para trabajar.

• Requiere sistemas modulares: Cuando aplicamos el método RAD, cada componente

del sistema debe ser iterable y constatable por sí mismo, para poder ser modificados
o intercambiados por cualquier miembro del equipo.
• Dificultad dentro de proyectos a gran escala: Cuando estemos ante un proyecto que
implique muchas personas y aplicaciones, la flexibilidad puede llegar a ser un
problema puesto que perderemos ligeramente el control sobre el diseño y el
desarrollo.
• Exige mucha interactividad del usuario: Conseguir feedback del usuario desde una
etapa temprana es muy útil pero, a la vez, puede ser una espada de doble filo ya que
tendremos que aceptar todo tipo de críticas constructivas y ser competente a la hora
de comunicarse con los usuarios.
• Necesidad de desarrolladores senior: Aplicar la metodología RAD no es tan fácil
como parece, por lo que en el equipo serán necesarios desarrolladores hábiles que
sean capaces de aplicar y adaptarse a cualquier necesidad o cambio.

Fases dentro de un proceso con metodología

RAD
Para implantar el modelo de desarrollo rápido de aplicaciones, hay que seguir una
metodología concreta que incluye las siguientes fases, las cuales son cíclicas:

➡️Planificación de necesidades:
En esta primera fase, lo que habrá que hacer será sentar las bases de las necesidades del
proyecto, tanto de necesidades de la aplicación como de alcance del proyecto y de esta
manera comenzar a trabajar en la creación de prototipos.

➡️Diseño y feedback con el usuario:

Los usuarios aportarán comentarios que serán determinantes a la hora de diseñar la
arquitectura del sistema. Con el feedback del usuario crearemos modelos y prototipos
iniciales. Y este paso se podrá repetir tantas veces como se considere necesario según
avance el proyecto.

➡️Construcción:
Ahora que tenemos el diseño básico, tendremos que realizar el grueso del proyecto:
Codificación, pruebas e integración reales de la aplicación. Al igual que en la fase anterior,
esta se podrá repetir tantas veces como necesitemos, según haya nuevos componentes o
modificaciones en el proyecto.

➡️Transición:
La última fase, también conocida como “cutover”, permitirá al equipo de desarrollo pasar
los componentes a un entorno de producción en vivo, para realizar todas las pruebas que
sean necesarias.

En la actualidad, existen herramientas que aplican el desarrollo RAD en su forma de

trabajar. Una de ellas es Mendix, si quieres saber qué es Mendix no dejes de visitar el post
del link.

Con todo esto, creemos que será mas fácil comprender por qué usar RAD es una buena
elección para tu forma de trabajar.

Metodología Scrum: qué es y

cómo funciona
Home > Sales Enablement > Metodología Scrum: qué es y cómo funciona
A la hora de poner en marcha un proyecto,
toda empresa debe asegurar que el equipo
implicado conoce sus tareas y plazos de
tiempo de entrega. Scrum es una metodología
de trabajo que nos ayuda a conseguirlo y que,
además, permite agilizar la entrega de valor al
cliente en iteraciones cortas de tiempo.
La metodología Scrum es un marco de trabajo o framework que
se utiliza dentro de equipos que manejan proyectos complejos. Es
decir, se trata de una metodología de trabajo ágil que tiene
como finalidad la entrega de valor en períodos cortos de tiempo y
para ello se basa en tres pilares: la transparencia, inspección y
adaptación. Esto permite al cliente, junto con su equipo comercial,
insertar el producto en el mercado pronto, rápido y empezar a
obtener ventas (Sales enablement ).

¿En qué se basa la metodología Scrum?

Al estar enmarcada dentro de las metodologías agile , Scrum se basa en
aspectos como:

• La flexibilidad en la adopción de cambios y nuevos requisitos

durante un proyecto complejo.

• El factor humano.

• La colaboración e interacción con el cliente.

• El desarrollo iterativo como forma de asegurar

buenos resultados.

Los pilares o características de la metodología Scrum más

importantes son 3:
1. Transparencia
Con el método Scrum todos los implicados tienen conocimiento de
qué ocurre en el proyecto y cómo ocurre. Esto hace que haya un
entendimiento “común” del proyecto, una visión global.

2. Inspección
Los miembros del equipo Scrum frecuentemente inspeccionan el
progreso para detectar posibles problemas. La inspección no es un
examen diario, sino una forma de saber que el trabajo fluye y
que el equipo funciona de manera auto-organizada.

3. Adaptación
Cuando hay algo que cambiar, el equipo se ajusta para
conseguir el objetivo del sprint. Esta es la clave para conseguir el
éxito en proyectos complejos, donde los requisitos son cambiantes o
poco definidos y en donde la adaptación, la innovación, la
complejidad y flexibilidad son fundamentales.

Roles en el equipo Scrum

Con la metodología Scrum, el equipo tiene como foco entregar
valor y ofrecer resultados de calidad que permitan cumplir los
objetivos de negocio del cliente.

Para ello, los equipos de Scrum son auto-organizados y

multifuncionales. Es decir, cada uno es responsable de unas
tareas determinadas y de terminarlas en los tiempos acordados. Esto
garantiza la entrega de valor del equipo completo, sin necesidad de
ayuda o la supervisión minuciosa de otros miembros de la
organización.

En Scrum existen 3 roles muy importantes : Product Owner,

Scrum Master y Equipo de desarrollo.
1. Product owner:
Es el responsable de maximizar el valor del trabajo del equipo de
desarrollo. La maximización del valor del trabajo viene de la mano de
una buena gestión del Product Backlog, el cual explicaremos más
adelante.

El Product owner es el único perfil que habla constantemente con

el cliente, lo que le obliga a tener muchos conocimientos sobre
negocio.

Para finalizar, un equipo Scrum debe tener solo un Product Owner

y este puede ser parte del equipo de desarrollo.

2. Scrum Master:
Es el responsable de que las técnicas Scrum sean comprendidas y
aplicadas en la organización. Es el manager de Scrum, un líder que
se encarga de eliminar impedimentos o inconvenientes que tenga el
equipo dentro de un sprint (que ya revisaremos en detalle más
adelante), aplicando las mejores técnicas para fortalecer el equipo de
marketing digital.

Dentro de la organización, el Scrum Master tiene la labor de ayudar

en la adopción de esta metodología en todos los equipos.

3. Equipo de desarrollo:
Son los encargados de realizar las tareas priorizadas por el
Product Owner. Es un equipo multifuncional y auto-organizado.
Son los únicos que estiman las tareas del product backlog, sin
dejarse influenciar por nadie.

Los equipos de desarrollo no tienen sub-equipos o especialistas.

La finalidad de esto es transmitir la responsabilidad compartida si no
se llegan a realizar todas las tareas de un sprint.

Los hitos de la Metodología de trabajo Scrum

La gráfica describe los hitos dentro del proceso Scrum. El
desarrollo iterativo se realiza en un sprint, que contiene los
siguientes eventos: sprint planning, daily meeting, sprint
review y sprint retrospective.

1. Sprint
El sprint es el corazón de Scrum, es el contenedor de los demás hitos
del proceso. Todo lo que ocurre en una iteración para entregar
valor está dentro de un sprint . La duración máxima es de un mes, el
tiempo se determina en base al nivel de comunicación que el cliente
quiere tener con el equipo. Los sprints largos pueden hacer que se
pierda feedback valioso del cliente y poner en peligro el proyecto.

2. Sprint planning
En esta reunión todo el equipo Scrum define qué tareas se van a
abordar y cuál será el objetivo del sprint . La primera reunión que se
hace en el sprint puede llegar a tener una duración de 8 horas
para sprints de un mes.

El equipo se hace las siguientes preguntas:

• ¿Qué se va a hacer en el sprint ? En base a ello, se eligen

tareas del Product backlog.

• ¿Cómo lo vamos a hacer? El equipo de desarrollo define las

tareas necesarias para completar cada ítem elegido del Product
Backlog.

La definición de qué se va a hacer implica que el equipo tenga un

objetivo y se encuentre comprometido con la entrega de valor
que se hará al cliente al final del sprint. A esto se le llama sprint
goal.
El resultado de esta reunión es el sprint goal y un sprint
backlog (que revisaremos más adelante).

3. Daily meeting
Es una reunión diaria dentro del sprint que tiene como máximo 15
minutos de duración. En ella debe participar, sí o sí, el equipo
de desarrollo y el Scrum Master. El Product Owner no tienen
necesidad de estar presente.

En esta reunión diaria el equipo de desarrollo hace las siguientes tres

preguntas:

• ¿Qué hice ayer?

• ¿Qué voy a hacer hoy?

• ¿Tengo algún impedimento que necesito que me solucionen?

Esta reunión es la más oportuna para poder inspeccionar el trabajo y

poder adaptarse en caso de que haya cambio de tareas dentro de
un sprint .

4. Sprint review
La review del valor que vamos a entregar al cliente se hace en esta
reunión, al final de cada sprint. Su duración es de 4 horas para
sprints de un mes, y es la única reunión de Scrum a la que puede
asistir el cliente. En ella el Product Owner presenta lo
desarrollado al cliente y el equipo de desarrollo muestra su
funcionamiento. El cliente valida los cambios realizados y además
brinda feedback sobre nuevas tareas que el Product Owner tendrá
que agregar al Product backlog.

5. Sprint retrospective
La retrospectiva es el último evento de Scrum, tiene una duración de
3 horas para Sprints de un mes, y es la reunión del equipo en la que
se hace una evaluación de cómo se ha implementado
la metodología Scrum en el último sprint .

Es una gran oportunidad para el equipo Scrum de inspeccionarse a

sí mismo, proponiendo mejoras para el siguiente sprint.

El resultado: una lista de mejoras que debe aplicar el siguiente día,

ya que al finalizar la retrospectiva, inmediatamente comienza un
nuevo sprint , que incluye el sprint planning, daily meeting, sprint
review y la ya mencionada sprint retrospective.
Herramientas para la metodología Scrum
Las herramientas que se utilizan en Scrum están definidas para
maximizar la transparencia dentro del equipo; es decir, que todos
tengan una misma visión de lo que está ocurriendo en el proyecto.

Las herramientas principales de Scrum son: product backlog y

sprint backlog.

1. Product backlog
Básicamente, el product backlog es el listado de tareas que
engloba todo un proyecto. Cualquier cosa que debamos hacer
debe estar en el product backlog y con un tiempo estimado por el
equipo de desarrollo.

La responsabilidad exclusiva de ordenar el product backlog es del

Product Owner, que se encuentra en constante comunicación con el
cliente para asegurarse de que las prioridades están bien
establecidas.

La ordenación también es 100% responsabilidad del Product

Owner, por lo que las tareas que están más arriba deben de
ser las de mayor prioridad.

El equipo de desarrollo elige tareas del product backlog en el sprint

planning para generar tanto el sprint backlog como el sprint goal.

2. Sprint backlog
Es el grupo de tareas del product backlog que el equipo de
desarrollo elige en el sprint planning junto con el plan para poder
desarrollarlas. Debe ser conocido por todo el equipo, para
asegurarse de que el foco debe estar en este grupo de tareas.

El sprint planning no cambia durante el sprint, solo se permite

cambiar el plan para poder desarrollarlas.

Ventajas y desventajas de la metodología

Scrum
Una vez sabemos cómo funciona esta metodología, hablemos de sus
ventajas y desventajas:

Ventajas de la metodología Scrum

• Scrum es muy fácil de aprender: los roles, hitos y
herramientas son claros y tienen un objetivo por lo que es un
método muy relacionado con nuestra manera diaria de trabajar.

• El cliente puede comenzar a usar el producto rápidamente.

 • Se agiliza el proceso, ya que la entrega de valor es muy
frecuente.

• Menor probabilidad de sorpresas o imprevistos, porque el cliente

está viendo frecuentemente el proyecto.

Desventajas de la metodología Scrum

• Aunque Scrum sea fácil de aprender, es muy difícil
implementarlo. Esto supone una predisposición y un cambio
de cultura de la organización que debe ir desde los altos
mandos hasta los clientes.

• La necesidad de tener equipos multidisciplinares puede ser

un problema, ya que es difícil encontrar personas que sean
capaces de hacer todo el trabajo de un equipo.

• El equipo puede tender a realizar el camino más corto para

conseguir el objetivo de un sprint , el cual no siempre ofrece
resultados de calidad.

En definitiva, Scrum es especialmente interesante para proyectos en

los que el objetivo es la entrega de valor continua al cliente para
poder empezar a ver resultados lo antes posibles. Además, esta
metodología permite agilizar procesos, practicar la transparencia y
motivar al equipo a través de la autonomía y la independencia.

Implementación del método Scrum

En We Are Marketing estamos trabajando con el método Scrum y
contamos con miembros del equipo certificados como Scrum Masters
en la web oficial de Scrum . Aunque esta metodología fue concebida
inicialmente para proyectos de desarrollo, nosotros también lo
utilizamos dentro de nuestras campañas de Marketing 360º para
ofrecer al cliente visibilidad y control sobre las acciones que llevamos
a cabo.

Proceso unificado de desarrollo

 Espacios de nombres
• Página

• Discusión

Acciones de página
• Ver

• Ver código

• Historial

Proceso Unificado de Proceso unificado de desarrollo

Desarrollo (RUP): es una
metodología de desarrollo de
software que está basado en
componentes e interfaces
bien definidas, y junto con
el Lenguaje Unificado de
Modelado (UML), constituye
la metodología estándar más
utilizada para el análisis,
implementación y
documentación de sistemas
orientados a objetos.

Es un proceso que puede

especializarse para una gran
variedad de sistemas de
software, en diferentes áreas
de aplicación, diferentes tipos
de organizaciones, diferentes
Concepto: Un proceso define “quién” está haciendo
niveles de aptitud y diferentes “qué”, “cuándo” y “cómo” para alcanzar un
tamaños de proyecto. determinado objetivo

RUP no es un sistema con

pasos firmemente establecidos, sino un conjunto de metodologías adaptables al
contexto y necesidades de cada organización.

Es el resultado de varios años de desarrollo y uso práctico en el que se han unificado

técnicas de desarrollo, a través del UML, y trabajo de muchas metodologías utilizadas
por los clientes. La versión que se ha estandarizado vio la luz en 1998 y se conoció en
sus inicios como Proceso Unificado de Rational 5.0; de ahí las siglas con las que se
identifica a este proceso de desarrollo.
 Sumario
[ocultar]

• 1 Un poco de historia
• 2 Principales Elementos
• 3 Características Principales de RUP
• 4 Principales ventajas
• 5 Ciclo de vida de RUP
• 6 Flujo de Trabajo de RUP
• 7 Fases
• 8 Hitos
• 9 Diferencias de RUP con las demás metodologías
• 10 Enlaces Relacionados
• 11 Fuente

Un poco de historia
Los orígenes de RUP se remontan al modelo espiral original de Barry Boehm. Ken
Hartman, uno de los contribuidores claves de RUP colaboró con Boehm en la
investigación. En 1995 Rational Software compró una compañía sueca llamada
Objectory AB, fundada por Ivar Jacobson, famoso por haber incorporado los casos de
uso a los métodos de desarrollo orientados a objetos.

El Rational Unified Process fue el resultado de una convergencia de Rational

Approach y Objectory (el proceso de la empresa Objectory AB). El primer resultado de
esta fusión fue el Rational Objectory Process, la primera versión de RUP, fue puesta
en el mercado en 1998, siendo el arquitecto en jefe Philippe Kruchten.

Principales Elementos
Como RUP es un proceso, en su modelación define como sus principales elementos:

Trabajadores (“quién”): Define el comportamiento y responsabilidades (rol) de un

individuo, grupo de individuos, sistema automatizado o máquina, que trabajan en
conjunto como un equipo. Ellos realizan las actividades y son propietarios de
elementos.

Actividades (“cómo”): Es una tarea que tiene un propósito claro, es realizada por un
trabajador y manipula elementos.

Artefactos (“qué”): Productos tangibles del proyecto que son producidos,

modificados y usados por las actividades. Pueden ser modelos, elementos dentro del
modelo, código fuente y ejecutables.

Flujo de actividades (“cuándo”): Secuencia de actividades realizadas por

trabajadores y que produce un resultado de valor observable.
Características Principales de RUP
o Unifica los mejores elementos de metodologías anteriores.
o Preparado para desarrollar grandes y complejos proyectos.
o Orientado a Objetos.
o Utiliza el UML como lenguaje de representación visual.

Principales ventajas
o Coste del riesgo a un solo incremento.
o Reduce el riesgo de no sacar el producto en el calendario previsto.
o Acelera el ritmo de desarrollo.
o Se adapta mejor a las necesidades del cliente.

Ciclo de vida de RUP

El ciclo de vida de RUP se caracteriza por:
Dirigido por casos de uso: Los casos de uso reflejan lo que los usuarios futuros
necesitan y desean, lo cual se capta cuando se modela el negocio y se representa a
través de los requerimientos. A partir de aquí los casos de uso guían el proceso de
desarrollo ya que los modelos que se obtienen, como resultado de los diferentes flujos
de trabajo, representan la realización de los casos de uso (cómo se llevan a cabo).

Centrado en la arquitectura: La arquitectura muestra la visión común del sistema

completo en la que el equipo de proyecto y los usuarios deben estar de acuerdo, por
lo que describe los elementos del modelo que son más importantes para su
construcción, los cimientos del sistema que son necesarios como base para
comprenderlo, desarrollarlo y producirlo económicamente. RUP se desarrolla
mediante iteraciones, comenzando por los CU relevantes desde el punto de vista de la
arquitectura. El modelo de arquitectura se representa a través de vistas en las que se
incluyen los diagramas de UML.

Iterativo e Incremental: Una iteración involucra actividades de todos los flujos de

trabajo, aunque desarrolla fundamentalmente algunos más que otros.

Por ejemplo, una iteración de elaboración centra su atención en el análisis y diseño,

aunque refina los requerimientos y obtiene un producto con un determinado nivel,
pero que irá creciendo incrementalmente en cada iteración.
Es práctico dividir el trabajo en partes más pequeñas o miniproyectos. Cada
miniproyecto es una iteración que resulta en un incremento. Las iteraciones hacen
referencia a pasos en los flujos de trabajo, y los incrementos, al crecimiento del
producto. Cada iteración se realiza de forma planificada es por eso que se dice que
son miniproyectos.

Flujo de Trabajo de RUP

En RUP se han agrupado las actividades en grupos lógicos definiéndose 9 flujos de
trabajo principales, los 6 primeros son conocidos como flujos de ingeniería y los tres
últimos como flujos de apoyo.

o Modelo del Negocio: Describe los procesos de negocio, identificando quiénes

participan y las actividades que requieren automatización.
oRequerimiento: Define qué es lo que el sistema debe hacer, para lo cual se
identifican las funcionalidades requeridas y las restricciones que se imponen.
oAnálisis y Diseño :Describe cómo el sistema será realizado a partir de la
funcionalidad prevista y las restricciones impuestas (requerimientos), por lo que indica
con precisión lo que se debe programar.
o Implementación: Define cómo se organizan las clases y objetos en componentes,
cuáles nodos se utilizarán y la ubicación en ellos de los componentes y la estructura
de capas de la aplicación.
o Prueba (Testeo): Busca los defectos a los largo del ciclo de vida.
o Instalación o despliegue: Produce release del producto y realiza actividades
(empaque, instalación, asistencia a usuarios, etc.) para entregar el software a los
usuarios finales.
o Administración del proyecto: Involucra actividades con las que se busca producir
un producto que satisfaga las necesidades de los clientes.
o Administración de configuración y cambios: Describe cómo controlar los
elementos producidos por todos los integrantes del equipo de proyecto en cuanto a:
utilización/actualización concurrente de elementos, control de versiones, etc.
o Ambiente: Contiene actividades que describen los procesos y herramientas que
soportarán el equipo de trabajo del proyecto; así como el procedimiento para
implementar el proceso en una organización.

Fases
Cada fase representa un ciclo de desarrollo en la vida de un producto de software.
La fase de concepción o inicio tiene por finalidad definir la visión, los objetivos y el
alcance del proyecto, tanto desde el punto de vista funcional como del técnico,
obteniéndose como uno de los principales resultados una lista de los casos de uso y
una lista de los factores de riesgo del proyecto. El principal esfuerzo está radicado en
el Modelamiento del Negocio y el Análisis de Requerimientos. Es la única fase que no
necesariamente culmina con una versión ejecutable.
La fase de elaboración tiene como principal finalidad completar el análisis de los
casos de uso y definir la arquitectura del sistema, además se obtiene una aplicación
ejecutable que responde a los casos de uso que la comprometen. A pesar de que se
desarrolla a profundidad una parte del sistema, las decisiones sobre la arquitectura se
hacen sobre la base de la comprensión del sistema completo y los requerimientos
(funcionales y no funcionales) identificados de acuerdo al alcance definido.
La fase de construcción está compuesta por un ciclo de varias iteraciones, en las
cuales se van incorporando sucesivamente los casos de uso, de acuerdo a los
factores de riesgo del proyecto. Este enfoque permite por ejemplo contar en forma
temprana con versiones el sistema que satisfacen los principales casos de uso. Los
cambios en los requerimientos no se incorporan hasta el inicio de la próxima iteración.
La fase de transición se inicia con una versión “beta” del sistema y culmina con el
sistema en fase de producción.

Hitos
Fases Hitos
Conceptualización -
Objetivos (visión)
Inicio
Elaboración Arquitectura
Funcionalidad
Construcción
operativa
Transición Release del sistema

Diferencias de RUP con las demás metodologías

Algunos aspectos que diferencian a RUP de las demás metodologías y lo que lo hace
único es que en RUP, los casos de uso no son sólo una herramienta para especificar
los requisitos del sistema, sino que también guían su diseño, implementación y
prueba. Los casos de uso constituyen un elemento integrador y una guía del trabajo.

Además de utilizar los casos de uso para guiar el proceso; se presta especial atención
al establecimiento temprano de una buena arquitectura que no se vea fuertemente
impactada ante cambios posteriores durante la construcción y el mantenimiento.
También este propone que cada fase se desarrolle en iteraciones