J Matamoros Set FM 1217 Memoria

Propuesta de diseño e implementación de una
aplicación móvil intranet (IntraUNED) Android

para la UNED Costa Rica
Nombre Estudiante: Jairo Matamoros S.

Máster Universitario en Desarrollo de Aplicaciones para Dispositivos Móviles
Nombre Consultor/a: Eduard Martin Lineros
Profesor/a responsable de la asignatura: Carles Garrigues Olivella
Fecha de Entrega: 12/2017

Copyright
© (Jairo Matamoros S.)

Reservados todos los derechos. Está prohibido
la reproducción total o parcial de esta obra por
cualquier medio o procedimiento,
comprendidos la impresión, la reprografía, el
microfilme, el tratamiento informático o
cualquier otro sistema, así como la distribución
de ejemplares mediante alquiler y préstamo,
sin la autorización escrita del autor o de los
límites que autorice la Ley de Propiedad
Intelectual.
Agradecimientos
Primeramente, doy a gracias a Dios por haberme permitido finalizar esta

importante etapa, a mi familia, profesores y demás colaboradores que me
ayudaron, de forma directa o indirecta, siempre que necesite apoyo y un
agradecimiento especial a la UNED por haberme permitido cursar este master
brindándome todo el apoyo que necesitaba, haciéndome posible cumplir este
anhelo.
No fue un camino sencillo, pero gracias a todo el esfuerzo y los apoyos
recibidos hoy se ve el resultado de dicho esfuerzo y de todo el trayecto
recorrido.
i
FICHA DEL TRABAJO FINAL
App Intranet (IntraUNED) para la UNED

Título del trabajo:
Costa Rica
Nombre del autor: Jairo Matamoros Segura
Nombre del consultor/a: Eduard Martin Lineros
Nombre del PRA: Carles Garrigues Olivella
Fecha de entrega (mm/aaaa): 12/2017

Máster Universitario en Desarrollo de
Titulación::
Aplicaciones para Dispositivos Móviles
Idioma del trabajo: Castellano
Palabras clave App móvil, intranet, tecnologías móviles
Resumen del Trabajo
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
Tabla 1 Usuario básico ....................................................................................... 7

Tabla 2 Usuario intermedio ................................................................................ 7
Tabla 3 Usuario avanzado ................................................................................. 8
Tabla 4 Recomendaciones stakeholder ............................................................. 9
Tabla 5 Sesión usuarios finales........................................................................ 10
Tabla 6 Escenarios........................................................................................... 15
Tabla 7 Actores ................................................................................................ 22
Tabla 9 Caso de uso 1 ..................................................................................... 24
Tabla 10 Caso de uso 2 ................................................................................... 24
Tabla 11 Caso de uso 3 ................................................................................... 25
Tabla 12 Caso de uso 4 ................................................................................... 25
Tabla 13 Caso de uso 5 ................................................................................... 26
Tabla 14 Caso de uso 6 ................................................................................... 26
Tabla 15 Caso de uso 7 ................................................................................... 27
Tabla 16 Caso de uso 8 ................................................................................... 27
Tabla 17 Caso de uso 9 ................................................................................... 28
Tabla 18 Dispositivos utilizados en las pruebas ............................................... 50
Tabla 19 Resultados de las pruebas ................................................................ 51
Lista de Ilustraciones
Ilustración 1 Framework de usabilidad (ISO 9241-11). .................................... 20

Ilustración 2 ...................................................................................................... 23
Ilustración 3 Esquema de petición de información ........................................... 28
Ilustración 4 Clases .......................................................................................... 29
Ilustración 6 Diseño conceptual arquitectura .................................................... 30
Ilustración 7 Modelo navigation drawer ............................................................ 33
Ilustración 8 Captura pantalla Splash ............................................................... 35
Ilustración 9 Captura sección código consumo API login ................................. 36
Ilustración 10 Captura pantalla login ................................................................ 37
Ilustración 11 Captura sección asignación de algunas de las opciones menú
lateral ............................................................................................................... 38
Ilustración 12 Captura menú lateral .................................................................. 38
Ilustración 13 Captura pantalla inicial ............................................................... 39
Ilustración 14 Captura sección asignación de actividades en el calendario ..... 40
Ilustración 15 Captura pantalla calendario ....................................................... 41
Ilustración 16 Captura pantalla directorio ......................................................... 42
Ilustración 17 Captura pantalla activos ............................................................. 43
Ilustración 18 Captura pantalla historial vacaciones ......................................... 44
Ilustración 19 Captura pantalla solicitud vacaciones ........................................ 45
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
1.1 Contexto y justificación del Trabajo
Hoy día, la manera en que se comunica, comparte o relaciona la información

ha cambiado por completo con la llegada de los dispositivos móviles, esto
compromete a las distintas instituciones, de todos los sectores, a replantearse
los modelos de comunicación y ofrecer servicios destinados a estos
dispositivos, que les permitan integrarse al contexto que este paradigma de las
tecnologías móviles causa.
En vista de lo anterior, la Universidad Estatal a Distancia de Costa Rica

(UNED) tiene una necesidad importante por cubrir, puesto que dentro de las
distintas aplicaciones informáticas que pone a disposición, para los estudiantes
y funcionarios, no cuenta con ninguna que sea destinada para el área de
dispositivos móviles; siendo una institución educativa que tiene como uno de
sus pilares la educación no presencial (UNED, 2005), debe apuntar cada vez
más al uso de las nuevas tecnologías, dentro de estas las móviles, y poder así
ofrecer a sus estudiantes y personal administrativo servicios tecnológicos que
satisfagan lo que el mundo actual solicita.
Con esta situación expuesta, el proyecto apunta a la creación una propuesta de

aplicación móvil para la institución, llamada: “IntraUNED”, que ponga a
disposición de los funcionarios, distintos servicios y procesos, con el fin de
integrar a la UNED al mundo de los dispositivos móviles y a su vez documentar
la experiencia de desarrollo móvil, que actualmente no se tiene en la institución,
esto para crear, en un futuro cercano, nuevas aplicaciones móviles con más
servicios para estudiantes y funcionarios.
1.2 Objetivos del Trabajo
-Crear una propuesta de aplicación móvil que permita a los funcionarios

de la UNED acceder a servicios de la institución (IntraUNED), por medio de sus
dispositivos móviles.
-Generar una experiencia de desarrollo de una aplicación móvil en el

departamento de tecnología de la institución, proveyendo la posibilidad de crear
más aplicaciones en un futuro cercano.
Dentro de los requerimientos funcionales que se espera que tenga la aplicación

en una primera versión, serian:
- La aplicación controlará el acceso y lo permitirá solamente a usuarios
autorizados, funcionarios de la institución.
- La aplicación tendrá una pantalla de bienvenida con la información básica del
funcionario.
- La aplicación permitirá el acceso a un directorio de personal de la institución.
- La aplicación tendrá una opción de calendario de eventos y cumpleaños.
- La aplicación permitirá el acceso a un repositorio de documentos.
- La aplicación permitirá recibir notificaciones push con información relevante.
- La aplicación tendrá un formulario de solicitud de vacaciones.
- La aplicación tendrá una consulta de boleta de pago.
- La aplicación tendrá una consulta de activos Fijos .
Dentro de los requerimientos no funcionales que se espera que tenga la

aplicación en una primera versión, serian:
- Usabilidad: la app debe tener facilidad de uso y aprendizaje para los usuarios.
- Extensibilidad: la app debe desarrollarse considerando un crecimiento en las
funcionalidades que contendrá.
- Seguridad: la app debe garantizar la confidencialidad de los datos de los
funcionarios.
2
1.3 Enfoque y método seguido
En el caso de la estrategia a seguir será la creación, desde cero, de una

propuesta de una primera versión de una app para dispositivos Android, se
debe crear desde cero porque no hay ninguna base actual desde donde iniciar
en la institución. La mayoría de los servicios que se piensa incluir en la app
serán adaptados para ser incluidos en la misma, puesto que algunos de cierta
forma existen de manera web o hibrida (es decir parte en web y otra parte en
papel).
El desarrollo de la aplicación se hará con el IDE Android Studio, puesto que se
desea realizar una aplicación nativa, y este es la herramienta de desarrollo
oficial de Android.
El método elegido a seguir para la elaboración del proyecto (aplicación) será
una combinación entre un modelo de prototipos y el modelo de diseño centrado
en el usuario DCU, esto permite el que se construya un prototipo en poco
tiempo y sin utilizar muchos recursos. El diseño rápido se centra en
representación de aspectos software visibles para el usuario. Este rápido
diseño conduce a la creación de un primer prototipo que será evaluado y
retroalimentado por el cliente, con esto se podrá entender mejor lo que se debe
hacer y permitiendo ver resultados progresivos a corto plazo. Con el DCU se
busca considerar las particularidades de los usuarios a los que se dirige el
producto con la finalidad de que sea usable. Dichas particularidades definen el
contexto de uso y se han de reflejar en la interacción del sistema y en la
implementación de sus funcionalidades.
1.4 Planificación del Trabajo
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
- Una propuesta de App Intranet funcional, con los requerimientos funcionales y

no funcionales descritos anteriormente.
- La documentación del proceso de desarrollo de la app (memoria), generando
una experiencia de desarrollo móvil para la institución.
- Presentación ejecutiva del proyecto.
1.6 Breve descripción de los otros capítulos de la memoria
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.
Usuarios y contexto de uso

En este apartado se realiza una explicación sobre la identificación de los usuarios, y
de los requerimientos encontrados en el análisis de dichos usuarios.
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.
Definición de los casos de uso

Se muestran los casos de uso según las funcionalidades de la aplicación identificadas.
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
Usuarios y contexto de uso
En el caso de los usuarios se identifican dos grupos principales, un usuario, que se

puede considerar experto que se puede considerar “stakeholder”, el cual puede apoyar
en la coordinación, brindar requisitos (requerimientos) y recomendaciones en el
proceso de análisis y desarrollo de la aplicación, este usuario es el Programa de
Gobierno Digital de la UNED, dicho programa es una dependencia de la institución,
que dentro de sus funciones principales están “fomentar el cambio de cultura
organizacional, desde la perspectiva de la revisión, evaluación, análisis, mejora y
cambio en los procesos con la incorporación de las Tecnologías de la Información y la
Comunicación” (UNED, 2013), es decir se encarga de gestionar la inclusión de
tecnologías de la información en los distintos procesos de la institución, por lo cual es
un usuario clave para el desenvolvimiento del proyecto en la institución.
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).
Análisis de perfiles de grupos de usuarios
Con la identificación de estos grupos se creó un análisis de cada uno, esto

proporciona la información necesaria para conocer los usuarios, lo que requieren o
esperan de la aplicación en el contexto del proyecto: la creación de una propuesta de
una aplicación móvil intranet para la UNED.
A partir de los usuarios consultados se identificaron los siguientes modelos.
Usuario básico
Elizabeth Zuñiga
Edad Biografía Frase

56 años Elizabeth tiene varios años de No conozco mucho sobre
trabajar en la UNED, hace aplicaciones y móviles.
poco tiempo empezó a
conocer sobre smartphones y
aplicaciones.
Nivel educativo
Universidad completa
Ocupación Apps que usa Que busca en una app
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

34 años Amanda usa con regularidad el Deseo encontrar las cosas
smartphone y también distintas que espero, si no las veo,
aplicaciones en su día a día. desinstalo la app.
Nivel educativo
Asistente Facebook Que la aplicación haga lo que
Instagram dice hacer
Whatsapp
Que no tenga exceso de
publicidad
Observaciones
¿Qué servicios incluirá?
¿Se podrá sincronizar
con el
calendario de la
universidad ?
Tabla 2 Usuario intermedio
7
Usuario avanzado
Marino Sanchez

42 años Marino es un desarrollador de Ojalá todo se pudiera
software en la UNED, le gusta hacer con el smartphone.
mucho el área de tecnologías
móviles.
Nivel educativo
Analista de sistemas Whatsapp Rapidez, facilidad en la
Waze búsqueda de información,
Skype seguridad.
Observaciones
Ya es hora que la UNED
tenga una app
¿Se contemplara
también para otras
plataformas aparte de
Android?
Tabla 3 Usuario avanzado
Sesión inicial stakeholder
Se realizó una sesión con el usuario considerado stakeholder para determinar algunos
requisitos o recomendaciones iniciales del proyecto:
Preguntas realizadas al usuario Respuestas / Conclusiones

¿Qué se espera de un proyecto Del proyecto se espera que los funcionarios de la
como este? UNED cuenten con una buena herramienta, una app
móvil para que puedan gestionar servicios y encontrar
información.
¿Cuáles son los aspectos que Se espera que los servicios y contenidos en la app
esperan que la app contemple? sean correctamente seleccionados, obteniendo como
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.
Tipos de usuario Básicos, intermedios y avanzados.
Servicios principales que podría Solicitud de vacaciones

usar el Consulta de boleta de pago
usuario en la aplicación Consulta de directorio
Tabla 4 Recomendaciones stakeholder
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:
Preguntas realizadas al usuario Respuestas / Conclusiones

¿Considera importante tener una aplicación La mayoría de respuestas apuntaron a que si es muy
móvil con servicios de intranet? necesario tener una aplicación móvil para los funcionarios
de la institució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.
¿Qué dispositivo móvil usa? El 90% usa un dispositivo Android
Tabla 5 Sesión usuarios finales
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.
Cierre de sesión: Cualquier usuario de la aplicación debe poder finalizar sesión en la

aplicación mediante un botón u opción de que indique "Cierre de sesió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.
Menú desplegable: la aplicación tendrá un menú desplegable al lado izquierdo el cual

mostrará las distintas opciones de la aplicación.
Directorio de personal: se debe tener una opción que muestre el directorio de personal
de la institución.
Calendario: se tendrá una opción de calendario de eventos.
Repositorio de documentos: se tendrá una opción con acceso a un repositorio con los
principales documentos que se utilizan en la institución.
Notificaciones push: Posibilidad de notificar al usuario de los distintos eventos de

institucionales.
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
Los requisitos no funcionales para la aplicación que se identificaron son:
Rendimiento: la aplicación debe desempeñarse de manera fluida y eficiente,

propiciando una experiencia atractiva para el usuario.
Seguridad: la aplicación debe garantizar la confidencialidad de los datos de los

funcionarios.
Accesibilidad: la aplicación debe ser clara y debe seguir los patrones de accesibilidad
estándares.
Usabilidad: cualquier funcionario debe ser capaz de poder utilizar la aplicación y

acceder a toda la funcionalidad sin ningún tipo de restricción o inconvenientes.
Estabilidad: la aplicación debe ser capaz de controlar los posibles errores ocurridos
durante la ejecución de la misma.
Mantenimiento: la aplicación debe poder ser mantenida y actualizada, dando

posibilidad a mejorar el rendimiento, incluir nuevas funciones y mejorar la usabilidad
en cualquier momento.
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.
Optimización: El consumo de batería y de datos debe ser adecuado, y nunca dejar

procesos sueltos que consuman memoria y batería. El tiempo de ejecución debe ser
mínimo, para mejorar los tiempos de respuesta y la experiencia de uso del usuario.
Diseño conceptual
Escenarios de uso
Con apoyo del stakeholder se desarrollaron 4 posibles escenarios de uso que se

busca que el usuario realice con la aplicación:
Escenario 1.
Marino se encuentra en su oficina, está trabajando animadamente con su ordenador

portátil, en dicho momento Marino tiene salir a una reunión, de camino recuerda que
debe llamar a una compañera para solicitar una información, pero no tiene el número
de la oficina, puesto que recuerda que puede hacer la búsqueda en el directorio de la
institución que la aplicación “IntraUNED” posee en una de sus funcionalidades, puesto
que ingresa a app, elige la opción del directorio y realiza la búsqueda para encontrar la
información de la compañera.
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.
En otra ocasión un domingo por la mañana, Amanda desea comprobar el salario

recibido, quiere revisar si le han pagado unas horas extras que tenía acumuladas, ante
la duda, quiere verificar su boleta de pago, pero no quiere encender su ordenador y
todo el tiempo que esto necesita solo para hacer esta comprobación rápida, por lo que
decide realizar dicha comprobación mediante la app “IntraUNED”, ingresa a la misma,
busca la opción en el menú de la app e ingresa en esta función, ingresa los datos
requeridos por la pantalla y logra descargar su boleta de pago para revisar lo que
deseaba.
Con la descripción de estos hipotéticos escenarios se pueden determinar los

siguientes flujos de interacción:
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.
Pantalla splash Pantalla de identificación
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.
Ilustración 1 Framework de usabilidad (ISO 9241-11).
Si se toma en cuenta que la interfaz de la aplicación o prototipo es el conjunto de

elementos o componentes que permiten a los usuarios, de esta, llevar a cabo lo que
requieren, se puede llegar a la conclusión que dependiendo del nivel o grado de
usabilidad que tenga la interfaz se pueden exhibir los posibles defectos de usabilidad
de la misma, lo que hace a dichos componentes menos usables o problemáticos.
Los defectos de usabilidad que tengan los componentes de la interfaz en ocasiones
pueden ser causa de fallos o errores de uso por parte del usuario cuando tiene
interacción con dichos componentes; es decir, acciones que realiza el usuario que se
desvían de lo que se puede considerar una ejecución correcta de una tarea o proceso.
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
Se deben revisar los estándares de diseño de aplicaciones de Google para determinar

que se cumple con un estándar de diseño de interfaz concreto y ajustado a lo que los
lineamientos que dicho estándar recomienda. Haciendo una lista de chequeo para
verificar el grado de cumplimiento o afinidad que se tiene en el prototipo en relación a
las recomendaciones y lineamientos de dicho estándar.
Simulaciones de diseño
Con el uso de una simulación de diseño se espera encontrar problemas potenciales de

usabilidad suponiendo cómo interactuaría un usuario final con el prototipo.
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.
También se deben realizar simulaciones específicas para la accesibilidad, tomando

usuarios con discapacidad para que de igual forma se verifique cómo se comporta el
prototipo en una situación como tal.
Al final se espera tener un documento con los hallazgos encontrados en cada sesión.
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í.
Definición de los casos de uso
Actores
En la aplicación se va tener un único actor, que será el usuario final de la aplicación.
ACT-1 Usuario final

Descripción Este actor representa a cualquier usuario final del sistema
Comentarios Ninguno
Tabla 7 Actores
22
Casos de uso
Diagrama de 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 -
Flujo normal 1- El usuario ingresa su usuario y contraseña

2- El usuario presiona el botón “Ingresar”
3- La aplicación procesa la solicitud
4- La aplicación ingresa al usuario a la pantalla inicial.
Flujo alternativo Si el usuario no ingresa el usuario y/o contraseña se muestra
una alerta indicando que es requerido
Postcondiciones El usuario se ingresa correctamente en la aplicación.
Tabla 8 Caso de uso 1
CU-2 Consultar directorio de personal

caso de uso cuando un usuario presiona la opción consulta del
directorio de personal.
Precondiciones -
Flujo normal 1- El usuario presiona la opción de consulta del directorio

de personal.
3- La aplicación ingresa al usuario a la pantalla de
consulta del directorio de personal.
Flujo alternativo -
Postcondiciones Se muestra la pantalla con el directorio de personal
Comentarios -
CU-3 Consultar calendario

24
caso de uso cuando un usuario presiona la opción consulta del
calendario.
Precondiciones -
Flujo normal 1- El usuario presiona la opción de consulta del

calendario.
consulta del calendario.
Flujo alternativo -
Postcondiciones Se muestra la pantalla de consulta del calendario
Comentarios -
CU-4 Consultar repositorio de documentos

caso de uso cuando un usuario presiona la opción consulta de
repositorio de documentos.
Precondiciones -
Flujo normal 1- El usuario presiona la opción de consulta de repositorio

de documentos.
repositorio de documentos.
Flujo alternativo -
Postcondiciones Se muestra la pantalla de consulta de repositorio de
documentos.
Comentarios Dichos documentos serán solo una lista, el usuario podrá
descargarlos a su dispositivo y fuera de aplicación gestionar
su uso.
CU-5 Consultar boleta de pago

25
boleta de pago
Precondiciones -
Flujo normal 1- El usuario presiona la opción de consulta de boleta de

pago
2- El usuario selecciona el mes, año y tipo de boleta.
4- La aplicación descarga la boleta.
Flujo alternativo Se mostrara un mensaje informativo si la boleta requerida no
existe para el mes y año seleccionados.
Postcondiciones Se descarga la boleta de pago solicitada.
Comentarios Dicha boleta se descargara a su dispositivo y fuera de
aplicación gestionara su uso.
CU-6 Consultar mapa

mapa (sedes)
Precondiciones -
Flujo normal 1- El usuario presiona la opción de consulta de mapa

(sedes)
3- La aplicación muestra la pantalla con el mapa y las
sedes marcados en el miso
Flujo alternativo -
Postcondiciones Se muestra el mapa con las sedes marcadas con un pin, al dar
clic sobre alguno se muestra información de la sede.
Comentarios -
CU-7 Consultar activos

26
mapa (sedes)
Precondiciones -
Flujo normal 1- El usuario presiona la opción de consulta de mapa

(sedes)
3- La aplicación muestra la pantalla con el mapa y las
sedes marcados en el miso
Flujo alternativo -
Postcondiciones Se muestra el mapa con las sedes marcadas con un pin, al dar
clic sobre alguno se muestra información de la sede.
Comentarios -
CU-8 Consultar vacaciones

vacaciones
Precondiciones -
Flujo normal 1- El usuario presiona la opción de consulta de

vacaciones
3- La aplicación muestra la pantalla el historial (listado) de
vacaciones solicitadas
Flujo alternativo -
Postcondiciones Se la pantalla con el historial (listado) de vacaciones
realizadas.
Comentarios -
CU-9 Solicitar vacaciones

caso de uso cuando un usuario presiona la opción solicitar de
vacaciones
27
Precondiciones -
Flujo normal 1- El usuario presiona la opción de solicitar de vacaciones

3- La aplicación muestra la pantalla para solicitar
vacaciones
4- El usuario ingresa los datos solicitados.
5- El usuario presiona el botón “Realizar solicitud”
Flujo alternativo Si el usuario no tiene vacaciones disponibles para los días
solicitados se muestra un mensaje indicándolo.
Postcondiciones Se realiza la solicitud de vacaciones.
Comentarios -
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.
Ilustración 3 Esquema de petición de informació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.
Estructura de las clases
Las estructuras de las clases u objetos de la aplicación son las siguientes:
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
Ilustración 5 Diseño conceptual arquitectura
Desarrollo
Para profundizar el entendimiento de la aplicación este apartado a la implementación y

pruebas. Se explica cómo fueron desarrollados algunos aspectos relevantes, tales
como la estructura de la aplicación, utilización de mapas, la implementación de la base
de datos, diseños de la interfaz y pruebas realizadas a las acciones más importantes.
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
Aunque se contempló inicialmente incluir también en esta versión la opción de

consulta de boleta de pago y mensajes (notificaciones push) por asuntos de alcance
del tiempo para el desarrollo no se incluyeron en esta versión, se incluyeron solo las
opciones en los menús.
31
Herramientas usadas
Aplicación Android
Android Studio 3.0.1: Es el entorno de desarrollo de Android basado en IntelliJ IDEA.

Se trata del IDE oficial para desarrollo de aplicaciones 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
Con el fin de conseguir una aplicación intuitiva y seguir el estándar de Google se ha

implementado el patrón de diseño Navigation Drawer. Es un panel lateral que se
desliza desde el borde izquierdo de la pantalla y muestra las principales opciones de
navegación de la aplicación.
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
Al deslizar de izquierda a derecha de la pantalla se abre el drawer (También podemos

abrirlo pulsando sobre el icono en la parte superior izquierda de la activity). Cada
elemento del drawer tiene un fragment asociado y ya creado, que ha sido diseñado de
forma diferente a cada uno de los demás bloques de información.
Cuando pulsamos sobre un ítem provocaremos que el fragment asociado se cargue en

el contenedor de fragments ocupando la totalidad de la pantalla.
Pantalla splash
La primera pantalla que observamos después de la ventana de carga de la aplicación

es la pantalla de “Splash”.
Dicha pantalla muestra el logo de la institución y la versión actual de la aplicación.
34
Ilustración 7 Captura pantalla Splash
Pantalla Login
Para el desarrollo de la pantalla de Login se tomó en cuenta que se debe realizar la

validación del usuario y/o contraseña contra el active directory institucional, es
importante destacar que los usuarios que deseen usar la aplicación deben estar
previamente registrados en este, dicho proceso debe realizarse de manera personal
en la institución, esto por política de la institución.
Esta validación se realiza mediante el API creado.
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
Ilustración 11 Captura menú lateral
38
Pantalla inicial
La pantalla inicial se creó como una opción complementaria al menú de opciones

lateral, mostrando las opciones de la aplicación mediante una serie de iconos intuitivos
para el usuario, siendo consecuentes con las opciones a la que representan.
Ilustración 12 Captura pantalla inicial
Pantalla calendario
En esta opción se creó un calendario en el cual se muestran las actividades, fechas

importantes, y demás, que a nivel institucional se tienen, actualmente estas solo están
disponibles mediante un calendario en papel, puesto que se espera que al estar
disponibles en la aplicación representen un aporte importante al quehacer institucional.
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.
Ilustración 13 Captura sección asignación de actividades en el calendario
40
Ilustración 14 Captura pantalla calendario
Pantalla directorio
En dicha opción se muestra un listado general de los funcionarios de la institución, al

ser un listado algo extenso se almacena en la base de datos local luego de la primera
carga.
41
Ilustración 15 Captura pantalla directorio
42
Pantalla Activos
En la pantalla de activos se muestran los activos institucionales que están a nombre

del funcionario, dichos datos están almacenados en las bases de datos institucionales
y son consumidos mediante el API.
Ilustración 16 Captura pantalla activos
43
Pantalla consulta vacaciones
En esta opción se muestra un historial de las solicitudes de vacaciones hechas por el

funcionario durante toda su estancia laboral en la institución, dicho historial se
actualiza y almacena en el dispositivo para evitar lentitud que podría producirse al
consumirlo siempre mediante el API.
Ilustración 17 Captura pantalla historial vacaciones
44
Pantalla solicitud vacaciones
En el caso de esta opción el usuario realiza una solicitud de vacaciones mediante el

llenado de un formulario que solicita la información necesaria para la realización de la
misma.
Ilustración 18 Captura pantalla solicitud vacaciones
45
Pantalla sedes
En dicha opción se utiliza los servicios de Google Maps y Firebase en donde se

almacenan las latitudes y longitudes de las distintas sedes de la UNED.
Ilustración 19 Función de creación de las marcas en el mapa
Previamente antes de hacer las marcas en el mapa se consume el servicio de base

datos de Firebase en donde se encuentran los datos de las localizaciones:
Ilustración 20 Captura de datos Firebase
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:
Presentación: Hace referencia a la parte visual que se utilizará para mostrar la

información y los datos. Normalmente, es la parte con la que el usuario final
interaccionará.
Negocio o Lógica: Es la capa intermedia encargada de interactuar con la interfaz y los

datos. Su función es recopilar los datos y procesarlos para que se muestren o
almacenen según se desee.
Persistencia: Es la capa de datos. Se encarga de las tareas que realizamos

habitualmente con los datos: insertar, modificar, consultar o borrar. Por norma general,
la información persiste en esta capa.
48
Ilustración 22 Arquitectura
Testeo y pruebas
Para comprobar que la aplicación cumple los objetivos expuestos en la planificación,

se desarrollaron varias pruebas para evaluar el rendimiento en distintos dispositivos
móviles. También se realizaron pruebas de satisfacción para saber la opinión de los
usuarios.
Pruebas de rendimiento
Las primeras pruebas ejecutadas sobre la aplicación corresponden a las de

rendimiento. Para que estas pruebas sean más objetivas, se han ejecutado sobre
diferentes dispositivos Android. Se han utilizado dispositivos de distintas gamas. El
Samsung Note 8 corresponde a una gama alta de móviles Android, el Huawei P9 lite a
una gama media y el Samsung j7 a una gama más discreta de los dispositivos
Android.
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
Se han realizado diversas pruebas de tiempo de respuesta en los diferentes móviles.

Para esta prueba se ha medido el tiempo de respuesta de distintas funcionalidades de
la aplicación.
Por una parte, se ha medido el tiempo de cargar la aplicación, tanto el primer

arranque como los demás. Para el primer arranque se debe tener en cuenta que la
aplicación obtiene los recursos e introduce la información en la base de datos local.
Esto aumenta el tiempo de espera de arranque, pero una vez completado el primer
arranque se disminuyen los tiempos de arranque. Si se mira desde esta perspectiva,
aumentando el tiempo necesario para el primer arranque, se disminuye los tiempos
posteriores de respuesta.
La segunda prueba medida es la descarga de todos los eventos del Directorio,
Historial de vacaciones y calendario. Esto porque son las pantallas que pueden
requerir más exigencia de móvil, aunque gran parte también está ligada a la velocidad
de internet que se disponga, ya que solo se requiere descargar los elementos de estas
opciones la primera vez que se accede. Una vez completado el primer acceso a las
opciones, los elementos son obtenidos de la base de datos, donde se almacenaron en
el primer arranque.
Por último, se ha medido el tiempo en cargar completamente el mapa de las sedes.

Debido a que en el primer arranque se procesan todos los marcadores del mapa, en
los siguientes accesos no se necesita procesamiento y el tiempo de respuesta
depende de la calidad de procesamiento del dispositivo.
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
del
calendario
Descarga de
del historial
vacaciones
Mostrar
mapas 3.5 segundos 5.5 segundos 6.5 segundos
Tabla 18 Resultados de las pruebas
Pruebas de satisfacción de usuarios
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
Como se puede observar la mayoría de los usuarios que probaron la aplicación

quedaron satisfechos con la disposición de sus funcionalidades y su facilidad de uso.
52
La interfaz gráfica de la aplicación es llamativa y amigable
Como se puede observar, los usuarios consideran el diseño de la interfaz de la

aplicación atractiva y amigable. Se puede considerar que el patrón de diseño ofrecido
en la aplicación ha gustado entre los usuarios ya que la aplicación parece atractiva,
intuitiva y fácil de usar.
El tiempo de respuesta es razonable tomando en cuenta ciertos criterios
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.
En términos generales, la aplicación cumple su objetivo y con un

rendimiento positivo
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
En términos generales se puede concluir que el proyecto que se logró realizar

responde a los intereses y requerimientos que se pusieron sobre la mesa en el punto
de partida del mismo, realizar el desarrollo de una aplicación sobre la plataforma
Android, con el fin de facilitar la integración y el quehacer institucional de los
funcionarios de la UNED.
Pese a que, a causa de cuestiones de tiempo, no se han podido implementar un par

de las funcionalidades que se propusieron al inicio, lo cierto es, que se han cumplido
los objetivos iniciales del proyecto y principalmente el poder dotar a la institución de la
aplicación móvil propia.
En lo relativo al desarrollo de la aplicación, se puede destacar que se pusieron en

práctica gran parte de los conocimientos adquiridos a lo largo del master, pero al no
disponer de una vasta experiencia en el desarrollo de una aplicación Android
completa, se tuvieron que realizar ciertas investigaciones en algunos temas, por lo que
la planificación del desarrollo se vio un poco afectado, esto porque se consumió un
poco más de tiempo de lo presupuestado en el mismo. Otro aspecto clave en el
desarrollo del proyecto, y que también consumió tiempo de investigación, fue la
creación de capa servidor o API, lo que también significo un reto importante.
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.
Línea futura de desarrollo
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.
Inicialmente se pueden retomar y terminar las opciones que, por lo anteriormente

descrito, no se pudieron finalizar en esta etapa, las cuales son las opciones de buscar
y descargar la boleta de pago y la opción de recibir y administrar push notification en 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.
Dentro de las funcionalidades que también se pueden incorporar en una posterior

versión podrían ser la opción de solicitar y administrar transporte institucional, poder
tener la opción de consultar el correo institucional, opción de consulta de los reportes
institucionales.
También algo importante que se debe realizar es gestionar toda la publicación y

demás en la tienda de Google (Play Store) puesto que la institución deberá definir
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
API: Interfaz de Programación de Aplicaciones, es el conjunto de funciones y

procedimientos que ofrece cierta biblioteca para ser utilizado por otro software como
una capa de abstracción.
APP: Aplicación móvil.
UNED: Universidad Estatal a Distancia de Costa Rica.
IDE: Entorno de desarrollo integrado, es un programa informático compuesto por un

conjunto de herramientas de programación.
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í.
GPS: siglas en ingles de Global Positioning System, en español Sistema de

Posicionamiento Global. Es un sistema global de navegación que, mediante satélites,
permite ubicar un objeto en la superficie terrestre con una precisión que va desde
varios metros a centímetros.
Biblioteca: agrupación de código y datos que proporcionan servicios a programas

independientes, pasando a formar parte de éstos. Permiten la distribución de
funcionalidades y la construcción modular. También conocido como librería, por su
similitud con el inglés library.
HTTP: siglas de HyperText Transfer Protocol, en español Protocolo de

Transferencia de Hipertexto. Constituye el protocolo utilizado para la transmisión de
documentos a través de la Web entre un cliente y servidor.
Interfaz: en computación, una interfaz se refiere a una abstracción que una

determinado elemento ofrece de sí mismo al exterior, facilitando de esta forma su
acceso y uso por otros elementos de hardware o software.
59
Latitud: distancia angular entre el ecuador y un punto de la superficie del planeta. Se
mide en grados entre 0 y 90.
Longitud: distancia angular entre el meridiano y un punto de la superficie del planeta.

Se mide en grados entre 0 y 360.
Librería: ver biblioteca.
Listener: objeto que está a la espera de determinado evento.
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.
PRESSMAN. Ingeniería del Software: Un Enfoque Práctico. 6a Edición.

McGraw-Hill,2002.
Android, el sistema operativo de Google. Último acceso, noviembre de 2017.

http://code.google.com/intl/es-ES/android/index.html
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
PFLEEGER, Shari Lawrence. Ingeniería de Software. Teoría y Práctica.

Prentice Hall, 2002.
Android Maps API Key Signup. Último acceso en diceimbre de 2017.

http://code.google.com/intl/es-ES/android/maps-api-signup.html
Google. (21 de 10 de 2017). Andorid developers. Obtenido de Andorid

developers: http://developer.android.com/guide/components/fragments.html
61
6. Anexos
Anexo 1
62

J Matamoros Set FM 1217 Memoria

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

J Matamoros Set FM 1217 Memoria

Cargado por

Copyright:

Formatos disponibles

Propuesta de diseño e implementación de una

aplicación móvil intranet (IntraUNED) Android

Nombre Estudiante: Jairo Matamoros S.

Nombre Consultor/a: Eduard Martin Lineros

Profesor/a responsable de la asignatura: Carles Garrigues Olivella

Fecha de Entrega: 12/2017

© (Jairo Matamoros S.)

Primeramente, doy a gracias a Dios por haberme permitido finalizar esta

App Intranet (IntraUNED) para la UNED

Nombre del consultor/a: Eduard Martin Lineros

Nombre del PRA: Carles Garrigues Olivella

Fecha de entrega (mm/aaaa): 12/2017

Palabras clave App móvil, intranet, tecnologías móviles

Resumen del Trabajo

Tabla 1 Usuario básico ....................................................................................... 7

Ilustración 1 Framework de usabilidad (ISO 9241-11). .................................... 20

1.1 Contexto y justificación del Trabajo

Hoy día, la manera en que se comunica, comparte o relaciona la información

En vista de lo anterior, la Universidad Estatal a Distancia de Costa Rica

Con esta situación expuesta, el proyecto apunta a la creación una propuesta de

-Crear una propuesta de aplicación móvil que permita a los funcionarios

-Generar una experiencia de desarrollo de una aplicación móvil en el

Dentro de los requerimientos funcionales que se espera que tenga la aplicación

Dentro de los requerimientos no funcionales que se espera que tenga la

En el caso de la estrategia a seguir será la creación, desde cero, de una

1.4 Planificación del Trabajo

- Una propuesta de App Intranet funcional, con los requerimientos funcionales y

1.6 Breve descripción de los otros capítulos de la memoria

Usuarios y contexto de uso

Definición de los casos de uso

Usuarios y contexto de uso

En el caso de los usuarios se identifican dos grupos principales, un usuario, que se

Análisis de perfiles de grupos de usuarios

Con la identificación de estos grupos se creó un análisis de cada uno, esto

A partir de los usuarios consultados se identificaron los siguientes modelos.

Edad Biografía Frase

Edad Biografía Frase

Edad Biografía Frase

Sesión inicial stakeholder

Preguntas realizadas al usuario Respuestas / Conclusiones

Tipos de usuario Básicos, intermedios y avanzados.

Servicios principales que podría Solicitud de vacaciones

Tabla 4 Recomendaciones stakeholder

Preguntas realizadas al usuario Respuestas / Conclusiones

¿Qué dispositivo móvil usa? El 90% usa un dispositivo Android

Tabla 5 Sesión usuarios finales

Cierre de sesión: Cualquier usuario de la aplicación debe poder finalizar sesión en la

Menú desplegable: la aplicación tendrá un menú desplegable al lado izquierdo el cual

Calendario: se tendrá una opción de calendario de eventos.

Notificaciones push: Posibilidad de notificar al usuario de los distintos eventos de

Los requisitos no funcionales para la aplicación que se identificaron son:

Rendimiento: la aplicación debe desempeñarse de manera fluida y eficiente,

Seguridad: la aplicación debe garantizar la confidencialidad de los datos de los

Usabilidad: cualquier funcionario debe ser capaz de poder utilizar la aplicación y

Mantenimiento: la aplicación debe poder ser mantenida y actualizada, dando

Optimización: El consumo de batería y de datos debe ser adecuado, y nunca dejar

Con apoyo del stakeholder se desarrollaron 4 posibles escenarios de uso que se

Marino se encuentra en su oficina, está trabajando animadamente con su ordenador

En otra ocasión un domingo por la mañana, Amanda desea comprobar el salario

Con la descripción de estos hipotéticos escenarios se pueden determinar los

Pantalla splash Pantalla de identificación

Ilustración 1 Framework de usabilidad (ISO 9241-11).

Si se toma en cuenta que la interfaz de la aplicación o prototipo es el conjunto de