Transcript Clase modelo

Metodologías de Desarrollo de
Software (Ciclo de Vida)
Juan Carlos Olivares Rojas
MSN: [email protected]
[email protected]
http://antares.itmorelia.edu.mx/~jcolivar/
@jcolivares
Social Network: Facebook, LinkedIn. Hi5
Agenda
• Ciclo de Vida
• Metodologías de Desarrollo Tradicionales
• Metodologías Ágiles
• Conclusiones
Problema
• Su profesor necesita realizar un nudo de
corbata para salir a reunión el problema es que
no sabe cómo hacerlo.
• La primera forma de hacerlo es a través de
outsorcing (que alguien le ayude).
• Otra forma de tratar de hacerlo es a través de
la experiencia y el sentido común.
• Si todas estas fallan, ¿qúe se puede hacer?
Solución
• La forma más fácil es a través de una
metodología para realizar nudos de corbatas
como la planteada en http://www.nudo-decorbata.com/
• Lo primero que se tiene que saber es si debe
ser un tipo especial de corbata o no. Los tipos
pueden ir desde nudo de corbata simple, doble,
windsor, medio windsor, nudo pequeño.
Tipos de Nudos
Tipos de nudos
Metodologías
• Las metodologías son un conjunto de mejores
prácticas que si no se llevan a la práctica o se
hacen a medias es muy difícil que se tenga
calidad.
• Aun siguiendo las recomendaciones, una
metodología no garantiza que un producto
tenga calidad.
• EVITAR FRACASO/RECHAZO
Uso de Mejores Prácticas
• Nos orientan hacia mejores resultados
Proyecto Aplicativo
• Mayo
Proyecto Aplicativo
• Junio
Proyecto Aplicativo
• Julio
Proyecto Aplicativo
• Agosto
Definición del Problema/Reto
• Cada buen final requiere de un buen inicio
Modelos de Desarrollo
• ¿Qué camino seguiremos?
Análisis de Requerimientos
• El planteamiento es lo importante, no la
velocidad
Diseño del Software
• ¿Cómo debo de hacerlo?
Sistemas de Alta Integridad
• Sigamos un método confiable y seguro
Métodos formales
• Cálculos precisos, especificación matemática.
Administración de Proyectos
• Una buena administración siempre nos llevará
por el camino adecuado
Aseguramiento Calidad (SQA)
• Se debe tener un buen manejo de calidad
Ambientes de Desarrollo Sw
• Una buena herramienta de Sw no tiene
precio…
Mantenimiento y Evolución
• El modelo de mantenimiento debe de ser
preparado
Mantener el Éxito
• Cada buen final requiere de un buen inicio…
Factores de Fracaso
• Todo se debe a problemas de comunicación…
• De entendimiento del problema (Implicación de
los Usuarios, Apoyo de los directivos,
Enunciado claro de los requisitos)
• De la visión del proyecto entre los clientes,
usuarios
y
desarrolladores
(Falta
de
información por parte de los usuarios,
Especificaciones y requisitos incompletos,
Especificaciones y requisitos cambiantes)
Factores de Fracaso
Factores de Fracaso
• “La parte más difícil de construir de un sistema
de software es precisamente saber QUÉ
construir. Ninguna otra parte del trabajo
conceptual es tan difícil como establecer los
requerimientos técnicos detallados, incluyendo
todas las interfaces con gente, máquinas y
otros sistemas. Ninguna otra parte del trabajo
afecta tanto el sistema si es hecha mal.
Ninguna otra parte es más difícil de rectificar
después” (Brooks)
Comunicación
Modelos de Ciclo de vida
Análisis
Requerimientos
Diseño del
Sistema
Diseño de
Objetos
Codificación
Pruebas
Instalación
Mantenimiento
Modelo Lineal/Cascada
Modelos de Ciclo de Vida
Análisis de los
Requerimientos
Mantenimiento
Diseño del
Sistema
Instalación
Diseño de
Objetos
Pruebas
Codificacion
Realmente no es tan lineal
OpenUP
• Originado como resultado de la compra de
Rational creador de RUP por parte de IBM.
• UP es toda una metodología para el desarrollo
de software:
Requisitos del usuario
Proceso de desarrollo
de software
Sistema de software
• Se caracteriza por ser una forma disciplinada de
asignar tareas y responsabilidades en una empresa
de desarrollo (quién hace qué, cuándo y cómo).
OpenUP
• Su objetivo es Asegurar la producción de software de
calidad dentro de plazos y presupuestos predecibles.
Dirigido por casos de uso, centrado en la arquitectura,
iterativo (mini-proyectos) e incremental (versiones).
• También es considerado un producto:
• Desarrollado y mantenido por la comunidad libre
• Actualizado constantemente para tener en cuenta las
mejores prácticas de acuerdo con la experiencia.
OpenUP
• Aumenta la productividad de los desarrolladores
mediante acceso a:
• Base de conocimiento, plantillas y herramientas.
• Se centra en la producción y mantenimiento de
modelos del sistema más que en producir
documentos.
• UP es una guía de cómo usar UML de la forma más
efectiva.
• Existen herramientas de apoyo a todo el proceso:
Modelamiento visual, programación, pruebas, etc.
OpenUP
• UP pretende implementar las mejores prácticas
actuales en ingeniería de software:
•
•
•
•
•
•
Desarrollo iterativo del software
Administración de requerimientos
Uso de arquitecturas basadas en componentes
Modelamiento visual del software
Verificación de la calidad del software
Control de cambios
OpenUP
• Desarrollo Iterativo:
• El software moderno es complejo y novedoso. No es
realista usar un modelo lineal de desarrollo como el
de cascada.
• Un proceso iterativo permite una comprensión
creciente de los requerimientos a la vez que se va
haciendo crecer el sistema.
• UP sigue un modelo iterativo que aborda las tareas
más riesgosas primero. Con esto se logra reducir los
riesgos del proyecto y tener un subsistema ejecutable
tempranamente.
OpenUP
• Administración de Requerimientos:
• Obtener los requerimientos
• Organizarlos
• Documentar requerimientos
restricciones
de
funcionalidad
• Rastrear y documentar decisiones
• Captar y comunicar requerimientos del negocio
y
OpenUP
• Arquitectura basada en Componentes:
• El proceso se basa en diseñar tempranamente una
arquitectura base ejecutable.
•
•
•
•
•
La arquitectura debe ser:
Flexible
Fácil de modificar
Intuitivamente comprensible
Promueve la reutilización de componentes
OpenUP
• Modelamiento visual de la estructura y el
comportamiento de la arquitectura y los componentes.
•
•
•
•
•
•
Bloques de construcción:
Ocultan detalles
Permiten la comunicación en el equipo de desarrollo
Permiten analizar la consistencia:
entre las componentes
entre diseño e implementación
OpenUP
• Verificación de cualidades:
• No sólo la funcionalidad es esencial, también el
rendimiento y la confiabilidad.
• UP ayuda a planificar, diseñar, implementar, ejecutar
y evaluar pruebas que verifiquen estas cualidades.
• El aseguramiento de la calidad es parte del proceso
de desarrollo y no la responsabilidad de un grupo
independiente.
OpenUP
• Control de Cambios:
• Los cambios son inevitables, pero es necesario
evaluar si éstos son necesarios y rastrear su impacto.
• UP indica como controlar, rastrear y monitorear los
cambios dentro del proceso iterativo de desarrollo.
OpenUP
• UP divide el proceso de desarrollo en ciclos, teniendo
un producto al final de cada ciclo.
• Cada ciclo se divide en cuatro Fases:
•
•
•
•
Inicio
Elaboración
Construcción
Transición
• Cada fase concluye con un hito bien definido donde
deben tomarse ciertas decisiones.
OpenUP
• Fases de UP
OpenUP
• Fase de Inicio
• Se establece la oportunidad y alcance el proyecto.
• Se identifican todas las entidades externas con las
que se trata (actores) y se define la interacción a un
alto nivel de abstracción:
• Identificar todos los casos de uso
• Describir algunos en detalle
OpenUP
• La oportunidad del negocio incluye:
•
•
•
•
Criterios de éxito
Identificación de riesgos
Estimación de recursos necesarios
Plan de las fases incluyendo hitos
– Productos:
– Un documento de visión general:
•
•
•
•
•
Requerimientos generales del proyecto
Características principales
Restricciones
Modelo inicial de casos de uso (10% a 20 % listos).
Glosario.
OpenUP
• Caso de negocio:
•
•
•
•
Contexto
Criterios de éxito
Pronóstico financiero
Identificación inicial de riesgos.
• Plan de proyecto.
• Uno o más prototipos.
OpenUP
• Hito:
Objetivos del
Ciclo de Vida
Inicio
Elaboración
Construcción
Transición
– Las partes interesadas deben acordar el alcance y la
estimación de tiempo y costo.
– Comprensión de los requerimientos plasmados en
casos de uso.
OpenUP
• Fase de Elaboración
• Objetivos:
•
•
•
•
Analizar el dominio del problema
Establecer una arquitectura base sólida
Desarrollar un plan de proyecto
Eliminar los elementos de mayor riesgo para el desarrollo
exitoso del proyecto
• Visión de “una milla de amplitud y una pulgada de
profundidad” porque las decisiones de arquitectura
requieren una visión global del sistema.
OpenUP
• Productos:
• Es la parte más crítica del proceso
• Se puede decidir si vale la pena seguir adelante
• A partir de aquí la arquitectura, los requerimientos y
los planes de desarrollo son estables.
• Ya hay menos riesgos y se puede planificar el resto
del proyecto con menor incertidumbre.
OpenUP
• Se construye
contemple:
una
arquitectura
ejecutable
que
• Los casos de uso críticos
• Los riesgos identificados
• Modelo de casos de uso (80% completo) con
descripciones detalladas.
• Otros requerimientos no funcio-nales o no asociados
a casos de uso.
• Descripción de la Arquitectura del Software.
OpenUP
• Un prototipo ejecutable de la arquitectura.
• Lista revisada de riesgos y del caso de negocio.
• Plan de desarrollo para el resto del proyecto.
• Un manual de usuario preliminar.
OpenUP
• Hito:
Arquitectura de
Ciclo de Vida
Concepción
•
•
•
•
Elaboración
Construcción
Transición
Condiciones de éxito de la elaboración:
¿Es estable la visión del producto?
¿Es estable la arquitectura?
¿Las pruebas de ejecución demuestran que los
riesgos han sido abordados y resueltos?
• ¿Es el plan del proyecto algo realista?
• ¿Están de acuerdo con el plan todas las personas
involucradas?
OpenUP
• Construcción:
• En esta fase todas las componentes restantes se
desarrollan e incorporan al producto. Todo es probado
en profundidad.
• El énfasis está en la producción eficiente y no ya en la
creación intelectual.
• Puede hacerse construcción en paralelo, pero esto
exige una planificación detallada y una arquitectura
muy estable.
OpenUP
• Productos:
• El producto de software integrado y corriendo en la
plataforma adecuada.
• Manuales de usuario.
• Una descripción del “release” actual.
OpenUP
Capacidad
Operacional
• Hito:
Concepción
Elaboración
Construcción
Transición
• Se obtiene un producto Beta que debe decidirse si
puede ponerse en ejecución sin mayores riesgos.
• Condiciones de éxito:
• ¿El producto está maduro y estable para instalarlo en
el ambiente del cliente?
• ¿Están los interesados listos para recibirlo?
OpenUP
• Transición:
• El objetivo es traspasar el software desarrollado a la
comunidad de usuarios.
• Una vez instalado surgirán nuevos elementos que
implicarán nuevos desarrollos (ciclos).
• Incluye:
• Pruebas Beta para validar el producto con las expectativas
del cliente
• Ejecución paralela con sistemas antiguos
OpenUP
• Conversión de datos
• Entrenamiento de usuarios
• Distribuir el producto
• Los objetivos de la fase de transición:
• Obtener autosuficiencia de parte de los usuarios.
• Concordancia en los logros del producto de parte de
las personas involucradas.
• Lograr el consenso cuanto antes para liberar el
producto al mercado.
OpenUP
• Hito:
Concepción
Elaboración
Construcción
Transición
Producto
• En esta etapa se obtiene el software final.
OpenUP
• Definiciones:
• Un trabajador define el comportamiento y las
responsabilidades de un individuo.
• Es como un “sombrero” que la persona usa durante el
proyecto:
• Una persona puede tener varios sombreros
• Es el rol que desempeña en un momento dado
• Responsabilidades:
• Hacer una serie de actividades
• Ser el responsable de una serie de artefactos
OpenUP
• Actividades:
• Una actividad es una unidad de trabajo que se asigna
a un trabajador. Ej.:
• Crear o modificar un artefacto
• Una actividad lleva entre un par de horas y un par de
días, involucra un solo trabajador y un número
pequeño de artefactos.
OpenUP
• Las actividades se consideran en la planificación y
evaluación del progreso del proyecto.
•
•
•
•
•
Ejemplos:
Planificar una iteración - Administrador de proyecto
Encontrar actores y casos de uso - Analista
Revisar el diseño - Revisor de diseño
Ejecutar pruebas de performance - Ing. de pruebas de
performance
OpenUP
• Asignación de Actividades:
Trabajador
Actividad
Pablo
Diseñador
Diseño de Objetos
María
Autor de Casos de Uso
Detallar un Caso de Uso
José
Diseñador de Casos de Uso
Diseñar un Caso de Uso
Silvia
Revisor de Diseño
Revisar el Diseño
Arquitecto
Análisis de Arquitectura
Diseño de Arquitectura
Recurso
Eduardo
OpenUP
• Artefactos:
• Elementos de información producidos, modificados o
usados por el proceso.
• Son los productos tangibles del proyecto.
• Son usados por los trabajadores para realizar nuevas
actividades y son el resultado de esas actividades.
OpenUP
• Flujos de Trabajo:
• Una lista de actividades, trabajadores y artefactos
constituye un proceso.
• Un flujo de trabajo es una secuencia de actividades
que produce un resultado valioso.
• No siempre es posible representar flujos de trabajo.
OpenUP
• Flujos de Trabajo:
Análisis de
Arquitectura
Diseño de
Arquitectura
Describir
Concurrencia
Describir
Distribución
Arquitecto
Análisis de
Casos de Uso
Diseño de
Casos de Uso
Diseñador de
Casos de Uso
Análisis de
Objetos
Diseño de
Objetos
Diseñador
Revisor de
Diseño
Revisar el
Análisis
Revisar el
Diseño
Revisar la
Arquitectura
OpenUP
• Flujos de Trabajo Esenciales:
Flujos de Trabajo
de Ingeniería
Flujos de Trabajo
de Apoyo
OpenUP
• Existen
habitualmente
problemas
de
comunicación entre ingenieros de software e
ingenieros de negocios.
• UP proporciona un lenguaje y proceso común
para estos dos ámbitos.
• Para el modelamiento del negocio se usan
“business use cases” (casos de uso del
negocio):
• La forma en que el software dará apoyo al
negocio.
OpenUP
• Requerimientos:
• Los desarrolladores y clientes deben acordar
qué es lo que el sistema debe hacer:
•
•
•
•
•
Relevar requerimientos
Documentar funcionalidad y restricciones
Documentar decisiones
Identificar actores
Identificar casos de uso
OpenUP
• Los casos de uso describen la funcionalidad.
• Los requerimientos no funcionales se incluyen
en una especificación complementaria.
C
lie
n
t
eR
e
c
ic
I
m
la
r
A
d
p
r
im
ir
I
O
m
in
is
t
p
r
a
e
r
OpenUP
• Análisis y Diseño:
• Descripción de cómo se implementará el
sistema: un plano
• Debe:
• Ejecutar las tareas y funciones descritas en los
casos de uso
• Satisfacer todos los requerimientos
• Flexible a cambios
OpenUP
• El diseño se
arquitectura.
centra
en
la
noción
de
• Diseñar y validar la arquitectura es una tarea
esencial.
• El modelo de diseño consta de
• Clases estructuradas en paquetes
• Diseños de subsistemas con interfaces
definidas (componentes)
• Forma de colaboración entre las clases.
OpenUP
• Implementación
• Propósito:
• Definir la organización del código
• Implementar clases y objetos en forma de
componentes (fuente, ejecutables, etc.)
• Probar las componentes desarrolladas
• Integrar las componentes en un sistema
ejecutable
OpenUP
• Pruebas:
• Propósito:
• Verificar la interacción entre los objetos
• Verificar
la
integración
apropiada
de
componentes
• Verificar que se satisfacen los requerimientos
• Identificar los defectos y corregirlos antes de la
instalación
OpenUP
• UP describe como planear y ejecutar estas
pruebas.
• UP propone probar las componentes desde el
principio:
• Confiabilidad, funcionalidad y performance
• Las pruebas de regresión son importantes en
desarrollos iterativos.
OpenUP
• Distribución:
• Producir un producto y hacerlo llegar a sus
usuarios finales.
•
•
•
•
•
Incluye varias actividades:
Producir un “release”
Empaquetar el software
Distribuir el software
Instalar el software
OpenUP
• Administración de Proyectos:
• Es el arte de balancear objetivos contrarios,
manejar riesgos y producir software que
satisface a clientes y usuarios.
• UP incluye:
• Un framework para manejo de proyectos de
software
OpenUP
• Guías para planificación, provisión de personal,
ejecución y monitoreo de planes
• Un framework para manejar riesgos
• Administración de Configuración y del Cambio:
• Forma de controlar los artefactos producidos
por las personas que trabajan en el proyecto.
OpenUP
• Algunos problemas habituales:
• Actualizaciones simultáneas
• Múltiples versiones
•
•
•
•
UP da guías para:
Desarrollos en paralelo
Automatizar la construcción
Administrar defectos
OpenUP
• Ambiente:
• Ambiente y herramientas de desarrollo que
harán posible llevar a cabo el proyecto.
• UP guía en la configuración de un ambiente de
proceso apropiado a cada proyecto.
Metodologías Ágiles
• Se
siguen
desarrollando
las
mismas
actividades del proceso de desarrollo de
software, sólo difieren en la forma de hacerlo.
• Las Metodologías Ágiles se fundamentan en 4
principios básicos (manifiesto ágil):
• Al individuo y las interacciones en el equipo de
desarrollo más que a las actividades y las
herramientas.
Metodologías Ágiles
• Desarrollar software que funciona más que
conseguir una buena documentación
Minimalismo respecto del modelado y la
documentación del sistema.
• La colaboración con el cliente más que la
negociación de un contrato.
• Responder a los cambios más que seguir
estrictamente una planificación.
Metodologías Ágiles
• Es más adecuada para los cambios reduciendo
los errores (costos) y logrando la satisfacción
de los clientes.
Tradicional
Costo
del
cambio
Suposición MAs
tiempo
Metodologías Ágiles
Metodología Ágil
Metodología Tradicional
Pocos Artefactos. El modelado es
prescindible, modelos desechables.
Más Artefactos. El modelado es esencial,
mantenimiento de modelos
Pocos Roles, más genéricos y flexibles
Más Roles, más específicos
No existe un contrato tradicional, debe ser
bastante flexible
Existe un contrato prefijado
Cliente es parte del equipo de desarrollo
(además in-situ)
El cliente interactúa con el equipo de
desarrollo mediante reuniones
Orientada a proyectos pequeños. Corta
duración (o entregas frecuentes), equipos
pequeños (< 10 integrantes) y trabajando en
el mismo sitio
Aplicables a proyectos de cualquier tamaño,
pero suelen ser especialmente
efectivas/usadas en proyectos grandes y con
equipos posiblemente dispersos
La arquitectura se va definiendo y mejorando
a lo largo del proyecto
Se promueve que la arquitectura se defina
tempranamente en el proyecto
Énfasis en los aspectos humanos: el individuo
y el trabajo en equipo
Énfasis en la definición del proceso: roles,
actividades y artefactos
Se esperan cambios durante el proyecto
Se espera que no ocurran cambios de gran
impacto durante el proyecto
Metodologías Ágiles
• Crystal Methodologies, Alistarir Cockburn,
www.crystalmethodologies.org
• SCRUM, Ken Schwaber & Jeff Sutherland,
www.controlchaos.com
• DSDM (Dynamic
Method),
www.dsdm.org
Systems
Development
• Lean Programming, Mary Poppendieck,
www.poppendieck.com
Metodologías Ágiles
• FDD (Feature-Driven Development), Peter
Coad & Jeff De Luca, www.nebulon.com/fdd,
www.coad.com/peter/#fdd
• Extreme Programming, Kent Beck
www.extremeprogramming.org,
www.xprogramming.com
• Adaptative
Software
Development,
Highsmith www.adaptivesd.com
Jim
Metodologías Ágiles
• Las dos principales metodologías ágiles son
scrum y XP (eXtreme Programming).
• Cualquiera que fuera el método ágil debe de
cumplir con el manifiesto ágil.
• Scrum es certificable mientras que XP no lo es,
pero muchos equipos de desarrollo la manejan
ampliamente.
XP
• Es una metodología idónea para equipos de
desarrollo pequeños menores a 10 personas.
• Se caracteriza por ser una metodología “ligera”
(excluye todo lo que no sirve dejando la
esencia o “sabor” de las cosas).
• Se centra en la implementación (codificación)
por lo que es ideal para entornos dinámicos.
XP
• La comunicación se da de manera muy
informal, generalmente verbal.
• Las metodologías ágiles se preocupan por
inculcar valores y XP no es la excepción, sus
principales valores son:
– Comunicación
– Simplicidad
– Retroalimentación
– Coraje.
XP
• Los actores que participan en el desarrollo de
software son:
• Programador: responsable de decisiones técnicas y
de construir el sistema. No hay distinción entre
analistas, diseñadores o codificadores. Es decir, en
XP los programadores modelan, codifican y prueban.
• Clientes: son parte del sistema, determinar que
construir y cuando, realizan test para determinar
cuando algo está completo.
XP
• Entrenador (Coach): es el líder del equipo.
Tiende a estar en un segundo plano a medida
que el equipo madura
• Rastreador (Tracker): también llamado Metric
Man, se encarga de observar sin molestar,
debe conservar datos históricos.
• Probador (Tester): Ayuda al cliente con las
pruebas funcionales.
XP
• El proceso de desarrollo en XP se puede
resumir como:
Mientras(sistema_es_útil) {
Captar requisitos
User Stories
Methaphor
Planificar
Release planning
Iteration planning
XP
Desarrollar
Programming
Presentar la entrega
Releasing
}
• Puntos clave: el juego de planificación,
entregas
cortas,
diseños
simples,
refactorización. LA GRAN FOTO
XP
XP
• XP es una metodología muy utilizada pero
como todo tiene también sus puntos débiles.
Entre ellos que pocos son los que utilizan la
metodología completa.
• A continuación se muestran y se explican las
prácticas que componen a la Programación
Extrema.
• XP no es sólo tirar líneas de código fuente.
XP
• Historias del Usuario
• Tareas de Ingeniería (bitácora de lo que se
está realizando)
• Pruebas de Aceptación
• Pruebas Unitarias y de Integración
• Plan de la Entrega
• Código
XP
Historia de Usuario
Número: 1
Nombre: Enviar artículo
Usuario: Autor
Modificación de Historia Número:
Iteración Asignada: 2
Prioridad en Negocio: Alta
Puntos Estimados:
(Alta / Media / Baja)
Riesgo en Desarrollo:
Puntos Reales:
(Alto / Medio / Bajo)
Descripción:
Se introducen los datos del artículo (título, fichero adjunto, resumen, tópicos) y de los autores
(nombre, e-mail, afiliación). Uno de los autores debe indicarse como autor de contacto. El sistema
confirma la correcta recepción del artículo enviando un e-mail al autor de contacto con un userid y
password para que el autor pueda posteriormente acceder al artículo.
Observaciones:
XP
XP
• Espacio abierto
• Mesas centrales
• Cubículos en el espacio exterior
XP
• Reunión diaria: “Stand-up Meeting”
– Todo el equipo
– Problemas
– Soluciones
• De pie en un círculo
– Evitar discusiones largas
– Sin conversaciones separadas
XP
simple design
CRC cards
spike solut ions
prot ot ypes
user st ories
values
accept ance t est crit eria
it erat ion plan
refact oring
pair
programming
Release
sof t ware increment
project velocit y comput ed
unit t est
cont inuous int egrat ion
accept ance t est ing
Adaptative Sw Development
adapt ive cycle planning
uses mission st at ement
project const raint s
basic requirement s
Requirement s gat hering
JAD
mini-specs
t ime-boxed release plan
Release
sof t ware increment
adjust ment s f or subsequent cycles
component s implement ed/ t est ed
focus groups for feedback
formal t echnical reviews
post mort ems
Scrum
• Es otra metodología ágil que entre sus
principales características están:
• Desarrollo de software por medio de iteraciones
(Sprints).
• Indicado para proyectos con un rápido cambio
de requerimientos.
• Gran protagonismo de reuniones a lo largo del
proyecto.
Scrum
• Originada a finales de los 80’s se empezó a
popularizar a mediados de los 90’s. En inglés
americano se denomina melé y hace referencia
a una jugada de rugby.
• Los roles se dividen en cerdo y gallina para
indicar el grado de participación en el proyecto.
Scrum
• Los actores que
metodología son:
intervienen
• Propietarios del producto
• Usuarios del poducto
• Scrum master
• Equipo de scrum.
en
esta
Scrum
Scrum
• Los sprints son la base del desarrollo en scrum,
consisten en una serie de actividades
previamente definidas en un lapso de 30 días.
• El product backlog es la lista de las tareas a
realizar durante todo el proyecto. No es una
lista fija. Se prioriza las tareas según los
requisitos de los usuarios o del propietario de la
aplicación.
Scrum
• Ejemplo de un sprint backlog
Scrum
• Sprint planning meeting: reunión que se realiza
antes de cada Sprint.
• Se hace conjuntamente con el Propietario del
producto el Scrum Master y el equipo Scrum.
• Enfocar la reunión hacia los requisitos más
prioritarios.
Scrum
• Revisión del sprint: se realiza al final de cada
Sprint.
• Se deben reunir el propietario de la aplicación
los usuarios así como el Scrum Master y su
equipo , además también es recomendable que
acudan ingenieros de otros proyectos para dar
su punto de vista.
Scrum
• Product owner:
• Definir la funcionalidad del producto
• Decidir las fechas de liberación y el contenido
(release)
• Aceptar o rechazar el producto
• Responsable del ROI
Scrum
• ¿Quiénes son products owner?
•
•
•
•
•
Analista
Tester
Usuario final
Cliente
Product Manager
Scrum
• Un rol de suma importancia
metodología es el escuchar.
en
esta
• Muchos problemas de desarrollo se pueden
solucionar fácilmente si se escucha a los
clientes, usuarios finales y equipos de
desarrollo.
Lean
• En una era donde ser esbelto es lo in ,
¿podemos poner a dieta nuestros procesos de
desarrollo de software?
• No
existe
una
definición
formal
de
metodologías esbeltas simplemente se usan
los principios del pensamiento ágil. Cada autor
varía los principios manejados. A continuación
se muestran algunos principios básicos.
Lean
• Eliminar el desperdicio
• Construir con calidad
• Crear conocimiento
•
•
•
•
Postergar compromiso
Entregas rápidas
Repetar a las personas
Optimizar el todo
Lean
• Mito: Especificación
desperdicio
temprana
reduce
• ¿Qué es desperdicio?
– Lo que no agrega valor
– Retraso en la entrega
– Funcionalidad no usada
• ¿Qué es valor?
– Ejemplos
– Stock: Requerimientos, Diseño, Bugs, …
el
Lean
• Mito: trabajo del tester es encontrar defectos
• Inspección para prevenir o para detectar defectos
• Listas de bug: desperdicio
• Pruebas automatizadas antes que el código
– De aceptación
– Integración
– Unitarias
Lean
• Cuidado…
– El código cambia
– Mucho código es desperdicio
– Menos código, menos oportunidad de defectos
• Solución
– KISS
– Refactoring
Lean
• Mito: las predicciones crean predictibilidad
• No es posible
– Conocer las necesidades al inicio
– Diseñar sin implementar
• Desarrollo de producto como aprendizaje y mejora
– Del producto / negocio
– Del proceso
– Difundir el conocimiento!
Lean
• Mito: Planificación es compromiso
• Tomar decisiones irreversibles
• Buscar soluciones reversibles
Lean
• Alta calidad
• Bajo costo
• Menos cambios
• Habilita a pruebas de concepto y mayor conocimiento
del cliente
• Mito: Apuro causa desperdicio
Lean
• Mito: existe la mejor manera de hacerlo
• Líderes emprendedores
• Expertos técnicos
• Control basado en objetivos
Lean
• Mito: optimizar por descomposición
• Ejemplos:
– El cliente quiere algo para ayer
– Testing está sobrecargado
• Las cadenas de valor que cruzan entre
empresas pueden ser costosas
OSSD
• Open Source Software Development es una
metodología de desarrollo de software que
comparte muchas características de los
considerados métodos ágiles: primero las
personas, entregables rápidos y pequeños,
entre otros.
• La parte de rigidez en el desarrollo de software
al no estar tan marcada hace de esta
metodología una opción no muy viable en cierto
tipo de proyectos
FDD
• Feature-Driven
Development
(Desarrollo
dirigido por características), es un proceso ágil
para el desarrollo de sistemas.
• Fue diseñado por Peter Coad, Eric Lefebvre y
Jeff DeLuca.
• No hace énfasis en la obtención de los
requerimientos sino en como se realizan las
fases de diseño y construcción.
FDD
• Propone tener etapas de cierre cada dos
semanas.
• Se basa en un proceso iterativo con iteraciones
cortas que producen un software funcional que
el cliente y la dirección de la empresa pueden
ver y monitoriar.
FDD
• El proceso consiste de cinco pasos
secuénciales durante los cuales se diseña y se
construye el sistema:
•
•
•
•
•
Desarrollo de un modelo global.
Construcción de una lista de funcionalidades.
Planeación por funcionalidad.
Diseño por funcionalidad.
Construcción por funcionalidad.
FDD
FDD
• Cuando comienza el desarrollo, los expertos
del dominio están al tanto de la visión, el
contexto y los requerimientos del sistema a
construir.
• Se divide el dominio global en áreas que son
analizadas detalladamente.
• Los desarrolladores construyen un diagrama de
clases o de objetos por cada área.
FDD
• Una funcionalidad es un ítem útil a los ojos del
cliente.
• La lista es elaborada por los desarrolladores y
es evaluada por el cliente.
• Se divide la lista en subconjuntos según la
afinidad
y
la
dependencia
de
las
funcionalidades.
FDD
• Una carácterística o rasgo se formula en base
al siguiente criterio:
• <acción><resultado><objeto>
• calcular el importe total de una venta
• determinar la última operación de un cajero
• validar la contraseña de un usuario.
FDD
• En este punto se procede a ordenar los
conjuntos de funcionalidades conforme a su
prioridad y dependencia, y se asigna a los
programadores jefes.
• Diseño por funcionalidades y Construcción por
funcionalidades:
– Se selecciona un conjunto de funcionalidades de la
lista.
– Se procede a diseñar y construir la funcionalidad
mediante un proceso iterativo.
FDD
• Una iteración puede tomar de unos pocos días
a un máximo de dos semanas. El proceso
iterativo incluye inspección de diseño,
codificación, pruebas unitarias, integración e
inspección de código.
FDD
Roles
• Está metodología se basa en muchos roles:
claves, soporte y adicionales.
• Entre los roles clave están:
• Director del Proyecto
– líder y administrador del proyecto
• Arquitecto Jefe
– Encargado del modelado global de la aplicación
Roles
• Director de Desarrollo:
– Lleva diariamente las actividades de desarrollo.
– Resuelve conflictos
• Programador en Jefe
• Propietario de clases
• Expertos de dominio
– Puede ser un usuario, un cliente, analista o una
mezcla de estos.
Roles
– Poseen el conocimiento de los requerimientos del
sistema.
– Pasa el conocimiento a los desarrolladores para
que se asegure la entrega de un sistema completo.
• Entre los roles de soporte se encuentran:
• Gestor de Domino
– Lidera el grupo de expertos del dominio
• Gestor de entregas
Roles
• Language Lawyer (Guru del Lenguaje)
– Posee un vasto conocimiento en un lenguaje
específico de programación o tecnología.
• Ingeniero de construcción
• Toolsmith / Herramentista
– Rol para la construcción de herramientas
específicas para el desarrollo, conversión de datos
y testeo.
– Puede trabajar en la preparación y mantenimiento
tanto de bases de datos o sitios web destinados al
proyecto.
Roles
• Administrador del sistema
– Configura, administra y repara los servidores,
estaciones de trabajo y equipos de desarrollo y
testeo utilizados por el equipo.
• Entre los roles adicionales se encuentran:
• Tester
• Deployer
– Encargado de convertir información existente al
nuevo sistema
• Escritores de documentos tecnicos
Proceso dx (UP Ágil)
• Creado por Robert Martin. El proceso dx es una
versión totalmente dócil del RUP.
• El dX está diseñado para gente que tiene que
usar el RUP pero quiere usar XP.
• Esta metodología es un ejemplo claro de
mezcla de metodologías.
Conclusiones
• Las metodologías ágiles no son nada nuevo
bajo el sol.
• Se tienen que “tropicalizar” las metodologías
para su buen funcionamiento.
• Existe una fuerte discusión en la academia
sobre si enfocarse a las metodologías ágiles o
no (al final de cuentas se debe entender el
proceso).
Conclusiones
• El proceso de desarrollo de software es un
proceso sociotecnológico.
• Para poder aprender la metodología se
necesita vivirla (se necesitan “horas de vuelo”).
• Las metodologías ágiles son muy buenas
cuando se domina el proceso en general.
Conclusiones
• Si el usuario final y/o clientes no colaboran es
sumamente difícil aplicar la metodología.
• Se debe aplicar métodos ágiles si se tienen
procesos bien definidos pero no funcionan de
manera adecuada frente a los campos o bien,
el equipo de desarrollo no está a gusto.
• Se siguen realizando el mismo proceso de
desarrollo de software sólo cambia la forma.
Conclusiones
• No importa que metodología se utilice solo hay
que llevarlo a la práctica como toda una
verdadera disciplina.
• La agilidad no cuesta. Lo único constante es el
cambio.
• A continuación se detalla una metodología de
calidad enfocada en el área de la función
informática para comprender las características
básicas de las metodologías de calidad.
References
• Forouzan, B. (2008), Data Comunications and
Networking, 4th. Edition, McGraw-Hill.
• Tanenbaum, A (2004). Computer Networks. 4th
Edition. Prentice Hall.
• Kurose, J. and Ross, K. (2007) Computer
Networking: A Top Down Approach 4th edition.
Addison-Wesley, July 2007.
¿Preguntas?