Encuesta2: la solución automatizada para la gestión eficiente de encuestas estudiantiles

ESCUELA DE INGENIERÍA INFORMÁTICA DE SEGOVIA Grado en Ingeniería Informática de Servicios y Aplicaciones Encuesta2 La solución automatizada para la gestión eficiente de encuestas estudiantiles Alumno: David Salgueiro Alija Tutor: Fco. José González Cabrera Índice Capítulo 1 - Introducción ................................................................................................ 10 1.1 Introducción .......................................................................................................... 10 1.2 Motivación ............................................................................................................ 10 1.3 Objetivos ............................................................................................................... 11 1.4 Alcance .................................................................................................................. 11 1.5 Entorno Tecnológico ............................................................................................. 12 1.5.1 Plataformas o frameworks .............................................................................. 12 1.5.2 Herramientas de Soporte ................................................................................ 13 Capítulo 2 – Estado del arte ............................................................................................ 15 2.1 Aplicaciones similares .......................................................................................... 15 2.2 Comparativa con otras aplicaciones...................................................................... 15 2.3 Análisis DAFO (Debilidades, Amenazas, Fortalezas y Oportunidades) .............. 17 2.3.1 Debilidades ..................................................................................................... 18 2.3.2 Amenazas ....................................................................................................... 18 2.3.3 Fortalezas ....................................................................................................... 18 2.3.4 Oportunidades ................................................................................................ 19 Capítulo 3 – Organización y planificación ..................................................................... 21 3.1 Metodología de trabajo ......................................................................................... 21 3.2 Planificación ......................................................................................................... 22 3.2.1 Planificación estimada.................................................................................... 22 3.2.2 Desarrollo real ................................................................................................ 24 3.2.3 Comparativa de planificaciones ..................................................................... 25 3.3 Análisis de costes .................................................................................................. 26 3.3.1 Coste de los componentes hardware .............................................................. 26 3.3.2 Coste de los componentes software ............................................................... 27 3.3.3 Coste de personal. .......................................................................................... 27 3.3.4 Coste total ....................................................................................................... 28 3.3.5 Análisis de costes por el método Albrecht. .................................................... 28 3.3.6 Análisis de costes por casos de uso ................................................................ 32 3.3.7 Comparativa de costes .................................................................................... 35 Capítulo 4 – Análisis del sistema ................................................................................... 37 4.1 Descripción de los subsistemas ............................................................................. 37 4.2 Árbol de características ......................................................................................... 40 4.3 Diagrama de flujo de datos ................................................................................... 41 4.4 Descripción de los actores .................................................................................... 42 4.5 Requisitos de usuario ............................................................................................ 42 4.6 Casos de uso/ Historias de usuario ....................................................................... 44 4.7 Especificación de casos de uso/ Criterios de aceptación historias de usuario ...... 45 4.8 Requisitos de Información .................................................................................... 50 4.8.1 Diagrama entidad-relación ............................................................................. 50 4.8.2 Modelo de datos ............................................................................................. 51 4.8.3 Diccionario de datos ....................................................................................... 51 4.9 Requisitos funcionales .......................................................................................... 57 4.10 Requisitos no funcionales ................................................................................... 60 Capítulo 5 – Diseño del sistema ..................................................................................... 63 5.1 Arquitectura de Odoo ............................................................................................ 63 5.1.1 Estructura del módulo Encuesta2 ................................................................... 64 5.2 Arquitectura física ................................................................................................. 70 5.3 Diagramas de secuencia ........................................................................................ 71 5.4 Diseño de la interfaz de usuario ............................................................................ 73 5.4.1 Página login .................................................................................................... 73 5.4.2 Página web ..................................................................................................... 73 5.4.3 Menú de navegación....................................................................................... 74 5.4.4 Detalle menús de navegación ......................................................................... 74 5.4.5 Menú estadísticas: .......................................................................................... 77 Capítulo 6 – Implementación y estructura ...................................................................... 79 6.1 Lenguajes de implementación .............................................................................. 79 6.2 Detalles de la implementación ......................................................................... 82 Capítulo 7 – Pruebas y evidencias .................................................................................. 84 7.1 Pruebas de caja blanca .......................................................................................... 84 7.2 Pruebas de caja negra y evidencias ....................................................................... 84 Capítulo 8 – Manuales del producto ............................................................................... 90 8.1 Manual de instalación ........................................................................................... 90 8.2 Manual de usuario. ................................................................................................ 91 El administrador tiene a su disposición el menú completo: ........................................ 91 Capítulo 9 – Conclusiones y mejoras ........................................................................... 100 9.1 Conclusiones ....................................................................................................... 100 9.2 Propuestas de mejoras ......................................................................................... 101 9.3 Referencias: Bibliografía y webgrafía ................................................................ 102 Índice de figuras Figura 1. Encuestas UVA ............................................................................................... 15 Figura 2. Google Forms .................................................................................................. 16 Figura 3. SurveyMonkey ................................................................................................ 16 Figura 4. Moodle ............................................................................................................ 16 Figura 5. Matriz DAFO .................................................................................................. 17 Figura 6. Iteración........................................................................................................... 22 Figura 7. Gantt planificación estimada ........................................................................... 23 Figura 8. Gantt desarrollo real ........................................................................................ 25 Figura 9. Tabla clasificación método Albrecht .............................................................. 29 Figura 10. Logo OpenEducatCore .................................................................................. 37 Figura 11. Módulo empleados ........................................................................................ 38 Figura 12. Modulo encuestas .......................................................................................... 38 Figura 13. Logo módulo Encuesta2 ................................................................................ 38 Figura 14. Módulo sitio web .......................................................................................... 39 Figura 15. Árbol de características ................................................................................. 40 Figura 16. Diagrama de flujo de datos (DFD) ................................................................ 41 Figura 17. Diagrama casos de uso .................................................................................. 44 Figura 18. Diagrama entidad relación ............................................................................ 51 Figura 19. MVC Odoo .................................................................................................... 63 Figura 20. Arquitectura Odoo 1 ...................................................................................... 65 Figura 21. Arquitectura Odoo 2 ...................................................................................... 66 Figura 22. Arquitectura Odoo 3 ...................................................................................... 67 Figura 23. Archivo manifest.py ...................................................................................... 68 Figura 24. Arquitectura Odoo 4 ...................................................................................... 69 Figura 25. Arquitectura física ......................................................................................... 70 Figura 26. Diagrama secuencia 1 ................................................................................... 71 Figura 27. Diagrama secuencia 2 ................................................................................... 72 Figura 28. Login ............................................................................................................. 73 Figura 29. Web Encuestados .......................................................................................... 73 Figura 30. Menú de navegación ..................................................................................... 74 Figura 31. Menú chat ...................................................................................................... 74 Figura 32. Menú profesor ............................................................................................... 75 Figura 33. Menú alumnos ............................................................................................... 75 Figura 34. Menú configuración sitio-web ...................................................................... 75 Figura 35. Menú encuestas ............................................................................................. 76 Figura 36. Menú empleado ............................................................................................. 76 Figura 37. Menú módulos ............................................................................................... 76 Figura 38. Menú ajustes ................................................................................................. 77 Figura 39. Menú estadísticas - respuestas cortas ............................................................ 77 Figura 40. Menú estadísticas - gráficos .......................................................................... 78 Figura 41. Menú estadísticas - porcentajes ..................................................................... 78 Figura 42. Logo Python .................................................................................................. 79 Figura 43. Logo XML .................................................................................................... 79 Figura 44. Logo JavaScript ............................................................................................. 80 Figura 45. Logo HTML .................................................................................................. 80 Figura 46. Logo PostgreSQL .......................................................................................... 81 Figura 47. Logo AppDiagrams.net ................................................................................. 81 Figura 48. Menú principal .............................................................................................. 91 Figura 49. Listado cursos ............................................................................................... 92 Figura 50. Listado departamentos .................................................................................. 92 Figura 51. Listado asignaturas ........................................................................................ 92 Figura 52. Listado profesores ......................................................................................... 92 Figura 53. Listado alumnos ............................................................................................ 93 Figura 54. Menú sitio web .............................................................................................. 93 Figura 55. Listado empleados ......................................................................................... 93 Figura 56. Menú aplicaciones y módulos ....................................................................... 94 Figura 57. Menú configuración ...................................................................................... 94 Figura 58. Registro encuestas ......................................................................................... 95 Figura 59. Envío encuestas ............................................................................................. 96 Figura 60. Visualización de resultados ........................................................................... 96 Figura 61. Crear sesión en vivo ...................................................................................... 97 Figura 62. Test de encuestas ........................................................................................... 97 Figura 63. Imprimir encuestas ........................................................................................ 98 Figura 64. Menú chat ...................................................................................................... 98 David Salgueiro Alija 16 Figura 2. Google Forms Otra alternativa son los formularios de Google que ofrecen las mismas funcionalidades de personalización, pero es necesario que cada profesor tenga su propia cuenta de Google y cada cuenta funcione de manera totalmente independiente. Además, no ofrece soporte para diferentes asignaturas y envío automático de las encuestas. Figura 3. SurveyMonkey SurveyMonkey es una plataforma online que permite a sus usuarios crear, enviar y analizar encuestas y cuestionarios. La plataforma proporciona opciones de diseño y personalización para adaptar las encuestas a las necesidades del usuario. Sin embargo, al igual que Google Forms es una plataforma independiente que no está integrada en un CRM lo que implica nuevos registros y descentralizar las necesidades de la Universidad. Figura 4. Moodle Otra opción es Moodle. Moodle es una plataforma interesante ya que la Universidad de Valladolid hace uso de ella para el campus virtual, sin embargo, el proyecto Encuesta2 mejora en algunos aspectos respecto al sistema de encuestas de Moodle. En Encuesta2 tenemos una mayor personalización y flexibilidad en las encuestas como puede ser crear David Salgueiro Alija 17 diferentes tipos de preguntas, establecer la lógica condicional, personalizar el diseño y agregar instrucciones o introducciones para sus usuarios. También cuenta con una interfaz de usuario más intuitiva y puede agrupar los datos de los resultados en forma de gráficos y estadísticas. Además, todos estos datos se encuentran de forma centralizada en la plataforma. 2.3 Análisis DAFO (Debilidades, Amenazas, Fortalezas y Oportunidades) DAFO es una herramienta de análisis que se usa en la planificación estratégica para evaluar las fortalezas, oportunidades, amenazas y debilidades. Permite obtener una visión clara de la situación actual del proyecto y ayudar en la toma de decisiones estratégicas, como muestra la siguiente imagen a que analizaré detalladamente. Figura 5. Matriz DAFO David Salgueiro Alija 18 2.3.1 Debilidades La plataforma Odoo requiere una curva de aprendizaje de corta duración para los usuarios que no estén familiarizados con la plataforma, lo que puede implicar una inversión inicial en tiempo y familiarización con el entorno. Una personalización muy específica puede recurrir en demasiados costos adicionales ya que sería necesario desarrollar desde cero una interfaz. Algunos profesores y estudiantes pueden dudar en usar esta nueva plataforma porque no están familiarizados con ella y puede ser difícil de usar al principio. 2.3.2 Amenazas La principal amenaza ya existe en la universidad de Valladolid y es que ya está implantado un sistema de encuestas. Aunque el enfoque de este proyecto es diferente al sistema ya implantado puede suponer rechazo por algunos de sus usuarios ya que podrían identificar este proyecto como un proyecto que hace la misma funcionalidad y por lo tanto inútil. Existen limitaciones técnicas que pueden requerir la compra de módulos adicionales para agregar determinada funcionalidad o nuevos desarrollos. Al igual que en la mayoría de los proyectos de software, existe el riesgo de que el público objetivo al que está destinado el proyecto no acabe de aceptarlo y por lo tanto acabe en desuso. 2.3.3 Fortalezas La principal fortaleza de este proyecto es el uso de la plataforma Odoo como base para el proyecto porque es un software de código abierto y ofrece una amplia gama de funcionalidades y características que facilitan la implementación. La flexibilidad que nos ofrece Odoo permite adaptar y personalizar cada una de las encuestas según las necesidades de cada profesor. Odoo permite la integración de otros módulos que pueden enriquecer la funcionalidad y la experiencia de usuario. En el proyecto Encuesta2 se podría añadir funcionalidad para el análisis de los datos recogidos o la generación de informes. David Salgueiro Alija 19 2.3.4 Oportunidades • Mejoras en la relación profesor-alumno. El proyecto Encuesta2 puede mejorar la comunicación entre profesores y alumnos, permitiendo así una retroalimentación más efectiva y una mayor comprensión de las necesidades y expectativas de ambas partes. • Recopilación de datos. La recopilación de datos a través de las encuestas proporciona información importante sobre la experiencia y la satisfacción de los alumnos con la docencia, lo que puede dar a identificar nuevas áreas de mejora y tomar decisiones con fundamento. • Automatización de procesos: con Odoo podemos automatizar procesos relacionados con las encuestas como el envío automático de encuestas o guardar los resultados de encuestas pasadas. David Salgueiro Alija 20 David Salgueiro Alija 21 Capítulo 3 – Organización y planificación 3.1 Metodología de trabajo Después de analizar los requisitos y objetivos del proyecto Encuesta2 opto por implementar una metodología iterativa e incremental. Esta metodología de trabajo permite una gran adaptación a las necesidades cambiantes del proyecto. Según va avanzando se descubren nuevas necesidades y requisitos que pueden ser incorporados de manera iterativa permitiendo así una mayor flexibilidad y agilidad en el desarrollo de este. Además, con la metodología iterativa se pueden obtener versiones funcionales del proyecto. Esta es una gran ventaja ya que el cliente puede ver y participar en el desarrollo del producto. Permite recopilar información de los usuarios finales de manera temprana y comprender mejor las necesidades y expectativas de los usuarios, lo que a su vez ayuda a mejorar y refinar el software a lo largo del desarrollo del producto. Al seguir una metodología iterativa se realizan demostraciones al cliente del estado del proyecto. Esto permite a los stakeholders y a los usuarios finales la oportunidad de comprobar el funcionamiento del software sin que esté acabado. En cada iteración se desarrolla y entrega una versión completamente funcional del software. Proporciona un retorno de la inversión temprano por parte del cliente y la posibilidad de beneficiarse del proyecto desde las etapas iniciales en lugar de esperar a que el desarrollo esté completamente acabado. En resumen, la metodología iterativa realizada para el proyecto Encuesta2 proporciona adaptabilidad a los cambios, una retroalimentación temprana, reducción de riesgos y una mayor transparencia y comunicación con el cliente obteniendo una entrega temprana de valor. Estas ventajas son beneficiosas ya que se adaptan a la naturaleza y flexibilidad de los proyectos desarrollados con Odoo. David Salgueiro Alija 22 Figura 6. Iteración 3.2 Planificación 3.2.1 Planificación estimada En este apartado se detalla la planificación prevista al inicio del Trabajo de Fin de Grado para llevar a cabo todos los objetivos y cumplir todos los requisitos en el tiempo establecido para la realización del proyecto. Se utilizará una metodología basada en iteraciones que irán añadiendo funcionalidad según vaya avanzando el desarrollo del mismo. La duración del desarrollo del TFG es de 300h. El proyecto está planificado para realizarse durante los meses de marzo, abril, mayo y junio, por lo que tendrá una duración de 4 meses. Se estima que durante estos 4 meses la jornada de trabajo sea de lunes a domingo durante 3h diarias. Estimo una duración de 122 días multiplicados por 3 horas diarias que son 366h. Son 66 horas de margen para posibles retrasos o ajustes que tengan que ser necesarios realizar en el proyecto. Además, es probable que debido a situaciones personales existan días que no se realicen esas 3 horas de jornada y otros que se hagan más de 3 horas por necesidades del proyecto. Además, antes del proyecto, he realizado un curso de Odoo de 40 horas en el que he aprendido todos los conceptos necesarios para la realización del trabajo. A continuación, se explicarán en que esta planificada cada una de las iteraciones. Estarán distribuidas por meses de trabajo, habiendo un total de 4 iteraciones. David Salgueiro Alija 23 • Iteración 1 (93h): En esta primera iteración se recogen todos los requisitos y casos de uso del proyecto. Se crea toda la instalación de Odoo y se investiga sobre si existe proyectos similares o si existen módulos ya desarrollados que cumplan los requisitos. En esta iteración se entrega el cliente una versión funcional de Odoo en la que puede visualizar el entorno y familiarizarse. • Iteración 2 (90h): Una vez creado, analizado y configurado todo el sistema se pasa a desarrollar un módulo propio que se adapte al entorno. En esta iteración se entrega al cliente una versión 0.5 del proyecto. El cliente podrá visualizar algunas de las características ya implementadas. • Iteración 3 (93h): En la tercera iteración se continua con el desarrollo del proyecto y se comprueba que el proyecto cumpla con todos los requisitos. En esta iteración el cliente ya puede ver una versión sin revisar del producto terminado. • Iteración 4 (90h): En esta última iteración se realiza toda la validación y pruebas de la plataforma. Además, se realizan despliegues del proyecto a un entorno de producción. Figura 7. Gantt planificación estimada Aunque la documentación del proyecto se desarrolla durante todas las iteraciones, es en la iteración 4 cuando se dedica un mayor tiempo ya que en esa iteración, el proyecto ya está acabado y puede documentarse de inicio a fin. David Salgueiro Alija 24 3.2.2 Desarrollo real Cuando el proyecto llega al final de su planificación, es interesante analizar las diferencias entre la planificación inicial y la planificación realizada. Durante el desarrollo del proyecto han surgido diversos problemas e inconvenientes que han podido alterar el desarrollo. En los siguientes puntos se explican cómo ha sido realmente el desarrollo de cada iteración. El 16 de febrero de 2023 se tiene la primera reunión inicial para explicar a mi tutor cual va a ser mi proyecto y se establecen los puntos principales entorno al proyecto. Tras esa reunión se realiza la Comunicación Oficial de Inicio. Finalmente se realizan 3 iteraciones que se detallarán a continuación. • Iteración 1 (87 h): En esta primera iteración se establecen los requisitos de usuario y casos de uso del proyecto. Se realiza una investigación profunda del entorno de desarrollo de Odoo y se instala el servidor en un entorno local y se configura la BBDD. También se buscan diferentes módulos que puedan adaptarse a los requisitos. En esta primera iteración se entrega al cliente una versión funcional en local del entorno de Odoo. • Iteración 2 (128 h): Una vez instalado todo el entorno y encontradas las diversas opciones o caminos a seguir, se elige uno y se empieza a desarrollar desde 0 el módulo encuestados. Durante esta etapa se crean los modelos, permisos, parámetros de seguridad y todo el código que implementa la funcionalidad. Además, se crea un servidor de correo electrónico para que funcione con la plataforma. Al finalizar esta iteración se entrega una versión funcional y que cumple con la mayoría de los requisitos que exige el proyecto. • Iteración 3 (94 h): En esta última iteración se termina de desarrollar el módulo y se comprueba que es robusto frente a errores y funciona a la perfección junto a los otros módulos del proyecto. También se mejora la interfaz de usuario y se realizan pruebas de validación de los datos. Aunque durante el resto de las iteraciones se documenta el proyecto según va avanzando, es en esta última cuando se dedica más tiempo a la documentación ya que existe una versión final del proyecto. David Salgueiro Alija 25 Figura 8. Gantt desarrollo real Finalmente, la duración del desarrollo del proyecto ha sido de 309 horas. Este desajuste de horas se debe a varios problemas e imprevistos que han surgido. Entre ellos se encuentran los bloqueos surgidos durante el desarrollo, caída y fallo de todo el sistema debido a la instalación de módulos de terceros y dificultades a la hora de desarrollar funcionalidad compleja. 3.2.3 Comparativa de planificaciones En este apartado vamos a comparar las dos planificaciones realizadas anteriormente. La planificación estimada se distribuye por meses de trabajo, en cada una de las iteraciones se entrega al cliente un producto funcional. Esta planificación tiene una duración de 366 horas, 66 horas a mayores de las inicialmente planificadas en el proyecto. La ventaja de esta planificación es que tiene un enfoque más estructurado y proporciona una marco de tempo claro y predecible para el proyecto. La principal desventaja es que es más difícil adaptarse a las nuevas necesidades requeridas durante el desarrollo del proyecto. La segunda planificación se ajusta mucho más a la realidad y necesidades del proyecto porque cada iteración se distribuye en entregables definidos del proyecto y no en función del tiempo. Esto da lugar a una mayor flexibilidad para adaptarse a los cambios David Salgueiro Alija 32 3.3.6 Análisis de costes por casos de uso El análisis de costes por casos de uso en un proyecto de software permite estimar y controlar los recursos financieros que son necesarios para desarrollar e implementar funcionalidades específicas del sistema. Un caso de uso representa una interacción entre los usuarios y el sistema, describiendo una serie de pasos y acciones que el usuario debe seguir para lograr un objetivo. 1. Clasificamos cada interacción entre actor y caso de uso según su complejidad y le asignamos un peso. Tenemos 3 actores que acceden a través de la interfaz gráfica. Por lo tanto, Peso de actores no ajustado (UAW) = 3*3=9 2. Calculo la complejidad de cada caso de uso según el número de transacciones. David Salgueiro Alija 33 Casos de uso Complejidad CU-1 5 CU-2 5 CU-3 5 CU-4 5 CU-5 5 CU-6 5 CU-7 5 CU-8 5 CU-9 5 CU-10 5 CU-11 5 CU-12 5 CU-13 5 CU-14 5 CU-15 5 CU-16 5 CU-17 5 CU-18 5 CU-19 5 CU-20 5 TOTAL 100 3. Calculamos de puntos de caso de uso sin ajustar UUCP= peso de los actores sin ajustar + peso de los casos de uso sin ajustar: UUCP= 9 +100=109 4. Calculamos los factores de complejidad técnica y los factores de entorno para obtener los puntos de casos de uso ajustados mediante la siguiente fórmula: UCP= UUCP * factores de complejidad técnica * factores de entorno. David Salgueiro Alija 34 Factor de complejidad técnica Factor de complejidad técnica Factor Descripción Peso Influencia Resultado R1 Sistema distribuido 2 2 4 R2 Objetivos de rendimiento 1 3 3 R3 Eficiencia respecto al usuario final 1 3 3 R4 Procesamiento complejo 1 2 2 R5 Código reutilizable 1 1 1 R6 Instalación sencilla 0.5 4 2 R7 Fácil utilización 0.5 1 0.5 R8 Portabilidad 2 3 6 R9 Fácil de cambiar 1 0 0 R10 Uso concurrente 1 1 1 R11 características de seguridad 1 3 3 R12 Accesible por terceros 1 0 0 R13 Se requiere formación especial 1 2 2 TOTAL 27.5 El factor de complejidad TCF se calcula con la siguiente fórmula: TCF= 0,6 +(0,01*27,5) =0,875 Factor de entorno Factor de entorno Factor Descripción Peso Influencia Resultado R1 Familiaridad con modelo de proyecto (RUP) 1.5 3 4.5 R2 Experiencia en la aplicación 0.5 3 1.5 R3 Experiencia en orientación a objetos 1 3 3 R4 Capacidades de análisis 0.5 3 1.5 R5 Motivación 1 3 3 R6 Requisitos estables 2 5 10 R7 Trabajadores a tiempo parcial -1 5 -5 R8 Lenguaje complejo -1 3 -3 TOTAL 15.5 El factor de entorno EF se calcula con la siguiente fórmula: EF= 1,4+(-0,03*15,5) = 0,935 David Salgueiro Alija 35 Ahora, calculamos los puntos de caso de uso ajustados UCP=100*0,87*0,935 = 81,34 Para calcular el esfuerzo en programación se utiliza la siguiente fórmula. Esfuerzo = UCP * Factor de productividad Donde el factor de productividad según el método de Karner equivale a 20 horas por persona por UCP. Esfuerzo =81,34 * 20h= 1626,8 horas por persona. Costo = 21,28€ * 1626,8 = 34618,30€ Obviamente este resultado está muy alejado del proyecto ya que en nuestro proyecto se reutiliza código libre. Y esta estimación obtiene estos resultados porque estima un desarrollo desde cero. 3.3.7 Comparativa de costes Después de analizar el coste del proyecto con diversas metodologías, comparo cada uno de los resultados. Metodología Costes Hardware, software y RRHH 6601.46€ Método Albrecht 10600.7€ Método casos de uso 34618.30€ Como podemos comprobar, la estimación por puntos el método Albrecht y casos de uso es superior a los costes calculados inicialmente. Este se debe a que estas metodologías están orientadas al uso de lenguajes más tradicionales y estiman el coste del proyecto desde cero. Por ello considero que estas dos metodologías sobrestiman el costo del proyecto. El coste más ajustado es la suma de los costos en software, hardware y recursos humanos. Coste final = Hardware + Software + Recursos Humanos Coste final = 6601.46€ David Salgueiro Alija 36 David Salgueiro Alija 37 Capítulo 4 – Análisis del sistema 4.1 Descripción de los subsistemas En Odoo, los módulos pueden considerarse como subsistemas que forman parte de la plataforma. Se compone de una serie de módulos independientes que se puede instalar y personalizar según las necesidades específicas del proyecto. Cada módulo tiene sus propias características, modelo de datos, vistas y controladores. Se pueden instalar y actualizar y adaptar a los requisitos. Los módulos de Odoo están diseñados para funcionar de manera conjunta y se integran entre sí, lo que permite a los desarrolladores acceder a las funcionalidades de otros módulos. El proyecto Encuesta2 hacemos uso de diversos módulos que se detallarán a continuación. Siendo el módulo encuestados el único propio. El resto de los módulos son de terceros y aportan funcionalidad y complementan el módulo encuestados A continuación, se detallarán con más profundidad los módulos usados en el proyecto. • OpenEducat_Core: Este módulo es el núcleo principal en la gestión de profesores y alumnos. Gestiona todos los usuarios con el rol de profesor y alumnos. Además, es el core de muchos otros módulos que pueden complementar la funcionalidad del proyecto. Figura 10. Logo OpenEducatCore David Salgueiro Alija 38 • Empleados: Este módulo proporciona funcionalidades para administrar y gestionar la información de RRHH. Almacena toda la información de los empleados y en el proyecto es útil para crear los usuarios de la plataforma. Figura 11. Módulo empleados • Encuestas: Permite a los usuarios registrados crear y administrar las encuestas de una manera efectiva. Recopila las respuestas de las encuestas y las muestra de forma gráfica. También incluye la funcionalidad de crear sesiones en vivo y compartir las encuestas por correo electrónico. Figura 12. Modulo encuestas • Encuestados: Este módulo es un módulo propio. Complementa la funcionalidad del resto de módulos. Ha sido personalizado para cumplir con los requisitos del proyecto. Como características propias incluye la gestión de cursos, departamentos y asignaturas. Entre las características complementarias al resto de módulos se encuentran la gestión de profesores, alumnos y encuestas. Además, gestiona toda la validación de campos de los modelos de datos mencionados anteriormente. Figura 13. Logo módulo Encuesta2 David Salgueiro Alija 39 • Sitio web: Permite la creación de un sitio web con sus diferentes páginas. En nuestro proyecto es usado para la creación de una página web de inicio y la página de login que permite el inicio de sesión y el acceso a la plataforma. Figura 14. Módulo sitio web David Salgueiro Alija 40 4.2 Árbol de características Un árbol de características es una estructura jerárquica que representa las características y funcionalidades del software de manera organizada y desglosada. Esta técnica se utiliza para analizar, documentar y gestionar características del sistema. Las características se agrupan en diferentes niveles jerárquicos en los que las principales características se dividen en subcaracterísticas más detalladas. Figura 15. Árbol de características David Salgueiro Alija 41 4.3 Diagrama de flujo de datos Un diagrama de flujo de datos (DFD) es una representación gráfica en la que se describe como fluyen los datos dentro de un sistema o proceso. El DFD es una técnica utilizada en el análisis y diseño de sistemas que permite visualizar el flujo de los datos desde las entradas hasta las salidas. El objetivo de un DFD es proporcionar una representación clara y concisa del flujo de datos de un sistema. Estos flujos muestran cómo los datos se intercambian en el sistema, las transformaciones que se aplican y como se almacenan o transmiten. Figura 16. Diagrama de flujo de datos (DFD) David Salgueiro Alija 48 Identificador CU15 Descripción Registrar estudiante Precondiciones Ninguna Secuencia normal El estudiante debe ser asignado a una asignatura Postcondiciones Que se asigne el estudiante a una asignatura Excepciones Que el estudiante no se haya asignado a ninguna asignatura y por lo tanto no reciba ninguna encuesta Identificador CU16 Descripción Personalizar sitio web Precondiciones Ninguna Secuencia normal Se crea un sitio web con las diferentes páginas web necesarias. Postcondiciones Creado un entorno web Excepciones Identificador CU17 Descripción Instalar módulo Precondiciones Que el módulo esté incluido en el directorio de Odoo y los módulos de los que dependa existan y estén instalados Secuencia normal Instalar modulo Postcondiciones Modulo instalado en el entorno Excepciones Identificador CU18 Descripción Acceder a la configuración Precondiciones Es necesario que el usuario sea un administrador Secuencia normal Acceso a ajustes desde el menú de aplicaciones Postcondiciones Excepciones Identificador CU19 Descripción Responder encuesta Precondiciones El estudiante haya recibid en su email una encuesta Secuencia normal Responder las preguntas de las encuestas Postcondiciones Se ha respondido la encuesta Excepciones David Salgueiro Alija 49 Identificador CU20 Descripción Chat Precondiciones Que el usuario haya iniciado sesión Secuencia normal El usuario podrá hablar con otros usuarios registrados Postcondiciones Comunicación Excepciones David Salgueiro Alija 50 4.8 Requisitos de Información 4.8.1 Diagrama entidad-relación El modelo conceptual Entidad-Relación se define como un diagrama de flujo en el que se reflejan las entidades, relaciones y atributos existentes en una base de datos. Para comprender que es un modelo entidad-relación debemos explicar cada uno de los componentes que lo forman. La entidad se define como una representación de un objeto o un concepto que puede referenciar a personas u objetos que se relacionan entre sí dentro de un mismo sistema. Las entidades se representan mediante un rectángulo, en el interior de este rectángulo se encuentra el nombre de la entidad escrito siempre con letras mayúsculas. Para terminar, tenemos que destacar que las entidades poseen atributos. En nuestro proyecto tenemos como ejemplo la entidad estudiante que almacena los atributos (nombre, primer_apellido, segundo_apellido, teléfono, género, email, titulo). Como acabamos de mencionar, las entidades se relacionan entre sí dando lugar al siguiente concepto el cual son las relaciones. Las relaciones son representadas mediante un rombo, dentro de este se encuentra el nombre de la relación, el cual siempre es un verbo y está en infinitivo. Además, todas las relaciones poseen cardinalidad y multiplicidad. La cardinalidad de una relación expresa el número máximo de entidades que están relacionadas con una única entidad del otro conjunto de entidades que interviene en la relación. La multiplicidad de una relación determina cuantos objetos de cada tipo intervienen en la relación. En la siguiente imagen se muestra el diagrama entidad-relación del módulo Encuesta2. David Salgueiro Alija 51 Figura 18. Diagrama entidad relación 4.8.2 Modelo de datos 4.8.3 Diccionario de datos Un diccionario de datos es una colección estructurada de información que describe los elementos de datos utilizados en la base de datos de un sistema o proyecto. En un diccionario de datos, se describe cada elemento de datos utilizado en la base de datos, como nombres de tablas, nombres de columnas, tipos de datos, longitudes, formatos, reglas de validación y relaciones con otros elementos de datos. En las siguientes tablas se amplía la información de las entidades y relaciones del apartado anterior. David Salgueiro Alija 52 ID E1 Nombre: ESTUDIANTE Definición: La entidad ESTUDIANTE representa al actor que está inscrito en alguna asignatura Atributos: ID Nombre Definición Tipo Reglas Compuesto Único Nulo A.1.1 Nombre Nombre del estudiante String NO SI NO A.1.2 Telefono Número de telefono del estudiante Int NO NO SI A.1.3 Género Género del estudiante String NO NO SI A.1.4 Email Email del estudiante String Formato de email NO NO NO Identificadores: ID Nombre atributo A1.4 Email ID E2 Nombre: CURSO Definición: La entidad CURSO representa el tiempo en el que se desarrolla una asignatura Notas: La entidad curso tiene una fecha de inicio y una fecha de fin. También debe estar asignado un cuatrimestre Atributos: ID Nombre Definición Tipo Reglas Compuesto Único Nulo A2.1 Nombre Identificador del curso String SI SI NO A2.2 Fecha de fin Fecha de fin del curso Date Fecha de fin debe ser posterior a la fecha de inicio NO NO NO A2.3 Año Año de desarrollo del curso Int NO NO NO A2.4 Fecha de inicio Fecha de inicio del curso Date NO NO NO A2.5 Cuatrimestre Cuatrimestre en el que se desarrolla el curso Int NO NO NO Identificadores: ID Nombre atributo A2.1 Nombre David Salgueiro Alija 53 ID E3 Nombre: ASIGNATURA Definición: La entidad asignatura representa el conjunto de enseñanzas impartidas por los profesores Atributos: ID Nombre Definición Tipo Reglas Compuesto Único Nulo A3.1 Nombre Nombre de la asignatura String NO NO NO Identificadores: ID Nombre atributo A3.1 Nombre ID E4 Nombre: PROFESOR Definición: La entidad PROFESOR representa el actor que imparte una asignatura y realiza encuestas Atributos: ID Nombre Definición Tipo Reglas Compuesto Único Nulo A4.1 Género Género del actor profesor String NO NO NO A4.2 Email Email corporativo del profesor String NO SI NO A4.3 Titulo Título que se le asigna al profesor String NO NO NO A4.4 Fecha Nacimiento Fecha de nacimiento del profesor Date NO NO NO A4.5 Telefono Telefono corporativo del profesor Int NO NO SI Identificadores: ID Nombre atributo A4.2 Email David Salgueiro Alija 54 ID E5 Nombre: ENCUESTA Definición: La entidad ENCUESTA representa a los objetos encuestas que han realizado los profesores Notas: Cada encuesta puede estar relacionada con 0 o con N asignaturas Atributos: ID Nombre Definición Tipo Reglas Compuesto Único Nulo A5.1 Asignatura Asignatura de la encuesta String NO SI NO Identificadores: ID Nombre atributo A5.1 Asignatura ID E6 Nombre: DEPARTAMENTO Definición: La entidad DEPARTAMENTO representa los departamentos a los que están asignados los profesores Notas: Un departamento puede tener uno o más profesores Atributos: ID Nombre Definición Tipo Reglas Compuesto Único Nulo A6.1 Nombre Nombre del departamento String NO SI NO Identificadores: ID Nombre atributo A61. Nombre ID R1 Nombre: APRENDER Definición: La relación APRENDER modela la accion que realiza el estudiante con la entidad asignatura Notas: Un estudiante puede estar presente en cero o más asignaturas y una asignatura puede tener 1 o N estudiantes Reglas Dudas: Entidades ID Nombre Entidad Participación Cardinalidad E1 ESTUDIANTE 0 N E3 ASIGNATURA 1 N David Salgueiro Alija 55 ID R2 Nombre: PERTENECER Definición: La relación PERTENECER modela el hecho que una asignatura pertence a un curso Notas: Una asignatura solo puede pertenecer a un curso. Reglas Entidades ID Nombre Entidad Participación Cardinalidad E2 CURSO 0 N E3 ASIGNATURA 1 1 ID R3 Nombre: IMPARTIR Definición: La relación IMPARTIR modela el hecho en el que la entidad profesor imparte una asignatura Notas: Reglas Entidades ID Nombre Entidad Participación Cardinalidad E3 ASIGNATURA 1 N E4 PROFESOR 0 N ID R4 Nombre: DEPENDER Definición: La relación DEPENDER modela la dependencia de una encuesta con la entidad asignatura Notas: Una encuesta puede depender de una asignatura Reglas Entidades ID Nombre Entidad Participación Cardinalidad E3 ASIGNATURA 0 N E5 ENCUESTA 0 1 David Salgueiro Alija 56 ID R5 Nombre: REALIZAR Definición: La relación REALIZAR modela la dependencia de la entidad en cuesta con la entidad profesor Notas: Un profesor puede realizar 0 o N encuestas mientras que una encuesta solamente es realizada por un profesor Reglas Entidades ID Nombre Entidad Participación Cardinalidad E5 ENCUESTA 0 N E4 PROFESOR 1 1 ID R6 Nombre CORRESPONDER Definición La relación CORRESPONDER modela la dependencia de la entidad profesor a la entidad departamento Notas: Un departamento puede tener 0 o N profesores mientras que un profesor solo puede pertenecer a un departamento Reglas Entidades ID Nombre Entidad Participación Cardinalidad E4 PROFESOR 1 1 E6 DEPARTAMENTO 0 N David Salgueiro Alija 57 4.9 Requisitos funcionales Los requisitos funcionales son las especificaciones detalladas de los comportamientos y funcionalidades que se esperan del sistema. Estos requisitos describen las acciones específicas que el sistema debe realizar para cumplir con los objetivos y las necesidades de los usuarios. En las siguientes tablas se muestran los requisitos funcionales del sistema. Identificador RF1 Definición Registro de curso Autores Administrador Dependencias Ninguna Descripción El administrador registra el curso a través de un formulario especifico. Importancia Es imprescindible registrar el curso para que el sistema funcione correctamente Comentarios Identificador RF2 Definición Registro de departamento Autores Administrador Dependencias Que el curso esté registrado Descripción El administrador registra el departamento a través de un formulario especifico. Importancia Es imprescindible registrar el departamento para que el sistema funcione correctamente Comentarios Identificador RF3 Definición Registro de asignatura Autores Administrador Dependencias Que el curso y el departamento estén registrados Descripción El administrador registra la asignatura a través de un formulario especifico. Importancia Es imprescindible registrar la asignatura para que el sistema funcione correctamente Comentarios David Salgueiro Alija 64 5.1.1 Estructura del módulo Encuesta2 A continuación, se muestra como está estructurado el módulo Encuesta2 de Odoo. • Carpeta ‘models’: En esta carpeta se encuentran los archivos que definen los modelos, principalmente son clase Python que representan las entidades de los datos de la aplicación. • Carpeta ‘wizard’: En esta carpeta se almacenan los asistentes que realizan tareas específicas o recopilan información adicional de un usuario en un contexto especifico. • Carpeta ‘controllers’: En esta carpeta se encuentran los archivos que definen los controladores de la aplicación, los cuales se encargan de manejar todas las acciones que tiene el usuario con la aplicación. • Carpeta ‘views’: Contiene todos los archivos XML que definen las vistas de la aplicación y determinan como se muestran los datos al usuario. • Carpeta ‘data’: Contiene los archivos XML utilizados para cargar datos en la base de datos al instalar el módulo. • Carpeta ‘static’: En esta carpeta se almacenan los archivos estáticos, como hojas de estilo CSS, scripts JavaScript, imágenes y otros recursos que son necesarios para representar la interfaz de usuario. • Carpeta ‘security’: Contiene los archivos XML que controlan todos los permisos de acceso y reglas de seguridad de la aplicación. David Salgueiro Alija 65 Figura 20. Arquitectura Odoo 1 David Salgueiro Alija 66 El archivo _init_.py del directorio raíz se usa para inicializar el paquete de un módulo. En este archivo se importan los modelos, wizards y controladores de la aplicación necesarios para su instalación. Figura 21. Arquitectura Odoo 2 David Salgueiro Alija 67 En los archivos_init_.py de las carpetas models, wizards y controladores se importan todos los archivos .py que están contenidos en esos directorios. Figura 22. Arquitectura Odoo 3 David Salgueiro Alija 68 El archivo _manifest.py contiene metadatos esenciales sobre el módulo y proporciona información clave para la gestión de módulos de Odoo. • Declaración del nombre y versión del módulo: Se especifica el nombre del módulo con la variable ‘name’ y la versión del módulo mediante la variable ‘version’. Estos valores se utilizan para identificar y diferenciar las versiones del módulo. • ‘Summary’: Proporciona una breve descripción del módulo. Esta descripción es visible desde la interfaz de instalación de aplicaciones de Odoo. • La variable ‘category’ se usa para clasificar un módulo entre las diferentes categorías existentes en Odoo. Esto ayuda a organizar y agrupar los módulos según su categoría. • Las dependencias se recogen en la variable ‘depends’ donde se especifican las dependencias del módulo, es decir, los módulos necesarios que deben estar instalados para que nuestro modulo funcione correctamente. En el caso del módulo Encuesta2 depende de los módulos base, hr, hr_attendance, survey y openeducat_core. • Además, en el campo ‘data’ se recogen todos los archivos asociados al módulo como pueden ser los archivos XML de las vistas, archivos CSV de seguridad, archivos de traducción, etc… Además de estos elementos, el archivo _manifest.py también puede contener otras declaraciones opcionales, como los autores del módulo, la especificación de auto instalación (auto_install) o la configuración técnica (application) Figura 23. Archivo manifest.py David Salgueiro Alija 69 Figura 24. Arquitectura Odoo 4 David Salgueiro Alija 70 5.2 Arquitectura física La arquitectura física de un sistema en Odoo es la forma en que se implementa y despliega el software para un entorno de producción. Se refiere a la estructura de todos los componentes del sistema, incluyéndose hardware y dispositivos. Es una representación tangible de cómo se implementa y organizan todos estos componentes en un entorno de producción. En la siguiente figura se muestra un diagrama detallado de la arquitectura física de nuestro sistema. Figura 25. Arquitectura física David Salgueiro Alija 71 5.3 Diagramas de secuencia Los diagramas de secuencia son diagramas utilizados en proyectos software para representar visualmente la interacción entre objetos o componentes de un sistema a lo largo del tiempo. Estos diagramas muestran cómo los objetos interactúan entre sí y envían mensajes y respuestas en una secuencia temporal, proporciona el flujo de eventos en un determinado escenario. En las siguientes figuras se encuentran los diagramas de flujo del sistema Encuesta2. Figura 26. Diagrama secuencia 1 David Salgueiro Alija 72 Figura 27. Diagrama secuencia 2 David Salgueiro Alija 73 5.4 Diseño de la interfaz de usuario 5.4.1 Página login En la página de login los usuarios registrados podrán iniciar sesión en la plataforma. Figura 28. Login 5.4.2 Página web El proyecto Encuesta2 dispone de una página web de inicio en la que se explica las características principales de la plataforma. También existe un botón de login que redirige a la página de login. Figura 29. Web Encuestados David Salgueiro Alija 80 • JavaScript: JavaScript se utiliza en Odoo para la programación en el lado del cliente. Permite la creación de interacciones dinámicas y la personalización de la interfaz de usuario. Con JavaScript, puedes agregar comportamientos específicos a los elementos de la interfaz de Odoo, realizar validaciones en cliente, interactuar con servicios web y realizar operaciones en el cliente sin necesidad de realizar una petición al servidor. Figura 44. Logo JavaScript • HTML/CSS: HTML (HyperText Markup Language) y CSS (Cascading Style Sheets) se utilizan para definir la estructura y la presentación de la interfaz de usuario del proyecto. HTML se utiliza para crear la estructura de las páginas web, mientras que CSS se utiliza para aplicar estilos y dar formato a los elementos visuales de la interfaz. También es usado para crear plantillas de correo electrónico. Figura 45. Logo HTML David Salgueiro Alija 81 • PostgreSQL: Aunque no es un lenguaje de programación en sí mismo, es importante mencionar que Odoo utiliza PostgreSQL como su sistema de gestión de base de datos. PostgreSQL es un potente sistema de base de datos relacional y es utilizado por Odoo para almacenar y gestionar los datos de la aplicación, como los registros de los modelos, las configuraciones y los datos del usuario. Para la gestión se usa pgAdmin que es una interfaz gráfica de administración de PostgreSQL que permite administrar, mantener y realizar tareas relacionadas con bases de datos de forma visual y eficiente. El lenguaje que se emplea para gestionar y manipular las bases de datos relacionales es SQL. Figura 46. Logo PostgreSQL • App.diagrams.net: es una aplicación que se utiliza en un entorno web y es útil para hacer diferentes tipos de gráficos y diagramas. Figura 47. Logo AppDiagrams.net David Salgueiro Alija 82 6.2 Detalles de la implementación La implementación de un proyecto en Odoo necesita considerar varios aspectos y seguir una determinada estructura. A continuación, se muestran los principales aspectos de la implementación del proyecto Encuesta2. 1) Requisitos: Antes de comenzar es importante establecer los requisitos funcionales, establecer los objetivos y el alcance del proyecto. Esto será útil para tener una visión global sobre el proyecto. 2) Configuración inicial: En esta etapa del proyecto se instala Python y se crea un environment con todas las librerías necesarias que requiere odoo15. Todas estas librerías están definidas en el fichero requirementes.txt de odoo15. Posteriormente se pasa a la configuración de eclipse con el environment y se configurar la conexión con PostgreSQL. 3) Estructura de datos: En Odoo los datos se organizan en modelos que representan entidades como pueden ser alumnos, profesores, cursos o encuestas. 4) Desarrollo de módulos: En Odoo, todas las funcionalidades se implementan mediante módulos que pueden ser desarrollados por terceros y personalizados por el desarrollador o directamente desarrollado desde 0 por el desarrollador. En el proyecto Encuesta2 se realizan las dos acciones anteriores, partiendo de funcionalidad ya desarrollada se implementa nueva funcionalidad acorde con los requisitos del proyecto. 5) Personalización de la interfaz: La interfaz del proyecto Encuesta2 está adaptada al usuario final de la plataforma de manera que sea simple e intuitiva. 6) Pruebas y depuración: Al finalizar el desarrollo del proyecto es necesario realizar pruebas de implementación. Se realizan pruebas de caja negra y pruebas de caja blanca que garanticen el correcto funcionamiento de la plataforma. David Salgueiro Alija 83 David Salgueiro Alija 84 Capítulo 7 – Pruebas y evidencias 7.1 Pruebas de caja blanca Las pruebas de caja blanca son técnicas utilizadas en los proyectos software para evaluar la calidad y funcionalidad de un programa de una computadora. El objetivo principal de las pruebas de caja blanca es asegurar que las diferentes rutas de ejecución dentro del código se han probado de manera exhaustiva. Para lograr esto, se crean casos de prueba basados en el conocimiento interno de cómo funciona el programa. Esto implica evaluar los bucles, condiciones lógicas y el flujo de datos dentro del sistema. Para evaluar el correcto funcionamiento del sistema, se han ejecutado las siguientes pruebas en el proceso de codificación. • Validación de comunicación del entorno de Odoo con PostgreSQL. • Validación del campo teléfono • Validación del campo email • Validación de fechas. • Validación de datos introducidos con los datos realmente almacenados en BBDD. • Validación de bucles y condiciones lógicas. • Validación de las funcionalidades implementadas • Validación del la integración de las nuevas funcionalidades con Odoo. • Validación del correcto funcionamiento del correo electrónico SMTP. 7.2 Pruebas de caja negra y evidencias Las pruebas de caja negra son técnicas utilizadas para evaluar el comportamiento de un sistema sin necesidad de conocer los detalles internos de implementación. En estas pruebas el software es tratado como si fuese una “caja negra” en la que no se tiene acceso al código fuentes y se evalúa a través de las entradas y salidas en el sistema. El principal objetivo de estas pruebas es verificar que el software funciona según los requisitos y especificaciones establecidas. Se centran en probar la funcionalidad y la interfaz de usuario. En las siguientes tablas se muestran las pruebas de caja negra que he realizado en la plataforma. David Salgueiro Alija 85 PCN-01 Objetivo Registrar curso Precondiciones Que el usuario haya hecho login como administrador Datos de entrada Año del curso, fecha de inicio, fecha de fin, cuatrimestre Acción esperada Al pulsar el botón guardar se guardará el cuatrimestre Resultado Satisfactorio PCN-02 Objetivo Registrar departamento Precondiciones Que el usuario haya hecho login como administrador Datos de entrada Nombre del departamento Acción esperada Departamento guardado Resultado Satisfactorio PCN-03 Objetivo Registrar asignatura Precondiciones Que el usuario haya hecho login como administrador Datos de entrada Nombre Estudiante Profesor Curso Acción esperada Al pulsar el botón guardar el departamento quede registrado Resultado Satisfactorio PCN-04 Objetivo Prueba funcionamiento Servidor SMTP Precondiciones Que el usuario haya hecho login como administrador Datos de entrada Servidor SMTP Puerto SMTP Autentificación Seguridad Nombre de usuario Contraseña Acción esperada Prueba de conexión exitosa Resultado Satisfactorio David Salgueiro Alija 86 PCN-05 Objetivo Registrar profesor Precondiciones Que el usuario haya hecho login como administrador Datos de entrada Nombre Primer Apellido Segundo apellido Genero Fecha de nacimiento Correo electrónico Teléfono Departamento. Acción esperada Al pulsar el botón guardar, registro del profesor Resultado Satisfactorio PCN-06 Objetivo Registrar alumno Precondiciones Que el usuario haya hecho login como administrador Datos de entrada Nombre Primer apellido Segundo apellido Genero Correo electrónico Fecha de nacimiento móvil Acción esperada Al pulsar el botón guardar, registro del alumno Resultado Satisfactorio PCN-07 Objetivo Crear encuesta Precondiciones El usuario debe haber iniciado sesión como profesor Datos de entrada Título de la encuesta Cuestionario Descripción Mensaje final Opciones Acción esperada Al pulsar el botón guardar, registro guardado Resultado Satisfactorio David Salgueiro Alija 87 PCN-08 Objetivo Enviar encuesta por email Precondiciones Que la encuesta haya sido creada Datos de entrada Asignaturas Correos electrónicos adicionales Asunto Plantilla Fecha límite de respuesta Acción esperada Que los correos electrónicos reciban su encuesta. Resultado Satisfactorio PCN-09 Objetivo Responder encuesta Precondiciones Que el usuario estudiante haya recibido la encuesta en su email. Datos de entrada Respuestas de las preguntas Acción esperada Que las respuestas sean enviadas al servidor Resultado Satisfactorio PCN-10 Objetivo Visualizar datos almacenados Precondiciones Que las encuestas hayan sido respondidas Datos de entrada Pulsar botón ver resultados de la encuesta elegida Acción esperada Mostrar resultados Resultado Satisfactorio David Salgueiro Alija 88 PCN-11 Objetivo Inicio de sesión Precondiciones Que el usuario este registrado Datos de entrada Usuario Contraseña Acción esperada Que haga login correctamente Resultado Satisfactorio David Salgueiro Alija 89 David Salgueiro Alija 96 Figura 59. Envío encuestas En la pestaña “ver resultados” podrá visualizar todos los resultados relativos a la encuesta. Figura 60. Visualización de resultados David Salgueiro Alija 97 En la pestaña “crear sesión en vivo” el usuario podrá crear sesión en directo de las respuestas de sus alumnos. Figura 61. Crear sesión en vivo En la pestaña “Test” el usuario podrá visualizar un ejemplo de cómo se le muestra la encuesta a los evaluados. Figura 62. Test de encuestas En la pestaña “Imprimir” el usuario podrá visualizar la encuesta para ser impresa en papel. David Salgueiro Alija 98 Figura 63. Imprimir encuestas • Menú chat: En este menú los usuarios se podrán poner en contacto con otros usuarios de la plataforma a través del chat, llamada o videollamada. Figura 64. Menú chat David Salgueiro Alija 99 David Salgueiro Alija 100 Capítulo 9 – Conclusiones y mejoras 9.1 Conclusiones Una vez finalizado el proyecto, es interesante analizar cómo ha ido evolucionando su desarrollo. Al inicio del proyecto, Odoo era una tecnología desconocida para mí en la que nunca había desarrollado anteriormente nada. Tan solo había realizado un curso de 40h que me permitió crear una visión de las posibilidades que tenía esta tecnología. También el lenguaje de Python era prácticamente nuevo porque solamente había visto algunos aspectos durante la carrera, pero no todas las posibilidades de desarrollo que nos ofrece. Por lo que el primer paso para el desarrollo del proyecto fue la formación y el aprendizaje mediante prueba y error. Los comienzos nunca son fáciles, siempre tenemos una incertidumbre a la hora de abordar nuevos proyectos que usan tecnologías inicialmente desconocidas. Sin embargo, considero que he conseguido superar con mayor o menor éxito cada uno de los objetivos del proyecto. Este proyecto me ha dado fuerzas y confianza en mí mismo para desarrollar nuevos proyectos aunque desconozca la tecnología. Como futuro ingeniero informático, considero que tengo una base sólida de conocimientos que permite afrontar y adaptarme a nuevos proyectos con tecnologías totalmente nuevas. El principal objetivo del proyecto era la creación de una aplicación que permitiese a los profesores realizar encuestas personalizadas que fuesen respondidas por los estudiantes. Además, la tecnología usada permite abrir diferentes líneas de mejora para implementar en un futuro. Como conclusión final, el proyecto Encuesta2 ha sido un proyecto en que ha habido mucha labor de investigación y aprendizaje además me ha permitido aumentar mi confianza frente a nuevos proyectos. He disfrutado del desarrollo de este proyecto viendo como la tecnología permite a los usuarios mejorar y hacer más fácil la vida. Hace ya muchos años que tomé la decisión de formarme en esta rama del conocimiento por las oportunidades prácticamente ilimitadas de mejorar la vida de las personas. Una decisión de la que no me voy a arrepentir. David Salgueiro Alija 101 9.2 Propuestas de mejoras El proyecto Encuesta2 tiene una perspectiva abierta por lo que permite muchos caminos a seguir para poder mejorarlo. Odoo cuenta con un enfoque modular que permite que el desarrollador pueda seleccionar y personalizar las aplicaciones y módulos específicos que mejor se adapten al proyecto. En el proyecto Encuesta2 podríamos seguir usando el paquete de aplicaciones desarrollado por OpenEducat. Entre estas aplicaciones tenemos acceso para padres, creación de un entorno de aula virtual, ERP, módulo de exámenes, pago de tasas, etc. Esto nos permite un amplio abanico de caminos a seguir como mejora del proyecto. Por otro lado, podríamos avanzar en el desarrollo de las encuestas. Una opción podría ser desarrollar un módulo que permita imprimir en papel todos los resultados y ofrezca poder crear diferentes gráficos y adaptarlos al gusto de cada usuario. También se podrían incluir herramientas de análisis de datos para tomar mejores decisiones con los datos obtenidos. Actualmente el proyecto se encuentra instalado en el entorno local, como mejora se podría implementar el proyecto en un servidor externo con un domino y una dirección web propia que sea accesible desde Internet. David Salgueiro Alija 102 9.3 Referencias: Bibliografía y webgrafía • Python Software Foundation. (s. f.). Descarga Python. Recuperado el 3 de marzo de 2023, de https://www.python.org/ • Odoo. (s. f.). Instalación de Odoo guía oficial. Recuperado el 4 de marzo de 2023, de https://www.odoo.com/documentation/14.0/administration/install/install.html#so urce-install • Odoo. (s. f.). Estructura de un módulo. Recuperado el 4 de marzo de 2023, de https://www.odoo.com/documentation/14.0/developer/howtos/backend.html?hig hlight=module%20structure#module-structure • Odoo. (s. f.). Definición de modelo. Recuperado el 5 de marzo de 2023, de https://www.odoo.com/documentation/16.0/developer/reference/backend/orm.ht ml#models • Odoo. (s. f.). Permisos de acceso y reglas de grupos. Recuperado el 6 de marzo de 2023, de https://www.odoo.com/documentation/14.0/applications/general/users/access_ri ghts.html? • Odoo. (s. f.). Crear environment Python. Recuperado el 6 de marzo de 2023, de https://www.odoo.com/documentation/14.0/developer/reference/addons/orm.ht ml • Odoo. (s. f.). Grupos y reglas. Recuperado el 6 de marzo de 2023, de https://www.odoo.com/documentation/14.0/applications/general/users/access_ri ghts.html? • Odoo S.A… (s.f.). Descarga Odoo 15 . Recuperado el 7 de marzo del 2023, desde https://github.com/odoo/odoo • PostgreSQL Global Development Group (s.f.). Descarga PostgreSQL . Recuperado el 7 de marzo del 2023, desde https://www.postgresql.org/download/windows/ • Eclipse Foundation (s.f.). Descarga Eclipse . Recuperado el 8 de marzo del 2023, desde https://www.eclipse.org/downloads/ • Odoo S.A… (s.f.). Odoo . Recuperado el 10 de marzo del 2023, desde https://www.odoo.com/es_ES • OpenEducat (s.f.). OpenEducat . Recuperado el 10 de marzo del 2023, desde https://openeducat.org/ • OpenEducat Student (s.f.). OpenEducat Student . Recuperado el 10 de marzo del 2023, desde https://openeducat.org/feature-core#student • OpenEducat Faculty (s.f.). OpenEducat Faculty . Recuperado el 10 de marzo del 2023, desde https://openeducat.org/feature-core#faculty David Salgueiro Alija 103 • Odoo S.A… (s.f.). Módulo survey Odoo . Recuperado el 20 de abril del 2023, desde https://www.odoo.com/es_ES/event/conoce-el-modulo-gratuito-encuestas- de-odoo-3334/register • SurveyMonkey Inc… (s.f.). Web SurveyMonkey . Recuperado el 29 mayo del 2023, desde https://es.surveymonkey.com/ • Moodle Pty Ltd… (s.f.). Encuestas Moodle . Recuperado el 29 mayo del 2023, desde https://docs.moodle.org/all/es/Agregar_una_Encuesta • Universidad De Valladolid… (s.f.). Encuesta docente UVA . Recuperado el 29 mayo del 2023, desde https://encuestadocente.uva.es/ • Copia de seguridad Odoo. (s. f.). En Noviello. Recuperado el 2 de junio de 2023, de https://noviello.it/es/como-configurar-la-copia-de-seguridad-automatica-con- odoo/?utm_content=cmp-true • Creación de gráficos en Canva. (s. f.). En Canva. Recuperado el 4 de junio de 2023, de https://www.canva.com/es_es/