Metodologías de Desarrollo de Software (Ciclo de Vida)

Presentación del tema: "Metodologías de Desarrollo de Software (Ciclo de Vida)"— Transcripción de la presentación:

1 Metodologías de Desarrollo de Software (Ciclo de Vida)
Juan Carlos Olivares Rojas MSN: @jcolivares Social Network: Facebook, LinkedIn. Hi5

2 Agenda Ciclo de Vida Metodologías de Desarrollo Tradicionales
Metodologías Ágiles Conclusiones

3 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?

4 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 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.

5 Tipos de Nudos

6 Tipos de nudos

7 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

8 Uso de Mejores Prácticas
Nos orientan hacia mejores resultados

9 Proyecto Aplicativo Mayo

10 Proyecto Aplicativo Junio

11 Proyecto Aplicativo Julio

12 Proyecto Aplicativo Agosto

13 Definición del Problema/Reto
Cada buen final requiere de un buen inicio

14 Modelos de Desarrollo ¿Qué camino seguiremos?

15 Análisis de Requerimientos
El planteamiento es lo importante, no la velocidad

16 Diseño del Software ¿Cómo debo de hacerlo?

17 Sistemas de Alta Integridad
Sigamos un método confiable y seguro

18 Métodos formales Cálculos precisos, especificación matemática.

19 Administración de Proyectos
Una buena administración siempre nos llevará por el camino adecuado

20 Aseguramiento Calidad (SQA)
Se debe tener un buen manejo de calidad

21 Ambientes de Desarrollo Sw
Una buena herramienta de Sw no tiene precio…

22 Mantenimiento y Evolución
El modelo de mantenimiento debe de ser preparado

23 Mantener el Éxito Cada buen final requiere de un buen inicio…

24 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)

25 Factores de Fracaso

26 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)

27 Comunicación

28 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

29 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

30 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: 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). Requisitos del usuario Sistema de software Proceso de desarrollo de software

31 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.

32 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.

33 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

34 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.

35 OpenUP Administración de Requerimientos: Obtener los requerimientos
Organizarlos Documentar requerimientos de funcionalidad y restricciones Rastrear y documentar decisiones Captar y comunicar requerimientos del negocio

36 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

37 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

38 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.

39 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.

40 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.

41 OpenUP Fases de UP

42 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

43 OpenUP La oportunidad del negocio incluye: Productos:
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.

44 OpenUP Caso de negocio: Plan de proyecto. Uno o más prototipos.
Contexto Criterios de éxito Pronóstico financiero Identificación inicial de riesgos. Plan de proyecto. Uno o más prototipos.

45 OpenUP Hito: 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. Objetivos del Ciclo de Vida Inicio Elaboración Construcción Transición

46 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.

47 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.

48 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.

49 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.

50 OpenUP Hito: 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? Arquitectura de Ciclo de Vida Concepción Elaboración Construcción Transición

51 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.

52 OpenUP Productos: El producto de software integrado y corriendo en la plataforma adecuada. Manuales de usuario. Una descripción del “release” actual.

53 OpenUP Hito: 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? Capacidad Operacional Concepción Elaboración Construcción Transición

54 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

55 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.

56 OpenUP Hito: En esta etapa se obtiene el software final. Concepción
Elaboración Construcción Transición Producto

57 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

58 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.

59 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

60 OpenUP Asignación de Actividades:

61 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.

62 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.

63 OpenUP Flujos de Trabajo: Análisis de Arquitectura Diseño de Describir
Concurrencia Distribución Casos de Uso Objetos Revisar el Análisis Diseño Revisar la Revisor de Diseñador Diseñador de Arquitecto

64 OpenUP Flujos de Trabajo Esenciales: Flujos de Trabajo de Ingeniería
de Apoyo

65 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.

66 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

67 OpenUP Los casos de uso describen la funcionalidad.
Los requerimientos no funcionales se incluyen en una especificación complementaria.

68 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

69 OpenUP El diseño se centra en la noción de arquitectura.
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.

70 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

71 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

72 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.

73 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 Apoyar a los usuarios

74 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

75 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.

76 OpenUP Algunos problemas habituales: Actualizaciones simultáneas
Múltiples versiones UP da guías para: Desarrollos en paralelo Automatizar la construcción Administrar defectos

77 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.

78 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.

79 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.

80 Metodologías Ágiles Es más adecuada para los cambios reduciendo los errores (costos) y logrando la satisfacción de los clientes. Costo del cambio tiempo Tradicional Suposición MAs

81 Metodología Tradicional
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

82 Metodologías Ágiles Crystal Methodologies, Alistarir Cockburn,
SCRUM, Ken Schwaber & Jeff Sutherland, DSDM (Dynamic Systems Development Method), Lean Programming, Mary Poppendieck,

83 Metodologías Ágiles FDD (Feature-Driven Development), Peter Coad & Jeff De Luca, Extreme Programming, Kent Beck Adaptative Software Development, Jim Highsmith

84 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.

85 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.

86 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.

87 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.

88 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.

89 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

90 XP Desarrollar Programming Presentar la entrega Releasing }
Puntos clave: el juego de planificación, entregas cortas, diseños simples, refactorización. LA GRAN FOTO

91 XP

92 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.

93 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

94 XP Número: 1 Nombre: Enviar artículo Usuario: Autor
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 (Alta / Media / Baja) Puntos Estimados: Riesgo en Desarrollo: (Alto / Medio / Bajo) Puntos Reales: Descripción: Se introducen los datos del artículo (título, fichero adjunto, resumen, tópicos) y de los autores (nombre, , afiliación). Uno de los autores debe indicarse como autor de contacto. El sistema confirma la correcta recepción del artículo enviando un al autor de contacto con un userid y password para que el autor pueda posteriormente acceder al artículo. Observaciones:

95 XP

96 XP Espacio abierto Mesas centrales Cubículos en el espacio exterior

97 XP Reunión diaria: “Stand-up Meeting” De pie en un círculo
Todo el equipo Problemas Soluciones De pie en un círculo Evitar discusiones largas Sin conversaciones separadas

98 XP

99 Adaptative Sw Development

100 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.

101 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.

102 Scrum Los actores que intervienen en esta metodología son:
Propietarios del producto Usuarios del poducto Scrum master Equipo de scrum.

103 Scrum

104 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.

105 Scrum Ejemplo de un sprint backlog

106 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.

107 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.

108 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

109 Scrum ¿Quiénes son products owner? Analista Tester Usuario final
Cliente Product Manager

110 Scrum Un rol de suma importancia en esta metodología es el escuchar.
Muchos problemas de desarrollo se pueden solucionar fácilmente si se escucha a los clientes, usuarios finales y equipos de desarrollo.

111 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.

112 Lean Eliminar el desperdicio Construir con calidad Crear conocimiento
Postergar compromiso Entregas rápidas Repetar a las personas Optimizar el todo

113 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, …

114 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

115 Lean Cuidado… Solución El código cambia Mucho código es desperdicio
Menos código, menos oportunidad de defectos Solución KISS Refactoring

116 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!

117 Lean Mito: Planificación es compromiso Tomar decisiones irreversibles
Buscar soluciones reversibles

118 Lean Alta calidad Bajo costo Menos cambios
Habilita a pruebas de concepto y mayor conocimiento del cliente Mito: Apuro causa desperdicio

119 Lean Mito: existe la mejor manera de hacerlo Líderes emprendedores
Expertos técnicos Control basado en objetivos

120 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

121 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

122 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.

123 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.

124 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.

125 FDD

126 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.

127 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.

128 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.

129 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.

130 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.

131 FDD

132 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

133 Roles Director de Desarrollo: Programador en Jefe
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.

134 Roles Entre los roles de soporte se encuentran: Gestor de Domino
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

135 Roles Language Lawyer (Guru del Lenguaje) Ingeniero de construcción
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.

136 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

137 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.

138 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).

139 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.

140 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.

141 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.

142 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.

143 ¿Preguntas?