Simulación como Herramienta para la Mejora de los Procesos de Software Desarrollados con Metodologías Ágiles Utilizando Dinámica de Sistemas Objetivo.

Presentación del tema: "Simulación como Herramienta para la Mejora de los Procesos de Software Desarrollados con Metodologías Ágiles Utilizando Dinámica de Sistemas Objetivo."— Transcripción de la presentación:

1

2 Simulación como Herramienta para la Mejora de los Procesos de Software Desarrollados con Metodologías Ágiles Utilizando Dinámica de Sistemas Objetivo General: Diseñar Modelos de Simulación de los distintos Procesos y Ciclos de Vida de Desarrollo de Software Ágiles. Objetivos Específicos: Establecer el estado del arte en la gestión de proyectos de desarrollo de software ágiles; y en el uso de simulación como herramienta de apoyo en dicha gestión. Estudiar herramientas para el desarrollo de modelos y simulación dinámica de sistemas. Construir modelos de simulación para la gestión de proyectos de desarrollo de software que utilizan metodologías ágiles, utilizando la metodología de dinámica de sistemas. Validar dichos modelos con proyectos reales. Evaluar y validar dichos modelos ante modificaciones en los parámetros principales del mismo generando las conclusiones correspondientes.

3 Ing. Henry Kotynski, Mg. Diego Alberto Godoy, Ing. Edgardo Belloni, Dr. Eduardo O. Sosa, Ing. Matias Rodriguez

4 Modelos Dinámicos existentes para PDS Construir un Modelo Dinámico para la Gestión de PDS utilizando la Metodología de Dinámica de Sistemas Evaluar diferentes políticas de gestión de proyectos y obtener las conclusiones correspondientes Para así Que permita Analizar el efecto que tiene el uso de diversas políticas de Gestión en Proyectos de Desarrollo de Software que utilizan Scrum

5

6 Simula: El desarrollo de un Producto de Software. No Considera: Comunicación entre los Integrantes del Team Considera: Diferentes niveles de Experiencia en la metodología. Adquisición de Experiencia en la metodología. Cansancio por Trabajo. Errores de Codificación. El Modelo Características del Modelo Dinámico Construido

7 Subsistema Horas de Trabajo por día: Horas extras por día Subsistema Recursos Humanos: Número Ideal de Integrantes del Team. Número de Integrantes por Nivel de Experiencia. Tasas de abandono por cada Nivel de Experiencia. Tasas de Promoción entre los Niveles de Experiencia Subsistema Adquisición de Experiencia: Tasas de Aprendizaje para cada Nivel de Experiencia. Nivel de Productividad de Nivel de Experiencia. Subsistema Inasistencias: Probabilidad de Inasistencias no acordadas. Características del Modelo Dinámico Construido

8 VariableValor Horas Diarias8 Días semana5 Horas Totales por Semana40 Velocidad Prueba1 Inasistencias Pactadas10 Inasistencias Imprevistas1220% Factor Dedicación Diario80,00% Días Hombre Ideal168 Días Hombre Real161 Team8 Errores por Presión en el plazo Si Errores de IntegraciónSi15% Promociones en el TeamNo Abandonos en el TeamSi Tareas ExtrasSi Tareas Extras No planificadas Si15% Búsqueda de nuevosSi

9 Sprint Puntos de Historia Velocidad de Trabajo Duración en Horas Horas Extras Duración Sprint Tareas Extras (T.E.) Puntos con T.E. T.E. No Planificadas Ausencias No Acordadas Inicio Recalculado 1360,8740242339000 2340,82402423371642 3380,92402423410184 4350,894014113615126 5350,894014133801167 6361,00401415 10208 Total214240924918232312

10

11

12 Tareas Pendientes Codif. Y Codificadas Burdwon Chart, Tareas Pendientes Codif. Y Codificadas

13 Pruebas Sin Errores y Con Errores de DesarrolloPruebas de Integración

14

15

16

17 Análisis Sensibilidad 1 - Experiencia Team y Tasa de Errores de Integración

18 Tasa de Error por Presión Tasa de Error por Presión y Errores Detectados Análisis Sensibilidad 1 - Tasa de Errores de Integración Por Presión

19 Tasa de Error por Presión y Errores Detectados Tasa de Error por Presión Análisis Sensibilidad 1 - Tasa de Errores de Integración por Presión

20 Caso 1 Análisis Sensibilidad 2 - Team y Experiencia

21 Caso 2 Análisis Sensibilidad 2 - Team y Experiencia

22 Caso 3 Análisis Sensibilidad 2 - Team y Experiencia

23 Caso 4 Análisis Sensibilidad 2 - Team y Experiencia

24

25 Luego del Análisis de Sensibilidad realizado se observa que la composición de Team en cuanto a número de integrantes, nivel de experiencia y rotación de los mismos afecta de manera directa al normal desarrollo del proyecto dado que la Experiencia Total del Team es uno de los factores relevantes para el proyecto. Permite cuantificar este impacto al final de cada Sprint.

26 La validación realizada tanto de diversos proyectos como casos de “entrenamiento” se evalúa como positiva ya que el Modelo construido se comportó de acuerdo con los datos de proyectos reales. El mismo cumple con sus objetivos y puede ser utilizado como herramienta para evaluar diferentes decisiones de gestión. El modelo es de utilidad para el Scrum Master y el Team la hora de analizar el efecto del uso de la metodología Scrum en su proyecto de desarrollo de software.

27 En relación a nuevos objetivos y trabajos futuros, se espera en -primer término- avanzar con la construcción de otros subsistemas, como por ej. el de Cálculo de Costos y el de Comunicación en el Team. Por otra parte, se planea experimentar con el simulador en cátedras que –como parte de su intensidad de formación práctica– promuevan actividades de proyecto y desarrollo de software utilizando metodologías ágiles. Resulta también necesario construir bases de datos de proyectos de software reales desarrollados con Scrum, ya que actualmente resulta difícil contar con datos post mortem de proyectos gestionados con métodos ágiles, en general, y Scrum en particular.

28 hkotynski,diegodoy,ebellloni,eduardo.sosa @citic.dachary.edu.ar