Universidad “Gran Mariscal de Ayacucho” Ingeniería de Sistemas Dirección de Operaciones I Participantes: Montes, Kimberlys Mosquera, Johanbert Suarez,

Presentación del tema: "Universidad “Gran Mariscal de Ayacucho” Ingeniería de Sistemas Dirección de Operaciones I Participantes: Montes, Kimberlys Mosquera, Johanbert Suarez,"— Transcripción de la presentación:

1 Universidad “Gran Mariscal de Ayacucho” Ingeniería de Sistemas Dirección de Operaciones I Participantes: Montes, Kimberlys Mosquera, Johanbert Suarez, Ocnelis

2 Metodología Ágil

3 Las metodologías ágiles forman parte del movimiento de desarrollo ágil de software, que se basan en la adaptabilidad de cualquier cambio como medio para aumentar las posibilidades de éxito de un proyecto.

4 ¿Para que un método de gestión?

5 Metodología Ágil El Manifiesto de la metodología Ágil: 1.Individuo y las iteraciones del equipo de desarrollo sobre el proceso y las herramientas. (Calidad del profesional del equipo, Entrega Temprana y Continua) 2.Software funcionando sobre documentación extensiva. 3.La colaboración con el cliente sobre negociación contractual. 4.Respuesta ante el cambio sobre seguir estrictamente un plan. Es importante la derecha pero valoramos más la izquierda

6 ¿Por qué surgen las Metodologías Ágiles? 1.Dificultades para implantar metodolog í as tradicionales. Procesos ceremoniosos, herramientas CASE y notaciones de modelado sofisticadas (UML) 2.Una soluci ó n a medida para un segmento importante de proyectos de desarrollo de software 3.“ Aceptar el cambio ”...

7 ¿Cuándo utilizar una Metodología Ágil? - Sus clientes no tienen una idea firme de lo que el sistema debe hacer. - Sistemas cuya funcionalidad se espera que cambie cada pocos meses. - Si los clientes necesitan un nuevo sistema en una fecha específica.

8 Comparación Ágil v/s Tradicional Metodología ÁgilMetodología Tradicional 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 cliente y el trabajo en equipo Énfasis en la definición del proceso: roles, actividades y artefactos Se esperan cambios durante el proyectoSe espera que no ocurran cambios de gran impacto durante el proyecto

9 Programación Extrema

10 Antecedentes e Historia de Programación extrema

11 Sin embargo, se reconoce a Kent Beck como el que articuló esta propuesta y le dio nombre propio. Kent Beck En 1989, Cunningham formó un equipo que usaba los principios y muchas de las prácticas que después adoptaría XP, mientras trabajaba para la compañía “Wyatt Software” [Fowler 2000]. Antecedentes e Historia de Programación extrema

12 +Los autores de la Programación Extrema, crearon el sitio web Portland Pattern Repository y empezaron a hablar de ella y promocionarla, de lo que era y cómo realizarla. Estos propulsores de la XP hablaban de ella en cada ocasión que tenían y en cada página que, poco o mucho hablara de temas de programación. Antecedentes e Historia de Programación extrema Portland Pattern Repository

13 - ¿Qué es XP? - Características

14 Justificación y fundamentos de XP

15 Principios, roles y prácticas de Programación extrema

16 Principios de la Programación extrema Se busca : 1.Realimentación rápida 2.Asumir la simplicidad 3.Cambio incremental 4.Aceptar el cambio 5.Hacer trabajo de calidad.

17 1.El juego de la planificación 2.Entregas pequeñas 3.Metáfora 4.Diseño simple 5.Recodificación 6.Programación en parejas 7.Propiedad colectiva 8.Integración continua 9.Semana de 40 horas 10.Cliente in situ 11.Estándares de programación 12.Pruebas Prácticas XP DISEÑO CODIFICACION PLANIFICACION PRUEBAS

18 Las cuatro actividades básicas 1.Codificar 2.Hacer pruebas 3.Escuchar 4.Diseñar.

19 Roles de XP Cliente  Elabora especificaciones de los requerimientos iniciales. Programador  Responsable de diseñar, codificar, probar e integrar el producto de software. Administrador  Responsable de coordinador de las actividades de desarrollo y asegurar su cumplimiento.

20 Los cuatro valores Valores para desarrollar software: 1.Comunicación 2.Sencillez 3.Retroalimentación 4.Valentía.

21 Objetivos de XP Son: 1.La satisfacción del cliente. 2.Potenciar el trabajo en grupo, todos están involucrados en el desarrollo del software.

22 +Da lugar a una programación sumamente organizada. +Ocasiona eficiencias en el proceso de planificación y pruebas. +Cuenta con una tasa de errores muy pequeña. +Propicia la satisfacción del programador. +Es recomendable emplearla solo en proyectos a corto plazo. +En caso de fallar, las comisiones son muy altas. +Requiere de un rígido ajuste a los principios de XP. +Puede no siempre ser más fácil que el desarrollo tradicional. Ventajas Desventajas

23 CONCLUSIONES +La programación extrema es una forma ligera, eficiente, flexible, científica y divertida de generar software. +La programación extrema se beneficia de la existencia de un gran número de herramientas de software libre que permiten aplicarla con gran productividad. +El software libre se inspira en algunas de las prácticas de la XP. +Aprovecha el tiempo de los clientes y ayuda a que un cliente se sienta integrado, evitando que se desmoralice por no saber como preparar pruebas de aceptación. +Permite identificar historias adicionales que no fueran obvias para el cliente o en las que cliente no hubiese pensado de no enfrentarse a dicha situación.

24 Ciclo

25 GRACIAS