ESTILOS ARQUITECTÓNICOS, MODELOS DE REFERENCIA Y FRAMEWORKS

Diseño y arquitectura de software Carrera de Software
Ph.D. Franklin Parrales 1
13/05/2021
ESTILOS
ARQUITECTÓNICOS,
MODELOS DE REFERENCIA Y
FRAMEWORKS
Unidad 2B
Material docente compilado por el profesor Ph.D. Franklin Parrales Bravo
para uso de los cursos de Diseño y Arquitectura de Software

13/05/2021
Objetivo general de la Unidad 2
Diseñar modelos arquitectónicos orientados a servicios
mediante el estableciendo de un marco estructural básico
para identificar los principales componentes del sistema y
la comunicación entre cada uno de ellos.

13/05/2021
Unidad 2: Estilos arquitectónicos, modelos
de referencia y frameworks
• Estilos arquitectónicos, modelos, y frameworks.
– Arquitectura en capas y orientada a objetos.
– Arquitectura para redes, móviles, y sistemas
embebidos.
– Arquitecturas orientadas a servicios.
– Arquitecturas para la solución de problemas.
• Metodologías para el diseño del software.
– Metodologías clásicas.
– Metodologías ágiles.
– Diferencias entre Metodología Tradicionales y Ágiles.
Unidad 2B

13/05/2021
• Estilos arquitectónicos, modelos, y frameworks.
embebidos.

13/05/2021
Ciclo de Vida del Software
• Consiste en determinar:
– las fases productivas de un proyecto,
– los objetivos de cada fase productiva, y
– los productos obtenidos en cada una de estas
fases así como sus características.

13/05/2021
Ciclos de Vida del Software
• Se han propuesto muchos ciclos de vida para
el desarrollo del software, pero estos son los
más representativos:
– Poner la cola al burro.
– Ciclo de vida clásico o en cascada.
– Construcción rápida de Prototipos Desechables
– Incremental
– Evolución de prototipos
– Reutilización de Software
– Síntesis automática de software
– En espiral.

13/05/2021
Poner la cola al burro
• Se coge a uno o varios
informáticos,
• Se les muestra más o
menos el problema,
• Se les deja solos en un
cuarto a oscuras,
• Transcurrido un tiempo
se abre la puerta.

13/05/2021
Lo sorprendente es que a veces funciona
• Las empresas que desean obtener software económico y
rápidamente lo utilizan, con las siguientes mejoras:
– Se contrata a personas que no tengan experiencia
– Se les dan pocos recursos, son novatos y no saben exigir
– Se suele utilizar la técnica de desprecio:
• “siempre tarde y encima no hace lo que queremos”
» (imaginábamos qué haría, aunque no lo habíamos dicho)
• Los resultados son curiosos:
– Se suele subcontratar a cualquier precio con empresas
externas, “Seguro que ellos saben hacer las cosas”
• Cuando funciona existe mucha incertidumbre sobre el como o
por que ha funcionado.
– Parece claro que cuando funciona, los informáticos sabían que se
esperaba del producto, sabían que se debía hacer, estaban muy
motivados y les gusta el trabajo que están haciendo. Pero es difícil
prever que esto ocurrirá.

13/05/2021
• Modelos arquitectónicos, modelos, y frameworks.
embebidos.

13/05/2021
¿Qué es el proceso del software?
• Metodología seguida por una organización
para el desarrollo del software
• Esta metodología incluye todas las fases
del ciclo de vida clásico
• Este proceso se define de manera general
para todas las aplicaciones de una
organización
• Igualmente se definen tareas especificas a
cada aplicación en particular

13/05/2021
¿Qué es un proceso de desarrollo de software?
Define
• Quién va a hacer qué
• Cuándo hacerlo, y
• Cómo alcanzar un objetivo determinado
Proceso de desarrollo de software
Requisitos nuevos o modificados
Sistema nuevo o modificado

13/05/2021
Características de un proceso de
desarrollo de software
• Proporciona pautas para el
desarrollo eficiente de
software de calidad.
• Reduce el riesgo y aumenta la
previsibilidad
• Promueve una visión y una
cultura comunes
• Presenta las mejores
prácticas actuales

13/05/2021
El proceso del software
Marco de trabajo común
Actividades del marco de trabajo
Conjunto de tareas
Hitos, entregas
Tareas
Puntos SQA

13/05/2021
El proceso del software
• Marco de Trabajo Común es el entorno para la definición de un
grupo de actividades aplicables a todos los proyectos de software
independientemente de su tamaño y complejidad.
• Actividades de Protección van enfocadas a garantizar la calidad del
software. Se aplican durante todo el proceso y son independientes
del marco de trabajo y de las tareas que lo constituyen.
• Conjunto de Tareas se refiere a actividades de la Ingeniería de
Software que hacen que el marco de trabajo se adapte a las
características particulares de cada proyecto de software. En este
conjunto se definen tareas, hitos que son señales que se colocan en
un momento específico del proceso y que coinciden con la entrega
de un resultado concreto y los puntos SQA (Software Quality
Assurance o Aseguramiento de la Calidad del Software).
• Un aspecto muy importante del proceso de desarrollo de software
es la madurez que se alcanza en términos de estándares y de
métodos definidos para la construcción de software.
– Para determinar la madurez de las prácticas de ingeniería de software
de una organización, el Software Engineering Institute (SEI) define
cinco niveles de madurez del proceso y las actividades que se deben
llevar a cabo para alcanzarlos.

13/05/2021
Madurez del proceso en la
organización de desarrollo
• La misma industria, diferentes niveles de
madurez.

13/05/2021
Madurez del proceso en la
organización de desarrollo
• Hay factores que no quedan claramente
reflejados en el ciclo de vida ni en las
técnicas de desarrollo.
• Los factores no estudiados son:
– El cumplimiento de los plazos de entrega.
– La calidad (número de errores en el
Software).
– El coste del proyecto.

13/05/2021
CMM (Capability Maturity Model)
• Proporciona una Guía sobre como
– controlar los procesos:
• de desarrollo del software.
• de mantenimiento.
– Hacer evolucionar hacia una cultura de:
• Ingeniería del software.
• Gestión eficiente.

13/05/2021
Inicial
Repetible
Optimización
Gestionado
Definido
Control
Básico
Definición
del
Proceso
Medición
del
Proceso
Control
del
Proceso
Evolución de las organizaciones según
el CMM

13/05/2021
Nivel Inicial.
• Según las circunstancias utilizamos un
proceso distinto. (algunos caóticos)
• A medida,
• Poco formalizado,
• Uso de herramientas informales.
• Pocos procesos definidos.
• El éxito depende del esfuerzo individual.

13/05/2021
Nivel de Repetición.
• Se tiene procesos estables de desarrollo,
con control estadístico.
• Uso de datos históricos
• Establecimiento de procesos de gestión
de proyecto, para hacer seguimiento de:
– Coste.
– Planificación.
– Funcionalidad.

13/05/2021
Nivel de Definición.
• Proceso de desarrollo perfectamente
definido y estandarizado.
• Integrado en la organización.
• Bien documentado.
• Todos los proyectos utilizan una versión
documentada y aprobada de proceso.

13/05/2021
Nivel de Gestión.
• Mejoras de calidad sustanciales.
• Control cuantitativo de productos y
proceso a través de
– Mediciones del proceso comprensibles.
– Mediciones de la calidad

13/05/2021
Nivel de Optimización.
• A través de mediciones del proceso
utilizando ideas y tecnologías innovadoras
obtenemos:
– Mejoras en calidad y cantidad.

13/05/2021
Modelos del proceso del software
LINEALES
• Modelo Lineal o en Cascada
INCREMENTALES
• Modelo Incremental
• Modelo de desarrollo rápido de aplicaciones
(DRA)
EVOLUTIVOS
• Modelo de Construcción de Prototipos
• Modelo Espiral
RUP

13/05/2021
Modelo lineal secuencial
o Cascada
• Desarrollado entre 1960-1980
• Basado en el modelo en cascada de
Winston Royce
• Se conoce como el ciclo de vida básico
• Secuencia de actividades, donde la
estrategia principal es seguir el progreso
del desarrollo de software hacia puntos de
revisión bien definidos mediante entregas
calendarizadas.

13/05/2021
o en cascada
Definición
Análisis
Diseño
Desarrollo
Pruebas
Mantenim.
Definición de requisitos:
• Las restricciones y metas del sistema se definen a partir de la
interacción con el interesado.
• Se comprende la naturaleza de la aplicación y el dominio de
información, así como su funcionalidad, rendimiento e interconexión
• Se reúnen todos los requisitos que debe cumplir el software

13/05/2021
Definición
Análisis
Diseño
Desarrollo
Pruebas
Mantenim.
Se concentra en cuatro características básicas:
Estructura de datos
Arquitectura del software
Representaciones de interfaz
Detalle procedimental (algoritmo)
o en cascada

13/05/2021
o en cascada
Definición
Análisis
Diseño
Desarrollo
Pruebas
Mantenim.
• Se llama también Implementación
• Generación de código entendible por la máquina
• Actualmente se investiga mucho sobre la manera
de generar código automáticamente

13/05/2021
o en cascada
Definición
Análisis
Diseño
Desarrollo
Pruebas
Mantenim.
• Proceso de depuración de programas
• Chequear la validez de las sentencias
• Pruebas para detectar errores, asegurando que a
partir de los datos de entrada si se genere la salida
deseada

13/05/2021
o en cascada
Definición
Análisis
Diseño
Desarrollo
Pruebas
Mantenim.
• Corrección de errores no detectados en la etapa de
pruebas
• Posibles mejoras funcionales debidas a nuevos
requerimientos del cliente
• En esta fase se vuelven a aplicar todas las etapas
anteriores sobre el software existente

13/05/2021
o en cascada
Definición
Análisis
Diseño
Desarrollo
Pruebas
Mantenim.
LIMITACIONES
• En la realidad no estrictamente secuencial (se traslapan las
etapas)
• El interesado debería exponer los requisitos en la etapa
inicial, pero en realidad él lo hace a través de todo el
proceso y esto complica las cosas
• La primera versión del software llega al final del proceso, a
veces el afán del cliente hace que la aplicación final no
cumpla con los requerimientos

13/05/2021
Modelos Waterfall y “V” en la Práctica
Análisis y
Definición de los
Requerimientos
Diseño de la
Arquitectura del
Sistema
Diseño Detallado
Implementación
Integración y
Verificación
Instalación,
Operación y
Mantenimiento
Corregir
fallas
Corregir
fallas
Corregir
fallas
Corregir
fallas
Corregir
fallas
Corregir
fallas
Corregir
fallas
Corregir
fallas
Corregir
fallas
Corregir
fallas
Corregir
fallas
Cambiar un
requerimiento
Cambiar un
requerimiento
Cambiar un
requerimiento
Se acumulan correcciones hacia el final,
con la consiguiente incertidumbre
(ej., no se tiene certeza sobre cuánto
falta hacer, porque no se sabe
cuánto van a demandar
los bloques azules)

13/05/2021
LINEALES
INCREMENTALES
(DRA)
EVOLUTIVOS
• Modelo Espiral
RUP

13/05/2021
Modelo Incremental
• Aplica el enfoque lineal secuencial
escalonadamente
• Incrementos parciales de la herramienta completa
(versiones)
• Cada incremento agrega funcionalidad adicional o
mejorada sobre el sistema
• Cada etapa debe cumplir con los requisitos de las
desarrolladas
Incremento 2
Incremento n
... ... ... ...
Análisis Diseño Código Pruebas
Incremento 1

13/05/2021
Modelo Incremental
• Ventajas:
– Los clientes no tienen que esperar hasta que el sistema se
entregue completamente para comenzar a hacer uso de él.
– Los clientes pueden usar los incrementos iniciales como
prototipo para precisar los requerimientos posteriores del
sistema.
– Minimización del riesgo de falla en el proyecto porque los
errores se van corrigiendo progresivamente.
• Problemas:
– Adaptación de los requisitos del cliente para lograr
incrementos pequeños (no mas de 20.000 líneas de
código) que añadan funcionalidad al sistema.
• Nota: Una evolución de este enfoque se conoce como
Programación Extrema (XP-Extreme Programming).

13/05/2021
LINEALES
INCREMENTALES
(DRA)
EVOLUTIVOS
• Modelo Espiral
RUP

13/05/2021
Modelo de Desarrollo Rápido
de Aplicaciones (DRA)
• Basado en el Modelo Lineal Secuencial
• Modelo llevado a cabo por varias equipos de trabajo
que siguen las etapas del proceso de manera
simultanea.
• Modelo aplicable a la construcción de sistemas de
información fácilmente modularizables.
• El Modelo DRA necesita clientes y desarrolladores
comprometidos con el proceso.
• No es muy útil para aplicaciones que requieren
adopción de nuevas tecnologías porque la curva de
aprendizaje puede afectar el cronograma del proyecto.

13/05/2021
Modelo de Desarrollo Rápido de
Aplicaciones (DRA)

13/05/2021
LINEALES
INCREMENTALES
(DRA)
EVOLUTIVOS
• Modelo Espiral
RUP

13/05/2021
Modelo de Construcción de
Prototipos
Comienza con una recolección inicial de requisitos
para pasar a un diseño rápido y finalmente a la
construcción de un prototipo de la solución.

13/05/2021
Modelo de Construcción de
Prototipos
El desarrollador y el cliente deben ser concientes de que
el prototipo se utiliza para precisar los requisitos del
software y así evitar inconvenientes como:
– El cliente cree que el prototipo es una primera versión
funcional del Sistema.
– El desarrollador construye el prototipo rápidamente y
en ocasiones sin hacer uso de la tecnología optima
disponible.

13/05/2021
LINEALES
INCREMENTALES
(DRA)
EVOLUTIVOS
• Modelo Espiral
RUP

13/05/2021
Modelo Espiral
• Utilización de ciclos en lugar de sucesión de
actividades.
• Facilita el desarrollo rápido de versiones
incrementales de software.

13/05/2021
Modelo Espiral
• Una de las principales ventajas de este modelo de desarrollo
es que considera directamente los riesgos técnicos en
todas las etapas del proyecto, reduciéndolos antes de que se
conviertan en problemáticos. Además, este modelo puede
adaptarse y aplicarse a lo largo de la vida del software.
• Los procesos que se llevan a cabo dentro de un modelo en
espiral son los siguientes:
– Comunicación con el cliente : Tareas para dinamizar la
interacción desarrollador – cliente.
– Planificación : Definición de recursos, tiempo y otra información
relacionada con el proyecto.
– Análisis de Riesgos : Evaluación de riesgos técnicos y de gestión.
– Ingeniería : Construcción de una o más representaciones de la
aplicación.
– Construcción y Adaptación : Tareas de construcción, pruebas e
instalación de la aplicación.
– Evaluación del Cliente : Reacción del cliente frente a la aplicación
obtenida a partir de la fase de ingeniería y de construcción.

13/05/2021
LINEALES
INCREMENTALES
(DRA)
EVOLUTIVOS
• Modelo Espiral
RUP

13/05/2021
Rational Unified Process (RUP)
• RUP es un proceso de desarrollo de software 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
• RUP tiene 3 características importantes:
– Es un proceso dirigido por Casos de Uso (CU)
– Es un proceso Centrado en la Arquitectura
– Es un proceso Iterativo e Incremental

13/05/2021
¿Qué propone Rational Unified Process (RUP)?
• Indica
– Actividades
– Roles
– Workflow
– Artefactos
QUÉ tareas hacer
QUIÉN las hace
CUÁNDO se hace
QUÉ documentos entregar

13/05/2021
Rational Unified Process (RUP). Etapas

13/05/2021
Concepción Elaboración Construcción Transición
Iteraciones Iter #1 #2 Iter #3 #4 #5 #6 Iter #7 #8
RUP: descripción general
Fases
Disciplinas
Requerimientos
Análisis
Diseño y
Arquitectura
Implementación
Test

13/05/2021
Fases del RUP
• Concepción (inception)
– Establecer una visión y alcance empresarial
– Identificar la funcionalidad básica
• Elaboración
– Establecer requisitos de detalle y visión técnica
– Realizar análisis y diseño de alto nivel
– Identificar riesgos y crear un plan de desarrollo
• Construcción
– Crear iteraciones de software de calidad de
producción, probado e integrado
• Transición
– Prueba beta y capacita a los usuarios sobre el terreno
– Identificar y corregir deficiencias
• Todas las disciplinas se aplican en todas las fases.
– Requisitos, análisis, diseño, implementación,
prueba

13/05/2021
RUP: Organización de Modelos
▪ M. de Casos de Uso del Negocio (Business Use-
Case Model)
▪ M. de Objetos del Negocio (Business Object Model)
▪ M. de Casos de Uso (Use-Case Model)
▪ M. de Análisis (Analysis Model)
▪ M. de Diseño (Design Model)
▪ M. de Despliegue (Deployment Model)
▪ M. de Datos (Data Model)
▪ M. de Implementación (Implementation Model)
▪ M. de Pruebas (Test Model)

13/05/2021
Modelado de software
Construcción de Software
Ingeniería de requerimientos
Diseño
y
Arquitectura
de
Software

13/05/2021
Modelado de software
Modelo de
Casos de Uso
Modelo de
Análisis
Modelo de
Diseño
Modelo de
Despliegue
Modelo de
Implementación
Modelo de
Prueba
especificado por realizado por
distribuido por
implementado por
verificado por
Transición del MCU hacia el
MA

13/05/2021
embebidos.

13/05/2021
Métodos Ágiles
• Surgen como una reacción frente a las
metodologías tradicionales
– Frente a la idea de que el desarrollo de
software es consistente, fiable, predecible y
medible
– Aceptar que no siempre es así y encontrar la
mejor manera de aceptar los cambios
• No proponen nuevas técnicas, sólo una
forma distinta de afrontar el desarrollo de
software

13/05/2021
Manifiesto Ágil
• Firmado por los principales críticos de las
metodologías tradicionales (y creadores de
algunos de los métodos ágiles más populares)
• 4 valores básicos:
– Individuos y su interacción frente a procesos y
herramientas
– Software que funciona frente a documentación
exhaustiva
– Colaboración con el cliente frente a contratos
– Respuesta al cambio frente a seguimiento de un plan

13/05/2021
Manifiesto Ágil: 12 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.
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 para a continuación
ajustar y perfeccionar su comportamiento en consecuencia.

13/05/2021
Prácticas Básicas en Métodos Ágiles
(Cockburn)
• Entre 2 y 8 personas trabajando juntas
– Comunicación y comunidad
• Usuarios expertos junto al equipo de desarrollo
– Realimentación continua
• Iteraciones cortas
– Tres meses como mucho, para favorecer pruebas y
depuración
• Pruebas automáticas
– Las pruebas unitarias y funcionales estabilizan el
código y permiten mejorarlo
• Desarrolladores expertos
– Mejora la velocidad de desarrollo entre 2 y 10 veces

13/05/2021
Métodos ágiles más utilizados
• eXtreme Programming (XP)
• Scrum
• Crystal
• Lean Development
• Kanban
• Feature Driven Development
• Dynamic Systems Development Method
• Adaptive Software Development
• Pragmatic Programming
• RUP?

13/05/2021
eXtreme Programming (Beck)
• El más popular de los métodos ágiles
• Versiones con incrementos muy pequeños
• Evolución constante del código
• 5 valores:
– Simplicidad
– Comunicación
– Retroalimentación
– Coraje
– Respeto

13/05/2021
eXtreme Programming
• Simplicidad
– Se simplifica el diseño para agilizar el desarrollo
y facilitar el mantenimiento
– Para mantener la simplicidad es necesaria la
refactorización del código
– Simplicidad en la documentación: el código debe
comentarse en su justa medida
– Autoría colectiva del código y la programación
por parejas
La refactorización de código tiene el objetivo de que los métodos puedan
leerse de la manera más fácil posible.
En el mejor de los casos, los programadores externos que lean el código
deberían poder captar la lógica interna del método.

13/05/2021
eXtreme Programming
• Comunicación
– Para los programadores el código comunica
mejor cuanto más simple sea
– Las pruebas unitarias describen el diseño de
las clases y los métodos al mostrar ejemplos
concretos de cómo utilizar su funcionalidad
– Los programadores se comunican gracias a
la programación por parejas
– La comunicación con el cliente es fluida
porque forma parte del equipo de desarrollo

13/05/2021
eXtreme Programming
• Retroalimentación:
– La opinión del cliente se conoce en tiempo
real porque está integrado en el proyecto
– Los ciclos cortos muestran resultados
rápidamente
– El código y la programación por parejas
también son fuente de retroalimentación

13/05/2021
eXtreme Programming
• Coraje:
– Diseñar y programar para hoy, no para
mañana
– Refactorizar cuando sea necesario
– Desechar código obsoleto o complejo

13/05/2021
eXtreme Programming
• Respeto:
– Propiedad colectiva del código
– Alta calidad

13/05/2021
eXtreme Programming
• 12 reglas
1. El juego de la
planificación
2. Entregas pequeñas
3. Metáfora
4. Diseño simple
5. Pruebas
6. Refactorización
7. Programación en
parejas
8. Integración continua
9. Propiedad colectiva
del código
10. Cliente presente
11. Semanas de 40
horas
12. Espacios comunes

13/05/2021
eXtreme Programming
• Roles
– Programador: código simple, pruebas
– Cliente: historias, pruebas funcionales,
prioridades
– Tester: ayuda con las pruebas, mantiene pruebas
funcionales y analiza resultados
– Tracker: retroalimentación, estimaciones, evalúa
objetivos
– Coach: responsable del proceso
– Consultor: externo, conocimientos técnicos
– Manager: decisiones

13/05/2021
El Equipo XP (Programación Extrema)
• “Clientes”
– Definen el producto
– Incluyen un dueño del producto
• Que es el responsable de la visión del producto
• “Programadores”
– Escriben el código, diseñan la arquitectura, etc.
• Validadores
– “Investigan”, en busca de defectos
– Son “optativos”, porque los clientes y programadores
pueden cumplir sus funciones
• Entrenadores
– Un entrenador de programadores
• Programador experimentado, para atender consultas, liderar en
las decisiones importantes, y evaluar lo que hacen los otros
– Si hace falta, un administrador de proyecto
• No es imprescindible porque el equipo se auto-organiza
• Otros
– Si hacen falta: escritores, analistas ISO 9000, etc.

13/05/2021
Los “Clientes”
• Son los responsables de establecer los
requerimientos del sistema
– Utilizando las estimaciones de costo que les proveen
los “programadores”
• Entre los “clientes” pueden haber:
– Clientes reales de la empresa
– Expertos de dominio (ej., analistas de negocios,
científicos)
– Diseñadores de interfaces al usuario
• Proporción típica: 1 cada 3 programadores
– O los necesarios para mantener ocupados a los
programadores
El Equipo XP

13/05/2021
Plan del Release
• Release es cada “vendible” que se le entrega al
usuario final
• Se aconseja que demore unos tres meses como
máximo
• Empieza con una planificación, a cargo de los
“clientes”
– A cada requisito se le llama historia de usuario
• Ej.: Un usuario que necesita tal cosa, opera el producto de tal
manera, obtiene tal respuesta, etc. Casos puntuales y
concretos.
• …pero dejando los detalles para después
– Los “programadores” los asisten, estimando el esfuerzo (o
sea, tiempo) que demoraría cada historia
• Para que puedan decidir qué dejar para un próximo release
– Obtienen así el release plan
Programación Extrema

13/05/2021
Plan de la Iteración
• El release se divide en iteraciones
– Unas 1 a 3 semanas c/u
– Luego de cada iteración, se tiene un producto
demostrable
• …para ser evaluado por los “clientes” y verificado por los
validadores
• Al principio de cada iteración, los “clientes”
determinan qué historias se van a hacer en ella
– Empezando por las que son clave; la optimización va
al final
– Este plan puede ser modificado en base a las
estimaciones (de costo) de los programadores
• Queda así establecido lo que hace cada equipo
en el resto de la iteración:
– Los “programadores” implementan esas historias
– Los “clientes” seleccionan y detallan las de la próxima
iteración
• …y atienden consultas de los programadores
– O sea que los “clientes” reemplazan la documentación pesada
– Los validadores (si los hay) ponen a prueba los builds
que proveen los “programadores”

13/05/2021
Los “Programadores”
• Codifican en pares (pair programming)
– Habitualmente, en una PC compartida, con teclado y
mouse para c/u, más dos notebooks individuales
• Para averiguar más, googlear “pairing workstation”
– Es una alternativa a la técnica más tradicional:
revisión de código
– El objetivo es lograr un código confiable que pueda
ser comprendido por todos
• Antes de programar cualquier unidad, programan
su código de prueba
– Esto se llama Desarrollo Guíado por Pruebas (Test-
Driven Development, o TDD)
– Para estas pruebas automatizadas utilizan ejemplos
preparados por los “clientes”
– En C, el código de prueba de una unidad puede
consistir de muchas llamadas a ese módulo, con
diferentes parámetros, chequeándose las variables
retornadas
– Como las pruebas se automatizan, los proyectos
necesitan pocos o ningún validador
El Equipo XP

13/05/2021
Otras Técnicas Importantes
• Colaboración
– El ambiente de trabajo debe ser abierto
– …con varios pizarrones para intercambiar ideas
• Sugerencia: Sacarles fotos a los diagramas en el pizarrón
– Todo código es de todos
• Usar un sistema de control de versiones
• Métricas
– Como métrica de progreso del proyecto, se usa la suma del
esfuerzo de las historias ya implementadas y verificadas
• Y como métrica de lo que resta por hacerse, se usa la suma del
esfuerzo de la historias que faltan
– La cantidad de historias a hacer puede ser ajustada, en función
de la velocidad (o sea, progreso / tiempo) que está logrando el
equipo
• Y hay bastantes más prácticas en XP…

13/05/2021
El proceso de la programación extrema
historias del usuario
valores
criterios de pruebas de aceptación
plan de iteración
diseño simple
tarjetas CRC
prueba unitaria
integración continua
incremento de software
velocidad calculada del proyecto
soluciones en punta
prototipos
rediseño
programación por parejas
pruebas de aceptación
Lanzamiento
El diseño XP sigue
rigurosamente el
principio MS (mantenlo
sencillo).
Un diseño sencillo
siempre se prefiere
sobre una
representación más
compleja.
Se desalienta el diseño
de funcionalidad
adicional porque el
desarrollador supone
que se requerirá
después

13/05/2021
El diseño en la programación extrema
• XP estimula el uso de las tarjetas CRC como
un mecanismo eficaz para pensar en el
software en un contexto orientado a objetos.
• Las tarjetas CRC (clase-responsabilidad-
colaborador) identifican y organizan las
clases orientadas a objetos que son
relevantes para el incremento actual de
software.
• Las tarjetas CRC son el único producto del
trabajo de diseño que se genera como parte
del proceso XP.

13/05/2021
Tarjetas CRC
• Clase - el nombre
• Responsabilidades - lo que sabe y lo que hace
• Collaboraciones - quiénes le ayudan
Clase: Model
Colaboradores:
• View
• Controller
Responsabilidad:
• Proporciona el núcleo de funcionalidad
de la aplicación
• Registra los View y Controller
dependientes
• Notifica a los componentes
dependientes acerca de cambios en los
datos

13/05/2021
Tarjetas CRC
• Permiten una rápida visión de los
elementos esenciales de las clases al
encarar la descomposición
• Se usan como técnica de diseño con
participación de usuarios
– Cada uno desempeña el rol de una clase
– Cada uno describe lo que hace al “ejecutar”
un determinado escenario de cierto caso de
uso

13/05/2021
• Scrum
• Crystal
• Kanban
• RUP?

13/05/2021
SCRUM (Ken Schwaber)
• Basado en el método de desarrollo de
Nonaka y Takeuchi
• El nombre se refiere a una práctica del rugby
en la que un balón que sale fuera se pone en
juego con la colaboración de todo el equipo
• No describe técnicas de desarrollo, sino
relaciones entre los miembros del equipo
• La idea básica es que el desarrollo de
software es tan complejo que es inevitable
que se produzcan cambios durante a lo largo
del proceso.

13/05/2021
SCRUM
• Tres fases:
– pre-juego: planificación y arquitectura
– desarrollo (o juego): sprints
– post-juego: lanzamiento
• Roles principales:
– Scrum Master
– Responsable de producto
– Equipo SCRUM
– Cliente
– Gestores

13/05/2021
SCRUM
• Los principios Scrum son congruentes con el
manifiesto ágil y se utilizan para guiar actividades de
desarrollo dentro de un proceso de análisis que
incorpora las siguientes actividades estructurales:
requerimientos, análisis, diseño, evolución y entrega.
• Dentro de cada actividad estructural, las tareas del
trabajo ocurren con un patrón del proceso llamado
sprint.
• El trabajo realizado dentro de un sprint se adapta al
problema en cuestión y se define —y con frecuencia
se modifica— en tiempo real por parte del equipo
Scrum.

13/05/2021
SCRUM
Desarrollo en sprints (ciclo de trabajo repetitivo)
• Desarrollar: Definición de los cambios necesarios para la
implementación de los requisitos del backlog en módulos, la
apertura de los módulos, análisis del dominio, diseño,
desarrollo, implementación, pruebas y documentación de los
cambios. El Desarrollo consiste en el microproceso de
descubrimiento, invención e implementación.
• Integrar: Cierre de los módulos, creación de una versión
ejecutable con los cambios que implementan los requisitos
del backlog.
• Revisar: Reunión de todos los equipos para presentar el
trabajo y revisar el progreso, identificando y resolviendo
posibles cuestiones y añadiendo nuevos elementos al
backlog. Se revisan los riesgos y las respuestas apropiadas.
• Ajustar: Consolidación de la información de la revisión de los
módulos afectados.

13/05/2021
SCRUM
30 días
SCRUM: reunión diaria de 15 minutos.
Los miembros del equipo responden a
preguntas básicas:
1) ¿Qué hiciste desde la última
reunión Scrum?
2)¿Tienes algún obstáculo?
3)¿Qué harás antes de la próxima
reunión?
Aspectos
con retraso
ampliados
por el
equipo
Al ﬁnal del sprint
se demuestra la
nueva
funcionalidad
Cada
24
horas
Retraso del
sprint:
Característica(s)
asignadas para
el sprint
Retraso del producto
Características del producto
que desea el cliente con
prioridad

13/05/2021
SCRUM
• Retraso: lista de prioridades de los requerimientos o
características del proyecto que dan al cliente un valor
del negocio. Es posible agregar en cualquier momento
otros aspectos al retraso (ésta es la forma en la que
se introducen los cambios). El gerente del proyecto
evalúa el retraso y actualiza las prioridades según se
requiera.
• Sprints: consiste en unidades de trabajo que se
necesitan para alcanzar un requerimiento definido en
el retraso que debe ajustarse en una caja de tiempo14
predefinida (lo común son 30 días). Durante el sprint
no se introducen cambios (por ejemplo, aspectos del
trabajo retrasado). Así, el sprint permite a los
miembros del equipo trabajar en un ambiente de corto
plazo pero estable.

13/05/2021
SCRUM
• Reuniones Scrum: son reuniones breves (de 15 minutos, por
lo general) que el equipo Scrum efectúa a diario. Hay tres
preguntas clave que se pide que respondan todos los
miembros del equipo:
– ¿Qué hiciste desde la última reunión del equipo?
– ¿Qué obstáculos estás encontrando?
– ¿Qué planeas hacer mientras llega la siguiente reunión del
equipo?
• Un líder del equipo, llamado maestro Scrum, dirige la junta y
evalúa las respuestas de cada persona.
– La junta Scrum ayuda al equipo a descubrir los problemas
potenciales tan pronto como sea posible.
– Asimismo, estas juntas diarias llevan a la “socialización del
conocimiento”, con lo que se promueve una estructura de
equipo con organización propia.

13/05/2021
SCRUM
• Demostraciones preliminares: entregar el incremento
de software al cliente de modo que la funcionalidad que
se haya implementado pueda demostrarse al cliente y
éste pueda evaluarla.
• Es importante notar que las demostraciones
preliminares no contienen toda la funcionalidad
planeada, sino que éstas se entregarán dentro de la caja
de tiempo establecida

13/05/2021
Aspectos destacados de SCRUM
• Roles
– Product owner (PO) resposable de describir y priorizar los
requisitos.
– Team responsable de producir un "sprint" encuadrado en el
tiempo (iteración)
– Scrum master (SM) responsable de posibilitar las condiciones
de trabajo en equipo
• Prácticas
– Micro feedback, como reuniones scrum diarias, sprint backlog,
burn-down charts
– Macro feedback y priorización por parte del propietario del
producto en cada sprint,
• Product backlog
• Scrum no prescribe
– Soluciones técnicas, métodos de trabajo, planes de avance del
proyecto
– Estos son responsabilidad del equipo para descubrirlos y
adaptarlos según las necesidades.
• Adecuado para proyectos con objetivos inciertos u objetivos
móviles
– O donde no se conoce del todo el camino para llegar

13/05/2021
Prácticas de Scrum
• Cuadros de tiempo (time boxing)
– El valor incremental de una actividad disminuye con el tiempo.
– Beneficio 80/20 logrado dentro del cuadro de tiempo
• Resultados potencialmente instalables
– Tiempo de iteraciones ("sprints") encuadrado a 30 días (o
menos)
– Cada iteración ofrecerá valor personalizado y calidad de
producción.
• Reducir elaboración inicial (un día)
– Especifique "todos" los requisitos generales para la acumulación
de productos inicial
• Principales casos de uso con escenarios, alt. historias del usuario
• Roles de actores principales
• Priorizar y volver a priorizar
– Solo trabaje en lo que se pueda completar durante el próximo
sprint (iteración)
– Cuadro de tiempo de especificación y planificación: un día

13/05/2021
Iteraciones Iter #1 #2 Iter #3 #4 #5 #6 Iter #7 #8
RUP: descripción general
(repaso para comparar con Scrum)
Fases
Disciplinas
Requerimientos
Análisis
Diseño y
Arquitectura
Implementación
Test

13/05/2021
Pre-project
Sprints #1 #2 #3 #4
Scrum - Descripción general
Disciplinas
Sprints
Requisitos
iniciales
Requerimientos
Análisis
Diseño y
Arquitectura
Implementación
Test

13/05/2021
Hitos importantes
• RUP
• Scrum
tiempo
Vision Baseline
Architecture
Initial
Capability
Product
Release
2-6 weeks per iteration
~15 %
tiempo
Vision Initial, high-level
Product Backlog
Pre-project
Requirimientos
Iniciales
Sprints
Any number of
potential Product
Releases
1 day 30 days per sprint
Any number of
potential Product
Releases

13/05/2021
• Scrum
• Crystal
• Kanban
• RUP?

13/05/2021
Crystal (Cockburn)
• Conjunto de métodos de desarrollo
• Incluye distintas metodologías que se
pueden elegir y adaptar en función del
proyecto
• Cada metodología se identifica con un color
que refleja su peso
• Se pueden utilizar otros métodos ágiles como
método de desarrollo
• Desarrollo incremental con muchas entregas

13/05/2021
Crystal
• Variantes más populares
– Crystal Clear: para proyectos pequeños
– Crystal Orange: para proyectos medianos

13/05/2021
Clear Yellow Orange Red
Crystal es una familia de metodologías porque cada proyecto es
ligeramente diferente y necesita su propio método.
• Las tecnologías
cambian las
técnicas.
• Las culturas
cambian las
normas.
• Las distancias
cambian la
comunicación.
Cantidad de personas involucradas
Criticidad
(los
defectos
provocan
la
pérdida
de
...)
Comfort
(C)
Essential
money
(E)
Life
(L)
1 - 6 - 20 - 40 - 100 - 200
C6 C20 C40 C100 C200
D6 D20 D40 D100 D200
E6 E20 E40 E100 E200
L6 L20 L40 L100 L200
Discretionary
money
(D)

13/05/2021
Crystal Orange : alcance
• Para proyectos D40:
– Hasta 40 personas, mismo edificio
• Pérdida de dinero discrecional
– (puede extenderse hasta E50)
• No para proyectos muy grandes
– (sub equipo insuficiente)
• No para proyectos de vital
importancia
– (verificación insuficiente)
• (Described in Surviving OO Projects,
Cockburn, 1998, pp. 77-93)
Amber
C6 C20 C40 C80
D6 D20 D40 D80
E6 E20 E40 E80
L6 L20 L40 L80

13/05/2021
Roles y equipos de Crystal Orange para 45
personas
•Roles:
•Sponsor,
•Business expert,
•Usage expert,
•Technical facilitator,
•Business analyst/designer,
•Project Manager,
•Architect,
•Lead designer/programmer,
•Designer/programmer,
•UI designer,
•Design Mentor,
•Reuse Point,
•Writer,
•Tester
•Teams:
• System planning,
•Project monitoring,
•Architecture,
•Technology,
•Functions,
•Infrastructure,
•External test.

13/05/2021
C6 C10
D6 D10
E6 E10
Crystal Clear : scope
• Para proyectos D6:
– 3-6 personas, cerca o en la misma
habitación
– Pérdida de dinero discrecional
• (puede extenderse a: proyecto E8)
• No para grandes proyectos
– (coordinación de grupo insuficiente)
• No para proyectos de vital
importancia
– (verificación insuficiente)
• (Described in Crystal Clear, Cockburn, 2004 also in Agile
Software Development, Cockburn 2002)

13/05/2021
Crystal Clear roles y equipos para 3-8
personas
•Required Roles:
•sponsor,
•senior designer,
designer/programmer,
•user (part-time)
•Combined Roles:
•coordinator,
•business expert,
•requirements gatherer
•Teams:
• single team of designer-
programmers
•Seating:
•single big room, or adjacent
offices

13/05/2021
• ¡Debe hacer esto!
– 1. Entrega frecuente: cada mes o dos
– 2. Comunicación osmótica: sentarse uno al
lado del otro
– 3. Mejora reflexiva: hacer un taller de
reflexión mensualmente
Centrarse en las primeras 3
propiedades

13/05/2021
• ¡Agregue estos como pueda!
– 4. Seguridad personal: hable libremente sin temor a
ser castigados
– 5. Enfoque: sepa qué es lo más importante, tenga
tiempo para trabajar en ello
– 6. Fácil acceso a usuarios expertos
– 7. Entorno técnico con
• Integración frecuente: cada hora, diaria, 3 / semana
• Pruebas automatizadas: pruebas unitarias, pruebas de
aceptación
• Gestión de la configuración: check-in, versionado
¡Simplemente comience a trabajar y manténgase
en comunicación de buen humor con sus
compañeros de equipo!

13/05/2021
Richness (“temperature”) of communication channel
“cold” “hot”
Communication
Effectiveness
2 people at
whiteboard
2 people
on phone
2 people
on email
Videotape
Paper
Audiotape
Crystal
Principios de diseño

13/05/2021
Siete principios para el diseño
1. Prefiera la comunicación cara a cara
– La comunicación interactiva cara a cara es el canal más
barato y rápido para intercambiar información
2. El peso de la metodología es costoso
3. Use metodologías más pesadas para equipos más
grandes / distribuidos
4. Utilice más reuniones(ceremonias) para mayor
criticidad
5. Utilice más comentarios y comunicaciones, con
menos entregables intermedios
6. Disciplina, habilidades, comprensión del proceso
contrario, formalidad, documentación
7. La eficiencia es prescindible en actividades que no
supongan un cuello de botella.

13/05/2021
Los procesos ágiles son fáciles de describir y comprender
como ciclos anidados de diferentes duraciones.
Proyecto
Integración
Día/Semana
Iteración
Entregable

13/05/2021
Para comprender Crystal (o cualquier proceso
ágil), describa cada ciclo de forma independiente.
Proyecto
Entregable
Entregable
Iteración
Iteración
Iteraciones
Día/Semana
Integration Integration
Día/semana
Integrations
Días Días
Integrations Integrations

13/05/2021
Las actividades de cualquier día pueden
pertenecer a diferentes ciclos
Project Iteration Day Integration Episode
Charter
Plan
Daily standup
Design & Check-in
Design & Check-in
Build and test
Design & Check-in
Design & Check-in
Build and test
Daily standup
Design & Check-in
Design & Check-in
Build and test
Design & Check-in
Design & Check-in
Build and test
Deliver
Reflect and celebrate
Plan
(etc.)
Wrapup

13/05/2021
• Scrum
• Crystal
• Kanban
• RUP?

13/05/2021
Lean Software Development (Charette)
• Proviene de la industria de la automoción
(Toyota)
• No pretende cambiar el proceso de
desarrollo, sino todo el funcionamiento de
la empresa

13/05/2021
Siete principios
Lean Software Development

13/05/2021
Siete principios
1) Ver y eliminar el waste-desperdicio
• Evitar definir requerimientos a detalle muy
temprano cuando se sabe que se van a solicitar muchos
cambios.
• Apurar el desarrollo aun sabiendo que el software no se va a
probar inmediatamente.
• Incorpora la calidad temprano
– Eliminar la mala de costumbre de no probar bien lo desarrollado
y dejarle el trabajo a QA que ya “nos informará si algo salió mal”.
– Automatizar pruebas y solucionar defectos apenas estos se
detecten y no dejarlos para después.
– Eliminar la causa raíz de los incidentes asegurando que estos
nunca más vuelvan a ocurrir.

13/05/2021
• Desperdicio es
– Cualquier cosa que interfiera con darles a los clientes lo que valoran
• En el momento y lugar donde proporcionará el mayor valor
1. Trabajo parcialmente terminado
– Documentación no codificada, código no sincronizado, no probado, no documentado o no
implementado
2. Características adicionales
– “Es mejor para los desarrolladores surfear que escribir código que no será necesario”
Jeff Sutherland, CTO PatientKeeper [YAGNI]
3. Reaprendizaje
– Benefíciese y conserve las experiencias, mejore el producto y el proceso
4. Cambiar de tarea
– Toma tiempo, distrae de los resultados, retrasa todas las tareas en la entrega de valor
5. Transferencias
– El conocimiento tácito se pierde en las transferencias. Como regalar una bicicleta y un libro de
instrucciones a alguien que no sepa montar. Utilice equipos integrados, experiencia y
conversación.
6. Retrasos
– Los desarrolladores toman decisiones críticas cada 15 minutos. Ponga la información a
disposición.
– Otros retrasos: aprobación de proyectos, personas, aprobación de cambios, funcionalidad,
pruebas.
7. Defectos
– La prueba es diseño. Haga que los defectos sean inusuales. Descubra los defectos a tiempo.
Pruebe de forma automática y manual, temprano y con frecuencia. La verificación final no debe
descubrir nuevos defectos de forma rutinaria
Lean Development – Evite los siete desperdicios

13/05/2021
2) Ampliar el aprendizaje
• Pretender tener un diseño definido a detalle asumiendo que
éste no va a cambiar no es realista. Sobre todo para un
sistema complejo y con mucha incertidumbre.
• Se sustituyen los requisitos por presentar las pantallas a los
usuarios.
• Herramientas:
– Tool 3: Feedback.
– Tool 4: Iteraciones.
– Tool 5: Sincronización (builds cada día del producto y tests
automatizados, comunica restricciones y deja la solución
emerger).
– Tool 6: Set-Based Development (converger con restricciones en
lugar de decisiones tempranas)
Siete principios

13/05/2021
3) Decidir lo más tarde posible
• Dejar las decisiones para el final introduciendo opciones en el
desarrollo, aunque cueste más desarrollar las opciones (la
reducción del riesgo lo compensa).
• Situación donde he visto que mi idea era mejor que otras pero
debido a que ésta no estaba contemplada en el plan inicial no fue
considerada. En este caso todos los requerimientos se definieron
muy temprano y no se consideró que a medida que se progresa se
gana más conocimiento y las ideas evolucionan en el proyecto.
• Herramientas:
– Tool 7: Options Thinking (retrasa decisiones importantes si hay
incertidumbre).
– Tool 8: El último momento responsable.
– Tool 9: Tomando decisiones, 2 aproximaciones depende del contexto,
depth-first para decisiones claras o un experto vs breadth first para
retrasar decisiones.
Siete principios

13/05/2021
4) Reaccionar/Liberar tan rápido como sea posible
• Liberar lo más rápido posible y con una buena velocidad
mejora el aprendizaje.
• Transparencia en el proceso.
• Herramientas:
– Tool 10: Sistemas Pull y planificaciones solo alto nivel
con Information Radiators, ver también Kanban.
– Tool 11: Teoría de colas, mirar tiempo de ciclo en lugar de
trabajo hecho, y hacer releases pequeñas para disminuir
tamaño de cola.
– Tool 12: Cost of Delay, hay que dar al equipo un modelo
económico (Trade-off triangle) para que tome sus propias
decisiones acorde a lo que la compañía persigue. Mejor si los 3
ejes tienen las mismas unidades de medida. Así se reducirán los
tiempos de ciclo y se respetarán las fechas.
Siete principios

13/05/2021
5) Potenciar el equipo
• Las organizaciones de software no pueden funcionar a pleno
rendimiento, hay que dejar un tiempo para invertir en formación,
reestructuración, y organizar recursos para crecer.
• Herramientas:
– Tool 13: Autodeterminación, el manager se convierte en empowerer y
facilitador del trabajo, introducir feedback loops, implementa basado en
principios y no en procesos.
– Tool 14: Motivacion, comunica el propósito de los proyectos, el objetivo
debe ser conseguible. Comunica a los developers con los clientes
directamente. Recibirás un mayor compromiso con el trabajo de las
iteraciones.
– Tool 15: El liderazgo dentro del equipo emerge, no se elige desde
arriba sino que es algo que se debe ganar.
– Tool 16: Experiencia, promueve las comunidades de expertos y los
estándares.
Siete principios

13/05/2021
6) Crear la integridad
• Integridad conceptual significa que los componentes separados del sistema
funcionan bien juntos, como en un todo, logrando equilibrio entre la
flexibilidad, mantenibilidad, eficiencia y capacidad de respuesta.
• Flujo de información entre lo que debe construir y la construcción debe ser
al mismo tiempo, no secuencialmente. No es válida la
documentación, mejor la comunicación cara a cara.
• Pruebas de aceptación para probar el todo.
• Herramientas:
– Tool 17: Integridad percibida, foco en el valor para el cliente, utilizar modelos en
lenguaje de negocio como contrato entre equipo y clientes.
– Tool 18: Integridad conceptual, la solución debe funcionar como un todo. La
comunicación debe ser efectiva sobre todo en la fase de diseño. Mejor si el diseño no
se basa en un documento de requerimientos sino hacer sesiones continuas de
diseño. Si algo ya funciona y lo puedes reaprovechar hazlo.
– Tool 19: Refactoring, la arquitectura debe mantenerse sana durante la evolución.
Simplicidad, claridad, mantenibilidad.
– Tool 20: Testing, deben probar que hace lo que debe, automatizar al máximo e
integrar en la construcción diaria.
Siete principios

13/05/2021
7) Véase todo el conjunto
• Piensa en grande, actúa en pequeño, equivócate
rápido; aprende con rapidez.
• Hay que ver el conjunto, no solo el producto o el
proceso, y siempre aplicando sentido común.
• Herramientas:
– Tool 21: Medidas, para mejorar y decidir hay que medir.
Medidas de información, no de rendimiento individual. Por
ejemplo asignar los defectos a features, no al
desarrollador.
– Tool 22: Contratos, se busca la colaboración, ser flexible
con el alcance. El cliente debe entender que si el riesgo
surge deberá incrementar el coste, no puede ser coste y
fecha fija.
Siete principios

13/05/2021
• Scrum
• Crystal
• Kanban
• RUP?

13/05/2021
¿Qué es Kanban?
● Surgió en los años 40
● Sistema de producción de
Toyota
● Producción basada en la
demanda de los clientes.
● Centrada en el Servicio
● Kanban significa tarjeta
con signos o señal visual.

13/05/2021
Principios
● A) Comenzar con lo actual El método Kanban se inicia con las
funciones y procesos que ya se tienen y estimula cambios continuos,
incrementales y evolutivos al sistema.
● B) Aplicar cambios incrementales Todos deben estar de acuerdo en
que la manera de hacer mejoras en el sistema es el cambio continuo,
gradual y evolutivo. Los cambios fuertes pueden parecer más eficaces,
pero fracasan más debido a la resistencia y el miedo en la organización.
● C) Respetar lo establecido Para facilitar el cambio futuro conviene
respetar los roles, responsabilidades y cargos actuales, eliminando los
temores iniciales. Esto permite obtener un mayor apoyo a la iniciativa
Kanban.
● D) Liderazgo en todos los niveles Kanban promueve acciones de
liderazgo desde las personas de bajo rango hasta los gerentes.

13/05/2021
Prácticas
1. Visualizar el flujo
de trabajo
2. Eliminar interrupciones. Limitar trabajo
WIP
3. Gestionar el flujo Flujo rápido e ininterrumpido

13/05/2021
Prácticas
4. Hacer las políticas explícitas
○ Fomentar la visibilidad
5. Circuitos de retroalimentación
6. Mejorar colaborando
○ usando modelos y el método científico

13/05/2021
Beneficios
1. Estímulo del rendimiento: Análisis y estimación
para medir el rendimiento. Detección de
problemas y ajuste del trabajo. Flexibilidad.
2. Organización y colaboración: Enfoque visual.
Colaboración en tiempo real. Accesibilidad y
comunicación.
3. Distribución del trabajo: Visión rápida y ahorro de
tiempo. El flujo constante de tareas reduce el
tiempo perdido. Cada uno elige sus tareas.

13/05/2021
Ejemplo
Fuente: http://metodokanbansoftwareagil.blogspot.com

13/05/2021
Herramientas: Trello

13/05/2021
Herramientas: Wekan (open source)

13/05/2021
embebidos.

13/05/2021
Metodología Tradicionales vs Ágiles
Metodologías Tradicionales Metodologías Agiles
Basadas en normas provenientes de
estándares seguidos por el entorno de
desarrollo
Basadas en heurísticas provenientes de
prácticas de producción de código
Cierta resistencia a los cambios Especialmente preparados para cambios
durante el proyecto
Impuestas externamente Impuestas internamente (por el equipo)
Proceso mucho más controlado, con
numerosas políticas/normas
Proceso menos controlado, con pocos
principios.
El cliente interactúa con el equipo de
desarrollo mediante reuniones
El cliente es parte del equipo de desarrollo
Más artefactos Pocos artefactos
Más roles Pocos roles
Grupos grandes y posiblemente distribuidos Grupos pequeños (<10 integrantes) y
trabajando en el mismo sitio
La arquitectura del software es esencial y se
expresa mediante modelos
Menos énfasis en la arquitectura del software
Existe un contrato prefijado No existe contrato tradicional o al menos es
bastante flexible

13/05/2021
Diferencias por las características del
Proyecto
Modelo de
Proceso
Tamaño del
Proceso
Tamaño del
Equipo
Complejidad
del Problema
RUP Medio /
Extenso
Medio /
Extenso
Medio / Alto
ICONIX Pequeño /
Medio
Pequeño /
Medio
Pequeño /
Medio
XP Pequeño /
Medio
Pequeño Medio / Alto
SCRUM Pequeño /
Medio
Pequeño Medio / Alto

13/05/2021
Cabe destacar:
• El retrasar las decisiones en un proyecto de
software permite potenciar el valor del producto
tanto para el cliente como al equipo o empresa
que desarrolla
• Para que un grupo de desarrollo adopte una
metodología ágil debe poseer
experiencia trabajando con metodologías
tradicionales, ya que la experiencia es la que
predomina en los mementos cruciales del
proyecto, además debe tener la capacidad de ser
equipos auto-gestionados, altamente motivados y
con gran innovación

13/05/2021
Cabe destacar:
• Las metodologías ágiles permiten disminuir
costos y brindar flexibilidad a los proyectos de
software donde la incertidumbre está presente
• El uso de metodologías tradicionales es
esencial al inicio en un equipo de desarrollo de
software
• Las metodologías ágiles se deberían aplicar en
proyectos donde exista mucha incertidumbre
donde el entorno es volátil, donde los requisitos
no se conocen con exactitud, mientras que las
metodologías tradicionales obligan al cliente a
tomar las decisiones al inicio del proyecto.

13/05/2021
ESTILOS
ARQUITECTÓNICOS,
MODELOS DE REFERENCIA Y
FRAMEWORKS
Unidad 2B
Final de la unidad

ESTILOS ARQUITECTÓNICOS, MODELOS DE REFERENCIA Y FRAMEWORKS

Recommended

Recommended

More Related Content

More from Franklin Parrales Bravo

More from Franklin Parrales Bravo (20)

Recently uploaded

Recently uploaded (20)

ESTILOS ARQUITECTÓNICOS, MODELOS DE REFERENCIA Y FRAMEWORKS