Metodología Híbrida:

RUP
Autor: Mg. Mauricio Galvez Legua
([email protected])

Autor: Mauricio Galvez Legua ([email protected]) 1

 Definición
• RUP (Rational Unified Process) o Proceso Unificado
Racional, es una metodología de proceso de
desarrollo de software desarrollado por IBM.
• Junto con UML (Unified Modeling Language),
constituyen en una metodología estándar muy
utilizado para el análisis, diseño, implementación y
documentación de sistemas orientados a objetos.

Autor: Mauricio Galvez Legua ([email protected]) 2

 Definición
• RUP es un marco genérico que puede adaptarse a
una gran variedad de tipos de sistemas, áreas de
aplicación, tipos de organizaciones y diferentes
tamaños de proyectos.
• RUP no es un sistema con pasos específicamente
definidos.

Autor: Mauricio Galvez Legua ([email protected]) 3

 Principios de desarrollo de RUP
• La filosofía RUP se desarrolló en base a 6 principios:
– Adaptar el proceso
– Equilibrar prioridades
– Demostrar valor iterativamente (ágil)
– Colaboración entre equipos (ágil)
– Enfocarse en la calidad (mejora continua,
enfocado en el “cliente”) (ágil)
– Elevar el nivel de abstracción (mejorar el
entendimiento del sistema por parte del usuario)

Autor: Mauricio Galvez Legua ([email protected]) 4

 Principios de desarrollo de RUP
• Adaptar el proceso:
– El proceso debe adaptarse a las características propias del
proyecto u organización.
– Influyen en su diseño específico: el tamaño y tipo de
organización, así como las regulaciones existentes.
– Se debe tener en cuenta el alcance del proyecto.

Autor: Mauricio Galvez Legua ([email protected]) 5

 Principios de desarrollo de RUP
• Equilibrar prioridades:
– Los requerimientos de los diversos usuarios pueden ser
diferentes, contradictorios o disputarse recursos limitados.
– Debe encontrarse un equilibrio que satisfaga los
requerimientos de todos. En base a este equilibrio se
podrán corregir desacuerdos que surjan en el futuro.

Autor: Mauricio Galvez Legua ([email protected]) 6

 Principios de desarrollo de RUP
• Demostrar valor iterativamente:
– Los proyectos se entregan, aunque sea de un modo
interno, en etapas iteradas.
– En cada iteración se analiza la opinión del cliente, la
estabilidad y calidad del producto, y se ajusta la dirección
del proyecto así como también los riesgos involucrados.

Autor: Mauricio Galvez Legua ([email protected]) 7

 Principios de desarrollo de RUP
• Colaboración entre equipos:
– El desarrollo de software no lo hace una única persona
sino un equipo.
– Debe haber una comunicación fluida para coordinar
requisitos, desarrollo, evaluaciones, planes, resultados,
etc.

Autor: Mauricio Galvez Legua ([email protected]) 8

 Principios de desarrollo de RUP
• Enfocarse en la calidad:
– El control de calidad no debe realizarse al final de cada
iteración, sino en todos los aspectos de la producción del
software.
– El aseguramiento de la calidad forma parte del proceso de
desarrollo y no de un grupo independiente. Es una
estrategia de desarrollo de software.

Autor: Mauricio Galvez Legua ([email protected]) 9

 Principios de desarrollo de RUP
• Elevar el nivel de abstracción:
– Este principio dominante motiva el uso de conceptos
reutilizables tales como patrones de diseño del software,
lenguajes 4GL o esquemas (frameworks), etc. Estos se
pueden acompañar por las representaciones visuales de la
arquitectura, por ejemplo con UML.

Autor: Mauricio Galvez Legua ([email protected]) 10

 Características del Proceso RUP
• Presenta las siguientes características:
– Dirigido por casos de uso
– Centrado en la arquitectura
– Iterativo e Incremental
– Desarrollo basado en componentes
– Utilización de UML
– Proceso integrado

Autor: Mauricio Galvez Legua ([email protected]) 11

 Características del Proceso RUP: Dirigido
por casos de uso
• Significa que los requerimientos están
enfocados a dar valor al cliente y que el
proceso debe garantizar que todo el
desarrollo, pruebas, planificación,
documentación, entre otros, está fuertemente
orientado a cubrir estas expectativas del
cliente y asegurar que los requerimientos de
valor se ponen en producción.

Autor: Mauricio Galvez Legua ([email protected]) 12

 Casos de Uso

• Los casos de uso son una técnica de captura

de requisitos que fuerza a pensar en términos
de importancia para el usuario y no sólo en
términos de funciones.
• Un caso de uso es un fragmento de
funcionalidad del sistema que proporciona un
resultado de valor para el usuario.

Autor: Mauricio Galvez Legua ([email protected]) 13

 Casos de Uso
• Los casos de uso
modelan los
requerimientos
funcionales del sistema.
• Un caso de uso es la
descripción de una
acción o actividad.
• Los casos de uso guían el
proceso de desarrollo
del software: diseño,
implementación y
pruebas.
Autor: Mauricio Galvez Legua ([email protected]) 14
 Casos de Uso
• Un diagrama de caso de uso es una descripción de
las actividades que deberá realizar alguien o algo
para llevar a cabo algún proceso.
• Los personajes o entidades que participarán en un
diagrama de caso de uso se denominan actores. Se le
llama actor a toda entidad externa al sistema que
guarda una relación con este y que le demanda una
funcionalidad.

Autor: Mauricio Galvez Legua ([email protected]) 15

 Casos de Uso
• Los diagramas de casos de uso sirven para especificar
la comunicación y el comportamiento de un sistema
mediante su interacción con los usuarios y/u otros
sistemas.
Capturar, definir y validar
los casos de uso

Implementar los casos de

uso

Verificar que se satisfacen

los casos de uso

Autor: Mauricio Galvez Legua ([email protected]) 16

Características del Proceso RUP: Centrado
en la arquitectura
• Significa que hay un énfasis a diseñar una
arquitectura de calidad, y es la arquitectura
también la que guía la forma cómo se debe
planear y hacer el desarrollo.

Autor: Mauricio Galvez Legua ([email protected]) 17

Características del Proceso RUP: Centrado
en la arquitectura
• La arquitectura de un software se define
como:
Conjunto de decisiones significativas acerca de
la organización de un sistema software, la
selección de los elementos estructurales a partir
de los cuales se compone el sistema, las
interfaces entre ellos, su comportamiento, sus
colaboraciones, y su composición.

Autor: Mauricio Galvez Legua ([email protected]) 18

Características del Proceso RUP: Centrado
en la arquitectura
• La arquitectura de un sistema software se
describe mediante diferentes vistas del
sistema en construcción.
– El concepto de arquitectura de software incluye
los aspectos estáticos y dinámicos más
significativos del sistema.
– La arquitectura del software es una vista del
diseño completo con las características más
importantes resaltadas, dejando los detalles de
lado.
Autor: Mauricio Galvez Legua ([email protected]) 19
 Características del Proceso RUP: Iterativo
e incremental
• Significa que el proyecto se divide en varios ciclos
de vida, denominadas iteraciones, que deben dar
como resultado el sistema de software.
• Se establecen criterios de evaluación cada vez
que se planifica una iteración.

Autor: Mauricio Galvez Legua ([email protected]) 20

 Características del Proceso RUP: Iterativo
e incremental
• Por cada una de las iteraciones se va agregando
nuevos requerimientos y sobre todo valor para el
cliente; por este motivo es incremental.

Autor: Mauricio Galvez Legua ([email protected]) 21

 Características del Proceso RUP:
Desarrollo basado en componentes
• La creación de sistemas complejos en software
requiere dividir el sistema en componentes con
interfaces bien definidas, que posteriormente serán
ensamblados para obtener el sistema completo.
– El software está formado por componentes de software
interconectados a través de interfaces.
• Esta característica en el proceso de desarrollo,
permite que el sistema se vaya creando a medida
que se obtienen o se desarrollan sus componentes.

Autor: Mauricio Galvez Legua ([email protected]) 22

 Características del Proceso RUP:
Utilización del UML
• UML es un lenguaje para visualizar, especificar,
construir y documentar software.
– Utilizar herramientas de modelado visual facilita la gestión
de dichos modelos, permitiendo ocultar o exponer detalles
cuando sea necesario.
– El modelado visual también ayuda a mantener la
consistencia.
• En resumen, el modelado visual ayuda a mejorar la
capacidad del equipo para gestionar la complejidad
del software.

Autor: Mauricio Galvez Legua ([email protected]) 23

 Características del Proceso RUP: Proceso
integrado
• Proceso integrado

Autor: Mauricio Galvez Legua ([email protected]) 24

 Ciclo de vida de RUP
• RUP repite a lo largo de una serie de ciclos que
constituyen la vida de un sistema. Cada ciclo
constituye una versión del sistema.
• El ciclo de vida RUP es una implementación del
desarrollo en espiral.

Autor: Mauricio Galvez Legua ([email protected]) 25

 Ciclo de vida de RUP
• El ciclo de vida de RUP se organiza en cuatro fases
secuenciales (modelo cascada):
– Inicio o concepción (Inception): Objetivos y alcance del
proyecto.
– Elaboración (Elaboration): elaborar la arquitectura del
sistema.
– Construcción (Construction): Desarrollar las
funcionalidades del sistema.
– Transición (Transition): Depurar y entregar al usuario.

Inception Elaboration Construction Transition

Autor: Mauricio Galvez Legua ([email protected]) 26

 Ciclo de vida de RUP: Inicio o concepción
• Se define el alcance del proyecto. Se desarrolla una
descripción del producto final (requerimientos del
sistema) mediante casos de uso, y se presenta el
análisis del negocio. Esta fase responde las siguientes
preguntas:
– ¿Cuáles son las principales funciones del sistema para los
usuarios más importantes?
– ¿Cómo sería la arquitectura del sistema?
– ¿Cuál es el plan del proyecto y cuánto costará desarrollar
el producto?

Autor: Mauricio Galvez Legua ([email protected]) 27

 Ciclo de vida de RUP: Inicio o concepción
• En esta fase se identifican y priorizan los riesgos más
importantes.
• Las iteraciones hacen mayor énfasis en actividades
de modelado del negocio y de requisitos.

Autor: Mauricio Galvez Legua ([email protected]) 28

 Ciclo de vida de RUP: Elaboración
• Planificar el proyecto y elaborar la arquitectura base.
Se especifican en detalle la mayoría de los casos de
uso del software y se diseña la arquitectura.
• Las iteraciones en la fase de elaboración:
– Establecen una firme comprensión del problema a
solucionar.
– Establece la fundamentación arquitectural para el
software.
– Establece un plan detallado para las siguientes iteraciones.
– “Elimina” los mayores riesgos.

Autor: Mauricio Galvez Legua ([email protected]) 29

 Ciclo de vida de RUP: Elaboración
• Las iteraciones se orientan al desarrollo de la línea
base de la arquitectura, abarcan los flujos de trabajo
de requisitos, modelo de negocios, análisis, diseño y
una parte de implementación orientado a la línea
base de la arquitectura.

Autor: Mauricio Galvez Legua ([email protected]) 30

 Ciclo de vida de RUP: Construcción
• Construir el sistema. Durante la fase de construcción
se desarrolla el software. La línea base de la
arquitectura crece hasta convertirse en el sistema
completo.

Autor: Mauricio Galvez Legua ([email protected]) 31

 Ciclo de vida de RUP: Construcción
• Para cada iteración se
seleccionan algunos casos de uso,
se refinan su análisis y diseño y se
procede a su implementación y
pruebas.
• Se realizan iteraciones hasta que
se termine la implementación de
la nueva versión del software.

Autor: Mauricio Galvez Legua ([email protected]) 32

 Ciclo de vida de RUP: Transición
• Transición a los usuarios. Cubre el período durante el
cual el software se convierte en la versión beta. Las
iteraciones en esta fase continúan agregando
características al software. Sin embargo las
características se agregan a un sistema que el usuario
se encuentra utilizando activamente.
– Se pretende garantizar que se tiene un producto
preparado para su entrega a la comunidad de usuarios.

Autor: Mauricio Galvez Legua ([email protected]) 33

 Ciclo de vida de RUP
• La duración y esfuerzo dedicado en cada fase es
variable dependiendo de las características del
proyecto. En promedio se tiene:

Autor: Mauricio Galvez Legua ([email protected]) 34

 Workflows o disciplinas
• Cada fase en RUP se completa con la realización
de varias iteraciones en las que se desarrollan
una serie de actividades, que el modelo RUP se
denominan workflows o disciplinas.

Autor: Mauricio Galvez Legua ([email protected]) 35

 Workflows o disciplinas
• Los workflows o disciplinas, las podemos dividir
en dos grandes grupos:
– Workflows primarios
– Workflows de apoyo

Autor: Mauricio Galvez Legua ([email protected]) 36

 Workflows primarios
• Workflows primarios:
– Business Modeling (Modelado de negocio): Describe los
procesos de negocio, identificando quiénes participan y las
actividades que requieren automatización.
– Requirements (Requisitos): Define qué es lo que el
sistema debe hacer, para lo cual se identifican las
funcionalidades requeridas y las restricciones que se
imponen.
– Analysis & Design (Análisis y diseño): Describe cómo el
sistema será realizado a partir de la funcionalidad
prevista y las restricciones impuestas, por lo que
indica con precisión lo que se debe programar.

Autor: Mauricio Galvez Legua ([email protected]) 37

 Workflows primarios
– Implementation (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.
– Test (Pruebas): Asegurarse que el funcionamiento
del sistema sea el correcto y que todo lo solicitado
está presente.
– Deployment (Despliegue): Realiza actividades
(empaque, instalación, asistencia a usuarios, etc.)
para entregar el software a los usuarios finales.

Autor: Mauricio Galvez Legua ([email protected]) 38

 Workflows primarios
Independientemente
de la fase

Autor: Mauricio Galvez Legua ([email protected]) 39

 Comparativa
• Comparativa entre el modelo cascada y el modelo
iterativo e incremental y modelo RUP:

Autor: Mauricio Galvez Legua ([email protected]) 40

 Workflows de apoyo
• Workflows de apoyo:
– Configuration & Change Management (Gestión de
configuración y cambios): Describe cómo controlar los
elementos producidos por todos los integrantes del equipo
de proyecto en cuanto a la utilización/actualización
concurrente de elementos, control de versiones, etc.
– Proyect Management (Gestión del proyecto): Involucra
actividades con las que se busca producir un producto que
satisfaga las necesidades de los clientes.
– Enviroment (Entorno): 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.

Autor: Mauricio Galvez Legua ([email protected]) 41

 Workflows o disciplinas

Autor: Mauricio Galvez Legua ([email protected]) 42

 Workflows o disciplinas
• El agrupamiento de disciplinas es principalmente una
ayuda para comprender el proyecto desde la visión
tradicional en cascada.

Autor: Mauricio Galvez Legua ([email protected]) 43

 Workflows o disciplinas
• Las disciplinas las podemos clasificar en dos partes:
– Desarrollo
– Soporte

Autor: Mauricio Galvez Legua ([email protected]) 44

 Workflows o disciplinas
• Disciplinas 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.
– Codificación: Se crea el software adaptándolo a las
necesidades.
– Pruebas: Se comprueba que el software actúa de forma
adecuada.

Autor: Mauricio Galvez Legua ([email protected]) 45

 Workflows o disciplinas
• Disciplinas de Soporte:
– Administración del Proyecto: Proveer un marco de trabajo
para administrar los proyectos de software.
• Proveer guías prácticas para la planeación, soporte,
ejecución y monitoreo de proyectos.
• Proveer un marco de trabajo para la administración del
riesgo.

Autor: Mauricio Galvez Legua ([email protected]) 46

 Workflows o disciplinas
• Disciplinas de Soporte:
– Gestión, Configuración y Cambio: Consiste en controlar los
cambios y mantener la integridad de los productos que
incluye el proyecto.
• Identificar los elementos configurables.
• Restringir los cambios en los elementos configurables.
• Auditar los cambios hechos a estos elementos.
• Definir y mantener las configuraciones de estos
elementos.

Autor: Mauricio Galvez Legua ([email protected]) 47

 Workflows o disciplinas
• Cada disciplina está asociada con un conjunto de
modelos que se desarrollan.
Disciplina Modelos
Requisitos Modelo de Casos de Uso
Análisis Modelo de Análisis
Diseño Modelo de Diseño – Modelo de Despliegue
Implementación Modelo de Implementación
Prueba Modelo de Prueba

Autor: Mauricio Galvez Legua ([email protected]) 48

 Artefactos
• Los artefactos son unidades de información creadas,
producidas, cambiadas o utilizadas en el proceso de
desarrollo del software.
• Un artefacto puede ser:
– Un documento, como un caso de negocio o un documento
de la arquitectura del software.
– Un modelo, como un modelo de caso de uso. Los modelos
están plasmados en artefactos (documentos).

Autor: Mauricio Galvez Legua ([email protected]) 49

 Artefactos
• Grado de finalización de los artefactos por cada fase:

Autor: Mauricio Galvez Legua ([email protected]) 50

 Hitos
• Cada fase finaliza con un hito. Cada hito se
determina por la disponibilidad de un conjunto de
modelos, los cuales están compuestos de
documentos (artefactos) que han sido desarrollados
hasta alcanzar un estado definitivo.

Autor: Mauricio Galvez Legua ([email protected]) 51

 Hitos
• Los hitos tienen muchos objetivos, es por ello que los
jefes de proyecto deben tomar ciertas decisiones
antes de que el trabajo continúe con la siguiente
fase.
• Los hitos permiten controlar la dirección y progreso
del trabajo.
• Al final se obtiene un conjunto de datos a partir del
seguimiento del tiempo y esfuerzo consumidos en
cada fase. Estos datos son útiles para las
estimaciones en futuros proyectos.

Autor: Mauricio Galvez Legua ([email protected]) 52

 Roles
• Un rol define el comportamiento y responsabilidades
de un individuo, o de un grupo de individuos
trabajando juntos como un equipo.
• 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 debe de conseguir.

Autor: Mauricio Galvez Legua ([email protected]) 53

 Roles
• Una persona puede desempeñar diversos roles, así
como un mismo rol puede ser representado por
varias personas.
• Las responsabilidades de un rol son tanto el llevar a
cabo un conjunto de actividades como el ser el
dueño de un conjunto de artefactos.

Autor: Mauricio Galvez Legua ([email protected]) 54

 Roles por cada disciplina
Disciplina Roles generales Roles específicos
Modelado de Analista de procesos de Diseñador de negocio: Detallar un
negocio negocio: Descubrir todos los conjunto de los casos de uso de
casos de uso de negocio. negocio.
Requisitos Analista de sistemas: Descubrir Especificador de casos de uso:
todos los casos de uso. Detallar un conjunto de los casos de
uso.
Análisis y diseño Arquitectos de Software: Toma Diseñadores: Detallan el análisis y
decisiones tecnológicas de la diseño para un conjunto de casos de
solución a nivel global. uso.
Implementación Integrador: Es el propietario Desarrollador o programador:
del plan de construcción que Implementa un conjunto de clases o
muestra cómo se integrarán un conjunto de operaciones de una
cada una de las clases con las clase.
otras.

Autor: Mauricio Galvez Legua ([email protected]) 55

 Roles por cada disciplina
Disciplina Roles generales Roles específicos
Pruebas Gestor de las pruebas (tester): Diseñador de pruebas:
Asegura que las pruebas han sido Implementa las pruebas
realizadas correctamente. automáticas de la iteración.
Analista de pruebas: Selecciona qué Probador: Ejecuta un test
se va a probar según lo estimado. específico.
Diseñador de pruebas: Decide qué
pruebas deberían ser automáticas o
manuales, y crea las automáticas.
Despliegue o Gestor de la implantación: Supervisa Asegurar la correcta
implantación la implantación de todas las unidades. implantación del sistema.

Autor: Mauricio Galvez Legua ([email protected]) 56

 Roles por cada disciplina
Disciplina Roles generales Roles específicos
Gestión del proyecto Gestor del proyecto: Crea los Gestor de proyectos: Planifica,
casos de negocio y un plan monitoriza y gestiona los riesgos para
general, y toma decisiones una sola iteración.
críticas al respecto de que
cosas hacer y cuales no hacer.
Entorno Ingeniero de procesos: Es el Especialista en herramientas: Crea
responsable de los procesos manuales de uso de herramientas
del proyecto. específicas.
Configuración y Gestor de la configuración: Gestor de la configuración: Crea una
mantenimiento Establece las políticas y planes. unidad de despliegue o implantación,
Gestor de control de cambios: reportes del estado de la
Establece un proceso de configuración, auditorias, entre otros.
control de los cambios. Gestor de control de cambios: Revisa
y gestiona las peticiones de cambios.

Autor: Mauricio Galvez Legua ([email protected]) 57

 Roles, actividades, artefactos y flujos de
trabajo
• Un proceso de desarrollo de software define quién
hace qué, cómo y cuándo:
– Los roles, responden a la pregunta ¿Quién?
– Los productos de trabajo, responde a la pregunta ¿Qué se
va a realizar?
– Las actividades, responden a la pregunta ¿Cómo?
– Los flujos de trabajo de las disciplinas, responde a la
pregunta ¿Cuándo?

Autor: Mauricio Galvez Legua ([email protected]) 58

 Roles, actividades, artefactos y flujos de
trabajo

Autor: Mauricio Galvez Legua ([email protected]) 59

 Roles, actividades, artefactos y flujos de
trabajo
• RUP se define por una serie de características
denominadas buenas prácticas y que vienen
definidas en “RUP, Best Software Practices
Development”:
– Gestión de los riesgos: Decidir qué riesgos tener en cuenta
en cada iteración. Actualizar la lista de riesgos y hacerla
visible. Utilizar herramientas de gestión de riesgos y
trazabilidad.
– Desarrollos iterativos: Entregas iterativas. Replanificación
basada en el feedback. Planificar las iteraciones en función
de los riesgos.

Autor: Mauricio Galvez Legua ([email protected]) 60

 Roles, actividades, artefactos y flujos de
trabajo
– Usar componentes basados en la arquitectura: Aplicar
componentes y principio de diseño de servicios. Modelar
componentes, servicios e interfaces. Crear especificaciones
detalladas de los componentes y los servicios.
– Gestión de los requisitos: Identificar escenarios. Capturar
casos de uso, y relacionarlos con sus respectivos
escenarios. Trocear casos de uso en requisitos gestionados
independientemente. Utiliza UML para la realización de un
modelo visual del software.

Autor: Mauricio Galvez Legua ([email protected]) 61

 Roles, actividades, artefactos y flujos de
trabajo
– Modelado del software visual: La calidad debe ser revisada
respecto a los requisitos basándose en la fiabilidad,
funcionalidad, rendimiento de la aplicación y del sistema.
Planificación, diseño, implementación, ejecución y
evaluación de las pruebas.
– Verificar la calidad del software: Controlar y hacer el
seguimiento de los cambios. Utilización de entornos de
trabajos independientes para aislar los diferentes cambios.
– Control de los cambios del software: La metodología RUP
quizás sea la más adecuada para proyectos grandes ya que
necesita disponer de un equipo de trabajo que sea capaz
de manejar procesos en varias etapas.

Autor: Mauricio Galvez Legua ([email protected]) 62

 Fin !!!

Autor: Mg. Mauricio Galvez Legua

([email protected])

Autor: Mauricio Galvez Legua ([email protected]) 63

 Metodologías en el desarrollo de
software
Autor: Mg. Mauricio Galvez Legua
([email protected])

Autor: Mauricio Galvez Legua ([email protected]) 1

 Introducción
• Las metodologías para el desarrollo de software las
podemos clasificar en dos grandes grupos:
– Metodologías tradicionales o predictivas:
• Popularmente conocidas como waterfall o plan-driven
o procesos dirigidos por un plan.
• Enfocados en el tiempo y costo estimado.
• El cliente solo participa al inicio del desarrollo del sw.
– Metodologías ágiles o incrementales.
• Enfocados en la flexibilidad y mejora continua.
• El cliente participa en todo el proceso de desarrollo del
sw.

Autor: Mauricio Galvez Legua ([email protected]) 2

El cliente no especifica
Introducción
adecuadamente lo que
realmente requiere. Producto Final

Producto Final Producto Final

Al cliente se le va
presentando prototipos
de lo que requiere.

Prototipo 1 Prototipo 2 Prototipo 3 Prototipo 4

Autor: Mauricio Galvez Legua ([email protected]) 3
 Metodologías Tradicionales o predictivas
• Las metodologías tradicionales o waterfall o basadas
en procesos dirigidos por un plan se desarrollaron en
ambientes empresariales dominados por los
mainframes, los cuales eran sistemas de cómputo
propietarios y caros.

Autor: Mauricio Galvez Legua ([email protected]) 4

 Metodologías Tradicionales o predictivas
• Tuvieron su auge en las grandes empresas, en donde
la lógica de negocio no cambiaba frecuentemente y
por ende el software podía ser útil por muchos años
sin casi ninguna modificación.
• Esto ocasionó que los desarrollos de software fueran
muy complejos y especializados y que solo la
empresa que comercializaba los mainframes tenia el
conocimiento para realizar tales desarrollos.

Autor: Mauricio Galvez Legua ([email protected]) 5

 Metodologías Tradicionales o predictivas
• Se difundió la idea que la forma más adecuada para
lograr un mejor software era:
– Mediante una cuidadosa planeación del proyecto.
– Aseguramiento de calidad formalizada.
– El uso de métodos de análisis y el diseño apoyado por
herramientas CASE (Computer Aided Software
Engineering).
– Procesos de desarrollo de software rigurosos (poca
flexibilidad para los cambios) y controlados (ampliamente
documentado)
• Esto se acentuó aún más con el desarrollo de grandes
sistemas de software de larga duración, como los
sistemas aeroespaciales y gubernamentales.

Autor: Mauricio Galvez Legua ([email protected]) 6

 Metodologías Tradicionales o predictivas
• En muchos casos los equipos de desarrollo estaban
geográficamente dispersos y la elaboración del
software duraba largos periodos de tiempo.
• Un ejemplo de este tipo de software es el sistema de
control de una aeronave moderna, que podía tardar
hasta diez años desde la especificación inicial hasta la
implementación.
El software aeronáutico incluye las funcionalidades
propias de una solución de gestión, además del
mantenimiento de las aeronaves y cuestiones
ingenieras del sector.

Autor: Mauricio Galvez Legua ([email protected]) 7

 Metodologías Tradicionales o predictivas
• Estas metodologías son una disciplina que tiene
como base una gestión predictiva.
• Con los requisitos iniciales del proyecto, se configura
un plan adecuado empleando recursos y el tiempo
necesarios.
• Durante la fase de desarrollo se comprueba si hay
desviaciones, si las hay, se definen las medidas a
tomar y se valora cuáles son las variaciones que
puede experimentar la planificación original.

Autor: Mauricio Galvez Legua ([email protected]) 8

 Metodologías Tradicionales o predictivas
• Un enfoque basado procesos dirigidos por un plan
identifica etapas separadas en el proceso de
software con salidas asociadas a cada etapa.
– Las salidas de una etapa se usan como base para planear la
siguiente actividad del proceso.
– La iteración ocurre dentro de las actividades con
documentos formales usados para comunicarse entre
etapas del proceso.

Documento Documento Documento

1 2 3

Autor: Mauricio Galvez Legua ([email protected]) 9

 Metodologías Tradicionales o predictivas
“Las metodologías tradicionales, normalmente se
relacionan al modelo cascada simple (waterfall)”
Análisis y
Desarrollo o Pruebas o Despliegue y
definición de Diseño
Implementación Verificación Mantenimiento
requisitos

Autor: Mauricio Galvez Legua ([email protected]) 10

 Metodologías Tradicionales o predictivas
• Las metodologías tradicionales o basadas en
procesos dirigidos por un plan, incluyen costos
operativos significativos en la planeación, el diseño y
la documentación del sistema.
– En algunos tipos de software, como los sistemas de control
críticos para la seguridad, donde es esencial un análisis
completo del sistema, resulta justificable dichos costos.

Autor: Mauricio Galvez Legua ([email protected]) 11

 Metodologías Tradicionales

Autor: Mauricio Galvez Legua ([email protected]) 12

 Metodologías Tradicionales:
características
• Los requisitos son fundamentales y deben estar bien definidos
al inicio del proyecto.
• Se supone que en el proyecto, no va a surgir ningún tipo de
modificación, por lo tanto no está sujeto a modificaciones.
• Se basa en procesos.
• Gestión predictiva (se sabe de antemano, el tiempo y costo).
• El desarrollo del software se define en fases cuyo conjunto se
denomina “ciclo de vida”.
• Documentación exhaustiva de todo el proyecto. Los proyectos
suelen estar bien documentados.
• Se enfocan en obtener el software en tiempo y coste
establecido.

Autor: Mauricio Galvez Legua ([email protected]) 13

 Metodologías Tradicionales: ventajas
• La gestión de proyectos en cascada o waterfall
permite:
– Planificar los proyectos con anticipación para evitar la
corrupción del alcance.
– Realizar un “fácil” seguimiento del progreso en las
diferentes fases del proyecto.
– Trabajar en varios proyectos sin estar completamente
dedicado a uno en particular.
– Gestionar las dependencias fácilmente.

Autor: Mauricio Galvez Legua ([email protected]) 14

 Metodologías Tradicionales: desventajas
• Esta metodología también tiene algunas desventajas
que es importante tener en cuenta:
– Puede conducir a un mayor riesgo del proyecto debido a la
falta de flexibilidad.
– Puede provocar la pérdida de información si diferentes
personas trabajan en el proyecto durante las diferentes
fases y no se documenta con claridad.
– Puede provocar errores inesperados si los controles de
calidad se realizan tarde.
– Puede disminuir la satisfacción del cliente por su poca o
nula participación en el proyecto.

Autor: Mauricio Galvez Legua ([email protected]) 15

 “Ley” de Brooks
• Frederick Phillips Brooks, es un
ingeniero de software y científico
de la computación que trabajó en
IBM y dirigió el desarrollo del
sistema operativo OS/360 (uno de
los proyectos de software más
grandes de la historia).

Autor: Mauricio Galvez Legua ([email protected]) 16

 “Ley” de Brooks
• Basado en esa experiencia escribió un libro de
administración de proyectos de ingeniería de
software denominado The Mythical Man-Month:
Essays on Software Engineering (Mítico Hombre-
Mes: Ensayos de ingeniería de Software) en donde
contaba anécdotas del desarrollo del OS/360 y en
donde afirmó su famosa Ley de Brooks:
“Añadir recursos humanos a un proyecto retrasado lo
hace demorarse aún más”

Autor: Mauricio Galvez Legua ([email protected]) 17

 “Ley” de Brooks

Autor: Mauricio Galvez Legua ([email protected]) 18

 Cambio y Complejidad
• En el año 2001, diecisiete personas se reunieron y
crearon lo que conocemos hoy como el Manifiesto
Ágil, el cual sentaría las bases para las metodologías
ágiles que surgirían formalmente después, como
Scrum, XP, DSDM, Crystal, entre otros.

Autor: Mauricio Galvez Legua ([email protected]) 19

 Manifiesto Ágil
• A causa de las metodologías ágiles, que estaban
surgiendo, se definieron los 4 postulados que dan
origen al “Manifiesto Ágil”, el cual propugnaba
“mejores formas de desarrollar software”.

Autor: Mauricio Galvez Legua ([email protected]) 20

 Manifiesto Ágil

Autor: Mauricio Galvez Legua ([email protected]) 21

 Manifiesto Ágil
• Del manifiesto ágil, se desprende doce principios:
1. Nuestra mayor prioridad es satisfacer al cliente mediante la
entrega temprana y continua de software con valor.
2. Aceptamos que los requisitos cambien, incluso en etapas
tardías del desarrollo. Los procesos Ágiles aprovechan el
cambio para proporcionar ventaja competitiva al cliente.
3. Entregamos software funcional frecuentemente, entre dos
semanas y dos meses, con preferencia al periodo de tiempo
más corto posible.
4. Los responsables de negocio y los desarrolladores trabajamos
juntos de forma cotidiana durante todo el proyecto.
5. Los proyectos se desarrollan en torno a individuos motivados.
Hay que darles el entorno y el apoyo que necesitan, y confiarles
la ejecución del trabajo.

Autor: Mauricio Galvez Legua ([email protected]) 22

 Manifiesto Ágil
6. El método más eficiente y efectivo de comunicar información al
equipo de desarrollo y entre sus miembros es la conversación cara a
cara.
7. El software funcionando es la medida principal de progreso.
8. Los procesos Ágiles promueven el desarrollo sostenible. Los
promotores, desarrolladores y usuarios debemos ser capaces de
mantener un ritmo constante de forma indefinida.
9. La atención continua a la excelencia técnica y al buen diseño mejora
la Agilidad.
10. La simplicidad, o el arte de maximizar la cantidad de trabajo no
realizado, es esencial.
11. Las mejores arquitecturas, requisitos y diseños emergen de equipos
auto-organizados.
12. A intervalos regulares el equipo reflexiona sobre cómo ser más
efectivo. Esto permite ajustar y perfeccionar su comportamiento en
consecuencia (mejora continua).

Autor: Mauricio Galvez Legua ([email protected]) 23

 Cambio y Complejidad
• Estas personas encontraron problemas comunes en
la implementación de sus proyectos de software, los
cuales se podían diferenciar de los proyectos
comunes.
• Se llegó a diferenciar los proyectos de software de
otros proyectos en base al nivel de incertidumbre o
complejidad. Por ejemplo: no es lo mismo construir
una carretera, luego de hacerlo mil veces, que
construir un software para resolver un problema
específico y que jamás se ha realizado.

Autor: Mauricio Galvez Legua ([email protected]) 24

 Cambio y Complejidad
• El cambio y la complejidad es una forma útil de
analizar y determinar la mejor forma de desarrollar
software:

Autor: Mauricio Galvez Legua ([email protected]) 25

 Cambio y Complejidad
• Las diferentes zonas proporcionan un medio simple
para categorizar las condiciones para el desarrollo de
un software:
– Las metodologías ágiles surgieron con el fin de gestionar la
dimensión del cambio, por lo que su aplicación esta en las
zonas uno y dos.
– Las metodologías tradicionales son apropiadas para la
gestión de programas de desarrollo complejos a gran
escala, por lo que se adaptan bien a las zonas uno y tres,
donde la baja volatilidad del cambio permite una
planificación más detallada.

Autor: Mauricio Galvez Legua ([email protected]) 26

 Cambio y Complejidad
• En el caso del cuadrante uno, donde el cambio y la
complejidad son bajos se puede elegir cualquier
metodología.
• El problema esta en la zona cuatro, en donde una
combinación de metodologías puede ser la solución.

Autor: Mauricio Galvez Legua ([email protected]) 27

 Metodologías Ágiles o incremental
• Actualmente las empresas operan en un entorno
global que cambia rápidamente y por ello deben
responder frente a nuevas oportunidades y
mercados así como al surgimiento de productos y
servicios competitivos.
• Tecnologías como la globalización, el internet y las
telecomunicaciones han propiciado estos cambios.

Autor: Mauricio Galvez Legua ([email protected]) 28

 Metodologías Ágiles o incremental
• El software, que es parte importante en todas las
áreas de una empresa, debe tener capacidad de
desarrollarse y adaptarse rápidamente a estos
entornos cambiantes.
• Actualmente el desarrollo y la entrega rápida son por
lo general el requerimiento fundamental de los
sistemas de software.

Autor: Mauricio Galvez Legua ([email protected]) 29

 Metodologías Ágiles o incremental
• Actualmente, muchas empresas están dispuestas a
negociar en nivel de calidad del software y el
compromiso con los requerimientos, para obtener
con mayor rapidez la implementación que necesitan
del software.

Autor: Mauricio Galvez Legua ([email protected]) 30

 Metodologías Ágiles o incremental
• Debido a que las empresas operan en entornos
cambiantes, a menudo es prácticamente imposible
derivar un conjunto completo de requerimientos
para el desarrollo del software.
• Los procesos de desarrollo de software que buscan
especificar por completo los requerimientos y luego
diseñar, construir y probar el sistema, no están
orientados al desarrollo rápido de software.

Autor: Mauricio Galvez Legua ([email protected]) 31

 Metodologías Ágiles o incremental
• En las metodologías ágiles, el software no se
desarrolla como una sola unidad, sino como una serie
de incrementos (sprints), y cada uno de ellos incluye
nuevas funcionalidad del sistema.

Análisis y
Desarrollo o Pruebas o Despliegue y
definición de Diseño
Implementación Verificación Mantenimiento
requisitos

Autor: Mauricio Galvez Legua ([email protected]) 32

 Metodologías Ágiles o incremental
• Las metodologías ágiles se basan en ciclos de vida de
software incremental, donde rara vez se trabaja por
“adelantado” una solución completa del problema.

Autor: Mauricio Galvez Legua ([email protected]) 33

 Metodologías Ágiles o incremental
• Se avanza en una serie de pasos hacia una solución y
se retrocede cuando se detecta que se cometieron
errores o ante nuevos cambios por parte del usuario.
• Esto permite reducir los costos y facilita la realización
de cambios en el software conforme éste se va
desarrollando.

Autor: Mauricio Galvez Legua ([email protected]) 34

 Metodologías Ágiles o incremental
• Involucran a los clientes en el proceso de desarrollo
para lograr una rápida retroalimentación sobre los
requerimientos cambiantes.
La participación del cliente es fundamental.
• Minimizan la cantidad de documentación con el uso
de comunicaciones informales, en vez de reuniones
formales con documentos escritos.

Autor: Mauricio Galvez Legua ([email protected]) 35

 Metodologías Ágiles o incremental
• Las metodologías ágiles son más efectivas cuando el
sistema logra diseñarse con un pequeño equipo
asignado que se comunique de manera informal.

Autor: Mauricio Galvez Legua ([email protected]) 36

 Metodologías Ágiles o incremental
• Las metodologías ágiles proporcionan una visión más
dinámica que las metodologías tradicionales.
• Su característica principal es que permiten cambios
en los requisitos en cualquier fase del desarrollo; es
más, esos cambios son bienvenidos.

Autor: Mauricio Galvez Legua ([email protected]) 37

 Metodologías Ágiles o incremental
• La máxima prioridad es la satisfacción del cliente, por
lo cual se le debe estar entregando resultados
evaluables de forma continua con los que se va
midiendo el progreso del proyecto.
• Es importante que tanto el cliente, usuario y los
desarrolladores trabajen juntos durante el desarrollo
del proyecto, por lo que el cliente debe tener
disponibilidad para ello.

Autor: Mauricio Galvez Legua ([email protected]) 38

 Metodologías Ágiles o incremental
• La característica 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 ni las herramientas que emplean los
programadores, sino la calidad de los programadores.”
(Robert. L. Class).

Autor: Mauricio Galvez Legua ([email protected]) 39

 Metodologías Ágiles o incremental
• Podemos deducir que las metodologías ágiles a
diferencia de las metodologías tradicionales son más
adecuadas cuando el entorno presenta una cierta
incertidumbre o es cambiante.

Autor: Mauricio Galvez Legua ([email protected]) 40

 Metodologías Ágiles o incremental
• Los equipos de las metodologías ágiles deben auto-
organizarse entre ellos, reunirse y reflexionar
frecuentemente sobre cómo ser más eficaces y
mejorar la calidad técnica. En este sentido, el
compromiso del equipo de proyecto debe ser fuerte.

Autor: Mauricio Galvez Legua ([email protected]) 41

 Metodologías Ágiles o incremental:
características
• Rápida, específica y dinámica.
• Estimula las actitudes y estructuras del equipo, pues
hace más fácil la comunicación.
• Considera al cliente como parte del equipo de
desarrollo.
• Las entregas son rápidas y continuas.
• Su estructura se adecua al cambio.

Autor: Mauricio Galvez Legua ([email protected]) 42

 Metodologías Ágiles: ventajas
• La metodología ágil permite:
– Adaptarse rápidamente a los cambios inesperados.
– Centrarse en la satisfacción del cliente.
– Lograr una gran motivación intrínseca al centrarse en el
trabajo en equipo y la participación de los miembros.

Autor: Mauricio Galvez Legua ([email protected]) 43

 Metodologías Ágiles: desventajas
• Toda la flexibilidad inherente a la metodología ágil
puede:
– Aumentar la corrupción del alcance y el presupuesto del
proyecto de forma inesperada.
– Dificultar la interacción con los clientes si no se tiene el
tiempo o la disponibilidad necesaria.
– Hacer difícil a los equipos virtuales prosperar en entornos
ágiles.
– Al centrarse exclusivamente en el proceso de sprint, el
equipo no podrá trabajar en otros proyectos.

Autor: Mauricio Galvez Legua ([email protected]) 44

 Comparación entre Tradicional y Ágil

Sprint

Autor: Mauricio Galvez Legua ([email protected]) 45

 Comparación entre Tradicional y Ágil

Autor: Mauricio Galvez Legua ([email protected]) 46

 Comparación entre Tradicional y Ágil

Autor: Mauricio Galvez Legua ([email protected]) 47

 Tipos de Metodologías Ágiles
• Actualmente existen varios tipos de metodologías
ágiles como:
– Scrum
– XP o Programación extrema
– Kanban
– Etc.

Autor: Mauricio Galvez Legua ([email protected]) 48

 Metodologías Ágiles: Scrum
• Consiste en trabajar por iteraciones o también
llamados “sprints”, que suelen durar normalmente
una semana.
– Durante este periodo, se ejecutan las actividades
necesarias según el requerimiento planteado para esa
semana.
– Cada día se van teniendo reuniones donde comprobar lo
que se va haciendo y resolver los problemas que se
presenten.

Autor: Mauricio Galvez Legua ([email protected]) 49

 Metodologías Ágiles: Scrum
• Se trata de ir ajustando los resultados y
respondiendo a las exigencias reales y exactas del
cliente.

Autor: Mauricio Galvez Legua ([email protected]) 50

 Metodologías Ágiles: XP
• Esta metodología XP (Extreme Programming), se
caracteriza por brindar una flexible adaptabilidad a
cualquier modificación o cambios de los requisitos en
cualquier fase del proyecto, con la finalidad, de
ofrecer a los clientes “lo que quieren y cuando lo
quieren”.

Pensando bien,
lo que quiero es
un submarino !!!

Autor: Mauricio Galvez Legua ([email protected]) 51

 Metodologías Ágiles: XP
• Se aplica a proyectos muy complejos con un nivel
muy elevado de incertidumbre. El criterio abarca la
adaptación constante de los procesos hasta que
alcanzan el resultado deseado.
• Estos proyectos incluyen muchos cambios y es
normal que los equipos cambien de estrategias de
una semana a la siguiente.

Autor: Mauricio Galvez Legua ([email protected]) 52

 Metodologías Ágiles: XP
• Para aplicar la gestión extrema de proyectos hay que
tener una amplia flexibilidad. Es uno de los motivos
por el cual los sprints debe ser cortos, como máximo
durar unas pocas semanas.
• La metodología XP ofrece la posibilidad de realizar
cambios con mucha frecuencia, de abordar prácticas
de prueba y error para resolver problemas, y de
implementar muchas iteraciones para la
autocorrección.

Autor: Mauricio Galvez Legua ([email protected]) 53

 Metodologías Ágiles: XP
• El enfoque de la XP
mantiene como
fundamento cinco valores
principales: simplicidad,
comunicación,
retroalimentación,
valentía o coraje y
respeto.

Autor: Mauricio Galvez Legua ([email protected]) 54

 Metodologías Ágiles: XP
• El proceso de la XP se basa en cuatro actividades
estructurales principales: planeación, diseño,
codificación y pruebas.

Autor: Mauricio Galvez Legua ([email protected]) 55

 Metodologías Ágiles: Kanban
• Se centra en la planificación adaptativa, la entrega
temprana y la mejora continua.
• Su objetivo es gestionar de manera general cómo se
van completando las tareas en un proceso de
desarrollo de software.

Autor: Mauricio Galvez Legua ([email protected]) 56

 Metodologías Ágiles: Kanban
• Kanban es una palabra japonesa que significa
“tarjetas visuales” (Kan es “visual” y Ban “tarjeta”).

Autor: Mauricio Galvez Legua ([email protected]) 57

 Metodologías Ágiles: Kanban
• Se basa en una serie de principios que la diferencian
del resto de metodologías conocidas como ágiles:
– Calidad garantizada: Todo lo que se hace debe salir bien a
la primera, no hay margen de error. De aquí a que en
Kanban no se premie la rapidez, sino la calidad final de las
tareas realizadas. Esto se basa en el hecho que muchas
veces cuesta más arreglarlo que hacerlo bien a la primera.

Autor: Mauricio Galvez Legua ([email protected]) 58

 Metodologías Ágiles: Kanban
– Reducción del desperdicio: hacer solamente lo justo y
necesario, pero hacerlo bien. Esto supone la reducción de
todo aquello que es superficial o secundario (principio
YAGNI).
– Mejora continua: no es simplemente un método de
gestión, sino también un sistema de mejora en el
desarrollo de proyectos, según los objetivos a alcanzar.
– Flexibilidad: existen tareas pendientes acumuladas
(backlog), sin embargo es posible priorizar aquellas tareas
entrantes según las necesidades del momento (capacidad
de dar respuesta a tareas imprevistas).

Autor: Mauricio Galvez Legua ([email protected]) 59

 Punto comunes entre Scrum y Kanban
• Kanban y Scrum son las dos metodologías ágiles más
comunes. Entre sus “puntos comunes” citamos:
– Ambas motivan a los equipos a adoptar la mejora
continua.
– Ambas son excelentes herramientas de colaboración en
equipo. Propicia el trabajo en equipo.

Autor: Mauricio Galvez Legua ([email protected]) 60

 Diferencias entre Scrum y Kanban
• Scrum es más estricto que Kanban:
– Scrum incluye un conjunto específico de reglas que los
equipos deben seguir, mientras que Kanban se usa más
para visualizar el trabajo.
– Muchos equipos implementan Scrum con un tablero
Kanban, pero en esos casos, la metodología sigue siendo
Scrum, no Kanban.
– Kanban es más que una metodología estricta, es una forma
de visualizar el trabajo.

Autor: Mauricio Galvez Legua ([email protected]) 61

 Diferencias entre Scrum y Kanban
• Scrum es más restrictivo en tiempo, Kanban es más
flexible:
– Scrum se ejecuta en sprints, que suelen ser ciclos de
trabajo de una o dos semanas. Al final de un sprint, se
tiene un conjunto de tareas terminadas, sin importar
cuáles sean.
– Los tableros Kanban no necesariamente tienen una fecha
de inicio o finalización.

Autor: Mauricio Galvez Legua ([email protected]) 62

 Diferencias entre Scrum y Kanban
• Las columnas del tablero Kanban se pueden
organizar de diferentes formas:
– Cuando se implementa Scrum, es importante realizar un
seguimiento del trabajo a medida que se avanza por las
diferentes etapas. Sin embargo, en un tablero Kanban que
no se basa en Scrum, las columnas pueden representar
diferentes aspectos de un proyecto como por ejemplo, el
trabajo que se realizará cada mes, las tareas que se
completaron anteriormente, o cualquier otra cosa que se
necesite.

Autor: Mauricio Galvez Legua ([email protected]) 63

 Comparación entre Scrum y Kanban

Autor: Mauricio Galvez Legua ([email protected]) 64

 Combinación Scrum y Kanban
• Para organizar reuniones de actualización diarias
eficaces, planificar sprints y realizar análisis
retrospectivo relevantes, se requiere de un medio
para visualizar el trabajo a través de las diferentes
etapas y para realizar un seguimiento de todo el
trabajo en curso.
– Los tableros Kanban pueden ayudar a abordar el trabajo
pendiente de los sprints y organizar el flujo de trabajo
durante un sprint.

Autor: Mauricio Galvez Legua ([email protected]) 65

 Combinación Scrum y Kanban
• Los equipos que implementan Scrum en tableros
Kanban (a veces denominados tableros Scrum),
suelen crear un tablero nuevo para cada sprint por
dos razones principales:
– Con un nuevo tablero Kanban se puede comenzar “desde
cero”. Esto hace que sea más fácil visualizar el trabajo
nuevo que se debe completarse en cada sprint.
– Seguimiento al trabajo realizado durante cada sprint para
visualizar qué se ha logrado.

Autor: Mauricio Galvez Legua ([email protected]) 66

 Comparación entre Waterfall, Scrum y
Kanban

Autor: Mauricio Galvez Legua ([email protected]) 67

 Metodologías Híbridas
• El éxito de las metodologías ágiles condujo a cierta
integración con las metodologías tradicionales de
desarrollo, basados en el modelado de sistemas.
Ejemplo:
– RUP (Rational Unified Process) o Proceso Racional
Unificado.
• Otra metodología híbrida es Scrumban, la cual es el
combinación de Scrum y Kanban.

Autor: Mauricio Galvez Legua ([email protected]) 68

 Fin !!!

Autor: Mg. Mauricio Galvez Legua

([email protected])

Autor: Mauricio Galvez Legua ([email protected]) 69