Caso de estudio 3: Capacidad de recuperación

En un ambiente de desarrollo de software, sin importar la metodología que se aplique, las situaciones y condiciones cambian constantemente. La calidad de ejecución de los proyectos, puede verse afectada por múltiples factores, así sean internos o externos. Por ejemplo, las tareas pueden verse afectadas por el bajo desempeño de cierto número de desarrolladores, los clientes pueden cambiar los requisitos a último momento, o algún servicio del cual se dependencia tiene errores que impiden el desarrollo de nuestro proyecto.

Frente a estos factores, el algoritmo irá almacenando la información que le sea provista, y en función de ella deberá realizar las futuras asignaciones. Particularmente, estamos interesados en el caso de que un cierto recurso, que en sus últimas asignaciones había tenido un buen puntaje, empieza a tener performances negativas o viceversa, un recurso que empezó teniendo actuaciones pobres, empezó a esforzarse y mejorar. Sea cual sea el caso, el algoritmo tiene que ser capaz de adaptar sus decisiones para dejar de elegir el desarrollador que empezó a fallar en sus actividades, y elegir al que comenzó a mejorar.

Esta capacidad del algoritmo de adaptarse a los cambios de los recursos, la denominamos capacidad de recuperación. Representa la capacidad del algoritmo de manipular la memoria organizacional, de tal forma de adaptarse a los cambios descriptos anteriormente, y aun así mantener las asignaciones lo más optimas posibles.

En esta sección, se desarrollará un experimento donde se simula una situación de cambio en las aptitudes de los recursos. Para ello, se invertirán los criterios de calificación, asignando de forma opuesta. Los resultados serán mostrados de la misma manera que en los capítulos anteriores.

5.2.3.1 Configuración del proyecto

Para la implementación del caso de estudio se toma como punto de partida el estado del caso de estudio 2. En ese caso, se planificó 5 veces el mismo proyecto, evidenciando una mejora entre cada ejecución. Para comenzar este caso de estudio, la MO conseguida en el caso 2 será reutilizada. El criterio de calificación del caso 2 será alterado, para calificar de manera inversa, simulando un cambio de las performances de los recursos. Por lo tanto, se inicia este caso de prueba con una MO que ya contiene información sobre los recursos.

El resultado que se espera obtener con este caso de estudio es que, en el primer proyecto que utilice este nuevo criterio de calificación, el puntaje promedio obtenido por el mismo baje notablemente respecto del último proyecto planificado con el criterio de calificación utilizado en el caso 2.

El nuevo criterio de calificación, a diferencia del usado anteriormente, califica las diferentes asignaciones de manera opuesta. Por este motivo los recursos que obtenían un 10 en sus calificaciones para un determinado requerimiento ahora serán calificados con un 1. Por el contrario, los recursos que anteriormente mostraban un desempeño de 1 y 4 presentaran calificaciones de 10 y 8 respectivamente.

Tarea/Recurso

Senior

Semi-Senior

Junior

Alto

10

8

1

Media

8

10

1

Baja

1

8

10

Tabla 5.9: Nuevo criterio de evaluación para demostrar la capacidad de recuperación

La tabla 5.9 presenta un criterio de calificación opuesto al de la tabla 5.1. La semántica de la tabla es la misma.

A continuación se presenta la tabla 5.10, mostrando las sucesivas ejecuciones del algoritmo a lo largo de todos los proyectos con el nuevo criterio de calificación. La última fila de la tabla brinda la información más pertinente para este experimento, que es el puntaje promedio por sprint, el cual aumenta ejecución tras ejecución.

Proyectos

Score por Tarea 6 7 8 9 10 11 12 13 14 15 16 17 Agregar control de movimiento 4.5 8 8 8 8 8 8 8 8 8 8 8 Crear imágenes e interfaz 1 1 1 1 1 1 1 1 1 1 1 1 Crear modelo 3D de la sala 1 1 1 1 1 1 1 1 1 1 1 1 Crear modelo 3D del avatar 8 8 8 8 8 8 8 8 8 8 8 8

Diseñar estructura de base de datos 10 8 10 10 10 10 10 10 8 10 10 10 Diseñar interfaz de login 1 1 1 1 1 1 1 1 1 1 1 1 Implementar animaciones del avatar 4.5 4.5 8 8 8 8 8 10 8 10 10 10 Implementar altas bajas y modificaciones (ABM) 1 8 8 8 8 8 8 10 10 10 10 10 Implementar funcionalidad para inicio de sesión 1 1 1 1 1 1 1 1 1 1 1 1 Implementar lógica de panel 1 1 8 8 8 8 8 8 8 8 10 10 Implementar script para eventos del mouse 1 1 1 1 1 1 1 1 8 8 8 10 Implementar soporte multijugador 8 8 8 8 8 8 8 8 8 8 8 10 Implementar soporte para multijugador 8 8 8 8 8 8 8 8 8 8 8 8 Score Promedio del Sprint 3.84 4.5 5.46 5.46 5.46 5.46 5.46 5.76 6 6.31 6.46 6.76 Figura 5.10: Nuevo criterio de evaluación para demostrar la capacidad de recuperación

Como era de esperarse, y como se ha visto a lo largo de todo este capítulo, el puntaje promedio de cada tarea y el score promedio de cada proyecto va en aumento con las sucesivas ejecuciones del algoritmo

En la planificación del proyecto número seis, ocurre un abrupto descenso en el promedio de las calificaciones. Esto es debido a que el conocimiento en la memoria organizacional es obsoleto, ya que no representa la realidad de la organización, sino lo contrario.

A partir de la planificación del proyecto número siete, se puede ver como la herramienta empieza a realizar nuevamente el trabajo de almacenar conocimiento en la MO y a utilizar el mismo para aumentar la calidad de los resultados. Por otra parte, el mecanismo de

envejecimiento presente en la MO posibilita "olvidar" paulatinamente parte el conocimiento de mayor antigüedad, permitiendo conservar la experiencia más reciente y representativa de la realidad. En la Figura 5.11 se puede contemplar el desempeño del algoritmo a través de los distintos proyectos. La línea vertical que divide el gráfico entre los proyectos cinco y seis representa el cambio en el criterio de calificación de las asignaciones.

Figura 5.11: Score promedio por proyecto. Capacidad de recuperación.

Finalmente, luego de sucesivos Sprints la herramienta muestra como es capaz de recuperarse ante un cambio dramático en la calidad de los recursos, obteniendo resultados finales muy similares a los capturados en la anterior evaluación.

Como conclusión, luego de las sucesivas planificaciones de los proyectos, la herramienta muestra como es capaz de recuperarse ante un cambio drástico en la calidad de los recursos, obteniendo resultados finales muy similares a los capturados en la anterior evaluación. Cabe destacar, que la curva del score promedio a partir del sprint número 6, crece más lentamente que entre los sprints 1 y 5. Esto se debe a que la memoria organizacional estaba totalmente vacía entre los sprints 1 y 5, mientras que a partir del sprint 6, el algoritmo tuvo que asignar recursos teniendo en cuenta el conocimiento previamente generado en las ejecuciones anteriores.

Capítulo 6

Conclusiones

En este trabajo se desarrolló una herramienta con soporte inteligente que permite una asistencia a miembros de un equipo en la planificación de actividades y asignación a responsables en el contexto de un proceso iterativo e incremental. Como punto de partida, se seleccionó Virtual Scrum, una herramienta de administración de proyectos desarrollada por los estudiantes de la Facultad de Ciencias Exactas de la UNICEN. A la misma, se le incorporó asistencia inteligente, implementando en ella los enfoques propuestos en (Villaverde, 2009) y (Berdún, 2009).El primero enfoque aporta la capacidad de capturar, retener y recuperar la información relevante a la organización en relación a la administración de proyectos a través de una Memoria Organizacional (MO) basada en perfiles de usuario. El otro enfoque presenta un algoritmo de planning para automatizar el planeamiento basándose en el conocimiento organizacional adquirido por el enfoque anterior. El desarrollo y la integración de estos enfoques permitieron enriquecer la herramienta con capacidades de asistencia personalizada para el equipo de desarrollo teniendo como base de conocimiento para tal fin de la Memoria organizacional. Con lo cual, la asistencia al usuario se determina de acuerdo al conocimiento logrado a través de la captura y almacenamiento de las decisiones previas del equipo. De esta forma, se aumenta el conocimiento organizacional y se reduce el impacto que pueda producir la amnesia organizacional.