Definición de la empresa de desarrollo software

La empresa de desarrollo software cuya labor se describe en el presente repositorio ha sido constituida con el fin de cumplir el requisito de formar equipos de trabajo de 4 integrantes, necesario para optar a la evaluación continua en las asignaturas Arquitectura Software para Entornos Empresariales y Gestión de Proyectos Software, del Grado en Ingeniería Informática en la Universidad de Extremadura.

El objetivo principal de la empresa es llevar a cabo las tareas asignadas en ambas asignaturas a lo largo del cuatrimestre. Estas tareas incluyen, por un lado, el desarrollo de una aplicación basada en Netflix en el marco de Arquitectura Software para Entornos Empresariales, y por otro, la planificación detallada de dicho desarrollo como parte de Gestión de Proyectos Software.

A través de la realización de estas tareas, los integrantes de la empresa tienen como meta promover el trabajo en equipo y la entrega continua de valor, simulando un entorno de trabajo profesional. De esta manera, se busca aplicar los principios del desarrollo iterativo y la gestión eficiente de proyectos, proporcionando una experiencia práctica que se alinee con las buenas prácticas de la industria.

Definición del equipo de trabajo

Con el fin de cumplir con la condición de ambas asignaturas de contar con 3 integrantes que cursen ambas asignaturas y un integrante que curse únicamente su asignatura, el equipo de trabajo está conformado por 3 integrantes que cursan ambas asignaturas, un integrante que cursa exclusivamente Arquitectura Software para Entornos Empresariales y otro integrante que cursa exclusivamente Gestión de Proyectos Software:

• Jorge Carmona Leo - alumno de Arquitectura Software para Entornos Empresariales.

• Alberto Fernández Palomo - alumno de Arquitectura Software para Entornos Empresariales y de Gestión de Proyectos Software.

• Javier González Béjar - alumno de Arquitectura Software para Entornos Empresariales y de Gestión de Proyectos Software.

• Sergio Molano García - alumno de Arquitectura Software para Entornos Empresariales y de Gestión de Proyectos Software.

• Hugo Peña Cantonero - alumno de Gestión de Proyectos Software.

Definición de la aplicación a desarrollar

En el marco de la asignatura Arquitectura Software para Entornos Empresariales, se ha establecido que la aplicación a desarrollar estará inspirada en Netflix, un popular servicio de streaming que ofrece una amplia variedad de contenido, incluyendo series, películas, animes, documentales y otros programas galardonados, accesibles en múltiples dispositivos conectados a internet.

Además, debe contar con un componente encargado de la gestión de los usuarios (con y sin permisos de administración), otro encargado de la gestión de los contenidos ofrecidos (películas, episodios de serie y series), otro encargado del algoritmo de recomendaciones personalizadas al usuario (películas y series destacadas de sus géneros favoritos) y otro encargado de la interfaz de usuario.

Si bien la temática de la aplicación está establecida, corresponde a los equipos de trabajo definir las funcionalidades ofrecidas por su aplicación.

Conocedores de que en Gestión de Proyectos Software se pide planificar un proyecto que conste de 16 casos de uso y de las funcionalidades principales ofrecidas en Netflix, se ha decidido desarrollar una aplicación que permita a sus usuarios crearse una cuenta vinculada a su correo electrónico con la que iniciar sesión para así poder buscar películas, series o episodios de serie, para consultar información acerca de estas, o conocer las películas y series más destacadas de un determinado género. Además, el usuario podrá indicar sus 3 géneros favoritos para obtener recomendaciones personalizadas de películas o series que pueden ser de su interés.

Por otro lado, existirán perfiles de usuario con permisos de administración que tendrán la posibilidad de añadir o eliminar películas, series o episodios de serie y de modificar la información asociada a estos si lo estiman oportuno.

Definición de los casos de uso

A continuación se definen los casos de uso que conforman la aplicación a desarrollar, especificando cuáles son estructurales y cuáles no. Estos son esenciales para entender cómo los usuarios interactuarán con la aplicación y qué funcionalidades ofrecerá.

Casos de uso estructurales

1. Creación de cuenta de usuario: Permite a los usuarios crear una cuenta personal para, posteriormente, ingresar su correo electrónico y contraseña en la pantalla de autenticación, accediendo así al resto de las funcionalidades ofrecidas por la aplicación.

2. Inicio o cierre de la sesión de cuentas de usuario: Permite a los usuarios iniciar sesión con su cuenta al ingresar su correo electrónico y contraseña en la pantalla de autenticación. También permite cerrar sesión para regresar a la pantalla de autenticación.

3. Creación de series: Permite a los usuarios con permisos de administración añadir nuevas series a la aplicación.

4. Creación de películas o episodios de series: Permite a los usuarios con permisos de administración añadir nuevas películas o episodios de series a la aplicación.

5. Búsqueda de contenido: Permite a los usuarios buscar películas, episodios de serie, series o géneros en función de una cadena de texto.

6. Consulta de recomendaciones: Permite a los usuarios consultar películas y series recomendadas por la aplicación de forma personalizada, según sus géneros favoritos.

Casos de uso no estructurales

7. Consulta de datos de cuenta: Permite a los usuarios consultar los datos de sus cuentas.

8. Modificación de datos de cuenta: Permite a los usuarios modificar la información de sus cuentas.

9. Borrado de cuenta: Permite a los usuarios eliminar sus cuentas.

10. Consulta de datos de series: Permite a los usuarios consultar los datos de las series disponibles.

11. Modificación de datos de series: Permite a los usuarios con permisos de administración modificar la información de las series.

12. Borrado de series: Permite a los usuarios con permisos de administración eliminar series.

13. Consulta de datos de películas o episodios de series: Permite a los usuarios consultar los datos de películas o episodios de series.

14. Modificación de datos de películas o episodios: Permite a los usuarios con permisos de administración modificar la información de las películas o episodios de series.

15. Borrado de películas o episodios de series: Permite a los usuarios con permisos de administración eliminar películas o episodios de series.

16. Consulta de contenidos por género: Permite a los usuarios consultar películas o episodios de series de un determinado género.

Identificación del modelo del proceso de desarrollo a seguir

Dada la experiencia previa de algunos integrantes del equipo con el modelo elegido, así como la ventaja de concentrar esfuerzos en la planificación de la aplicación al inicio del curso, cuando la carga de trabajo en otras asignaturas aún no es elevada, se ha decidido optar por el Proceso Unificado como modelo de desarrollo a seguir. Esta elección permitirá una mayor dedicación en los siguientes trabajos de Arquitectura Software para Entornos Empresariales y Gestión de Proyectos Software, así como en el desarrollo de la aplicación en fases posteriores.

El Proceso Unificado se caracteriza por su enfoque en ciclos iterativos e incrementales, distribuidos a lo largo de cuatro fases: Inicio, Elaboración, Construcción y Transición. En cada iteración, se busca aumentar el producto mediante la implementación progresiva de mejoras y nuevas funcionalidades.

Además, este proceso está estructurado en torno a casos de uso, que dirigen la carga de trabajo en cada iteración. Las iteraciones siguen un enfoque basado en cinco disciplinas principales: Requisitos, Análisis y Diseño, Implementación, Test e Integración, y Despliegue.

Por último, este enfoque prioriza la evolución iterativa de la arquitectura del sistema, permitiendo que esta se desarrolle y ajuste a medida que se avanza en la aplicación y se agregan nuevas funcionalidades.

Definición del proceso de desarrollo

Tras estudiar la disponibilidad de cada uno de los integrantes del equipo de trabajo, se ha realizado la siguiente distribución de roles dentro del marco del Proceso Unificado:

• Sergio Molano García asumirá el rol de Jefe de Proyecto, con una disponibilidad del 50% y un coste estimado de 50€ por hora.

• Hugo Peña Cantonero asumirá el rol de Arquitecto Software, con una disponibilidad del 70% y un coste estimado de 35€ por hora.

• Javier González Béjar asumirá el rol de Desarrollador Senior, con una disponibilidad del 100% y un coste estimado de 29€ por hora.

• Alberto Fernández Palomo asumirá el rol de Desarrollador Junior, con una disponibilidad del 50% y un coste estimado de 22€ por hora.

En cuanto al desarrollo de los casos de uso, se ha adoptado la suposición de que todos presentan un nivel de complejidad equivalente, lo que implica que el tiempo asignado a cada uno será el mismo. El proyecto se desarrollará a lo largo de siete semanas, lo que equivale a siete iteraciones de una semana de duración cada una.

Cabe destacar que, en la planificación de las iteraciones, más de un rol puede participar en una misma disciplina de un caso de uso. No obstante, cada disciplina asociada a un caso de uso debe completarse dentro de una sola iteración, ya que estas no se dividen entre varias. Estas directrices se seguirán estrictamente a lo largo de la planificación detallada en los apartados posteriores.

Estimación de la aplicación

El plazo total asignado para el desarrollo del proyecto es de 7 semanas. Se estima que cada integrante del equipo de trabajo dedicará teóricamente 30 horas semanales, lo que se traduce en un tiempo total por persona de 210 horas. Sin embargo, la dedicación de cada rol variará según su disponibilidad, lo que se refleja en el siguiente reparto de horas:

• Jefe de Proyecto: 105 horas (50% de 210).

• Arquitecto Software: 147 horas (70% de 210).

• Desarrollador Senior: 210 horas (100% de 210).

• Desarrollador Junior: 105 horas (50% de 210).

En total, sumando las horas dedicadas por cada rol, se obtiene un tiempo total neto de 567 horas dedicadas al proyecto.

Con el tiempo total productivo estimado, se procede a repartirlo entre el Modelado de Negocio y el resto de disciplinas de Casos de Uso. Se ha decidido reservar un 15% del total para el Modelado de Negocio, resultando en 85 horas (15% de 567).

El 85% restante del tiempo se destinará a las disciplinas de Casos de Uso, lo que implica una dedicación de 482 horas (85% de 567).

Además, se ha determinado reservar un 10% extra del 85% destinado a Casos de Uso para el Modelado de Negocio, considerando el esfuerzo adicional requerido en las fases de Inicio y Elaboración. Así, aplicando este 10% al tiempo reservado para Casos de Uso, se obtienen 48,2 horas (10% de 482).

Este tiempo adicional se suma a las horas previamente asignadas al Modelado de Negocio, lo que resulta en un total de 133,2 horas (85 + 48,2).

Como consecuencia, las 48,2 horas adicionales se deducen del tiempo total destinado a Casos de Uso, resultando en 433,8 horas (482 - 48,2).

Estimación de los casos de uso

Siguiendo el tiempo total estimado en el apartado anterior, se ha calculado que, asumiendo que cada caso de uso presenta una complejidad similar, el tiempo dedicado a cada caso de uso es de 27,11 horas (433,8 / 16).

De acuerdo con el flujo de trabajo del Proceso Unificado, la elaboración de cada caso de uso implica completar de forma iterativa e incremental varias disciplinas: Requisitos, Análisis y Diseño, Implementación, Test e Integración y Despliegue. Cada disciplina requiere un esfuerzo y dedicación diferentes.

A continuación, se presentan los porcentajes asignados a cada disciplina, basados en el análisis de dedicación de las fases del Proceso Unificado:

• Requisitos: Esta disciplina se aborda principalmente en las fases de Inicio y Elaboración, con un esfuerzo aproximado del 5% y el 20% respectivamente. Por lo tanto, se le ha asignado un 10% del tiempo total de un caso de uso.

• Análisis y Diseño: Esta disciplina se trata principalmente en la fase de Elaboración, donde se dedica un esfuerzo del 20%. Por ello, se le asigna un 20% del tiempo total de un caso de uso.

• Implementación: Esta disciplina se aborda entre las fases de Elaboración y Construcción, donde el esfuerzo dedicado es del 20% y 65% respectivamente. Por lo tanto, se le asigna un 40% del tiempo de un caso de uso.

• Test e Integración: Los tests se llevan a cabo de manera moderada a lo largo de las fases de Construcción y Transición, con esfuerzos del 65% y 10% respectivamente. Dado que la dedicación a esta disciplina no es tan intensa, se le asigna un 20% del tiempo de un caso de uso.

• Despliegue: Esta disciplina se realiza principalmente durante la fase de Transición, donde se dedica un 10%. Por ello, se le asigna el 10% restante del tiempo total dedicado a un caso de uso.

Aplicando estos porcentajes al tiempo dedicado a cada caso de uso, se obtiene la siguiente distribución del tiempo en cada disciplina:

• Requisitos: 2,71 horas (10% de 27,11).

• Análisis y Diseño: 5,42 horas (20% de 27,11).

• Implementación: 10,84 horas (40% de 27,11).

• Test e Integración: 5,42 horas (20% de 27,11).

• Despliegue: 2,71 horas (10% de 27,11).

Priorización de los casos de uso

A continuación se presenta una aproximación del diagrama de red de los casos de uso de la aplicación. En este diagrama de red se muestra para cada caso de uso, su duración, un inicio temprano, un final temprano y un tiempo máximo disponible.

Cálculo del esfuerzo del equipo

En el desarrollo de la aplicación, se han asignado cuatro roles principales: Jefe de Proyecto, Arquitecto Software, Desarrollador Senior y Desarrollador Junior. Cada uno de estos roles tiene un nivel de dedicación específico, y sus responsabilidades abarcan diversas disciplinas que se desarrollan a lo largo de las iteraciones del proyecto, como el Modelado de Negocio y las disciplinas relacionadas con los Casos de Uso.

Para realizar una asignación precisa y realista de tareas, se ha consultado la documentación del Proceso Unificado proporcionada por la Universidad de Houston. Este material ofrece un desglose detallado de las disciplinas involucradas y los roles que intervienen en cada una. A partir de esta referencia, se ha establecido la siguiente asignación de disciplinas:

• Jefe de Proyecto: Modelado de Negocio, Requisitos y Análisis y Diseño.

• Arquitecto Software: Requisitos, Análisis y Diseño, Implementación y Test e Integración.

• Desarrollador Senior: Análisis y Diseño, Implementación, Test e Integración y Despliegue.

• Desarrollador Junior: Implementación, Test e Integración y Despliegue.

Para ajustar esta asignación a una planificación realista que se adecúe al tiempo disponible de trabajo, se han realizado las siguientes modificaciones:

• Aunque el Arquitecto Software se centra principalmente en la definición de la arquitectura y en guiar a los desarrolladores durante la implementación, dedicará un pequeño porcentaje de su tiempo a colaborar en la disciplina de Test e Integración junto con los desarrolladores.

• De forma similar, el Jefe de Proyecto también dedicará una pequeña parte de su tiempo a colaborar en la disciplina de Análisis y Diseño.

Para calcular el esfuerzo de cada rol, se ha estimado el tiempo disponible que cada uno tiene para dedicar a las diferentes disciplinas en cada iteración. El tiempo total de trabajo disponible se ha distribuido equitativamente entre las siete iteraciones planificadas. A continuación, se presenta la distribución del tiempo asignado a cada rol:

• Jefe de Proyecto: Con un total de 105 horas, dedicará aproximadamente 15 horas por iteración a los casos de uso, además de 133,2 horas extra al Modelado de Negocio.

• Arquitecto Software: Con un total de 147 horas, su dedicación será de 21 horas por iteración a los casos de uso.

• Desarrollador Senior: Con un total de 210 horas, dedicará 30 horas por iteración a los casos de uso.

• Desarrollador Junior: Con un total de 105 horas, su dedicación será de 15 horas por iteración a los casos de uso.

Este cálculo proporciona una estimación clara del esfuerzo de cada miembro del equipo a lo largo del desarrollo del proyecto, asegurando una planificación realista y alineada con la metodología del Proceso Unificado.

Definición de la planificación

Para asegurar una correcta distribución del trabajo y cumplimiento de los plazos del proyecto, se ha elaborado una planificación inicial en la que se distribuyen los distintos casos de uso a lo largo de las 7 iteraciones disponibles. Esta planificación ha sido elaborada y gestionada a través de una hoja Excel.

Distribución de los casos de uso

En la representación de la planificación, se ha seguido el siguiente esquema:

• Eje X: Las 7 iteraciones del proyecto.

• Eje Y: Los casos de uso, donde se resaltan en blanco aquellos que son considerados estructurales, ya que tienen un impacto más significativo en la arquitectura o en el comportamiento global de la aplicación.

• Colores por disciplina: Las disciplinas que se trabajan en cada iteración para los distintos casos de uso se distinguen por colores, lo que permite identificar de manera visual rápida cuál es el miembro del equipo encargado de cada una de ellas.

A continuación, se muestra una imagen representativa de la distribución descrita:

Participación y esfuerzo por rol

El siguiente paso en la planificación consiste en analizar y detallar el esfuerzo y la participación de cada miembro del equipo a lo largo de las iteraciones. Para ello, se ha generado un conjunto de tablas y gráficas que ilustran el tiempo y las disciplinas en las que cada rol ha intervenido, así como la carga de trabajo a lo largo de las iteraciones.

Participación y esfuerzo del Jefe de Proyecto

La participación del Jefe de Proyecto se concentra principalmente en las primeras iteraciones, durante las cuales se enfoca en el análisis de requisitos, tal y como lo establece el Proceso Unificado. No obstante, para equilibrar la carga y cumplir con los plazos, este rol también ha colaborado en tareas de Análisis y Diseño en las iteraciones intermedias.

En la siguiente gráfica de esfuerzo se muestra claramente esta distribución de su tiempo a lo largo de las 7 iteraciones:

En resumen, el Jefe de Proyecto ha destinado un total de 44 horas a tareas específicas de casos de uso, y ha reservado 61 horas adicionales para otras actividades.

Participación y esfuerzo del Arquitecto Software

La participación del Arquitecto Software se concentra principalmente en las primeras cinco iteraciones, ya que su labor se centra en las fases de análisis y diseño. A medida que se acercan las últimas dos iteraciones, el tiempo dedicado disminuye considerablemente, dado que este rol no es el principal responsable de las disciplinas de implementación o despliegue.

No obstante, se ha considerado que el Arquitecto Software dedicará un pequeño porcentaje de su tiempo disponible a colaborar en tareas de tests e integración durante las últimas fases del proyecto.

A continuación, se presenta una gráfica que ilustra la carga de trabajo del Arquitecto Software a lo largo de las iteraciones:

En resumen, el Arquitecto Software ha empleado 121 horas en tareas propias de su rol, y ha reservado 26 horas para otras actividades adicionales.

Participación y esfuerzo del Desarrollador Senior

El Desarrollador Senior tiene una participación similar a la del Arquitecto Software en las fases iniciales, con un enfoque principal en la implementación. Sin embargo, su presencia se extiende significativamente hasta la fase de Transición, ya que es responsable del despliegue y de tareas críticas de integración en las últimas iteraciones.

La siguiente gráfica muestra el esfuerzo dedicado por el Desarrollador Senior a lo largo de las 7 iteraciones:

Finalmente, el Desarrollador Senior ha dedicado 198,11 horas a sus tareas específicas y ha reservado 12 horas para otras actividades del proyecto.

Participación y esfuerzo del Desarrollador Junior

El Desarrollador Junior participa activamente en todas las iteraciones, excepto en las dos primeras, ya que la disciplina en la que comienza a involucrarse —principalmente implementación— no comienza hasta la tercera iteración. A medida que avanza el proyecto, su participación aumenta, especialmente en la implementación y test, donde juega un papel de apoyo en las tareas más técnicas.

La siguiente gráfica refleja su carga de trabajo a lo largo de las iteraciones:

En total, el Desarrollador Junior ha dedicado 105 horas a sus responsabilidades dentro del proyecto.

---

Para llevar a cabo una planificación detallada y adecuada del proyecto, se ha hecho uso de la herramienta ProjectLibre. Esta herramienta de código abierto permite gestionar proyectos de forma colaborativa, facilitando la asignación de tareas, el control del progreso y la distribución de recursos de manera eficiente. Aunque existen alternativas comerciales como Microsoft Project, ProjectLibre se ha elegido por su capacidad para ofrecer funcionalidades similares, como la creación de diagramas de Gantt, la gestión de dependencias y la asignación de recursos.

Planificación por iteraciones

El proyecto se ha estructurado en torno a 7 iteraciones, siguiendo un enfoque iterativo e incremental. En primer lugar, se ha definido la tarea principal denominada "Netflix application", que actúa como contenedor para las diferentes actividades planificadas en cada una de las iteraciones. ProjectLibre maneja tiempos y duraciones con precisión, aunque, como ocurre con la mayoría de herramientas de gestión de proyectos, algunas cifras pueden redondearse a dos decimales, lo que puede causar ligeras diferencias en la duración total estimada.

Cada iteración incluye las tareas asignadas, organizadas en dos grandes grupos principales:

• Management disciplines: Este grupo incluye las tareas relacionadas con el Modelado de Negocio, que se dividen en las siguientes categorías: Project Management, Environment y Configuration & Change Management. Aquí se contempla la participación de roles clave como el Jefe de Proyecto, que ha dedicado una parte de su tiempo a tareas de gestión y soporte, y el Arquitecto Software, quien también participa en actividades relacionadas con la configuración y gestión de cambios.

• Use case disciplines: Este grupo abarca las disciplinas correspondientes a cada caso de uso dentro de las iteraciones. Por ejemplo, en la Iteración 1, se han abordado las disciplinas de Requisitos y Análisis & Diseño para los casos de uso CU01 a CU06, siguiendo la planificación inicial.

El proyecto se ha dividido en cuatro fases clave, con objetivos específicos en cada una antes de avanzar a la siguiente fase. Estas fases se han planificado de la siguiente manera:

• Inicio: Esta fase consta de una única iteración (Iteración 1), donde se define el alcance del proyecto y se realiza el análisis de requisitos para los casos de uso estructurales (CU01 - CU13). Durante esta iteración, también se completa el Análisis y Diseño (A&D) de los primeros cinco casos de uso (CU01 - CU05).

• Elaboración: Esta fase comprende dos iteraciones (Iteración 2 y 3), enfocadas en la implementación de los casos de uso estructurales (CU01 - CU07). Durante esta fase, se completa el análisis y diseño de los casos de uso restantes (CU06 - CU13).

• Construcción: A lo largo de dos iteraciones adicionales (Iteración 4 y 5), se continúa con la implementación de los casos de uso restantes (CU08 - CU13) y se inician los test e integración de los primeros seis casos de uso.

• Transición: Durante las últimas dos iteraciones (Iteración 6 y 7), se finalizan las tareas de test e integración, y se despliegan los casos de uso completados.

Planificación por casos de uso

Además de la planificación basada en iteraciones, se ha llevado a cabo una Planificación por Casos de Uso. En este caso, las tareas se organizan en función de cada caso de uso específico, manteniendo la misma distribución de horas, pero con un enfoque que permite un seguimiento más detallado del progreso en cada uno de los casos de uso del proyecto.

En esta planificación, las tareas de Modelado de Negocio se agrupan en el apartado de Management, mientras que el resto de disciplinas específicas de los casos de uso, como Requisitos, Análisis y Diseño, Implementación, Test e Integración, y Despliegue, se organizan de forma independiente para cada caso de uso. Este enfoque facilita un control más granular de las actividades asociadas a cada caso de uso.

Diagramas de Gantt

Una de las vistas de ProjectLibre más útiles para el seguimiento del proyecto es el Diagrama de Gantt. Este diagrama permite visualizar de manera clara todas las tareas programadas a lo largo del proyecto, incluyendo sus duraciones, recursos asignados y dependencias entre tareas.

Cálculo del coste de la aplicación

Para determinar el coste total de desarrollo de la aplicación, se ha elaborado un informe detallado de la planificación del proyecto. En dicho informe se especifican las fechas de inicio y finalización del proyecto, con una duración total de 49 días, lo que corresponde a 7 semanas de trabajo. Además, se ha calculado el tiempo total empleado en el proyecto, estimándose en 2.537,42 horas.

El coste total del proyecto asciende a 120.189,12€, teniendo en cuenta las tarifas horarias de los diferentes miembros del equipo y el tiempo dedicado por cada uno de ellos.

Desglose del coste por participante

A continuación, se ofrece un análisis detallado del coste total acumulado por cada uno de los roles participantes en el proyecto. Este desglose permite una visión más precisa de la contribución económica de cada miembro en función de sus tarifas horarias y el tiempo invertido en las diferentes disciplinas.

Desglose del coste por Alberto Fernández Palomo

• Coste por hora: 22€/hora.

• Coste total: 4.395,16€.

Desglose del coste por Javier González Béjar

• Coste por hora: 29€/hora.

• Coste total: 15.507,46€.

Desglose del coste por Sergio Molano García

• Coste por hora: 50€/hora.

• Coste total: 90.120,00€.

Desglose del coste por Hugo Peña Cantonero

• Coste por hora: 35€/hora.

• Coste total: 10.167,50€.

Gráfico del coste total acumulativo

Para facilitar la comprensión del coste total del proyecto, a continuación se presenta un gráfico acumulativo que refleja cómo se ha distribuido el coste a lo largo del desarrollo. En este gráfico, se observa la evolución del gasto total conforme avanzan las iteraciones y se completan las tareas asignadas a cada uno de los participantes.