AGILE. INGENIERIA de SOFTWARE II AGILE. Nicolás D Ippolito. Cátedra de Ingeniería de Software II Slide: 1

Transcripción

1 INGENIERIA de SOFTWARE II AGILE Nicolás D Ippolito Slide: 1

2 AGILE: Agenda Casos de Estudio AGILE Slide: 2

3 AGILE: Agenda Casos de Estudio AGILE Slide: 3

4 INGENIERIA de Software II CASOS DE ESTUDIO TheRac-25 ARIANE 5 Mars Spirit & Odyssey Robot Asesino Slide: 4

5 THErapeutic RAdiation Computer Utilización medicinal Predecesores: Therac-6 & Therac-20 El software de la Therac-25 fue desarrollado por un solo desarrollador El Software es responsable de: Monitorear Hardware I/O del Operador Configurar el Hardware para emitir rayos Controlar Hardware para tratamiento Aislada en una habitación para evitar exponer a técnicos a la radiación. El paciente posee I/O Audio con el operador Slide: 5

6 THErapeutic RAdiation Computer Slide: 6

7 THErapeutic RAdiation Computer Primer incidente en 1985 Therac-25 administro una sobredosis de radiación. Al Técnico se le presento el mensaje: "No Dose had been administered. Hit the 'P' key thus proceeding with the dose El técnico presiono 5 veces la tecla P Urads (Reg. 200/1000) El técnico cometió el mismo error de cambiar rápidamente el modo X-ray a Electron. Slide: 7

8 THErapeutic RAdiation Computer Solo un desarrollador Una sola persona realizo el testing No se realizo test de Unidad Se testeo solo 2700 hs. Slide: 8

9 THErapeutic RAdiation Computer Conclusión: THERAC-25 es un ejemplo de desastres en Ingeniería de Software THERAC-25 fue diseñada para ayudar a la gente. Pero no se tomo con seriedad el problema Slide: 9

10 ARIANE 5 4 Junio 1996 Viaje inaugural ARIANE años de I+D I+D por $7.000 millones Carga + Cohete = $500 millones 37 seg. luego del despegue Slide: 10

11 ARIANE 5 Slide: 11

12 ARIANE 5 Ariane 501 fracaso por perdida de datos de altura y posición 37 segundos luego de iniciado. Se descubrió la falla en el sistema de referencia inercial. El sistema (SRI*) genero una excepcion durante la conversión de 64-bit float a 16-bit signed integer. El floating point que se intento convertir tenia un valor superior a 16-bit signed integer. Mayor a 32,767 (2 15 ) luego la conversión fallo. Slide: 12

13 MARS SPIRIT FILE SYSTEM en los robots Spirit: 500 sols (Garantia 90) ESTIMACION DE VELOCIDAD HORIZONTAL Mars Polar Lander (22 m./seg) pero y esto donde lo encontramos?... ICSE 2002 Lessons learned from 25 years of process improvement: the rise and fall of the NASA software Slide: 13

14 AGILE: Agenda Casos de Estudio AGILE Slide: 14

15 AGILE: Agenda Porque? Historia Ejemplos SCRUM extremeprogramming XP Conclusión Slide: 15

16 AGILE: Porque? El desarrollo de software es complejo, caracterizado por la inmadurez del proceso. Las dificultades esenciales de Software son [Brooks]: Complejidad:..no hay dos partes iguales Conformidad:... limitaciones arbitrarias (negocio)...cambios arbitrarios Cambio: soft facil de cambiar (no el hard)... éxito, implica nuevas features Invisibilidad: estructura compleja Slide: 16

17 AGILE: Porque? Status actual de los proyectos de software Falta de entendimiento del negocio Proyectos cancelados Retrasos en las entregas Altos costos de mantenimiento Gran cantidad de defectos Cambios en el negocio Inestabilidad de las personas Slide: 17

18 AGILE: Porque? Costo de cambio Standard SE XP asume tiempo Slide: 18

19 AGILE: Porque? Problemas de las Metodologías Tradicionales [LARMAN] Project Success % de éxito Duración en meses Fuente: Larman sobre proyectos Slide: 19

20 AGILE: Porque? 4.0x Problemas de las Metodologías Tradicionales Cono de incertidumbre Estimación 2.0x x Final Actual 0.5x 0.25x Tiempo Fuente: S. McConnell - Software Project Survival Guide (1998) Slide: 20

21 AGILE: Porque? Problemas de las Metodologías Tradicionales Se intenta imponer un modelo predecible sobre una entidad compleja Se intenta minimizar o restringir el cambio en todas las fases Se intenta congelar los requerimientos en forma temprana (Ciclo de Vida) Congelar la arquitectura y el diseño en las primeras fases del desarrollo (Ciclo de Vida) Slide: 21

22 AGILE: Porque? Problemas de las Metodologías Tradicionales [LARMAN] Éxito en Waterfall rarely 19% sometimes 16% Never 45% often 13% Alw ays 7% Fuente: Larman sobre proyectos Slide: 22

23 AGILE: Porque? Problemas de las Metodologías Tradicionales Son orientadas a la documentación. Priorizan a los procesos por sobre las personas. Plantean la construcción como un bigbang. No incorporan feedback sobre el proceso. Slide: 23

24 AGILE: Porque? Problemas de las Metodologías Tradicionales En el contexto actual diversos factores han modificado el grado de crecimiento de la curva: Avances tecnológicos Evolución de la ingeniería de Software El cambio es inevitable, el negocio cambia PORQUE CAMBIA EL NEGOCIO? YAGNI: You aren't gonna need it Slide: 24

25 AGILE: Porque? El cambio de paradigma: Aplanar la curva No evitar el cambio sino incorporarlo Controlar el costo del cambio Decidir en el momento adecuado No aplica a todos los cambios Slide: 25

26 AGILE: Porque? entonces AGILE? Slide: 26

27 AGILE: Manifesto Personas e interacciones por sobre procesos y herramientas Software Funcionando por sobre documentación clara Cliente involucrado por sobre negociación contractual Responder al cambio por sobre seguir un plan Cuando se valorice los items de la izquierda, valoraremos los items de la derecha mas. Slide: 27

28 AGILE: Intension Intentan minimizar el overhead metodológico mediante comunicación entre las personas Se fomenta el cambio. La planificación sirve para organizar las actividades Se adaptan en lugar de ser repetibles Son orientadas a las personas, en vez de orientadas al proceso Slide: 28

29 AGILE: Intension Son destinados a Producir el primer delivery en semanas para tener feedback rápido Inventar soluciones simples, es decir menos cambio para hacer cambios. KISS!!! Mejorar la calidad constantemente. Test continuo, para detectar errores antes. Slide: 29

30 PAPEL AUDIO AGILE: Comunicación TELEFONO VIDEO-PHONE CARA a CARA CARA a CARA con PIZARRON Comunicación efectiva OPCIONES DE DOCUMENTACION OPCIONES DE MODELADO FRIO Eficiencia del canal de comunicación CALIDO [Cockburn 2002] Slide: 30

31 AGILE: Proceso Como controlo el proceso? Feedback frecuente para conocer la situación actual en intervalos regulares Las iteraciones deben ser lo más cortas posibles (entre 2 semanas y 1 mes) time-box El cliente tiene mayor control sobre el proyecto El cliente y el equipo de desarrollo evalúan permanentemente el progreso El cliente puede cambiar las funcionalidades del software de acuerdo a los cambios en el negocio [Beck] Slide: 31

32 AGILE: El martillo al clavo Cuando elegir metodologías Ágiles? Los requerimientos son poco claros o altamente volátiles Se desea fomentar la mejora continua del proceso El cliente entiende el proceso y está involucrado en el proyecto Son ideales para pequeños grupos de trabajo (~<50) Se tienen recursos competentes Se tienen canales ricos de comunicación Slide: 32

33 AGILE: Scrum SCRUM Slide: 33

34 SCRUM SCRUM vs. Metodología Tradicional Definir Requerimientos Dividir en etapas Estimar Planificar (Schedule) Comenzar Desarrollo (Limitando el cambio) Documentar Conceptos Requerimientos del Sistema Diseño de Arquitectura Diseño Detallado Codigo, Debug, Test de Unidad Test del Sistema Deploy & Puesta en Marcha Listo. Apunten. Fuego! Slide: 34

35 SCRUM SCRUM vs. Metodología Tradicional Scrum asume: Requerimientos cambiaran durante el proyecto. Scrum toma el cambio como una forma de entregar al final del desarrollo algo mas cercano a la verdadera necesidad del Cliente. (Tunnel Vision) Sin embargo Scrum, no carece de mecanismos de control y estructura. Listo. Fuego! Mejorar punteria. Fuego. Mejorar punteria... Slide: 35

36 AGILE: Scrum SCRUM PRODUCT BACKLOG SPRINT BACKLOG BURN DOWN CHART SPRINT SCRUM MASTER TEAM PRODUCT OWNER SPRINT PLANNING MEETING SPRINT REVIEW MEETING SCRUM DAILY MEETING Slide: 36

37 AGILE: Scrum SCRUM: The Big Picture Slide: 37

38 SCRUM Scrum: De Pollitos y Cerditos -Pollito: Comencemos un restaurante! -Cerdito: Como lo llamaremos? -Pollito: Llamémoslo Jamon y Huevos -Cerdito: No gracias tu solo estarás involucrado yo estaré comprometido. Slide: 38

39 SCRUM Tipos de Reuniones Scrum SPRINT PLANNING SPRINT REVIEW DAILY SCRUM Slide: 39

40 SCRUM Reuniones: Sprint Planning Meeting Contexto y Características Antes del Sprint Product Owner define funcionalidades El equipo decide que puede realizar sprint Participantes: Product Owner Product Manager Marketing Team Management Slide: 40

41 SCRUM Reuniones: Sprint Review Contexto y Características Cada 30 días aprox. 2 hs. de preparación No mas de 4 horas Demo In-House Demo resultado producido Participantes: Clientes Management Product Owner Otros involucrados Slide: 41

42 SCRUM Reuniones: Daily Scrum Contexto y Características Diariamente 15-minutos De pie (recomendación) No se pretende resolver problemas Preguntas: Qué haz hecho ayer? Qué harás hoy? Qué obstáculos hay en tu camino? Participantes: Pollitos y cerditos están invitados (Esto permite evitar futuras reuniones) Solo los cerditos pueden hablar!!! Slide: 42

43 SCRUM Reuniones: Daily Scrum Actualización Sprint Burndown Chart Remanente de Horas Horas Horas Fecha Estimada Slide: 43

44 AGILE: XP extreme Programming Slide: 44

45 AGILE: XP Las raíces surgieron en la comunidad Smalltalk; de la colaboración de Kent Beck y Ward Cunningham a fines de los 80. En 1996 Beck fue llamado a Chrysler para inspeccionar el progreso de un proyecto de liquidación de sueldos de la empresa. Debido a la baja calidad del código entregado, Beck sugirió desechar todo el código y empezar de cero. Allí empezó a poner en marcha una serie de prácticas aprendidas anteriormente, y las fue refinando hasta lo que se convertirían en las bases de XP. Slide: 45

46 AGILE: XP VALORES Comunicación Feedback Simplicidad Coraje Slide: 46

47 AGILE: XP ROLES Desarrollador: escribe tests comunica KISS Customer: escribe stories tests funcionales aceptacion Tester: ayuda escribir tests funcionales Q.C... comunica Tracker: seguimiento de estimaciones progreso mejoras a XP Coach/Instructor: responsable del proceso debe dominar XP Consultor: external member conocimiento tecnico Manager (Jefe): toma decisiones comunica Slide: 47

48 PRACTICAS AGILE: XP EQUIPO CODIGO COMPARTIDO TDD (Test) ESTANDARES DE CODIFICACION TEST DEL CLIENTE El trabajo diario se alinea con PROGRAMACION REFACTORING Mantienen DE A PARES los al objetivos negocio y del la gente en Aplica disciplina sincronización Negocio. a los desarrolladores para mantener la calidad INTEGRACION DISEÑO SIMPLE HORAS CONTINUA PRODUCTIVAS 40 HS.!!! PLANNING GAME METAFORAS RELEASES PEQUEÑAS Slide: 48

49 AGILE: XP USER STORIES Escribir un índice de cards Título significativo Descripción corta (centrado en el cliente) Concentrarse en el QUE NO en COMO NO en PORQUE Utilizar el lenguaje del Cliente No se necesitan tener todas al comienzo Slide: 49

50 AGILE: XP A spike is a short throwaway experiment in code Slide: 50

51 AGILE: XP Slide: 51

52 AGILE: XP Slide: 52

53 No escalable AGILE: XP Criticas a XP Altos riesgos si existen fallas en la arquitectura Altos riesgos si no hay capacidad/estabilidad en las personas La programación de a pares es un intento por solventar la falta de análisis Puede caer en el modelo de codificar y probar Vagas nociones de aseguramiento de la calidad Fuerte tendencia a no documentar (Post-Mortem) Slide: 53

54 AGILE: Conclusiones FACTOR COMUN: ITERATIVOS Organización Propia Adaptable Empirico Mejorable Emergente AGILE Goaldriven Integridad Orientado al Producto Colaboración Delivery frecuente Disciplinado Apenas suficiente Ligero Iterativo Incremental Time-boxed Slide: 54

55 AGILE: Bibliografia [Beck] [Booch] [Jeffries] [http] [http] [http] [http] Extreme Programming Explained Object Oriented Analysis and Design with Applications, 2d. Ed Extreme Programming Installed [http] Slide: 55

56 AGILE: Preguntas? Slide: 56

57 ; Shukria; Meh ; Yebare; Otyo; Osy andi; Manbote; Ni wega; T w; Kongoi; Rakhmat; Chong rak ante; Ahsante; Asanteni; Asante sana mó; Shukria; Maigo; Maiteka; Atto; Attö; nida; Kamsahamnida; Komawoyo; Kulo; Kulo ma naa basee; Tenki ya; Tenkey; Dot nuet; Keyi tapon; Sh o; Gilakas'la; Ah gilakas'la; Nda pandula; Mèsi; Mèsi plen; M d dju; Jule; De gra; Dilan; Develpai; Gracias; Munchas gracias; A uija; Da ja; Òboi jâ; Pilamaya ye; Pilamaya yelo; Pilamaya aloh; Khawp lai; Gratia; Gratias; Gratias tibi ago; Gratiam habeo; Paldies; Liels paldies; Wa Melesí; Matóndo; Natondi yo; Gratzia; Mouchou gratzia; Xual mu wa; Dut zoil; Atk Ahku bumu; Achiu; Dekoju; Labai achiu; Dekui; Labai dekoju; Nuoširdziai dekoju ; Sia; Dank; Danke; Ek dank auk schoin; Sind auk viellmaols bedankt; Moducué; Weba nyo; No$un looviq; Hy'shqe siam; Kusakililaku; Webale; Webale; Erokamano; Ck'wálid Helí'dubshewx; Gunasakulila; Merci; Aske; Ashi; Ashi oleng; Ashi naling; Eso; Blagodar Asantte; Kooshukhuru; Marahaba; Misaotra; Misaotra tompoko; Misaotra indrindra; Terim asih; Gracias; Terima kasih banyak-banyak; Nandi; Valarey nanhi; Nanni; Sabkaa; Ni zzi; Grazzi hafna; Chjóonte; Chjoonta; Gracias tey; Chjónta che; Sanco; Mossi; Baniha Toa chie; Abaraka; I ning bara; Gura mie ayd; Gura mie eu; Gura mie mooar ayd; uru; Tika hoki; Ka pai; Meitaki; Meitaki ma'ata; Krasia may; Chaltu; Chaltu ma eimi; Abhari ahi; Dhanyawaadh; Dhanyawaatha; Tau; Gracias; Kom i; Nkhi k'a ninashitechino; Baiika; Bisse; Baika; Eswau; Laengz z ngz zingh camv; Tö' dun; Welálin; Weláliek; Akpe; Akpe úta'ùná; Kúta'ùrí; Kúta'ù shãàrí nuùro; Niku tab'i; T sa; Tyáhvi nyóò; Nihedebil; Wneeweh; Oneowe alailaa; Tand ikh bayarlalaa; Saikhan zoch a barka; Barka wusgo; B'o'tic; Syukp v'mkv; Tlazohcamati; Icnelia; amatl; Tlazocamati; Nict ue; Ttaubotneanau onga; Ngiyat antangi Nä