PSW Unidad 2 MODELOS DE PROCESO

Ph.D. Franklin Parrales 1
22/10/2021
Proceso de Software Carrera de Software
MODELOS DE PROCESO
Unidad 2
Material docente compilado por el profesor Ph.D. Franklin Parrales Bravo
para uso de los cursos de Proceso de Software

22/10/2021
Objetivo general de la Unidad 2
Caracterizar el modelado de procesos identificando los
factores claves del proceso para definir el alcance de los
proyectos de software.

22/10/2021
Contenido
• Modelado de procesos
– Introducción a los modelos de proceso
• Tipos de modelos
– Cascada
– Incremental
– Evolutivo
– Concurrentes.
– Desarrollo basado en componentes
– Otros Desarrollos de software (Agile)
– Métodos formales
• Proceso unificado
– Fases del proceso unificado
• Evaluación y mejora del proceso

22/10/2021
Contenido
– Cascada
– Incremental
– Evolutivo
– Concurrentes.

22/10/2021
Introducción a los modelos de proceso
• Los estándares establecen los diferentes procesos implicados
a la hora de desarrollar y mantener un sistema desde que
surge la idea o necesidad de desarrollar las aplicaciones
hasta que éstas se retiran de explotación.
– Sin embargo, ninguno impone un modelo de procesos concreto
(modelo de ciclo de vida) ni cómo realizar las diferentes actividades
incluidas en cada proceso, por lo que cada empresa deberá utilizar
los métodos, técnicas y herramientas que considere oportuno.
• Por su naturaleza, los modelos son simplificaciones; por lo
tanto, un modelo de procesos del software es una
simplificación o abstracción de un proceso real.
• Podemos definir un modelo de procesos del software como
una representación abstracta de alto nivel de un proceso
software.

22/10/2021
Introducción a los modelos de proceso
• Cada modelo es una descripción de un proceso software que
se presenta desde una perspectiva particular.
– Alternativamente, a veces se usan los términos ciclo de
vida y Modelo de ciclo de vida.
• Cada modelo describe una sucesión de fases y un
encadenamiento entre ellas.
– Según las fases y el modo en que se produzca este
encadenamiento, tenemos diferentes modelos de proceso.
• Un modelo es más adecuado que otro para desarrollar un
proyecto dependiendo de un conjunto de características de
éste.
• Existe una gran variedad de modelos diferentes entre los que
tenemos los que se estudiarán en esta unidad.

22/10/2021
Contenido
– Cascada
– Incremental
– Evolutivo
– Concurrentes.

22/10/2021
Tipos de modelos
• Modelos tradicionales: Formados
por un conjunto de fases o
actividades en las que no tienen en
cuenta la naturaleza evolutiva del
software
– Clásico, lineal o en cascada
– Estructurado
– Basado en prototipos
– Desarrollo rápido de aplicaciones
(RAD)
• Modelos evolutivos: Son modelos
que se adaptan a la evolución que
sufren los requisitos del sistema en
función del tiempo
– En espiral
– Evolutivo
– Incremental
– Modelo de desarrollo concurrente
• Modelos orientados a la
reutilización
– Basado en componentes
– Proceso Unificado
• Procesos ágiles
– Programación extrema (XP)
– Desarrollo de software
adaptativo
– Scrum, Crystal …

22/10/2021
Modelo Codificar y corregir
▪ Este es el modelo básico
utilizado en los inicios del
desarrollo de software.
▪ Contiene dos pasos:
◼ Escribir código.
◼ Corregir problemas en el
código.
▪ Primero implementar algo
de código y luego pensar
acerca de requisitos,
diseño, validación, y
mantenimiento

22/10/2021
Modelo 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.

22/10/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á.

22/10/2021
Contenido
– Cascada
– Incremental
– Evolutivo
– Concurrentes.

22/10/2021
Modelo en cascada
• Conocido también como modelo lineal o clásico
• Versión original se debe a W. W. Royce [Royce, 1970], apareciendo
después numerosos refinamientos
• Características
– Está compuesto por una serie de
fases que se ejecutan
secuencialmente
– Obtención de documentos como
criterio de finalización de fase
• Problemas de la progresión
secuencial
– Desconocimiento de las necesidades
por parte del cliente
– Inestabilidad de los requisitos
– No se ven resultados hasta muy
avanzado el proyecto
– Efecto big bang próximo a la entrega

22/10/2021
Modelo 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

22/10/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)
Modelo en cascada

22/10/2021
Modelo 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

22/10/2021
Modelo 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

22/10/2021
Modelo 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

22/10/2021
Desarrollo en Cascada (Sommerville)
[Ingeniería de Software. Sommerville I.., 2002]

22/10/2021
Modelo 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

22/10/2021
Modelo en “V”
• Es una evolución del
anterior. En este, la
verificación se desglosa
en etapas de nivel de
abstracción creciente.
Análisis y
Definición de los
Requerimientos
Diseño de la
Arquitectura del
Sistema
Diseño Detallado Testeo de cada
unidad (unit test)
Instalación,
Operación y
Mantenimiento
Prueba de
Aceptación
Prueba de
Integración
Implementación de
cada unidad
Plan de Pruebas
para Cada Unidad
Plan de Pruebas
de Integración
Plan de Pruebas de
Aceptación
❑ En cada etapa de
diseño se crea un
plan de pruebas,
que es el que guía la
etapa de validación
que le corresponde.

22/10/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)

22/10/2021
Contenido
– Cascada
– Incremental
– Evolutivo
– Concurrentes.

22/10/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

22/10/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).

22/10/2021
Contenido
– Cascada
– Incremental
– Evolutivo
– Concurrentes.

22/10/2021
Modelos evolutivos
• Los modelos
evolutivos son
iterativos.
• Se caracterizan por la
manera en la que
permiten desarrollar
versiones cada vez
más completas del
software.
Communicat ion
Quick plan
Const ruct ion
of
prot ot ype
Mode ling
Quick de sign
Delive ry
& Fe e dback
Deployment
comunicación
Plan
rápido
Modelado
Diseño
rápido
Construcción
del prototipo
Despliegue
Entrega y
Retroalimentación

22/10/2021
Recolección
y refinamiento de
requisitos
Diseño
rápido
Producto
Refinamiento
del prototipo
Evaluación del
prototipo por
el cliente
Construcción
del prototipo
• basado en:
– desarrollo de una implementación
inicial
– exposición a comentarios y crítica del
usuario
– refinamiento a través de diferentes
versiones hasta llegar a un sistema
adecuado
dos tipos:
prototipado evolutivo:
trabajo con cliente para explorar sus
requerimientos y entregar un sistema
final
evolución continua del prototipo
mediante la agregación de funciones
y características propuestas por el
cliente
prototipos desechables
comprensión de las necesidades del
cliente
desarrollo de una definición
mejorada de los requerimientos del
sistema
prototipos centrados en la
experimentación de requisitos poco
claros o complejos
problemas
prisas del cliente (utilización del prototipo
como sistema final
pasar elecciones debidas al prototipo a la
implementación final (entorno, sistema
operativo,...)
estructura deficiente
evolución del proceso difícil de gestionar
herramientas y técnicas especiales
poco adecuado para grandes sistemas

22/10/2021
Prototipado evolutivo
(ciclo de vida iterativo)
• Enfoque de desarrollo que se utiliza cuando no se conoce
con seguridad lo que se quiere construir
• Se comienza diseñando e implementando las partes más
destacadas del sistema
• La evaluación del prototipo proporciona la realimentación
necesaria para aumentar y refinar el prototipo
• El prototipo evoluciona y se transforma en el sistema final
Concepto
inicial
Diseño e
implementación
del prototipo
inicial
Refinar el prototipo
hasta que sea
aceptable
Completar y
entregar el
prototipo

22/10/2021
Modelo Espiral
• Fue propuesto inicialmente por B. Boehm [Boehm, 1986,
1988]
• Utilización de ciclos en lugar de sucesión de actividades.
• Facilita el desarrollo rápido de versiones incrementales
de software.

22/10/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.

22/10/2021
Contenido
– Cascada
– Incremental
– Evolutivo
– Concurrentes

22/10/2021
Modelos concurrentes
• Permite que un equipo de
software represente
elementos iterativos y
concurrentes de cualquiera
de los modelos de proceso
descritos en esta unidad.
• La figura muestra la
representación esquemática
de una actividad de
ingeniería de software
dentro de la actividad de
modelado con el uso del
enfoque de modelado
concurrente

22/10/2021
Modelos concurrentes
• El modelado concurrente define una serie de eventos que
desencadenan transiciones de un estado a otro para cada
una de las actividades, acciones o tareas de la ingeniería de
software.
• El modelado concurrente es aplicable a todos los tipos de
desarrollo de software y proporciona un panorama apropiado
del estado actual del proyecto.
• En lugar de confinar las actividades, acciones y tareas de la
ingeniería de software a una secuencia de eventos, define
una red del proceso.
• Cada actividad, acción o tarea de la red existe
simultáneamente con otras actividades, acciones o tareas.
• Los eventos generados en cierto punto de la red del proceso
desencadenan transiciones entre los estados.

22/10/2021
Contenido
– Cascada
– Incremental
– Evolutivo
– Concurrentes

22/10/2021
Desarrollo basado en componentes
• Configura aplicaciones a partir de componentes de software
preparados [Pressman, 2002]
• Enfoque iterativo y evolutivo [Nierstrasz, 1999]
• Se enmarca en un contexto más amplio: ingeniería del
software basada en componentes
Análisis de
riesgos
Planificación
Comunicación
con el cliente
Buscar
componentes
en bibliotecas
Construir la
iteración del
sistema
Extraer
componentes
disponibles
Poner nuevos
componentes
en biblioteca
Evaluación
del cliente
Construcción y
adaptación de la
ingeniería
Construir
componentes
no disponibles
Identificar
componentes
candidatos

22/10/2021
Desarrollo basado en componentes
• Un componente es una unidad ejecutable e independiente
• Los componentes publican su interfaz y todas las
interacciones son a través de ella
– Una interfaz que se suministra define los servicios que ofrece el
componente
– Una interfaz que se solicita especifica qué servicios deben estar
disponibles
• Para el desarrollo con reutilización:
– Debe ser posible encontrar los componentes reutilizables
apropiados
– Se debe confiar en que los componentes que se utilizan se
comportan conforme a lo especificado y son fiables
– Los componentes deben tener documentación asociada para
ayudar a comprenderlos y adaptarlos a una nueva aplicación

22/10/2021
Ingeniería del software basada en
componentes
Análisis del
Desarrollo de
la arquitectura
Desarrollo de
componentes
Ingeniería del dominio
dominio
del software
Modelo del
dominio
reutilizables
Modelo
estructural
Artefactos/
componentes
reutilizables
Desarrollo
basado en
de la reserva
Cualificación de
componentes
Actualización de
componentes
componentes
Diseño
arquitectónico
Análisis
Adaptación de
componentes
Composición de
Software de
aplicaciones
componentes
Ingeniería de
componentes Comprobación
El objetivo de la ingeniería del
dominio es identificar, construir,
catalogar y diseminar un
conjunto de componentes de
software que tienen aplicación
en el software actual y futuro
dentro de un dominio de
aplicación particular
[Presman, 2001]
➢ Ingeniería del dominio
➢ Desarrollo basado en
componentes

22/10/2021
Actividades de la ingeniería del
dominio
• Análisis del dominio:
– Definir el dominio a investigar
– Categorizar los elementos extraídos del dominio
– Recoger una muestra representativa de las aplicaciones del dominio
– Analizar cada aplicación de la muestra
– Desarrollar un modelo de análisis para los objetos
– Definir un lenguaje del dominio: hace posible la especificación y construcción
posterior de aplicaciones dentro del dominio
• Modelo del dominio: resultado de las actividades anteriores
• Modelado estructural: Enfoque de ingeniería basado en tramas que
opera efectuando la suposición consistente de que todo dominio de
aplicación posee tramas repetidas (de función, de datos y de
comportamiento) que tienen un potencial de reutilización
– Todo dominio de aplicación se puede caracterizar por un modelo estructural
– Un modelo estructural es un estilo arquitectónico reutilizable
– Punto de estructura: estructura bien diferenciada dentro de un modelo
estructural (genéricos: aplicaciones cliente, bases de datos, motores de cálculo,
función de reproducción de informes, editor de aplicaciones)

22/10/2021
Actividades del desarrollo basado en
componentes
• Cualificación de componentes: Asegura que un
componente candidato llevará a cabo la función necesaria,
encajará en el estilo arquitectónico del sistema y tendrá la
calidad requerida
• Adaptación de componentes: Elimina conflictos de
integración
– Enmascaramiento de caja blanca, gris o negra
• Composición de componentes: Ensambla componentes
cualificados, adaptados y diseñados para la arquitectura
establecida
• Ingeniería de componentes: Diseño de componentes para
su reutilización
• Actualización de componentes: El software actual se
reemplaza a medida que se dispone de nuevas versiones de
componentes

22/10/2021
Contenido
– Cascada
– Incremental
– Evolutivo
– Concurrentes

22/10/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

22/10/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

22/10/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.

22/10/2021
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.

22/10/2021
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.

22/10/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

22/10/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?

22/10/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

22/10/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.

22/10/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

22/10/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

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

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

22/10/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

22/10/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

22/10/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.

22/10/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

22/10/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

22/10/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”

22/10/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

22/10/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…

22/10/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

22/10/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.

22/10/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

22/10/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

22/10/2021
XP: eXtreme Programming
• Ventajas
– No es un producto de Microsoft.
– Es parte de un movimiento llamado “Agile Development”.
– Es una metodología ligera.
– Es una corriente en boga.
– Utiliza un modelo incrementar/Interactivo.
– Trabaja con el cliente en sitio.
– Control de cambios, es incremental.
– Se programa entre dos personas.
– Los requerimientos se construyen a través de experiencias.
– Una buena técnica para un buen desarrollador.
• Desventaja
– No funciona como industria.
– No funciona cuando se trabaja con equipos de trabajo grandes

22/10/2021
• Scrum
• Crystal
• Kanban
• RUP?

22/10/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.

22/10/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

22/10/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.

22/10/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.

22/10/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

22/10/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.

22/10/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.

22/10/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

22/10/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

22/10/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

22/10/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
(repaso para comparar con Scrum)
Fases
Disciplinas
Requerimientos
Análisis
Diseño y
Arquitectura
Implementación
Test

22/10/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

22/10/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

22/10/2021
• Scrum
• Crystal
• Kanban
• RUP?

22/10/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

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

22/10/2021
Clear YellowOrange 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)

22/10/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

22/10/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.

22/10/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)

22/10/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

22/10/2021
Centrarse en las primeras 3
propiedades
• ¡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

22/10/2021
¡Simplemente comience a trabajar y manténgase
en comunicación de buen humor con sus
compañeros de equipo!
• ¡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

22/10/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

22/10/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.

22/10/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

22/10/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

22/10/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

22/10/2021
• Scrum
• Crystal
• Kanban
• RUP?

22/10/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

22/10/2021
Siete principios
Lean Software Development

22/10/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.

22/10/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

22/10/2021
Siete principios
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)

22/10/2021
Siete principios
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.

22/10/2021
Siete principios
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.

22/10/2021
Siete principios
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.

22/10/2021
Siete principios
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.

22/10/2021
Siete principios
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.

22/10/2021
• Scrum
• Crystal
• Kanban
• RUP?

22/10/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.

22/10/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.

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

22/10/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

22/10/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.

22/10/2021
Ejemplo
Fuente: http://metodokanbansoftwareagil.blogspot.com

22/10/2021
Herramientas: Trello

22/10/2021
Herramientas: Wekan (open source)

22/10/2021
Contenido
– Cascada
– Incremental
– Evolutivo
– Concurrentes

22/10/2021
¿Que es un método formal?
• Modelo matemático para
– Diseñar.
– Especificar.
– Implementar.
– Verificar.
Sistemas informáticos.
aA, bA a+bA

22/10/2021
Métodos formales
• Los métodos formales son técnicas matemáticas, a menudo
soportadas por herramientas, para el desarrollo de sistemas
software y hardware.
• Su rigor matemático le permite a los ingenieros analizar y
verificar sus modelos en cualquier parte del ciclo de vida del
desarrollo.
• En la Ingeniería de Software los métodos formales se utilizan
para:
– Las políticas de los requisitos
– La especificación
– Las pruebas de correspondencia entre la especificación y los
requisitos
– Las pruebas de correspondencia entre el código fuente y la
especificación
– Pruebas de correspondencia entre el código máquina y el código
fuente

22/10/2021
Métodos formales
[Balzer R. A 15 Year Perspective on Automatic Programming. IEEE Transactions on Software Engineering,
vol.11, núm.11, páginas 1257-1268, Noviembre 1985 ]
Especificación
Tranformación
Interactiva
Transformación
Automática
Optimización
Validación de
Especificación
Mantenimiento
Especificación
de alto nivel
(prototipo)
Desarrollo
Formal
Desiciones
Especificación
de bajo nivel
Código
Fuente
Especificación
Informal

22/10/2021
Ventajas de los métodos formales
• Especificación
– La ingeniería de Software tiene problemas para la especificación
de comportamientos.
– La especificación formal proporciona una mayor precisión.
– Detección de ambigüedades y omisiones.
• Verificación
– “Se esta construyendo el producto correcto.”
– Con los métodos comunes a pesar de la generación de
manuales de pruebas rigurosos solo se logra eliminar los errores
más evidentes.
– Las técnicas de verificación formal dependen de
especificaciones matemáticas precisas.
• Validación
– “Se esta construyendo el producto correcto.”
– Utilizado principalmente para sistemas complejos como aquellos
de modelado y simulación.

22/10/2021
Ventajas de los métodos formales
• Se comprende mejor el sistema.
• La comunicación con el cliente mejora ya que se
dispone de una descripción clara y no ambigua de
los requisitos del usuario.
• El sistema se describe de manera más precisa.
• El sistema se asegura matemáticamente que es
correcto según las especificaciones.
• Mayor calidad software respecto al cumplimiento
de las especificaciones.
• Mayor productividad

22/10/2021
Desventajas de los métodos formales
• El desarrollo de herramientas que apoyen la
aplicación de métodos formales es complicado y
los programas resultantes son incómodos para los
usuarios.
• Los investigadores por lo general no conocen la
realidad industrial.
• Es escasa la colaboración entre la industria y el
mundo académico, que en ocasiones se muestra
demasiado dogmático.
• Se considera que la aplicación de métodos
formales encarece los productos y ralentiza su
desarrollo

22/10/2021
Los 10 mandamientos
(Bowen, Hinchley)
1. Seleccionarás la notación adecuada.
2. Formalizarás, pero no de más.
3. Estimarás los costes.
4. Poseerás un experto en métodos formales a tu
disposición.
5. No abandonarás tus métodos formales de desarrollo.
6. Documentarás suficientemente.
7. No comprometerás los estándares de calidad.
8. No serás dogmático.
9. Comprobarás, comprobarás y volverás a comprobar.
10. Reutilizarás cuanto puedas.

22/10/2021
Los 7 mitos de Hall
1. Los métodos formales pueden garantizar la
corrección del software
2. Todos los métodos formales se refieren a la
corrección de programas
3. Son de utilidad solamente para sistemas de altas
prestaciones/alta integridad (safety-critical)
4. Su uso requiere una alta cualificación o
entrenamiento matemático
5. Incrementan el coste de desarrollo
6. Son inadecuados y no serán aceptados por los
clientes
7. No se usan en la realidad en proyectos software de
gran escala

22/10/2021
Fracasos de la Aplicación de MF
• Algoritmo de división del procesador Pentium
(1993)
– Costo: 475 millones de dólares, credibilidad de Intel
• Explosión de la misión espacial Ariane 5 (1996)
– Costo: 500 millones de dólares
• Orbitador climático de Marte (1998)
– Costo: 125 millones de dólares

22/10/2021
Logros de la Aplicación de MF
• Metéor, Matra Transport, France:
– Herramienta: Atelier-B
– Resultado: No se encontró ningún error durante el
testing de 80000 líneas de código.
• SPOT 4, CS-CI, France:
– Herramienta: IFAD VDM-SL Toolbox
– Resultado: Se redujo un 38% menos de código
fuente y un 36% menos de esfuerzo total

22/10/2021
Métodos formales
OO
Conceptos
básicos
Fundamentos
matemáticos
básicos
Fundamentos
sobre OO
Proceso de
desarrollo de
software
Modelos
matemáticos
Lógica de primer
orden
Especificaciónes
algebraicas
Redes de Petri
Lógica temporal
Métodos semi-
formales
Métodos
generalistas
Métodos
orientados a
sistemas reactivos
Métodos
orientados a
componentes
Métodos formales
Métodos basados
en lógica de
primer orden
Métodos basados
en formalismos
algebraicos
Métodos basados
en redes de Petri
Métodos basados
en lógica temporal

22/10/2021
Clasificación de métodos Formales
La clasificación más común se realiza en base al modelo matemático
subyacente en cada método, de esta manera podrían clasificarse en:
• Especificaciones basadas en lógica de primer orden y teoría de
conjuntos: permiten especificar el sistema mediante un concepto
formal de estados y operaciones sobre estados. Los datos y
relaciones/funciones se describen en detalle y sus propiedades se
expresan en lógica de primer orden. La semántica de los lenguajes
está basada en la teoría de conjuntos. Los métodos de este tipo
más conocidos son: Z, VDM y B.
• Especificaciones algebraicas: proponen una descripción de
estructuras de datos estableciendo tipos y operaciones sobre esos
tipos. Para cada tipo se define un conjunto de valores y operaciones
sobre dichos valores. Las operaciones de un tipo se definen a
través de un conjunto de axiomas o ecuaciones que especifican las
restricciones que deben satisfacer las operaciones. Métodos más
conocidos: Larch, OBJ, TADs.

22/10/2021
• Especificación de comportamiento:
– Métodos basados en álgebra de procesos: modelan la
interacción entre procesos concurrentes. Esto ha potenciado su
difusión en la especificación de sistemas de comunicación
(protocolos y servicios de telecomunicaciones) y de sistemas
distribuidos y concurrentes. Los más conocidos son: CCS,CSP y
LOTOS.
– Métodos basados en Redes de Petri: una red de petri es un
formalismo basado en autómatas, es decir, un modelo formal
basado en flujos de información. Permiten expresar eventos
concurrentes. Los formalismos basados en redes de petri
establecen la noción de estado de un sistema mediante lugares
que pueden contener marcas. Un conjunto de transiciones (con
pre y post condiciones) describe la evolución del sistema
entendida como la producción y consumo de marcas en varios
puntos de la red.

22/10/2021
– Métodos basados en lógica temporal: se usan para
especificar sistemas concurrentes y reactivos. Los sistemas
reactivos son aquellos que mantienen una continua interacción
con su entorno respondiendo a los estímulos externos y
produciendo salidas en respuestas a los mismos, por lo tanto el
orden de los eventos en el sistema no es predecible y su
ejecución no tiene por qué terminar.

22/10/2021
Contenido
– Cascada
– Incremental
– Evolutivo
– Concurrentes

22/10/2021
¿Cuál es el más adecuado?
Modelo de
proceso
Desempeño
con requisitos
y arquitectura
no
predefinidos
Produce
software
altamente
fiable
Gestión de
riesgos
Permite
correcciones
sobre la
marcha
Visión del
progreso por
el Cliente y el
Jefe del
proyecto
Codificar y
corregir
Bajo Bajo Bajo Alto Medio
Desarrollo
En cascada
Bajo Alto Bajo Bajo Bajo
Desarrollo
Evolutivo
Alto Medio Medio Alto Alto
Desarrollo
formal de
sistemas
Bajo Alto Bajo a Medio Bajo Bajo
Desarrollo
basado en
reutilización
Medio Bajo a Alto Bajo a Medio Alto Alto
Desarrollo
Incremental
Bajo Alto Medio Bajo Bajo
Desarrollo
Espiral
Alto Alto Alto Medio Medio

22/10/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

22/10/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

22/10/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

22/10/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.

22/10/2021
Contenido
– Cascada
– Incremental
– Evolutivo
– Concurrentes

22/10/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

22/10/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

22/10/2021
Contenido
– Cascada
– Incremental
– Evolutivo
– Concurrentes

22/10/2021
Rational Unified Process (RUP). Etapas

22/10/2021
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

22/10/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

22/10/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)

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

22/10/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

22/10/2021
Rational Unified Process
• Ventajas
– Desarrollo iterativo.
– Utilizan la metodologíaUML (Unified Modeling
Language).
– Produce artefactos (Componentes).
– Modelo de software visual.
– Proceso complejo.
– Conveniente para sistemas grandes.
• Desventaja
– No tener personal preparado en la metodología.
– Deber ir en consistencia con la gestión del proyecto

22/10/2021
Contenido
– Cascada
– Incremental
– Evolutivo
– Concurrentes

22/10/2021
Evaluación y mejora del proceso
• La existencia de un proceso del
software no es garantía de que:
– el software se entregue a tiempo
– que satisfaga las necesidades de
los consumidores
– que tenga las características
técnicas que conducirán a
características de calidad de largo
plazo
• El proceso en sí debe evaluarse
para garantizar que cumple con
ciertos criterios de proceso
básicos que se haya demostrado
que son esenciales para el éxito
de la ingeniería de software

22/10/2021
Evaluación y mejora del proceso
• En las últimas décadas se han propuesto numerosos
enfoques para la evaluación y mejora de un proceso del
software:
– Método de evaluación del estándar CMMI para el proceso de mejora:
proporciona un modelo de cinco fases para evaluar el proceso: inicio,
diagnóstico, establecimiento, actuación y aprendizaje.
– Evaluación basada en CMM para la mejora del proceso interno:
proporciona una técnica de diagnóstico para evaluar la madurez relativa de
una organización de software; usa el SEI CMM como la base de la
evaluación.
– SPICE (ISO/IEC 15504): estándar que define un conjunto de
requerimientos para la evaluación del proceso del software. El objetivo del
estándar es ayudar a las organizaciones a desarrollar una evaluación
objetiva de cualquier proceso del software definido.
– ISO9001:2000 para software: estándar genérico que se aplica a cualquier
organización que desee mejorar la calidad general de los productos,
sistemas o servicios que proporciona. Por tanto, el estándar es
directamente aplicable a las organizaciones y compañías de software

22/10/2021
Final de la unidad
MODELOS DE PROCESO
Unidad 2

PSW Unidad 2 MODELOS DE PROCESO

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to PSW Unidad 2 MODELOS DE PROCESO

Similar to PSW Unidad 2 MODELOS DE PROCESO (20)

More from Franklin Parrales Bravo

More from Franklin Parrales Bravo (20)

Recently uploaded

Recently uploaded (11)

PSW Unidad 2 MODELOS DE PROCESO