Desarrollo de entorno de programación online dentro de app Angular

Universitat Politècnica de Catalunya (UPC) – BarcelonaTech Facultat d’Informàtica de Barcelona (FIB) Centre Internacional de Metodes Numerics en Enginyeria (CIMNE) Departament de GiD DESARROLLO DE ENTORNO DE PROGRAMACIÓN ONLINE DENTRO DE APP ANGULAR Trabajo Fin de Grado Grado en Ingeniería Informática - Computación Laura Santos López Director: Adrià Melendo Ribera Ponente: Mercè Mora Giné 15 de enero del 2022 Resumen El proyecto está dirigido a desarrollar un conjunto de funcionalidades complementarias en la aplicación web que la empresa CIMNE está implementando. Esta aplicación se utilizará para ejecutar simulaciones online con interfaz completamente personalizable tanto en aspecto como en funcionalidad. Una de las funcionalidades complementarias consiste en crear un sistema que permita programar de manera online, generando funciones y componentes HTML5 personalizados que las activarían. A este sistema se le han añadido ayudas adicionales para facilitar la programación al usuario. Algunas de estas herramientas consisten en métodos para poder gestionar los ficheros, poder ver las versiones anteriores y ayudas de autocompletado. La otra funcionalidad permitirá ejecutar todo aquello que se ha programado y ver que funciona como el usuario espera antes de guardarlo e incorporarlo definitivamente a la aplicación. Dado que este proyecto ampliaría una aplicación web, el lenguaje de programación que se utilizará es JavaScript en el framework de Angular con algunos módulos adicionales. Abstract This project is focused on developing a set of new complementary functionalities in the web application that CIMNE is implementing. This application will be used to run online simulations with a fully customizable UI(User Interface) in both looks and functionality. One of the featured additions consists of creating a system that allows users to program their custom functions online and the HTML5 components that would apply them. Into this system, additional tools have been added to make development easier for users. Some of these features consist of methods that allow file management, version control or autocompletion. Another functionality allows the execution of everything that has been developed. This way, users can check if everything works accordingly before saving or incorporating the files into the final project. Given that this project is an extension of a web application, the programming language that is used during development is Javascript using an Angular Framework with some additional modules. pág. 4 Índice 1. Contextualización del proyecto .................................................................... 12 1.1. Introducción ........................................................................................ 12 1.2. Definición de conceptos ........................................................................ 13 1.3. Actores implicados ............................................................................... 15 2. Alcance del proyecto .................................................................................. 17 2.1. Identificación del problema ................................................................... 17 2.2. Justificación ......................................................................................... 18 2.3. Definir los objetivos ............................................................................. 20 2.4. Posibles riesgos y obstáculos ................................................................ 22 3. Metodología y rigor .................................................................................... 24 3.1. Herramientas ....................................................................................... 25 3.2. Validación ........................................................................................... 26 4. Planificación inicial ..................................................................................... 27 4.1. Descripción de las tareas ...................................................................... 27 D – Documentación ................................................................................. 28 D1 – Entregas de GEP .......................................................................... 28 D2 – Escribir memoria .......................................................................... 28 D3 – Preparar presentación .................................................................. 28 S – Reuniones de seguimiento ................................................................. 29 S1 – Reunión inicial .............................................................................. 29 S2 – Reuniones seguimiento semanales ................................................. 29 S3 – Reunión hito intermedio ................................................................ 29 S4 – Reunión final ................................................................................ 29 CP – Preparación previa ........................................................................... 29 CP1 – Definir alcance ........................................................................... 30 CP2 – Planificación temporal ................................................................. 30 CP3 – Presupuesto y análisis de sostenibilidad ....................................... 30 pág. 5 CP4 – Aprendizaje Angular y TypeScript ................................................ 30 CP5 – Preparar el entorno .................................................................... 30 CD – Diseño ........................................................................................... 31 CD1 – Diseño del editor ........................................................................ 31 CD2 – Diseño del gestor de versiones .................................................... 31 CD3 – Diseño del modo Debug ............................................................. 31 CD4 – Diseño de la interfaz Gráfica ....................................................... 31 CI – Implementación ............................................................................... 31 CI1 – Crear el editor ............................................................................ 31 CI2 – Crear línea temporales ................................................................ 32 CI3 – Implementación interacciones con GitLab Api ................................ 32 CI4 – Implementar el modo Debug ....................................................... 32 CT – Pruebas .......................................................................................... 32 CT1 – Pruebas unitarias ....................................................................... 32 CT2 – Pruebas de principio a fin ............................................................ 33 CT3 – Pruebas de usabilidad ................................................................. 33 4.2. Recursos ............................................................................................. 33 4.2.1 Recursos humanos .......................................................................... 33 4.2.2 Recursos materiales ........................................................................ 34 4.3. Gestión del riesgo ................................................................................ 37 5. Presupuesto .............................................................................................. 39 5.1. Identificación y estimación de costes ..................................................... 39 Costes de personal .................................................................................. 39 Costes genéricos ..................................................................................... 41 Hardware ............................................................................................ 42 Software ............................................................................................. 42 Otros .................................................................................................. 43 Contingencia ........................................................................................... 44 Imprevistos ............................................................................................ 44 Coste total del proyecto ........................................................................... 45 pág. 6 5.2. Control de gestión ................................................................................ 46 6. Aplicación GiD de escritorio ......................................................................... 48 7. Solución propuesta ..................................................................................... 52 7.1. Posibles alternativas del editor .............................................................. 52 RunKit .................................................................................................... 53 AceEditor ................................................................................................ 54 MonacoEditor .......................................................................................... 55 7.2. Posibles alternativas del control de versiones ......................................... 56 7.3. Posibles alternativas del apartado de ejecución ...................................... 58 7.4. Solución escogida ................................................................................ 61 8. Desarrollo .................................................................................................. 63 8.1. Preparación previa ............................................................................... 63 8.2. Diseño de la interfaz gráfica ................................................................. 64 8.3. Creación del editor ............................................................................... 68 8.3.1 Actualizar código entre editores ....................................................... 69 8.3.2 Área editable .................................................................................. 70 8.3.3 Cambiar el nombre de la función ..................................................... 70 8.3.4 Autocompletado ............................................................................. 71 8.3.5 Validar sintaxis del código ............................................................... 72 8.4. Creación de la línea temporal ................................................................ 73 8.5. Implementación de interacciones con GitLab API .................................... 75 8.5. Implementar interacciones con GitLab API 8.5.1 Botón New ..................................................................................... 77 8.5. Implementar interacciones con GitLab API 8.5.2 Botón Open .................................................................................... 78 8.5. Implementar interacciones con GitLab API 8.5.3 Botón Save ..................................................................................... 78 8.5. Implementar interacciones con GitLab API 8.5.4 Botón SaveAs ................................................................................. 79 8.5. Implementar interacciones con GitLab API pág. 7 8.5.5 Botón Close .................................................................................... 79 8.5. Implementar interacciones con GitLab API 8.5.6 Botón Delete .................................................................................. 80 8.5. Implementar interacciones con GitLab API 8.5.7 Petición del código de un commit ..................................................... 80 8.6. Creación del apartado de ejecución ....................................................... 80 8.7. Implementar tests ................................................................................ 83 9. Estado final y desviaciones ......................................................................... 87 9.1. Cumplimiento de los objetivos .............................................................. 87 9.1.1 Resumen de los requisitos del proyecto ............................................ 87 9.1.2 Evaluación del cumplimiento de los requisitos ................................... 88 9.2. Desviaciones del proyecto .................................................................... 91 9.2.1 Desviaciones en la planificación ....................................................... 91 9.2.2 Desviaciones del presupuesto .......................................................... 96 Costes de personal ............................................................................... 96 Costes genéricos .................................................................................. 96 Contingencia ....................................................................................... 99 Imprevistos ......................................................................................... 99 Coste total ......................................................................................... 100 10. Informe de sostenibilidad ........................................................................ 101 10.1. Dimensión ambiental ........................................................................ 101 10.2. Dimensión económica ....................................................................... 103 10.3. Dimensión social .............................................................................. 104 10.4. Conclusión sobre la sostenibilidad ..................................................... 106 11. Conclusiones .......................................................................................... 108 11.1. Conclusiones del proyecto ................................................................. 108 11.2. Valoración personal .......................................................................... 109 11.3. Integración de conocimientos ........................................................... 112 11.4. Identificación de leyes y regulaciones ................................................ 114 11.5. Competencias técnicas ..................................................................... 116 pág. 8 11.6. Acciones futuras .............................................................................. 120 12. Bibliografía ............................................................................................ 122 13. Anexo A ................................................................................................ 128 Diagrama de Gantt inicial .......................................................................... 128 Diagrama de Gantt final ............................................................................ 131 14. Anexo B Manual ..................................................................................... 134 Vista rápida .............................................................................................. 134 Crear un fichero ....................................................................................... 137 Abrir un fichero ........................................................................................ 139 Guardar cambios ...................................................................................... 139 Guardar Como .......................................................................................... 141 Cerrar fichero ........................................................................................... 142 Borrar fichero ........................................................................................... 143 Ejecutar Código ........................................................................................ 143 Comparación de versiones ......................................................................... 146 Índice de Tablas Tabla 1 : Tabla resumen de tareas con la duración y recursos de cada una. Elaboración propia .......................................................................................... 36 Tabla 2 : Retribución de cada Rol. Elaboración propia ........................................ 39 Tabla 3 : Tabla de costes por tarea. Elaboración propia ..................................... 41 Tabla 4 : Costes de los recursos de Hardware. Elaboración propia ...................... 42 Tabla 5 : Costes de los recursos de Software. Elaboración propia ....................... 43 Tabla 6 : Costes de energía previstos del proyecto. Elaboración propia ............... 43 Tabla 7 : Costes de contingencia. Elaboración propia ......................................... 44 Tabla 8 : Coste de los imprevistos. Elaboración propia ....................................... 45 Tabla 9 : Presupuesto final del proyecto. Elaboración propia .............................. 46 Tabla 10 : Costes de energía actualizados. Elaboración propia ........................... 98 pág. 9 Tabla 11 : Coste final del proyecto. Elaboración propia .................................... 100 Índice de Figuras Figura 1 : Representa un código en el que se están buscando errores. La imagen se ha extraído de [7] ........................................................................................... 14 Figura 2 : Representa el tablero de kanban del 27 de septiembre del 2021. Elaboración propia. ......................................................................................... 24 Figura 3 : Diagrama de dependencias de final-inicio. Elaboración propia ............. 37 Figura 4 : Aplicación GiD, parte de preporcesado. Elaboración propia ................. 49 Figura 5 : Aplicación GiD, parte de postporcesado. Elaboración propia ................ 50 Figura 6 : Ayuda visual para entender que ficheros contiene un ProblemType. Esta imagen se ha extraído de la página 3 de [44] ................................................... 51 Figura 7 : Un ejemplo del RunKit editor [16] ..................................................... 53 Figura 8 : Un ejemplo del AceEditor [17] .......................................................... 54 Figura 9 : Un ejemplo del MonacoEditor [18] .................................................... 55 Figura 10 : Un ejemplo del editor de difrencias del MonacoEditor [18] ................ 56 Figura 11 : Clase de tipo botón y los parámetros necesarios. Elaboración propia . 59 Figura 12 : Objeto JSON. Elaboración propia ..................................................... 60 Figura 13 : Elemento HTML con la información del JSON. Elaboración propia ...... 60 Figura 14 : Representación del elemento HTML en la página web. Elaboración propia ..................................................................................................................... 60 Figura 15 : Diagrama de flujo que representa la transformación de los datos desde el worker a la página web. Elaboración propia .................................................. 61 Figura 16 : Organización de la aplicación. Elaboración propia ............................. 65 Figura 17 : Diseño de la interfaz en la pestaña Editor. Elaboración propia ........... 65 Figura 18 : Diseño de la interfaz en la pestaña Editor&Play. Elaboración propia ... 66 Figura 19 : Diseño de la interfaz en la pestaña Editor&Versions. Elaboración propia ..................................................................................................................... 67 pág. 16 segundo tipo de usuarios, siendo capaz de unir su solver con la parte gráfica de la nueva aplicación. Si esta nueva web es un éxito, los primeros beneficiados serán el departamento de GiD y a su vez la empresa de CIMNE, dado que se comprarán más licencias. Pero estos no serian los únicos beneficiados, ya que si los usuarios pagan por un servicio que necesitan, en cierta manera también están sacando provecho de todas las opciones que la aplicación les proporciona. pág. 17 2. Alcance del proyecto El alcance es el conjunto de requisitos que se tienen que cumplir en el proyecto para que se considere terminado. Esto lo convierte en un aspecto muy importante que hay que tener bien definido para poder cumplir todos los plazos y que no se alargue en exceso por profundizar demasiado en algunos aspectos y quedarse corto en otros. 2.1. Identificación del problema Dentro del ámbito de la Ciencia y de la Ingeniería es necesario hacer simulaciones numéricas. La aplicación de escritorio de GiD intenta cubrir todas las necesidades comunes de estas simulaciones desde el punto de vista de pre y post procesado. Algunas de estas necesidades son el modelado geométrico, la definición efectiva de datos de análisis, mallados, transferencia de datos a softwares de análisis y la visualización y análisis de estos resultados numéricos. GiD ofrece muchas opciones de trabajo, entre otras permite crear entornos dentro de la aplicación con funcionalidades propias y cálculos específicos para el trabajo que se está realizando. Esto es conocido como ProblemType. La empresa ha decidido migrar esta aplicación a un entorno web para facilitar a los usuarios conectarse desde donde lo deseen sin tener que preocuparse del espacio físico en el que tienen guardado el trabajo. Al dar este paso surge el problema o necesidad de pensar una fórmula en la que se puedan crear los ProblemTypes de manera fácil, cómoda y eficiente. En la aplicación actual de escritorio, el usuario crea un directorio especifico donde introduce todos los ficheros que ha programado anteriormente en su ordenador y que la aplicación GiD necesita para personalizar el espacio de trabajo. Esta dinámica se intenta agilizar y facilitar con la nueva aplicación. El trabajo pretende resolver esta necesidad dedicando un espacio dentro de la nueva aplicación web, para crear un editor. Una posibilidad para este nuevo apartado es que tenga dos funcionalidades principales, una sería la edición y la otra la ejecución. pág. 18 La parte de edición quiere conseguir un entorno cómodo, con ayudas y con un prototipo inicial de gestión de versiones, donde el usuario pueda crear las funciones de sus ProblemTypes. Además, se quiere incorporar una segunda funcionalidad complementaria a la primera, permitiendo que el usuario pueda ejecutar parte del trabajo que está haciendo para comprobar si funciona correctamente. 2.2. Justificación Anteriormente, se ha explicado el problema a resolver, como se gestiona actualmente y cómo se afrontará, pero lo que no se ha explicado son los motivos que han llevado a esa solución. Para poder entenderlo hay que situarse en el área de las simulaciones numéricas y en el mercado actual. En internet se pueden encontrar algunos programas de escritorio que proporcionan al usuario una interfaz interactiva para el pre-procesado y/o post-procesado de modelos. La mayoría de estas aplicaciones vienen con su propio solver o motor de procesado, estos suelen estar centrados en los ámbitos de la ciencia que estudian, con funciones específicas para calcular y analizar datos. También se puede encontrar la situación inversa, empresas o paginas web que proporcionan los solvers, pero sin incluir la parte gráfica del pre-procesado y/o post-procesado. Algunos de los competidores de GiD son los programas de Tecplot [10] y ParaView [11] que solo proporcionan el post-procesado. Otros programas más parecidos a GiD son Femap [12] y FEMGV [13], ambos proporcionan pre y postprocesado de modelos de análisis. Femap permite combinarlo con sistemas CAD (Diseño Asistido por Ordenador), hacer simulaciones y combinar solvers ya existentes. Lo que diferencia a la aplicación de GiD de los programas anteriores, es que ofrece a sus usuarios un entorno gráfico con un solver y la posibilidad de crear tu propio solver e integrarlo con la interfaz de GiD para visualizar los datos y soluciones de pág. 19 las simulaciones. Además, proporciona plena libertad a la hora de decidir el tipo de entrada y salida de los datos, el programa se adapta totalmente a las necesidades de formato de los datos del usuario. También se ha evaluado el mercado al que se quiere acceder con la aplicación web, en este caso no se han encontrado tantas aplicaciones, solo se mencionará OnShape [14]. Proporciona un entorno CAD avanzado, pero la parte de simulaciones se tiene que añadir con un módulo. La aplicación web tiene una tienda en la que se pueden comprar y descargar solvers para complementar la aplicación, Simscale [15] sería el más parecido a GiD. Al ejecutar la simulación se abre una pestaña aparte, esto hace que la simulación no se vea muy integrada en la aplicación. Esto con la nueva aplicación web GiD no pasará, todo se verá muy unificado y el conjunto parecerá una aplicación personalizada. Alguna de las preguntas claves que se tienen que responder antes de empezar el proyecto son las siguientes. ¿Está el problema ya resuelto?, ¿Se puede utilizar o adaptar una solución existente o hay que diseñar una solución nueva? Para resolver estas preguntas se dedicó tiempo a investigar las soluciones existentes y programas parecidos para ver como afrontaban el problema. Se ha llegado a la conclusión de que el departamento de GiD quiere una solución muy especifica para complementar su programa. Se ha dividido el alcance del proyecto en requisitos más comunes que pueden ser solicitados por cualquier empresa o usuario. De esta manera se han encontrado diferentes soluciones ya existentes para cumplir con los requisitos propuestos que denominaremos módulos. Uno de los módulos es el editor. Después de unos días de búsqueda se encontraron tres opciones que se podían adaptar a nuestras necesidades. Estos editores son “Runkit” [16], “ACE” [17] y “Monaco” [18]. El primero está muy centrado en la ejecución y es complicado adaptarlo a nuestras necesidades. Con el segundo no ocurre lo mismo, es fácil de adaptar, pero no es compatible con un editor que pág. 20 resalta las diferencias de código en distintas versiones, por tanto se ha decidido utilizar “Monaco Editor”. El siguiente módulo a comentar es el que corresponde al gestor de versiones. Una de las opciones es crear una API propia que gestione los datos de los ficheros con sus versiones, pero este proceso consume demasiado tiempo y se ha decidido buscar una ya existente, como las que proporcionan GitHub [19] o GitLab [20]. En un futuro es posible que se cree una API propia para CIMNE, pero de momento se ha decidido utilizar la API de GitLab [21], ya que la propia empresa lo tiene instalado y ejecutándose en uno de sus servidores. La última decisión que se ha tomado hace referencia a la parte de ejecución y visualización. Se comprobará que el código introducido por el usuario no tiene errores y, en caso de que los tuviera, la propia aplicación los destacará para que sean corregidos. La parte de visualización se ha hecho con la misma dinámica que se utiliza en los “WorkingModes”. Esta dinámica consiste en utilizar unas clases que crean diferentes Objetos JSON que se transformarán a componentes de Angular para su visualización. 2.3. Definir los objetivos Al ser un trabajo realizado en colaboración con la empresa CIMNE en consorcio con la UPC, el objetivo final a conseguir está muy definido desde el principio. Consiste en que los usuarios que utilizarán la nueva aplicación web de GiD, que está en desarrollo, consigan crear funcionalidades en sus ProblemTypes. Como el proyecto es de gran envergadura, se empezará definiendo los requisitos básicos que se identificarán con objetivos secundarios. pág. 21 Uno de los objetivos secundarios más destacados, será conseguir un editor funcional, tarea que también puede resultar compleja ya que un editor implica muchas funcionalidades a desarrollar, por lo que también pondremos ciertos limites. La versión principal del proyecto debe contar con una parte donde escribir código, ha de tener la capacidad de deshacer y de rehacer, debe facilitar las ayudas de autocompletado y también ha de contar con botones con las opciones de abrir, guardar y eliminar ficheros. Otro objetivo secundario es tener un entorno en el que el usuario sea capaz de gestionar las diferentes versiones. Con este objetivo pasa lo mismo que en el anterior, al hablar de un gestor de versiones, directamente se piensa en Git y cómo trabajar simultáneamente en un mismo proyecto. La idea de futuro es conseguir que GiD web permita trabajar a varios usuarios en un mismo fichero de ProblemTypes igual que Git. Al finalizar este trabajo se quiere conseguir una primera versión que muestre un listado de las modificaciones anteriores de un fichero y que permita compararlas. Por último, se ha de verificar la ejecución del código del usuario, comprobando que no tenga errores y realmente funciona como el usuario espera. Si el código tiene errores se mostrarán en la aplicación lo que permitirá una rápida corrección. Este trabajo podrá ser ampliado en un futuro añadiendo puntos de parada y una forma de poder depurar el código, pero este apartado ya no forma parte del TFG. Una vez comentados el objetivo principal y los objetivos secundarios que son la mayor parte de los requisitos funcionales, falta comentar otro requisito funcional que para la empresa son muy importantes. Concretamente, que el trabajo realizado por el alumno se pueda integrar bien en la aplicación web que el departamento de GiD está creando. pág. 22 Otros requisitos no funcionales que han sido impartidos a lo largo de la carrera serian, que no solo es importante que la aplicación funcione y tenga todo lo que el usuario necesita o lo que la empresa pide, sino conseguir también la eficiencia, usabilidad y re-usabilidad. Si una aplicación tiene muchas funcionalidades, pero es muy compleja de utilizar, o va lenta, o los diferentes menús están muy escondidos y no son intuitivos, es muy posible que los usuarios busquen otra aplicación que, a pesar de no ofrecer tantas funcionalidades, sea más fácil de usar y que se ejecute más rápida. Por este motivo el trabajo también se centrará en que el usuario tenga una buena experiencia cuando utiliza la aplicación centrándose en la eficiencia y usabilidad. La reusabilidad y modularización de los diferentes componentes que serán creados a lo largo del trabajo, también son factores muy importantes, ya que es posible que en un futuro se quiera incorporar el componente de gestión de versiones para los modelos y simulaciones, y resultaría muy costoso si no se han modularizado bien las diferentes partes a la vez que generaría mucho código duplicado. 2.4. Posibles riesgos y obstáculos Uno de los principales riesgos en todo proyecto que suele aparecer en la fase inicial, es fijarse más objetivos de los que se pueden cumplir dentro del plazo estimado. El impacto de este riesgo es bajo dado que se podría reducir el tiempo de verificación si fuera necesario, pero para prevenir esta situación se ha hecho una planificación temporal cuidadosa y detallada. Para este proyecto se han tomado diferentes decisiones técnicas explicadas anteriormente respecto a utilizar algunos paquetes ya existentes. Si durante el curso del trabajo resulta que no se pueden adaptar o limitan demasiado para el fin esperado, se tendrían que buscar otros paquetes o simplemente implementar los componentes uno mismo, y eso conllevaría una pérdida de tiempo muy grande. El pág. 23 impacto de fallar en alguna de estas decisiones es alto, dado que cambiaría el rumbo del proyecto demasiado cerca de la fecha de entrega. Para prevenirlo se estudiarán detenidamente las diferentes opciones para poder tomar las decisiones con criterio y acierto. También se ha dejado un poco más de tiempo en las tareas de programación para solucionar imprevistos. No solo existen esos riesgos, sino que también hay un par de obstáculos, el desconocimiento y la inexperiencia. Los dos van cogidos de la mano, porque el estudiante no había tratado hasta ahora con el Framework de Angular y había tocado cómo parte complementaria de alguna asignatura el diseño de páginas web y los lenguajes de programación TypeScript y JavaScript. Esto hace que el estudiante tenga que dedicar un pequeño esfuerzo extra para que la curva de aprendizaje sea lo más pronunciada y rápida posible. Se considera que estos obstáculos conllevan un impacto mediano-bajo dado que en la planificación se ha tenido en cuanta este tiempo de aprendizaje. Gracias a la asignatura de Lenguajes de Programación impartida en la universidad, son obstáculos alcanzables a pesar de que requieren un esfuerzo extra. Por si acaso el tiempo reservado no fuera suficiente se ha decidido añadir algo más de tiempo extra para prevenir el desconocimiento y la inexperiencia de las herramientas. pág. 24 3. Metodología y rigor Para realizar este trabajo, el estudiante ha tenido que adaptarse a las metodologías que utilizaba la empresa. Primero hay una fase de autoaprendizaje y adaptación al Framework de Angular y al lenguaje de programación web. Cómo estamos hablando de un trabajo de creación que también contendrá una pequeña fase de investigación para encontrar la mejor manera de hacer las cosas, se necesitará una metodología flexible. La empresa ya trabaja con una metodología ágil que permite adaptar la forma de trabajo a las condiciones del proyecto y gestionar la realización de las tareas. Este tipo de metodología es el kanban [22], que es un método visual formado por un tablero continuo que se divide en columnas. Cada columna representa una actividad específica que, en conjunto, conforman un “flujo de trabajo”. Las tarjetas van moviéndose por el flujo de trabajo hasta que este termina. En este caso los flujos de trabajo corresponden a “next in line”, “in progress”, “in review” y “done”. Cada una de las tareas a realizar se representa en tarjetas. Esta distribución se puede ver en la siguiente imagen. Figura 2 : Representa el tablero de kanban del 27 de septiembre del 2021. Elaboración propia. Esto permite dividir el trabajo en partes, teniendo muy claro que conlleva cada una de las tareas y se visualizarán todas a la vez para que se prioricen las que están en curso. Al principio del trabajo se ha hecho una reunión con el director del TFG en pág. 25 la cual se acordaron y definieron las diferentes tareas que se tendrían que realizar. Una vez definidas las tareas el estudiante creó una tarjeta por cada tarea y se colocaron en la columna de “next in line”. Poco a poco se fueron empezando las tareas que se movían a la columna de “in progress”. Una vez terminada la tarea se situaba en la columna de “in review” y si el trabajo realzado era correcto, se pasaba a la columna de “done” y se empezaba con la siguiente tarea de la cola. Esto va de la mano de unas reuniones semanales de seguimiento para ver si los objetivos se van cumplido y resolver dudas que vayan surgiendo. La comunicación con el tutor del trabajo es constante, ya que se ha trabajado en la misma empresa y departamento de manera presencial con el tutor durante la ejecución del proyecto. Dentro de lo que las medidas Covid permiten en cada momento, así la comunicación se realiza en el día a día del trabajo. 3.1. Herramientas Para poder llevar a cabo la metodología anterior se ha decidido utilizar las herramientas que la empresa Atlassian [23] proporciona. Las herramientas que se utilizarán son “Jira” que permiten crear tableros y gestionar las tareas, “Confluence” que se utiliza para compartir documentos y redactarlos de manera online colaborativa y la aplicación de “Bitbucket” sirve para crear repositorios y almacenar el código que junto a “Sourcetree” [24] se obtiene una manera más simple de control de versiones. Gracias a esta interfaz se evita tener que aprender todas las órdenes de gestión de versiones Git que se tendrían que introducir por terminal. Con la situación actual también ha sido necesario buscar nuevas herramientas para poder mantener la comunicación entre los miembros del equipo y esto ha hecho que se utilicen otras aplicaciones cómo “Slack” [25], los “Meets de google” [26], “AnyDesk” [27] y otras opciones de escritorios remotos. pág. 32 de deshacer y rehacer, etc. El otro tipo de editor consiste en dos pestañas de editor normales una junto a la otra y marca las diferencias entre lo que se escriba en un editor con respecto al otro. Se estiman unas 50 horas. CI2 - Crear línea temporal Crear el componente de gestión de versiones utilizando el api de GitLab para obtener el código de versiones anteriores y mostrarlo en el editor. Se estiman unas 25 horas. CI3 - Implementar interacciones con GitLab Api Crear la barra de herramientas que permita abrir, guardar, eliminar y cerrar los ficheros del editor. Para esto se necesita conectar con el api de GitLab para poder hacer todas estas funciones. Se estiman unas 50 horas. CI4 - Implementar el modo Debug Ejecutar el código que el usuario introduce en el editor, detectar errores y mostrar la visualización gráfica por pantalla. Se estiman unas 75 horas. CT – Pruebas CT1 - Pruebas unitarias Probar cada componente por separado para ver que la funcionalidad es correcta. El número de horas depende de la cantidad de componentes y de la profundidad con que se quieran probar. Se estiman 25 horas. pág. 33 CT2 - Pruebas de principio a fin Consiste en comprobar el flujo de datos y la ejecución que sigue la página web con todos los componentes incorporados y una secuencia de acciones predeterminadas. Se estiman 25 horas. CT3 - Pruebas de usabilidad Pasar la aplicación a personas de la empresa para que la utilicen y reporten los errores encontrados y posibles mejoras. Se estiman 10 horas de pruebas y 15 horas de corrección de errores. 4.2. Recursos 4.2.1. Recursos humanos Dentro de un proyecto no todos los trabajadores tienen el mismo rango o responsabilidades. La diferencia principal que podemos encontrar es que hay un “Jefe de Proyecto” (JP) y luego está el “Equipo”. El “Jefe de Proyecto” es quien lidera el equipo, se encarga de la planificación, dirige las reuniones de seguimiento y toma las decisiones importantes. Por otra parte, está el “Equipo”, dentro de este equipo podemos encontrar diferentes roles, están los “Investigadores” (I) que son los encargados de buscar las diferentes soluciones y nuevas tecnologías que se pueden utilizar para cumplir los objetivos. También encontramos los “programadores”. En este rol hay que diferenciar entre los “programadores de funcionalidades” (PF) que su principal tarea es programar, crear código que cumpla con las funcionalidades pedidas, y el otro rol es el “programador /diseñador gráfico” (PD) que es quien se encarga de la visualización de la aplicación y de que los componentes de la página web se vean cómo el cliente quiere. Por último, aunque el programador ha creado pruebas unitarias y de principio a final, una parte importante de los errores se descubren con el uso de la pág. 34 aplicación y para ello se necesita un conjunto de personas que prueben la aplicación y detecten errores, estos son los “testers” (T). Este proyecto se realiza por una persona, eso quiere decir que el autor interpretará todos los roles, pero tendrá el apoyo de los miembros del departamento de GiD para cualquier duda que surja, en la Tabla 1 que está a continuación se puede ver una columna donde se especifica que rol va relacionado con cada tarea. 4.2.2. Recursos materiales En este apartado se comentará todo el material que se necesita para realizar el proyecto, tanto material físico cómo programas. Esto se verá reflejado por cada tarea en la tabla que aparece al final de este apartado. La empresa proporciona un espacio dentro del despacho del departamento de GiD con mesa y una torre para poder trabajar, pero se utilizará un portátil personal para escribir la documentación. En la tabla todo aparecerá cómo Ordenador. También se necesita internet para buscar información y poder subir el trabajo realizado. Cómo este recurso se necesitará siempre no aparecerá en la tabla. Se han descargado diferentes programas, algunos son de pago y los proporciona la empresa. Otros son gratuitos, concretamente programas de documentación y presentación cómo Word [28] y PowerPoint. También se han utilizado aplicaciones gratuitas para programar cómo el Visual Studio Code [29], Sourcetree [24], Angular [33]. También se utilizan paquetes cómo Monaco Editor, PrimeNG [34] para componentes visuales y GitLab api para conectar la aplicación con GitLab CIMNE. Se utilizan la mayoría de los recursos de Atlassian [23] y la aplicación Gantter [30] para la organización y las reuniones. Id. Tarea Tiempo (horas) Dependencias Recursos Roles D Documentación 160 h - - - D1 Entregas de GEP 90 h CP1, CP2, CP3 - Ordenador - pág. 35 - Microsoft Word - Material de GEP D2 Escribir memoria 60 h D1 - Ordenador - Microsoft Word JP, I, PF, PD, T D3 Preparar presentación 10 h D2, S4 - Ordenador - PowerPoint JP S Reuniones de Seguimiento 22 h - - - S1 Reunión Inicial 3 h - - Ordenador JP S2 Reuniones seguimiento semanales 15 h S1 - Ordenador - Atlassian JP, I, PF, PD, T S3 Reunión hito intermedia 2 h S2 - Ordenador JP, I, PF, PD, T S4 Reunión Final 2 h S2, S3, CT3 - Ordenador JP, I, PF, PD, T CP Preparación Previa 85 h - - - CP1 Definir Alcance 10 h S1 - Ordenador - Microsoft Word JP CP2 Planificación Temporal 10 h CP1 - Ordenador - Microsoft Word - Gantter JP CP3 Presupuesto y análisis de sostenibilidad 15 h CP2 - Ordenador - Microsoft Word JP CP4 Aprendizaje Angular y TypeScript 40 h CP3 - Ordenador - Udemy PF, PD CP5 Preparar el Entorno 10 h CP4 - Ordenador - Sourcetree - Angular - Visual Studio Code PF, PD CD Diseño 60 h - - - CD1 Diseño del Editor 12 h CP5 - Ordenador I CD2 Diseño del Gestor de Versiones 16 h CP5 - Ordenador I CD3 Diseño del Modo Debug 16 h CP5 - Ordenador I CD4 Diseño de la Interfaz Gráfica 16 h CP5 - Ordenador PD CI Implementación 200 h - - - CI1 Crear Editor 50 h CD1, CD4 - Angula - Visual Studio Code - Sourcetree PF, PD pág. 36 - paquete Monaco editor CI2 Crear Línea Temporal 25 h CD2, CD4 - Angula - Visual Studio Code - Sourcetree - PrimeNG PF, PD CI3 Implementar interacciones con GitlLab Api 50 h CD1, CD2 - Angula - Visual Studio Code - Sourcetree - cuenta GitLab CIMNE PF CI4 Implementar el modoDebug CD3, CD4 - Angular - Visual Studio Code - Sourcetree PF, PD CT Pruebas 75 h - - - CT1 Pruebas Unitarias 25 h CI3, CI4 - Angular - Visual Studio Code - Sourcetree PF CT2 Pruebas de Principio a Final 25 h CT1 - Angular - Visual Studio Code - Sourcetree PF CT3 Pruebas Usabilidad 25 h CT2 - T - Total 602 h - - - Tabla 1 : Tabla resumen de tareas con la duración y recursos de cada una. Elaboración propia En el Anexo A están las figuras que representan el diagrama de Gantt, en el que se pueden ver las diferentes tareas, en el que cada ámbito está representado por un color diferente. En el diagrama de Gantt se pueden ver las diferentes dependencias entre tareas, pero también se pueden apreciar de manera más clara las dependencias entre tareas de final a inicio en la siguiente figura. pág. 37 Figura 3 : Diagrama de dependencias de final-inicio. Elaboración propia 4.3. Gestión del riesgo El primer riesgo está relacionado con la tarea de Aprendizaje del entorno Angular y de TypeScript. Si la curva de aprendizaje no es tan rápida cómo se esperaba en un principio, se tendrán que añadir horas de trabajo según sea necesario, por eso esta tarea se realiza en agosto, si fuera necesario se podría alargar utilizando las dos semanas de vacaciones que el estudiante tiene en la empresa antes de empezar el cuatrimestre. De esta manera no se vería afectada la duración del proyecto. Los siguientes riesgos son más problemáticos, están relacionados con que una de las decisiones que se han tomado en las fases de Diseño no sea adecuada para este proyecto. Si la solución consiste en crear una tarea de adaptación de otro paquete ya existente, que reemplace el que no se adapta al proyecto, tendrá un coste menor al que si la solución es añadir la tarea de implementar desde cero las funcionalidades que debería tener el paquete. En el caso de cambiar de paquete se necesitarán los recursos del nuevo paquete. Asumiendo que parte del código que relaciona los componentes ya estará hecho, se estiman 15 horas para la gestión de versiones y 10 horas para el editor. En el caso del módulo de Debug es más complicado, porque se tendría que buscar una solución nueva e implementarla, esto se estima con unas 50 horas de trabajo extra y puede que se necesiten nuevos recursos. pág. 38 Se intentará no llegar al caso de implementar desde cero, porque si esta casuística se da en el editor y en el componente de gestión de versiones, es muy posible que el incremento de tiempo sea insostenible para el trabajo o se tendrían que reducir pruebas por falta de tiempo. Todos estos casos se han tenido en cuenta en el diagrama de Gantt que está en el Anexo A, se han representado de color amarillo y con el nombre de tarea extensión de identificador. Si al final todo va según lo previsto, se terminaría el trabajo un poco antes de la fecha de entrega y se puede aprovechar para hacer más pruebas o añadir alguna funcionalidad extra. pág. 39 5. Presupuesto Una parte importante de todo proyecto es hacer una estimación de costes que tenga en cuenta los obstáculos que puedan aparecer y los costes no programados para no sobrepasar el presupuesto acordado para el proyecto. 5.1. Identificación y estimación de costes Los costes se dividirán en dos tipos, los costes del personal y los costes genéricos que contendrán hardware, software y necesidades varias. También se tendrán en cuenta los imprevistos y se hará un plan de contingencia. Costes de personal Cómo ya se ha comentado anteriormente, en este proyecto participan diferentes roles y cada uno tiene diferentes grados de responsabilidad. Por este motivo, dependiendo del rol que tratemos los salarios varían. En la siguiente tabla se puede apreciar el coste por hora dependiendo del rol. Rol Coste por hora Seguridad Social Total Jefe de Proyecto 30 €/h 9 €/h 39 €/h Investigadores 20 €/h 6 €/h 26 €/h Programador funcionalidades 16 €/h 4,80 €/h 20,80 €/h Programador gráfico 16 €/h 4,80 €/h 20,80 €/h Tester 16 €/h 4,80 €/h 20,80 €/h Tabla 2 : Retribución de cada Rol. Elaboración propia Una vez fijado el precio por hora de cada rol es el momento de tener en cuenta todas las tareas de la planificación y calcular el coste del personal total. Es lo que se puede ver en la siguiente tabla, donde la columna JP corresponde al Jefe del proyecto, la columna I corresponde al Investigador, la columna PF al Programador de funcionalidades, la columna PD al Programador gráfico y la columna T al Tester. pág. 40 Id. Tarea Tiempo (horas) JP I PF PD T Coste D Documentación 160h 858€ 312€ 249,60€ 249,60€ 249,60€ 1.918,80€ D1 Entregas de GEP 90h - - - - - - D2 Escribir memoria 60h3 468€ 312€ 249,60€ 249,60€ 249,60€ 1.528,80€ D3 Preparar presentación 10h 390€ - - - - 390€ S Reuniones de Seguimiento 22h 858€ 494€ 395,20€ 395,20€ 395,20€ 2.537,60€ S1 Reunión Inicial 3h 117€ - - - - 117€ S2 Reuniones seguimiento semanales 15h 585€ 390€ 312€ 312€ 312€ 1.911€ S3 Reunión hito intermedia 2h 78€ 52€ 41,60€ 41,60€ 41,60€ 254,80€ S4 Reunión Final 2h 78€ 52€ 41,60€ 41,60€ 41,60€ 254,80€ CP Preparación Previa 85h 1.365€ - 520€ 520€ 2.405€ CP1 Definir Alcance 10h 390€ - - - - 390€ CP2 Planificación Temporal 10h 390€ - - - - 390€ CP3 Presupuesto y análisis de sostenibilidad 15h 585€ - - - - 585€ CP4 Aprendizaje Angular y TypeScript 40h4 - - 416€ 416€ - 832€ CP5 Preparar el Entorno 10h5 - - 104€ 104€ - 208€ CD Diseño 60h - 1.144€ - 332,80€ - 1.476,80€ CD1 Diseño del Editor 12h - 312€ - - - 312€ CD2 Diseño del Gestor de Versiones 16h - 416€ - - - 416€ CD3 Diseño del Modo Debug 16h - 416€ - - - 416€ 3 Estas horas son totales se dividen entre los dos roles, cada rol dedica 12 horas. 4 Estas horas son totales se dividen entre los dos roles, cada rol dedica 20 horas. 5 Estas horas son totales se dividen entre los dos roles, cada rol dedica 5 horas. pág. 41 CD4 Diseño de la Interfaz Gráfica 16h - - - 332,80€ - 332,80€ CI Implementación 200h - - 2.600€ 1.560€ - 4.160€ CI1 Crear Editor 50h6 - - 520€ 520€ - 1.040€ CI2 Crear Línea Temporal 25h7 - - 260€ 260€ - 520€ CI3 Implementar interacciones con GitlLab Api 50h - - 1.040€ - - 1.040€ CI4 Implementar el modoDebug 75h8 - - 780€ 780€ - 1.560€ CT Pruebas 75h - - 1040€ - 520€ 1560€ CT1 Pruebas Unitarias 25h - - 520€ - - 520€ CT2 Pruebas de Principio a Final 25h - - 520€ - - 520€ CT3 Pruebas Usabilidad 25h - - - - 520€ 520€ - Total 602h 3.081€ 1.946€ 4.804,80€ 3.057,6€ 1.164,8€ 14.058,20€ Tabla 3 : Tabla de costes por tarea. Elaboración propia Después de observar la Tabla 3 podemos deducir que el coste del personal para el proyecto es de 14.058,20€ que se redondeará a 14.059 €. Costes genéricos Para esta parte tendremos en cuenta que la amortización del Hardware es de unos 4 años, la fórmula que se utilizará para calcular las amortizaciones es 𝑪𝒐𝒔𝒕𝒆𝑫𝒊𝒔𝒑𝒐𝒔𝒊𝒕𝒊𝒗𝒐 ( € ) ∗𝑯𝒐𝒓𝒂𝒔𝑼𝒔𝒐(𝒉𝒐𝒓𝒂𝒔) 𝑽𝒊𝒅𝒂Ú𝒕𝒊𝒍 ( 𝒂ñ𝒐𝒔 ) ∗𝑫í𝒂𝒔𝑻𝒓𝒂𝒃𝒂𝒋𝒂𝒅𝒐𝒔 ( 𝒅𝒊𝒂𝒔/𝒂ñ𝒐 ) ∗𝑯𝒐𝒓𝒂𝒔𝑫𝒊𝒂𝒓𝒊𝒂𝒔(𝒉𝒐𝒓𝒂𝒔/𝒅𝒊𝒂) 6 Estas horas son totales se dividen entre los dos roles, cada rol dedica 25 horas. 7 Estas horas son totales se dividen entre los dos roles, cada rol dedica 12.5 horas. 8 Estas horas son totales se dividen entre los dos roles, cada rol dedica 37.5 horas. pág. 48 6. Aplicación GiD de escritorio Anteriormente se ha mencionado mucho el nombre de la aplicación GiD actual que se puede descargar en [43] y se ha hecho un pequeño resumen del objetivo principal y de lo que quiere aportar a sus usuarios. En este apartado se quiere profundizar un poco más para ver parte del potencial que tiene y poder entender mejor la explicación del desarrollo. La idea principal de arquitectura de la nueva web reside en crear una web que tenga todas las funcionalidades ya existentes en la aplicación original e incluso añadir algunas nuevas. Pero esta parte solo será el frontend, eso quiere decir que convertirá los datos en una interfaz gráfica para que el usuario pueda ver e interactuar con la información de forma digital usando HTML, CSS y JavaScript. Pero si lo que hace es convertir la información, la pregunta que nos interesa es ¿Qué información? o ¿De dónde sale esa información? La respuesta es muy simple, se conectará a otro componente que nosotros llamamos ModelManager que contendrá la información de los usuarios y sus modelos. Una vez el usuario esté preparado para trabajar, solo tendrá que abrir un modelo y empezar a hacer geometrías, cálculos, simulaciones, etc. Para que esto sea posible, en un servidor estará activa una instancia del programa original de la cual la aplicación web obtendrá los datos de los cálculos, simulaciones y demás para poder mostrarlos al usuario. Pero también se le enviará toda la información de las tareas a realizar con las ordenes precisas para que el programa del servidor las pueda ejecutar. Las conexiones explicadas anteriormente han sido creadas por los compañeros de la empresa y una vez empezado el proyecto esa parte ya era funcional. A continuación, se puede ver una imagen de la aplicación de GiD del apartado de Preproceso. Esta es la parte CAD de la aplicación, en la que se pueden hacer operaciones geométricas como generar entidades, manipularlas y destruirlas. pág. 49 Figura 4 : Aplicación GiD, parte de preporcesado. Elaboración propia Si se presiona el botón de la barra estándar, la aplicación te llevará a la parte de postprocesado que se puede ver en la siguiente imagen. Si se presiona te lleva otra vez a la parte de preprocesado. El postprocesado permite estudiar los resultados de un solver. La aplicación recibe información de mallas y resultados desde el módulo de resolución, y si el módulo de resolución no crea ninguna malla nueva, se utilizará la malla de preprocesado que genera el programa de GiD. pág. 50 Figura 5 : Aplicación GiD, parte de postporcesado. Elaboración propia Los ProblemTypes son un conjunto de funcionalidades que permiten al usuario interactuar fácilmente con ellas por medio de una interfaz gráfica de usuario (GUI), y facilita la definición e introducción de todos los datos necesarios para llevar a cabo un determinado cálculo. Para que la aplicación pueda preparar los datos para un programa específico de análisis, es necesario personalizar la aplicación, lo que hacemos con los ProblemTypes que se pueden cargar y descargar fácilmente una vez han sido introducidos en la aplicación. Este trabajo ha intentado facilitar la creación de funcionalidades con un editor para que esté integrada dentro de la nueva aplicación web, ya que la aplicación de escritorio actualmente se hace creando un directorio al que se le pone el nombre del ProblemType, que ha de contener un conjunto de ficheros. pág. 51 Los ficheros, definen el tipo de ProblemType y contienen el conjunto de funcionalidades que personalizan el preprocesado. Se añade un fichero que define cómo la aplicación GiD extrae la información del preporcesado para pasarla al solver. Se añade otro fichero que define como sale la información del solver para que el postprocesado la lea de esa manera. La siguiente imagen muestra lo que es la aplicación de GiD y los ficheros externos que consiguen personalizar la aplicación. Figura 6 : Ayuda visual para entender que ficheros contiene un ProblemType. Esta imagen se ha extraído de la página 3 de [44] La aplicación de GiD permite hacer muchas más acciones que no se han explicado en este proyecto, solo nos hemos centrado en explicar una vista general de la aplicación y las partes relacionadas con las funcionalidades y ProblemTypes. pág. 52 7. Solución propuesta En este apartado se hará una relación de posibles maneras de solucionar el problema planteado inicialmente. Se evaluarán las diferentes opciones y se tendrán en cuenta las limitaciones de cada una para poder escoger la mejor propuesta como solución final. El trabajo se abordará por objetivos secundarios, como se ha explicado anteriormente estos son las tareas CD1 9 , CD2 10 y CD3 11 del diagrama de Gantt. 7.1. Posibles alternativas del editor Para resolver el problema del editor se pensó en buscar un componente que proporcionara un editor básico al que se le pudieran añadir funcionalidades y permitiera adaptarse a lo que la empresa necesitara. Otra opción que se barajó fue crearlo desde cero, pero se consideró que era demasiado costoso y que no daría tiempo a terminar el proyecto dentro del tiempo estimado e incluso sería difícil hacer el resto de las funcionalidades si se decidía implementar el editor desde cero. Una vez tomada la decisión de trabajar con un componente ya existente y adaptar funcionalidades, se pasó a la fase de buscar componentes que se pudieran adaptar, como los editores utilizados en diferentes entornos de desarrollo integrado (IDEs). De todas las opciones encontradas, las más destacadas fueron “RunKit” [16], “AceEditor” [17] y “MonacoEditor” [18]. A continuación analizaremos con detalle las características de cada una de las opciones para poder determinar qué beneficios y qué inconvenientes proporcionaba cada alternativa. 9 Tarea del diagrama de Gantt que corresponde con el diseño del editor 10 Tarea del diagrama de Gantt que corresponde con el diseño del gestor de versiones 11 Tarea del diagrama de Gantt que corresponde con el diseño del modo debug pág. 53 RunKit Figura 7 : Un ejemplo del RunKit editor [16] Como beneficio se puede destacar que es un editor centrado en la parte de ejecución. Principalmente permite ejecutar bloques de código en los llamados notebooks. Estos fragmentos de código se pueden conectar a ficheros de GitHub [19] para extraer los datos que luego se utilizarán en las ejecuciones, e incluso descargar paquetes NPM [45] e incorporarlos a la ejecución. Los inconvenientes que se han encontrado con esta opción es que no permite mucha personalización o adaptación con respecto a la visualización del editor. La empresa intenta ofrecer al usuario la mayor variedad y flexibilidad con respecto a pág. 54 la personalización del interfaz y con este editor se tendría que renunciar o invertir el doble de tiempo en sustituir o reemplazar los ficheros de estilos CSS que se utilizan para dar personalidad a las páginas web. Otro de los problemas importantes es que el editor está muy centrado en temas de documentación del código y gráficas para interpretar datos, para ejecutar componentes propios que el usuario pueda programar, se tendría que crear algún paquete NPM para completar el editor y eso complicaría un poco la manera en que el usuario crearía estos componentes y no sería tan intuitivo. AceEditor Figura 8 : Un ejemplo del AceEditor [17] Este componente es algo diferente al anterior, opta más por la parte de edición en vez de dar la opción de ejecutar cómo el anterior. Algunos de los beneficios que aporta este editor es que sí permite cambiar la visualización. También tiene reconocimiento de 110 sintaxis diferentes, con códigos de colores correspondientes a las palabras claves e indentados del lenguaje que se esté utilizando, y acepta hasta 4 millones de líneas. Incorpora opciones básicas de los editores como copiar, pegar, buscar, reemplazar y mucho más. Pero no es oro todo lo que reluce y a pesar de todos los beneficios que aporta esta decisión, también se ha encontrado un pequeño inconveniente. En la aplicación pág. 55 que la empresa quiere ofrecer a los usuarios se espera poder gestionar las versiones anteriores, esto quiere decir que la aplicación ha de poder mostrar el código anterior comparándolo con la versión actual. De esta manera el usuario puede ver las modificaciones entre las dos versiones de manera rápida e intuitiva. Hacer esta funcionalidad con “AceEditor” es algo más complicado de lo que parece a simple vista. El primer paso es obtener el código de las dos versiones, pero ese problema lo trataremos en profundidad un poco más adelante. El siguiente paso es encontrar las diferencias que hay de un código a otro. Esto se puede hacer con un algoritmo que implemente el estudiante. El último paso es poder mostrar las diferencias que detecta el algoritmo de cara al usuario, y aquí reside gran parte del problema. Se tendría que añadir dos componentes del “AceEditor”, uno de ellos bloqueado para que no se pueda cambiar el código que corresponde a la versión anterior y añadir ciertos decoradores para marcar las diferencias. Esta opción es viable, pero puede llevar demasiado tiempo de trabajo en la parte de visualización. MonacoEditor Figura 9 : Un ejemplo del MonacoEditor [18] Este editor es muy parecido al anterior. Muchos de los beneficios que aportaría utilizar esta alternativa son compartidos con los beneficios de utilizar el editor pág. 56 anterior. Permite validación de algunos de los lenguajes de programación más utilizados cómo JavaScript, TypeScript, CSS, JSON, HTML, etc. También tiene reconocimiento de diferentes sintaxis, con sus códigos de colores correspondientes a las palabras claves, etc. Pero uno de los beneficios más llamativos es que tiene incorporado un editor de diferencias, que resalta en verde las líneas nuevas y en rojo las líneas que han sido borradas. Las líneas modificadas tienen un color rojo claro en el código original y un verde claro en el código que ha sido modificado, resaltando el fragmento modificado de un tono más fuerte del color que corresponda. Figura 10 : Un ejemplo del editor de difrencias del MonacoEditor [18] A simple vista con las investigaciones iniciales no se han detectado inconvenientes que resulten un problema para el trabajo y es el que utilizan de base IDEs cómo Visual Studio Code. [29] 7.2. Posibles alternativas del control de versiones Otro de los problemas a los que hay que enfrentarse a lo largo de este proyecto es encontrar una manera que permita gestionar las versiones anteriores del código del usuario. Esto ha de permitir poder acceder al código anterior que ha de estar almacenado en alguna parte y poderlo comparar. La parte de comparación ha sido pág. 57 tratada en el apartado anterior con el problema del editor, en este apartado se evaluarán las diferentes opciones de almacenado. La primera alternativa en la que se pensó fue en crear una API propia para la empresa que se conectara a una base de datos para poder guardar la información del código. Los beneficios de esta idea son muy evidentes. Al crear algo desde cero no existe el problema de tener que adaptarse o moldearse a lo que ofrece el programa que se está utilizando y además se puede crear a la medida de las necesidades de la empresa. Esta característica es un arma de doble filo, lo que nos lleva a hablar de los problemas que tiene esta solución. Lo primero a destacar es que no sólo se quiere guardar el código, también se quiere gestionar de manera similar a Git. En la primera versión del proyecto solo habrá una única rama con las versiones anteriores en formato commit 12 , pero más adelante se querrá dar la opción al usuario de trabajar en diferentes ramas, crear ramas nuevas y poder trabajar simultáneamente en el mismo fichero con más gente. Teniendo en cuenta estos planes de futuro para el proyecto, quizás esta solución conlleva demasiado tiempo y esfuerzo cuando ya hay plataformas que ofrecen APIs de conexión con este tipo de gestores de versiones; así que, se optó por utilizar una plataforma ya existente. La segunda alternativa fue utilizar APIs que permiten conectar a la aplicación con repositorios de código cómo GitLab [20] o GitHub [19], ambas opciones ofrecen más o menos las mismas funcionalidades. El beneficio de esta solución es que facilitará en un futuro el tema de gestionar las ramas y almacenar la información correctamente. Como inconveniente se puede considerar que permite guardar el código con un mensaje de commit pero no mucha información más, aunque de momento esta alternativa parece suficiente. 12 Operación que permite Git para guardar. pág. 64 8.2. Diseño de la interfaz gráfica Una vez el entorno de trabajo está preparado, se han evaluado las posibles implementaciones con sus beneficios e inconvenientes y se ha decidido cuál es la mejor solución. Es el momento de dar forma e imaginar gráficamente la parte de la aplicación que se implementará en este TFG. Para ello se crea un diseño de la interfaz gráfica que resulte cómodo e intuitivo para el usuario, esta tarea corresponde a la tarea CD4 14 del diagrama de Gantt. La aplicación en todo momento tendrá la barra superior visible, que llamaremos “cabecera”. La cabecera contendrá el logo de la aplicación y diferentes iconos para abrir menús. La parte central de la pantalla se dividirá en dos, la superior que ocupará mucho menos espacio que la inferior. La parte central-superior será común para los diferentes editores y permitirá ver el nombre del fichero y contendrá botones que permitan gestionar los diferentes ficheros. La parte central-inferior contendrá un componente de menú en pestañas que irá cambiando según las necesidades del usuario entre el editor, el editor con la parte de ejecución o el editor de diferencias. A continuación, se muestran una serie de figuras que representan los elementos que tendrá la aplicación y cómo se sitúan en el espacio. En la primera se puede observar la distribución del espacio, en las siguientes observamos una posible representación de cómo quedaría la interfaz en cada pestaña. Al programar la aplicación se utilizarán elementos PrimeNG [34] que son una colección de componentes de interfaz de usuario para Angular. En las figuras podemos observar fotos reales de algunos de estos elementos de la colección PrimeNG como los 14 Tarea del diagrama de Gantt que corresponde con el diseño de la interfaz gráfica. pág. 65 botones y la línea temporal, sacados de su pagina web oficial para seguir el estilo que tiene el resto de la aplicación y hacernos una idea del resultado final. Figura 16 : Organización de la aplicación. Elaboración propia En la siguiente imagen el editor ocupa todo el espacio central-inferior para que el usuario pueda codificar cómodamente. Figura 17 : Diseño de la interfaz en la pestaña Editor. Elaboración propia pág. 66 En la siguiente imagen el espacio central-inferior está dividido en dos partes. La parte izquierda corresponde al editor, donde el usuario puede seguir modificando el código. En la parte derecha se puede observar que aparecen dos recuadros. El recuadro superior es una pequeña pantalla en la que se mostrarán las ejecuciones del usuario en caso de que no se hayan cometido errores de código, en este caso se pueden apreciar un conjunto de botones de diferentes colores. El recuadro inferior quiere representar una pequeña consola de ayuda, que mostrará los mensajes de error en caso de que estén y el contenido de las llamadas a la función “conosle.log()”. Además se puede apreciar que en el panel central-superior que contiene todos los botones que permiten gestionar los diferentes ficheros, también ha aparecido un botón nuevo. Este botón es el “Play” que permite ejecutar el código que el usuario tiene escrito en el editor y mostrarlo en la pantalla de visualización. Figura 18 : Diseño de la interfaz en la pestaña Editor&Play. Elaboración propia pág. 67 Por último, se muestra una figura con la pestaña del Editor&Versions. Se puede ver que el panel central-inferior también se ha dividido en dos partes. La parte de la izquierda contendrá el editor, en este caso se puede observar que el editor es algo diferente a los anteriores. Este componente muestra dos editores en uno, con ayudas visuales para que el usuario pueda ver las diferencias de código que tienen ambos editores. El editor de la izquierda corresponde a las versiones de código anteriores y el de la derecha muestra el código actual, incluso te deja seguir modificándolo. En el panel-inferior se puede ver que la parte derecha contiene una línea temporal que muestra diferentes puntos con los mensajes relacionados a cada guardado. Los botones inferiores son más antiguos en el tiempo respecto a los que están más arriba en la línea temporal. Figura 19 : Diseño de la interfaz en la pestaña Editor&Versions. Elaboración propia pág. 68 8.3. Creación del editor Es el momento de empezar a programar. Lo primero que se ha hecho es crear un componente Angular llamado feature-studio.component y una ruta web nueva, que llevará a este componente. Esto genera un espacio nuevo dentro de la aplicación web que se utilizará como lienzo. También se crea un servicio llamado feature-studio.service que de momento estará vacío, los componentes le pedirán los datos que necesiten de GitLab y el servicio hará las peticiones necesarias y retornará esa información en el formato que el componente necesita. De esta manera el componente feature-studio.component funcionará como controlador que se conectará con el servicio feature-studio.service y enviará la información a cada uno de sus componentes, que podemos denominar hijos. Una vez creado el componente feature-studio.component ya se puede empezar a dar forma. En primer lugar se añade un menú de pestañas para poder cambiar entre los tres tipos de editores. Se deja un poco de espacio en la parte superior, que es donde se colocarán los botones para gestionar los ficheros. Ahora nos centraremos en crear el editor, se crea un nuevo componente Angular que se llamará editor.component y añadimos uno a cada pestaña. A continuación descargamos el paquete [52] llamado ngx-monaco-editor y lo instalamos en el proyecto. Dentro del editor.component.html insertamos la etiqueta del editor. Se ha decidido que el componente editor contenga los tres tipos de editores y dependiendo del valor de la variable editor_type se mostrará uno u otro. Para el editor normal y el de ejecución se mostrará el ngx-monaco-editor y para el de diferencias se mostrará el ngx-monacodiff-editor. Cuando se crean los editores se definen unas opciones por defecto, las más importantes son el lenguaje de programación que será JavaScript, el tema que será oscuro, activar la opción de deshacer, activar la opción de rehacer y se asignan unos tamaños para que se vean bien dependiendo del espacio en el que se muestran. pág. 69 Se crean unas variables llamadas code , codePlay , originalModelcode y modifiedModelcode. En estas variables se almacenará el código que el usuario escribe en cada editor. Son variables de “doble binding” como las llama Angula. Esto quiere decir que se pueden actualizar en las dos direcciones. Una es desde la parte html, el usuario escribe en el componente editor y se guarda el código en la variable. El otro es desde el código, se puede asignar un valor a la variable desde el lado del programador y el usuario lo ve reflejado en el componente editor. Esto permite que el editor pueda tener código por defecto y se puedan cargar ficheros que han sido guardados previamente. Una vez se tienen los tres editores básicos, es el momento de añadir todas las funcionalidades que queremos que tengan. 8.3.1. Actualizar código entre editores Para que la aplicación no esté continuamente actualizándose, dado que la podría ralentizar demasiado, se ha decidido utilizar el siguiente método que aportará un factor de eficiencia y velocidad a la aplicación. Cuando el usuario modifica el código del editor, este se guarda en la variable asociada al editor que se está utilizando en el momento. Cuando el usuario decide cambiar de pestaña para visualizar otro editor, el componente controlador featurestudio.component, pide el código actual al editor que se ha estado usando y lo actualiza en el nuevo. De esta manera no se actualiza la página para cada click del teclado si no en el momento de cambiar de pestaña y solo se actualizan los editores que se van a utilizar. Para poder hacer esto se han utilizado los decoradores @Input() y @Output() que tiene Angular. De esta manera se puede cambiar perfectamente entre pestañas y siempre se tendrá el código actualizado. pág. 70 8.3.2. Área editable Se quiere que el usuario sea capaz de crear ProblemTypes. Estos están formados por diferentes funcionalidades que juntas conforman esos cambios que quiere añadir el usuario a la aplicación original. El editor está pensado de la siguiente manera. En cada fichero solo se puede guardar una funcionalidad y esta tiene que venir definida por una cabecera concreta. En la siguiente imagen se puede observar la definición de la cabecera de una funcionalidad. Figura 20 : Función que define una funcionalidad. Elaboración propia Para minimizar los errores que pueda cometer el usuario se ha decidido crear un área editable para que la definición de la función que contendrá la programación de esa funcionalidad no la tenga que escribir el usuario. Para hacer esto se pone el código de la imagen anterior por defecto en el editor. Si el usuario escribe en el área que no es editable, es decir antes de la frase // Start of editable area o después de la frase // End of editable area se deshace el cambio que haya hecho. De esta manera solo se permite escribir dentro de esas frases. 8.3.3. Cambiar el nombre de la función Como se ha comentado anteriormente, el usuario solo puede escribir dentro del área editable, así que se ha creado una función que recorre la cabecera y cambia el nombre, dejando el resto de código igual. Esta función se utilizará cuando se cree un “nuevo” fichero o cuando se haga un “guardar como” que el usuario escribirá el nombre del fichero nuevo y este mismo nombre se utilizará para la función. pág. 71 8.3.4. Autocompletado Se quieren proporcionar ayudas al usuario a modo de manual. Solo escribiendo parte de una palabra le aparezcan las posibles opciones que quería escribir y las funciones que puede llamar relacionadas con esa palabra. Para hacer esto se añade un triggerCharacters que se activa cuando se detecta un “.” o un “(” y sacando la última palabra que se está escribiendo del editor se evalúa para determinar en qué caso está. Esta evaluación se hace mediante unas expresiones regulares que intentan encontrar unos patrones específicos dentro de la palabra que ha escrito el usuario. En este caso se buscan los patrones relacionados con las palabras context, CurrentWorkingMode o definition[id].el_nombre_que_sea. Una vez se sabe en qué caso se está, se añaden como sugerencias del editor todas las funciones que el usuario puede llamar a partir de esa palabra. Esto se hace mediante la función registerCompletionItemsProvider() que tiene el paquete de MonacoEditor. Figura 21 : Autocompletado del Editor. Elaboración propia pág. 72 Cuando se inicia por primera vez el editor también se añaden unas palabras clave que el usuario puede utilizar como creadoras de los componentes html como botones, ventanas, inputs o elementos más específicos de la aplicación como las coordenadas. Si el usuario presiona el autocompletado de alguna de estas creadoras se añade la creadora con los parámetros obligatorios a modo de ayuda para que el usuario solo tenga que cambiar los valores. Figura 22 : Autocompletado de una creadora. Elaboración propia Figura 23 : Código insertado por el autocompletado. Elaboración propia 8.3.5. Validar sintaxis del código Esta parte está relacionada con la parte de ejecución. El editor lo único que hará es recibir un listado de palabras que sintácticamente son erróneas y las resaltará. El listado lo proporcionará la ejecución, más adelante se explicará cómo se hace esta parte. pág. 73 La manera en que resalta el editor es con un marker que en formato de error deja un subrayado ondulado rojo debajo de la palabra. Hay que indicar en la línea y columna que empieza la palabra y en la línea y columna que termina. Una vez esa palabra ha sido modificada, no se encuentra dentro del código del editor, sale de la lista de errores y se elimina el marker. De esta manera se puede comprobar la sintaxis más específica de funciones propias o de las creadoras que se han comentado anteriormente. Palabras clave del lenguaje JavaScript como function, let, var, private entre otras, las remarca el propio MonacoEditor. Figura 24 : Resaltado del error onclick con los mensajes de error. Elaboración propia 8.4. Creación de la línea temporal La línea temporal la programaremos dentro de uno de los componentes que se ha creado anteriormente, el componente feature-studio.component. Aparecerá en el tercer panel, que tiene el nombre de Editor, Versions y contiene el editor de diferencias. Se ha de añadir una barra de desplazamiento en el lado derecho. Al principio no será muy necesaria, pero cuando los ficheros acumulen muchos elementos guardados y se vean en la línea temporal, esta barra permitirá desplazarse por toda la línea temporal. Teniendo en cuenta la posibilidad de que el usuario se desplace pág. 80 8.5.6. Botón Delete Con él se activa el dialogo de dialog-table en el que se tiene que seleccionar el fichero que se quiere borrar. Una vez seleccionado se elimina de la lista de ficheros que sale en el dialogo y el componente hace la petición al servicio. Esta petición es la siguiente POST /projects/:id/repository/commits?branch=main& commit_message=delete&actions&[{action:’delete’,filePath:filePath}] con lo que se consigue borrar el fichero. En caso de que el fichero que se quiere borrar estuviera abierto en ese momento, desaparecería el código del editor y se pondría el código por defecto. 8.5.7. Petición del código de un commit Cuando se presiona un botón de la línea temporal el componente featurestudio.component hace una petición al servicio con el identificador del commit que se ha presionado. La petición http es la siguiente GET /projects/:id/repository/files/:file_path/raw?ref=commit_id&access_t oken=token [55], esto retorna el código de una versión anterior. A continuación, se envía al componente feature-studio.component para que este lo envíe al editor y el usuario pueda ver las diferencias entre los dos códigos. El resto de los botones se tratarán en el siguiente apartado. 8.6. Creación del apartado de ejecución Lo primero que se ha hecho es crear un componente nuevo llamado runfeture.component. Este componente es hijo del controlador featurestudio.component. El componente se divide en dos partes horizontalmente, en la parte superior se ha dejado espacio para mostrar la ejecución dentro de un elemento html de etiqueta div y en la parte inferior se ha añadido un recuadro que contiene una barra de pág. 81 desplazamiento y otro elemento html de etiqueta div. En este último elemento es en el que se muestran los diferentes mensajes del componente a modo de ayuda. Cuando el componente se inicializa se crea un WebWorker indicando la dirección del fichero que se ejecutará en segundo plano, de la siguiente manera new Worker(dirección_fichero). Para comunicarse entre la ejecución principal y el WebWorker se utilizan unas funciones que proporcionan las librerías de JavaScript que son las siguientes, onmessage = function(){}, self.postMessage(…) y addEventListener((…)=>{…}). El fichero con el que se trabaja ya tenía muchas funciones y clases programadas por los compañeros con los que el estudiante está trabajando en la empresa. Pero para que funcione la ejecución se necesita transformar los componentes html que el usuario programa en el editor, a elementos html reales que la aplicación pueda mostrar. Para hacer esto el estudiante ha creado alguna clase de JavaScript con el nombre de AcceptCancel, Tree, ProgressBar, DropDown, Frame, Row, Column, Button, SelectButon, Input, Listbox, Coordinates, Window, Toolbar, Canvas y TreeTabel. Todas ellas son una extensión de la clase Widget que ya estaba creada. Para cada una de las clases mencionadas anteriormente se ha creado un componente Angular. En los ficheros .html se ha mostrado el componente que indica el nombre de la clase y en los ficheros .ts estará todo el código necesario para hacer la conexión con el WebWorker manteniendo los datos actualizados. Con todas las piezas preparadas solo falta montar la ejecución. Aquí es donde entran en juego los botones de ExecutionValues y Run. Como se ha comentado anteriormente, la aplicación web se conectará a una instancia del programan GiD original, pero en el caso de la ejecución esto no pasa. Quizás en el futuro se decida pág. 82 cambiar esta decisión técnica para que la experiencia de ejecución sea más real, pero para este trabajo se ha decidido hacerlo de la siguiente forma. El usuario podrá ver los componentes que ha programado y su funcionamiento, pero cuando este necesite información de la aplicación real, como por ejemplo saber el número de nodos que tiene una figura geométrica, el propio usuario será quien declare el valor de retorno. Gracias al botón ExecutionValues se pueden definir estos valores que la aplicación retornará, así es más fácil comprobar casos muy concretos. Con esto aclarado es el momento de hacer que el botón Run funcione. Cuando el botón se presiona, el componente controlador obtiene el código del editor y lo envía al componente run-feature.component. Se transforma el código a un formato ejecutable, esto quiere decir separar los argumentos del cuerpo del código para que gracias a la función de JavaScript new Function(arguments, code) el WebWorker pueda utilizar el método eval() para ejecutar esta función, acompañado de un try{}catch(error){} para detectar errores. Cuando se utiliza el método eval() las constructoras de componentes html que ha utilizado el usuario como la clase Button se transforman a objetos JSON. Más tarde el componente Angular widget.compoente transforma el objeto JSON a un formato que el componente Angular button.component puede leer y mostrar el botón en el área que se había reservado para la ejecución. Si en este proceso el método try{}catch(error){} detecta errores el WebWorker los envía al componente run-feature.component y terminará la ejecución del WebWorker. El componente run-feature.component los añadirá al apartado del terminal para que el usuario los vea y los pueda solucionar. En el caso de que detecte la función console.log() enviará la información que tiene que aparecer en el terminal pero no terminará la ejecución del WebWorker. pág. 83 8.7. Implementar tests En este apartado se explicarán las diferentes validaciones que se han hecho del código. Realmente los tests se han implementado junto con la creación de los componentes, pero se han recopilado en este apartado para mejorar la estructura del trabajo. Se harán tres tipos de validaciones, las dos primeras son el test e2e y el test unitario. La última prueba es algo diferente, no requiere programación externa al trabajo, pero si que necesitará la colaboración de compañeros de la empresa. Utilizarán la aplicación para reportar una serie de criticas constructivas. Los compañeros de la empresa han preparado todo el entorno para que el estudiante pueda programar los tests. Para el test e2e ha sido necesario instalar protractor [59] que es un programa de Node.js que utiliza Jasmine [60] que es un framework de testeo. También se ha descargado Cucumber [61] para definir los tests con frases simples que puede escribir cualquier persona, incluso si no ha participado en la programación del proyecto. Las frases tienen las palabras claves Given, When y Then. Aquí es donde entra el trabajo del estudiante. Recopila las frases en ficheros dentro de la carpeta features y por cada una crea una función en el fichero common.steps.ts de los tipos siguientes : - Given(`frase_del_test`, (variables) => { código_del_test }) - When(`frase_del_test`, (variables) => { código_del_test }) - Then(`frase_del_test`, (variables) => { código_del_test }) El código del test recorre la aplicación y mediante funciones como las que aparecen en la siguiente imagen se seleccionan componentes, se hace click en ellos o incluso se escribe texto si es el caso de un input o el editor para comprobar que la funcionalidad de los componentes es correcta y cohesiona bien con la aplicación. pág. 84 Figura 26 : Ejemplo de un test e2e. Elaboración propia Este tipo de test comprueba ejecuciones completas como abrir un fichero, hacer algún cambio y guardarlo, comprueba que la línea de versiones se haya actualizado y finalmente cierra el fichero. Este caso se puede ver en la siguiente imagen. Figura 27 : Ejemplo de una ejecución completa de un test e2e. Elaboración propia pág. 85 Los tests unitarios están incorporados dentro de Angular. Al ejecutar ng test se abre una instancia de Karma test runner [62] y con la información de los ficheros Angular .spec pasa los tests. Los ficheros .spec contienen una instancia del componente que se está testeando con funciones definidas de la siguiente manera: - it(`frase_del_test`, () => { código_del_test } En este caso las comprobaciones que hacen los test están relacionadas con la funcionalidad del componente que se está testeando, para que las funciones que se testean se ejecuten correctamente. Por ejemplo, si el componente tiene una función que cambia el nombre del fichero del editor, se mira el nombre del fichero antes y después de ejecutar la función que se quiere testear, y finalmente se comprueba que se haya modificado correctamente. La cantidad de tests unitarios es algo menor de lo esperado dado que se han desarrollado muchas funcionalidades y no ha dado tiempo a comprobar cada función individualmente, solo las que se han considerado más importantes. A continuación, hay una imagen con el test explicado anteriormente Figura 28 : Ejemplo de un test unitario. Elaboración propia Estos tests son totalmente reproducibles. El test unitario tiene que estar siempre que se programe en ejecución para asegurar que nada de lo añadido puede hacer que lo existente falle y el test e2e se ha de pasar al menos una vez antes de pág. 86 guardar los cambios en la rama master para comprobar que el componente programado actúa como es debido con el resto de la aplicación. Para pasar los tests e2e primero hay que ejecutar yarn run start-local, que prepara la aplicación web, y luego yarn run e2e-over-running, que pasa los tests. En el caso de los unitarios hay que ejecutar yarn run test. Para el último tipo de prueba el estudiante hizo una pequeña exposición de todo lo implementado al departamento de GiD, esta reunión se hizo por las mismas fechas que la reunión de seguimiento con la ponente del trabajo. Fue una reunión muy constructiva en la que salieron muchas ideas nuevas y posibles mejoras de elementos actuales. Pero este tema se comentará en el apartado de Acciones futuras y se verá más adelante. Una vez expuesto el contenido y una breve explicación de cómo se han implementado las funcionalidades, todos los miembros del departamento han tenido acceso al proyecto para poder descargarlo y ejecutarlo en sus máquinas. De esta manera han podido probarlo y dar su opinión de usabilidad y funcionamiento. Los tres tipos de pruebas han reportado algún que otro error. En el momento en que esto pasa, se detiene la programación de tests nuevos y se crea una tarea de tipo bug. Se soluciona el error lo antes posible para continuar testeando. pág. 87 9. Estado final y desviaciones A continuación, se hará un breve recordatorio de los objetivos y los requisitos relacionados con cada objetivo, y se evaluarán para corroborar que se han alcanzado los objetivos propuestos y que el proyecto realmente resuelve el problema planteado. También se explicarán los cálculos de las desviaciones que se han tenido en cuenta durante todo el proyecto para verificar que no se ha sobrepasado el presupuesto inicial. 9.1. Cumplimiento de los objetivos 9.1.1. Resumen de los requisitos del proyecto Como se ha comentado en el aparatado de objetivos, se considera que el trabajo ha terminado cuando un usuario es capaz de navegar por la aplicación, seleccionar el Editor y escribir el código, ejecutarlo y visualizar las versiones anteriores. Los requisitos principales que ha de cumplir el editor para que se considere funcional y terminado son los siguientes: 1) El usuario puede escribir código en un área editable. 2) Se pueden realizar funciones básicas de los editores como rehacer y deshacer lo que se ha escrito. 3) El editor tiene ayudas de autocompletado. 4) El editor permite crear ficheros nuevos. 5) El editor permite visualizar el código de ficheros que se han guardado anteriormente. 6) El editor permite guardar cambios y guardar como nuevo fichero. 7) El editor permite cerrar un fichero. 8) El editor permite borrar un fichero. pág. 88 Los requisitos para cumplir el objetivo de poder controlar las versiones son los siguientes: 1) El usuario ha de poder ver un listado con las modificaciones anteriores de ese fichero. 2) El usuario puede comparar el código de una versión con el código actual. El último objetivo es tener un apartado para ejecutar el código, y se considera terminado cuando cumpla los siguientes requisitos: 1) El usuario puede ver la ejecución de su código. 2) El usuario puede interactuar con la ejecución del código. 3) Se detectan los errores en el código. 4) Los errores y mensajes de ayuda se muestran en un terminal. Estos han sido los requisitos funcionales relacionados con un objetivo concreto, pero no hay que olvidar los requisitos no funcionales, que se nombran a continuación: 1) Las implementaciones del trabajo se han de integrar bien con la parte de la aplicación web que está creada. 2) La aplicación ha de ser eficiente. 3) El usuario encuentra sencillo y cómodo el manejo de la aplicación. 4) Los componentes creados son modulares y se pueden reutilizar en otras partes de la aplicación. 9.1.2. Evaluación del cumplimiento de los requisitos Una vez recordados todos los requisitos es el momento de evaluarlos uno a uno para determinar si el proyecto resuelve el problema planteado inicialmente. Se empieza por evaluar el objetivo del editor, se corrobora que se han desarrollado todas las funcionalidades y que han pasado los tests. El requisito 1) El usuario puede escribir código en un área editable está implementado y explicado en el apartado 8.3.2. Área editable, también se ha pág. 89 comprobado su funcionamiento dentro de un test e2e. Por lo tanto, podemos decir que este requisito se cumple satisfactoriamente. El siguiente es 2) Se pueden realizar funciones básicas de los editores como rehacer y deshacer. Esta funcionalidad ya estaba incorporada con el editor y solo se ha tenido que activar. Como también pasa el test, consideramos que el requisito ha sido cumplido. El requisito 3) El editor tiene ayudas de autocompletado, se ha explicado en el apartado 8.3.4. Autocompletado, se comprueba como parte de un test e2e y con eso se puede ver que también se cumple. Los requisitos 4) El editor permite crear ficheros nuevos, 5) El editor permite visualizar el código de ficheros que se han guardado anteriormente, 6) El editor permite guardar cambios y guardar como nuevo, 7) El editor permite cerrar un fichero y 8) El editor permite borrar un fichero, han sido explicados en los apartados 8.5.1. Botón New, 8.5.2. Botón Open, 8.5.3. Botón Save y 8.5.4. Botón Save As, 8.5.5. Botón Close y 8.5.6. Botón Delete respectivamente. Se han ejecutado tests e2e para comprobar el funcionamiento. Con todos los requisitos cumplidos podemos decir que el objetivo del que hablamos se cumple satisfactoriamente, por tanto el proyecto ha superado el objetivo del editor. Para comprobar que se cumple el objetivo de poder controlar las versiones, hay que valorar dos requisitos. El primero es 1) El usuario ha de poder ver un listado con las modificaciones anteriores de ese fichero y la aplicación se lo ha de permitir. El desarrollo ya ha sido explicado en los apartados 8.4. Creación de una línea temporal y en 8.5.2. Botón Open. Los tests comprueban que cuando se abre un fichero aparece la línea temporal y que al ser guardado se actualiza, por lo que daremos este requisito por cumplido y finalizado. El segundo requisito es 2) El usuario puede comparar el código de una versión con el código actual, gracias al apartado 8.5.7. Petición del código de un commit vemos que la aplicación permite obtener el código de una versión pág. 96 Ahora se calculará la desviación total en la relación de tareas: ( F𝑪𝒐𝒔𝒕𝒆𝑬𝒔𝒕𝒊𝒎𝒂𝒅𝒐𝑻𝒐𝒕𝒂𝒍−𝑪𝒐𝒔𝒕𝒆𝑹𝒆𝒂𝒍𝑻𝒐𝒕𝒂𝒍F ) = ( 𝟏𝟒.𝟎𝟓𝟗 € F−F𝟏𝟓.𝟔𝟏𝟗 € ) = −F𝟏.𝟓𝟔𝟎 € F F Y el desvío total de horas F ( F𝑯𝒐𝒓𝒂𝒔𝑬𝒔𝒕𝒊𝒎𝒂𝒅𝒂𝒔−𝑯𝒐𝒓𝒂𝒔𝑹𝒆𝒂𝒍𝒆𝒔F ) = ( F𝟔𝟎𝟐𝑯F−𝟔𝟕𝟕𝑯F ) = −F𝟕𝟓𝑯F F 9.2.2. Desviaciones del presupuesto En el apartado anterior se han visto diferentes cambios en las extensiones de las tareas de desarrollo, esto se ha visto reflejado en las diferentes desviaciones temporales que han provocado desviaciones en el coste del proyecto. A continuación se calculará el coste final del trabajo teniendo en cuenta las desviaciones anteriores y las desencadenadas con respecto a los recursos, imprevistos, electricidad y contingencia. Costes de personal El coste del personal ha incrementado en 1.560€ al utilizar el tiempo extra de desarrollo dado que los roles de programadores han invertido más horas en esas tareas. El coste de personal asciende a un total de 15.619€ Costes genéricos Los costes genéricos también han cambiado dado que dependen de las horas totales de uso. En este apartado se utilizará la desviación total de recursos con la siguiente formula: ( F𝑪𝒐𝒔𝒕𝒆𝑬𝒔𝒕𝒊𝒎𝒂𝒅𝒐𝑻𝒐𝒕𝒂𝒍−𝑪𝒐𝒔𝒕𝒆𝑹𝒆𝒂𝒍𝑻𝒐𝒕𝒂𝒍F ) pág. 97 Al principio del trabajo también se consideró importante tener una desviación propia de la electricidad dado que al empezar el trabajo el precio de la luz aumentaba constantemente, la formula utilizada es la siguiente: ( F𝑪𝒐𝒔𝒕𝒆𝑬𝒔𝒕𝒊𝒎𝒂𝒅𝒐𝑬𝒍𝒆𝒄𝒕𝒓𝒊𝒄𝒊𝒅𝒂𝒅−𝑪𝒐𝒔𝒕𝒆𝑹𝒆𝒂𝒍𝑬𝒍𝒆𝒄𝒕𝒓𝒊𝒄𝒊𝒅𝒂𝒅F ) Se empezará por recalcular la amortización del Hardware dado que las horas de uso del ordenador de sobremesa han aumentado, las del portátil siguen siendo las mismas. 𝑪𝒐𝒔𝒕𝒆𝑫𝒊𝒔𝒑𝒐𝒔𝒊𝒕𝒊𝒗𝒐 ( € ) ∗𝑯𝒐𝒓𝒂𝒔𝑼𝒔𝒐(𝒉𝒐𝒓𝒂𝒔) 𝑽𝒊𝒅𝒂Ú𝒕𝒊𝒍 ( 𝒂ñ𝒐𝒔 ) ∗𝑫í𝒂𝒔𝑻𝒓𝒂𝒃𝒂𝒋𝒂𝒅𝒐𝒔 ( 𝒅𝒊𝒂𝒔/𝒂ñ𝒐 ) ∗𝑯𝒐𝒓𝒂𝒔𝑫𝒊𝒂𝒓𝒊𝒂𝒔(𝒉𝒐𝒓𝒂𝒔/𝒅𝒊𝒂)=F 𝟐.𝟎𝟎𝟎 ( € ) ∗(𝟒𝟐𝟎 ( 𝒉𝒐𝒓𝒂𝒔 ) +𝟕𝟓 ( 𝒉𝒐𝒓𝒂𝒔 ) ) 𝟒 ( 𝒂ñ𝒐𝒔 ) ∗𝟐𝟑𝟔 W 𝒅𝒊𝒂𝒔 𝒂ñ𝒐 X ∗𝟓 W 𝒉𝒐𝒓𝒂𝒔 𝒅𝒊𝒂 X =𝟐𝟏𝟎€ El coste inicial de la amortización del ordenador de sobremesa era de 178€, si le restamos los 210€ de la desviación actual, el resultado es una amortización de 32€ más. Los costes relacionados con el software seguirán siendo los mismos. Los cálculos se han hecho por precio mensual y como no se ha aumentado el numero de meses del trabajo ese precio no varía. Los últimos costes que se han de tener en cuenta son los relacionados con el alquiler, internet y electricidad. El alquiler y el coste de internet tampoco han variado dado que el numero de meses del trabajo no ha aumentado. El coste final de la electricidad ha aumentado por dos razones. Por una parte el número de horas de uso de ordenador ha sido mayor y por otra parte, el coste del pág. 98 kWh que se utilizó al principio como valor de electricidad media era de 0.27592€/kWh y a lo largo del trabajo se ha detectado un valor medio máximo de 0.49195€/kWh. Para los cálculos actualizados se ha hecho una media de los dos valores y se ha utilizado 0.383935€/kWh. El coste final no será de 27,3€ sino que se incrementa en 16,91€. La siguiente tabla muestra los precios actualizados. Otros Potencia Unidades Horas Consumo Coste Monitor 40W 1 495h 19,8kWh 7,61€ Ordenador uso 180W 1 495h 89,1kWh 34,21€ Ordenador apagado 4W 1 182h 0,73kWh 0,29€ Portátil 30W 1 182h 5,46kWh 2,10€ Total - - - - 44,21€ Tabla 10 : Costes de energía actualizados. Elaboración propia Una vez se tienen todos los costes actualizados, se suman los costes del Hardware, Software y Otros que dan un valor de 1.315,71€ que redondeado son 1.316€. Esta cantidad es la que se utilizará en el cálculo de las desviaciones. La deviación total de recursos: ( F𝑪𝒐𝒔𝒕𝒆𝑬𝒔𝒕𝒊𝒎𝒂𝒅𝒐𝑻𝒐𝒕𝒂𝒍−𝑪𝒐𝒔𝒕𝒆𝑹𝒆𝒂𝒍𝑻𝒐𝒕𝒂𝒍F ) = 𝟏.𝟐𝟔𝟕 € −𝟏.𝟑𝟏𝟔 € =F−𝟒𝟗 Como el precio de la electricidad ha subido en parte porque se ha hecho un poco más de gasto del esperado y el otro motivo es porque ha subido el precio, a continuación se puede ver el cálculo de la desviación: ( F𝑪𝒐𝒔𝒕𝒆𝑬𝒔𝒕𝒊𝒎𝒂𝒅𝒐𝑬𝒍𝒆𝒄𝒕𝒓𝒊𝒄𝒊𝒅𝒂𝒅−𝑪𝒐𝒔𝒕𝒆𝑹𝒆𝒂𝒍𝑬𝒍𝒆𝒄𝒕𝒓𝒊𝒄𝒊𝒅𝒂𝒅F ) = 𝟐𝟕,𝟑 € −𝟒𝟒,𝟐𝟏 € =F−𝟏𝟔,𝟗𝟏 € pág. 99 Los costes genéricos han aumentado 49€ Contingencia La contingencia tenía en cuenta posibles imprevistos como el aumento de personal o algunos costes generales. El aumento de personal en situaciones reales se puede causar si algún miembro del equipo necesita la baja y se ha de cubrir esa plaza contratando a otra persona. Como este proyecto solo lo realiza el estudiante, este caso no se dará y no será necesario utilizar el dinero. ( F𝑪𝒐𝒔𝒕𝒆𝑬𝒔𝒕𝒊𝒎𝒂𝒅𝒐𝑪𝒐𝒏𝒕𝒊𝒏𝒈𝒆𝒏𝒄𝒊𝒂−𝑪𝒐𝒔𝒕𝒆𝑹𝒆𝒂𝒍𝑪𝒐𝒏𝒕𝒊𝒏𝒈𝒆𝒏𝒄𝒊𝒂F ) = ( F𝟐.𝟗𝟑𝟗 € F−𝟎 € ) = F𝟐.𝟗𝟑𝟗 € F Imprevistos Los imprevistos tienen en cuenta los riesgos que se identificaron al principio del proyecto como el aumento de tiempo en algunas tareas o la necesidad de adquirir un nuevo ordenador para trabajar. Finalmente se ha aumentado el coste del personal resultando un total de 1.560€, y el coste general con un resultado de 49€. Por otra parte, no ha sido necesario adquirir ningún dispositivo nuevo. ( F𝑪𝒐𝒔𝒕𝒆𝑬𝒔𝒕𝒊𝒎𝒂𝒅𝒐𝑰𝒎𝒑𝒓𝒆𝒗𝒊𝒔𝒕𝒐𝒔−𝑪𝒐𝒔𝒕𝒆𝑹𝒆𝒂𝒍𝑰𝒎𝒑𝒓𝒆𝒗𝒊𝒔𝒕𝒐𝒔F ) = ( F𝟏.𝟐𝟔𝟏 € F−𝟏.𝟔𝟎𝟗 € ) =F−𝟑𝟒𝟖 € F Esto quiere decir que los gastos finales han aumentado, superando la previsión inicial de imprevistos en 348€, pero como de contingencia no se ha gastado nada, no se supera el cálculo de presupuesto inicial. Esto se puede ver en el siguiente apartado. pág. 100 Coste total Para calcular el presupuesto final se tiene en cuenta los costes genéricos y de personal, la contingencia y imprevistos solo forman parte del presupuesto inicial. En la siguiente tabla se puede apreciar el coste final. Descripción Coste Coste del personal 15.619€ Coste genérico 1.316€ Presupuesto Final 16.935€ Tabla 11 : Coste final del proyecto. Elaboración propia En la planificación inicial se estimaron unos 19.526€ ( F𝑪𝒐𝒔𝒕𝒆𝑬𝒔𝒕𝒊𝒎𝒂𝒅𝒐−𝑪𝒐𝒔𝒕𝒆𝑹𝒆𝒂𝒍F ) = ( 𝟏𝟗.𝟓𝟐𝟔 € F−𝟏𝟔.𝟗𝟑𝟓 € F ) = 𝟐.𝟓𝟗𝟏 € Eso quiere decir que al dar una desviación positiva no nos hemos pasado del presupuesto inicial. Finalmente, el coste total del proyecto es de 16.935€ pág. 101 10. Informe de sostenibilidad Una parte que no se puede tomar a la ligera es el análisis de sostenibilidad, este análisis se hará teniendo en cuanta tres dimensiones, la ambiental, la económica y la social. Pero antes de empezar a profundizar en cada una de las dimensiones por separado, se hará una autoevaluación por parte del estudiante. 10.1. Dimensión ambiental En este apartado se tratará la dimensión Ambiental desde tres puntos de vista: el proyecto en producción, vida útil del proyecto y los riesgos. Durante la puesta en producción se ha planteado el impacto ambiental que conlleva la realización del proyecto. Se puede decir que no es demasiado grande. Los factores que hacen que el proyecto impacte negativamente en el medio ambiente durante su creación son los ordenadores que se utilizarán y el servidor de la empresa en el que está Instalado GitLab. Al final del trabajo el consumo eléctrico relacionado con los aparatos eléctricos ha sido de 115,09 kW. Si se tiene en cuenta que el consumo de electricidad de una persona en el despacho es de 0.40kWh 15 y que, sin contar las horas de documentación, se pasarán 517 horas en el despacho, el consumo del despacho será 206,8 kWh. Finalmente, el consumo de electricidad de este trabajo ha sido de aproximadamente 322kW. A pesar de que el impacto ambiental no sea muy elevado, se busca una manera de reducirlo un poco más y en este proceso se decidió utilizar ordenadores que la empresa y el estudiante ya tenían, es decir no comprar ningún material hardware 15 El consumo de una persona anual es de 3.487,00kWh/año. Si el año tiene 365 días y los días 24 horas, cada persona gasta un total de 0.40 kWh. [63] pág. 102 especifico para el proyecto. De esta manera el coste ambiental de fabricación queda amortizado en diferentes proyectos. Algo parecido pasa con la huella ecológica respecto a la electricidad. Dado que en el mismo despacho se realizan diferentes proyectos, este repartirá la huella ecológica en los diferentes proyectos. Si se pensara en hacer el proyecto de nuevo y se rehiciera un estudio de sostenibilidad para minimizar el impacto medioambiental, resultaría muy similar a este, porque para hacer el proyecto se necesita un ordenador y el consumo eléctrico básico de una persona. Eso quiere decir que si no se pueden recortar recursos por ningún lado no es posible disminuir más el impacto ambiental. También hay que tener en cuenta como afectará el proyecto durante su vida útil al medioambiente. Los recursos que se utilizarán en la vida útil y el impacto medioambiental del proyecto seguirán siendo los mismos que han resultado en la producción. Se necesitará un ordenador para mantener la aplicación actualizada con las nuevas tecnologías y seguramente también surgirán pequeños errores que detecten los usuarios, los cuales tendrán que solucionarse lo antes posible. Para que la aplicación siga resultando atractiva, a medida que pase el tiempo se tendrán que añadir funcionalidades nuevas, para esto también se necesitará el ordenador con su consumo de electricidad correspondiente. Además, este proyecto permitirá reducir el uso de otros recursos, actualmente se utiliza el programa de escritorio de GiD en diferentes ordenadores. Al migrar el programa a una aplicación web para que los usuarios sean capaces de utilizarlo desde donde deseen, a la larga se puede considerar como una mejora ambiental, dado que, al no necesitar ningún software específico, ni librerías concretas, hace que sea más fácil poder trabajar en diferentes dispositivos y se elimina la necesidad de comprar un ordenador personal, reduciendo el número total de este recurso. Incluso se podría acceder desde los centros cívicos que proporcionan acceso libre a ordenadores y de esta manera se puede reducir la contaminación que se produce pág. 103 al fabricar un nuevo ordenador y los residuos que genera una vez termina la vida útil del mismo. Algunos de los riesgos a los que se enfrenta el trabajo con respecto a la huella ecológica son que se estropee el ordenador y se tenga que comprar otro. Con respecto al coste ambiental de fabricación no quedaría amortizado en diferentes proyectos, sino que se consumiría más en la fabricación de uno nuevo. Otro escenario muy perjudicial sería que la solución escogida al final no resultara la mejor o no funcionara. Esto aumentaría el número de horas de trabajo y con ello el consumo de energía, casi como si se hiciera el trabajo de nuevo. 10.2. Dimensión económica Antes de empezar el proyecto se ha estimado el coste de su realización tanto en recursos humanos como en materiales. Esto se puede observar en el apartado 5. Presupuesto donde se detalla con claridad cada uno de los costes e incluso se tienen en cuenta los imprevistos y un plan de contingencia. Se ha intentado seguir al máximo esta planificación para que no aumente el coste del proyecto. Al finalizar el proyecto se han revisado estos costes actualizando las horas por tarea y de uso de los recursos. Gracias a las desviaciones del apartado 9.2. Desviaciones del proyecto se ha visto que los recursos de personal han aumentado en 1.560€ y los costes genéricos han aumentado en 49€, como consecuencia de tener que dedicar más tiempo a ciertas tareas de desarrollo. Al contar con una partida para contingencias e imprevistos, estos gastos no han supuesto un problema. Se estimó un coste de 19.526€ para realizar el trabajo y finalmente con los incrementos comentados ha resultado un total aproximado de 16.935€, por lo que el trabajo final ha resultado menor respecto al coste del estimado y el dinero restante se puede ahorrar para otros trabajos. Se considera que el coste es adecuado con respecto a los beneficios que se pueden obtener con las licencias del producto y sería complicado reducir los costes porque pág. 104 a simple vista no se aprecia ningún sobrecoste, si bien es cierto que se ha intentado ser precavidos en el apartado de imprevistos y se ha asumido un porcentaje algo mayor para evitar pasarse del presupuesto, cosa que ha resultado muy útil porque al final se ha necesitado parte del dinero de imprevistos y contingencias. El coste final es razonable para un proyecto de esta magnitud. Durante la vida útil del proyecto se considera que su mantenimiento no será muy costoso dado que se ha creado con lenguajes de programación y herramientas modernas. Si algún día se quieren añadir nuevas funcionalidades tampoco será demasiado costosa la adaptación a las bases del proyecto, dado que se ha intentado modularizar cada componente para que sea simple cambiarlo por uno nuevo o simplemente añadir más. Todas estas tareas las puede realizar un programador, con una retribución de 20,80€/h y un ordenador como el que se ha utilizado, por lo tanto, no se prevé un aumento de los costes. No se puede minimizar más el coste dado que el ordenador y una persona que haga el mantenimiento, actualizaciones y ajustes dentro de la aplicación son esenciales para que los usuarios sientan que hay un servicio técnico detrás que soluciona los posibles problemas que vayan surgiendo. Al ser un proyecto para una empresa concreta, los riesgos que se pueden correr están relacionados con la posible anulación de los fondos que financien el proyecto, ya que si estos dejasen de existir todo lo realizado, seria difícil o sencillamente no podría implementarse en otro posible proyecto. 10.3. Dimensión social A nivel social se diferenciará lo que ha aportado la realización del proyecto al estudiante y lo que aportará el proyecto finalizado a la sociedad. A nivel del estudiante este proyecto ha sido una gran oportunidad para adquirir diferentes tipos de conocimientos. Se clasifican entre conocimientos técnicos y no pág. 105 técnicos. Dentro del área técnica, el estudiante ha aprendido nuevos lenguajes de programación y el entorno en el que se ha programado, además de poder profundizar en áreas que no se han tocado tanto dentro de la especialidad de Computación. Los conocimientos no técnicos que ha aportado este proyecto son las capacidades de trabajo en equipo y organización, además de ofrecer la oportunidad de una primera experiencia laboral dentro de una empresa y poder ver el funcionamiento y manera de trabajar. Una vez la aplicación esté finalizada, intentará cubrir la necesidad que ha surgido últimamente de poder trabajar desde cualquier lugar, sin necesidad de tener un software específico, solo con el acceso a internet. Esto no era una necesidad anteriormente, pero con la aparición de la COVID19, lo que antes parecía no ser una necesidad real ahora cada vez resulta más necesario, hasta el punto que se está evolucionando en esa dirección con respecto al trabajo. Esto ha generado que la empresa de CIMNE decidiese migrar una de sus aplicaciones a formato web. Con esta migración se espera que la nueva aplicación tenga todas las funcionalidades que tenía la anterior y se ha intentado replantear alguna de las funcionalidades existentes para que con las nuevas tecnologías resulte más fácil de utilizar por los usuarios. A nivel social se quiere mejorar la comunicación a la hora de trabajar permitiendo compartir los ProblemTypes entre usuarios e incluso a largo plazo permitirá que los usuarios sean capaces de trabajar en el mismo ProblemType a la vez con la gestión de versiones. Por tanto este proyecto beneficia el área de las simulaciones numéricas y con ello a los estudiantes, ingenieros y científicos que terminen utilizando la aplicación. Si la aplicación tiene mucho éxito podría perjudicar un poco a otras empresas similares a CIMNE. En cualquier caso, el grado en que les puede perjudicar no es muy elevado si desarrollan un solver que se pueda integrar en el programa de GiD, incluso les puede resultar útil proporcionando más herramientas a sus cálculos. pág. 112 11.3. Integración de conocimientos A lo largo de la carrera se imparten conocimientos de diferentes áreas, en concreto este trabajo se centra en la especialidad de computación por lo que las asignaturas de esta modalidad han sido especialmente útiles. Pero se ha intentado poner en práctica el máximo de aprendizajes adquiridos. Gracias a esto el estudiante ha profundizado en usos de estos conocimientos más específicos en el mundo real. Dado que este proyecto es de creación, hay que tener en cuenta que todos los conocimientos adquiridos con relación a la programación han sido esenciales para poder implementar la aplicación. Las asignaturas de PRO1 y PRO2 16 , EDA 17 , LI 18 y A 19 han influido en la manera en la que se afrontan los problemas dando paso a una mente más lógica y analítica. También han proporcionado la base respecto a la programación dirigida a objetos, las dependencias entre ellos, los tipados, los cálculos de costes, la eficiencia de algoritmos, etc. Una asignatura que entraría dentro del grupo anterior, pero de la que quiero hacer mención especial, es la de LP 20 . Gracias a esta asignatura y a la competencia de aprendizaje autónomo he sido capaz de adaptarme a un framework y a lenguajes totalmente nuevos para mi y estos conocimientos me dan la seguridad necesaria para poder enfrentarme a cualquier reto en el futuro. Otras asignaturas que han resultado útiles a lo largo del proyecto han sido BD 21 que me han permitido entender las estructuras de almacenamiento a la hora de 16 Asignatura de programación uno y dos 17 Asignatura de datos y algoritmos 18 Asignatura de lógica en la informática 19 Asignatura de algorítmica 20 Asignatura de lenguaje de programación 21 Asignatura de bases de datos pág. 113 conectar la aplicación con GitLab, los conocimientos aprendidos en TC 22 que han facilitado el uso de expresiones regulares para evaluar contenido del editor y la asignatura de PAR 23 que ha proporcionado las bases para entender y utilizar herramientas que trabajaran en segundo plano y threads secundarios. Toda aplicación ha de ser llamativa para los usuarios, pero a la vez fácil de utilizar e intuitiva. Para poder darle al usuario una mejor experiencia a la hora de utilizar la aplicación, se han puesto en práctica todos los conocimientos de usabilidad que se han impartido en las asignaturas de G 24 y de IDI 25 . No solo hay que centrarse en los conocimientos técnicos. Durante la carrera también se han enseñado aptitudes de comunicación eficaz y escrita que junto con asignaturas como IES 26 me han proporcionado herramientas para entender, dejar documentado y compartir con mis compañeros del trabajo el flujo de datos y las implementaciones hechas dentro de la aplicación. Y asignaturas como GEOC 27 , DCS 28 , G y VC 29 me han ayudado a acercarme más al mundo que trata el departamento de GiD con geometrías, mallados y simulaciones. A lo largo de este proyecto el estudiante se ha enfrentado a problemas del día a día que tienen las grandes empresas, pero nunca lo había vivido en su propia piel. Un claro ejemplo es la parte económica, hacer un presupuesto. Para este apartado han sido de gran ayuda los conocimientos proporcionados por las asignaturas de 22 Asignatura de teoría de la computación 23 Asignatura de paralelismo 24 Asignatura de gráficos 25 Asignatura de interacción y diseño de interfaces 26 Asignatura de introducción a la ingeniería del software 27 Asignatura de geometría computacional 28 Asignatura de diseño de curvas y superficies 29 Asignatura de visión por computador pág. 114 PE 30 y también EEE 31 . Otro ejemplo es la gestión de un proyecto de esta magnitud, que gracias a la asignatura de PROP 32 , en la que se hace una pequeña práctica a menor escala, pero que ha resultado muy útil para enfrentarse a un proyecto real. Por último, todo y que no menos importante, se tiene que destacar especialmente la asignatura de AC 33 y las asignaturas obligatorias del departamento de computadores que han aportado la concienciación necesaria con respecto al medio ambiente y sostenibilidad que toda persona tendría que tener para su día a día. No solo se ha enseñado ese valor que considero muy importante, sino que también he aprendido a trabajar en equipo y tener una buena actitud frente al trabajo. Esto me ha sido muy útil en el poco tiempo que llevo en el mundo laboral y estoy segura de que en futuras ocasiones me resultará más provechoso. Todo lo explicado anteriormente me ha proporcionado el conocimiento necesario para adquirir un criterio propio a la hora de tomar decisiones y conseguir hacerlo de manera efectiva y creativa aportando soluciones con las que ser capaz de resolver perfectamente los problemas planteados. 11.4. Identificación de leyes y regulaciones En este apartado se hablará de las diferentes leyes a las que el proyecto va ligado. Este proyecto es una parte de una aplicación web, por lo que nos centraremos en las leyes que toda página web debe cumplir. Antes de utilizar cualquier aplicación web el usuario debe registrarse introduciendo unos datos personales y de contacto. En este momento la ley establece que la 30 Asignatura de probabilidad y estadística 31 Asignatura de empresa y entorno económico 32 Asignatura de proyecto de programación 33 Asignatura de arquitectura de computadores pág. 115 aplicación ha de informar al usuario de los Términos y Condiciones de uso, que los tiene que aceptar para poder finalizar el registro como un nuevo usuario. El documento de términos y condiciones de uso regula la relación con el usuario respecto al acceso de los contenidos y de los servicios que se ponen a su disposición mediante la aplicación web. Esto sirve para establecer cuáles son las responsabilidades legales, tanto de la empresa que proporciona la aplicación, cómo del usuario que la está utilizando. La aplicación web a la que pertenece el proyecto que estamos desarrollando está en proceso, pero los usuarios tendrán que registrarse para utilizar los diferentes servicios que proporciona el departamento de GiD. Como ya hay servicios que hoy en día están activos, se están utilizando y contienen datos de usuarios ya existentes, el apartado de registros contiene un documento de Términos y Condiciones de uso que se muestra al usuario para que lo lea y lo acepte antes de registrarse y dar información personal. Dado que el registro es el mismo para todos los servicios, se puede decir que el proyecto cumple esta normativa, quizás antes de comercializarlo o ponerlo en producción se tendría que repasar este documento y añadir alguna cláusula un poco más específica. El documento mencionado anteriormente contiene información de la empresa, condiciones particulares de uso, las obligaciones que tiene la empresa y el cliente, responsabilidades y limitaciones, los derechos de propiedad intelectual e industrial, tratamiento de datos de carácter personal y política de confidencialidad, derechos de acceso, rectificación, cancelación, oposición, suspensión, limitación del tratamiento y portabilidad de los datos, duración y modificación del servicio, legislaciones aplicables y tribunales competentes, garantía, modificaciones del servicio, variaciones de las condiciones, resolución alternativa de conflictos y uso de cookies. A este proyecto le afecta especialmente la Política de Privacidad, dado que en la aplicación web se almacenarán datos de los usuarios. Estos datos se tratarán cómo pág. 116 indica el Reglamento (UE) 2016/679 del Parlamento Europeo y del Consejo, de 27 de abril de 2016 [64], relativo a la protección de las personas físicas en lo que respecta al tratamiento de datos personales y a la libre circulación de estos datos para abreviar RGPD, la Ley Orgánica 3/2018, de 5 de diciembre [65], de Protección de Datos Personales y garantía de los derechos digitales. En un futuro también le afectará la Política de Cookies, ya que se utilizarán las cookies propias teniendo como finalidad el acceso y entrada del usuario, la autenticación o identificación del usuario a la hora de iniciar sesión, así como la seguridad del usuario a la hora de utilizar la aplicación. 11.5. Competencias técnicas En este apartado se hablará de las competencias técnicas asociadas a él y en que grado se han tratado. CCO1.1: Evaluar la complejidad computacional de un problema, conocer estrategias algorítmicas que puedan llevar a su resolución, y recomendar, desarrollar e implementar la que garantice el mejor rendimiento de acuerdo con los requisitos establecidos. (Un poco) Para resolver todo problema, antes de empezar a programar hay que hacer un estudio en el que se evalúen las posibles implementaciones y los costes de cada una. Para este trabajo, las posibles soluciones tenían mas o menos el mismo coste, excepto las soluciones que exigían implementar el componente desde cero, que se descartaron rápidamente por falta de tiempo. El resto de las soluciones eran muy parecidas con respecto a los costes, por este motivo la competencia se trata un poco. Dentro de las implementaciones que se han tenido que desarrollar, se ha intentado programar la menos costosa si había más de una manera. Un buen ejemplo de eso puede ser la actualización del pág. 117 componente editor. Dado que hay tres componentes que tienen que estar siempre actualizados, se ha decidido que se actualice el editor al que se quiere acceder cuando se cambia de pestaña y no actualizar los tres cada vez que se cambia la información del actual. Con respecto al código, se ha intentado parar los ciclos de búsqueda una vez se encuentra el componente, en lugar de recorrer todos los elementos. Son pequeñas estrategias que a la larga favorecen el rendimiento de la aplicación. CCO1.2: Demostrar conocimiento de los fundamentos teóricos de los lenguajes de programación y las técnicas de procesamiento léxico, sintáctico y semántico asociadas, y saber aplicarlas para la creación, diseño y procesamiento de lenguajes. (Un poco) El editor creado ejecuta el código del usuario que está escrito en un sublenguaje formado por JavaScript y unas clases específicas, implementadas por el estudiante para que el usuario pueda crear componentes HTML. Mientras se ejecuta el código se detectan errores del propio lenguaje JavaScript, pero también de estas clases específicas que proporcionamos, para ello se ha utilizado parte del conocimiento relacionado con los fundamentos teóricos de los lenguajes. No se ha hecho un parser de un compilador, ni mucho menos, pero en cierta manera la idea que está detrás es similar. El usuario utiliza estas clases, que equivaldrían a la entrada de un parser para transformarlas en objetos del estilo JSON, y finalmente el componente de Angular los transforma en otros objetos Angular, los cuales harán posible la visualización de los componentes HTML por la pantalla. También se han utilizado estos conocimientos teóricos de los lenguajes para autocompletar expresiones y funciones más específicas de nuestro sublenguaje que no detectaría JavaScript, para ello se han utilizado expresiones regulares. Por todo lo expuesto anteriormente se considera que se ha trabajado un poco esta competencia. pág. 118 CCO1.3: Definir, evaluar y seleccionar plataformas de desarrollo y producción de hardware y software para el desarrollo de aplicaciones y servicios informáticos de diversa complejidad. (En profundidad) Algunas de estas plataformas de desarrollo y producción de hardware y software ya han venido impuestas por la empresa. Por ejemplo, el uso de Git, Jira, Confluence, Jenkins, Slack, el framework de Angular y los lenguajes de programación de JavaScript y TypeScript. Pero no hay que olvidar que el trabajo realzado en si, es una plataforma de desarrollo y producción de software permitiendo crear funcionalidades para los ProblemTypes de GiD. Para poder realizar el proyecto se han tenido que evaluar diferentes plataformas de desarrollo y producción que irán integradas dentro de la aplicación. Es un claro ejemplo de los diferentes componentes de editores y que finalmente se ha decidido utilizar MonacoEditor. También se evaluaron diferentes plataformas para gestionar las versiones y los ficheros y, como explica el apartado de Solución propuesta, se decidió utilizar GitLab. Se considera que esta competencia se ha tratado en profundidad porque evaluar y seleccionar las plataformas de desarrollo y producción que más se adaptaban al tipo de proyecto ha sido una decisión esencial para la elaboración del mismo. CCO2.3: Desarrollar y evaluar sistemas interactivos y de presentación de información compleja, y su aplicación en la resolución de problemas de diseño de interacción persona computador. (En profundidad) Esta competencia se trata en profundidad dado que la mayoría de los objetivos principales la tratan. A lo largo del trabajo se ha desarrollado un apartado de la página web que consideramos un sistema interactivo para el usuario y que ha de encontrar familiar y fácil de usar. También hay un apartado que muestra la ejecución del código del fichero escogido. Esto se hace por medio de mostrar una pantalla con los componentes html de manera interactuables con todas las funcionalidades que el usuario ha programado. Además, también aparecen pequeños mensajes por un componente terminal que ayudan al usuario a detectar pág. 119 errores en su código. Se considera que toda esta información compleja se consigue mostrar de una manera intuitiva y solucionando el problema de interacción persona computador. CCO2.6: Diseñar e implementar aplicaciones gráficas, realidad virtual, realidad aumentada y videojuegos. (Bastante) En este proyecto se ha colaborado creando funcionalidades dentro de una aplicación web. Para realizar esto se ha tenido que diseñar el apartado del editor teniendo en cuenta la usabilidad y la comodidad de los usuarios y más adelante implementar las funcionalidades necesarias para cumplir los requisitos que la empresa ha exigido. Como al final del trabajo se ha diseñado e implementado una parte de una aplicación gráfica, se considera que se ha tratado bastante el objetivo. CCO3.1: Implementar código crítico siguiendo criterios de tiempo de ejecución, eficiencia y seguridad. (Bastante) Toda aplicación tendría que funcionar de manera rápida, eficiente y tratar los datos del usuario de manera segura. Esta aplicación no es una excepción, se ha trabajado generando un identificador único llamado token para que los ficheros del usuario solo los pueda ver él mismo. Respecto a la eficiencia y tiempo de ejecución se han intentado minimizar las peticiones http a GitLab. En los casos que las peticiones tienen que cargar muchos datos o buscar la información entre muchos ficheros, haciendo que la petición se resuelva de manera más lenta, se ha añadido un diálogo de texto informando al usuario. Se considera que durante el desarrollo se ha tenido en cuenta la ejecución, eficiencia y seguridad pero diremos que esta competencia se ha tratado bastante en vez de en profundidad, dado que algunas de las acciones futuras son para mejorar la eficiencia de la aplicación. pág. 120 11.6. Acciones futuras Una vez se ha comprobado que el proyecto resuelve el problema planteado se puede decir que ya se ha terminado el trabajo. Pero realmente este proyecto todavía tiene mucho recorrido. A nivel de lo que está implementado, se tendría que hacer un pequeño mantenimiento de la aplicación y, en el momento en que salga al mercado, estar preparados para solucionar pequeños bugs o errores que encuentren los usuarios, o simplemente hacer de soporte técnico para resolver dudas que les puedan surgir. Otra tarea importante es seguir investigando las tecnologías que puedan ir surgiendo, como se comentó al principio del proyecto. Con el paso del tiempo algunas de estas tecnologías pueden quedar desactualizadas y se necesitan remplazar o llevar a la versión más nueva. Para que esto pueda pasar hay que estar continuamente informado de las novedades del mercado, por si se encuentra un componente que se adapte mejor o simplemente actualizar las versiones de los ya existentes. De cara a seguir implementando funcionalidades y mejorar las existentes, se ha pensado en incorporar un buen sistema de paginación para ganar eficiencia a la hora de cargar los commits anteriores de un fichero para que el usuario no note que el proceso de abrir un fichero puede ser un poco lento. La idea principal es cargar los primeros 8 commits como máximo y a medida que el usuario bajara la barra de scroll hasta el final se cargarían los 8 commits siguientes. Otra de las mejoras propuestas es añadir más información al autocompletado, para que el usuario no necesite mirar documentaciones externas, simplemente escribiendo en el editor ya consigue todo lo que necesita saber. pág. 121 Además, se quiere que la aplicación se vea bien en todo tipo de monitores, tengan más o menos pulgadas y en un futuro también se quiere pasar a aplicación móvil. Se ha pensado en añadir dentro del editor un “eslint” o “linting”, que es una herramienta de análisis de código y se considera que de esta manera se conseguirán encontrar mejor los errores antes de que el usuario presione el botón de ejecutar. En este mismo ámbito se quiere añadir la opción de que al pasar el ratón por encima de un error la aplicación te muestre también las posibles soluciones al error. Pero para este último caso se tendrán que estudiar las posibles maneras de implementarlo. La última mejora que se quiere hacer es añadir ayudas para la depuración de código. Actualmente permite ejecutarlo y ver los errores, pero en un futuro se quieren añadir puntos de parada y poder visualizar el valor de las variables en cada momento. Esto también requiere un pequeño estudio de las diferentes maneras de implementación. Estas han sido algunas de las mejoras que han surgido a lo largo del trabajo, por lo que se puede decir que todavía hay mucho margen de ampliación para el proyecto. pág. 128 13. Anexo A Diagrama de Gantt inicial Figura 29 : Primera parte del Diagrama de Gantt inicial. Elaboración propia pág. 129 Figura 30 : Segunda parte del Diagrama de Gantt inicial. Elaboración propia pág. 130 Figura 31 : Tercera parte del Diagrama de Gantt inicial. Elaboración propia. pág. 131 Diagrama de Gantt final Figura 32 : Primera parte del diagrama de Gantt final. Elaboración propia pág. 132 Figura 33 : Segunda parte del diagrama de Gantt final. Elaboración propia pág. 133 Figura 34 : Tercera parte del diagrama de Gantt final. Elaboración propia pág. 134 14. Anexo B Manual Este apartado es una pequeña guía para poder utilizar la parte del editor y programar alguna funcionalidad. Como en toda aplicación lo primero es introducir el usuario y contraseña, una vez registrado, la aplicación te llevará a la página principal de modelos. Para llegar al editor hay que entrar en el menú que se ve en la imagen inferior y presionar la opción editor. Figura 35 : Manual, pantalla de modelos. Elaboración propia. Vista rápida Una vez en la pantalla del editor lo primero que se ve es el editor con los botones de gestión de ficheros. Funciona como cualquier editor, se presiona en la línea en la que se quiere escribir, en este caso solo se puede escribir dentro del área editable que está marcada por los comentarios de //Start of editable area y //End of editable area y ya se puede escribir. También se explicará como acceder a los diferentes editores “Editor and Run” y “Editor and Versions”. pág. 135 Figura 36 : Manual, pantalla del Editor. Elaboración propia Para acceder al editor con el apartado de ejecución hay que presionar el botón de la pestaña de “Editor and Run” que se encuentra justo encima del Editor tal y como muestra la siguiente imagen. Figura 37 : Manual, botón pestaña Editor and Run. Elaboración propia A continuación, se puede ver el apartado de “Editor and Run” pág. 136 Figura 38 : Manual, pestaña “Editor and Run”. Elaboración propia Para acceder a la pestaña de “Editor and Versions” hay que presionar el botón que de la pestaña “Editor and Versions” Figura 39 : Manual, botón pestaña “Editor and Versions”. Elaboración propia A continuación, se puede ver el apartado de “Editor and Versions” con un fichero cargado y todas las versiones anteriores del fichero en el lado derecho en la línea temporal. En este caso la línea temporal ha bajado lo suficiente para que aparezca el botón con el icono de una flecha, situado en la parte inferior derecha. Si se presiona este botón la línea temporal se situará otra vez al principio. pág. 137 Figura 40 : Manual, pestaña “Editor and Versions”. Elaboración propia Crear un fichero Para crear ficheros solo hay que presionar el botón y aparecerá el mensaje que se puede ver en la siguiente imagen. En el diálogo se puede ver un campo de entrada donde hay que poner el nombre del nuevo fichero, este nombre será tanto para el fichero como para la funcionalidad que contendrá, en la siguiente imagen se ha escogido el nombre de “Doc_1”. Una vez se ha rellenado el campo del nombre hay que presionar el botón del mensaje para que el fichero se cree. pág. 144 concretos. En la siguiente imagen se puede ver el diálogo que aparece, de momento permite controlar el número de nodos y el número de elementos. Una vez cambiado se puede regresar al valor anterior con el botón . Cuando ya se tienen todos los datos modificados se presiona el botón para guardar los valores actualizados. Cuando está todo listo para ejecutar el código que está ahora mismo en el editor, se presiona el botón para que empiece la ejecución. En la siguiente imagen se puede ver una ejecución finalizada, en este caso el código hace aparecer un botón de forma circular para crear una esfera. Al presionar el botón se abre una ventana en la que te pide el radio y la posición del centro de la esfera. Cuando se presiona el botón de crear en el apartado del terminal, aparece toda la información de la esfera, pero no aparecerá en la pantalla de visualización. Esta pantalla es para comprobar el funcionamiento de la interfaz, las geometrías no aparecen, solo te informa si la creación ha sido exitosa o no. Figura 50 : Manual, cambiar valores por defecto de la ejecución. Elaboración propia pág. 145 En este caso la ejecución ha sido exitosa, pero en la siguiente imagen podemos ver otra ejecución que no lo ha sido, ha tenido errores en el código. Figura 51 : Manual, ejecución de la creación de una esfera. Elaboración propia Figura 52 : Manual, errores en la ejecución. Elaboración propia pág. 146 Comparación de versiones Para acceder a esta funcionalidad hay que ir al apartado de “Editor and Versions”. Una vez en esta ventana es necesario tener un fichero abierto para poder ver la línea temporal. Si se presiona en cualquiera de los nodos se cargará el código de esa versión en el editor izquierdo, mientras que en el editor derecho seguirá el código actual. A continuación, se puede ver una imagen que compara dos versiones de un fichero. Todo lo que aparezca de color verde son modificaciones que se han hecho o líneas de código que se han añadido y todo lo que se marca en rojo son líneas de código que se han borrado. Figura 53 : Manual, comparación de dos versiones. Elaboración propia