Metodologías de

Implementación
Curso: Sistemas de Información
Profesor: Gonzalo Valdés, PhD

Escuela de Ingeniería
Métodos Tradicionales
Modelo en Cascada
ANÁLISIS DE
REQUERIMIENTOS
• W. Royce, 1970
• Es el más antiguo DISEÑO DEL
SISTEMA

• También llamado clásico y DISEÑO DE

secuencial PROGRAMAS

• Debe completarse un estado antes

de comenzar el siguiente CODIFICACIÓN

• Asume secuencialidad, requiere TESTING UNITARIO

establecimiento explícito de E INTEGRADO
requerimientos desde el comienzo, Este es el momento en que el
y exige al cliente/usuario gran TESTING DEL
SISTEMA
usuario recibe el valor,
producto del uso del
paciencia software generado en el
• Es útil para que el desarrollador TESTING DE
ACEPTACIÓN
proyecto

visualice lo que va a hacer

• Muy usado pero pierde terreno OPERACIÓN Y
MANTENCIÓN

3
Modelo en Cascada
• Requisitos – Determinación exhaustiva y detallada de los
requerimientos
• Diseño – Diseño en detalle de la solución. Cada requerimiento debe
tener al menos un elemento de diseño que lo satisface
• Codificación – Implementación (“nos encerramos”) hasta que cada
elemento de diseño quede implementado
• Testing – Pruebas de verificación, validación, etc.
• Operación – Despliegue y puesta en producción
• Mantenimiento – Cambios correctivos o evolutivos a la solución
implementada

4
Modelo en Cascada
• Se asocian hitos y entregables con cada actividad. P. ej.: al final de “testing
unitario e integrado” está el hito “módulos de código escritos, testeados e
integrados, listo para pasar a pruebas de sistema …”
• Fácil ver el avance del proyecto a través del modelo

• Críticas
• Su principal problema es que no refleja la realidad
• Proyectos raramente siguen el flujo secuencial (excepto que se conozca muy bien el
problema)
• Dificultad para establecer los requerimientos al principio del proceso
• Errores detectados tardíamente
• Mantenimiento por “parchado” (corregir según se presenten los problemas)
5
… en la realidad
ANÁLISIS DE
• Si no hay control puede REQUERIMIENTOS

ocurrir que …
OPERACIÓN Y DISEÑO DEL
MANTENCIÓN SISTEMA

TESTING DE DISEÑO DE
ACEPTACIÓN PROGRAMAS

TESTING DEL
CODIFICACIÓN
SISTEMA

TESTING UNITARIO
E INTEGRADO

6
Verificación, Validación y Retrabajo
• Verificación
• Se preocupa de que el sistema trabaje correctamente
• ¿Estamos construyendo el producto correctamente?
• Validación
• Se preocupa de que el sistema cumpla con los requerimientos
• ¿Estamos construyendo el producto correcto?
• Retrabajo (Rework)
• Trabajo realizado para corregir defectos
• … “hacer el trabajo de nuevo porque no los hicimos bien al principio”

7
Modelo V
• Alemania, 1992
• Variación del modelo en cascada OPERACIÓN Y
• Muestra como el testing se MANTENCIÓN
relaciona con análisis y diseño ANÁLISIS DE
Validar
requerimientos TESTING DE
• El “ángulo” es la codificación REQUERIMIENTOS ACEPTACIÓN

• Los sucesivos testings proceden DISEÑO DEL TESTING DEL

como contraparte de las SISTEMA Verificar SISTEMA

actividades de desarrollo DISEÑO DE

Diseño
TESTING UNITARIO
• Se forman “ciclos” desarrollo- PROGRAMAS E INTEGRADO

V&V-desarrollo
CODIFICACIÓN
• Explicita V&V, iteraciones y
rework

8
Métodos Ágiles
Motivación
• Interés creciente en los métodos ágiles (inicialmente llamados ligeros,
lightweight)
• Enfrentamiento de requerimientos cambiantes
• Tiempos de desarrollo escasos
• Clientes y usuarios cada vez más exigentes

• Caracterizados alternativamente como

• Antídoto a la burocracia de los métodos planificados (pesados, heavyweight)

• Cuidado con el uso de la palabra “ágil”

• Lo opuesto de “ágil” es “planificado”
• No “no-ágil”
• Lo opuesto de “planificado” es “ágil”
• No “in-disciplinado”, porque los métodos ágiles exigen mucha disciplina
10
Motivación
• Fundamentos
• La metodología en cascada funciona en ambientes y requerimientos
conocidos al detalle
• Cuando hay incertidumbre, los requerimientos son débiles, el diseño precario
y el fracaso grande y costoso

• Mínimo viable y feedback temprano

• La clave es construir las soluciones más pequeñas posibles que sean de valor
para los usuarios, disponibilizarlas y así recibir feedback temprano
directamente de ellos

11
Motivación
• Agilidad:
• Facilidad de un método de desarrollo de software para abordar cambios
• Cambios de requerimientos, tecnología, contexto del sistema

• Algunas características de los métodos ágiles

• Documentación mínima
• Ciclos iterativos breves
• Reacción rápida ante los cambios
• Estrecha relación con el cliente
• Diseño simple
• Satisfacción de necesidades inmediatas
• Foco en las personas
• Organización libre
• Procesos adaptables, no predictivos
12
 Agile Manifesto
• Valoramos:
• Individuos e interacciones sobre procesos y herramientas
• Software funcionando sobre documentación exhaustiva
• Colaboración con los clientes sobre negociación de contratos
• Responder a los cambios sobre seguir un plan

• Es decir, aunque hay valor en los ítems de la derecha, valoramos más los ítems de
la izquierda

Ref.: “Manifesto for Agile Software Development” (2001). http://agilemanifesto.org/

13
Formar un Equipo Ágil
• Auto-organización
• Alejarse de las formas mecánicas de organización de flujos de trabajo para que los equipos
exploten soluciones creativas que satisfagan mejor las necesidades de los clientes

• Ambiente de Trabajo Creativo

• Para soportar dicho ambiente, se debe fomentar la comunicación, la colaboración y el trabajo
de equipo

• Los Equipos se forman con Individuos

• Cada individuo necesita aprender como ir más allá de los confines de su “zona de seguridad”.
Esto requiere práctica y un ambiente que los soporte

• Confianza
• Los equipos necesitan sentir que se les da “poder”, seguridad y confianza. Necesitan ser
capaces de tomar riesgos y fallar
14
 Diseño Emergente
• Entrega piezas completas del sistema en intervalos
regulares
• Itera sobre la robustez
• Pruebas tempranas y frecuentes
• Arquitectura y diseño son tan importantes que deben
ocurrir todo el tiempo
• “El mejor diseño emerge de construir continuamente la
solución más simple para los requerimientos abordados
en cada iteración, reestructurando el diseño cuando la
implementación de nuevos requerimientos así lo
requiera”
• La evolución del diseño se produce a través de una
reorganización continua de la estructura del producto,
conocida como Refactoring
• Incorporar la complejidad estructural sólo a medida que
vaya siendo necesario
• Facilitar los cambios que puedan ocurrir durante el
desarrollo
• La organización de las unidades de construcción de
software va emergiendo en la medida que se va
avanzando en el desarrollo, lo que se contrapone con el
enfoque tradicional de diseño, que propone planear el
diseño de software antes de la construcción.. 15
Diseño Emergente vs. Diseño planificado (Up-front)

16
Scrum
• Framework simple que puede ser implementado en unos pocos días
• Enfoque para manejar problemas complejos
• Ambiente para soportar auto-organización, creatividad y emergencia
• Esfuerzo colaborativo que involucra implementadores y clientes en un
dialogo constante

• Conceptos claves
• Proceso Empírico
• Planificación detallada por anticipado y procesos definidos son reemplazados por ciclos “just-
in-time” de revisión y adaptación
• Auto-organización
• El equipo se autogestiona y organiza alrededor de metas, tomando en cuenta restricciones
claramente establecidas

17
El Framework Scrum

Retrospective
&
Impediment
Backlog

Sprint
Estimation Planning
Review
Meeting Meeting

18
El Framework Scrum

19
Roles de Scrum
• Product Owner (Dueño del Producto)
• Gestiona la Visión y los Requerimientos
• Es el responsable de construir y difundir la visión del producto, mejorar el ROI,
conciliar las expectativas del cliente y de los stakeholders, trazar el rumbo a seguir y
planificar las entregas, coordinar y priorizar el Product Backlog, proveer
requerimientos claros y testeables al Team, colaborar con el cliente y con el Team
para asegurar que se cumplan las metas y para aceptar el software al final de cada
iteración
• Puede ser un analista que escribe los requerimientos

• Scrum Master (Facilitador)

• Gestiona el Proceso
• Líder Servidor del Equipo
• Es responsable de guiar al Team, crear un ambiente de confianza, facilitar las
reuniones del Team, hacer las preguntas difíciles, remover impedimentos, hacer
visibles los problemas, mantener al proceso avanzando, sociabilizar Scrum y Agile
con el resto de la organización, educar a Clientes y otros Stakeholders

20
Roles de Scrum
• The Team (El Equipo)
• Se gestiona así mismo
• Se maneja desde una perspectiva táctica. Es responsable por estimar el
tamaño de los ítems del Product Backlog, tomar decisiones de diseño e
implementación, y comprometerse a entregar incrementos de software
• Sigue su propio progreso (con ayuda del Scrum Master). Es autónomo y auto-
organizado, pero debe responder ante el Product Owner para entregar lo
prometido

21
Reuniones de Scrum
• Estimation Meeting (Reunión de estimación)
• El Team se reúne con el Product Owner para discutir sobre los ítems del Backlog y asignarle
un tamaño a cada uno. Esto ocurre por primera vez antes de que comience el desarrollo y
luego iterativamente al inicio de cada Sprint.
• Planning Meeting (Reunión de planificación)
• Ocurre al comienzo de cada Sprint. El Team y el Product Owner negocian el Sprint. La
planificación puede ser basada en compromisos o en velocidad
• Daily Scrum (Scrum Diario)
• Todos los días. Máximo 15 minutos. El equipo se reúne para reportar a los demás miembros
el progreso, intenciones e impedimentos y actualizar el task board
• Review (Revisión)
• Inspeccionar y adaptar el producto. El Team se reúne con el Product Owner al final de cada
Sprint para hacer una demostración del software que se ha desarrollado en el Sprint
• Retrospective (Retrospectiva)
• Inspeccionar y adaptar el proceso. El Team se reúne con el Scrum Master para discutir qué
cosas anduvieron bien y cuáles pueden ser mejoradas

22
Artefactos de Scrum
• Product Backlog (Trabajo por hacer del producto)
• Lista priorizada de todos los requerimientos conocidos acerca del producto
• Cada requerimiento se denomina Product Backlog Item (PBI)
• Representa el Qué del proyecto
• Siempre fluyendo; sufre de re-priorizaciones según las necesidades del cliente
• Committed Backlog (aka Sprint Backlog)
• El subconjunto del Product Backlog que el Team se ha comprometido a desarrollar para el
siguiente Sprint
• Es fijo
• Los PBIs comprometidos son descompuestos en tareas: el Cómo
• Impediment List (Lista de impedimentos)
• Lista priorizada de todos los impedimentos al proceso de desarrollo
• Dividida en secciones Organizacional y Team
• Product Increment (Incrementos del producto)
• El software terminado y entregado al final de cada Sprint
• Aceptado o rechazado por el Product Owner y los stakeholders

23
Kanban
• Metodología de proceso mucho más simple que las anteriores, que se
basa en la ges�ón visual de los elementos a ser trabajados, y cuya
única limitante está en la cantidad de elementos que pueden ser
trabajados en paralelo. En este caso, cada necesidad a ser abordada
tiene un ciclo de vida independiente de las demás

• La ges�ón visual se hace a través de un tablero Kanban

24
 Kanban

Tareas por hacer.

WIP: Work In Progress (3),

máximo recomendado, 3.

25
Gestión de Proyectos Ágil (Scrum)

26
Gestión de Proyectos Ágil (Scrum) - Estimaciones

• Primero Crear el Product Backlog

• Cuando un proyecto se inicia no es necesario que sea exhaustivo
• Típicamente al principio se escribe todo lo obvio, lo que suele ser más que suficiente para un primer
Sprint
• Los PBIs (Product Backlog Items) pueden ser:
• User stories, casos de uso, requerimientos (funcionales, técnicos, etc.), y/o complementos entre estos

• Técnicas para reunir PBI’s

• Cuestionarios, observación, entrevistas, etc.

• Si se usan user stories, entonces se estima con story points

• Basado en una combinación de complejidad y tamaño
• La escala la decide el Team (e.g., 1 a 10), es una estimación relativa
• Se hace mediante votaciones iterativas de los miembros del Team hasta converger

27
Gestión de Proyectos Ágil (Scrum) - Estimaciones
 Estimaciones del
Product Backlog

28
Gestión de Proyectos Ágil (Scrum) -
Planificación Basada en Compromisos
• El Product Backlog es constantemente re-priorizado por el Product Owner (PO) según las
necesidades del cliente
• Dichas transformaciones son explicadas por el PO al Team durante la Planning Meeting del Sprint
• Durante la Planning Meeting el Team selecciona los PBI’s que puede terminar durante el Sprint
que viene (se compromete)
• Cada PBI se descompone en múltiples tareas para el Sprint, la estimación de dichas tareas y su
asignación es hecha por el Team
• Task Board
• Muestra todo el trabajo que se está haciendo durante un Sprint
• Se actualiza diariamente en el Daily Scrum
• Las tareas se ubican en la columna To Do
• Típicamente se incluyen columnas In Progress (trabajo que se está realizando) y Done (trabajo ya
terminado)

29
Gestión de Proyectos Ágil (Scrum) -
Planificación y Seguimiento
 Task Boards para Sprints

30
Gestión de Proyectos Ágil (Scrum) -
Planificación y Seguimiento
 Burndown Charts para un Sprint
Task Burndown

60

50
40
Nº Tasks

real
30
ideal
20

10
0
1 2 3 4 5 6 7 8 9 10
Days
Story Burndown

8
7
6
Nº Stories
5
4
3
2
1
0
1 2 3 4 5 6 7
Days

31
Gestión de Proyectos Ágil (Scrum) -
Planificación y Seguimiento
• Burndown del Proyecto
 Altura representa el
trabajo pendiente al
inicio de cada Sprint

 Velocity Graph
Velocity

80
70
60

Story points
 Su información 50
Real
40
puede usarse como 30
Ideal
alternativa a la 20
planificación basada 10
en compromisos 0
1 2 3 4 5 6 7 8
para equipos
Sprint
experimentados

32
Actividad – 1 décima Tarea 1
• En equipos de 5 personas
• Describa 2 ejemplos de implementación de sistemas de información donde
usaría una metodología tradicional, y 2 donde usaría una metodología ágil
• Algunas variables a considerar: tipo de cliente, tipo de empleados en su organización
(la que implementará el SI), tecnología a usar, complejidad del SI, tipos de
datos/información a procesar, ambigüedad o certeza en los requerimientos, etc.

• Enviar a:
• iic2713seccion1@gmail.com
• Asunto: [SI Sección 1] Tradicional vs. Ágil
• Cuerpo
• Integrantes
• Respuesta

• Recuerde anotar los nombres de sus compañer@s apenas se inicie su

breakout session!
33