Plan de Proyecto Software

Introducción

La planificación de todo proyecto es un proceso de gestión organizado e integrado, centrado en las actividades necesarias para asegurar una exitosa consecución del proyecto. Esta planificación contribuye a una mejor utilización de los recursos, y a un uso óptimo del tiempo asignado a un proyecto, algo crucial en todo proyecto, y especialmente relevante en el caso de un Trabajo de Fin de Grado (TFG).

En este apartado se recogen los aspectos más relevantes en cuánto a la planificación temporal de nuestro proyecto, así como su viabilidad, tanto económica como legal.

Planificación temporal

Una de las primeras decisiones que se llevaron a cabo en el marco del proyecto JIZT, fue la elección de la metodología de desarrollo software que adoptaríamos.

Lo primero que llevamos a cabo fue un análisis de las necesidades y limitaciones que presentaba nuestro proyecto, las cuales eran: tiempo limitado, eficiencia y velocidad, motivación y progreso del proyecto, y satisfacción de los usuarios.

Derivado de estas necesidades, se decidió que emplearíamos una metodología ágil. Las principales metodologías ágiles consideradas fueron Scrum, Kaban y Programación Extrema (XP).

Finalmente, nos decantamos por Kanban. Esta decisión estuvo en gran medida motivada por el hecho de que una planificación temporal rígida y prefijada, como ocurre por ejemplo en Scrum, era muy difícil de llevar a cabo en este proyecto dada nuestra inexperiencia con muchas de las herramientas y frameworks utilizados.

Kanban nos permitía un flujo continuo de trabajo, permitiendo añadir historias de usuario no contempladas inicialmente si así se consideraba apropiado.

En total se estimaron 523,15 horas, empleando finalmente 542,92:

Horas estimadas frente horas empleadas.

Figura 37 Horas estimadas frente horas empleadas.

En esta planificación, se emplearon dos conceptos ágiles fundamentales:

  • Historia de usuario: se trata de una descripción de una funcionalidad del software a implementar.

  • Epics: agrupan historias de usuario que conformen una misma feature, o funcionalidad a desarrollar.

En total, se especificaron 99 historias de usuario repartidas entre 8 epics1. Estos epics fueron, ordenados de manera cronológica:

  • Puesta en marcha: tareas preliminares de organización y puesta en marcha del proyecto (elección de metodologías, herramientas, etc.).

  • Motor de Resumen v0.1: implementar una primera versión del Motor de Resumen a través de los modelos preentrenados proporcionados por el módulo transformers de Hugging Face [transformers].

  • Arquitectura Microservicios v0.1: implementar una primera versión reducida de la Arquitectura de Microservicios, configurando el componente Ingress de Kubernetes [ingress], y dos microservicios: el Dispatcher y el Pre-procesador de textos.

  • Arquitectura Microservicios v0.2: continuar con la implementación de la arquitectura de microservicios, añadiendo la capacidad de realizar peticiones asíncronas y desarrollando la arquitectura dirigida por eventos. De momento, se sigue trabajando con una versión de la misma, esto es, con el Dispatcher y el Pre-procesador de textos.

  • Arquitectura Microservicios v0.3: una vez disponemos de una versión reducida de nuestra arquitectura que funciona correctamente en local, el siguiente paso es desplegarla en Google Kubernetes Engine (GKE) [gke]. Además, se deben implementar los microservicios restantes (Codificador, Motor de Resumen y Post-procesador) y la base de datos para gestionar los resúmenes.

  • Cliente v0.1: desarrollar el cliente (aplicación) que consumirá la API y permitirá al usuario final obtener resúmenes de sus textos. Dicho cliente se implementará con ayuda de Flutter [flutter-es], por lo que en principio estará disponible en plataformas móvil, web y escritorio.

  • Arquitectura Microservicios v0.4: ampliar la especificación de la API para que en las peticiones se puedan detallar todos los parámetros del resumen. Continuar con la mejora del sistema.

  • Documentación v0.1: escribir la Memoria y los Anexos. Generar una primera versión de la documentación de la API REST y del código perteneciente a JIZT.

En la siguiente figura se recoge un diagrama Gantt con el objetivo de facilitar la comprensión de la dimensión temporal del proyecto:

El proyecto comenzó el 1 de octubre de 2021, y finalizó el 16 de febrero de 2021.

Figura 38 El proyecto comenzó el 1 de octubre de 2021, y finalizó el 16 de febrero de 2021.

Dos conceptos importantes dentro de la metodología son lead time y cycle time [anderson10]. Veamos qué significa cada uno de ellos.

  • Lead time: es el período que transcurre entre la aparición de una nueva tarea en el flujo de trabajo y su salida final del sistema. Dicho de otro modo, es el tiempo total que el cliente está esperando la entrega de una parte del producto.

  • Cycle time: es la cantidad de tiempo que el equipo realmente empleó en una tarea, es decir, no se cuenta el tiempo que una tarea estuvo «en espera». Por lo tanto, el tiempo del ciclo debe comenzar a medirse cuando la tarea pasa a la columna «trabajando», y no antes.

Explicación gráfica del *lead* y *cycle time* sobre un tablero Kanboard.

Figura 39 Explicación gráfica del lead y cycle time sobre un tablero Kanboard.

Esta métrica nos aporta información que nos permite conocer cuánto tiempo tardaremos en entregar una determinada parte del producto. Es importante mantener el lead y cycle time tan cortos como sea posible, a fin de mantener pocas tareas «en ejecución» (WIP), permitiendo mantener un flujo constante de trabajo y aportar valor al cliente de manera frecuente.

Gráfico de *lead* y *cycle time* medios.

Figura 40 Gráfico de lead y cycle time medios.

Como vemos en la anterior figura, el lead time medio fue de algo menos de 7 días, y el cycle time de 4 días y 8 horas. Como es lógico, las primeras tareas se completaron más rápido, pero según la complejidad de las mismas fue incrementándose, también se reflejó en los tiempos. En el punto central del proyecto, se alcanzó una media de lead time de 9 días, aunque el cycle time se mantuvo por debajo de los 5, lo que indica que existía un mayor número de tareas esperando a ser atendidas.

Otro de los gráficos propios de Kanban que nos puede ofrecer información valiosa es el llamado diagrama de flujo acumulado (CFD, por sus siglas en inglés). Este gráfico muestra el número de tareas que hay en cada columna a lo largo del tiempo.

Diagrama de flujo acumulado desde el comienzo del proyecto.

Figura 41 Diagrama de flujo acumulado desde el comienzo del proyecto.

Como se aprecia en el anterior diagrama, el trabajo en las diferentes columnas se distribuyó de forma correcta, no apareciendo grandes diferencias entre ellas. En este gráfico, también podemos apreciar que en la parte central del proyecto, las tareas en «Work in progress» fueron algo mayores que en el resto de columnas, lo cual es comprensible.

El diagrama de flujo acumulado obtenido muestra también que el ritmo de trabajo fue constante, incrementándose ligeramente hacia el final del proyecto.

Podemos visualizar también la distribución de las tareas en función de su tipo:

Distribución de las tareas según su tipo.

Figura 42 Distribución de las tareas según su tipo.

Como es lógico, la mayor parte de las tareas se dedicaron a ofrecer nuevas funcionalidades (feature), aunque gran número de ellas se dedicaron al aprendizaje y búsqueda de información (research), lo cual también parece ajustarse a la realidad, puesto que como ya hemos mencionado, muchas de las herramientas y técnicas que hemos utilizado eran nuevas para nosotros.

Para finalizar esta sección, cabe mencionar que en el repositorio del proyecto, y en su tablero Kanban, se puede encontrar información más detallada de cada historia de usuario y epic.

Estudio de viabilidad

Viabilidad económica

Uno de los puntos cruciales a la hora de estudiar la viabilidad de un proyecto, y que en muchos casos determina el éxito o el fracaso del mismo, es la viabilidad económica.

En esta sección analizamos los costes y beneficios de JIZT.

Costes del proyecto

En nuestro caso, dividiremos los costes del proyecto en costes fijos, directos e indirectos.

Costes fijos

Los costes fijos son aquellos costes invariables que debemos abonar, independientemente del desarrollo del proyecto [perez18].

Tabla 2 Desglose de costes fijos del proyecto.

CONCEPTO

IMPORTE

Servicio de Internet

200,00 €

Servicio de Luz2

225,00 €

Materiales de oficina

5,00 €

Salarios3

9911,88 €

» Salario mensual neto

1000,00 €

» Retenciones por IRPF (24%)4

528,63 €

» Cuotas a la Seg. Social (30,6%)5

674,01 €

» Salario mensual bruto

2202,64 €

TOTAL

10341,88 €

Costes directos

Los costes directos son aquellos costes derivados directamente del desarrollo del proyecto.

Tabla 3 Desglose de costes directos del proyecto.

CONCEPTO

IMPORTE

Dominio jizt.it

4,81 €

Cuenta de Google Play

20,76 €

Impresión de la Memoria y el cartel del TFG

60,00 €

TOTAL

85,57 €

Costes indirectos

Los costes indirectos son aquellos que no dependen directamente del desarrollo del proyecto.

Tabla 4 Desglose de costes indirectos del proyecto.

CONCEPTO

IMPORTE

AMORTIZ.

Costes de hardware6

2509,58 €

79,49 €

» Ordenador personal

845,00 €

63,37 €

» Smartphone Android

215,00 €

16,12 €

» Servicio GKE7 de Google Cloud

1449,58 €

-

Costes de software8

89,95 €

16,86 €

» Adobe Illustrator

89,95 €

16,86 €

TOTAL

2599,53 €

96,35 €

Costes totales del proyecto

Considerando las tres categorías de costes recogidas anteriormente, la suma de los costes totales del proyecto asciende a 13026,98 €.

Beneficios

La API REST de JIZT se ofrece en tres planes de suscripción diferentes.

  • Gratuito: este plan se ajusta a las necesidades de cualquier usuario regular que no vaya a realizar un uso exhaustivo del servicio. Se permiten 5.000 peticiones a la API REST, pudiendo hacerse hasta 5 peticiones por minuto. No incluye soporte técnico.

  • Estándar: para aquellas empresas o particulares que van a realizar un uso más intensivo del servicio. Se incluyen 15.000 peticiones a la API REST, pudiendo hacerse hasta 15 peticiones por minuto. Incluye soporte técnico y de integración. El precio es de 166 €/mes.

  • Personalizado: para aquellos usuarios cuyas necesidades no encajen en ninguno de los anteriores planes. El precio se establecerá en función de los requerimientos concretos del usuario. Por ejemplo, este plan podría incluir el despliegue del backend de JIZT para el cliente, bien en sus propias dependencias, o bien a través de un cloud provider. De esta forma, este tipo de clientes tendrían control total sobre el backend, sin experimentar ninguna de las limitaciones recogidas anteriormente. El posterior mantenimiento del servicio podría estar incluido o no.

En cuanto a la aplicación, es totalmente gratuita y no contiene publicidad.

Análisis DAFO

Tras llevar a cabo un pequeño análisis de mercado, hemos identificado que las principales debilidades, amenazas, fortalezas y oportunidades de nuestro proyecto son las siguientes:

Análisis DAFO de JIZT.

Figura 43 Análisis DAFO de JIZT.