# U Helper ![](https://i.imgur.com/oVTolaU.png) **Aplicación U Helper** **Documento de conceptualización** **Versión 1.0 de la aplicación** **Versión 1.0 del documento** [TOC] ## Introducción El propósito de este documento es explicar detalladamente el proceso de desarrollo que se llevó a cabo para la creación de la aplicación UHelper. De manera específica, busca mencionar la metodología que siguió el proyecto, las tecnologías y artefactos utilizados y los objetivos de la aplicación. Este documento está estructurado de manera que primero se mostrará una breve introducción del proyecto junto a los desarrolladores de la aplicación. Posteriormente, en la descripción general, se abarcará el propósito y las funcionalidades de la aplicación (también mediante prototipos). Finalmente se mostrarán los aspectos técnicos y más "internos" al desarrollo del proyecto, que son los artefactos de la base de datos y las decisiones técnicas realizadas. El objetivo principal de la aplicación U Helper es facilitar, mediante distintas funcionalidades específicas, la experiencia universitaria de los estudiantes de la Universidad de Costa Rica. De una manera más concreta, esta aplicación busca facilitar los procesos de: comunicación con distintas instituciones de la Universidad de Costa Rica (mediante un acceso rápido a los contactos), manejar un horario de los cursos matriculados en el semestre y encontrar la ubicación de la clase de cada curso matriculado. ## Listado de equipos y miembros de los equipos ### Sprint 1 * Look and feel * Scrum Master * Database master * Documentación | Name | Carné | Rol | | ------ | ------ | ----- | | Daniel Salazar Mora | B87214 |Documentación| | Ricardo Franco Rodriguez| B83050 |Database master| | Josué Araya Murillo| B30478 |Look and feel| | Diego Trejos Echeverria | B57233 |Scrum Master| | Denis Solano Padilla | B59304 |Look and feel| ## Descripción general ### Descripción Antes de describir la aplicación en sí, es mejor contextualizar la razón de la existencia de UHelper. No conocer a fondo la Universidad de Costa Rica, puede resultar muy estresante para los estudiantes y más para los de primer ingreso. El tener que preocuparse porque no se sabe dónde se va a recibir la clase debería ser el menor de los problemas. Por lo tanto, se nos ocurrió la solución que presenta la aplicación UHelper. En el app, se selecciona el aula del curso respectivo, y se obtiene la dirección del edificio en Google Maps (único api a utilizar momentáneamente) y además, una breve descripción de la ubicación del aula dentro de dicho edificio. Esta funcionalidad se relaciona directamente con el epic "Localización de aulas" presentado en el backlog. Aunque esa es la funcionalidad principal, este app también busca facilitar otras funcionalidades, como la de tener el horario y tener una agenda con los contactos a las instituciones dentro de la Universidad de Costa Rica. Estas funciuonalidades se relacionan con los epics de "Administración del horario de usuario" e "Información de contactos de ayuda-asistencia" respectivamente. Para poder tener todas estas funcionalidades dentro del mismo app, se recurre al epic de "Navegación" que propone la creación del drawer que contendrá las opciones para que el usuario pueda seleccionarlas fácilmente. Finalmente, hay que almacenar todos estos datos del usuario y justamente es lo que propone el epic "Administración de perfiles" ya que crea usuarios, con sus respectivos correos electrónicos y contraseñas como autorización, que pueden tener toda la información mencionada anteriormente relacionada directamente a su perfil. ### Requerimientos funcionales * **R1:** Que el usuario pueda crear una nueva cuenta con su información personal para que pueda utilizar la aplicación. Este requerimiento se relaciona directamente con la historia de usuario MV2021A3-6. * **R2:** El usuario requiere poder iniciar sesión al utilizar sus credenciales de manera correcta para poder utilizar las funcionalidades que provee la aplicación. Este requerimiento se relaciona directamente con la historia de usuario MV2021A3-7. * **R3:** El usuario requiere de un menú (drawer) para poder tener una experiencia agradable de navegación dentro del app a la hora de buscar funcionalidaedes. Este requerimiento se relaciona directamente con la historia de usuario MV2021A3-15. * **R4:** El usuario requiere de tener a disposición una agenda con contactos oficiales de instituciones dentro de la Universidad de Costa Rica para facilitar su posibilidad de comunicarse adecuadamente con ellas (y de una manera rápida). Este requerimiento se relaciona directamente con la historia de usuario MV2021A3-18. * **R5:** El usuario requiere poder editar la información de su perfil para poder actualizar sus datos personales cuando sea necesario. Este requerimiento se relaciona directamente con la historia de usuario MV2021A3-10. * **R6:** El usuario requiere poder cambiar su contraseña cuando la haya olvidado o por gusto propio por motivos de seguridad. Este requerimiento se relaciona directamente con la historia de usuario MV2021A3-9. ### Requerimientos no funcionales * **R1:** Realizar llamados a la base de datos de manera asincrónica para asegurar que el thread principal se encargue de la interfaz con la que interactúa el usuario. * **R2:** El usuario puede acceder a las funcionalidades principales del app de la manera más simple posible desde el menú. * **R3:** La aplicación no aceptará contraseñas menores a 4 caractéres por cuestiones de seguridad. * **R4:** La aplicación no aceptará registrar más de una cuenta relacionada a un mismo correo por cuestiones de identificación y seguridad. * **R5:** La aplicación no aceptará un carné que no esté conformado por una letra y cinco números o por seis números. ## Prototipos de la aplicación A continuación se muestran algunos prototipos de manera muy general. Para ver la totalidad de los prototipos, se presenta el siguiente enlace: https://www.figma.com/file/WofkkGz5UD7ZUjpHCeICRK/U-helper?node-id=0%3A1 ### Página de inicio ![](https://i.imgur.com/TBFJCiU.png) ### Actividad de iniciar sesión ![](https://i.imgur.com/JyTq5fB.png) --- ![](https://i.imgur.com/reyXf6Z.png) ### Actividad de registro ![](https://i.imgur.com/9EYceMa.png) --- ![](https://i.imgur.com/3Zb1XIN.png) ### Actividad de ver contactos ![](https://i.imgur.com/0Ssvb02.png) --- ![](https://i.imgur.com/CKMJ5uy.png) ### Drawer ![](https://i.imgur.com/y1lpehb.png) ### Actividad de editar perfil ![](https://i.imgur.com/h5nQgWG.png) --- ![](https://i.imgur.com/DbqvDbT.png) --- ![](https://i.imgur.com/ZZYGKmd.png) ![](https://i.imgur.com/C2z2G1M.png) ![](https://i.imgur.com/HkbnZEh.png) ![](https://i.imgur.com/ChVYObI.png) ![](https://i.imgur.com/yUnSe7E.png) ![](https://i.imgur.com/6zPB1Ej.png) ## Artefactos de la base de datos ### Esquema conceptual Se realizó un esquema conceptual EER de la base de datos, utilizando la herramienta de Lucidchart. A continuación se presenta una imagen de dicho esquema y el link donde se encuentra para poder verlo a mayor detalle. Enlace: https://lucid.app/lucidchart/invitations/accept/inv_7565cbfd-a123-4af1-b2b4-d05283d3847c ![](https://i.imgur.com/53LnQL5.png) ## Decisiones técnicas ### Metodología En este proyecto se aplicó una metodología ágil scrum, por lo que a los miembros del equipo se le asignaron roles específicos para dividirse distintas responsabilidades. Se aplicaron las respectivas acciones que caracterizan a las metodologías ágiles, como las reuniones de control de avances de funcionalidades y las reuniones de validación con el PO y/o interesados en el proyecto. Sin embargo, debido al contexto de pandemia se recurrió a la virtualidad en la comunicación entre miembros y con el PO o interesados en el proyecto, mediante las plataformas de Discord y Zoom. ### Artefactos utilizados * Documento con protipos (realizado en Figma) * Documento de conceptualización * Documento del esquema conceptual de la base de datos (realizado en Lucidchart) * Código (realizado con Java en Android Studio) * Backlog para organización de tareas (realizado en Jira) ### Tecnología Se utilizó Java como lenguaje de programación, en el ambiente de Android Studio. En la aplicación se utiliza la versión de Android 5.0, nivel del API 21 (como mínimo) y además, la base de datos es la de SQLite con la biblioteca de Room para facilitar el manejo de los datos. El manejo de la distribución de tareas fue realizado con Jira. ### Formatos de los commits Cada commit, si es de funcionalidad, deberá mencionar: breve descripción de cambios, desarrolladores que trabajaron, id historia de usuario y subtarea técnica respectiva (si la tiene) y como opcional WIP (work in progress). Si el commit es un arreglo, se deberá mencionar el tipo y brevemente qué se arreglo. ### Repositorio de código y estrategia de branches El código se encuentra en el siguiente repositorio de Bitbucket: https://bitbucket.org/lyonv/ecci_ci0161_i2021_g01_t03 Con respecto a la estrategia de branches, nuestro enfoque es el de trabajar por funcionalidades. De esta manera, los branches serán nombrados acorde a a la funcionalidad y facilitará el pair-programming entre miembros del equipo. Además, al tener el nombre de la funcionalidad será más sencillo de identificarlo en caso de que se requiera. También es importante mencionar que se utilizó la técnica de integración continua y que se utilizaron pull requests para realizar commits en máster(requeriendo un mínimo de dos vistos buenos). ### Definición de listo Para subir un commit a master, se debe realizar la técnica de jalar master dentro de la rama a mezclar y posteriormente asegurarse que: 1. No rompa la arquitectura. 2. Debe completar una tarea técnica. 3. Seguir principios de *clean code* básico. 4. Master continúe funcional. 5. La historia de usuario relacionada a la funiconalidad debe estar ya validada por el PO.