AGILE AGILE. AGILE: Agenda. INGENIERIA de SOFTWARE II. Casos de Estudio AGILE. AGILE: Agenda. INGENIERIA de Software II. Casos de Estudio AGILE

Transcripción

1 : Agenda INGENIERIA de SOFTWARE II Casos de Estudio Nicolás D Ippolito Slide: 1 Slide: 2 : Agenda INGENIERIA de Software II Casos de Estudio CASOS DE ESTUDIO TheRac-25 ARIANE 5 Mars Spirit & Odyssey Robot Asesino Slide: 3 Slide: 4 1

2 THErapeutic RAdiation Computer 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 Slide: 6 THErapeutic RAdiation Computer 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 Solo un desarrollador Una sola persona realizo el testing No se realizo test de Unidad Se testeo solo 2700 hs Urads (Reg. 200/1000) El técnico cometió el mismo error de cambiar rápidamente el modo X-ray a Electron. Slide: 7 Slide: 8 2

3 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 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: 9 Slide: 10 ARIANE 5 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: 11 Slide: 12 3

4 MARS SPIRIT : Agenda FILE SYSTEM en los robots Spirit: 500 sols (Garantia 90) ESTIMACION DE VELOCIDAD HORIZONTAL Mars Polar Lander (22 m./seg) Casos de Estudio 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 Slide: 14 : Agenda : Porque? Porque? Historia Ejemplos extremeprogramming XP Conclusión 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: 15 Slide: 16 4

5 : Porque? : 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 Costo de cambio Standard SE XP asume tiempo Slide: 17 Slide: 18 : Porque? : Porque? Problemas de las Metodologías Tradicionales [LARMAN] % de éxito Project Success Estimación Problemas de las Metodologías Tradicionales Cono de incertidumbre 4.0x 2.0x x Final Actual 0.5x Duración en meses 0.25x Tiempo Fuente: Larman sobre proyectos Fuente: S. McConnell - Software Project Survival Guide (1998) Slide: 19 Slide: 20 5

6 : Porque? : 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) Problemas de las Metodologías Tradicionales [LARMAN] Éxito en Waterfall sometimes 16% rarely 19% often 13% Alw ays 7% Never 45% Fuente: Larman sobre proyectos Slide: 21 Slide: 22 : Porque? : 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. 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: 23 Slide: 24 6

7 : Porque? : 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 entonces? Slide: 25 Slide: 26 : Manifesto : Intension 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. 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: 27 Slide: 28 7

8 : 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. Comunicación efectiva PAPEL AUDIO Comunicación TELEFONO VIDEO-PHONE CARA a CARA CARA a CARA con PIZARRON OPCIONES DE DOCUMENTACION OPCIONES DE MODELADO FRIO Eficiencia del canal de comunicación CALIDO Slide: 29 [Cockburn 2002] Slide: 30 : Proceso : El martillo al clavo Como controlo el proceso? Cuando elegir metodologías Ágiles? 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] 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: 31 Slide: 32 8

9 : 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: 33 Slide: 34 vs. Metodología Tradicional Scrum asume: Requerimientos cambiaran durante el proyecto. : Scrum 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. PRODUCT BACKLOG SPRINT BACKLOG BURN DOWN CHART SPRINT MASTER TEAM PRODUCT OWNER SPRINT PLANNING MEETING SPRINT REVIEW MEETING DAILY MEETING Listo. Fuego! Mejorar punteria. Fuego. Mejorar punteria... Slide: 35 Slide: 36 9

10 : Scrum Scrum: De Pollitos y Cerditos : The Big Picture -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: 37 Slide: 38 Reuniones: Sprint Planning Meeting Tipos de Reuniones Scrum SPRINT PLANNING SPRINT REVIEW DAILY 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: 39 Slide: 40 10

11 Horas Horas Reuniones: Sprint Review Reuniones: Daily Scrum 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 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: 41 Slide: 42 Reuniones: Daily Scrum : XP Actualización Sprint Burndown Chart Remanente de Horas extreme Programming Fecha Estimada Slide: 43 Slide: 44 11

12 : 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. : XP VALORES Comunicación Feedback Simplicidad Coraje Slide: 45 Slide: 46 : XP ROLES PRACTICAS : XP EQUIPO Desarrollador: escribe tests comunica KISS Customer: escribe stories tests funcionales aceptacion CODIGO COMPARTIDO TDD (Test) ESTANDARES DE CODIFICACION Tester: ayuda escribir tests funcionales Q.C... comunica Tracker: seguimiento de estimaciones progreso mejoras a XP 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 PLANNING GAME Coach/Instructor: responsable del proceso debe dominar XP INTEGRACION DISEÑO SIMPLE CONTINUA HORAS PRODUCTIVAS 40 HS.!!! Consultor: external member conocimiento tecnico METAFORAS Manager (Jefe): toma decisiones comunica RELEASES PEQUEÑAS Slide: 47 Slide: 48 12

13 : XP USER STORIES : XP 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 A spike is a short throwaway experiment in code Slide: 49 Slide: 50 : XP : XP Slide: 51 Slide: 52 13

14 No escalable : 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 : Conclusiones FACTOR COMUN: ITERATIVOS Organización Propia Colaboración Emergente Adaptable Empirico Goaldriven Mejorable Integridad Orientado al Producto Delivery frecuente Puede caer en el modelo de codificar y probar Vagas nociones de aseguramiento de la calidad Disciplinado Apenas suficiente Ligero Iterativo Incremental Time-boxed Fuerte tendencia a no documentar (Post-Mortem) Slide: 53 Slide: 54 : Bibliografia : Preguntas? [Beck] [Booch] [Jeffries] Extreme Programming Explained Object Oriented Analysis and Design with Applications, 2d. Ed Extreme Programming Installed [http] [http] [http] [http] [http] Slide: 55 Slide: 56 14

15 kria; re; Otyo; Manbote; Ni weg goi; Rakhmat; Chong Ahsante; Asanteni; Asante s Shukria; Maigo; Maiteka; Atto; At Kamsahamnida; Komawoyo; Kulo; Kulo see; Tenki ya; Tenkey; Dot nuet; Keyi tapon kas'la; Ah gilakas'la; Nda pandula; Mèsi; Mèsi ple Jule; De gra; Dilan; Develpai; Gracias; Munchas gracia a ja; Òboi jâ; Pilamaya ye; Pilamaya yelo; Pilamaya aloh; Kh tia; Gratias; Gratias tibi ago; Gratiam habeo; Paldies; Liels paldies í; Matóndo; Natondi yo; Gratzia; Mouchou gratzia; Xual mu wa; Dut zoil; hku bumu; Achiu; Dekoju; Labai achiu; Dekui; Labai dekoju; Nuoširdziai dekoj Sia; Dank; Danke; Ek dank auk schoin; Sind auk viellmaols bedankt; Moducué; W nyo; No$un looviq; Hy'shqe siam; Kusakililaku; Webale; Webale; Erokamano; Ck'w elí'dubshewx; Gunasakulila; Merci; Aske; Ashi; Ashi oleng; Ashi naling; Eso; Blago antte; Kooshukhuru; Marahaba; Misaotra; Misaotra tompoko; Misaotra indrindra; T h; Gracias; Terima kasih banyak-banyak; Nandi; Valarey nanhi; Nanni; Sabkaa ; Grazzi hafna; Chjóonte; Chjoonta; Gracias tey; Chjónta che; Sanco; Mossi; Ban a chie; Abaraka; I ning bara; Gura mie ayd; Gura mie eu; Gura mie mooar a u; Tika hoki; Ka pai; Meitaki; Meitaki ma'ata; Krasia may; Chaltu; Cha mi; Abhari ahi; Dhanyawaadh; Dhanyawaatha; Tau; Gracias Nkhi k'a ninashitechino; Baiika; Bisse; Baika; Eswau; Lae z zingh camv; Tö' dun; Welálin; Weláliek; Akpe; Ak a'ùná; Kúta'ùrí; Kúta'ù shãàrí nuùro; Niku tab ; Tyáhvi nyóò; Nihedebil; Wneeweh; On ailaa; Tand ikh bayarlalaa; Saikha arka; Barka wusgo; B'o'tic; mkv; Tlazohcamati; Icn matl; Tlazocamati ; Ttaubotne ga; N 15