Post on 25-Mar-2020
Escu
ela
Po
lité
cn
ica
Su
peri
or
de J
aé
n
Gra
do
en
Ing
enie
ría
Info
rmát
ica
ESTUDIO Y DESARROLLO DE
UN PROTOTIPO DE
PLATAFORMA ONLINE PARA
AYUDA A LA REALIZACIÓN DE
PRESENTACIONES DE FORMA
REMOTA
UNIVERSIDAD DE JAÉN
Escuela Politécnica Superior de Jaén
Trabajo Fin de Grado
Alumno: Gabriel Fernández Moral
Tutor: Prof. D. José Ramón Balsas Almagro
Dpto: Informática
Gabriel Fernández Moral Estudio y desarrollo de un prototipo de plataforma online para ayuda a la realización de presentaciones de forma remota
Universidad de Jaén
Escuela Politécnica Superior de Jaén
Departamento de Informática
Don José Ramón Balsas Almagro , tutor del Proyecto Fin de Carrera titulado: Estudio
y desarrollo de un prototipo de plataforma online para ayuda a la realización de
presentaciones de forma remota, que presenta Gabriel Fernández Moral, autoriza su
presentación para defensa y evaluación en la Escuela Politécnica Superior de Jaén.
Jaén, 2 de Septiembre de 2016
El alumno: Los tutores:
Gabriel Fernández Moral José Ramón Balsas Almagro
Gabriel Fernández Moral Estudio y desarrollo de un prototipo de plataforma online para ayuda a la realización de presentaciones de forma remota
Índice
1. Introducción .................................................................................................................... 7
1.1. Motivación ............................................................................................................... 8
1.2. Objetivos ................................................................................................................. 9
1.3. Metodología ...........................................................................................................10
1.4. Estructura del documento ......................................................................................11
2. Análisis ..........................................................................................................................13
2.1. Análisis preliminar ..................................................................................................13
2.2. Propuesta de solución ............................................................................................19
2.3. Requisitos del sistema ...........................................................................................21
2.4. Historias de usuario................................................................................................23
2.5. Planificación inicial de tareas .................................................................................26
2.6. Estudio de viabilidad ..............................................................................................29
2.7. Modelo de dominio .................................................................................................41
2.8. Análisis de la interfaz .............................................................................................42
3. Diseño ...........................................................................................................................44
3.1. Diagrama Entidad-Relación ....................................................................................45
3.2. Diagrama de componentes ....................................................................................48
3.3. Diseño de la interfaz de usuario .............................................................................50
4. Implementación .............................................................................................................52
4.1. Arquitectura ............................................................................................................53
4.2. Detalles sore implementación ................................................................................62
4.3. Despliegue del proyecto .........................................................................................75
5. Conclusiones .................................................................................................................75
5.1. Mejoras y trabajos futuros ......................................................................................77
6. Bibliografía ....................................................................................................................79
Apéndice I. Manual de instalación del sistema .....................................................................80
Apéndice II. Manual de usuario ............................................................................................82
Apéndice III. Descripción de contenidos suministrados ........................................................94
Apéndice IV. Acceso a instalación de pruebas .....................................................................95
Gabriel Fernández Moral Estudio y desarrollo de un prototipo de plataforma online para ayuda a la realización de presentaciones de forma remota
Índice de ilustraciones
Ilustración 2.1 – Microsoft PowerPoint ..................................................................................14
Ilustración 2.2 – Prezi ...........................................................................................................15
Ilustración 2.3 – Dropbox ......................................................................................................16
Ilustración 2.4 – Google Drive ..............................................................................................17
Ilustración 2.5 – Dispositivos de control remote ....................................................................18
Ilustración 2.6 – Icono de la aplicación Remote Mouse ........................................................19
Ilustración 2.7 – Propuesta de solución ................................................................................21
Ilustración 2.8 – Beneficios en relación al número de usuarios .............................................41
Ilustración 2.9 – Modelo de dominio .....................................................................................42
Ilustración 3.1 – Diagrama Entidad Relación ........................................................................45
Ilustración 3.2 – Diagrama Entidad Relación FN1 ................................................................47
Ilustración 3.3 – Diagrama de componentes de back-end ....................................................49
Ilustración 3.4 – Diagrama de componentes de aplicación front-end ....................................50
Ilustración 3.5 – Pantalla de login .........................................................................................51
Ilustración 3.6 – Pantalla de lista de ficheros ........................................................................51
Ilustración 3.7 – Pantalla de visualización de ficheros ..........................................................52
Ilustración 4.1 – Arquitectura ................................................................................................55
Ilustración 4.2 – Conversión de aplicación web a aplicaciones móviles nativas ....................57
Ilustración 4.3 – Gestión de peticiones en Node.js ...............................................................58
Ilustración 4.4 – Captura de la aplicación exportada con GoNative.io funcionando como
aplicación nativa en Android .................................................................................................61
Ilustración 4.5 – Callbacks ....................................................................................................63
Ilustración 4.6 – Callback hell ...............................................................................................64
Ilustración 4.7 – Evitar el ‘callback hell’ mediante la correcta definición de funciones ...........64
Ilustración 4.8 – Promises ...................................................................................................65
Ilustración 4.9 – Componentes .............................................................................................66
Ilustración 4.10 – Modelos y relaciones en Sequelize.js .......................................................68
Ilustración 4.11 – Utilización de Socket.io.............................................................................69
Ilustración 4.12 – JSON web tokens .....................................................................................72
Ilustración 7.1 – Firewall para Node.js ..................................................................................81
Ilustración 7.2 – Crear cuenta de usuario .............................................................................83
Ilustración 7.3 – Creando cuenta de usuario ........................................................................84
Ilustración 7.4 – Cuenta creada satisfactoriamente ..............................................................85
Ilustración 7.5 – Validación de cuenta ..................................................................................86
Ilustración 7.6 – Cuenta validada .........................................................................................86
Ilustración 7.7 – Pantalla principal sin ficheros .....................................................................87
Ilustración 7.8 – Selección de ficheros .................................................................................87
Ilustración 7.9 – Subida de ficheros ......................................................................................88
Ilustración 7.10 – Lista de ficheros actualizada ....................................................................88
Ilustración 7.11 – Borrado de ficheros ..................................................................................89
Ilustración 7.12 – Confirmar borrado ....................................................................................89
Ilustración 7.13 – Descarga de fichero .................................................................................90
Ilustración 7.14 – Fichero descargado ..................................................................................90
Ilustración 7.15 – Iniciar presentación ..................................................................................91
Gabriel Fernández Moral Estudio y desarrollo de un prototipo de plataforma online para ayuda a la realización de presentaciones de forma remota
Ilustración 7.15 – Compartir presentación ............................................................................91
Ilustración 7.16 – Enlace a presentación ..............................................................................92
Ilustración 7.17 – Visualización de presentación a través del enlace ....................................92
Ilustración 7.18 – Navegación a través de la presentación ...................................................93
Ilustración 7.19 – Cerrar sesión ............................................................................................94
Gabriel Fernández Moral Estudio y desarrollo de un prototipo de plataforma online para ayuda a la realización de presentaciones de forma remota
Índice de tablas
Tabla 2.1 – Historias de usuario ...........................................................................................26
Tabla 2.2 – Tareas ...............................................................................................................29
Tabla 2.3 – Sueldos .............................................................................................................31
Tabla 2.4 – Horas según rol .................................................................................................36
Tabla 2.5 – Costes de salarios .............................................................................................37
Tabla 2.6 – Estimaciones porcentaje de usuarios premium ..................................................39
Tabla 2.7 – Costes empresariales de desarrollo y mantenimiento ........................................40
Tabla 2.8 – Personas ...........................................................................................................44
Tabla 3.1 – Tuplas de usuarios ............................................................................................46
Tabla 3.2 – Tuplas de ficheros .............................................................................................46
Tabla 3.3 – Tuplas de presentaciones ..................................................................................46
Gabriel Fernández Moral Estudio y desarrollo de un prototipo de plataforma online para ayuda a la realización de presentaciones de forma remota
1. Introducción
El imparable avance de internet durante este siglo ha supuesto un auténtico
cambio en la forma en que las personas nos comunicamos, trabajamos, nos
relacionamos o simplemente disfrutamos de nuestro tiempo de ocio.
La popularización de herramientas y servicios como Dropbox1, Whatsapp2 o
Skype3 ha abierto todo un nuevo abanico de posibilidades que nos permiten
interactuar de forma mucho más natural con personas que no necesariamente se
encuentran en nuestras inmediaciones geográficas.
No resulta ya extraño escuchar hablar sobre entrevistas de trabajo remotas,
equipos de desarrollo distribuidos a lo largo y ancho del planeta o personas que
producen vídeos que son visionados por usuarios de todo el mundo. Todas estas
aplicaciones que ya han cambiado nuestras vidas, son posibles gracias a las
posibilidades que hoy en día nos ofrece un internet mucho más completo que en sus
orígenes.
Dentro del ámbito de las aplicaciones ofimáticas, observamos cómo se está
produciendo un claro cambio de paradigma. Si bien hasta hace unos años empresas
como Microsoft vendían licencias de uso para productos de escritorio, cada vez más
el usuario demanda aplicaciones basadas en la nube, que no necesiten de laboriosos
procesos de instalación para su uso y que permitan de serie la interacción desde
cualquier lugar y con cualquier persona.
Esta demanda ha conllevado consigo también un cambio en el modelo de
negocio. En lugar de vender licencias de uso, ahora la tendencia es el Software As A
Service (SAAS). Esta nueva forma de vender un producto, permite una mayor agilidad
a las empresas y a los usuarios frente a los inevitables cambios de este mundo, así
como una cuantiosa reducción de costes.
Merece la pena destacar a su vez, el impulso de los sistemas operativos móviles
como Android e iOS, que han conseguido popularizar el acceso a internet en movilidad
1 Sitio web de Dropbox: www.dropbox.com 2 Sitio web de Whatsapp: www.whatsapp.com 3 Sitio web de Skype: www.skype.com
Gabriel Fernández Moral Estudio y desarrollo de un prototipo de plataforma online para ayuda a la realización de presentaciones de forma remota
y han revolucionado la forma de trabajar. Son muchos los profesionales que ya no
están sujetos a su ordenador de sobremesa a la hora de realizar la mayoría de sus
tareas laborales.
También en el ámbito de la enseñanza, la forma de impartir contenidos, la
manera en que los alumnos interactúan con la información o los cauces de
comunicación entre ellos no tienen nada que ver con los habituales hace unos años.
1.1. Motivación
Este proyecto surge de una necesidad en las aulas de la Universidad de Jaén.
Como alumno de la misma, a menudo me encontraba ante la tesitura de tener que
realizar alguna presentación ante profesores y alumnos. La forma habitual de realizar
dichas exposiciones consistía en utilizar el ordenador conectado al proyector del que
constan todas las aulas.
Sin embargo, este método presentaba el inconveniente de tener que interactuar
directamente con el ordenador para realizar transiciones en dichas presentaciones.
Una solución habitual para los profesores consistía en la adquisición de un dispositivo
pulsador que permitiera realizar dichas transiciones desde algunos metros de
distancia respecto al equipo. En este sentido han sido muchos los dispositivos que he
llegado a ver, desde ratones que permiten varios metros de alcance inalámbrico, hasta
dispositivos más especializados que incluyen hasta un puntero láser.
No obstante, esta solución implicaba tener que llevar siempre contigo dicho
dispositivo. Además, para alumnos que sólo realizamos un uso esporádico de él, sería
un gasto un tanto innecesario.
Por otro lado, si bien el mercado actual cuenta con un buen número de
alternativas a la hora de realizar videoconferencias (léase Skype, Google Hangouts4,
GoToMeeting5…), resulta mucho más complejo encontrar una herramienta sencilla
para realizar presentaciones de documentos de forma remota. Muchas de estas
4 Sitio web de Google Hangouts: www.google.com/hangouts 5 Sitio web de GoToMeeting: www.gotomeeting.com
Gabriel Fernández Moral Estudio y desarrollo de un prototipo de plataforma online para ayuda a la realización de presentaciones de forma remota
soluciones incluyen opciones de edición colaborativa o para compartir pantalla, pero
ninguna de ellas incluye una solución simple y dedicada para presentar documentos
a distancia.
Todo esto ha motivado mi decisión de basar mi Trabajo de Fin de Grado en el
estudio y desarrollo de un prototipo de aplicación enfocada a realizar presentaciones
remotas en tiempo real.
1.2. Objetivos
Los objetivos globales que se pretenden conseguir mediante el desarrollo del
presente trabajo se enumeran a continuación:
Realizar un estudio de tecnologías web para la comunicación asíncrona
entre aplicaciones cliente y servidor.
Diseñar e implementar un prototipo de la aplicación de servidor que
permita la gestión de los servicios de presentación y la operación remota
tanto del orador como de los asistentes.
Desarrollo de un prototipo de aplicación cliente para el orador, adaptada
a dispositivos móviles, que envíe al servidor datos relativos al
desplazamiento dentro de una presentación.
Desarrollo de un prototipo de aplicación web que permita a los asistentes
visualizar de forma remota la presentación controlada desde el dispositivo
móvil.
En un orden más específico al desarrollo del proyecto, también se incluyen los
siguientes objetivos:
Estudio y análisis de las tecnologías de desarrollo a nivel de servidor.
Comparativa de las tecnologías de desarrollo a nivel de aplicación web.
Estudio y análisis de las tecnologías de comunicación asíncrona entre
aplicaciones web y de servidor.
Gabriel Fernández Moral Estudio y desarrollo de un prototipo de plataforma online para ayuda a la realización de presentaciones de forma remota
Investigación de las alternativas existentes en cuanto a persistencia de
datos, así como de herramientas de interacción entre la aplicación de
servidor y dicha capa de persistencia.
Comparativa de librerías visuales para el desarrollo de la interfaz de
usuario de la aplicación web.
Aplicación de los estándares REST6 [1] en la capa de servicios que
expondrá la aplicación de servidor.
Estudio y aplicación de visualización de ficheros pdf en aplicaciones web.
Despliegue del prototipo de aplicación en alguna de las plataformas
existentes en el mercado destinadas a tal fin.
En resumen, tras la realización de este trabajo, el fruto del desarrollo debería
otorgar los siguientes productos:
A. Un servicio web con interfaz REST de forma que pueda ser consumido
tanto por nuestra aplicación web como por cualquier otro producto que
decida utilizarlo.
B. Una aplicación web que saque partido de dicho servicio web para la
realización de presentaciones remotas. Esta aplicación debería ser
accesible desde dispositivos con pantallas pequeñas.
C. Un despliegue de las dos herramientas anteriores en una plataforma
destinada a tal fin que permita su utilización por parte de cualquier usuario.
1.3. Metodología
Durante el desarrollo del trabajo se utilizarán principalmente las siguientes
metodologías a nivel global:
Estudio de los requisitos del sistema a desarrollar.
Recopilación bibliográfica sobre la temática y tecnologías relacionadas.
Estimación temporal y de costes de desarrollo.
6 REST: Representational Estate Transfer. Hace referencia a una forma concreta de desarrollar interfaces para servicios web basada en la realización de operaciones sobre los datos mediante el uso de los métodos del protocolo HTTP.
Gabriel Fernández Moral Estudio y desarrollo de un prototipo de plataforma online para ayuda a la realización de presentaciones de forma remota
Diseño del sistema utilizando una metodología de orientación a
componentes utilizando el patrón de diseño Modelo-Vista-Controlador.
Implementación del prototipo del sistema.
De forma más específica al desarrollo del proyecto, tanto en su vertiente técnica,
como de gestión del mismo, también se pondrán en uso las siguientes metodologías
que facilitarán el proceso de desarrollo:
Elaboración y estimación de historias de usuario que reflejen los requisitos
del sistema a desarrollar.
Utilización de un sistema de control de versiones de forma efectiva con
división de ramas para desarrollo, producción, así como para cada nueva
funcionalidad.
Además, a lo largo del desarrollo del proyecto se aplicarán el conjunto de
metodologías ágiles SCRUM [2]. Entre sus características destacan el desarrollo
iterativo mediante ciclos de igual longitud temporal, la flexibilidad y capacidad de
adaptación a entornos cambiantes. Por tanto, teniendo en cuenta que contamos con
un equipo pequeño y que nuestro conocimiento del producto y las tecnologías pueden
ir cambiando conforme avance el desarrollo, el uso de SCRUM nos permitirá poder
adaptarnos de manera más fácil a los posibles cambios.
Por otro lado, puesto que este proyecto se plantea a largo plazo, podría continuar
añadiendo funcionalidades una vez concluida la fase de liberación del producto
mínimo viable. En este sentido, no teniendo aún definidas dichas funcionalidades, la
utilización de metodologías ágiles se antoja fundamental.
1.4. Estructura del documento
Este documento se divide en 3 índices, 6 apartados y 4 apéndices.
En primer lugar, nos encontraremos con 3 índices de diferentes elementos cada
uno.
Gabriel Fernández Moral Estudio y desarrollo de un prototipo de plataforma online para ayuda a la realización de presentaciones de forma remota
El primero de ellos, hace referencia a cada uno de los puntos de que consta todo
el documento en cuestión.
El segundo índice indica cada una de las ilustraciones que se han incluido en el
documento así como la página en la que aparecen.
Por último, un tercer índice nos señaliza cada una de las tablas que se incluyen
este documento.
A continuación, contamos con 6 puntos en los que se desarrolla detalladamente
este proyecto. El primero de ellos, realiza una breve introducción al mismo,
contemplando los objetivos y la necesidad real que motiva este trabajo.
El segundo punto, realiza un análisis sobre las herramientas similares ya
existentes en el mercado y busca un nicho de mercado que aún no se encuentre
cubierto para poder centrar en él nuestro sistema. Se realiza un estudio de viabilidad
y se tienen en cuenta todos los requisitos que debe cubrir nuestro producto así como
las tareas necesarias para su desarrollo.
En el tercer punto, se realiza un diseño a partir de los requisitos obtenidos
durante la fase de análisis. Se tiene en cuenta en cada momento los objetivos que
pretende nuestro sistema en la toma de decisiones y se establece de forma clara la
idea de la solución a desarrollar.
El siguiente punto, el punto 4, realiza una revisión más técnica sobre el proceso
de implementación del sistema, se nombran muchas de las tecnologías utilizadas
durante el mismo y se justifica el uso de cada una de ellas.
El quinto apartado, realiza una revisión de los objetivos del proyecto y extrae las
conclusiones pertinentes una vez finalidado el proyecto.
En último lugar, el punto sexto enumera una lista de referencias bibliográficas
que han servido de fuente de inspiración para el desarrollo del proyecto.
En cuanto a los apéndices, cada uno sirve a un propósito específico. El primero
de ellos indica de forma muy detallada los pasos necesarios para realizar la instalación
Gabriel Fernández Moral Estudio y desarrollo de un prototipo de plataforma online para ayuda a la realización de presentaciones de forma remota
del sistema de forma local, si bien esto no es necesario para probar el producto como
podemos ver de forma más detallada en dicho apéndice.
El segundo de los apéndice constituye una guía o manual de usuario a través de
la funcionalidad básica que se incluye en el prototipo desarrollado con el fin de guiar
al posible lector de esta memoria en el uso de la aplicación desarrollada.
El tercer apéndice enumera de forma breve los contenidos suministrados como
entrega final junto a esta memoria.
El último de los apéndices indica el enlace de acceso a la versión de pruebas
desplegada para poder realizar pruebas sobre este proyecto sin necesidad de realizar
una instalación previa.
2. Análisis
2.1. Análisis preliminar
El uso de presentaciones para exponer ideas o trabajos se ha convertido en algo
habitual en nuestra sociedad. Tanto en el sector empresarial, como en el educativo,
es ya muy común asistir a reuniones, conferencias o clases magistrales cuyo hilo
conductor son las diapositivas.
El número de soluciones existentes para tal fin se ha visto incrementado con la
popularización del acceso a internet y la aparición de nuevas tecnologías que permiten
desarrollos mucho más complejos.
Dentro de este sector existen un buen número de aplicaciones muy diferentes
entre sí, desde las tradicionales diapositivas de PowerPoint, hasta productos mucho
más elaborados con multitud de opciones.
A continuación procedemos a realizar un breve análisis de algunas de las
soluciones más relevantes.
Gabriel Fernández Moral Estudio y desarrollo de un prototipo de plataforma online para ayuda a la realización de presentaciones de forma remota
2.1.1. Microsoft PowerPoint
Ilustración 2.1 – Microsoft PowerPoint
Microsoft PowerPoint es sin duda la aplicación más veterana dentro de este
sector [3]. Los orígenes de su desarrollo se remontan a la década de los ochenta y
gracias a sus numerosas opciones y a su inclusión dentro de la suite ofimática de
Microsoft ha sabido ganarse un buen hueco en el mercado.
A pesar de las numerosas bondades de PowerPoint como herramienta de
edición, su principal limitación quizás sea la restricción de trabajar con tipos de ficheros
propios de esta solución. Esto, en un mundo en el que estamos acostumbrados a
trabajar con una gran variedad de diferentes tipos de ficheros, puede ser un problema.
PowerPoint ha dado pasos en la realización de presentaciones remotas
incluyendo entre otras novedades, la liberación de las aplicaciones de la suite
ofimática de Microsoft para las plataformas móviles Android e iOS.
Estas aplicaciones móviles permiten comenzar a crear una presentación para
continuar trabajando en ella posteriormente en un ordenador. Sin embargo, no
incluyen la posibilidad de difundir presentaciones ni de utilizar el terminal móvil como
mando para una presentación remota.
Las últimas versiones de Powerpoint incluyen la característica de realización de
presentaciones en línea. Sin embargo, éstas necesitan de una configuración previa
de un servidor específico para su difusión. Otra alternativa mucho más viable son los
planes de suscripción para Office 365. Estos planes tienen unos precios que oscilan
alrededor de los 10 € por usuario y mes. Sin embargo, siguen teniendo la gran
desventaja de tan sólo permitirnos realizar presentaciones sobre los documentos
realizados con la propia aplicación de Powerpoint.
Gabriel Fernández Moral Estudio y desarrollo de un prototipo de plataforma online para ayuda a la realización de presentaciones de forma remota
2.1.2. Prezi
Ilustración 2.2 – Prezi
Prezi surgió en 2009 como una vuelta de tuerca más en el ámbito de las
presentaciones. Se enfoca en la posibilidad de desplazarse a través de un documento
a través de zooms en las diferentes partes del mismo, creando así un efecto visual
muy sorprendente.
Si bien la idea de esta empresa ha supuesto una pequeña revolución en la forma
de visualizar las diapositivas [4], también es cierto que su capacidad para asombrar
pierde efecto una vez la solución ha llegado a ser conocida por un grupo amplio de la
población.
Prezi incluye una novedosa forma de realizar presentaciones remotas mediante
desplazamientos. Sin embargo, presenta dos grandes limitaciones. La primera de
éstas, consiste en su incapacidad para trabajar sobre documentos no generados en
la misma plataforma, esto es, tan sólo podemos realizar presentaciones sobre los
documentos que generemos con el editor de presentaciones de Prezi. Por otro lado,
esta aplicación web se basa en tecnologías en desuso como son Adobe Flash [5] y
Adobe Air, lo cual limita tanto su compatibilidad con otros servicios y navegadores,
como sus posibilidades de desarrollo y mantenimiento.
Gabriel Fernández Moral Estudio y desarrollo de un prototipo de plataforma online para ayuda a la realización de presentaciones de forma remota
2.1.3. Dropbox
Ilustración 2.3 – Dropbox
El caso de Dropbox es quizás el de una de las compañías de reciente creación
más exitosas de los últimos años [6]. Sus comienzos se remontan a 2007 y, tras ser
pretendida por otras grandes empresas tecnológicas como Apple, decidió seguir su
propio camino.
Su principal baza es la de permitir almacenar ficheros en la nube, accesibles
desde cualquier lugar con conexión a internet. También permite compartir los ficheros
alojados con cualquier otra persona incluso si no dispone de una cuenta en el servicio.
Dropbox se presenta no sólo como una aplicación, sino como un servicio, lo que
permite su integración con multitud de otras aplicaciones, hecho del que han sabido
sacar partido otras plataformas.
Pese a que Dropbox cuenta ya con herramientas integradas en su propia
aplicación web capaces de visualizar ciertos contenidos como imágenes o pdf, aún no
dispone de capacidad alguna para realizar presentaciones remotas.
Gabriel Fernández Moral Estudio y desarrollo de un prototipo de plataforma online para ayuda a la realización de presentaciones de forma remota
2.1.4. Google Drive
Ilustración 2.4 – Google Drive
Tras el éxito de Dropbox, Google decidió lanzar al mercado su propio sistema de
almacenamiento. Con Google Drive, no sólo tenemos la capacidad de almacenar y
compartir ficheros, sino que también integra un completo modo de edición colaborativa
[7].
Las presentaciones creadas en esta plataforma pueden reproducirse
remotamente a través de Hangouts, otra de las herramientas online de Google. Sin
embargo, esto reduce mucho el ámbito de uso. Si bien tiene sentido al usar la suite
completa de aplicaciones de Google, una vez más nos encontramos ante la limitación
de tener que usar dicho ecosistema de aplicaciones y tipos de ficheros para todo.
Gabriel Fernández Moral Estudio y desarrollo de un prototipo de plataforma online para ayuda a la realización de presentaciones de forma remota
2.1.5. Dispositivos de control remoto
Ilustración 2.5 – Dispositivos de control remote
En cuanto a elementos hardware para el control de presentaciones, el mercado
nos ofrece un amplio rango de productos. El precio de estos mandos oscila entre los
10 y los 100€ dependiendo del grado de sofisticación que exijamos.
Sin embargo, muchos de estos productos sólo son compatibles con Microsoft
PowerPoint y no ofrecen soporte a otras plataformas de presentaciones remotas. Su
rango de uso suele establecerse en torno a unos 10 metros lo que quizás aporta una
capacidad suficiente si nos limitamos a su uso dentro de una habitación. Por otro lado,
estos dispositivos podrían no ser suficientes para la realización de presentaciones en
grandes conferencias donde la distancia entre el presentador y el equipo puede
superar con creces dicho rango.
2.1.6. Aplicaciones de ratón para móviles
Otra alternativa en el mercado actual serían las aplicaciones de ratón para
móviles. Estas aplicaciones se conectan mediante wifi o bluetooth a un ordenador y
permiten simular la utilización de un ratón mediante la pantalla táctil de nuestro
dispositivo móvil.
Gabriel Fernández Moral Estudio y desarrollo de un prototipo de plataforma online para ayuda a la realización de presentaciones de forma remota
Ilustración 2.6 – Icono de la aplicación Remote Mouse
Un buen ejemplo de este sector es el representado por la aplicación Remote
Mouse7. Al igual que el resto de sus competidoras, pueden ser bastante útiles en
alguna situación de emergencia, si bien la interacción para controlar un ordenador con
ellas resulta bastante engorrosa para el usuario.
2.2. Propuesta de solución
Como hemos podido comprobar en el análisis preliminar, existe un buen número
de soluciones relacionadas con el ámbito de las presentaciones, así como el
almacenamiento de ficheros. Sin embargo, ninguna de ellas ofrece una forma sencilla
de realizar presentaciones sobre ficheros de los que ya disponga el cliente si no es
creandolos directamente en dichas plataformas.
Intentar abordar este proyecto como la creación de una plataforma que
permitiera realizar presentaciones de cualquier fichero sería una tarea demasiado
ardua. No obstante, esta no debe ser jamás la idea de un proyecto que empieza desde
cero.
En lugar de ello, la idea inicial sería apostar por conseguir realizar
presentaciones remotas de ficheros pdf. Éste es un tipo de fichero muy común y con
el que la mayoría de usuarios están acostumbrados a trabajar. Además, presenta la
7 Aplicación Remote Mouse para android: https://play.google.com/store/apps/details?id=com.hungrybolo.remotemouseandroid
Gabriel Fernández Moral Estudio y desarrollo de un prototipo de plataforma online para ayuda a la realización de presentaciones de forma remota
ventaja de que casi cualquier documento puede convertirse fácilmente a este tipo de
fichero, con lo cuál podría ser presentado a través de nuestra herramienta.
Por otro lado, aún no sabemos cómo de grande puede llegar a ser nuestro
proyecto, o qué impacto puede llegar a tener en el público. Teniendo esto en cuenta,
deberíamos pensar en una arquitectura escalable. Es decir, debemos pensar al
realizar el diseño de nuestro sistema en que, quizás, con el tiempo no sólo tengamos
una aplicación web que quiera utilizar el servicio sino también posiblemente
aplicaciones móviles, aplicaciones de Windows u OSX, televisiones inteligentes…
Por tanto, la idea inicial del sistema consistirá en:
Una capa de persistencia, que pueda ser fácilmente migrada a sistemas
mayores de almacenamiento si así se requiere.
Una capa de lógica de negocio que se comunicará con dicha capa de
persistencia y, a su vez, expondrá las funcionalidades a través de un
servicio REST.
Una aplicación adaptable a pantallas de teléfonos móviles que consuma
los servicios REST haciendo así uso de toda la funcionalidad.
La comunicación entre la aplicación web y el servicio debería realizarse de forma
asíncrona, ya que, una vez el cliente de la aplicación web se conecte a una
presentación remota, dicha aplicación deberá recibir eventos desde el servicio cada
vez que se produzca un desplazamiento a través de la navegación en la presentación.
Gabriel Fernández Moral Estudio y desarrollo de un prototipo de plataforma online para ayuda a la realización de presentaciones de forma remota
Ilustración 2.7 – Propuesta de solución
2.3. Requisitos del sistema
En este apartado procedemos a detallar los requisitos, tanto funcionales como
no funcionales, que debería satisfacer nuestro sistema. Este es un paso previo a la
fase de diseño, que nos permitirá tener una idea clara del ámbito del problema a
resolver.
2.3.1. Requisitos funcionales
Entre los requisitos funcionales incluimos todos aquellos que deben dotar al
producto de funcionalidades específicas.
El sistema debe permitir al usuario la creación de una cuenta a partir de
un nombre de usuario, contraseña y dirección de correo electrónico.
Al crear una cuenta, el sistema debe enviar un correo electrónico a la
dirección proporcionada con un enlace que permita validar dicha cuenta.
Esto servirá para garantizar que dicha cuenta de correo electrónico
pertenece al usuario.
Gabriel Fernández Moral Estudio y desarrollo de un prototipo de plataforma online para ayuda a la realización de presentaciones de forma remota
El sistema debe permitir al usuario acceder mediante los credenciales de
identificación asociados a una cuenta validada.
El usuario debe poder subir cualquier tipo de fichero al sistema una vez
se ha identificado con los credenciales de su cuenta.
El sistema debe ser capaz de mostrar al usuario una lista completa de
todos los ficheros que el usuario a introducido en el sistema.
Cada fichero debe poder ser eliminado por su usuario dueño cuando éste
lo desee.
El usuario debe poder descargar cada uno de los ficheros que ha
introducido en el sistema.
Debe permitir visualizar ficheros que sean de tipo pdf y comenzar así una
presentación del mismo.
Al iniciar una presentación, el sistema debe generar un enlace que
identifique unívocamente a dicha presentación.
El usuario debe poder ver el enlace de su presentación para compartirlo
con los posibles espectadores que quieran seguir dicha presentación.
Cualquier usuario, incluso sin cuenta en el sistema, que acceda al enlace
de una presentación válida, debe poder visualizar el documento asignado
a dicha presentación.
El usuario que ha iniciado una presentación, debe poder desplazarse
hacia adelante y atrás a través del documento.
Los espectadores de una presentación deben ver en tiempo real los
desplazamientos a través de la presentación conforme el presentador los
realice.
El usuario debe poder finalizar una presentación. En este caso, la
presentación ya no será accesible a través del enlace asignado.
Si una presentación no finaliza correctamente en 24 horas desde su
creación, el sistema deberá encargarse de eliminarla.
2.3.2. Requisitos no funcionales
En esta sección se incluyen características que debe cumplir el producto sin
aportar necesariamente una funcionalidad específica al producto.
Gabriel Fernández Moral Estudio y desarrollo de un prototipo de plataforma online para ayuda a la realización de presentaciones de forma remota
El sistema debe ser accesible por nuevas aplicaciones que se desarrollen
en el futuro.
La aplicación web debe contar con una interfaz adaptada a móviles que
permita su uso en terminales de reducidas dimensiones. Este requisito
estará especialmente orientado a permitir controlar la presentación desde
un terminal móvil.
El sistema debe proporcionar la seguridad necesaria para que los ficheros
de cada usuario no sean expuestos a terceros sin su consentimiento.
La aplicación web debe contar con una estética minimalista para que el
usuario encuentre fácilmente las opciones.
2.4. Historias de usuario
Puesto que hemos decidido utilizar una metodología SCRUM durante el
desarrollo, a continuación definiremos las historias de usuario, que reflejarán de forma
global el trabajo a realizar durante todo el desarrollo.
Además, procederemos a valorar las historias de usuario con puntos de historia
que nos darán una estimación aproximada de la cantidad de trabajo que puede
conllevar el desarrollo de cada una de ellas.
Número identificativo Historia de usuario Puntos de historia
1
Como usuario, me gustaría poder visualizar una lista de mis ficheros para poder interactuar con ellos.
5
2
Como usuario, me gustaría poder subir ficheros a la plataforma para poder almacenarlos en el sistema.
5
3
Como usuario, me gustaría que la lista de ficheros se actualice al añadir nuevos ficheros al sistema para poder interactuar con los ficheros que acabo de añadir.
2
4 Como usuario, 3
Gabriel Fernández Moral Estudio y desarrollo de un prototipo de plataforma online para ayuda a la realización de presentaciones de forma remota
me gustaría poder descargar los ficheros que he añadido a la plataforma para poder recuperarlos siempre que quiera.
5
Como programador, me gustaría notificar al usuario mediante alertas accesibles si se ha producido algún error en el sistema, para que el usuario sepa que algún tipo de problema está afectando a su experiencia.
3
6
Como usuario, me gustaría poder acceder al sistema con mis credenciales, para evitar que otra persona pueda acceder a mis ficheros.
8
7
Como programador, me gustaría que todas las interacciones con el API Resto requieran de un token para garantizar la autorización de dicha acción.
13
8
Como usuario, me gustaría que mis ficheros se muestren por páginas si hay un gran número de ellos para poder visualizarlos de forma correcta.
5
9
Como usuario, me gustaría poder salir del sistema cuando ya no necesite trabajar más para impedir que otra persona pueda acceder a mi cuenta.
5
10
Como programador, me gustaría evitar que un usuario pueda añadir al sistema dos ficheros con el mismo nombre para evitar conflictos.
3
11
Como usuario, me gustaría poder crear una cuenta en el sistema para poder acceder y trabajar con mis ficheros.
5
12
Como programador, me gustaría que en el proceso de creación de una cuenta sea necesario validar la cuenta de correo electrónico asociada para asegurarme de que dicha dirección pertenece al usuario.
3
Gabriel Fernández Moral Estudio y desarrollo de un prototipo de plataforma online para ayuda a la realización de presentaciones de forma remota
13
Como usuario, me gustaría poder visualizar mis ficheros pdf para poder iniciar una presentación con ellos.
13
14
Como programador, me gustaría que sólo los ficheros de tipo pdf puedan ser visualizados para restringir el ámbito del proyecto.
1
15
Como usuario, me gustaría poder desplazarme a través de las páginas de mi fichero pdf mientras lo visualizo para poder leer distintas páginas.
5
16
Como usuario, me gustaría poder disponer de un enlace a mi presentación para poder compartirlo con los posibles espectadores.
3
17
Como usuario, me gustaría que cualquier espectador que acceda al enlace de mi presentación pueda ver mi presentación para visualizar el documento.
8
18
Como usuario, me gustaría que cada vez que me desplazo por las páginas del documento de mi presentación, dichos cambios se reflejen también en la visualización de los espectadores para que puedan seguir la presentación en tiempo real.
8
19
Como usuario, me gustaría que cuando un espectador se conecte a mi presentación, visualice la página actual en que se encuentra la presentación para que su visualización esté desde el principio actualizada.
2
20
Como usuario, me gustaría que mi presentación no sea accesible una vez haya cerrado dicha presentación para evitar que cualquier persona con el enlace pueda
5
Gabriel Fernández Moral Estudio y desarrollo de un prototipo de plataforma online para ayuda a la realización de presentaciones de forma remota
seguir visualizando mi documento.
21
Como programador, me gustaría que cualquier presentación iniciada hace más de 24 horas se elimine automáticamente para evitar una acumulación de presentaciones inutilizadas en el servidor.
3
Tabla 2.1 – Historias de usuario
En total tenemos una estimación de 108 puntos de historia.
2.5. Planificación inicial de tareas
Una vez elaborada la lista completa de historias de usuario, procedemos a
descomponer dichas historias en tareas más concretas, que nos permitan tener una
mejor idea del trabajo que conlleva cada historia de usuario.
Historia de usuario Tareas
1
Instalación de la base de datos
Instalación del servidor para el back-end
Creación de modelos de fichero y usuario
Creación del servicio web para recuperar los datos de ficheros asociados a un usuario
Instalación del servidor para la aplicación web
Diseño y creación de interfaz de usuario para la lista de ficheros en la aplicación web
Realizar solicitud de ficheros desde la aplicación web al api REST
Actualizar la lista de ficheros en la interfaz de usuario
2
Modificación de interfaz de usuario para permitir añadir nuevos ficheros
Lógica de envío de ficheros desde la aplicación web al api REST
Creación del servicio web en el api REST para añadir nuevos ficheros
Persistencia de los nuevos ficheros en base de datos
Gabriel Fernández Moral Estudio y desarrollo de un prototipo de plataforma online para ayuda a la realización de presentaciones de forma remota
Persistencia de los nuevos ficheros en disco en el servidor del back-end
3 Refrescar la lista de ficheros cuando llegue la respuesta del back-end tras haber añadido nuevos ficheros.
4
Modificar la interfaz de usuario para permitir descargar cada fichero existente
Realizar petición de descarga al api REST
Crear servicio web para descargar un fichero
Recuperar instancias de fichero de la base de datos
Recuperar fichero de disco duro y devolverlo como respuesta
5
Diseño e implementación de la interfaz de usuario para mostrar alertas.
Gestión de alertas al mostrar la lista de ficheros
Gestión de alertas al añadir ficheros
Gestión de alertas al descargar ficheros
6
Diseño e implementación de interfaz de usuario de login
Realizar petición de autentificación al api REST
Crear un servicio web para autentificación
Redireccionamiento a pantalla principal tras login exitoso
Redireccionamiento a pantalla de login tras intentar acceder a cualquier ruta sin estar autenticado
7
Generación de tokens en el servicio web de login y envío a cliente
Envío de token en cada petición desde la aplicación web
Comprobación de token en cada acceso al api REST salvo el login
8 Diseño e implementación de la interfaz de usuario paginada
Gestión de cambio de páginas
9
Diseño e implementación de la interfaz de usuario de logout
Borrado de token de web storage
Redirección a pantalla de login
10 Gestión de subida de ficheros con nombres ya existentes
Muestra de alerta
11
Diseño e implementación de interfaz de usuario para creación de cuentas
Realizar petición de creación de cuenta al api REST
Creación de servicio web para creación de cuentas
Generación de enlace tras crear cuenta
Gabriel Fernández Moral Estudio y desarrollo de un prototipo de plataforma online para ayuda a la realización de presentaciones de forma remota
12
Envío de enlace a la dirección de correo electrónico asociada a la cuenta
Redirección del enlace a pantalla de login de la aplicación web
Petición de validación al api REST
Creación de servicio web para validación de cuentas
Notificación de éxito o error
13
Diseño e implementación de interfaz de usuario para visualización de ficheros pdf
Solicitud de fichero al api REST con autentificación
Implementación de visualización de fichero pdf
14
Comprobación de tipo de fichero al solicitar visualización
Mostrar alerta en caso de que no sea un fichero de tipo pdf
15
Diseño e implementación de interfaz de usuario para navegación a través de documento
Gestión de eventos sobre los botones de navegación
Renderizado de páginas del documento
16
Llamada al api REST para generación de presentación
Creación de servicio web para creación de presentaciones
Generación de url asociada a la presentación y envío a la aplicación web
Guardado de la url en local storage
Diseño e implementación de interfaz de usuario para mostrar url asociada a presentación
17
Redirección de url a aplicación web
Realizar petición de fichero al api REST
Comprobar en el servicio web de descarga de ficheros que existe una presentación para el fichero asociado y que el token de la url es correcto
Visualización de fichero asociado a url en aplicación web
Mostrar alerta en caso de error o acceso no autorizado.
18
Creación de servicio web para gestión de mensajes de presentaciones
Creación de namespace asociado a la presentación al iniciar presentación
Envío de mensajes al namespace de la presentación en los eventos de cambio de página
Conexión al namespace de la presentación cuando un espectador accede al url de una presentación
Gabriel Fernández Moral Estudio y desarrollo de un prototipo de plataforma online para ayuda a la realización de presentaciones de forma remota
Replica de mensajes del namespace a todos los espectadores de dicho namespace
Gestión de eventos de cambios de página en el visualizador de los espectadores
19
Guardado de última página visualizada para cada namespace
Envío de mensaje de página actual a espectador recién conectado
Gestión de mensaje de página actual para mostrar dicha página
20
Gestión de eventos de cerrado de presentación
Realizar petición al api REST para eliminación de presentación
Creación de servicio web para borrado de presentaciones
21 Automatización de borrado de instancias antiguas de presentaciones en base de datos
Tabla 2.2 – Tareas
2.6. Estudio de viabilidad
En este apartado realizaremos un análisis sobre la viabilidad de este proyecto,
tanto para su presentación para la asignatura de Trabajo de Fin de Grado, como para
una posterior puesta en marcha en el mercado.
2.6.1. Análisis de tiempos de desarrollo
Como podemos observar de los puntos anteriores, el ámbito de nuestro proyecto
queda constituido por un conjunto de 21 historias de usuario que, en total, suman una
estimación de 108 puntos de historia.
A partir del trabajo del alumno en proyectos similares, y teniendo en cuenta la
limitación de horas disponibles en el día a día, se estima que el alumno será capaz de
alcanzar una media de 10 puntos de historia por cada ciclo de iteración bisemanal
trabajando durante 3 horas por cada jornada laboral.
Gabriel Fernández Moral Estudio y desarrollo de un prototipo de plataforma online para ayuda a la realización de presentaciones de forma remota
Esta estimación nos llevaría a la necesidad de contar con 11 ciclos de iteración,
o lo que es lo mismo, 22 semanas naturales. Esto es, 5 meses y medio
aproximadamente.
El tiempo requerido para la realización de este prototipo de aplicación encaja
dentro de los límites establecidos para la asignatura de Trabajo de Fin de Grado, por
lo que podemos asegurar que este proyecto es viable para tal fin. Sin embargo, para
su posterior explotación comercial sería necesario el desarrollo de nuevas
funcionalidades que permitan monetizar el producto, lo que requeriría una mayor
dedicación de tiempo. En ese caso, la viabilidad del proyecto estaría comprometida a
un plazo de tiempo mayor al que permite esta asignatura.
2.6.2. Análisis de costes de desarrollo para este proyecto
Para la puesta en marcha del proyecto contaremos con el mínimo número
necesario de roles que se describirán a continuación. Más adelante, una vez el
proyecto empezara a generar beneficios, se podrían incluir nuevos roles que cubrieran
necesidades mucho más específicas.
Analista de negocio: será la persona encargada de gestionar los requisitos
de las funcionalidades a desarrollar. Su trabajo comprenderá el desglose
de cada nueva característica para una mejor definición de la misma.
Participará con el resto del equipo en la elaboración de las historias de
usuario, aportando siempre un punto de vista técnico enfocado a los
requisitos. Es el principal encargado de definir de forma clara y concisa el
ámbito del problema.
Programador: será el encargado de diseñar e implementar la solución
técnica ante el problema definido por el analista de negocio. Participará
también en la elaboración y valoración de las historias de usuario,
aportando en este caso un enfoque basado en la complejidad del software
a desarrollar. Debe velar por la seguridad, estabilidad y escalabilidad del
producto.
Diseñador de interfaz de usuario: la persona al cargo de este rol deberá
diseñar desde un punto de vista estético y funcional la capa de interacción
Gabriel Fernández Moral Estudio y desarrollo de un prototipo de plataforma online para ayuda a la realización de presentaciones de forma remota
de nuestro software con el usuario. Será el principal encargado de
garantizar que la experiencia de uso sea satisfactoria y el producto resulte
intuitivo en su utilización.
Analista de calidad: este rol es el asociado a aquella persona que debe
velar por la calidad de nuestro software. Su principal objetivo es garantizar
que nuestra solución al problema cumple con todos los requisitos
establecidos. Definirá y aplicará los procesos de prueba que deberán
aplicarse al final de cada iteración para asegurar que el producto cumple
con lo demandado.
La tabla 2.3 incluye una estimación de salarios basado en el convenio colectivo
de Telefónica publicado en el BOE a fecha de 21 de enero de 2016 [8] para una
jornada regular de 160 horas mensuales y el cálculo proporcional al trabajo de una
hora para cada uno de estos roles.
Rol – rango salarial Sueldo mensual Sueldo por hora
Analista de negocio –
Titulado Superior o Máster
Nivel 5
3.655,67 € 22,84 €
Programador – Técnico
Medio o de Grado Nivel 5 3.011,67 € 18,82 €
Diseñador de interfaz de
usuario – Operador
Audiovisual Nivel 5
2.376,85 € 14,86
Analista de calidad –
Técnico Medio o de Grado
Nivel 5
3.011,67 € 18,82 €
Tabla 2.3 – Sueldos
A continuación, realizamos una estimación de las horas de trabajo que conllevará
cada una de las tareas en que se descompone el proyecto para cada uno de los
Gabriel Fernández Moral Estudio y desarrollo de un prototipo de plataforma online para ayuda a la realización de presentaciones de forma remota
diferentes roles. De esta forma, podremos tener un cálculo aproximado del número de
horas que serán necesarias de trabajo de cada rol.
Tareas Horas analista Horas
programador
Horas
diseñador
de
interfaz
Horas
analista
de
calidad
Instalación de la base de datos
1
Instalación del servidor para el back-end
2
Creación de modelos de fichero y usuario
1 1
Creación del servicio web para recuperar los datos de ficheros asociados a un usuario
1 2 1
Instalación del servidor para la aplicación web
1
Diseño y creación de interfaz de usuario para la lista de ficheros en la aplicación web
1 2 3 2
Realizar solicitud de ficheros desde la aplicación web al api REST
2
Actualizar la lista de ficheros en la interfaz de usuario
1 2
Modificación de interfaz de usuario para permitir añadir nuevos ficheros
2 2 1
Lógica de envío de ficheros desde la aplicación web al api REST
4 1 3
Creación del servicio web en el api REST para añadir nuevos ficheros
2
Persistencia de los nuevos ficheros en base de datos
2 2
Persistencia de los nuevos ficheros en disco en el servidor del back-end
2 3
Refrescar la lista de ficheros cuando llegue la
2 1
Gabriel Fernández Moral Estudio y desarrollo de un prototipo de plataforma online para ayuda a la realización de presentaciones de forma remota
respuesta del back-end tras haber añadido nuevos ficheros.
Modificar la interfaz de usuario para permitir descargar cada fichero existente
1 2
Realizar petición de descarga al api REST
2
Crear servicio web para descargar un fichero
2
Recuperar instancias de fichero de la base de datos
2
Recuperar fichero de disco duro y devolverlo como respuesta
3 2
Diseño e implementación de la interfaz de usuario para mostrar alertas.
2 3
Gestión de alertas al mostrar la lista de ficheros
2 2
Gestión de alertas al añadir ficheros
2 2
Gestión de alertas al descargar ficheros
2 2
Diseño e implementación de interfaz de usuario de login
1 2 3
Realizar petición de autentificación al api REST
2
Crear un servicio web para autentificación
2
Redireccionamiento a pantalla principal tras login exitoso
2 2
Redireccionamiento a pantalla de login tras intentar acceder a cualquier ruta sin estar autenticado
2 2
Generación de tokens en el servicio web de login y envío a cliente
1 2
Envío de token en cada petición desde la aplicación web
2
Comprobación de token en cada acceso al API REST salvo el login
2
Gabriel Fernández Moral Estudio y desarrollo de un prototipo de plataforma online para ayuda a la realización de presentaciones de forma remota
Diseño e implementación de la interfaz de usuario paginada
2 2
Gestión de cambio de páginas
2 2
Diseño e implementación de la interfaz de usuario de logout
2 2
Borrado de token de web storage
2
Redirección a pantalla de login
2 2
Gestión de subida de ficheros con nombres ya existentes
2
Muestra de alerta 1 2
Diseño e implementación de interfaz de usuario para creación de cuentas
2 1 1
Realizar petición de creación de cuenta al api REST
2
Creación de servicio web para creación de cuentas
2
Generación de enlace tras crear cuenta
1 3
Envío de enlace a la dirección de correo electrónico asociada a la cuenta
2 2 3
Redirección del enlace a pantalla de login de la aplicación web
3 2
Petición de validación al api REST
2
Creación de servicio web para validación de cuentas
2
Notificación de éxito o error
2 1
Diseño e implementación de interfaz de usuario para visualización de ficheros pdf
4 2 2
Solicitud de fichero al api REST con autentificación
2
Implementación de visualización de fichero pdf
4 2
Comprobación de tipo de fichero al solicitar visualización
2 1
Gabriel Fernández Moral Estudio y desarrollo de un prototipo de plataforma online para ayuda a la realización de presentaciones de forma remota
Mostrar alerta en caso de que no sea un fichero de tipo pdf
2 1
Diseño e implementación de interfaz de usuario para navegación a través de documento
1 2 2
Gestión de eventos sobre los botones de navegación
2
Renderizado de páginas del documento
3
Llamada al api REST para generación de presentación
2
Creación de servicio web para creación de presentaciones
1 2
Generación de url asociada a la presentación y envío a la aplicación web
1 2
Guardado de la url en local storage
2
Diseño e implementación de interfaz de usuario para mostrar url asociada a presentación
2 2 1
Redirección de url a aplicación web
2 2
Realizar petición de fichero al api REST
2
Comprobar en el servicio web de descarga de ficheros que existe una presentación para el fichero asociado y que el token de la url es correcto
3 1
Visualización de fichero asociado a url en aplicación web
2 1 2
Mostrar alerta en caso de error o acceso no autorizado.
2 1
Creación de servicio web para gestión de mensajes de presentaciones
3
Creación de namespace asociado a la presentación al iniciar presentación
1
Gabriel Fernández Moral Estudio y desarrollo de un prototipo de plataforma online para ayuda a la realización de presentaciones de forma remota
Envío de mensajes al namespace de la presentación en los eventos de cambio de página
2
Conexión al namespace de la presentación cuando un espectador accede al url de una presentación
2
Réplica de mensajes del namespace a todos los espectadores de dicho namespace
2
Gestión de eventos de cambios de página en el visualizador de los espectadores
2 2
Guardado de última página visualizada para cada namespace
2
Envío de mensaje de página actual a espectador recién conectado
1
Gestión de mensaje de página actual para mostrar dicha página
1 1
Gestión de eventos de cerrado de presentación
1
Realizar petición al api REST para eliminación de presentación
2
Creación de servicio web para borrado de presentaciones
2 1
Automatización de borrado de instancias antiguas de presentaciones en base de datos
1 2 1
TOTAL 16 159 26 53 Tabla 2.4 – Horas según rol
Teniendo en cuenta estas estimaciones de horas y el sueldo promedio por hora
de cada rol, podemos realizar el siguiente presupuesto de gastos en salarios para la
elaboración de este proyecto. Podemos comprobarlo en la tabla 2.5.
Gabriel Fernández Moral Estudio y desarrollo de un prototipo de plataforma online para ayuda a la realización de presentaciones de forma remota
Rol – rango salarial Sueldo por hora Horas Coste total
Analista de negocio –
Titulado Superior o
Máster Nivel 5
22,84 €
16 365,44 €
Programador –
Técnico Medio o de
Grado Nivel 5
18,82 €
159 2992,38 #
Diseñador de interfaz
de usuario –
Operador Audiovisual
Nivel 5
14,86
26 386,36 €
Analista de calidad –
Técnico Medio o de
Grado Nivel 5
18,82 €
53 997,46 €
Coste total 4.741,64 €
Tabla 2.5 – Costes de salarios
Como podemos ver, los costes de salarios para la realización de este proyecto
supondrían un total de 4.741,64 € aproximadamente.
El resto de elementos necesarios para el desarrollo de este proyecto no han
supuesto coste alguno, a saber:
Equipo portátil para el desarrollo: ya disponible previamente.
Suscripción a GitHub para repositorios privados: gratuita gracias al
acuerdo de la Universidad de Jaén.
Suscripción a Heroku: la versión gratuita ha sido suficiente para lo
necesario durante esta primera versión.
Por tanto, el coste total del desarrollo de este proyecto se remite directamente al
coste de salarios, esto es 4.741,64 €.
Gabriel Fernández Moral Estudio y desarrollo de un prototipo de plataforma online para ayuda a la realización de presentaciones de forma remota
2.6.3. Análisis de explotación
A continuación, realizamos un análisis sobre el futuro de este proyecto. Esto es,
en caso de continuar con este desarrollo y crear una empresa con el fin de explotar
este producto, ¿cuáles serían los costes?, ¿qué volumen de usuarios necesitaríamos
para que la actividad fuera sostenible? En este apartado intentaremos aclarar estas
cuestiones.
La idea de negocio de este proyecto conlleva la necesidad de un equipo de
desarrollo estable que aporte de manera continua nuevas funcionalidades al producto
principal de la compañía. Esta situación deberá mantenerse una vez el producto
mínimo viable haya sido liberado al mercado. Por tanto, en lugar de realizar una
estimación de horas de trabajo necesarias para cada rol, se establece que los
contratos serán indefinidos y el cálculo de los costes de desarrollo asociados a los
salarios será por meses completos y no por horas de trabajo.
El modelo de explotación diseñado para nuestro proyecto seguiría el paradigma
freemium, esto es, ofreceríamos el servicio a todo el mundo de forma gratuita para
garantizar que el sistema se da a conocer y la gente puede probarlo en cualquier
momento. Esta versión sin embargo sería una versión limitada, con poco espacio de
almacenamiento y alguna restricción respecto al número de espectadores.
Para complementar a esta versión, existiría también una versión de pago con
más almacenamiento y número de espectadores ilimitados para las presentaciones.
Además, existiría la posibilidad de conseguir espacio adicional.
Para calcular el precio que debería tener la versión de pago, realizaremos una
estimación de costes y beneficios mediante varios escenarios.
Para las cuentas gratuitas hemos decidido que el espacio disponible será de 100
MB, mientras que para las cuentas premium el espacio será de 1 GB con opción de
ampliación.
Gabriel Fernández Moral Estudio y desarrollo de un prototipo de plataforma online para ayuda a la realización de presentaciones de forma remota
Basándonos en los planes de de pago de Heroku [9], esto nos supone unos
costes por usuario gratuito de 0,2 € y de 2 € por usuario premium en la modalidad
standard 6 de los planes que ofrece dicha empresa.
Como desconocemos el porcentaje de nuestros usuarios que optarán por una
cuenta de pago, realizaremos tres estimaciones diferentes.
Estimación
pesimista
Estimación
realista
Estimación
optimista
Usuarios de
pago /
usuarios
totales
1 / 1000 1/100 1/10
Precio mínimo
para usuario
de pago
202 € 22 € 4 €
Tabla 2.6 – Estimaciones porcentaje de usuarios premium
Como podemos ver en la tabla, la estimación pesimista queda un poco fuera de
lugar, ya que en este caso los costes serían tan elevados que nuestra empresa habría
fracasado y no sería viable.
Por tanto, decidimos apostar por la estimación realista como opción más
aproximada a una posible realidad. Para facilitar aún más las cosas a nuestros clientes
premium, optamos por no generar beneficios mediante la venta de espacio añadido.
Esto es, por cada gigabyte extra que requiera el cliente, el precio será de 2 € al mes,
que es lo que el mismo volumen de gastos que le supone a nuestra empresa.
Basándonos en la estimación del escenario realista, aplicamos un porcentaje del
25% para generar beneficios, lo que nos daría un precio final de 27,5 € para las
cuentas premium. Esta cuantía puede parecer algo elevada para un uso particular,
pero resulta un gasto casi irrisorio para una empresa que quiera obtener estos
servicios, y son ellas quienes constituirían nuestro principal nicho de mercado. En un
Gabriel Fernández Moral Estudio y desarrollo de un prototipo de plataforma online para ayuda a la realización de presentaciones de forma remota
futuro, podríamos estudiar la posibilidad de ofrecer una versión de coste menor para
particulares, pero de momento, la mejor opción parece apostar por lo simple.
A los costes del servicio de Heroku, habría que añadir los costes mensuales
salariales del equipo de desarrollo y mantenimiento. También debemos tener en
cuenta otros elementos necesarios, todos estos quedan reflejados en la tabla 2.7.
Concepto Cuantía/mes
Coste mensual de salarios 12.055,86 €
Coste mensual de espacio de coworking
en Jaén para 4 personas 280 €
Suscripción empresarial a GitHub 7 €
Suscripción avanzada a Heroku 25 €
Alquiler mensual de 4 ordenadores
portátiles 180 €
TOTAL 12.547,86 €/mes
Tabla 2.7 – Costes empresariales de desarrollo y mantenimiento
Ahora, una vez definidos todos los costes y beneficios globales, podemos
calcular el mínimo número de usuarios que nuestro sistema necesitaría para empezar
a producir beneficios. Esto lo hacemos mediante la siguiente ecuación.
Ingresos - costes = 0
Y desarrollando tenemos que:
X · 0,01 · 27,5 – ( X · ( 0,01 · 2 + 0,99 · 0,2 ) + 12.547,86 ) = 0
Donde X es el número de usuarios totales de nuestro sistema. Despejando esta
variable tenemos que:
X = 220. 138 usuarios
Gabriel Fernández Moral Estudio y desarrollo de un prototipo de plataforma online para ayuda a la realización de presentaciones de forma remota
Es decir, con un ratio de un usuario premium por cada cien usuarios totales,
necesitaríamos un mínimo de 220.138 usuarios totales para cubrir todos los gastos y
empezar a generar beneficios.
Como podemos ver en la gráfica, la diferencia entre nuestros beneficios y
nuestros costes crecerá en mayor medida conforme aumente nuestro número de
usuarios. De ahí, que nuestro principal objetivo debería ser llegar al mayor número
posible de personas. Esto da sentido al hecho de ser un sistema basado en la nube,
el cual convertiría a todo el mundo con acceso a internet en nuestro mercado. También
aquí encuentra su razón de ser el modelo freemium, ya que nos permite, por un lado,
darnos a conocer y que cualquier persona pueda utilizar la aplicación en un momento
dado y, por otro lado, monetizar nuestro servicio mediante el acceso a funcionalidades
más avanzadas a cambio de una cuota mensual.
Ilustración 2.8 – Beneficios en relación al número de usuarios
2.7. Modelo de dominio
A partir de las historias de usuario de que se compone el proyecto, elaboramos
el siguiente modelo de dominio. Al habernos centrado en una solución sencilla pero
que esconde mucho potencial, nuestro modelo de dominio es muy sencillo, pues tan
sólo consta de varios conceptos y algunas relaciones entre ellos.
-500.000,00 €
0,00 €
500.000,00 €
1.000.000,00 €
1.500.000,00 €
2.000.000,00 €
2.500.000,00 €
3.000.000,00 €
Ingre
sos -
coste
s
Usuarios
Ingresos - costes
Gabriel Fernández Moral Estudio y desarrollo de un prototipo de plataforma online para ayuda a la realización de presentaciones de forma remota
Ilustración 2.9 – Modelo de dominio
2.8. Análisis de la interfaz
Para el análisis previo al diseño de la interfaz de usuario, nos basaremos en el
siguiente estudio de algunos de los perfiles de personas que utilizarán nuestro
sistema.
Persona 1
Nombre: Eddie
Trabajo: Estudiante
Conocimientos técnicos: tiene un nivel medio de ofimática con ordenadores,
está acostumbrado a trabajar con aplicaciones webs así como con
aplicaciones móviles.
Fin: Eddie utiliza la aplicación para realizar una presentación sobre uno de
sus trabajos en clase. Necesita que el proceso sea rápido para poder
empezar la presentación cuanto antes y que el paso de páginas se produzca
en tiempo real.
Persona 2
Nombre: Laura
Trabajo: Profesora de universidad
Gabriel Fernández Moral Estudio y desarrollo de un prototipo de plataforma online para ayuda a la realización de presentaciones de forma remota
Conocimientos técnicos: Laura está acostumbrada a redactar documentos
mediante su portátil, así como a utilizar programas destinados con su área
de investigación. A veces consulta redes sociales o páginas para informarse.
Fin: Laura necesita utilizar nuestro sistema para su uso diario en sus clases.
Le gustaría poder guardar varios de sus ficheros sobre presentaciones y ver
un listado de ellos de forma rápida y concisa para poder iniciar una
presentación sobre uno de ellos. En ocasiones, realiza ponencias online y le
vendría bien tener una herramienta que le permita dar la posibilidad a sus
oyentes de no estar necesariamente en presencia física.
Persona 3
Nombre: Arturo
Trabajo: Responsible de ventas de seguros
Conocimientos técnicos: Arturo está acostumbrado a utilizar su ordenador en
su día a día para realizar presupuestos y manejar contabilidades. Tiene un
iPhone mediante el cual gestiona su correo corporativo ya que su trabajo le
obliga conlleva tanto trabajo de oficina como desplazamientos sobre el
terreno.
Fin: A menudo Arturo tiene que realizar pequeñas presentaciones en
reuniones con compañeros de trabajo para definir algún plan de actuación.
En otras ocasiones, Arturo explica a sus posibles clientes o empresas
colaboradoras, las bondades de las ofertas que su compañía ofrece. En
ambos casos, Arturo necesita poder realizar presentaciones de forma ágil y
poder manejar el sistema desde su móvil para no tener que depender de
moverse con un ordenador portátil.
Persona 4
Nombre: Andrea
Trabajo: Fisioterapeuta, autónoma
Conocimientos técnicos: Andrea no ha tenido mucho contacto con las
tecnologías de la información. En ocasiones utiliza alguna aplicación de
mensajería desde su ya antiguo móvil. Es capaz de navegar en internet por
páginas simples para buscar alguna información en un momento puntual.
Fin: Andrea se ha apuntado a un curso para ahondar en sus conocimientos
sobre la técnica de fisioterapia manipulativa. Sin embargo, el curso se realiza
Gabriel Fernández Moral Estudio y desarrollo de un prototipo de plataforma online para ayuda a la realización de presentaciones de forma remota
en Madrid y Andrea vive en Vigo. Para facilitar el seguimiento a los alumnos
inscritos no residentes en Madrid, la institución que imparte el curso ha tenido
a bien utilizar nuestro sistema. Andrea necesita poder seguir la presentación
del curso desde cualquier dispositivo con conexión a internet ya que, al
trabajar como autónoma, no sabe muy bien en qué lugar se encontrará a la
hora de realización del curso.
Tabla 2.8 – Personas
De este estudio, extraemos algunos de los requisitos que serán necesarios en el
posterior diseño de la interfaz de usuario de nuestra aplicación:
Debemos contar con una pantalla inicial que muestre de forma clara los ficheros
del usuario
Debe existir algún menú auxiliar en la pantalla inicial para realizar otras
operaciones complementarias.
La interfaz debería ser utilizable en dispositivos con una gran variedad en
cuanto a tamaños de pantalla, ya que podría ser utilizada desde un ordenador
de escritorio, portátil, tablet, móvil o cualquier otro dispositivos con conexión a
internet y un navegador moderno.
Debe existir un modo presentación en el que se pueda visualizar de forma
cómoda el archivo de la presentación.
Los espectadores de presentaciones deberían acceder directamente a la
presentación para facilitar su seguimiento a personas de diversas capacidades
tecnológicas.
3. Diseño
En esta sección, una vez ya realizado un análisis completo, procederemos a
detallar de manera especificada la solución al problema que pretendemos abordar.
Para ello, nos basaremos principalmente en distintos diagramas que tratarán de
mostrar una idea lo suficientemente detallada de cómo queremos construir el sistema.
Estos diagramas serán los de entidad-relación, de componentes y de secuencia.
Gabriel Fernández Moral Estudio y desarrollo de un prototipo de plataforma online para ayuda a la realización de presentaciones de forma remota
Posteriormente, realizaremos un diseño de la interfaz de usuario en base a los
requisitos obtenidos en el análisis realizado en el punto anterior.
3.1. Diagrama Entidad-Relación
Una vez tenemos una idea del modelo de dominio de nuestro sistema, podemos
definir un esquema con el que comenzaremos nuestro modelo de entidad relación. En
este caso, puesto que pretendemos aplicar llamadas asíncronas para realizar las
presentaciones, nuestra base de datos no necesitará almacenar información sobre los
espectadores o los eventos de cambio de página. Por tanto, el diagrama inicial que
representa nuestras entidades y relaciones es el siguiente.
Ilustración 3.2 – Diagrama Entidad Relación
3.1.1. Proceso de normalización
A continuación, podemos comenzar a aplicar a este diagrama el proceso de
normalización. Este proceso consiste en la aplicación de 3 fases con unas reglas
definidas que garantizarán que nuestro esquema de base de datos es óptimo. Esto
es, que no presenta redundancia de datos o campos innecesarios.
La realización de este proceso nos servirá para ocupar un menor volumen de
espacio en disco conforme nuestra base de datos crezca, así como para facilitar el
mantenimiento en caso de que sea necesario realizar borrado de datos o
reestructuraciones del esquema.
Gabriel Fernández Moral Estudio y desarrollo de un prototipo de plataforma online para ayuda a la realización de presentaciones de forma remota
3.1.2. Primera forma normal (FN1)
Para aplicar la primera fase de normalización, necesitaremos aplicar las
siguientes reglas:
Eliminación de los grupos de repetición en cada una de las tablas.
Creación de una tabla independiente para cada conjunto de datos.
Definición de una clave primaria para cada tabla.
Para aplicar la primera forma normal, damos valores a algunas tuplas en cada
una de las tres tablas que tenemos definidas
Usuario
Id Username Email Pass Validated
1 pepe pepe@gmail.com Abwgys5 True
2 antonio Antonio88@hotmail.com adrTuIi0 False
3 luz luz@company.com 1a2b3c4d True
4 max Max-jay@yahoo.es maxJayMax12! True
Tabla 3.1 – Tuplas de usuarios
File
Id Name
1 tfg.pdf
2 Presentación.ppt
3 calendario.jpg
Tabla 3.2 – Tuplas de ficheros
Presentation
Id timestamp
1 01/02/16 14:55
2 03/07/12 13:22
Tabla 3.3 – Tuplas de presentaciones
Gabriel Fernández Moral Estudio y desarrollo de un prototipo de plataforma online para ayuda a la realización de presentaciones de forma remota
Como vemos, ninguna de ellas presenta grupos de repetición, pues tienen, para
cada tupla, un único valor en cada columna.
Además, definimos en cada una de dichas tablas su “Id” como clave primaria. Si bien
es cierto, que en la tabla de Usuario podríamos haber definido la columna
“Username” como clave primaria, hemos optado por elegir el campo Id para que, en
caso de que nuestro usuario desee cambiar su nombre de usuario en el futuro, no
sea necesario cambiar todas las referencias de ficheros a esa tupla.
Por tanto, podemos garantizar que nuestro diagrama de Entidad-Relación ya está en
primera forma normal (FN1) y quedaría de la siguiente forma:
Ilustración 3.2 – Diagrama Entidad Relación FN1
3.1.3. Segunda forma normal (FN2)
El proceso de conversión a segunda forma normal consiste en la supresión de
dependencias parciales sobre claves compuestas. Consta de la aplicación de las
siguientes reglas:
Tablas independientes para valores que se apliquen a múltiples tuplas.
Relacionar estas tablas mediante una clave externa
Puesto que ninguna de nuestras tablas contienen claves compuestas, podemos
asegurar que nuestro diagrama ya cumple con la segunda forma normal (FN2).
Gabriel Fernández Moral Estudio y desarrollo de un prototipo de plataforma online para ayuda a la realización de presentaciones de forma remota
3.1.4. Tercera forma normal (FN3)
La tercera forma normal es la que asegura que no existen campos que dependan
de otros campos que no sean la clave primaria.
En nuestra tabla Usuario, vemos que cada uno de sus campos, no tiene sentido
sin la presencia de un Id que haga referencia a un usuario concreto.
En el caso de la tabla File, no tiene cabida un nombre de fichero sin un id de
fichero. Lo mismo para la tabla Presentation.
Podemos asegurar por tanto, que nuestro diagrama de entidad-relación se
encuentra en tercera forma normal.
3.2. Diagrama de componentes
Nuestra idea inicial consiste en utilizar Node.js8 para la implementación del
servicio REST y angularJS para el desarrollo de la aplicación web que consuma dicho
servicio.
Puesto que ambas herramientas están muy enfocadas al uso de componentes,
este diagrama toma especial interés. En él, podremos definir las partes esenciales en
que se distribuirá nuestro sistema y cómo interactuarán entre ellas.
Nuestro sistema constará de dos partes bien diferenciadas. Por un lado, el
servicio REST que ofrecerá una interfaz que pueda ser utilizada por cualquier
aplicación que quiera desarrollarse para tal fin. Por otro lado, nuestra aplicación web
que consumirá el servicio REST ofrecido y que nos permitirá hacer uso de toda su
funcionalidad.
El siguiente diagrama muestra los componentes del sistema de back-end. Cada
componente define una interfaz que será utilizada por otros componentes. Como
podemos ver, a la derecha quedan definidas las interfaces de los componentes que
8 Node.js: Entorno de servidor basado en el lenguaje de programación javascript.
Gabriel Fernández Moral Estudio y desarrollo de un prototipo de plataforma online para ayuda a la realización de presentaciones de forma remota
compondrán el API REST para que nuestra aplicación web pueda comunicarse con
dicho sistema.
Ilustración 3.3 – Diagrama de componentes de back-end
Por otro lado, tendremos los componentes de la aplicación web. Podemos ver
su estructura en la ilustración 3.4.
Gabriel Fernández Moral Estudio y desarrollo de un prototipo de plataforma online para ayuda a la realización de presentaciones de forma remota
Ilustración 3.4 – Diagrama de componentes de aplicación front-end
3.3. Diseño de la interfaz de usuario
Basándonos en el análisis realizado en el punto 2.8, decidimos realizar una
interfaz de usuario sencilla y fácil de entender que pueda adaptarse a pantallas de
diferentes tamaños para ser utilizada en dispositivos de distinto tipo.
Necesitaremos una pantalla de login, una pantalla que nos muestre al usuario el
listado de sus ficheros en el sistema y permita interactuar con ellos y, por último, una
pantalla que permita la visualización de ficheros pdf tanto en modo presentador como
en modo espectador.
Gabriel Fernández Moral Estudio y desarrollo de un prototipo de plataforma online para ayuda a la realización de presentaciones de forma remota
Ilustración 3.5 – Pantalla de login
Ilustración 3.6 – Pantalla de lista de ficheros
Gabriel Fernández Moral Estudio y desarrollo de un prototipo de plataforma online para ayuda a la realización de presentaciones de forma remota
Ilustración 3.7 – Pantalla de visualización de ficheros
4. Implementación
Este apartado se enfoca en el desarrollo del sistema una vez realizado su
análisis y diseño. A través de los siguientes apartados trataremos de explicar los
aspectos más relevantes de la implementación que se ha seguido durante el
desarrollo de este proyecto. Además, se justificarán algunas de las decisiones que se
han tomado desde un punto de vista técnico.
Para mayor claridad, este apartado se divide en dos secciones bien diferencias.
En primer lugar, una sección más generalista sobre la arquitectura del sistema y sus
ventajas. Durante la misma, trataremos de dar una visión global del proyecto haciendo
hincapié en los temas más importantes que se han tenido en cuenta durante el
desarrollo relativos a la estructura del producto.
En segundo lugar, otra sección mucho más detallista se centrará en cada una de
las herramientas con que se ha construido el proyecto.Trataremos de explicar las
particularidades de cada una de ellas así como su elección y encaje dentro de este
trabajo.
Gabriel Fernández Moral Estudio y desarrollo de un prototipo de plataforma online para ayuda a la realización de presentaciones de forma remota
4.1. Arquitectura
Este proyecto software consiste en una aplicación en la nube, que permita
realizar presentaciones sobre documentos a cualquier persona con una conexión a
internet independientemente del tipo de dispositivo desde el que acceda.
Además, necesitaremos que la comunicación se produzca en tiempo real, pues
cualquier retraso en la transmisión de los mensajes, frustaría la experiencia de
usuario.
Teniendo estas particularidades en cuenta, nuestros principales objetivos
durante la implementación del sistema serán:
Conseguir un sistema versátil, que pueda ser fácilmente adaptado
a cualquier plataforma.
Asegurar que nuestro sistema pueda adaptarse fácilmente a retos
futuros como mayor volumen de tráfico o nuevas plataformas.
Inmediatez en la realización de presentaciones.
Mediante los siguientes puntos, ponemos de manifiesto las decisiones tomadas
para la consecución de dichos objetivos.
4.1.1. Escalabilidad9
Como ya hemos comentado, uno de los principales retos de nuestro sistema
consistirá en su capacidad para adaptarse a los cambios. Un problema común en
desarrollos de productos software ocurre cuando un sistema pensado para ser
utilizado con un volumen relativamente estable de usuarios, pasa a ser utilizado con
volúmenes de tráfico mucho mayores. Esto puede llegar a suponer retrasos en las
9 Escalabilidad: En telecomunicaciones y en ingeniería informática, la escalabilidad es la propiedad deseable de un sistema, una red o un proceso, que indica su habilidad para reaccionar y adaptarse sin perder calidad, o bien manejar el crecimiento continuo de trabajo de manera fluida, o bien para estar preparado para hacerse más grande sin perder calidad en los servicios ofrecidos. En general, también se podría definir como la capacidad del sistema informático de cambiar su tamaño o configuración para adaptarse a las circunstancias cambiantes.[11]
Gabriel Fernández Moral Estudio y desarrollo de un prototipo de plataforma online para ayuda a la realización de presentaciones de forma remota
comunicaciones, denegaciones de servicio, inestabilidad o incluso inoperatividad del
sistema.
Otra característica que puede hacer no escalable un proyecto es su dependencia
de una plataforma concreta o de un lenguaje de programación que caiga en desuso y
deje de ser soportado.
El mundo de la tecnología cambia constantemente, apareciendo nuevas
plataformas de forma continua que cambian la forma en que las personas interactúan
entre sí y con la información. Nuestro sistema debe ser capaz de adaptarse a todas
esas nuevas plataformas que puedan aparecer en el futuro, con los menores costes
de tiempo y desarrollo posibles, para poder competir en un mercado con tantas
alternativas.
Ejemplos comunes que hacen que una arquitectura no sea escalable hay
muchos. Desde aplicaciones para una plataforma (por ejemplo de escritorio o web)
que, posteriormente, necesitan utilizarse en móviles, hasta sistemas cuya base de
datos está ligada a una aplicación en sí, haciéndola inaccesible desde otras
aplicaciones.
Para evitar estos problemas, en este proyecto se aplica una estructura orientada
a servicios web10 [12]. Contamos con distintas piezas independientes que se unen
entre sí.
10 Servicios web: conjunto de aplicaciones o de tecnologías con capacidad para interoperar en la web. Estas aplicaciones o tecnologías intercambian datos entre sí con el objetivo de ofrecer unos servicios. Los proveedores ofrecen sus servicios como procedimientos remotos y los usuarios solicitan un servicio llamando a estos procedimientos a través de la web.
Gabriel Fernández Moral Estudio y desarrollo de un prototipo de plataforma online para ayuda a la realización de presentaciones de forma remota
Ilustración 4.1 – Arquitectura
En primer lugar, un Sistema de Gestión de Bases de Datos independiente del
resto del sistema. Esto nos garantiza que en un momento dado, podamos migrar dicho
sistema a un servidor con mayores prestaciones, realizar duplicación del mismo o
simplemente instalarlo en una plataforma de terceros como AWS11 o Microsoft
Azure12.
Por otro lado, tendremos un sistema de back-end13, que se comunicará con el
Sistema de Gestión de Bases de Datos y que, a su vez, ofrecerá toda la funcionalidad
básica del sistema a través de un API basada en en un servicio web. De esta forma,
desligamos la funcionalidad que ofrece el sistema de una aplicación orientada a una
plataforma concreta. Así, nos aseguramos de que cualquier aplicación cliente que
necesitemos construir en un futuro, podrá comunicarse con dicha API para consumir
los servicios que ofrece. Ahondaremos más sobre este tema en el punto 4.1.2
especialmente destinado a ello.
11 AWS: Amazon Web Services. Plataforma de la empresa Amazon que ofrece servicios de computación en la nube bajo demanda. 12 Microsoft Azure: Plataforma de la empresa Microsoft que ofrece servicios de computación en la nube bajo demanda. 13 Back-end: hace referencia al trabajo puramente de servidor en un producto software. Esta capa ofrece una serie de servicios mediante una interfaz que serán utilizados por las aplicaciones clientes o front-end.
Gabriel Fernández Moral Estudio y desarrollo de un prototipo de plataforma online para ayuda a la realización de presentaciones de forma remota
Por último, tenemos una aplicación web (parte front-end14) que hará uso de los
servicios que ofrece el back-end. Esta aplicación gestiona la interacción del usuario
con el sistema. Ha sido creada pensada para ser lo más versátil posible pero, gracias
a la arquitectura implementada, podríamos desarrollar cualquier otra aplicación para
cualquier plataforma que se comunique de igual manera con la capa de back-end.
La elección de una aplicación web como plataforma para la aplicación cliente se
debe principalmente a su capacidad para ser utilizada desde multitud de dispositivos.
Una aplicación web puede ejecutarse en cualquier dispositivo con un navegador y
conexión a internet. Desde ordenadores de escritorio a tabletas o teléfonos móviles
pueden hacer uso de sus ventajas.
Esta capacidad multiplataforma, también conlleva consigo que, para dotar a la
aplicación de una experiencia de usuario satisfactoria, su interfaz visual debe
adaptarse a multitud de diferentes formatos de pantallas. Para ello, utilizaremos un
framework15 de elementos visuales construido específicamente para este fin. Si bien
en el mercado existen numerosas opciones, nos decantamos por Bootstrap16 debido
a su comunidad y amplia documentación. Hablaremos más sobre Bootstrap en el
apartado 4.2 que hace referencia a tecnologías concretas.
Por otro lado, la elección de la web como plataforma de nuestra aplicación
cliente, también nos permite adaptar dicha aplicación para ser convertida con ciertas
herramientas a aplicaciones nativas de otras plataformas. En este sentido,
utilizaremos Gonative17 para poder portar dicha aplicación web a plataformas móviles
como Android o iOS sin tener que realizar un desarrollo específico para cada
plataforma.
14 Front-end: en contraposición al término back-end, front-end hace referencia al desarrollo de un sistema de software en la parte de la aplicación cliente, que gestiona la interacción del usuario con el sistema y hace uso de la funcionalidad que ofrece la capa de back-end. 15 Framework: en el desarrollo de software, un framework o infraestructura digital, es una estructura conceptual y tecnológica de soporte definido, normalmente con artefactos o módulos concretos de software, que puede servir de base para la organización y desarrollo de software. Típicamente, puede incluir soporte de programas, bibliotecas, y un lenguaje interpretado, entre otras herramientas, para así ayudar a desarrollar y unir los diferentes componentes de un proyecto. 16 Bootstrap: framework visual que ofrece herramientas para el desarrollo de aplicaciones cuya interfaz visual se adapta a diferentes tamaños de pantalla. 17 Gonative: herramienta que permite portar aplicaciones web a aplicaciones nativas para plataformas móviles.
Gabriel Fernández Moral Estudio y desarrollo de un prototipo de plataforma online para ayuda a la realización de presentaciones de forma remota
Ilustración 4.2 – Conversión de aplicación web a aplicaciones móviles nativas
4.1.2. Servicio web (API)
La interfaz de nuestro servicio web o API18, puede construirse desde diferentes
enfoques. Entre los servicios web existentes en internet destacan principalmente dos
estilos distintos. Por un lado, los servicios de tipo SOAP19, más antiguos y basados en
el intercambio de información mediante datos en formato XML20. Por otro lado, los
servicios de tipo REST, que actualmente son la tendencia natural, y cuyo intercambio
de información puede realizarse mediante una gran variedad de formatos, aunque,
habitualmente se realice mediante formato JSON21.
En nuestro caso, servicio web estará implementado mediante el uso de un
servidor Node.js. Esta decisión viene marcada por el objetivo de inmediatez de que
necesitamos dotar a nuestro sistema. Node.js, ha demostrado en numerosos estudios,
resultar mucho más rápido y eficiente en la gestión de peticiones que otras tecnologías
de servidor como Java [13].
18 Bootstrap: framework visual que ofrece herramientas para el desarrollo de aplicaciones cuya interfaz visual se adapta a diferentes tamaños de pantalla. 19 SOAP: Simple Object Access Protocol (Protocolo de Acceso a Objeto Simple) es un protocolo que define como dos objetos en procesos diferentes pueden comunicarse entre sí a través del intercambio de información mediante ficheros XML. 20 XML: Extensible Markup Language (Lenguaje de Marcas Extensible) es un lenguaje de marcas desarrollado para el intercambio de información en sistemas software. 21 JSON: Javascript Object Notation (Objeto de Anotación de Javascript) es un formato de texto ligero para el intercambio de datos a través de sistemas software basado en la notación literal de objetos del lenguaje de programación javascript.
Gabriel Fernández Moral Estudio y desarrollo de un prototipo de plataforma online para ayuda a la realización de presentaciones de forma remota
Node.js consigue esta eficiencia mediante el uso de operaciones asíncronas y
no bloqueantes a través de todo su diseño y no sólo en la gestión de operaciones de
entrada y salida. Esto consigue que, cuando se realizan operaciones que, a su vez
dependen de otras operaciones más lentas como una conexión a base de datos, el
sistema no permanece inactivo esperando una respuesta, sino que continúa su flujo
natural de ejecución y reacciona en consecuencia cuando cada petición ha sido
respondida.
Ilustración 4.3 – Gestión de peticiones en Node.js
Esta particularidad de Node.js será clave tanto en la realización de
presentaciones, donde el usuario necesita que los desplazamientos tengan el menor
retardo posible, como en la gestión de peticiones cuando crezca el volumen de tráfico
que nuestro servicio web tiene que gestionar.
Node.js está implementado en el lenguaje de programación javascript, utilizando
el motor V8. La elección de esta plataforma para nuestro back-end conlleva consigo
la elección natural del formato JSON para la transferencia de datos con la capa de
front-end.
Gabriel Fernández Moral Estudio y desarrollo de un prototipo de plataforma online para ayuda a la realización de presentaciones de forma remota
A su vez, el marcado carácter web de nuestra aplicación, en conjunción con el
uso de JSON, hace de la elección del protocolo HTTP22 y del estándar REST para la
definición del API del back-end, una elección sencilla.
4.1.3. Front-end
Para el desarrollo de aplicaciones web del lado del cliente, existen numerosos
frameworks tanto de javascript, como de HTML23 y CSS24 que ofrecen multitud de
funcionalidades específicas.
Dentro del amplio abanico de frameworks para javascript, nos hemos decantado
por Angular.js. Entre sus bondades, destacan su sistema de “data binding”25, que
facilita enormemente la manipulación de la información, sus herramientas de
comunicación con servicios externos, que posibilitarán la comunicación con nuestra
capa de back-end, o la multitud de componentes externos adicionales que existen
para esta herramienta.
En cuanto a los elementos visuales, necesitamos una herramienta que nos
proporcione facilidad para la creación de una interfaz de usuario que se pueda adaptar
a pantallas de formatos muy diversos. En este sentido, existen muchas opciones como
Foundation26, Pure27, Ink 28o HTML KickStart29.
22 HTTP: Hypertext Transfer Protocol (Protocolo de Transferencia de Hipertexto) es el protocolo de comunicación que permite las transferencias de información en la web. 23 HTML: HyperText Makup Language (Lenguaje de Marcado de Hipertexto) es un lenguaje de etiquetas que se utiliza en la elaboración de la estructura del contenido en las páginas web. 24 CSS: Cascading Style Sheet (Hoja de estilos en cascada) es un lenguaje usado para definir los estilos visuales de un documento estructurado escrito en HTML, XML y XHTML. 25 Data binding: hace referencia sistema de mapeo de datos entre dos capas de software distintas de manera automática. 26 Foundation: framework visual especialmente orientado al desarrollo de pantallas adaptables a diferentes formatos. 27 Pure: biblioteca muy pequeña de elementos visuales que tan sólo utiliza CSS para la creación de layouts gráficos. 28 Ink: framework que se basa en la utilización de otras bibliotecas como Sass, Compass y Normalize.css para extender las funcionalidades del lenguaje CSS estándar. 29 HTML KickStart: framework de elementos visuales que incluye herramientas para el uso de tipografías, iconos, layouts y otros elementos web.
Gabriel Fernández Moral Estudio y desarrollo de un prototipo de plataforma online para ayuda a la realización de presentaciones de forma remota
Sin embargo, nos decantamos por Bootstrap30, debido a los conocimientos
previos que el desarrollador de este proyecto ya tiene sobre esta herramienta, así
como a su comunidad, puesto que ésta es la principal alternativa en su sector.
4.1.4. Aplicación web convertible a aplicación móvil
Uno de los beneficios de las aplicaciones web, son su carácter multiplataforma,
lo que las hace aptas para su uso en multitud de dispositivos distintos.
Además, hoy en día el mercado del software brinda varias alternativas que nos
permiten portar aplicaciones web a aplicaciones nativas de otras plataformas como
pueden ser Android o iOS en dispositivos móviles, y Mac OS X, Windows o Ubuntu en
sistemas tradicionales de escritorio.
Si bien estas aplicaciones portadas nunca serán tan eficientes como
aplicaciones nativas desarrolladas sobre la propia plataforma, en casos como el actual
donde la necesidad de procesamiento no resulta elevada, ésta puede ser una buena
opción.
De esta manera, conseguimos que mediante un sólo desarrollo, podamos tener
una aplicación para un buen rango de plataformas distintas. En proyectos que
empiezan desde el principio y para empresas con pocos recursos, esta opción resulta
muy atractiva, pues los costes que supondrían el desarrollo de una aplicación
específica para cada plataforma, podrían resultar inasumibles.
Un buen enfoque consiste en empezar el proyecto con una aplicación web
adaptable a distintos dispositivos que nos permita llegar al mayor número de usuarios
posible. En caso de éxito, una vez nuestra empresa adquiera más recursos, se podría
valorar el desarrollo de aplicaciones específicas para cada plataforma.
30 Bootstrap: biblioteca de elementos visuales para el desarrollo de sitios web enfocados primero a su uso en dispositivos móviles. Fue desarrollado por la empresa Twitter que, más tarde, lo liberó como proyecto de código abierto para que pueda ser utilizado por los desarrolladores de todo el mundo.
Gabriel Fernández Moral Estudio y desarrollo de un prototipo de plataforma online para ayuda a la realización de presentaciones de forma remota
Entre las alternativas para este fin destacan PhoneGap31 o Titanium32. No
obstante, en el proyecto actual hemos hecho uso de una nueva herramienta
denominada GoNative.io33 debido a su facilidad de uso.
Con GoNative.io se pueden crear paquetes instalables en dispositivos Android e
iOS con tan sólo insertar la dirección url del sitio donde se encuentre instalada nuestra
aplicación web.
Ilustración 4.4 – Captura de la aplicación exportada con GoNative.io funcionando como aplicación nativa en Android
31 PhoneGap: sistema para crear aplicaciones híbridas usando las tecnologías HTML5, CSS3 y Javascript, ejecutadas dentro de un componente WebKit del dispositivo móvil. 32 Titanium: sistema para crear aplicaciones nativas a partir de aplicaciones web que utilicen los estándares de HTML5, CSS3 y Javascript. 33 GoNative.io: herramienta que permite la conversión de aplicaciones web en paquetes instalables en dispositivos Android e iOS. Esta herramientas es una herramienta comercial de código cerrado. Si bien no podríamos utilizarla de forma comercial para explotar un sistema sin pagar su licencia, sí que podemos hacer uso de ella con el objetivo de creación de un prototipo. https://gonative.io/
Gabriel Fernández Moral Estudio y desarrollo de un prototipo de plataforma online para ayuda a la realización de presentaciones de forma remota
4.2. Detalles sore implementación
En este apartado nos centramos en detalles más específicos de la
implementación del sistema, así como en diferentes tecnologías y bibliotecas que se
han utilizado y el problema que han ayudado a resolver cada una de ellas.
4.2.1 Programación asíncrona en javascript
Si bien javascript como tal no implica el uso de programación asíncrona, la
implementación del motor V8 que utiliza Node.js sobre este lenguaje sí que lo hace.
En la práctica esto quiere decir que las operaciones de nuestro código no serán
bloqueantes, pues la ejecución del código continuará sin necesidad de tener que
ejecutar las operaciones de manera secuencial tal cual fueron escritas.
Este enfoque ha demostrado resultar mucho más eficiente puesto que las
operaciones costosas como acceso a base de datos o lectura de ficheros no ralentizan
al resto del programa.
En la utilización de llamadas asíncronas en javascript existen dos
aproximaciones diferentes, son los llamados callbacks34 y promises35.
En frameworks que se ejecutan asíncronamente por defecto como son Node.js
y Angular.js, el orden de ejecución de un programa no tiene por qué seguir el orden
secuencial en que están escritas las líneas de código en el código fuente. No sabemos
a ciencia cierta, si una sección de código se va a ejecutar antes o después que otra y,
por tanto, no sabemos por ejemplo si el resultado de una función ha sido ya resuelto
o no.
Sin embargo, siempre existen secciones que necesitamos que no sean resueltas
o procesadas hasta que otra lo haya sido previamente, puesto que existe una relación
34 Callback: en programación, una devolución de llamada o retrollamada (callback) es una función “A” que se utiliza como argumento de otra función “B”. Cuando se llama a “B”, ésta ejecuta a “A” tras su finalización. 35 Promise: es un objeto que se ejecuta en programación asíncrona. Puede encontrarse en tres estados diferentes: pendiente, cumplida o rechazada. Puede recibir manejadores de eventos que se ejecuten cuando la promesa sea resuelta ante un eventual éxito o fracaso.
Gabriel Fernández Moral Estudio y desarrollo de un prototipo de plataforma online para ayuda a la realización de presentaciones de forma remota
de dependencia entre ellas. Es aquí donde son útiles estas dos aproximaciones, que
se utilizan para indicar que una función no debe ejecutarse hasta que otra lo haya
hecho previamente.
La aproximación mediante callbacks consiste en pasar como parámetro la
función dependiente a aquella de la cual depende. Al terminar su ejecución, esta
segunda función realizará una llamada a la función dependiente que le fue pasada
como argumento, pasándose a su vez como argumento el resultado de su propia
ejecución.
Podemos ver un ejemplo de esto en la ilustración 4.5. En este caso, la función
‘getUsersByUserName’ recibe a su vez dos funciones callbacks como parámetros,
‘onGetUserByUserNameFailed’ y ‘checkAuthenticationAndValidation’. En tiempo de
ejecución y una vez la primera llamada haya sido resuelta, ésta llamará a una de estas
dos funciones que se le han pasado como parámetros según cuál sea el resultado de
su propia ejecución.
Ilustración 4.5 – Callbacks (fichero: slidecloud/modules/controllers/auth_controller.js)
La aproximación mediante callbacks suele conducir a un problema conocido
como callback hell si no se presta especial atención a la estructuración ordenada del
código.
Podemos ver un ejemplo de este fenómeno en la ilustración 4.6.
Gabriel Fernández Moral Estudio y desarrollo de un prototipo de plataforma online para ayuda a la realización de presentaciones de forma remota
Ilustración 4.6 – Callback hell
Este fenómeno se produce cuando tendemos a definir las funciones callback que
pasamos como argumentos en línea, de manera que al final nuestro código acaba
teniendo esta apariencia tan escalonada y difícilmente legible. Para evitarlo, es
importante definir cada función de forma apropiada, con su nombre correspondiente
como podemos ver en la ilustración 4.7.
Ilustración 4.7 – Evitar el ‘callback hell’ mediante la correcta definición de funciones (fichero: slidecloud/modules/controllers/file_controller.js)
Gabriel Fernández Moral Estudio y desarrollo de un prototipo de plataforma online para ayuda a la realización de presentaciones de forma remota
En cuanto a los promises, estos utilizan los métodos “then” y “catch” para indicar
que una función debe ejecutarse al finalizar otra y qué función debe ejecutarse si se
produce un error, respectivamente. Podemos ver un ejemplo en la ilustración 4.8.
Ilustración 4.8 – Promises (fuente: slidecloud/modules/persistence/filesHandler.js)
En Node.js se puede programar utilizando tanto callbacks como promises, si bien
la plataforma está pensada desde sus inicios para la utilización de callbacks. En su
gran mayoría, las bibliotecas externas se encuentran implementadas siguiendo el
primer enfoque, mientras que tan sólo un margen residual hacen uso de los promises.
Para el desarrollo de un código limpio y legible resulta inevitable elegir uno de los dos
enfoques y realizar una adaptación de uno a otro cuando utilicemos una biblioteca que
utilice el enfoque contrario como podemos ver en la ilustración 4.8 donde el método
findAll utiliza promises mientras que nuestro sistema está pensado en callbacks.
Angular.js por su parte, hace uso de los promises, sin embargo esto no supone
ningún problema, puesto que la única comunicación entre front-end y back-end se
lleva a cabo mediante el intercambio de información en objetos JSON.
Gabriel Fernández Moral Estudio y desarrollo de un prototipo de plataforma online para ayuda a la realización de presentaciones de forma remota
4.2.2 Componentes en Angular.js 36y Node.js
Tanto Node.js como Angular.js utilizan una arquitectura basada en
componentes37.
Ambos se sirven de las funcionalidades que ofrecen las palabras reservadas
exports y require para definir la interfaz de un módulo e importar otros módulos
respectivamente.
En la ilustración 4.9 podemos ver cómo el componente filesHandler importa a su
vez al módulo usersHandler y cómo define los métodos que ofrece en su interfaz para
que puedan ser utilizados por otros componentes.
Ilustración 4.9 – Componentes (fichero: slidecloud/modules/persistence/usersHandler.js)
La arquitectura orientada a componentes [14] se basa en la descomposición del
diseño en componentes funcionales o lógicos que expongan interfaces de
comunicación definidas. Define un nivel de abstracción mayor que el paradigma de
orientación a objetos y no trata asuntos relativos a los objetos como el envío de
mensajes o la representación de sus estados.
36 A lo largo, de este documento nos referimos siempre a la primera versión de Angular.js, puesto que la segunda versión recientemente liberada al mercado, supone un framework completamente distinto y diseñado desde cero. 37 Componente: un componente o módulo es un conjunto de funcionalidad de software que se encapsula en una unidad única de código y puede ser utilizada por otros componentes o realizar llamadas a otros componentes a su vez.
Gabriel Fernández Moral Estudio y desarrollo de un prototipo de plataforma online para ayuda a la realización de presentaciones de forma remota
Los componentes pueden reutilizarse en diferentes partes de un proyecto o en
diferentes proyectos de software, así como ser extendidos para crear otro componente
con funcionalidad añadida.
4.2.3 Sequelize.js38
Para la comunicación entre el Sistema de Gestión de Bases de Datos y la capa
de back-end de nuestro sistema, resulta muy útil el uso de una herramienta de ORM39
o Mapeador Objeto-Relacional.
Una herramienta de ORM nos permite convertir los objetos con los que trabaja
nuestra lógica de negocio en entradas de una base de datos relacional y viceversa.
De esta forma, realizamos una abstracción sobre el lenguaje del Sistema de Gestión
de Bases de Datos y nos centramos en la lógica de negocio, ahorrándonos la
complejidad que supone la conversión de elementos de un modelo a otro.
En nuestro caso hemos optado por la biblioteca Sequelize.js ya que, al estar
desarrollada en javascript, encaja perfectamente dentro del conjunto de herramientas
que utilizamos en nuestro proyecto.
Sequelize.js soporta multitud de dialectos de bases de datos como PostgreSQL,
MySQL, SQLite y MSSQL. Su desarrollo mediante promises permite un gran soporte
de transacciones sólidas.
Esta herramienta también nos permite definir modelos y sus relaciones de
manera sencilla como podemos ver en la ilustración 4.10.
38 Sequelize.js: http://docs.sequelizejs.com/ 39 ORM: Object-Relational Mapping (mapeo objeto-relación) consite en una herramienta de comunicación entre la capa de lógica de negocio y la capa de persistencia de información de un sistema de software, que permite convertir objetos en instancias de una base de datos relacional.
Gabriel Fernández Moral Estudio y desarrollo de un prototipo de plataforma online para ayuda a la realización de presentaciones de forma remota
Ilustración 4.10 – Modelos y relaciones en Sequelize.js (fichero: slidecloud/modules/models/models.js)
4.2.4 Websockets y Socket.io
Una de las principales limitaciones de http y la estructura básica de internet
consiste que tan sólo está orientado para comunicaciones del tipo petición-respuesta.
Este modelo no permite, por ejemplo, que un servidor pueda comunicarse con una
aplicación cliente a voluntad si no es porque ésta ha realizado previamente una
petición.
Los websockets40 surgen para solucionar este problema. Son una tecnología
muy novedosa que utilizan el protocolo TCP41 para permitir comunicaciones
bidireccionales. En nuestro proyecto, ésta es una pieza clave pues al realizar
presentaciones, necesitamos que el presentador pueda enviar un evento de
desplazamiento a la capa de back-end y ésta a su vez debe enviar dicho evento a
todas las aplicaciones cliente que estén visualizando dicha presentación.
40 Websocket: tecnología que proporciona un canal de comunicación bidireccional sobre un único socket TCP. 41 TCP: Transmission Control Protocol (Protocolo de Transmisión de Control) es uno de los protocolos fundamentales en Internet.
Gabriel Fernández Moral Estudio y desarrollo de un prototipo de plataforma online para ayuda a la realización de presentaciones de forma remota
Socket.io 42es un framework desarrollado en javascript que nos permite utilizar
esta tecnología en nuestros desarrollos.
En la ilustración 4.11 podemos ver un ejemplo de su utilización en este proyecto
para comenzar a escuchar eventos sobre una presentación.
Ilustración 4.11 – Utilización de Socket.io (fichero: slidecloud/modules/controllers/io_controller.js)
4.2.5 File upload
Angular File Upload43 es un pequeño módulo que facilita la tarea de realizar
subidas de ficheros desde una aplicación web con Angular.js. En nuestro caso la
hemos utilizado para la gestión de los ficheros que el usuario puede subir a su cuenta.
Soporta subidas de un único fichero o de varios de forma simultánea y trabaja con
cualquier extensión de fichero.
4.2.6 Git y Github
Durante el desarrollo de un proyecto de cierta envergadura, resulta
imprescindible la utilización de un sistema de control de versiones.
En el mercado contamos con varias alternativas como Team Foundation Server44
de Microsoft, Mercurial45 o Subversion46. Nos decantamos por Git47 por su popularidad
y facilidad de uso, por ser de código abierto y por la enorme comunidad con que cuenta
a sus espaldas.
42 Socket.io: http://socket.io/ es un framework que permite comunicación bidireccional en tiempo real basada en eventos mediante la utilización de web sockets. 43 Angular File Upload: https://github.com/nervgh/angular-file-upload 44 Team Foundation Server: https://www.visualstudio.com/en-us/products/tfs-overview-vs.aspx 45 Mercurial: https://www.mercurial-scm.org/ 46 Subversion: https://subversion.apache.org/ 47 Git es un sistema de control de versiones libre y de código abierto. https://git-scm.com/
Gabriel Fernández Moral Estudio y desarrollo de un prototipo de plataforma online para ayuda a la realización de presentaciones de forma remota
Git nos ofrece la posibilidad de poder trabajar con distintas ramas y repositorios,
así como deshacer cualquier cambio para volver a un cierto punto en el desarrollo.
GitHub48 por su parte, es un portal web que nos ofrece la posibilidad de gestionar
nuestros propios repositorios utilizando el sistema de control de versiones Git.
Podemos interactuar con él a través del propio Git en línea de comandos o mediante
las distintas aplicaciones con interfaz de usuario que hacen uso del sistema.
En nuestro proyecto se ha trabajado en dos repositorios distintos, uno para la
capa de back-end, y otro para la aplicación web que consume el API de la primera
capa. En cada uno de estos repositorios se cuenta con una rama master donde se
almacena el código principal del proyecto, una rama development donde se incorporan
las últimas novedades que se van a incorporar a la rama master una vez se alcance
algún hito del proyecto, así como una rama para cada tarea específica de
programación que se irán uniendo a la rama de development. Por último, también
contamos con una rama de producción production que diferirá de la rama master en
cuestiones específicas al despliegue del sistema.
4.2.7 Heroku
A la hora de realizar un proyecto de desarrollo, resulta siempre interesante poder
contar con un entorno donde realizar una instalación del proyecto y poder realizar
pruebas de desarrollo o con usuarios para tener algún feedback sobre el
funcionamiento del mismo.
En este caso hemos utilizado Heroku49. Esta plataforma nos ofrece un plan
gratuito con especificaciones reducidas que resulta muy útil a la hora de poner en
marcha un proyecto con poco presupuesto. Podemos ampliar las funcionalidades que
nos brinda la plataforma conforme lo hagan las necesidades de nuestro sistema.
48 GitHub: portal web que permite alojar proyectos software mediante su gestión con Git. https://github.com/ 49 Heroku: plataforma web que nos permite realizar despliegues de proyectos software. https://www.heroku.com/
Gabriel Fernández Moral Estudio y desarrollo de un prototipo de plataforma online para ayuda a la realización de presentaciones de forma remota
Además, Heroku ofrece la posibilidad de realizar despliegues automáticos desde
ramas y repositorios concretos de GitHub, lo que facilita mucho la integración con el
entorno de desarrollo.
4.2.8 Nodemailer
El proceso de creación de una cuenta en nuestro proyecto se realizar de igual
manera a como funcionan numerosos servicios hoy en día en internet. En primer lugar,
el usuario selecciona sus credenciales y asigna una cuenta de correo electrónico. El
sistema procederá entonces a enviar un correo electrónico a dicha cuenta a modo de
verificación. Dicho correo incluye un enlace a una url única que utilizará el sistema
como prueba de validación sobre dicha cuenta de correo electrónico.
Para el envío de correos electrónicos desde nuestro sistema, hemos utilizado la
biblioteca Nodemailer50. Ésta funciona sobre Node.js, lo cual encaja a la perfección
con nuestro proyecto, y nos permite enviar correos personalizados tanto con texto
plano como con plantillas que incluyan código HTML.
4.2.9 Autentificación, JSON web tokens y jwt.io
En el ámbito de un proyecto de software, hablamos de autentificación para
referirnos al procedimiento por el cual un usuario garantiza ser quien dice ser a la hora
de realizar una acción sobre el sistema. De esta forma nos aseguramos, por ejemplo,
de que tan sólo un usuario puede eliminar los ficheros de su propia cuenta.
Existen diversas maneras de implementar el proceso de autentificación en una
plataforma. En esta ocasión hemos optado por JSON web tokens51.
El procedimiento funciona mediante el cifrado de cierta información utilizando un
“secreto” o clave tan sólo conocida por quien realiza el cifrado y el algoritmo de cifrado
HMAC52. Una vez el usuario introduce sus credenciales de acceso al sistema y se
50 Nodemailer: biblioteca sobre Node.js que permite el envío de correos electrónicos. https://nodemailer.com 51 JSON web tokens: estándar abierto (RFC 7519) que define una forma compacta y autocontenida para transmisiones de información de forma segura entre dos partes en forma de objeto JSON. 52 HMAC: algoritmo de cifrado que combina una función hash criptográfica con el uso de una llave criptográfica secreta.
Gabriel Fernández Moral Estudio y desarrollo de un prototipo de plataforma online para ayuda a la realización de presentaciones de forma remota
comprueba la validez de las mismas, el sistema responde con un “token” que debe
ser enviado cada vez que se realice una operación. De esta forma, el sistema conoce
que el usuario que envía el token es quien dice ser.
Ilustración 4.12 – JSON web tokens (fuente: https://jwt.io/introduction/)
El protocolo JSON web tokens está definido en su totalidad por la IETF53 y cuenta
entre sus ventajas con el hecho de ser compacto, lo que permite que los “tokens”
puedan ser enviados a través de la red como parámetros de una petición de tipo POST
o dentro de la propia cabecera.
Además, son autocontenidos, es decir, el “token” contiene dentro de sí toda la
información sobre el usuario, evitando tener que realizar un mayor número de
consultas a la base de datos.
Para la aplicación de este procedimiento hemos utilizado el framework jwt.io54
que permite utilizar el estándar de JSON web tokens en multitud de plataformas como
.NET, Python, Node.js, Java, Perl o Ruby.
53 IETF: Internet Engineering Task Force define el estándar de JSON web tokens en https://tools.ietf.org/html/rfc7519 54 JWT.io: framework que permite aplicar el estándar de autentificación JSON web tokens.
Gabriel Fernández Moral Estudio y desarrollo de un prototipo de plataforma online para ayuda a la realización de presentaciones de forma remota
4.2.10 Pdf.js
En cuanto a la visualización de documentos en nuestro sistema, hemos
implementado soporte para los ficheros con extensión “pdf”55. Para esta labor hemos
utilizado la biblioteca “pdf.js” desarrollada por Mozilla, que nos permite poder realizar
lecturas desde documentos de tipo “pdf” desde nuestra propia aplicación web en el
navegador web.
4.2.11 Bower
Como hemos visto hasta ahora, el desarrollo de un proyecto conlleva el uso de
diferentes herramientas y bibliotecas. Si bien gestionar esta tarea puede parecer
sencillo en un principio, se vuelva más compleja conforme aumenta el número de
herramientas externas de las que depende nuestro proyecto.
En este sentido, un gestor de paquetes es siempre una buena opción para
mantener de forma ordenada las librerías que vamos añadiendo al proyecto.
Hemos utilizado Bower en la aplicación web, una herramienta especialmente
diseñada para la instalación y desinstalación de paquetes en aplicaciones web.
Trabaja sobre Npm56 y Node.js.
4.2.12 Npm
Npm funciona de forma parecida a como lo hace Bower, aunque en este caso se
centra en la gestión de paquetes sobre un sistema Node.js.
Hemos utilizado npm para la gestión de bibliotecas externas en nuestro sistema
de back-end. De esta forma el proceso de instalación o despliegue en otra máquina
resulta mucho más cómodo y sencillo.
55 PDF: Portable Document Format (formato de documento portable) es un formato de almacenamiento abierto para documentos digitales independiente de plataformas, creado por la empresa Adobe Systems. 56 NPM: es un manejador de paquetes para proyectos software.
Gabriel Fernández Moral Estudio y desarrollo de un prototipo de plataforma online para ayuda a la realización de presentaciones de forma remota
Otra de las ventajas que aporta un sistema de gestión de paquetes como npm
consiste en la actualización de las bibliotecas externas. De esta forma podemos
decidir cuándo queremos que se instale la última verisón de cada una de ellas.
4.2.13 Base de datos
Hoy día existen en el mercado numerosas alternativas en cuanto al uso de bases
de datos. Si bien las bases de datos realacionales clásicas han perdido algo en cuanto
a capacidad de innovación, actualmente no faltan otros modelos que apuestan por
una revolución en este sector como son las bases de datos no relacionales57.
Dentro de este sector, contamos con alternativas como MongoDB58, MariaDB59
o Cassandra60. Todas ellas utilizan un enfoque distinto, unas basadas en documentos,
otras en grafos y otras en pares clave-valor.
Por otro lado, en el sector de las bases de datos más tradicionales también
contamos con un amplio abanico de posibilidades como son PostgreSQL61, MySQL62
o Microsoft SQL Server63.
En este proyecto, si bien las bases de datos no relacionales podrían suponer una
fuerte mejora de rendimiento y escalabilidad, apostaremos por una base de datos
clásica SQLite64, con capacidades limitadas pero suficientes para la elaboración de un
prototipo. De esta manera, podremos centrar nuestros esfuerzos en otros aspectos
57 Bases de datos no relacionales: bases de datos que no utilizan el modelo tradicional de estructura de tablas y relaciones, ni el lenguaje de consulta SQL. Estos modelos han demostrado ser más eficientes que las bases de datos tradicionales. 58 MongoDB: Sistema de Gestión de Bases de Datos no relacional orientado a documentos bajo el concepto de código abierto. 59 MariaDB: Sistema de Gestión de Bases de Datos no relacional derivado de MySQL, lo que le proporciona una gran capacidad de migración desde este sistema. 60 Cassandra: Sistema de Gestión de Bases de Datos no relacional y distribuido creado por la fundación Apache y escrito en Java. 61 PostgreSQL: Sistema de Gestión de Bases de Datos relacional, de código abierto, orientado a objetos y libre. 62 MySQL: Sistema de Gestión de Bases de Datos relacional, de código abierto, desarrollado por Oracle y probablemente el sistema más popular para este fin. 63 Microsoft SQL Server: Sistema de Gestión de Bases de Datos relacional desarrollado por la empresa Microsoft. Sólo está disponible para sistemas operativos Windows. 64 SQLite: Sistema de Gestión de Bases de Datos relacional compuesto de una pequeña biblioteca que lo convierte en un sistema muy ligero en comparación al resto.
Gabriel Fernández Moral Estudio y desarrollo de un prototipo de plataforma online para ayuda a la realización de presentaciones de forma remota
que sí entran en el ámbito de este proyecto y dejar una posible actualización a otro
Sistema de Gestión de Bases de Datos para futuras mejoras.
4.3. Despliegue del proyecto
Con el fin de plasmar hacer disponible a pruebas el proyecto desarrollado, se ha
realizado un despliegue del mismo en los servidores de Heroku. Esta versión está
disponible para su libre uso y testeo.
Si bien aún tiene muchas posibles mejoras, así como funcionalidad que podría
ser añadida en un futuro, esta versión ya incluye la posibilidad de guardar cualquier
tipo de documento en la cuenta de usuario, así como realizar presentaciones sobre
ficheros de tipo pdf.
El despliegue del que hablamos en cuestión, se encuentra accesible a través de
la siguiente dirección:
http://slidecloud.herokuapp.com/
5. Conclusiones
En esta sección realizaremos un análisis de los resultados obtenidos mediante
el desarrollo de este proyecto y los compararemos con los objetivos propuestos
inicialmente. Más adelante, en el punto 5.1, analizaremos cuáles serían las siguientes
mejoras y trabajos futuros a realizar sobre el presente proyecto siguiendo la inercia
natural de desarrollo del mismo.
Como podemos comprobar en el apartado de implementación, se ha realizado
una clara explicación sobre Node.js y Angular.js así como sobre websockets y
Socket.io, se han identificado sus potenciales ventajas para el proyecto y se ha
justificado así su uso dentro del mismo.
Gabriel Fernández Moral Estudio y desarrollo de un prototipo de plataforma online para ayuda a la realización de presentaciones de forma remota
El diseño e implementación tanto del sistema back-end como de la aplicación
cliente específicamente adaptada a móviles, han sido diseñadas e implementadas tal
y como se definió en los objetivos.
Además la misma aplicación web, permite a los posibles espectadores de una
presentación realizar su seguimiento de forma remota y en tiempo real.
En el punto 4.2 sobre detalles de implementación, se ha realizado un extenso
estudio sobre cada una de las tecnologías empleadas tanto en servidor como en la
aplicación cliente, y se ha justificado la adecuación de cada una de ellas en el marco
de este proyecto.
En dicho punto también se ha explicado en qué consiste la biblioteca sequelize.js
y por qué encaja dentro del ámbito del proyecto, así como una mención del panorama
actual de bases de datos y la elección que se ha tomado en este caso.
A su vez, también se han analizado diferentes biblitecas visuales para el
desarrollo de la aplicación web y se ha justificado la elección de Bootstrap.
También hemos hablado de REST y se ha aplicado en la implementación del API
de la capa del sistema de back-end.
En cuanto a la visualización de ficheros, hemos justificado la elección de los
ficheros de tipo pdf como principal enfoque de nuestro sistema y hemos hablado de la
biblioteca pdf.js para su renderizado.
Se ha llevado a cabo el proceso de despligue del sistema en la plataforma
Heroku y se ha presentado dicho sistema en este documento para su libre utilización
y testeo.
Teniendo todo esto en consideración, podemos concluir que se han alcanzado
los objetivos iniciales de este proyecto y su fruto queda plasmado en forma del sistema
de back-end y su api, la aplicación web que utiliza dicho sistema y que está
específicamente adaptada a pantallas pequeñas y su despliegue en Heroku.
Gabriel Fernández Moral Estudio y desarrollo de un prototipo de plataforma online para ayuda a la realización de presentaciones de forma remota
5.1. Mejoras y trabajos futuros
El trabajo desarrollado durante este proyecto constituye una buena base de
producto sobre la que poder seguir trabajando. Cumple con las funciones básica que
debería cumplir un producto mínimo viable centrándose en ofrecer una funcionalidad
muy específica pero de forma correcta en lugar de pretender ser una herramienta para
todo pero que no consiga hacer nada bien.
Desde este punto podemos aportar numerosas mejoras y nuevas
funcionalidades, así como otros aspectos técnicos que no han sido cubiertos en este
proyecto por quedar fuera del ámbito del mismo pero que, sin duda, en un proyecto a
largo plazo deberían tenerse en cuenta.
A continuación enumero de forma breve algunas de las mejoras funcionales que
deberían añadirse a este proyecto de aquí en adelante:
Soporte para presentaciones en mayor tipo de ficheros. Si bien el soporte
a presentaciones en ficheros pdf resulta muy versátil pues casi cualquier
documento puede ser convertido a pdf, el soporte a otros tipos de ficheros
como diapositivas de PowerPoint, hojas de cálculo o imágenes aportaría
un valor añadido al cliente que podría olvidarse de tener que convertir
estos ficheros previamente.
Aplicaciones nativas para móviles. Si bien la aplicación web desarrollada
cumple con su función, gracias a disponer de un API REST que ofrece
nuestros servicios, resultaría bastante rápido poder desarrollar
aplicaciones nativas para cada plataforma con el consiguiente aumento
en la experiencia de usuario.
Aplicación de escritorio para sincronizar los ficheros de una carpeta. De
esta forma, el usuario no tendría que preocuparse de subir los ficheros a
nuestra plataforma, pues directamente los tendría sincronizados.
Soporte para poder realizar marcas, dibujos o resaltar texto sobre un
documento en una presentación. Esto serviría para que el presentador
pudiera hacer hincapié en secciones específicas del documento mientras
realiza su presentación.
Gabriel Fernández Moral Estudio y desarrollo de un prototipo de plataforma online para ayuda a la realización de presentaciones de forma remota
Añadir la posibilidad de realizar notas sobre el documento. Esto podría
implementarse de varias formas, esto es, que el presentador pueda crear
anotaciones o bien, que el público de una presentación pueda hacer
comentarios sobre una sección específica, lo cual resultaría aún más
interesante.
Posibilidad de incluir streaming 65de audio y quizás vídeo. Esto convertiría
definitvamente a nuestro producto en una plataforma online con la que
poder impartir eventos, conferencias, cursos o clases de forma remota sin
tener que recurrir a servicios externos como Skype.
Por otro lado tenemos también una lista de mejoras técnicas que también
pasamos a detallar:
Cobertura de tests unitarios y de integración, así como cobertura de testeo
de escenarios principales para realizar un desarrollo mediante BDD66.
Cualquier desarrollo constante hoy día necesita un conjunto de tests que
sirvan como “esqueleto” sobre el que desarrollar. Sería imposible editar
código constantemente y tener que comprobar de forma continua que
todo el código existente hasta entonces sigue funcionando de forma
correcta. Una estructura de tests con automatización constante nos daría
siempre información sobre si con nuestros últimos cambios algo ha dejado
de funcionar correctamente.
Migración del Sistema de Gestión de Bases de Datos a un servicio de
terceros. Mediante esta acción conseguiríamos que nuestro sistema fuera
totalmente distribuido, garantizando así que, por ejemplo, otro sistema
futuro pudiera acceder a los mismos datos en dicho sistema con total
garantía. También facilitaría la posible expansión de recursos que nuestro
sistema de back-end podría llegar a necesitar conforme el volumen de
tráfico creciese.
65 Streaming (del inglés): dícese de la capacidad de un servicio en línea para emitir contenido bajo demanda, ya se trate de audio, vídeo o cualquier otro contenido multimedia. 66 BDD: Behaviour Driven Development. Dícese de un proceso de elaboración de software mediante el cual se definen en primer lugar, con lenguaje natural, los escenarios que debe satisfacer el producto en cuestión para, posteriormente, automatizar dichos escenarios sobre el producto en forma de tests e implementar la funcionalidad suficiente para que dichos tests sean satisfechos.
Gabriel Fernández Moral Estudio y desarrollo de un prototipo de plataforma online para ayuda a la realización de presentaciones de forma remota
Mejora del sistema de renderizado de presentaciones para abarcar un
mayor rango de proporciones en los documentos. De esta forma
garantizaríamos que no aparecen en ningún caso barras de
desplazamiento horizontales ni verticales en la presentación.
Experimentar con bases de datos no relacionales para poder añadir una
mejora de rendimiento cuando nuestras necesidades en cuanto a
volumen de usuarios lo requieran.
6. Bibliografía
[1] E Tomàs (2014). Qué es REST. Desarrolloweb.com [Online]. Disponible:
http://www.desarrolloweb.com/articulos/que-es-rest-caracteristicas-sistemas.html [2] Proyectos Ágiles (2015). Qué es SCRUM. Proyectosagiles.org [Online]. Disponible:
https://proyectosagiles.org/que-es-scrum/. Acceso: Jul 23, 2016 [3] J. Hewitt (2008). MS PowerPoint: From Humble Beginnings to Business Meeting
Standard. Bright Hub. [Online]. Disponible: http://www.brighthub.com/office/collaboration/articles/13189.aspx. Acceso: May. 29, 2016.
[4] R Wauters (2014). Big numbers for Prezi. 50 million users, 160 million presentations created and $57m in fresh funding. Techeu. [Online]. Disponible: http://tech.eu/news/prezi-funding-50-million-users/. Acceso: May 29, 2016.
[5] Europapress (2015). Adobe anuncia el principio del fin de Flash y se centrará en HTML5. Europapress. [Online]. Disponible: http://www.europapress.es/portaltic/internet/noticia-adobe-anuncia-principio-fin-flash-centrara-html5-20151202175822.html. Acceso: Jul 23, 2016.
[6] M Hendrickson (2008). Dropbox: The Online Storage Solution We’ve Been Waiting For?. TechCrunch. [Online]. Disponible: http://techcrunch.com/2008/03/11/dropbox-the-online-storage-solution-weve-been-waiting-for/. Acceso: May 29, 2016.
[7] J McEleney (2015). How Google solved the versión control problem. OnShape. [Online]. Disponible: https://www.onshape.com/cad-blog/how-google-solved-the-version-control-problem. Acceso: May 29, 2016.
[8] Ministerio de Empleo y Seguridad Social. Boletín Oficial del Estado. [Online]. Disponible: https://www.boe.es/boe/dias/2016/01/21/pdfs/BOE-A-2016-541.pdf. Acceso Jun 4, 2016.
[9] Heroku (2016). Heroku Pricing. Heroku. [Online]. Disponible https://www.heroku.com/pricing. Acceso: Jun 6, 2016.
[10] Zenith (2015). ¿Qué es y cómo funciona el modelo freemium? BlogginZenith. [Online]. Disponible: http://blogginzenith.zenithmedia.es/que-es-y-como-funciona-el-modelo-freemium-diczionario/.Acceso: Jul 23, 2016.
[11] Technopat (2012). Escalabilidad. Wikipedia. [Online]. Disponible: https://es.wikipedia.org/wiki/Escalabilidad#Referencias. Acceso: Jul 23, 2016.
[12] W3C (?). Guía breve de Servicios Web. W3C. [Online]. Disponible: http://www.w3c.es/Divulgacion/GuiasBreves/ServiciosWeb. Acceso: Jul 23, 2016.
[13] I. Roth (2014). What makes Node.js Faster Than Java?. StrongLoop. [Online]. Disponible: https://strongloop.com/strongblog/node-js-is-faster-than-java/. Acceso: Jul 23, 2016.
Gabriel Fernández Moral Estudio y desarrollo de un prototipo de plataforma online para ayuda a la realización de presentaciones de forma remota
[14] J. Peláez (2015). Arquitectura basada en Componentes. Geeks.ms [Online]. Disponible: http://geeks.ms/jkpelaez/2009/04/18/arquitectura-basada-en-componentes/. Acceso: Jul 23, 2016.
Apéndice I. Manual de instalación del sistema
Como ya comentamos en el punto 4.3, una versión desplegada de este sistema
está disponible de forma online para su libre uso:
http://slidecloud.herokuapp.com/
En cualquier lugar, a continuación detallamos los pasos necesarios para
cualquier usuario que así lo requiera pueda realizar la instalación pertinente de este
software de forma local.
Instalación del sistema de back-end y base de datos:
En primer lugar, será necesario tener instalado Node.js. Para ello, podemos
descargar sus instalables para Windows, Linux o Mac OS X desde aquí:
https://nodejs.org/en/download/
En sistemas Windows, se lanzará una ventana y de Windows Firewall, en el que
deberemos desbloquear Node.js como vemos en la siguiente ilustración.
Gabriel Fernández Moral Estudio y desarrollo de un prototipo de plataforma online para ayuda a la realización de presentaciones de forma remota
Ilustración 7.1 – Firewall para Node.js
Junto con esta instalación, también queda instalado npm, el gestor de paquetes
de Node.js. Puesto que todas las dependencias del proyecto están gestionadas con
dicho gestor de paquetes, esto facilitará mucho la instalación. Tan sólo será necesario
copiar el código del proyecto, bien desde el código presentado junto con esta
documentación, o bien desde el siguiente repositorio de GitHub:
https://github.com/gabrifdez89/slidecloud
Una vez copiado el código, deberemos abrir una ventana de comandos en el
directorio raíz del proyecto y ejecutar la siguiente instrucción para realizar toda la
instalación de las dependencias:
sudo npm install
A continuación, una vez instaladas todas las dependencias, será necesario
lanzar el servidor de Node.js que ejecutará la aplicación. Para ello tecleamos:
npm start
Gabriel Fernández Moral Estudio y desarrollo de un prototipo de plataforma online para ayuda a la realización de presentaciones de forma remota
Con esto ya tendremos la parte de back-end corriendo y la base de datos
enlazada a él. Ahora tan sólo nos falta instalar la aplicación web.
Instalación del sistema de front-end:
En este caso, ya tendremos instalados Node.js y npm, por lo que procederemos
directamente a copiar el código desde aportado junto a este proyecto o desde el
siguiente enlace:
https://github.com/gabrifdez89/slidecloud-webclient
Abrimos una ventana de comandos distinta a la anterior en la ruta raíz de este
proyecto y ejecutamos nuevamente:
npm install
Y a continuación:
npm start
Ahora, ya tenemos todo nuestro sistema funcionando debidamente. Para
acceder a la aplicación, bastará con acceder a la siguiente ruta a través de nuestro
navegador web:
http://localhost:3030/
Apéndice II. Manual de usuario
Una vez instalado el software o accedido a la versión de prueba disponible en la
url que aparece a continuación, el usuario deberá crearse una cuenta para poder
utilizar el sistema.
http://slidecloud.herokuapp.com/
Gabriel Fernández Moral Estudio y desarrollo de un prototipo de plataforma online para ayuda a la realización de presentaciones de forma remota
Si ha instalado la versión de forma local y desea saltarse este paso, puede utilizar
el usuario de pruebas que ya existe en la base de datos, cuyas credenciales son:
Usuario: pepe
Contraseña: pepe
Este usuario viene prestablecido en la versión que aún no es de producción para
poder realizar pruebas sin necesidad de crear una nueva cuenta.
En caso de necesitar crear una nueva cuenta desde cero, bastará con
seleccionar la opción “Create account” que aparece en la pantalla de login, tal y como
vemos en la siguiente ilustración.
Ilustración 7.2 – Crear cuenta de usuario
A continuación, veremos como el formulario cambia para permitirnos registrar
una nueva cuenta. Deberemos especificar un nombre de usuario que se encuentre
Gabriel Fernández Moral Estudio y desarrollo de un prototipo de plataforma online para ayuda a la realización de presentaciones de forma remota
disponible, una contraseña y una dirección de correo electrónico válida. Podemos ver
un ejemplo en la ilustración 7.3. A continuación, pulsaremos sobre “Log in”.
Ilustración 7.3 – Creando cuenta de usuario
Si el proceso ha transcurrido de forma correcta, el sistema nos mostrará una
notificación indicando que nuestra cuenta ha sido creada y que debemos proceder a
activarla mediante el enlace enviado a la cuenta de correo proporcionada.
Gabriel Fernández Moral Estudio y desarrollo de un prototipo de plataforma online para ayuda a la realización de presentaciones de forma remota
Ilustración 7.4 – Cuenta creada satisfactoriamente
Procedemos a comprobar nuestro correo electrónico y vemos el correo que ha
sido enviado. Si no lo encontramos, deberíamos registrar la sección de correo no
deseado, puesto que es posible que nuestro proveedor de correo lo haya archivado
en dicha sección. Una vez localidado el correo, presionamos sobre el enlace que éste
incluye o copiamos y pegamos dicho enlace en la barra de direcciones de nuestro
navegador web.
Gabriel Fernández Moral Estudio y desarrollo de un prototipo de plataforma online para ayuda a la realización de presentaciones de forma remota
Ilustración 7.5 – Validación de cuenta
Al acceder al enlace el sistema debería avisarnos de que nuestra cuenta ha sido
validada y podremos comenzar a utilizar el servicio.
Ilustración 7.6 – Cuenta validada
Introducimos nuestras credenciales para entrar al sistema y presionamos sobre
el botón de “Log in”. Si no hemos cometido ningún error, veremos la pantalla principal
de SlideCloud con nuestros ficheros en el sistema. Como aún no hemos subido ningún
fichero, nuestra lista de ficheros estará vacía.
Para comenzar a interactuar con el sistema deberíamos presionar sobre el botón
“Choose files” que aparece en el margen derecho para seleccionar uno o varios
ficheros que subir al sistema.
Gabriel Fernández Moral Estudio y desarrollo de un prototipo de plataforma online para ayuda a la realización de presentaciones de forma remota
Ilustración 7.7 – Pantalla principal sin ficheros
A continuación se abrirá una ventana del sistema de ficheros de nuestro sistema
oeprativo mediante la cual podremos seleccionar los ficheros a subir. Recomendamos
subir al menos un fichero de tipo pdf para poder realizar presentacions sobre él. En
este caso hemos seleccionado dos ficheros, uno de ellos de tipo pdf.
Ilustración 7.8 – Selección de ficheros
Comprobamos que el componente de subida de ficheros se actualiza con los
elementos seleccionados y hacemos click sobre el botón “Upload”
Gabriel Fernández Moral Estudio y desarrollo de un prototipo de plataforma online para ayuda a la realización de presentaciones de forma remota
Ilustración 7.9 – Subida de ficheros
Comprobaremos que la lista de ficheros se actualiza automáticamente.
Ilustración 7.10 – Lista de ficheros actualizada
Una vez que ya hemos añadido ficheros al sistema, podemos interactuar con
ellos. En esta ocasión vamos a presionar el icono del aspa sobre la línea del fichero
con extensión “.docx” para eliminarlo del sistema puesto que no vamos a utilizarlo.
Gabriel Fernández Moral Estudio y desarrollo de un prototipo de plataforma online para ayuda a la realización de presentaciones de forma remota
Ilustración 7.11 – Borrado de ficheros
Nos aparecerá una ventana de confirmación. Presionamos en el botón de
“Delete” para confirmar la acción y comprobamos que éste desaparecerá de la lista
de ficheros.
Ilustración 7.12 – Confirmar borrado
Para descargar el otro fichero que aún tenemos en el sistema, pulsaremos sobre
el icono de flecha hacia abajo dentro de un círculo que aparece en la línea del fichero.
Comprobaremos como nuestro navegador web inicia la descarga del fichero.
Gabriel Fernández Moral Estudio y desarrollo de un prototipo de plataforma online para ayuda a la realización de presentaciones de forma remota
Ilustración 7.13 – Descarga de fichero
Ilustración 7.14 – Fichero descargado
Por último, procedemos a iniciar la presentación del documento pdf. Para ello,
presionamos sobre el icono de la pizarra sobre la línea del fichero.
Gabriel Fernández Moral Estudio y desarrollo de un prototipo de plataforma online para ayuda a la realización de presentaciones de forma remota
Ilustración 7.15 – Iniciar presentación
Se visualizará el documento en cuestión. Para compartir nuestra presentación
con otros espectadores o realizar una prueba individual, pulsaremos sobre el icono de
los eslabones para visualizar el enlace a la presentación.
Ilustración 7.15 – Compartir presentación
Aparecerá una ventana con el enlace a la presentación que podemos copiar y
compartir con los espectadores. Para realizar una prueba, podemos abrir nosotros
mismos dicho enlace en otra ventana del navegador o en un dispositivo diferente.
Gabriel Fernández Moral Estudio y desarrollo de un prototipo de plataforma online para ayuda a la realización de presentaciones de forma remota
Ilustración 7.16 – Enlace a presentación
Al acceder a dicho enlace en otro dispositivo o ventana de navegador,
comprobamos que se visualiza el mismo fichero, esta vez sin los controles de
navegación, pues estamos accediendo al mismo como espectadores de la
presentación.
Ilustración 7.17 – Visualización de presentación a través del enlace
Gabriel Fernández Moral Estudio y desarrollo de un prototipo de plataforma online para ayuda a la realización de presentaciones de forma remota
Podemos comprobar que al desplazarnos por el documento en la primera
ventana del navegador mediante los botones de flechas horizontales, dichos
desplazamientos se renderizan en tiempo real también en la otra ventana o en el otro
dispositivo desde el que hayamos accedido a la presentación.
Ilustración 7.18 – Navegación a través de la presentación
Una vez nuestra presentación finalice, podemos cerrar el documento mediante
el botón con el aspa y cerrar nuestra cuenta en el sitema mediante el botón de “Log
out” de la barra superior.
Gabriel Fernández Moral Estudio y desarrollo de un prototipo de plataforma online para ayuda a la realización de presentaciones de forma remota
Ilustración 7.19 – Cerrar sesión
El sistema volverá automáticamente a la pantalla de login y nuestra sesión habrá
sido cerrada.
Apéndice III. Descripción de contenidos suministrados
En el dispositivo de almacenamiento entregado se incluyen, además de este
documento a modo de memoria explicativa del desarrollo, lo siguientes elementos:
Carpeta source. Aquí podemos encontrar todo el código fuente del
proyecto. En su interior encontraremos dos carpetas, la primera
denominada “slidecloud” que contiene el proyecto de back-end y base de
datos, y la segunda denominada “slidecloud-webclient” que contiene el
proyecto de front-end. Podremos realizar su instalación tal y como se
indica en el apéndice I.
Carpeta repositorios. En esta carpeta encontraremos un par de enlaces a
los repositorios en GitHub que incluyen el código fuente del proyecto.
Gabriel Fernández Moral Estudio y desarrollo de un prototipo de plataforma online para ayuda a la realización de presentaciones de forma remota
Carpeta despliegue. Aquí encontraremos otro enlace al despliegue del
proyecto en Heroku. Esta versión puede utilizarse para realizar pruebas
sobre el proyecto desarrollado sin necesidad de realizar una instalación.
Carpeta ilustraciones. Incluye todas las ilustraciones que han sido
utilizadas en la elaboración de esta memoria.
Carpeta aplicación android. Incluye el apk para la instalación de la
aplicación cliente en android.
Apéndice IV. Acceso a instalación de pruebas
Como ya hemos mencionado previamente durante esta memoria, una versión de
pruebas del proyecto desarrollado se encuentra disponible a través del siguiente
enlace:
http://slidecloud.herokuapp.com/
Si desea probar la funcionalidad de este proyecto sin tener que realizar una
instalación específica del mismo, puede servirse de este despligue con dicho fin.
Le recomendamos encarecidamente que consulte el apéndice II “manual de
usuario” a modo de guía e introducción a la funcionalidad básica que incluye el
proyecto.