Naxter
Una plataforma de creación y consumo de contenido social
Autor:
Carlos Otero Franjo Tutor:
Bruno Francisco Orcha García Profesor responsable de la asignatura:
César Pablo Córcoles
Máster en Desarrollo de Sitios y Aplicaciones Web
Enero de 2023
Trabajo de Fin de Máster presentado en el Máster en Desarrollo de Sitios y Aplicaciones Web de la Universitat Oberta de Catalunya para la obtención del Máster Universitario
Reservados todos los derechos. Está prohibido la reproducción total o parcial de esta obra por cualquier medio o procedimiento, comprendidos la impresión, la reprografía, el microfilme, el tratamiento informático o cualquier otro sistema, así como la distribución de ejemplares mediante alquiler y préstamo, sin la autorización escrita del autor o de los límites que autorice la Ley de Propiedad Intelectual.
Ficha del trabajo final
Título del trabajo Naxter: Una plataforma de creación y consumo de contenido social
Nombre del autor Carlos Otero Franjo
Nombre del consultor/a Bruno Francisco Orcha García Nombre del PRA César Pablo Córcoles
Fecha de entrega (mm/aaaa) 01/2023
Titulación o programa Máster en Desarrollo en Sitios y Aplicaciones Web
Área del trabajo final Informática, Multimedia y Telecomunicación / Desarrollo Web
Idioma del trabajo Castellano
Palabras clave Publicación, consumo, token
I
La realización de este Trabajo de Fin de Máster se resume en la ejecución de un proyecto que desarrolle una plataforma de generación y consumo de contenido social, similar a un blog, haciendo uso de la metodología ágil Scrum, donde los usuarios con los permisos adecuados podrán realizar las publicaciones que requieran, relacionadas con un tema concreto, permitiendo subir contenido multimedia, de manera que quede a disposición de los usuarios compartir el tipo de contenido que ellos gusten y permitir consumirlo al resto de usuarios, obteniendo valoraciones, visitas y comentarios. Esta plataforma tendrá también funcionalidades de mensajería entre usuarios a través de chats, y una funcionalidad de merchandising.
De esta manera, este producto se definirá como una plataforma en la que los usuarios podrán compartir y debatir entre ellos sobre diversos temas, permitiendo crear y consumir contenido social variado, como también centrado y clasificado a partir los gustos de cada uno de los usuarios de la plataforma.
Abstract
The development of this master's final work is summarized in the execution of a project that develops a platform for the generation and consumption of social content, similar to a blog, using the agile Scrum methodology, where users with the appropriate permissions will be able to carry out posts they require, related to a specific theme, allowing the upload of multimedia content, so that it’s available to users to share the type of content they like and allow other users to consume it, obtaining ratings, visits and comments. This platform will also have messaging features between users through chats, and a merchandising feature.
So this product will be defined as a platform in which users can share and debate among themselves on various themes, allowing the creation and consumption of varied social content, as well as focused and classified based on users’s liking of the platform.
II
Capítulo 1...1
Introducción...1
1.1. Contexto y justificación...1
1.2. Objetivos...2
1.3. Impacto en sostenibilidad, ético-social y de diversidad...3
1.4. Sumario de productos obtenidos...4
1.5. Organización del documento...5
Capítulo 2...6
Gestión del proyecto...6
2.1. Enfoque y método seguido...6
2.2. Metodología de desarrollo...7
2.3. Gestión de la configuración...10
2.3.1. Gestión de las herramientas...11
2.3.2. Control de versiones...12
2.4. Planificación temporal...13
2.4.1. Planificación, definición y análisis de requisitos...17
2.4.2. Diseño, arquitectura y desarrollo de los subsistemas de seguridad y administración...17
2.4.3. Desarrollo del subsistema de perfiles...18
2.4.4. Desarrollo del subsistema de publicaciones...19
2.4.5. Desarrollo del subsistema de mensajería...20
2.4.6. Desarrollo del subsistema de merchandising...20
2.4.7. Documentación...21
2.4.8. Finalización...21
2.5. Gestión de las comunicaciones...22
2.5.1. Gestión e identificación de los interesados...22
2.5.2. Planificación de las comunicaciones...23
2.6. Gestión de costes...24
2.6.1. Medios materiales necesarios...24
2.6.2. Presupuesto del proyecto...25
III
Análisis de requisitos...28
3.1. Contexto de ingeniería...29
3.2. Análisis de mercado y descripción técnica de la competencia...30
3.3. Viabilidad...31
3.4. Usabilidad...32
3.4.1. Público objetivo...32
3.4.2. Personas usuarias...33
3.4.3. Sitemap...35
3.4.4. Patrones de usabilidad...37
3.5. Requisitos de información, funcionales y no funcionales...40
3.6. Casos de uso...42
3.6.1. Subsistema de seguridad...44
3.6.2. Subsistema de administración...45
3.6.3. Subsistema de perfiles...46
3.6.4. Subsistema de publicaciones...47
3.6.5. Subsistema de mensajería...48
3.6.6. Subsistema de merchandising...49
Capítulo 4...50
Diseño y arquitectura del sistema...50
4.1. Tecnologías...50
4.2. Arquitectura del sistema...51
4.2.1. Patrones de diseño...54
4.2.2. Front-end Angular...55
4.2.3. Back-end Spring Boot...56
4.2.4. Gradle...56
4.2.5. JWT (JSON Web Tokens)...57
4.2.6. Base de Datos MongoDB...57
4.4. Diagrama de clases...58
4.5. Diagramas de secuencia...60
4.5.1. Diagrama de secuencia del proceso de login...60
4.6. Wireframes...62
4.6.1. Subsistema de administración...63
4.6.2. Subsistema de perfiles...64 IV
Capítulo 5...66
Implementación de la aplicación...66
5.1. Planificación, definición y análisis de requisitos...67
5.2. Diseño, arquitectura y desarrollo de los subsistemas de seguridad y administración 68 5.3. Desarrollo del subsistema de perfiles...69
5.4. Desarrollo del subsistema de publicaciones...70
5.5. Desarrollo del subsistema de mensajería...72
5.6. Desarrollo del subsistema de merchandising...74
5.7. Documentación...74
5.8. Finalización...75
5.9. Despliegue...75
5.9.1. Heroku...75
5.9.2. Fly.io...76
5.9.3. AWS...77
Capítulo 6...78
Pruebas...78
6.1. Plan de pruebas...78
6.1.1. Objetivos del plan de pruebas...78
6.1.2. Alcance de las pruebas...79
6.1.3. Responsable de las pruebas...79
6.1.4. Ejecución de las pruebas...79
Capítulo 7...80
Conclusiones...80
Glosario...84
Bibliografía...85
Anexos...87
V
Ilustración 1: EDT...14
Ilustración 2: Diagrama de Gantt a alto nivel del proyecto...15
Ilustración 3: Diagrama de Gantt del proyecto...16
Ilustración 4: Diagrama de Gantt de la 1ª iteración...17
Ilustración 5: Diagrama de Gantt de la 2ª iteración...18
Ilustración 6: Diagrama de Gantt de la 3ª iteración...19
Ilustración 7: Diagrama de Gantt de la 4ª iteración...19
Ilustración 8: Diagrama de Gantt de la 5ª iteración...20
Ilustración 9: Diagrama de Gantt de la 6ª iteración...21
Ilustración 10: Diagrama de Gantt de la etapa de documentación...21
Ilustración 11: Diagrama de Gantt de la 7ª iteración...22
Ilustración 12: Sitemap...36
Ilustración 13: Patrón global header...37
Ilustración 14: Patrón card...37
Ilustración 15: Patrón tag...38
Ilustración 16: Patrón tooltip...38
Ilustración 17: Patrón notification...39
Ilustración 18: Patrón fat footer...39
Ilustración 19: Diagrama de casos de uso del subsistema de seguridad...44
Ilustración 20: Diagrama de casos de uso del subsistema de administración...45
Ilustración 21: Diagrama de casos de uso del subsistema de perfiles...46
Ilustración 22: Diagrama de casos de uso del subsistema de publicaciones...47
Ilustración 23: Diagrama de casos de uso del subsistema de mensajería...48
Ilustración 24: Diagrama de casos de uso del subsistema de merchandising...49
Ilustración 25: Diagrama de arquitectura...52
Ilustración 26: Diagrama de componentes...53
Ilustración 27: Diagrama de clases...59
Ilustración 28: Diagrama de secuencia del proceso de login...61
Ilustración 29: Wireframe del subsistema de administración...63
Ilustración 30: Wireframe del subsistema de perfiles...64
Ilustración 31: Wireframe de una publicación del subsistema de publicaciones...65
VI
Ilustración 33: Pantalla del subsistema de mensajería...73
Índice de tablas
Tabla 1: Coste del trabajador...26Tabla 2: Coste del equipo...26
Tabla 3: Coste total del proyecto...27
Tabla 4: User Persona 1...34
Tabla 5: User Persona 2...35
Tabla 6: Requisitos de información...40
Tabla 7: Requisitos funcionales...41
Tabla 8: Requisitos no funcionales...42
Tabla 9: Casos de uso del subsistema de seguridad...44
Tabla 10: Casos de uso del subsistema de administración...45
Tabla 11: Casos de uso del subsistema de perfiles...46
Tabla 12: Casos de uso del subsistema de publicaciones...48
Tabla 13: Casos de uso del subsistema de mensajería...49
Tabla 14: Casos de uso del subsistema de merchandising...49
VII
Capítulo 1
Introducción
En este primer capítulo se requiere introducir el proyecto del Trabajo de Fin de Máster, exponiendo el contexto y justificando la necesidad del trabajo, analizando los objetivos y su impacto en sostenibilidad, ético-social y de diversidad.
1.1. Contexto y justificación
Las plataformas de contenido social que se alojan en sitios y aplicaciones web permiten publicar contenido diverso que se desee compartir, posibilitando actualizar y recopilar contenido con diferentes recursos de uno o varios autores. Para que las plataformas sociales sean más eficaces, como punto de partida, se debe disponer de medios tecnológicos adecuados para gestionar contenido dinámico, fácilmente usable para los distintos usuarios. De esta manera se agiliza y se proporciona una optimización a la hora de trabajar con este tipo de contenido y, por supuesto, cumpliendo en todo momento con los objetivos de crear y consumir los diversos recursos del sistema a los usuarios finales, independientemente de su perfil.
La realización de este Trabajo de Fin de Máster consiste en una aplicación de gestión de contenido social y digital y su preproducción, que se basa en la ejecución de un proyecto que desarrolle una aplicación web Spring [1] y Angular [2], para la gestión de una plataforma de generación y consumo de contenido social, de manera que permita la creación y posterior navegación sobre estos recursos. La implementación de esta plataforma de contenido social, originará un tema relevante, ya que será similar a un blog, donde los usuarios con los permisos adecuados, podrán realizar las publicaciones que requieran relacionadas con un tema concreto, permitiendo exponer en ellas contenido multimedia como fotos. De esta manera queda a disposición de los usuarios compartir el tipo de contenido que ellos gusten y permitir consumirlo, obteniendo valoraciones y comentarios, como sucede en plataformas que desarrollan foros como Reddit. Esta plataforma web tendrá también funcionalidades de 1
mensajería entre usuarios a través de chats, como sucede en las redes sociales de Twitter, Facebook o Instagram, y la funcionalidad de merchandising, como también sucede en esta última de Instagram. Por lo tanto, este producto ejecutará un entorno, resolviendo esta necesidad, en el que los usuarios podrán compartir y debatir entre ellos sobre diversos temas, permitiendo crear y consumir contenido social variado, como también centrado y clasificado a partir los gustos de cada uno de los usuarios del marco adecuado.
Como ya se mencionó anteriormente, enfocándose en el contexto de operatividad y requisitos del sistema, se resolverá esta necesidad al iniciar el proyecto, permitiendo la gestión de usuarios a través de sus perfiles, roles y permisos en función de estos. Se implementará una gestión de temas y publicaciones, etiquetas representativas, ejecución de suscripciones, posibilidad de realizar y plantear comentarios, valoraciones y visitas a los perfiles, introducir contenido multimedia, mensajería entre usuarios a través de chats individualizados, y finalmente una sección de merchandising por medio de sus productos. Los roles a gestionar para los usuarios, y así gestionar los diferentes permisos y funcionalidades son: sin autenticación, genérico, consumidor, moderador, productor y administrador, y cada rol superior tendrá los permisos de este rol y del rol inmediatamente inferior.
La aplicación resultante a obtener se desarrolla en Spring, Angular y MongoDB [3] ya que hoy en día los productos desarrollados con estas tecnologías se cuentan por millones, y cada día a la web se suman miles de nuevas aplicaciones y sitios de desarrolladores de todo tipo en todo el mundo. A través de estas tecnologías se posee una gran capacidad de personalización mediante el uso de sus frameworks y herramientas, presentes a día de hoy en la realización de la mayoría de aplicaciones, por eso se realizará esta aportación y desarrollo en este Trabajo de Fin de Máster a través de la plataforma web descrita. Para el desarrollo del proyecto se hará uso de Visual Studio Code, IntelliJ IDEA Ultimate y JDK (Java Development Kit) 17 para poder realizar de manera correcta el programa a desarrollar, como también otras APIs (Application Programming Interface) y dependencias que se añadirán a medida que se avance en el proyecto para poder completarlo correctamente.
1.2. Objetivos
A continuación, una vez introducido el proyecto, se procede a indicar el objetivo principal de este Trabajo de Fin de Máster, que consiste en el diseño e implementación de una aplicación web que permita:
2
▪ El envío de datos e información entre el cliente y servidor de forma segura y válida, manejado a través de la autenticación y la generación de tokens (OBJ-01).
▪ La gestión de usuarios y sus perfiles que harán uso de la aplicación, consistentes en diversos roles que permitan el control de permisos y el acceso a las funcionalidades finales del sistema (OBJ-02).
▪ La gestión de publicaciones de temáticas variadas, consistentes en recursos dinámicos como etiquetas, suscripciones, comentarios, valoraciones, además de contenido multimedia que los usuarios puedan incorporar (OBJ-03).
▪ El envío de mensajes entre usuarios a través de un chat individualizado y personalizado que permita una comunicación clara y precisa entre sus participantes (OBJ-04).
▪ La gestión de la sección de merchandising de los usuarios que activen en su correspondiente perfil (OBJ-05).
1.3. Impacto en sostenibilidad, ético-social y de diversidad
En este apartado se planteará una reflexión para identificar los impactos positivos y negativos en las tres dimensiones de la Competencia de Compromiso Ético y Global (CCEG) apoyándose en el marco de referencia de los Objetivos de Desarrollo Sostenible (ODS).
En la dimensión de sostenibilidad, se considera que el resultado de este proyecto no tiene ningún impacto, ni positivo ni negativo en aspectos de sostenibilidad medioambiental y ecológica, ya sea referente al consumo energético o contaminación, ni en su desarrollo y periodo de explotación, ya que en este proyecto se hace referencia a una aplicación de creación y consumo contenido digital, por lo que no afectaría a estos indicadores. De igual forma, tampoco se considera que impacte en alguno de los objetivos ODS relacionados con la energía limpia, industria, sostenibilidad, consumición y producción de recursos, cambio climático o vida animal. En cuanto a la dimensión de comportamiento ético y de responsabilidad social (RS), se considera que el resultado de este proyecto puede tener tanto impactos negativos como positivos en aspectos ético-sociales, no con impacto en los ODS ni en privacidad de los datos y propiedad intelectual, pero sí relacionados con los usuarios, al poder subir contenido en sus publicaciones o comentarios poco ético respecto a la sociedad u otros
3
usuarios. Para minimizar estos comportamientos se tienen los roles superiores de moderadores y administradores para poder bloquear su actividad y eliminar su contenido. También puede tener un impacto positivo, como es la creación y subida de contenido que ayude a mejorar el comportamiento y sociedad actual, influyendo en mejoras sociales y desigualdades.
Finalmente, relacionado con la dimensión de diversidad, género y derechos humanos, se considera que el resultado de este proyecto puede tener tanto impactos negativos como positivos en aspectos de género o diversidad, no con impacto en la privacidad, propiedad intelectual o seguridad de las personas, pero sí en los ODS 5 – Gender equality u ODS 10 – Reduced equality, colectivos de alguna raza, religión ideología u orientación sexual, ya que, como ya sucedía en la anterior dimensión, los usuarios productores y consumidores de contenido, pueden generar contenido en sus publicaciones y comentarios que perjudique negativamente en estos indicadores. Como ya se mencionó, para minimizar estos comportamientos se tienen los roles superiores de moderadores y administradores para poder bloquear su actividad y eliminar su contenido cuando se identifique. De la misma forma, este contenido que generan los usuarios, puede impactar positivamente en la generación de contenido y en sus valoraciones o comentarios, que permita ayudar a mejorar estos indicadores.
1.4. Sumario de productos obtenidos
Los productos obtenidos para el proyecto será los siguientes, en los cuales se proporcionará la implementación de los subsistemas de la aplicación:
▪ Proyecto Gradle [4] preparado para ejecución con los siguientes ficheros y directorios:
gradle/, src/, build.gradle, settings.gradle, gradlew y gradlew.bat. Mediante el comando gradlew bootJar se generará el .jar en el directorio build/libs, el cual se puede ejecutar mediante el comando java -jar <file_name>.jar.
▪ Proyecto Angular preparado para ejecución con el directorio raíz y sin los directorios node_modules/ y .angular/. Mediante estos archivos se podrá ejecutar npm i para la instalación de las dependencias y ejecutar ng serve para la ejecución de la aplicación.
Estos proyectos estarán alojados en los siguientes repositorios y desplegados en las siguientes plataformas:
4
▪ Repositorios Github:
▪ Servidor Spring: https://github.com/coterofr/naxter-server
▪ Cliente Angular: https://github.com/coterofr/naxter
▪ Aplicaciones desplegadas:
▪ Servidor Spring: https://naxter-server.fly.dev/
▪ Cliente Angular: https://naxter.fly.dev/
1.5. Organización del documento
El documento de la memoria para este Trabajo de Fin de Máster estará subdivido en diferentes capítulos correspondientes a las etapas desempeñadas en cada iteración del proyecto.
▪ El Capítulo 1 describe e introduce el proyecto y la aplicación desarrollada, de manera que se entienda y establezcan los objetivos principales para este Trabajo de Fin de Máster.
▪ En el Capítulo 2 se define la gestión del proyecto, en la cual se establece la metodología, la gestión de la configuración, la planificación temporal, la gestión de comunicaciones y la gestión de costes.
▪ En el Capítulo 3 se realiza y especifica el análisis de requisitos, donde se documenta el contexto de ingeniería y una descripción técnica de otras aplicaciones relacionadas, los casos de uso, y los anexos de los requisitos de información, los requisitos funcionales y los requisitos no funcionales.
▪ En el Capítulo 4 se explica y comenta el diseño y arquitectura del sistema a través del diagrama de arquitectura, el diagrama de componentes, el modelo entidad- relación, el diagrama de clases y los diagramas de secuencia.
▪ En el Capítulo 5 se realiza una descripción de todo el proceso de implementación transcurrido a lo largo de las iteraciones del ciclo de vida del proyecto, desde su comienzo a través de las primeras etapas de formación, gestión y análisis, hasta su finalización, cierre y entrega.
▪ En el Capítulo 6 se define el proceso de pruebas, documentando el plan de pruebas a través de sus objetivos y alcance, como también de los casos de prueba sobre los requisitos funcionales y no funcionales identificados en la etapa de análisis.
▪ Finalmente, en el Capítulo 7 se describen las conclusiones finales junto con las lecciones aprendidas y la experiencia obtenida en este Trabajo de Fin de Máster.
5
Capítulo 2
Gestión del proyecto
A la hora de desarrollar un proyecto, se debe gestionar de manera exacta y precisa, administrando su inicio y evolución, controlando y respondiendo ante problemas que surjan durante el desarrollo del mismo, y logrando el éxito en su finalización y aprobación. De este modo se consiguen reducir los errores que puedan aparecer. Por lo tanto esta gestión consiste en el empleo de técnicas y conocimientos orientados a planificar los procesos del proyecto de principio a fin, a lo largo de su ciclo de vida, y por tanto cumplir el plan de proyecto dentro de las restricciones temporales, de calidad, de costes, y de alcance del producto a desarrollar.
Una vez introducido el capítulo, y considerándolo fundamental para lograr un desenvolvimiento correcto del proyecto, se describirán: el enfoque y método seguido, la metodología de desarrollo, la gestión de la configuración, la planificación temporal, la gestión de comunicaciones, y la gestión de costes.
2.1. Enfoque y método seguido
En este apartado se procede a indicar cuál es la estrategia para llevar a cabo el trabajo y conseguir los objetivos propuestos, que en este caso es el desarrollo de una nueva aplicación web. Esta nueva aplicación sobre el Trabajo de Fin de Máster requiere la gestión de contenido social y digital, y se fundamenta en la implementación de un sistema que desarrolle una aplicación web para la gestión de una plataforma de generación y consumo de contenido social, de manera que permita la creación y posterior consumo de estos recursos generados.
La implementación de esta plataforma de contenido social se contextualiza de manera semejante a un sistema de blog, donde los usuarios con los permisos adecuados podrán realizar las publicaciones que requieran relacionadas con un tema concreto. Queda a disposición de estos usuarios compartir el tipo de contenido que ellos gusten y permitir consumirlo,
6
obteniendo valoraciones y comentarios. Esta plataforma, como ya se mencionó anteriormente, tendrá también funcionalidades de mensajería entre usuarios a través de chats, y de merchandising. Por lo tanto, esta nueva aplicación deberá satisfacer los objetivos de que los usuarios finales puedan compartir y debatir entre ellos sobre diversos temas, permitiendo crear y consumir contenido social variado, como también centrado y clasificado a partir los gustos de cada uno de los usuarios con los perfiles y permisos adecuados.
De esta manera, como ya se indicó al inicio del apartado, para llevar a cabo esta estrategia, se implementará un nuevo producto a partir de las pautas indicadas, siguiendo la planificación establecida y desarrollando y validando los requisitos especificados en cada una de las iteraciones definidas al inicio del proyecto.
2.2. Metodología de desarrollo
En este apartado se procede a justificar y explicar la selección de la metodología de desarrollo en el proyecto actual de Trabajo de Fin de Máster. Conforme ya es sabido, muchos proyectos fracasan debido a diversas causas como una mala planificación temporal o económica, que puede llevar a sobrecostes que no se pueden abarcar en el proyecto. Muchas veces estas causas están relacionadas con la selección de la metodología, ya que dependiendo del proyecto en el que se encuentra, podrán ser más beneficiosas unas metodologías u otras.
No existen metodologías buenas o malas, ya que todas responden a problemas que surgen en la gestión de proyectos, sin embargo, hay algunas más eficaces en determinados contextos, donde radica la principal diferencia, como puede ser la capacidad de respuesta. Es por ello que la elección de la metodología que más se adecúa al tipo de proyecto que se pretende desarrollar es fundamental, donde si se realiza una mala elección pueden provocar las causas anteriormente mencionadas, ocasionando la imposibilidad de avanzar en el proyecto.
La selección de una metodología puede llegar a ser de vital importancia para proyectos de gran tamaño, pero para los que son más simples pueden no tener tanta importancia a la hora de realizar esta elección. Esto se debe a que los trabajos que ya poseen una estructura y elaboración compleja necesitan una metodología de desarrollo para su efectiva estructuración, planificación y seguimiento en los procesos de desarrollo teniendo en cuenta factores como los costes, la planificación, la calidad y las dificultades asociadas en cada una de las etapas de desarrollo del sistema, permitiendo tener una aplicación libre de errores. Teniendo en cuenta esto, por otro lado se tiene la secuencia de etapas por las que el sistema se está llevando a
7
cabo, y el transitar entre ellas, lo que se conoce como ciclo de vida, definiendo los objetivos en cada etapa y la acción de la siguiente fase. La metodología del proyecto no debe garantizar solo eso, sino el cómo hacerlo, operando con las fases definidas en el ciclo de vida, y el cómo alcanzar esos objetivos, pudiendo seguir uno o más ciclos de vida a lo largo del proyecto a desarrollar.
En este Trabajo de Fin de Máster se tiene un solo desarrollador, lo que supone que no se dispondrá de un equipo de trabajo estándar, y con una duración de 300 horas de trabajo autónomo (12 créditos ECTS con 25 horas/crédito). Esto permite una elección de una metodología que no requiera demasiado tiempo en las etapas de gestión a la hora de administrar el proyecto y poder progresar de forma ágil. También se tiene que debido a la inexperiencia del desarrollador, se podría producir algún retraso, como a la hora de manejar el ámbito del proyecto como el de las metodologías. Esto sumado a que a lo largo del avance del proyecto en la aplicación pueden producirse cambios en los requisitos y adición de funcionalidades a la hora de comunicarse con los clientes, o tutores en este caso, a través de la retroalimentación, se necesitaría una metodología que proporcione una mayor adaptabilidad.
Es por ello que la selección debe encaminarse a una metodología ágil, que posibilite avanzar en el desarrollo soportando y ajustándose a las modificaciones en los requisitos cuando sea preciso, sintetizando los procesos de aplicación.
Considerando las metodologías ágiles que más se adecúan, las que más se adaptan a este tipo de proyectos son Scrum, Programación Extrema (XP) y Kanban [5], ya que son las que mejor se acoplan a las disposiciones del proyecto, pero si se consideran en menor detalle, la elegida sería Scrum. Esto se debe a que en Programación Extrema se centra especialmente en potenciar las relaciones interpersonales como clave del éxito, promoviendo el trabajo en equipo en un buen clima de trabajo, lo que no encaja en gran medida en este proyecto al ser con un solo desarrollador. También se requiere una retroalimentación continua entre el cliente y equipo de desarrollo mediante una colaboración constante, pero en este proyecto no se busca ese tipo de retroalimentación, ya que se requeriría especialmente en las primeras fases del proyecto. En cuanto a la metodología Kanban, tampoco se requiere especialmente de las técnicas que se hacen uso en esta, tales como los cuadros o diagramas en los que se reflejan el avance de las tareas de la aplicación y con unas estimaciones menos precisas. Es por ello, que la metodología a usar en este proyecto es Scrum, la cual permite, como ya se mencionó antes, flexibilidad a la hora de realizar la gestión del desarrollo software.
8
Esta metodología es por definición un procedimiento con un ciclo de vida iterativo e incremental, con entregables incrementales sobre los que permite obtener retroalimentación.
Mediante esta metodología se le proporciona transparencia y visibilidad al proyecto, mayor responsabilidad al equipo, facilidad de acomodar cambios, y un mayor ahorro en costes. A continuación también se mencionan los roles de esta metodología que se van a seguir en el equipo para el desarrollo del proyecto, donde el cliente y el Product Owner será el tecnólogo, que en este caso es el tutor del proyecto, aunque la gestión de la lista de tareas y características (backlog) y las decisiones sobre priorización serán tomadas por el alumno; el Scrum Master será el alumno, con una supervisión del tutor; y el Scrum Team será el alumno en su totalidad.
Se proporciona una gestión en iteraciones que permite realizar en primer lugar una lista de ítems de todas las características deseadas para el producto, y a medida que avanza el proyecto se realizan una serie de sprints o iteraciones donde antes de efectuar cada uno, se presentan los elementos principales en el trabajo pendiente al equipo en una reunión previa, y luego se elige el trabajo a completar durante el sprint. Del mismo modo, al final de cada sprint se asegura que el backlog contiene los elementos necesarios para cumplir los objetivos del proyecto. También pueden realizarse reuniones frecuentes para mantener el equipo actualizado sobre lo realizado en el proyecto. En cuanto al trabajo realizado en cada sprint, el equipo debe presentar el trabajo que se ha completado en una reunión, como a su vez reflexionar sobre qué cambios se pueden realizar en el próximo sprint. Para el correcto seguimiento y gestión de los sprints, se hará uso de la herramienta Trello, la cual permite definir en cada iteración el backlog a través de una selección de requisitos priorizada en función del valor del Retorno de Inversión (ROI).
Por consiguiente, esta metodología ágil Scrum, se escoge porque permite refinar los requisitos que no estén completamente definidos al principio del proyecto, permitiendo incorporar, modificar o eliminarlos, basado en un feedback o retroalimentación del cliente, y a su vez, se permite una integración continua a través de un diseño sencillo. A mayores de los motivos ya comentados, esta metodología también permite, refactorizaciones y replanificaciones, como también un desglose del sistema en otros subsistemas independientes, lo cual será necesario en este proyecto, tal y como se verá en el siguiente capítulo.
En cuanto al cliente, también se tiene que se permita involucrar a los usuarios para refinar los requisitos como también el diseño, de manera que se permitan satisfacer las necesidades del cliente. Respecto a esto, como medida de seguridad, rediseño, e implementación, se le
9
proporcionará al cliente una representación visual y esquemática de la estructura de la aplicación (wireframe) para permitir y tener la certeza de cumplir con sus expectativas y necesidades desde un primer momento, de manera que no haya que volver a rediseñar partes que se creían ya terminadas. Por lo tanto para este Trabajo de Fin de Máster se tiene que mediante esta metodología se promueve la innovación, motivación y compromiso del equipo que forma parte del proyecto, propiciando flexibilidad, productividad y eficiencia al proyecto.
2.3. Gestión de la configuración
En la documentación del PMBOK se define el plan de gestión de la configuración de la siguiente forma:
“Describe la manera en que la información sobre los elementos del proyecto, así como cuáles elementos, serán registrados y actualizados de modo que el producto, servicio o resultado del proyecto se mantenga consistente y/u operativo.”
Se debe asegurar la calidad de todo producto obtenido durante cualquiera de las etapas del desarrollo a través de un estricto control de cambios y la disponibilidad constante de una versión estable de cada elemento del trabajo. Esto también facilita el mantenimiento de los sistemas al proporcionar una imagen detallada del sistema en cada etapa del desarrollo, y evita sobreesfuerzos asegurando la integridad del proyecto facilitando la capacidad del control de cambios. Tal y como se indica en la documentación de la Guía práctica de gestión de configuración del Instituto Nacional de Tecnologías de la Comunicación (INTECO) [6], la configuración del software es el conjunto de características funcionales y físicas del software detalladas en la documentación técnica o alcanzadas en un producto, y la gestión de la configuración es un proceso cuyo propósito es establecer y mantener la integridad de los productos de trabajo a través de los siguientes procedimientos:
▪ La identificación de los elementos y productos que serán controlados y monitorizados, donde se establecen esquemas para la identificación de los elementos y sus versiones, como también las herramientas y técnicas a usar para adquirir y gestionar los elementos controlados.
▪ La definición de un procedimiento para el control de los productos, que cubre el proceso de determinar qué cambios realizar, la autorización necesaria para aprobar
10
ciertos cambios, el soporte a la implementación de esos cambios, y el concepto de desviaciones formales con respecto a los requisitos del proyecto.
▪ El registro o informe de estado de los productos, el cual realiza la actividad de reportar la información necesaria para gestionar de forma efectiva la configuración del software.
▪ Las auditorías de configuración, donde se lleva a cabo la evaluación de la conformidad de los productos y procesos software con respecto a las regulaciones, estándares, guías, planes y procedimientos aplicables.
▪ La distribución del elemento de configuración de software fuera de la actividad de desarrollo, incluyendo liberaciones internas como distribuciones al cliente.
Por lo tanto la gestión de la configuración es un proceso fundamental para el proyecto a desarrollar, ya que posibilita una mejor organización del desarrollo y mantenimiento del producto, facilitando el resto de procesos de producción. Durante el ciclo de vida del proyecto, lo cambios son inevitables, los cuales puede llegar a provocar confusión e incertidumbre si no se han analizado o pronosticado correctamente, por lo que con esta gestión se reduce el riesgo de efectuar una entrega errónea asegurando la integridad del desarrollo.
Si se realiza una gestión de la configuración deficiente puede llevar a un aumento de costes, de tiempo, de procesos y un mal seguimiento del alcance del proyecto, pudiendo llevar a un descontrol de la gestión de versiones en la documentación o en el código al no establecer un correcto control de cambios. En este proyecto al tener un único desarrollador, el trabajo en la gestión de la configuración se sintetiza, tal y como se comentará en los siguientes subapartados.
2.3.1. Gestión de las herramientas
Al tener un único desarrollador en este proyecto, la gestión de la configuración en cuanto al control de versiones para asegurar la integridad y los cambios del trabajo a realizar, se reduce, llegando a tener una gestión efectiva en este aspecto. Para ello se hace eso de ciertas herramientas que ayudarán a realizar una gestión de la configuración correcta y definida de forma eficiente, que serán las siguientes:
▪ Dropbox: servicio de alojamiento de archivos multiplataforma en la nube, que concede el establecimiento y sincronización de archivos en línea y entre ordenadores, y compartir archivos y carpetas con otros usuarios, y con tabletas o móviles.
11
▪ GitHub: plataforma de desarrollo colaborativo para alojar proyectos utilizando el sistema de control de versiones de Git.
▪ LibreOffice Writer: componente de procesador de texto de código abierto del paquete software LibreOffice.
Para el control de versiones de los documentos y archivos relacionados con la memoria del trabajo se utilizará la herramienta Dropbox, ya que dispone de un soporte de sincronización de archivos en la nube a través del propio equipo del desarrollador, permitiendo obtener desde el perfil las versiones anteriores de la propia documentación.
Para el control de los archivos correspondientes al código de la aplicación se hará uso de la herramienta GitHub, la cual posibilitará un control de cambios definido y riguroso de los proyectos de Visual Studio Code e IntelliJ. Esta plataforma proporciona un análisis de cambios suficiente para la aplicación a desarrollar a través de su sistema de repositorios actual.
En cuanto a la elaboración de la memoria del proyecto se hará uso de LibreOffice Writer, el cual necesita tener unos conocimientos básicos para avanzar de manera adecuada en el progreso del proyecto desde el comienzo de este.
2.3.2. Control de versiones
Para la identificación rápida y precisa de las versiones de la memoria del proyecto se hará uso de una terminología determinada, la cual se especifica a continuación:
<apellidos_nombre>_Memoria_TFM_<AAMMDD>_v<número_versión>.<extensión>. El campo apellidos_nombre se refiere al identificador general del documento a través del nombre del desarrollador, el cual permitirá asociar que se refiere a la memoria del Trabajo de Fin de Máster de esa persona. El campo AAMMDD se corresponde con el formato año, mes y día de la fecha de la última modificación o cambio de esa versión. El campo número_versión es el número de la siguiente versión correspondiente a la memoria del proyecto, y el campo extensión es la extensión correspondiente al archivo del documento. Una muestra de este formato podría ser el siguiente: OteroFranjoCarlos_Memoria_TFM_221001_v01.odt.
La denominación del documento mediante este formato se relacionaría con la primera versión de la memoria del Trabajo de Fin de Máster, modificado por última vez el 01 de
12
Octubre de 2022. Se puede observar también como el formato utilizado para la herramienta LibreOffice Writer es odt. Como ya se ha mencionado anteriormente, para los ficheros correspondientes al código de la aplicación, se hará uso de GitHub, por lo que esta nomenclatura no sería necesaria.
2.4. Planificación temporal
A continuación en este apartado se procede a presentar y analizar la planificación temporal del Trabajo de Fin de Máster. En primer lugar, para poder identificar las tareas y actividades de cada fase del proyecto, se hizo uso de la Estructura de Desglose del Trabajo (EDT), la cual es una herramienta fundamental de descomposición jerárquica, orientada al trabajo a ser ejecutado por el desarrollador del proyecto, para cumplir con los objetivos y crear los entregables requeridos, donde cada nivel inferior del diagrama EDT representa una definición con un detalle incrementado del trabajo del proyecto. De este modo se organiza y define el alcance total aprobado del proyecto según la documentación.
En la Figura 1 se muestra el diagrama EDT correspondiente al Trabajo de Fin Máster, con sus niveles y fases subdivididas que representan las tareas del proyecto a realizar. Tal y como se ha mencionado anteriormente, la metodología empleada en este proyecto es Scrum, la cual se define por tener un ciclo de vida con iteraciones en las que se proporcionan al cliente entregas funcionales de la aplicación de forma incremental. En este proyecto se tienen planificadas siete iteraciones, correspondientes a cada uno de los hitos planificados. La primera iteración tiene una duración de dos semanas, la segunda tiene una duración de otras dos semanas, la tercera también tiene una duración de dos semanas, la cuarta tiene una duración de tres semanas, la quinta tiene una duración de dos semanas y media y las dos iteraciones siguientes dos semanas. También se tiene una fase que dura todo el ciclo de vida del proyecto que es la fase de documentación.
13
Ilustración 1: EDT 14
Para un desarrollo más completo de la planificación temporal se mostrará a continuación un cronograma a alto y bajo nivel, a partir de un Gantt, sobre el EDT mostrado anteriormente del proyecto. Este cronograma contiene siete iteraciones, correspondientes a las tareas del diagrama, más la fase de documentación que dura todo el ciclo de vida del proyecto.
Estas iteraciones, fundamentadas sobre la metodología ágil Scrum, son desarrolladas únicamente por el desarrollador del proyecto, teniendo así un solo recurso, y se corresponden con la planificación temporal inicial del proyecto, ya que el desarrollo real sobre cómo ha resultado finalmente la planificación del proyecto se comentará en el Capítulo 5 de Implementación.
15
Ilustración 2: Diagrama de Gantt a alto nivel del proyecto
16
Ilustración 3: Diagrama de Gantt del proyecto
2.4.1. Planificación, definición y análisis de requisitos
Esta primera iteración se basa en la realización del análisis y estudio de todo lo que comprende el proyecto, tanto del ámbito de la nueva plataforma, como también un estudio sobre toda las tecnologías y herramientas empleadas. Para ello, los primeros días serán dedicados al estudio del ámbito y del proyecto. Posteriormente se comenzará con la gestión del proyecto, en especial la gestión y planificación temporal, para así posteriormente poder efectuar de manera correcta una primera versión del análisis de requisitos.
En la especificación del análisis de requisitos, se comprende tanto los requisitos de almacenamiento, requisitos funcionales y no funcionales. Esta identificación de requisitos se realiza de forma posterior a la realización de la gestión del proyecto, en la cual se especificó el contexto y se seleccionó la metodología del proyecto.
Finalmente se realizará un boceto inicial del modelado conceptual para tener un diagrama representativo previo a la implementación de la aplicación. A continuación se muestra esta primera iteración en el diagrama de Gantt:
2.4.2. Diseño, arquitectura y desarrollo de los subsistemas de seguridad y administración
Esta segunda iteración se basa en la actualización de la especificación del análisis de requisitos, y la realización de la fase de diseño del sistema, en la cual a partir de la gestión del proyecto, el análisis de requisitos, y un primer boceto del modelado conceptual, se realiza el diagrama de arquitectura del sistema, el modelo de clases, modelo de datos, una primera versión y aproximación de las interfaces a partir de los wireframes, y los casos de uso correspondientes.
17
Ilustración 4: Diagrama de Gantt de la 1ª iteración
En la fase de implementación se inicia el desarrollo de la aplicación, en la cual se inicializan, configuran y componen los proyectos y se implementan los requisitos funcionales necesarios para el correcto funcionamiento de la aplicación en este apartado relacionado con los subsistemas de seguridad y administración relacionados con el envío de tokens, idiomas, registro e inicio de sesiones de los usuarios, e igualmente, en la fase de pruebas, se realiza el plan de pruebas del proyecto y los casos de prueba para los requisitos implementados en la aplicación. A continuación se muestra esta segunda iteración en el diagrama de Gantt:
2.4.3. Desarrollo del subsistema de perfiles
Esta tercera iteración se basa en el desarrollo del componente de perfiles para la gestión de los perfiles, visitas y suscripciones, en la cual en primer lugar en la fase de análisis se refinan los requisitos y casos de uso necesarios para su desarrollo, y a continuación también se refinan en la fase de diseño tanto el diagrama de arquitectura, el modelo de datos, el diagrama de clases, los wireframes y se comienzan a especificar los diagramas de secuencia necesarios para el correcto desarrollo de esta fase de implementación y desarrollo.
En esta iteración se implementan los requisitos funcionales necesarios para el correcto funcionamiento de la aplicación en este apartado relacionado con el subsistema de perfiles. En la fase de pruebas se refina el plan de pruebas del proyecto en función de lo ya implementado, y se realizan los casos de prueba para los requisitos desarrollados en la aplicación. A continuación se muestra esta tercera iteración en el diagrama de Gantt:
18 Ilustración 5: Diagrama de Gantt de la 2ª iteración
2.4.4. Desarrollo del subsistema de publicaciones
Esta cuarta iteración se basa en el desarrollo e implementación del subsistema de publicaciones para la gestión de temas, publicaciones, etiquetas, valoraciones, comentarios y contenido multimedia. Para ello, como ya se realizó en las anteriores iteraciones, se realiza en primera instancia la fase de análisis donde se refinan los requisitos funcionales y no funcionales, y casos de uso necesarios correspondientes para esta iteración, y a continuación en la fase de diseño también se refinan tanto el diagrama de arquitectura, el modelo de datos, el diagrama de clases, los wireframes y los diagramas de secuencia necesarios para el correcto desarrollo de esta fase.
En la fase de pruebas se refina, en este caso en menor medida, el plan de pruebas del proyecto en función de lo ya implementado, y se realizan los casos de prueba para los requisitos desarrollados en la aplicación. A continuación se muestra esta cuarta iteración en el diagrama de Gantt:
19
Ilustración 6: Diagrama de Gantt de la 3ª iteración
Ilustración 7: Diagrama de Gantt de la 4ª iteración
2.4.5. Desarrollo del subsistema de mensajería
Esta quinta iteración se basa en el desarrollo del subsistema de mensajería para la implementación del chat entre usuarios. Como ya se realizó a lo largo del resto de iteraciones del proyecto, se realiza la fase de análisis donde se refinan los requisitos funcionales, no funcionales, y casos de uso necesarios, y a continuación también se refinan en la fase de diseño tanto el diagrama de arquitectura, el modelo de datos, el diagrama de clases, los wireframes y los diagramas de secuencia correspondientes para el correcto desarrollo de esta fase.
En la fase de pruebas se refina, si es necesario, el plan de pruebas del proyecto en función de lo ya implementado, y se realizan los casos de prueba para los requisitos desarrollados en la aplicación. A continuación se muestra esta quinta iteración en el diagrama de Gantt:
2.4.6. Desarrollo del subsistema de merchandising
Esta sexta y última iteración relacionada con la implementación de la aplicación consiste en el desarrollo del subsistema de merchandising para la gestión de sus productos. Para ello en primer lugar se realiza la fase de análisis correspondiente donde se refinan los requisitos funcionales, no funcionales, y casos de uso necesarios, y a continuación en la fase de diseño también se refinan los diagramas, en caso de ser necesario, para el correcto desarrollo de esta fase.
En la última fase de pruebas se refina, si es necesario, el plan de pruebas del proyecto en función de lo ya implementado, y se realizan los casos de prueba para estos últimos requisitos
20 Ilustración 8: Diagrama de Gantt de la 5ª iteración
desarrollados en la aplicación. A continuación se muestra esta sexta iteración en el diagrama de Gantt:
2.4.7. Documentación
Esta fase de documentación se realiza desde el comienzo de la primera iteración, cuando se comienza con la gestión del proyecto, y finaliza hasta cuando se cierre el Trabajo de Fin de Máster. Es una fase que dura todo el ciclo de vida del proyecto en la cual se recogen en la memoria toda la documentación necesaria desde la fases tempranas del proyecto hasta las últimas, de tal manera que se puedan entender todos los detalles de la aplicación y como se fue desarrollando, como también se comenta el código de la aplicación a medida que se va implementando. A continuación se muestra la fase de documentación en el diagrama de Gantt:
2.4.8. Finalización
En esta séptima y última iteración del proyecto, se finaliza y cierra el proyecto para así finalmente poder entregarlo. En esta etapa se finaliza y repasa la aplicación y la memoria que se estuvo realizando a lo largo del ciclo de vida del proyecto:
21
Ilustración 9: Diagrama de Gantt de la 6ª iteración
Ilustración 10: Diagrama de Gantt de la etapa de documentación
2.5. Gestión de las comunicaciones
En esta sección de la gestión de comunicaciones se especifican las diferentes formas de comunicación que se van a seguir a lo largo del ciclo de vida del proyecto a la hora de transmitir y recibir información entre el desarrollador y los interesados de la aplicación del proyecto de este Trabajo de Fin de Máster. A su vez, igualmente se especificará la información relativa a cada uno de los interesados del proyecto, como también de las comunicaciones efectuadas con estos.
2.5.1. Gestión e identificación de los interesados
Una de las etapas para poder establecer una buena gestión de las comunicaciones, es la gestión de los interesados. Los interesados de un proyecto son aquellos individuos, grupos u organizaciones que pueden afectar, verse afectados o percibirse a sí mismos como afectados por una decisión, actividad o resultado del propio proyecto. En la documentación del PMBOK se define la gestión de los interesados de un proyecto como:
“Los procesos requeridos para identificar a las personas, grupos u organizaciones que pueden afectar o ser afectados por el proyecto, para analizar las expectativas de los interesados y su impacto en el proyecto, y para desarrollar estrategias de gestión adecuadas a fin de lograr la participación eficaz de los interesados en las decisiones y en la ejecución del proyecto.”
Uno de los procesos más importantes de esta gestión es la identificación de los interesados, que fundamentalmente es la identificación periódica de los interesados del proyecto así como el analizar y documentar información relevante relativa a sus intereses, participación, interdependencias, influencia y posible impacto en el éxito del proyecto. Es de vital
22 Ilustración 11: Diagrama de Gantt de la 7ª iteración
importancia realizar este proceso de manera apropiada para la correcta gestión de las comunicaciones para el desarrollo del proyecto. En este Trabajo de Fin de Máster el número de interesados es limitado, donde se encuentra el desarrollador del proyecto, el tutor y el profesor responsable de la asignatura.
2.5.2. Planificación de las comunicaciones
Para el desarrollo correcto de cualquier proyecto es necesario que la transmisión de la información sea en el momento adecuado, con información precisa y a la persona correcta. En esta etapa se recoge y garantiza que los interesados del proyecto identificados en la sección anterior dispongan de la información requerida cuando sea necesario, y con los métodos de comunicación empleados. Los métodos de comunicación que se utilizarán son los siguientes:
▪ Comunicación interactiva: entre dos o más interesados que realizan un intercambio de información de tipo multidireccional en tiempo real. Emplea objetos de comunicación tales como reuniones o tutorías, llamadas telefónicas, mensajería instantánea, la cual será la más utilizada tal y como se comentará a continuación y algunas formas de medios sociales y videoconferencias.
▪ Comunicación de tipo push (empujar): enviada o distribuida directamente a receptores concretos que necesitan recibir la información determinada. Esto asegura la distribución de la información, pero no garantiza que efectivamente haya llegado ni sea comprendida por la audiencia prevista. Los objetos de comunicación de tipo push incluyen cartas, memorandos, informes, correos electrónicos, faxes, correos de voz, blogs y comunicados de prensa.
La comunicación interactiva se hará uso a la hora de efectuar el envío de mensajes con el tutor a través del campus virtual de la UOC, mientras que las de tipo push se hará uso cuando se envíen correos electrónicos con pequeñas dudas o en las que sea necesario ocultar contenido del proyecto al resto de los compañeros del aula. Se debe asegurar el correcto envío y recibo de la información pidiendo siempre un correo de respuesta confirmando la llegada del mismo. De no recibir la confirmación debe reenviarse el correo, o asegurarse por otro medio, como llamada telefónica, para la correcta recepción del correo electrónico.
Como ya se ha indicado en la comunicación interactiva, el método de comunicación más utilizado será el del envío de mensajes que se llevarán a cabo a través del campus virtual, y se
23
realizarán de manera periódica y continua desde el comienzo del proyecto, de forma que la mayoría de los conceptos queden fijados al inicio, y que las etapas de análisis y diseño queden definidas de manera clara y correcta para el avance adecuado del proyecto.
2.6. Gestión de costes
Para este apartado se indicará en primer lugar los medios materiales necesarios para la realización del proyecto, para posteriormente realizar el análisis del presupuesto del proyecto.
2.6.1. Medios materiales necesarios
▪ Ordenador portátil estándar (HP Pavilion x360 Convertible): necesario para el desarrollo de la aplicación y la documentación correspondiente.
▪ Acceso a Internet: necesario para la búsqueda de información necesaria para el desarrollo del proyecto y las copias de seguridad en la nube.
▪ Procesador de texto LibreOffice Writer: necesario para la documentación del proyecto.
▪ Entorno de desarrollo integrado Visual Studio Code: necesario para el desarrollo de la aplicación en la parte del front-end con Angular.
▪ Entorno de desarrollo integrado IntelliJ IDEA Ultimate: necesario para el desarrollo de la aplicación en la parte del back-end con Spring Boot.
▪ Entorno de gestión de bases de datos Studio 3T: necesario para la gestión de la base de datos implementada con MongoDB.
▪ Sistema de gestión de bases de datos MongoDB: necesario para el desarrollo de la aplicación.
▪ Herramienta de creación y uso de APIs Postman: necesaria para la realización de requests de prueba contra el servidor back-end para su testeo.
▪ Herramienta de modelado de software StarUML: necesaria para la elaboración de los diagramas.
▪ Herramienta de elaboración de diagramas Flowmapp: necesaria para la elaboración del diagrama sitemap.
▪ Herramienta de elaboración de diagramas Draw.io: necesaria para la elaboración de la Estructura de Desglose del Trabajo (EDT).
▪ Herramienta de elaboración de prototipos Balsamiq: necesaria para la elaboración de los prototipos de la interfaz de la aplicación.
24
▪ Herramienta de administración y gestión de proyectos ProjectLibre: necesaria para la elaboración del Gantt del proyecto.
▪ Herramienta de administración y gestión de proyectos Trello: necesaria para realizar una correcta gestión y seguimiento del proyecto.
2.6.2. Presupuesto del proyecto
Como ya se comentó en los anteriores apartados, muchos de los proyectos que acaban fracasando es debido a una mala gestión de los costes, provocado por sobrecostes inesperados a lo largo del proyecto que impiden avanzar y seguir desarrollándolo con normalidad. En este apartado se realizará el análisis y gestión de los costes para poder planificar y gestionar el presupuesto del proyecto y desarrollar la aplicación de manera correcta. Para la correcta gestión, se trabajará a lo largo del ciclo de vida del proyecto con los siguientes tipos de costes especificados en el PMBOK:
▪ Costes directos: son los que guardan una relación estrecha con el producto o servicio.
De hecho, se establecen desde las primeras fases de producción y suelen reflejarse en los presupuestos o estimaciones de costes. Un ejemplo son las materias primas, es decir, los materiales que han servido de base para la elaboración de los productos o el desarrollo de los proyectos. También los relacionados con la mano de obra directa, por ejemplo, el pago que reciben las personas que trabajan en el proyecto, que generalmente se expresa en horas.
▪ Costes indirectos: por el contrario, estos costes son los que se relacionan de manera tangencial con los proyectos o las tareas previstas, como por ejemplo el consumo de electricidad en sus operaciones, de manera que aunque no tenga una influencia directa en el producto final como tal, es un recurso indispensable para el proyecto.
En esta fase de análisis y gestión de costes, pese a que este proyecto solo se esté desarrollando por un solo trabajador, es esencial para el correcto avance del proyecto. Uno de los motivos ya comentados, es el del fracaso de los proyectos debido a una mala estimación.
Unos resultados que pueden demostrar esto, son los datos especificados por The Standish Group, mediante el denominado The Chaos Report de 2015 [7], donde se indica que el 19% de los proyectos resultaron fallidos, mientras que en resultados de años anteriores a 2013 se ha llegado a tener que, hasta un 54% de los proyectos completados sufren sobrecostes.
25
A continuación se procede con la estimación de los costes de este Trabajo de Fin de Máster que implicaría llevar a la práctica este proyecto en un entorno no instructivo, teniendo en cuenta los costes directos e indirectos mencionados anteriormente. En los costes directos, se incluye el salario del desarrollador, teniendo en cuenta que el tutor ocupa un rol de potencial cliente. En relación con el cálculo del salario, se toman los resultados obtenidos de la guía salarial del sector de las Tecnologías de la Información (TI) de Galicia en el curso 2015-2016 [8] elaborado por la consultora Vitae Consultores, en el que un Analista Programador con experiencia de dos a cuatro años tiene un salario de 23.000 € brutos al año de media, y 26.000
€ brutos al año de máximo, por lo que se tomará para este proyecto el valor de 24.500 € brutos al año, y que según la guía salarial Hays de 2018 sobre la evolución de los salarios, este salario medio irá en aumento cada año. El coste de la seguridad social de un trabajador a cargo de la empresa es de un 30,9%, por lo que se atribuye en este proyecto un 31% sobre el salario bruto, lo que conllevaría a los gastos mostrados en la siguiente tabla, teniendo en cuenta que se tienen 12 pagas a través de 20 días laborables al mes con 8 horas diarias:
Salario bruto anual Seguridad social Coste/mes Coste/hora
24.500 € 7.595 € 2.674,58 € 16,72 €
Tabla 1: Coste del trabajador
En relación a los costes directos, también se incorpora el precio de la impresión de una copia de la memoria del Trabajo de Fin de Máster. Si se estiman para este proyecto 90 páginas, y se considera un precio aproximado de 0.15 € cada página a color, se tiene de coste 13.5 € para la correspondiente impresión.
Respecto a los costes indirectos, se considera en primer lugar el equipo de trabajo, que en este caso es un ordenador portátil HP Pavilion x360 Convertible. De este modo, el coste del equipo se estima como el precio del ordenador, 720 €, con una vida media aproximada de 4 años. Para el cálculo del coste del equipo en el ciclo de vida del proyecto se tiene la siguiente tabla:
Dispositivo Vida media Tiempo de uso Coste total Coste en el proyecto
Ordenador portátil 48 meses 5 meses 720 € 75 €
Tabla 2: Coste del equipo
26
El resto de costes indirectos relativos al acceso a Internet, la luz o la corriente eléctrica, se estimarán con un peso del 5% del coste final, como es habitual a la hora de desarrollar proyectos de un tamaño considerable. Por otro lado, el software empleado en este proyecto es software de pago, como también software libre o con licencia de pruebas, de manera que también implica mayores costes en relación a los ya comentados anteriormente. En la siguiente tabla se muestra el análisis del coste final del proyecto:
Componente Coste total
Desarrollador Java 5.016 €
Equipo de trabajo 75 €
Visual Studio Code 0 €
IntelliJ IDEA Ultimate 181,43 €
MongoDB 0 €
Postman 0 €
LibreOffice 6.0.4.2 0 €
StarUML 0 €
Draw.io 0 €
Balsamiq 0 €
ProjectLibre 0 €
Trello 0 €
Impresión memoria 13,5 €
Resto de costes indirectos 5% sobre el coste total
COSTE TOTAL 5.550,23 €
Tabla 3: Coste total del proyecto
27
Capítulo 3
Análisis de requisitos
El análisis de requisitos es una de las tareas más importantes en el ciclo de vida del desarrollo software, puesto que en ella se determinan los requerimientos de la aplicación. Es una tarea que cubre el vacío entre la definición del software del sistema y el diseño del mismo.
Tanto el desarrollador como el cliente tienen un papel activo, pues juntos definen en detalle los requisitos del sistema a desarrollar y los pasos a seguir. Este análisis y especificación de requisitos es un estudio profundo de las necesidades del proyecto, y especifica las características operacionales que tendrá el software a desarrollar. Se puede realizar a través de entrevistas, observación, o demás técnicas específicas. Esta etapa define el plan de proyecto a seguir y es fundamental para cumplir la planificación temporal establecida, así como el presupuesto acordado y los objetivos fijados.
En este proyecto, el análisis y especificación de requisitos se realiza a partir de la información extraída en las etapas de análisis de cada una de las iteraciones y en el estudio y el ámbito de la aplicación del proyecto. A mayores también se obtuvo información de aplicaciones existentes con objetivos relacionados con este proyecto, lo que denominaremos en este documento como la competencia.
Otra cuestión para este apartado es que, para la especificación de requisitos se seguirá el estándar ISO/IEC/IEEE 29148:2018 [9]. La especificación de requisitos es una descripción completa del comportamiento de la aplicación software que se va a desarrollar, que contiene las necesidades de negocio de los clientes, como la propuesta de solución de la ingeniería de requisitos. Por lo que para realizarla en este caso, se presentará la información que viene especificada y recomendada por el estándar ISO/IEC/IEEE 29148:2018. De esta forma se seguirá la estructura y la organización de las funcionalidades para una buena especificación de requisitos a partir del planteamiento que presente. Este estándar está enfocado en recomendaciones prácticas para la especificación de requerimientos, y tiene como objetivos ayudar a describir con precisión lo que se requiere en el software, y a las personas encargadas de recibir esta información, establecer una estructura estándar para la 28
especificación de los requisitos en los proyectos. A continuación, antes de realizar el análisis y especificación de requisitos de información, funcionales y no funcionales (Anexo 1), se expone el contexto de ingeniería de la aplicación a partir de la información extraída de las partes interesadas, y posteriormente una descripción técnica de la competencia.
3.1. Contexto de ingeniería
Este apartado tiene como objetivo describir cómo funcionan las partes interesadas, incluyendo información obtenida del análisis inicial como con las consultas realizadas con el tutor. Por lo que se pretende resumir lo que se haya podido extraer del análisis, como a su vez una descripción de los intereses de los potenciales clientes.
Para que las plataformas sociales sean más eficaces se debe disponer de medios tecnológicos adecuados para gestionar contenido dinámico, fácilmente usable para los distintos usuarios. De esta manera se agiliza y se proporciona una optimización a la hora de trabajar con este tipo de contenido y, por supuesto, cumpliendo en todo momento con los objetivos de crear y consumir los diversos recursos del sistema a los usuarios finales, independientemente de su perfil. Este producto ejecutará un entorno, resolviendo esta necesidad, en el que los usuarios podrán compartir y debatir entre ellos sobre diversos temas, permitiendo crear y consumir contenido social variado, como también centrado y clasificado a partir los gustos de cada uno de los usuarios del marco adecuado. Como ya se mencionó anteriormente en diversos apartados, enfocándose en el contexto de operatividad y requisitos del sistema, se resolverá esta necesidad al iniciar el proyecto, permitiendo la gestión de usuarios a través de sus perfiles, roles y permisos en función de estos. Se implementará una gestión de temas y publicaciones, etiquetas representativas, ejecutar suscripciones, posibilidad de realizar y plantear comentarios, valoraciones y visitas a los perfiles, introducir contenido multimedia, mensajería entre usuarios a través de chats individualizados, y finalmente una sección de merchandising por medio de sus productos.
Es por ello que este producto podrá ser de interés y de utilidad para los usuarios en este proyecto a desarrollar en este Trabajo de Fin de Máster, en el que se propone disponer de medios tecnológicos para adecuar contenido dinámico, fácilmente usable para los distintos usuarios, pudiendo incorporar recursos a consumir de manera flexible y dinámica. Por lo que de esta manera se agiliza y se proporciona una optimización a la hora de trabajar con este tipo de contenido, y cumpliendo en todo momento con los objetivos de favorecer
29
