Documentos de Académico
Documentos de Profesional
Documentos de Cultura
J Matamoros Set FM 1217 Memoria
J Matamoros Set FM 1217 Memoria
i
FICHA DEL TRABAJO FINAL
El proyecto procura llevar a cabo una propuesta de app móvil intranet para la
UNED Costa Rica, llamada “IntraUNED”, teniendo los principales servicios
que se pueden brindar a los funcionarios de esta y a su vez documentar los
procedimientos sobre el desarrollo de aplicaciones para dispositivos móviles.
La metodología del proyecto se pretende llevar a cabo en tres etapas, la
primera, una definición clara sobre los requerimientos, los usuarios de la app y
la creación del diseño conceptual de la misma, la segunda etapa, la cual
corresponderá al desarrollo de la propuesta de app, esto basado en la
conceptualización de la etapa anterior, la tercera etapa consiste en finalizar los
últimos detalles de la propuesta y documentar todo el procedimiento mediante
la realización de una memoria y presentación final.
Se pretende que dicha app sea una base para que la misma pueda crecer en un
futuro cercano y también que este desarrollo cree una experiencia importante
para la institución.
ii
Abstract
The project seeks to carry out a mobile intranet app proposal for UNED Costa
Rica, having the main services that can be provided to the officials of this and in
turn document the procedures on the development of applications for mobile
devices. The methodology of the project is intended to be carried out in three
stages, the first, a clear definition of the requirements, the users of the app and
the creation of the conceptual design of the app, the second stage, which will
correspond to the development of the proposal of app, this based on the
conceptualization of the previous stage, the third stage is to finalize the last
details of the proposal and to document the whole procedure by means of the
realization of a memory and final presentation.
It is intended that this app is a basis for it to grow in the near future and also
that this development creates an important experience for the institution.
iii
iv
Índice
1. Introducción .................................................................................................... 1
1.1 Contexto y justificación del Trabajo ........................................................... 1
1.2 Objetivos del Trabajo................................................................................. 2
1.3 Enfoque y método seguido ........................................................................ 3
1.4 Planificación del Trabajo ........................................................................... 3
1.5 Breve sumario de productos obtenidos ..................................................... 4
1.6 Breve descripción de los otros capítulos de la memoria............................ 4
2. Resto de capítulos .......................................................................................... 5
3. Conclusiones ................................................................................................ 56
4. Glosario ........................................................................................................ 59
5. Bibliografía ................................................................................................... 61
6. Anexos ......................................................................................................... 62
v
Lista de tablas
Lista de Ilustraciones
vi
Ilustración 20 Función de creación de las marcas en el mapa ......................... 46
Ilustración 21 Captura de datos Firebase ......................................................... 46
Ilustración 22 Captura pantalla mapas ............................................................. 47
Ilustración 23 Arquitectura ................................................................................ 49
1. Introducción
2
1.3 Enfoque y método seguido
El proyecto está estimado para ser desarrollo con una dedicación de 2 horas
por día, aproximadamente, de lunes a sábado.
Ver anexo #1
3
1.5 Breve sumario de productos obtenidos
A continuación, se describe brevemente cada uno de los capítulos que componen esta
memoria:
Introducción
En dicho capítulo se realiza la presentación del proyecto, se expone cuál es la
motivación por la cual se lleva a cabo, también los principales objetivos que se desean
lograr a través del mismo.
Diseño conceptual
Se presentan los requisitos necesarios que deben desarrollarse a lo largo del proyecto
en un nivel conceptual.
Prototipado
Se exponen los prototipos de las principales pantallas de la aplicación.
Evaluación
Para afirmar que en el prototipo cumple con lo requerido, se realizaran ciertas pruebas
y se muestran resultados.
4
Diseño de la arquitectura
Se explica el diseño del API a realizar.
Desarrollo
Se describe como se ha llevado a cabo el proceso de implementación (desarrollo) de
cada una de las secciones del proyecto.
Testeo y pruebas
Se realiza un resumen sobre el resultado de algunas pruebas realizadas.
Conclusiones
En este capítulo se realiza una valoración general del proyecto, los objetivos
conseguidos y el trabajo pendiente a realizar en el futuro
2. Resto de capítulos
El otro grupo de usuarios, son todos los potenciales consumidores directos de la app,
los usuarios finales, estos son los más de 2900 funcionarios de la UNED, que posean
un smartphone con sistema operativo Android. Este segundo grupo de usuarios al ser
un grupo diverso se puede dividir en 3 subgrupos: los que tienen conocimiento básico,
intermedio y avanzado en relación al uso de aplicaciones y dispositivos móviles.
5
Una vez identificados estos grupos de usuarios se conformó un conjunto de trabajo
para enfocarse en determinar las principales funcionalidades, requerimientos
(funcionales y no funcionales), cuestiones de accesibilidad y aspectos más relevantes
que debe incluir la aplicación en su primera versión, este grupo de trabajo está
integrado por un usuario representante de los perfiles anteriormente citados (usuario
básico, usuario intermedio y usuario avanzado).
Usuario básico
Elizabeth Zuñiga
6
Analista de servicios Pinterest Que sea fácil de usar
Whatsapp
Que funcione bien
Observaciones
¿Tendremos ayuda para
usar la app?
¿Sera sencilla de usar?
Tabla 1 Usuario básico
Usuario intermedio
Amanda Monge
7
Usuario avanzado
Marino Sanchez
Se realizó una sesión con el usuario considerado stakeholder para determinar algunos
requisitos o recomendaciones iniciales del proyecto:
8
resultado una app con servicios que las personas
necesitan y usen a diario.
Lo anterior ayudaría a mejorar la imagen que tiene la
institución con respecto a la inclusión de nuevas
tecnologías de información y comunicaciones.
Defina tres metas u objetivos - Mantener a los funcionarios bien informados por
(cuantificables) que se esperaría medio de una aplicación móvil.
alcanzar con el proyecto - Aumentar la satisfacción de los funcionarios con
respecto a los servicios tecnológicos a su disposición
- Que la mayor parte de funcionarios instalen y usen la
aplicación.
Esta técnica permitió identificar cuáles eran algunos de los objetivos principales que el
usuario stakeholder podía brindar al proyecto. Es importante no perder de vista que, si
bien es diseño está centrado en el usuario, si se hace el enfoque solo a los usuarios
finales o bien con el enfoque de solo el desarrollador, se pueden omitir detalles
importantes que un usuario experto, en la creación y adopción de servicios digitales, si
puede contemplar.
Por ello es realmente importante identificar qué puede aportar este usuario para poder
organizar y clasificar los requisitos respecto a los usuarios finales.
En esta instancia se pudo identificar que el principal requisito o recomendación, que
este usuario puede comentar, es ofrecer a los usuarios finales todas las herramientas
o servicios posibles en la aplicación, de manera sencilla y eficiente.
9
Sesión inicial usuarios finales
Se realizó una sesión con 15 posibles usuarios finales, 5 de cada perfil, se hace un
resumen de lo más significativo a continuación:
¿Tiene referentes de aplicaciones móviles Ninguno ha usado alguna aplicación de este tipo.
similares, en los que usted haya tenido alguna
experiencia?
¿Cuáles son los servicios y contenidos que - Búsqueda de información sobre los centros y sedes de la
usted incluiría en una aplicación de este tipo? UNED.
- Calendario académico y de actividades.
- Poder realizar las gestiones más frecuentes, como
consultar y solicitar vacaciones y la boleta de pago.
- Información relevante sobre la institución, noticias.
¿Qué tipo de aplicaciones usa usted? Redes sociales, contenidos informativos, juegos,
productividad.
La reunión con usuarios permite ver la otra cara de la moneda, esto es, no solo los
objetivos del desarrollador (los planteados en la primera etapa) y lo recomendado por
el stakeholder, sino las expectativas reales que el usuario final esperaría cubrir con la
aplicación. Con esta técnica hay una aproximación básica a lo que el usuario quiere, a
sus necesidades, a lo que el realmente tomará del producto digital. En esta instancia
se cruzan, integrando o diferenciando, los objetivos planteados inicialmente con
necesidades de usuario.
Con los usuarios se pudo identificar que ellos asimilan muy bien la idea de tener una
aplicación móvil y con esta esperan que se tenga acceso a los servicios de forma más
inmediata y ágil.
10
Requisitos funcionales
Luego del análisis inicial del proyecto y de las distintas reuniones con los usuarios,
surgen los siguientes requerimientos funcionales para la aplicación en una primera
versión:
Pantalla de acceso (Login): la aplicación tendrá una pantalla de acceso que controlará
el ingreso y lo permitirá solamente a usuarios autorizados, funcionarios de la
institución.
Pantalla de inicio: la aplicación tendrá una página inicial que tendrá los iconos a forma
de menú de los principales servicios a disposición.
Directorio de personal: se debe tener una opción que muestre el directorio de personal
de la institución.
Repositorio de documentos: se tendrá una opción con acceso a un repositorio con los
principales documentos que se utilizan en la institución.
Consulta de boleta de pago: se tendrá una opción para consultar la boleta de pago
11
Solicitud y consulta de vacaciones: se tendrá una opción para poder solicitar
vacaciones y consultar el historial de solicitudes.
Localización (mapa): se tendrá una opción con un mapa que muestre la ubicación e
información básica de las distintas sedes de la UNED.
Consulta de activos fijos: se tendrá una opción para consultar los activos fijos ligados
al funcionario.
Requisitos no funcionales
Accesibilidad: la aplicación debe ser clara y debe seguir los patrones de accesibilidad
estándares.
Estabilidad: la aplicación debe ser capaz de controlar los posibles errores ocurridos
durante la ejecución de la misma.
Interfaz: Clara y concisa. No debe dar lugar a la confusión del usuario y debe seguir
los estándares de diseño.
12
Integración: La aplicación debe de integrarse con todo el sistema operativo de Android.
Hacer uso de las aplicaciones nativas si se necesita y mantener un diseño acorde al
sistema.
Diseño conceptual
Escenarios de uso
Escenario 1.
Escenario 2.
Un lunes por la tarde, Elizabeth regresa del trabajo hacia su casa, toma el autobús, es
hora pico y hay mucho tránsito, por lo que tardara una hora al menos para llegar a su
casa, recuerda que debe realizar una solicitud de vacaciones para el día siguiente por
lo que decide realizarla con su smartphone, mediante la app “IntraUNED”, Elizabeth no
tiene mucha experiencia con su teléfono inteligente, pero le ella instaló previamente, la
app, por lo que decide probarla, realizando la gestión durante el viaje, al inicio por su
13
falta de experiencia tarda un poco en entender su funcionamiento, pero al cabo de un
par de minutos conoce la organización de la app, selecciono la opción solicitud de
vacaciones, incluyo las fechas y finalizo la gestión, después de utilizarla durante el
viaje se da cuenta que no debe esperar llegar a su casa a encender el ordenador para
hacer la gestión, está satisfecha, con la app, logro realizar la solicitud durante el
trayecto a casa.
Escenario 3.
Durante una actividad laboral fuera de la oficina Amanda requiere conocer las sedes
que tiene la UNED en la zona sur del país, no está muy segura de las sedes existentes
por lo que para esta ocasión utiliza la app “IntraUNED”, ingresa a la app, comprueba el
menú de la pantalla inicial y selecciona la opción de mapa y ahí puede verificar las
distintas sedes de una forma sencilla y ágil.
Escenario 4.
14
Escenario Primer toque Segundo toque Tercer toque Cuarto toque
Escenario 1. Usuario Usuario recorre Usuario realiza
Usuario consulta el selecciona la la lista de una búsqueda
directorio de funcionarios opción del menú funcionarios -
y realiza una búsqueda de la pantalla
principal o
desde el menú
lateral
Escenario 2. Usuario Usuario ingresa Usuario realiza
Usuario desea realizar selecciona la las fechas la solicitud con
una solicitud de opción del menú deseadas éxito.
vacaciones de la pantalla -
principal o
desde el menú
lateral
Escenario 3. Usuario Usuario observa Usuario
Usuario desea observar selecciona la el mapa con las interactúa con
el mapa de sedes y opción del menú sedes el mapa y
algún detalle de alguna de la pantalla puede ver la -
principal o información de
desde el menú las sedes.
lateral
Escenario 4. Usuario Usuario Usuario
Usuario desea descargar selecciona la selecciona el descarga su
su boleta de pago opción del menú mes y el tipo de boleta con
de la pantalla boleta éxito. -
principal o
desde el menú
lateral
Tabla 6 Escenarios
Con la descripción de estos flujos, se propone una identificación sobre que debe pasar
en cada “toque” efectivo en la aplicación.
Muchas veces se desean muchas funciones y opciones en una aplicación, al mismo
tiempo, pero al identificar y comparar los principales objetivos que se plantean
inicialmente, con lo esperado por el usuario, se establecen cuáles son los toques que
se deben dar para llegar a la información o realizar el proceso deseado.
15
Se identificaron en este caso 4 acciones principales (probablemente sean muchas
más) que se trataron no tuvieran más de tres toques desde el acceso inicial, esto para
dar una sensación de facilidad y sencillez en el uso de la aplicación.
Prototipado
Las siguientes son las capturas de las pantallas del prototipo, aunque no son el
100% de las pantallas de este, se busca documentar las más que representen
las ideas de diseño y también ilustrar los argumentos más relevantes del mismo.
16
Pantalla inicial Menú lateral de la aplicación
17
Pantalla solicitud vacaciones Pantalla mapa sedes
18
Pantalla calendario institucional Pantalla directorio de personal
Evaluación
En el caso de la realización de una evaluación del prototipo en una etapa temprana del
proyecto es de vital importancia porque brinda la posibilidad de detectar fallos para
mejorar la interfaz de un producto de software o como en este caso, el prototipo de
una aplicación, esto a partir de valoraciones cualitativas del mismo o de sus
componentes.
Por lo que se desea establecer el grado de usabilidad que tiene el prototipo se deben
obtener datos cuantitativos, a partir de una medición objetiva de algunas métricas
como la efectividad, eficiencia, cumplimento y satisfacción, esto porque, como lo indica
la definición de usabilidad de ISO, son atributos de la usabilidad de un producto de
software (ISO 9241-II:1998, 1998).
Dicha medición de atributos proporcionara un valor o valores del grado de usabilidad
que tiene el prototipo. La siguiente figura resume los conceptos necesarios para
19
evaluar la usabilidad de un producto software a través de las relaciones entre los
elementos de una interfaz y la interacción del usuario en la realización de tareas.
Con lo anterior descrito el objetivo principal de las pruebas es detectar y verificar los
errores de diseño cometidos, con la ayuda de los posibles usuarios finales y el
stakeholder. Con estas pruebas se espera detectar los posibles defectos de usabilidad
y permiten establecer recomendaciones de rediseño destinadas a mejorar el prototipo
y con esto el producto final.
20
Las pruebas o revisiones a realizar que se planifico realizar al prototipo son las
siguientes:
Revisión de estándares
Simulaciones de diseño
La idea es que se hagan al menos 3 sesiones con los usuarios finales y el stakeholder,
el plan de la prueba seria que una persona tome el papel de usuario final mientras que
se le orienta por una serie de tareas reales que tiene que realizar sobre el prototipo,
con esto se busca determinar si el prototipo es intuitivo para el usuario final.
21
Técnicas de filtrado
En este caso dichas técnicas también serán de gran apoyo, esto porque son
actividades sencillas y sin coste alguno, que brindaran ayuda importante a la hora de
identificar barreras potenciales a la accesibilidad en el diseño del prototipo.
Se deben realizar pruebas como usar el prototipo con algún tipo de lentes que
disminuyan la visión, esto para comprobar cómo se comporta la interfaz, iconos,
colores y demás en una situación así. También se deben realizar pruebas con guantes
que dificulten tomar el dispositivo, con lo cual, de igual forma que la prueba anterior se
busca verificar cómo se comporta el prototipo ante una situación así.
Actores
Comentarios Ninguno
Tabla 7 Actores
22
Casos de uso
Consultar directorio de
Ingresar a la aplicación personal
Consultar calendario
Consultar repositorio
documentos
Usuario final
Consultar boleta pago
Consultar mapa
Consultar activos
Consultar vacaciones
Solicitar vacaciones
Ilustración 2
23
CU-1 Ingresar a la aplicación
Actores Usuario final
Descripción La aplicación deberá comportarse como se describe en el
caso de uso cuando un usuario intenta ingresar en la
aplicación.
Precondiciones -
24
Descripción La aplicación deberá comportarse como se describe en el
caso de uso cuando un usuario presiona la opción consulta del
calendario.
Precondiciones -
25
caso de uso cuando un usuario presiona la opción consulta de
boleta de pago
Precondiciones -
26
mapa (sedes)
Precondiciones -
27
Precondiciones -
Diseño de la arquitectura
Diseño de la API
En el caso de la aplicación no utilizara una base datos propia como tal, ni interna ni
externa, esto porque la estructura de esta planteada a consumir una API REST la cual
será la que se comunique con las bases de datos de donde se extraerá la información
y se mostrara en la aplicación.
Las ventajas que supone esta estructura son muy buenas, puesto que la gestión de la
información queda en la infraestructura de la UNED, lo que clarifica y facilita el
desarrollo de la aplicación. La escalabilidad y encapsulación son otras de las ventajas
28
más destacables de este modelo, permitiendo aumentar funcionalidades o recursos de
ambos por separado.
Documentos Vacaciones
Tiene Codigo solicitud
Descripcion
Perfil Funcionario
Nombre Activos
Consulta
Identificacion
Tiene Codigo
-Oficina
Descripcion
Consulta
Sedes
Consulta Nombre
Calendario Descripcion
Año
Mes
Actividades
Dia
Ilustración 4 Clases
29
Arquitectura de la aplicación
Desarrollo
Para el desarrollo de la aplicación se ha tenido en cuenta que debe ser una aplicación
intuitiva y fácil de usar. Se ha divido la aplicación en diferentes bloques, los
correspondientes a esta parte del proyecto son los siguientes:
30
API general para consumo de la aplicación
Estructura general de la aplicación.
Pantalla splash
Pantalla login
Menú lateral
Pantalla inicial
Pantalla calendario
Pantalla directorio
Pantalla Activos
Pantalla consulta vacaciones
Pantalla solicitud vacaciones
Pantalla sedes
Pantalla perfil
31
Herramientas usadas
Aplicación Android
Sugar ORM: Esta herramienta se encarga de gestionar las bases de datos SQLite. Se
ha empleado en el proyecto para diseñar y gestionar operaciones sobre la base de
datos local de la aplicación.
Librería volley: Volley es una librería HTTP que facilita la creación de enlaces para
aplicaciones Android, es considerada una de más rápidas y eficientes.
Diseño
Navigation Drawer
32
Ilustración 6 Modelo navigation drawer
El navigation drawer es una vista que actúa como menú para cambiar entre los
distintos Fragments o pantallas de la aplicación. El drawer se oculta automáticamente
cuando el usuario está usando la aplicación, por lo que permite a los Fragments
ocupar el mayor tamaño de pantalla posible.
El drawer por defecto, dispone de un adaptador que te permite mostrar los elementos,
pero solo con texto, por lo tanto, hubo se crearon nuevas vistas personalizadas.
En términos más específicos, cada ítem del drawer, está formado por un layout que
contiene un ImageView y un TextView respectivamente.
Como se mencionó anteriormente, esta aplicación se basa en el patrón de diseño de
Drawer + Fragments. Para comprender el comportamiento principal de la aplicación es
necesaria conocer que es un Fragment:
Un Fragment representa un comportamiento o una porción de interfaz de usuario en
una actividad. Puede combinar múltiples fragmentos en una sola actividad para
construir una interfaz de usuario multi-panel y reutilizar un fragmento en múltiples
actividades (Google, 2017).
33
Se puede entender un fragment como una sección modular de una actividad, que tiene
su propio ciclo de vida, recibe sus propios eventos de entrada y que se pueden
agregar o quitar mientras que la actividad esté en marcha (algo así como una "sub
actividad" que pueda reutilizar en diferentes actividades) (Google, 2017).
.
Por tanto, todo fragment necesita una actividad y una vista donde implementarse
(Contenedor fragment). Este contenedor puede mostrar un fragment a la vez,
pudiendo cambiar en tiempo de ejecución el fragment que se muestra.
Al pulsar sobre un ítem del drawer, el fragment principal de la aplicación se cambiará
por el correspondiente fragment creado para cada uno de los ítems del drawer.
Carga de fragments
Pantalla splash
34
Ilustración 7 Captura pantalla Splash
Pantalla Login
35
Ilustración 8 Captura sección código consumo API login
Modelo de datos para almacenar la persistencia de los datos obtenidos del consumo
del API
36
Ilustración 9 Captura pantalla login
Menú lateral
Como se explicó al inicio del apartado se utilizó un menú lateral con un “navigation
drawer”. Esto porque con la llegada de Material Design a Android, los menús laterales
se mejoraron con tal de facilitar la usabilidad de las aplicaciones, por dicha razón se
incluyó en la aplicación. Dicho menú cuenta con todas las opciones disponibles en la
aplicación, proveyendo al usuario de todas las opciones independientemente de la
pantalla en donde se encuentre.
37
Ilustración 10 Captura sección asignación de algunas de las opciones menú lateral
38
Pantalla inicial
Pantalla calendario
39
En las fechas que se tienen actividades, u otras acciones, se muestra una marca en el
calendario, dichas actividades están almacenadas en una base de datos en la
institución y son consumidas mediante el API para poder ser mostradas en el
calendario.
40
Ilustración 14 Captura pantalla calendario
Pantalla directorio
41
Ilustración 15 Captura pantalla directorio
42
Pantalla Activos
43
Pantalla consulta vacaciones
44
Pantalla solicitud vacaciones
45
Pantalla sedes
46
Ilustración 21 Captura pantalla mapas
47
Arquitectura
Para que sea posible el acceso de múltiples usuarios a una información de las bases
de datos comunes es necesario usar una arquitectura cliente/servidor mediante un
API.
Esta arquitectura consiste básicamente en un cliente que realiza peticiones a otro
programa (servidor) que le da respuesta.
Aplicado al presente caso de estudio, nuestra aplicación Android haría la función de
cliente haciendo peticiones a nuestro servidor para obtener o modificar datos.
Cabe destacar también que es una arquitectura de 3 capas, quiere decir que es un
conjunto de subsistemas cada uno de los cuales depende del que se encuentra en la
capa inferior y proporciona los cimientos del que se encuentra inmediatamente por
encima de él.
La arquitectura de tres capas es de las más habituales en sistemas informáticos y
podemos distinguir los siguientes niveles:
48
Ilustración 22 Arquitectura
Testeo y pruebas
Pruebas de rendimiento
49
Samsung Note 8 Huawei P9 lite Samsung j7
Octa-core (4x2.3 Octa-core (4x2.0 Octa-core 1.6
Procesador GHz & 4x1.7 GHz) GHz Cortex-A53 & GHz Cortex-
4x1.7 GHz Cortex- A53
A53)
RAM 6 GB RAM 3 GB RAM 3 GB RAM
S.O Android 7.1.1 Android 6.0 Android 6.0.1
(Nougat) (Marshmallow) (Marshmallow)
Pantalla 6.3 inches 5.2 inches 5.5 inches
Tabla 17 Dispositivos utilizados en las pruebas
50
Samsung Note 8 Huawei P9 lite Samsung j7
Inicio y carga
(primera 5.1 segundos 6.0 segundos 7.1 segundos
vez)
Inicio y carga
2.1 segundos 3.2 segundos 4.2 segundos
Descarga de
elementos 5.5 segundos 6.7 segundos 7.3 segundos
del directorio
Descarga de
elementos 5.1 segundos 6.0 segundos 7.1 segundos
del
calendario
Descarga de
elementos 4.1 segundos 5.0 segundos 6.1 segundos
del historial
vacaciones
Mostrar
mapas 3.5 segundos 5.5 segundos 6.5 segundos
Otro factor a analizar para saber si la aplicación cumple con los requisitos necesarios
de cara al cliente es realizar pruebas para determinar el agrado del usuario.
La población utilizada para estas pruebas constaba del mismo equipo que colaboro al
inicio para la definición de los requisitos de la aplicación.
Para este cometido se ha realizado una encuesta a estos usuarios, donde se
preguntaban sobre las siguientes cuestiones:
51
Las opciones de la aplicación son de fácil de comprensión para el usuario
52
La interfaz gráfica de la aplicación es llamativa y amigable
53
En esta pregunta pudimos comprobar como los usuarios consideraban notable el
tiempo de respuesta. Según lo observado la opción de directorio y el mapa de sedes
son las que más pueden tardar la primera vez que se cargan.
Observando esta pregunta se puede deducir que los usuarios están satisfechos con la
funcionalidad obtenida en esta primera versión de la aplicación. Algún usuario ha
valorado con un 3 el rendimiento de la aplicación. Esto es debido a lo comentado
anteriormente sobre los tiempos de cargas de algunas opciones la primera vez.
Se podría decir que se ha obtenido un rendimiento y una cantidad de funcionalidades
que todos los usuarios esperaban. Han valorado positivamente el tiempo de respuesta
y el rendimiento por lo tanto podemos concluir que la aplicación cumple con los
requisitos no funcionales expuestos en la fase inicial de identificación de los
requerimientos.
54
¿Qué es lo que más le ha llamado la atención de la aplicación?
A modo de buscar un punto fuerte de la aplicación, se preguntó por lo que los usuarios
creían más atractivo de la aplicación. Esto sirve al desarrollador que funcionalidad o
que punto de la aplicación causa más impacto en los usuarios y mejorarlo.
Como se puede ver, las opciones más marcadas en la encuesta fueron la interfaz y las
funcionalidades.
La interfaz también ha causado muy buena impresión gracias sus colores y su patrón
de diseño tan llamativo con animaciones y efectos de transición, también porque
cumple con los patrones de diseño de Google por lo que hace la aplicación más
intuitiva.
A modo de resumen, se puede concluir que se han cumplido la gran mayoría los
objetivos impuestos para la aplicación, y que los usuarios que la han testeado están
satisfechos con las funcionalidades que ofrece.
55
3. Conclusiones
Otro aspecto a destacar, fue que durante el desarrollo del proyecto se tuvo la
necesidad de cambiar y redefinir algunas secciones que ya estaban implementadas,
debido a varios elementos, en algunos casos, a causa de que se determinaba una
mejor técnica capaz de mejorar lo que ya estaba hecho, en otros, por motivos de
incompatibilidades entre distintos dispositivos y también, aunque menos frecuente,
56
debido a la necesidad de integración con la otra parte del proyecto. Dichas situaciones
derivaron en cierto “re-trabajo”, que ha sido un aspecto importante a tener en cuenta,
puesto que significo un esfuerzo extra en el tiempo de desarrollo. Por otra parte, el
tiempo limitado del que se disponía, también jugó un papel en el proyecto a la hora de
definir diferentes plazos, en los que debían acabarse distintas tareas.
Pero de las situaciones anteriormente descritas se rescata que dejaron un aprendizaje
significativo sobre cómo afrontar estas circunstancias en proyectos futuros.
En resumen, se ha realizado un proyecto en el cual se ha tenido que estar
completamente involucrado día a día, con una inversión muy importante de tiempo y
sacrificio con el objetivo de generar esta primera versión de la aplicación.
Bueno trabajo futuro queda mucho, puesto que es una primera versión de la aplicación
y que el proyecto tiene mucho potencial para crecer, dado la gran cantidad de
opciones y servicios que pueden ser incluidos dentro de una aplicación de este tipo.
A continuación, se comentarán algunas de las líneas de trabajo que se consideran
más viables y/o necesarias según el estado actual de la aplicación.
Sería importante poder realizar un plan piloto de la aplicación con una muestra mucho
más grande de usuarios, que los que pudieron participar en las pruebas realizadas,
esto para poder, con dicha población mayor de usuarios, poder depurar de una mejor
manera la aplicación.
57
como gestionara dicha cuenta, por otra parte, también se debe pasar a un servidor de
producción el API creado para la aplicación.
58
4. Glosario
Fragmentación: fenómeno que describe una situación en la que una misma tecnología
ha evolucionado de forma que se hace incompatible entre sí.
59
Latitud: distancia angular entre el ecuador y un punto de la superficie del planeta. Se
mide en grados entre 0 y 90.
60
5. Bibliografía
UNED. (2005). Modelo Pedagógico. San José, Costa: EUNED.
ISO 9241-II:1998. (1998). Ergonomic requirements for office work with visual
display terminals.
UNED. (24 de 07 de 2013). Sitio Web UNED. Obtenido de Sitio Web UNED:
https://www.uned.ac.cr/transparencia/informe-de-labores-2012/informes-
de-labores-por-dependencias/otras-dependencias-2012/234-gobierno-
digital-2012
61
6. Anexos
Anexo 1
62