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.

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

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

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

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

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

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, , , , , , Total

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

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

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

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

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

Caso 1 Análisis Sensibilidad 2 - Team y Experiencia

Caso 2 Análisis Sensibilidad 2 - Team y Experiencia

Caso 3 Análisis Sensibilidad 2 - Team y Experiencia

Caso 4 Análisis Sensibilidad 2 - Team y Experiencia

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.

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.

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.