Resumen Metodologias De Desarrollo 3x3u4e

Universidad de San Carlos de Guatemala Facultad de ingeniería Escuela de ciencias y sistemas Software Avanzado Escuela de vacaciones – Diciembre 2015 Kevin Barrientos Castellanos 2012-12631

Metodologías de desarrollo Todo proyecto de desarrollo de software debe de ser controlado de manera que se minimicen los posibles riesgos que surgen durante el mismo. Si no se tiene claro lo qué se debe de hacer y el momento en qué se debe de hacer el proyecto puede fracasar. Por ello conforme la tecnología avanza se han elaborado diferentes metodologías de desarrollo. Estas metodologías establecen un marco de trabajo usado para estructurar, planificar y controlar el proceso de desarrollo. Entre las metodologías tradicionales más comunes podemos mencionar: modelo cascada tan bien conocido como tradicional, desarrollo iterativo incremental, desarrollo basado en prototipos y el modelo espiral. Estas metodologías se caracterizan por tener un proceso bien definido sin embargo a medida que la tecnología avanza, las condiciones de desarrollo tan bien cambian. Por ejemplo antes el desarrollo de software era un proceso en el que el cliente no participaba mucho y ahora se requiere de su constante presencia a lo largo de las fases. Además los equipos de trabajo han cambiando, se han vuelto multidisciplinarios, situados en diferentes puntos geográficos probablemente incluso en diferentes países. Así pues han surgido metodologías que se adaptan de mejor manera y que han tenido auge en los últimos años, estas son las llamadas metodologías ágiles entre las que podemos mencionar: XP, Scrum y Kanban. A continuación se describe un pequeño resumen de cada metodología. Aunque, en general un proyecto de desarrollo adopta más de una metodología poniendo en practica los conceptos que más se adecuan a su entorno.

TRADICIONALES CASCADA Esta metodología describe el ciclo tracicional del desarrollo de software en cinco etapas: 1. 2. 3. 4. 5.

Toma de requerimientos Análisis del problema Diseño de la solución Codificación Pruebas

Estas etapas deberán ejecutarse una después de la otra de manera secuencial. La gran desventaja de este planteamiento se debe a que en ciclo de vida de desarrollo de un producto real existen cambios que nos forzarán a regresar a una etapa anterior, lo cual va en contra de esta metodología. Sin embargo para un

desarrollo sencillo esta metodología es fácil de implementar debido a que es clara en las tareas que se realizarán en cada una de sus etapas. Sin embargo para un proyecto cuyos requerimientos no están muy definidos no se aconseja su implementación ya que el proyecto esta sujeto a cambios constantes. Desarrollo iterativo incremental Esta metodología pretende dividir el proyecto en etapas definidas e implementar en cada una de estas etapas el método de cascada. De esta manera cada iteración es un objetivo alcanzado del cual se supone no se retrocederá. Con esto logramos manejar cambios con un menor impacto en el proyecto siempre y cuando los cambios solo afecten la iteración que se esta trabajando. Cualquier cambio que pretenda afectar iteraciones anteriores representa un gran riesgo al proyecto. BASADO EN PROTOTIPOS Un prototipo es la representación del sistema en funcionamiento, pero sin todas sus operaciones desarrolladas a totalidad. Esta metodología basa todas sus etapas en prototipos. Cada prototipo es elaborado según la toma de requerimientos realizada previamente. Sus fases son: • Toma de requerimientos • Elaboración de prototipo • Aprobación por parte del cliente • Codificación Sirve para darle una idea general al cliente de lo que se desarrollará para así obtener su aprobación antes de elaborar el producto y así poder aclarar conceptos que pudieron no quedar muy claros. Así reducimos la incertidumbre de lo que se hará y garantizamos un mayor grado de satisfacción por parte del cliente. Esta metodología involucra más al cliente lo cual es de gran importancia para el éxito de un proyecto sin embargo carece de un análisis formal de riesgos para su gestión en caso de presentarse. ESPIRAL Basada en el modelo incremental. Se agrega la planificación, análisis de riesgos e ingeniería. También cada entrega de prototipos se considera una vuelta (ciclo) del espiral sobre la cual se trabaja. Dentro de sus ventajas y desventajas esta la agregación de etapas necesarias tales como la gestión de riesgos la cual con el tiempo se puede volver muy burocrática impidiendo que el proyecto avance, sin embargo sus beneficios son útiles si se maneja correctamente.

ÁGILES XP – EXTREME PROGRAMMING Desarrollada por Kent Beck. «Todo en el software cambia. Los requisitos cambian. El diseño cambia. El negocio cambia. La tecnología cambia. El equipo cambia. Los del equipo cambian. El problema no es el cambio en sí mismo, puesto que sabemos que el cambio va a suceder; el problema es la incapacidad de adaptarnos a dicho cambio cuando éste tiene lugar.» Kent Beck.

La nota del autor infiere que es dicha metodología implenta mecanismos para responder al constante cambio que se produce a lo largo del ciclo de desarrollo de un proyecto. Al estar preparados para el cambio, el riesgo disminuye. • • • • •

En la programación extrema, todos los requerimientos se expresan como escenarios (llamados historias de ). XP surgió como respuesta y posible solución a los problemas derivados del cambio en los requerimientos. XP se plantea como una metodología a emplear en proyectos de riesgo XP aumenta la productividad El cambio se lleva a cabo a través de las entregas regulares del sistema, un desarrollo previamente probado y la integración continua.

Ventajas: • Programación organizada. • Menor taza de errores. • Satisfacción del programador. Desventajas: • Es recomendable emplearlo solo en proyectos a corto plazo. • Altas comisiones en caso de fallar. • Posee muchos roles (programador, cliente, tester, tracker, coach, consultor, big boss) por lo cual con un equipo pequeño de trabajo es difícil llevarla a la práctica. SCRUM Esta metodología ha sido ampliamente aceptada por su versatilidad. Aunque al inicio resulta complicada su implementación, una vez que se adquiere experiencia, proyectos con alto grado de incertidumbre y de corta duración pueden ser exitosos con un correcto control de su proceso. Al igual que XP esta metodología define roles que poseen funciones específicas en cada parte del proceso de desarrollo. Los roles son: • Product Owner: persona que conoce a fondo el producto, posee una visión clara del producto. Es quien define prioridades y es el encargado de manejar el product backlog según lo considere conveniente. • Scrum master: persona altamente capacitada en el desarrolladas bajo la metodología SCRUM, es un facilitador que quita impedimentos para que el proyecto continué su camino. • Equipo de desarrollo: desarrolladores. Además Scrum define ceremonias que se debe de llevar a cabo durante el desarrollo. • Product Grooming • Sprint Planning ◦ Responsable: scrum master ◦ Actividades ▪ Sprint prioritization • Debe de tener una meta (producto funcional). • Analizar el product backlog para determinar cuáles se deben de realizar. ▪ Sprint planning

•

•

•

• Cómo se alcanzar el objetivo/meta • Determniar tareas • Estimate sprint back hours Daily scrum: el objetivo es conocer la respuesta a cada una de las siguietnes preguntas. ▪ Qué se ha hecho desde el último DS? ▪ Qué se tiene planeado hacer hasta el próximo DS en la Story X? ▪ Hay algún impedimento que impide cumplir con los objetivos? Sprint Review ◦ Para ver si el producto fue bueno o no. Generalmente participa el cliente, scrum master y product owner, en ocaciones un miembro del equipo. Retrospective ◦ Mejora continua. Análisis del último sprint con los del equipo, scrum master y product owner.

Por último los artefactos que utiliza Scrum son: • Producto backlog: caracterizan del producto. • Sprint: periodo de tiempo en el que se desarrolla una porción del product backlog para tener un producto funcional al final de éste periodo. Se recomienda que dure entre 1 a 4 semanas. KANBAN Kanban es otro marco utilizado para implementar ágil. De vuelta en la década de 1940, Toyota optimizó su proceso de ingeniería modelandolo al igual que los supermercados abastecían sus estanterías. Los supermercados mantenían apenas suficiente producto para satisfacer la demanda de los consumidores, una práctica que optimiza el flujo entre el supermercado y el consumidor. Debido a que los niveles de inventario coinciden con los patrones de consumo, el supermercado gana eficacia significativa en la gestión del inventario y la optimización para el cliente. Cuando Toyota trajo la idea a los de pisos de la su fábrica, los equipos (tales como el equipo que se conecta las puertas al marco del coche) entregarían una tarjeta, o "Kanban", entre sí (por ejemplo, al equipo que reúne las puertas) para señal de que tienen un exceso de capacidad y están dispuestos a tirar de más materiales. Aunque la tecnología de señalización ha evolucionado, este sistema sigue siendo el núcleo de "justo a tiempo" de fabricación actual. Un equipo Kanban solamente se centra en el trabajo que está activamente en progreso. Una vez que el equipo completa un elemento de trabajo, arrancan el próximo elemento de trabajo de la parte superior de la cartera. El propietario del producto es libre de volver a priorizar el trabajo de la cartera sin alterar el equipo, porque cualquier cambio fuera de los elementos de trabajo actuales no afectan el equipo. Mientras el dueño del producto mantiene los elementos de trabajo más importantes en la parte superior de la cartera, el equipo de desarrollo está asegurado que están entregando valor máximo de nuevo a la empresa. Así que no hay necesidad de las iteraciones de longitud fija que se encuentra en scrum. Efeciencia a través del enfoque La multi-tarea mata la eficiencia. Cuantos más elementos de trabajo hay en un momento dado, se incrementa el cambio de contexto, lo que dificulta su camino hasta su finalización. Es por eso que un punto clave de Kanban es limitar la cantidad de trabajo en curso (WIP – work-in-progress).