MetodologĂas de Desarrollo de Software (Ciclo de Vida) Juan Carlos Olivares Rojas MSN: juancarlosolivares@hotmail.com jcolivar@itmorelia.edu.mx http://antares.itmorelia.edu.mx/~jcolivar/ @jcolivares Social Network: Facebook, LinkedIn. Hi5
• Ciclo de Vida
Agenda
• 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-de-corbata.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
• Mayo
Proyecto Aplicativo
• Junio
Proyecto Aplicativo
• Julio
Proyecto Aplicativo
• Agosto
Proyecto Aplicativo
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 llevarรก por el camino adecuado
siempre
nos
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
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
OpenUP
• Administración de Requerimientos: • Obtener los requerimientos • Organizarlos • Documentar requerimientos de funcionalidad y restricciones • Rastrear y documentar decisiones
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.
• Fases de UP
OpenUP
• Fase de Inicio
OpenUP
• 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.
• Caso de negocio: • • • •
OpenUP
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.
• Productos:
OpenUP
• 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 una arquitectura ejecutable que contemple: • 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
• Construcción:
OpenUP
• 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.
• Productos:
OpenUP
• El producto de software integrado y corriendo en la plataforma adecuada. • Manuales de usuario. • Una descripción del “release” actual.
OpenUP
• Hito: Concepción
Elaboración
Capacidad Operacional
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?
• Transición:
OpenUP
• 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.
• Definiciones:
OpenUP
• 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 •
• Actividades:
OpenUP
• 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: Recurso
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
Eduardo
• Artefactos:
OpenUP
• 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.
• Flujos de Trabajo:
OpenUP
• 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.
• Flujos de Trabajo:
OpenUP
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.
• Requerimientos:
OpenUP
• 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.
Imprimir Informe
Cliente
Operador
Reciclar Administrar Depósito
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
• El diseño se arquitectura.
OpenUP 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)
• Implementación
OpenUP
• 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
• Pruebas:
OpenUP
• 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.
• Distribución:
OpenUP
• 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 personal, ejecución y monitoreo de planes
de
• Un framework para manejar riesgos • Administración Cambio:
de
Configuración
y
del
• 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
• Ambiente:
OpenUP
• 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 Systems Development Method), www.dsdm.org
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
â&#x20AC;˘ 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: Prioridad en Negocio: Alta (Alta / Media / Baja) Riesgo en Desarrollo: (Alto / Medio / Bajo)
Iteración Asignada: 2 Puntos Estimados:
Puntos Reales:
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
• Espacio abierto
XP
• 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
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
â&#x20AC;˘ 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.
• Product owner:
Scrum
• Definir la funcionalidad del producto • Decidir las fechas de liberación y el contenido (release) • Aceptar o rechazar el producto
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
Lean
• Mito: Especificación temprana reduce el desperdicio • ¿Qué es desperdicio?
– Lo que no agrega valor – Retraso en la entrega – Funcionalidad no usada
• ¿Qué es valor?
– Ejemplos – Stock: Requerimientos, Diseño, Bugs, …
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
• Cuidado…
Lean
– 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
• Alta calidad
Lean
• 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
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
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
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?