cronic: aplicación para el control y observación de
TRANSCRIPT
CRONIC
Aplicacion para el control y observacion de
enfermedades de larga duracion
Ruben Sanchez Garcıa
Memoria del Proyecto Final del Grado Multimedia.
Desarrollo de Aplicaciones Interactivas
Consultor: Kenneth Capseta Nieto
Profesor: Carlos Casado Martınez
Marzo de 2016
Licencia
Esta obra esta sujeta a una licencia de Reconocimiento No Comercial Sin Obra
Derivada 3.0 Espana de Creative Commons
El framework Laravel es una aplicacion bajo licencia MIT
Los proyectos de la fundacion jQuery estan licenciados bajo la licencia espe-
cificada en el repositorio del proyecto, o si no se especifica, bajo la licencia
MIT.
Bootstrap se distribuye bajo la licencia MIT. Copyright 2015 Twitter.
Heroku - Copyright 2000 – 2015 salesforce.com, inc.
FullCalendar.io - La version estandar de FullCalendar se lanza bajo una licen-
cia MIT.
Highcharts - Copyright 2016 Highcharts. Gratuito para uso educativo.
Select2 - Se distribuye bajo una licencia MIT. Copyright (c) 2012-2015 Kevin
Brown, Igor Vaynberg, y los autores que han contribuido.
Select2 Bootstrap - se distribuye bajo una licencia MIT. Copyright (c) 2012-
2015 Florian Kissling
Bootbox - se distribuye bajo una licencia MIT. Copyright (c) 2011-2014 Nick
Payne
Bootstrap toggle - se distribuye bajo una licencia MIT. Copyright (c) 2011-
2014 Min Hur, The New York Times Company
Datetimepicker - se distribuye bajo una licencia MIT. Copyright (c) 2013
http://xdsoft.net
Moment.js - se distribuye bajo una licencia MIT. Copyright (c) 2011-2016 Tim
Wood, Iskren Chernev, y el resto de autores de Moment.js
2
Nota del autor
Pese a que la documentacion esta escrita en castellano, el presente proyecto ha
sido realizado en idioma ingles por dos motivos principales:
La facilidad colaborativa dentro de la comunidad del software libre para un
proyecto en el idioma mas hablado del mundo
La conveniencia de utilizar algunas librerıas de terceros en ese idioma sin
necesidad de configuraciones adicionales
3
Abstracto
El registro diario por parte del paciente del estado de una enfermedad de larga
duracion es un campo poco explorado en el ambito de las aplicaciones interactivas.
Si bien es posible llevar el control utilizando aplicaciones genericas de toma de notas
o incluso un CMS, el disponer de una aplicacion especıfica para ese proposito aporta
suficientes ventajas como para ser considerado. Varios ejemplos de dichas ventajas
son la posibilidad de anadir avisos especıficos para toma de medicinas o visitas a
la consulta del profesional sanitario, una interfaz adaptada a nuestro caso de uso o
la apertura de un canal de comunicacion directo entre el paciente y el profesional
sanitario. Es igualmente destacable que la terapia cognitivo-conductual para un
amplio abanico de trastornos psicologicos incluye como parte imprescindible esta
clase de registros 1.
La aplicacion web CRONIC nace con la intencion de proponer una solucion que
cubra las necesidades de esa problematica. Mediante la creacion de un perfil de usua-
rio, el paciente debera ser capaz de guardar un pequeno texto con la descripcion de
su estado, anadir un historial de medicinas aplicables a su caso y registrar eventos de
interes como futuras visitas a la consulta de su especialista. Asimismo el profesional
sanitario podra crear un perfil de usuario que quedara asociado a sus pacientes y
permitira la recepcion en su pantalla principal de las entradas de registro que estos
hayan decidido enviarle.
Palabras clave— memoria, tfg, cronic, registro enfermedad, comunicacion doc-
tor paciente, terapia cognitivo conductual
1Dubord 2011
4
Abstract
The daily journaling by the patient of a long duration illness is a field which has
only been marginally explored in the field of interactive applications. Even though
it’s possible to log it by using generic note taking applications or even a CMS, the
fact of having a specific application for that purpose gives enough benefits so to
make it worth. A few examples are the possibility of adding tailored reminders for
the taking of medicines or medical appointments, an interface specifically tailored
to our use case or the opening of a communication channel between the patient and
the medical professional. It is also worth to mention that the cognitive-conductual
therapy for a wide range of psychological disorders includes this kind of logging as
an essential part. 2.
The web application CRONIC is born with the aim of propose a solution that
covers the necessities of this problematic. By creating a user profile, the patient
will be able to keep a brief description of his or her daily state, add a history
of medicines that apply to the case and include interesting events such as future
medical appointments. The medical professional will also be able to create a user
profile associated to the patient, which will enable the retrieval of entries that the
patient might have considered worth to send for review.
Keywords— end of degree project paper, illness monitoring, cronic, doctor
patient communication, cognitive conductual therapy
2Dubord 2011
5
Indice general
1. Introduccion 11
1.1. Motivacion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.2. Propuesta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2. Descripcion 13
2.1. Control de la enfermedad . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.2. La aplicacion web como plataforma ideal . . . . . . . . . . . . . . . . 14
2.3. CRONIC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3. Objetivos 16
3.1. Objetivos generales . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.2. Objetivos especıficos . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.3. Objetivos a largo plazo . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4. Marco Teorico 18
4.1. Estudios previos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.2. Herramientas actuales . . . . . . . . . . . . . . . . . . . . . . . . . . 18
5. Contenido 19
5.1. Contenidos de la aplicacion web . . . . . . . . . . . . . . . . . . . . . 19
5.2. Otros contenidos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
6. Metodologıa 24
6.1. Enfoque metodologico . . . . . . . . . . . . . . . . . . . . . . . . . . 24
6.2. Metodologıa de programacion y gestion del proyecto . . . . . . . . . . 25
7. Arquitectura de la aplicacion 28
8. Plataforma de desarrollo 29
9. Planificacion 32
10.Proceso de Trabajo 36
6
Cronic
11.Prototipos 45
12.Perfiles de Usuario 52
12.1. Personajes de usuario . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
13.Usabilidad 54
13.1. Partes del test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
14.Seguridad 57
15.Versiones 58
16.Instrucciones 59
17.Bugs conocidos 61
18.Proyeccion de Futuro 62
19.Presupuesto 63
20.Analisis de mercado 64
20.1. Herramientas actuales . . . . . . . . . . . . . . . . . . . . . . . . . . 64
21.Conclusiones 66
21.1. Conclusiones sobre temas teoricos . . . . . . . . . . . . . . . . . . . . 66
21.2. Conclusiones sobre temas practicos . . . . . . . . . . . . . . . . . . . 66
A. Lista de entregables 68
A.1. Documentos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
B. Codigo fuente 69
C. Capturas de pantalla 70
D. Librerıas utilizadas 79
D.1. Librerıas para PHP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
D.2. Librerıas para Javascript . . . . . . . . . . . . . . . . . . . . . . . . . 79
D.3. Librerıas para CSS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
E. Guıa de estilo 81
Capıtulo 0 Ruben Sanchez Garcıa 7
Indice de figuras
5.1. Platform as a service. . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
6.1. Funcionamiento del metodo Scrum (elaboracion propia). . . . . . . . 26
6.2. Vista de las historias de usuario. . . . . . . . . . . . . . . . . . . . . . 27
6.3. Vista del listado de errores. . . . . . . . . . . . . . . . . . . . . . . . 27
7.1. Arquitectura de la aplicacion. . . . . . . . . . . . . . . . . . . . . . . 28
8.1. El software Vagrant nos permite ejecutar un entorno Ubuntu precon-
figurado para desarrollo desde OSX. . . . . . . . . . . . . . . . . . . . 30
9.1. Listado de tareas en el diagrama . . . . . . . . . . . . . . . . . . . . . 34
9.2. Representacion grafica del proceso . . . . . . . . . . . . . . . . . . . . 35
10.1. Interfaz de NinjaMock . . . . . . . . . . . . . . . . . . . . . . . . . . 38
10.2. Vista de la pizarra unica de Kanban. . . . . . . . . . . . . . . . . . . 41
11.1. Algunos bocetos preliminares anteriores a la realizacion de los proto-
tipos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
11.2. Protitipo de la pantalla de introduccion del diario . . . . . . . . . . . 47
11.3. Protitipo de la pantalla de introduccion de recordatorios. La opcion
de email no ha sido incorporada en la version final . . . . . . . . . . . 48
11.4. Protitipo de la pantalla de vista del diario . . . . . . . . . . . . . . . 49
11.5. Protitipo de la pantalla de editar perfil . . . . . . . . . . . . . . . . . 50
11.6. Protitipo de la pantalla de busqueda, no incluida en esta version. . . 51
16.1. Ejemplo de Impromptu . . . . . . . . . . . . . . . . . . . . . . . . . . 60
16.2. Ejemplo de Chardin . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
C.1. Portada. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
C.2. Formulario de registro . . . . . . . . . . . . . . . . . . . . . . . . . . 71
C.3. Entrada. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
C.4. Panel de control. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
C.5. Introduccion de diario. . . . . . . . . . . . . . . . . . . . . . . . . . . 72
8
Cronic
C.6. Introduccion de eventos. . . . . . . . . . . . . . . . . . . . . . . . . . 73
C.7. Listado de entradas. . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
C.8. Grafico de dolor. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
C.9. Vista de calendario. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
C.10.Edicion de perfil. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
C.11.Perfil actualizado. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
C.12.Distribucion de menu en modo tablet. . . . . . . . . . . . . . . . . . . 76
C.13.Distribucion de menu en modo telefono. . . . . . . . . . . . . . . . . 77
C.14.Menu desplegado en modo telefono. . . . . . . . . . . . . . . . . . . . 78
Capıtulo 0 Ruben Sanchez Garcıa 9
Indice de cuadros
8.1. Herramientas utilizadas. . . . . . . . . . . . . . . . . . . . . . . . . . 29
8.2. Lenguajes y Librerıas. . . . . . . . . . . . . . . . . . . . . . . . . . . 29
19.1. Presupuesto. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
10
Capıtulo 1
Introduccion
1.1. Motivacion
Durante los ultimos anos se ha popularizado el fenomeno de registrar todos los
datos, momentos, ideas y conceptos de nuestra vida. Con la ayuda de las tecnologıas
moviles que nos permiten ejecutar aplicaciones en cualquier lugar, hemos visto la
llegada de herramientas para registrar y catalogar lo que comemos, las horas que
dormimos, cuantas tazas de cafe bebemos al dıa, los pasos dados y nuestras sesiones
en el gimnasio, que tareas tenemos pendientes, a que personas nos han presentado
hoy e incluso cuanto han ejercitado nuestras mascotas.
Sin embargo las aplicaciones de la rama sanitaria suelen ser de un tono amable,
enfocandose a registrar nuestra actividad, indicando que a cuanta mas actividad, mas
salud. Tambien acostumbran a incluir apartados para registrar alergias o medicinas,
pero nunca da la impresion de que estas aplicaciones se dirigen a la persona realmente
enferma, mas bien a alguien que simplemente se preocupa por su salud.
Ası pues, el panorama de las aplicaciones dedicadas al registro diario de inciden-
cias en lo que respecta a enfermedades serias de larga duracion quedaba limitado a
un pequeno punado de ejemplos en las tiendas de aplicaciones para iOS y Android.
Un gran porcentaje son de pago y muchas de las que se ofrecen gratuitamente son de
una calidad deficiente, particularmente en lo que respecta a la interfaz y usabilidad.
Considerando entonces que este tipo de programas ha recibido muy poca atencion
por parte de los desarrolladores, tenemos ante nosotros una oportunidad para crear
una aplicacion para las personas con enfermedades serias que pueda aportar funcio-
nalidades interesantes como una comunicacion doctor paciente u otros anadidos de
interes.
11
Cronic
1.2. Propuesta
A lo largo del presente trabajo se va a desarrollar una aplicacion web responsiva
con la intencion de aportar una herramienta de utilidad al campo de las aplicaciones
sanitarias. Con nuestro desarrollo vamos a posibilitar que el paciente pueda regis-
trar los eventos e incidencias de su enfermedad, que pueda establecer un vınculo
comunicativo con el profesional sanitario que le atiende e incluso registrar su to-
ma de medicamentos o programar las proximas visitas a la consulta mediante un
calendario.
12 Capıtulo 1 Ruben Sanchez Garcıa
Capıtulo 2
Descripcion
2.1. Control de la enfermedad
Cuando una enfermedad se cronifica o simplemente evoluciona durante un perio-
do de tiempo medio o largo, llevar un registro de su estado es de suma importancia.
Por desgracia, la unica circunstancia en la cual el registro puede ser llevado dia-
riamente por un profesional es cuando el paciente se encuentra ingresado en un
centro hospitalario. Para el resto de situaciones, la observacion del estado se realiza
unicamente con la frecuencia con la cual se programen las visitas al facultativo.
En esos casos, la observacion diaria de la evolucion de los sıntomas quedara bajo
responsabilidad del paciente. Salvo en las ocasiones concretas en las cuales a este le
recomienden llevar un registro, habitualmente se limitara a usar la memoria e inten-
tar recordar durante que dıas se sintio mejor o peor, lo cual no es extremadamente
fiable en lo que respecta a proponer un diagnostico y tratamiento. La inclusion en la
rutina diaria de un control y registro mediante una herramienta interactiva no solo
aporta los beneficios habituales de un registro normal y corriente como el que pu-
diera hacerse con papel y bolıgrafo, sino que anade una serie de ventajas inherentes
a la plataforma utilizada.
2.1.1. Beneficios para el paciente
Uno de los beneficios mas interesantes que el paciente percibira llevando registros
es la observacion de patrones. Los sıntomas nuevos o agravados que sin registros
pudieran parecer arbitrarios, con un estricto control diario podran relacionarse a
otros factores como la toma de ciertas medicinas, ingesta de uno u otro alimento,
ejercicio fısico o falta de este por citar algunos ejemplos. De este modo es posible
descubrir factores que contribuyan a mejorar la salud del paciente.
Igualmente existe la posibilidad de que en cierto momento el tratamiento o sim-
plemente el estilo de vida se degrade, con lo cual darse cuenta a traves de los registros
13
Cronic
puede desencadenar una pronta correccion.
Existen diversos estudios que relacionan el registro diario con la mejora intrınseca
del estado de salud (Purcell 2006) Si bien los estudios no son conclusivos y ni siquiera
se refieren exclusivamente a la escritura de datos de salud sino al llevar un diario
generico sobre cualquier tematica, se puede deducir de ello que en nuestro caso
tambien deberıa existir una sensible mejora del estado de animo.
2.1.2. Aplicaciones en diversas terapias
En el apartado anterior se mencionan algunos factores que benefician al paciente
en lo que respecta a controlar enfermedades eminentemente fısicas. Una de las face-
tas mas interesantes del llevar un diario medico es que el solo hecho de llevarlo ya
es una parte indispensable en la terapia cognitivo conductual aplicada a una serie
de trastornos psicologicos. No es el proposito de este estudio el entrar en detalles
exhaustivos sobre estos beneficios, pero como pequeno resumen se puede mencio-
nar que el paciente notara mejora en lo que respecta a gestionar la ansiedad y la
depresion, reducir el estres o incluso priorizar problemas y miedos para entenderlos
mejor.
2.1.3. Beneficios para el profesional sanitario
El principal beneficio para el profesional sanitario es que al aportar el paciente
un registro fidedigno de sus estados, este puede tomar decisiones en lo que respecta
al diagnostico y tratamiento con una mayor fiabilidad que en el supuesto caso de
basarse en recuerdos que pueden no ser exactos.
La inclusion de materiales multimedia como fotografıas, complementa el registro
de texto y facilita la comprension de lo que en este se detalla. Puede ser particu-
larmente de utilidad para enfermedades muy visibles como heridas de gran tamano,
ulceras o algunos tipos de tumores.
Por ultimo es necesario resenar que el formato de registro mediante una aplica-
cion interactiva abre una serie de nuevas posibilidades en lo que respecta al canal
de comunicacion entre el paciente y el profesional sanitario. Esto puede traducirse
en una mejora del servicio que en algunos contextos de la sanidad privada podrıa
utilizarse para cobrar un importe extra.
2.2. La aplicacion web como plataforma ideal
Dentro del abanico de posibilidades a la hora de crear una aplicacion interactiva,
la opcion que mejor se ajusta a las necesidades del proyecto es una aplicacion web.
14 Capıtulo 2 Ruben Sanchez Garcıa
Cronic
Los avances en CSS para realizar aplicaciones que adapten su medida de pantalla
al dispositivo que las utilice sumado a la proliferacion de conexiones a internet en
dispositivos moviles, que en 2016 llego a 3.790 billones de usuarios1, hacen que el
hecho de acceder a una web movil desde cualquier lugar no represente un problema.
Al mismo tiempo existen otras ventajas como la compatibilidad en multiples dispo-
sitivos. De hecho, cualquier aparato que disponga de un navegador web deberıa ser
capaz de visualizar la aplicacion.
Existen algunas desventajas. Por ejemplo, no es posible aprovechar las API del
telefono para funciones como utilizar la camara o enviar notificaciones push. Pa-
ra conseguir esto deberıa utilizarse una aplicacion instalable, lo cual nos aportarıa
ventajas adicionales pero tambien una serie de problemas como por ejemplo el in-
cremento del tiempo necesario para desarrollo.
2.3. CRONIC
CRONIC es el nombre de la aplicacion desarrollada para solucionar la pro-
blematica expuesta. Por el momento se ofrece unicamente en formato aplicacion
web, aunque no se descartan versiones adicionales para moviles en un futuro. Ha si-
do programada en PHP usando el framework Laravel para el backend y en javascript
con el framework jQuery para el frontend.
Su funcionalidad principal permite dar de alta un usuario y asociar datos de una
enfermedad. Tambien es posible anadir el nombre del doctor especialista. El paciente
registrara su estado con la frecuencia deseada. Si ası lo desea, podra marcar algunas
entradas como especialmente interesantes. Como funcionalidad adicional sera posible
anadir avisos para la toma de medicinas y futuras consultas medicas, siendo posible
consultar estas ultimas en un calendario.
Por otra parte, el doctor se habra dado de alta con un perfil de profesional. En su
pantalla principal podra acceder al flujo de registros del paciente, o bien completo
o bien filtrando por las entradas que este haya marcado como interesantes.
1http://www.slideshare.net/wearesocialsg/digital-in-2016
Capıtulo 2 Ruben Sanchez Garcıa 15
Capıtulo 3
Objetivos
3.1. Objetivos generales
Desarrollar una aplicacion web accesible desde dispositivos moviles (diseno
responsivo) para llevar el control de enfermedades de larga duracion
Utilizar la experiencia del desarrollo para aprender nuevas tecnologıas como
por ejemplo el framework Laravel
Implementar la base tecnologica de la aplicacion (el backend) de una manera
que haga factible el abrir la web al publico general una vez finalizado el TFG
con el posible crecimiento que esto conllevarıa
Conseguir un producto final que sea de utilidad para los tipos de usuario a los
que se dirige
3.2. Objetivos especıficos
La aplicacion debera permitir el registro del estado del paciente diario o con
la frecuencia que este desee.
Debera existir un apartado para especificar las medicinas tomadas y visitas al
medico.
Las medicinas se gestionaran mediante recordatorios. En la version web el
recordatorio se limitara a enviar un email a la direccion incluida en el perfil
del paciente
Las futuras visitas a la consulta se gestionaran mediante un calendario
16
Cronic
La aplicacion debera permitir el marcar entradas para el envıo al facultativo
responsable del tratamiento. Estas seran vistas por este al entrar en su sesion
de usuario
3.3. Objetivos a largo plazo
Estos objetivos no forman parte del bloque de trabajo presentado en este TFG,
pero sı del bloque de trabajo futuro que se realizara a partir de la entrega final.
Valorar la conveniencia de migrar a una base de datos NoSQL para facilitar
la comunicacion con aplicaciones moviles
Como alternativa, explorar la posibilidad de crear el propio feed JSON desde
el propio Laravel, o con herramientas que lo faciliten, como Lumen1
Adaptar el codigo a una aplicacion movil realizada con PhoneGap para ası
aprovechar al maximo las API de los dispositivos moviles
Trabajar en la difusion del producto y el crecimiento de usuarios
Estudiar la viabilidad de establecer la funcionalidad de registro como gratuita
pero la comunicacion con el doctor como funcion de pago
Estudiar nuevas funciones sociales, como foros de comunicacion entre pacientes
de la misma enfermedad
1https://lumen.laravel.com/
Capıtulo 3 Ruben Sanchez Garcıa 17
Capıtulo 4
Marco Teorico
4.1. Estudios previos
En lo que respecta a la literatura analizando los beneficios de la escritura a
modo de diario para registrar la evolucion de la enfermedad, encontramos muy pocos
ejemplos. Algunos estudios prueban los beneficios de tal actividad (Shetzer 2007)
en contextos genericos de enfermedad o edad avanzada. Sin embargo hay algunas
enfermedades que han merecido especial atencion en ese ambito. El cancer es una de
ellas, existiendo gran variedad de estudios sobre los beneficios de llevar un registro
diario (Smith y col. 2005).
Si bien es cierto que estos textos se estan refiriendo a un diario en el sentido
mas comun del termino (de ahı el uso del termino ingles journaling), no existe gran
cantidad de literatura sobre el registro de los conceptos medicos puros abstraıdos
del bloque principal de texto. A falta de estudios que prueben su beneficio, solo
podemos sacar conclusiones del material existente e intentar extrapolar los beneficios
conocidos al contexto de nuestro producto.
Un campo donde sı existe abundante documentacion es la aplicacion de este tipo
de registros en las terapias cognitivo-conductuales y el llamado auto-registro. Llama-
do tambien registro de pensamiento, se considera una de las herramientas principales
para el retorno del paciente a la racionalidad (Dubord 2011). Es interesante destacar
como algunos estudios sobre dichas terapias destacan tambien los beneficios en la
enfermedad cronica a un nivel mas generico (Taylor 2006).
4.2. Herramientas actuales
Esta tematica se mencionara mas adelante en el capıtulo 20, Analisis de mercado.
18
Capıtulo 5
Contenido
5.1. Contenidos de la aplicacion web
La aplicacion web se encuentra alojada en http://cronic.herokuapp.com/. Heroku
es un proveedor de PaaS 1, lo que significa que los pasos asociados a la configuracion
de la plataforma de alojamiento no seran necesarios. Si en un alojamiento al uso se
espera que configuremos la base de datos, los permisos de usuarios y la seguridad,
en una PaaS unicamente se espera que subamos el codigo de nuestra aplicacion,
quedando la configuracion a cargo del proveedor del servicio. El siguiente grafico
ilustra las diferencias entre uno y otro modo:
1https://www.salesforce.com/paas/overview/
19
Cronic
Figura 5.1: Platform as a service.
5.1.1. Registro de usuarios
La primera vez que el usuario accede a nuestra aplicacion, es necesario regis-
trarse para obtener unas credenciales. Actualmente solo es posible el registro en la
base de datos propia. Existe una anotacion en el gestor de Scrum2 (Taiga) para
implementar el registro vıa redes sociales3, pero muy probablemente se incluya en
los sprint posteriores a la entrega final de este trabajo. Se expondran mas detalles
sobre Agile/Scrum y Taiga en futuros capıtulos.
Para registrarse unicamente se solicita el nombre, apellidos y una direccion de
email. Adicionalmente se requiere saber si la persona se registra como paciente o
como doctor, ya que de ello dependra la funcionalidad disponible en cada caso. El
2https://www.scrum.org/Resources/What-is-Scrum3https://tree.taiga.io/project/rubenwap-cronic/us/15
20 Capıtulo 5 Ruben Sanchez Garcıa
Cronic
resto de datos se aportaran en la seccion de configuracion.
5.1.2. Panel de control
El panel de control es la vista principal que el usuario recibira al introducir sus
credenciales en la aplicacion. En una primera version, se incluiran las siguientes
partes:
Vista destacada de la ultima entrada guardada. Puede valorarse aumentar el
numero e incluir dos o tres entradas. La vista incluira el tıtulo, el icono para
representar el estado de salud del paciente y un extracto del cuerpo principal
del texto.
Vista preliminar o version reducida del grafico del apartado Progreso, en el
cual se representan los picos del estado de salud del paciente, utilizando para
ello la escala que ha de seleccionarse en cada entrada del diario que se registre.
Lista de proximos recordatorios de calendario, caso de haberse registrado al-
guno en la pagina correspondiente.
5.1.3. Vista de todos los registros
Una vista en formato tabla de todas las entradas con paginacion. Se implemen-
taran una serie de filtros para poder seleccionar un sub grupo de resultados.
5.1.4. Vista de introduccion de registros
El formulario principal para la introduccion de registros. Se compone de las
siguientes partes:
Sensacion: Basado en una escala de medicion del dolor a traves de caras (Bieri
y col. 1990). No existe una unica escala sino varias, cada una con distintos
matices. El desafıo para un producto multimedia consiste en simplificar la
escala (a menudo la cantidad de caras es excesiva) y depurar el estilo grafico
para que sea atractivo al tiempo que comprensible. La meta es que cada cara
tenga matices distintos que la hagan reconocible.
En este formulario se presentan en un carrusel. El usuario debera situar el
carrusel en la posicion correspondiente a su eleccion de cara.
Tıtulo: Un tıtulo generico explicando el tema principal de la entrada.
Cuerpo: Detalle expandido del tema.
Capıtulo 5 Ruben Sanchez Garcıa 21
Cronic
En el futuro esta previsto implementar la funcionalidad de incorporar datos
estructurados. Es decir, sera posible anadir campos dinamicamente para no limitarse
a escribir texto sino datos como presion sanguınea, pulsaciones, nivel de azucar u
otras variables a eleccion del paciente.
5.1.5. Vista de eventos / calendario
Se incorporara un calendario en el cual podran anadirse eventos. El formulario
para anadirlos tiene en cuenta conceptos habituales para los pacientes como por
ejemplo citas en la consulta medica o comienzo de la toma de un medicamento.
5.1.6. Vista de progreso
Cuando el paciente selecciona una cara de la escala de dolor en el formulario
principal, se asigna un valor numerico a esa cara. De ese modo, es posible llevar
un control grafico del progreso de la enfermedad en terminos generales. La primera
version de la aplicacion permitira ver la representacion de la ultima semana. En el
futuro se anadiran opciones adicionales para personalizar completamente el grafico.
5.1.7. Vista de configuracion
En esta vista es posible completar el perfil del paciente de manera totalmente
opcional con datos relativos a su enfermedad. Si ası lo desea tambien sera posible
seleccionar un doctor (de entre los cuales se hayan dado de alta en la aplicacion)
para poder enviar anotaciones a este en un feed.
5.2. Otros contenidos
La siguiente lista de elementos no se incluira en la version presentada como
objeto de este trabajo, pero a modo informativo, las siguientes caracterısticas seran
implementadas en el futuro:
Creacion de foros tematicos sobre enfermedades. El usuario podra activar su
participacion en ellos de manera opcional
Creacion de un chat en tiempo real con los usuarios registrados
Implementacion de RESTful APIs desde nuestra base de datos en PostgreSQL
con la intencion de hacerlos legibles desde una aplicacion movil
Valorar la creacion de una aplicacion movil nativa, inicialmente en un frame-
work multiplataforma como PhoneGap.
22 Capıtulo 5 Ruben Sanchez Garcıa
Cronic
5.2.1. Pagina web
La pagina web del producto actualmente no cumple ninguna otra funcion excepto
la de mostrar una breve presentacion de sus caracterısticas y permitir el registro del
usuario. En el futuro se ampliaran las funcionalidades. Se difundiran las aplicaciones
nativas y se incluira informacion corporativa si se estima necesario constituirse como
empresa para facilitar los tramites relacionados a la gestion de datos personales y
otra informacion privada del usuario.
Como alternativa a la comercializacion del producto se propone liberarlo como
software libre con licencia no comercial.
Capıtulo 5 Ruben Sanchez Garcıa 23
Capıtulo 6
Metodologıa
6.1. Enfoque metodologico
A la hora de afrontar la metodologıa del siguiente trabajo, se han tenido en
cuenta una serie de puntos de interes, organizados en categorıas segun su impor-
tancia. Dependiendo de si esta es alta o baja, se les otorga mas o menos tiempo de
investigacion y desarrollo. A continuacion se exponen los pasos ordenados segun su
importancia:
6.1.1. Muy importante
Documentarse sobre los beneficios del registro en la salud el usuario para poder
planear una aplicacion coherente y de utilidad
Estudiar la documentacion de Laravel para poder realizar la base de la apli-
cacion de manera agil con el menor numero de problemas posibles
Estudiar conceptos avanzados de bases de datos para poder disenar la de la
aplicacion de manera logica
6.1.2. Moderadamente importante
Revisar los principios de diseno y usabilidad que contribuyan a una mejor
experiencia de usuario
Investigar distintos plugins de jQuery que puedan contribuir a facilitar la in-
teraccion con la interfaz
Estudiar la idoneidad de Heroku como plataforma para lanzar la aplicacion
24
Cronic
6.1.3. Poco importante
Trazar un plan de viabilidad de la aplicacion como producto comercial
Una vez estudiados estos puntos, se han integrado o descartado para la planifi-
cacion definitiva. Este plan, expuesto en el Capıtulo 9, muestra la lista maestra de
las tareas llevadas a cabo en el presente trabajo y el orden aplicado a estas.
6.2. Metodologıa de programacion y gestion del
proyecto
Si el apartado anterior se referıa a consideraciones generales y el futuro capıtulo
9 explicara lo relativo a la gestion del proyecto, el capıtulo actual debe detallar
la tecnica que se ha utilizado para llevar a buen termino la programacion de la
aplicacion. Se trata de Scrum, una metodologıa basada en el movimiento Agile muy
popular en la actualidad, que pese a estar pensada para equipos, tambien puede
aplicarse al trabajo de una sola persona, como el caso que nos ocupa.
6.2.1. Algunos principios de Agile relevantes a nuestro caso
(Beck y col. 2001)
Los cambios de requisitos son bienvenidos incluso a mitad de desarrollo
Las iteraciones del software funcionando se van entregando con rapidez
El progreso se mide segun si el software funciona o no
La prioridad es para el producto funcional, no para la documentacion detallada
Por supuesto es necesario dejar fuera los principios que hacen hincapie en la
colaboracion entre el equipo. Se requiere un estudio separado para detallar las ca-
racterısticas y beneficios de esta metodologıa, pero como resumen cabe destacar la
importancia que se le da a conseguir piezas funcionando aunque no sean perfectas a
la primera. En el caso actual no es posible organizar las reuniones Scrum diarias, ya
que con una persona no tienen sentido, pero sı podemos trabajar con un Backlog, o
lista de tareas (o historias) pendientes.
De esta lista vamos seleccionando elementos y ubicandolos en un Sprint regular,
para forzarnos a una cierta productividad. Cuando se trabaja en equipo esta etapa
suele durar entre una y dos semanas. En un hipotetico caso de dos semanas, la sema-
na en la cual comienza un Sprint, primero se repasa y analiza como ha funcionado
Capıtulo 6 Ruben Sanchez Garcıa 25
Cronic
el de la semana anterior. La segunda semana, se pueden filtrar y elegir elementos
del Backlog para comenzar de nuevo la siguiente semana.
En el grafico adjunto puede entenderse esta idea. Se ha utilizado como ejemplo
un proyecto con tres versiones: Integration, para uso por los desarrolladores, Staging,
para uso por los testers y Production, para uso general por todos los publicos. El
exito de un Sprint provoca el traslado del codigo de un entorno a otro.
Figura 6.1: Funcionamiento del metodo Scrum (elaboracion propia).
6.2.2. Gestion de Agile/Scrum mediante el programa Taiga
A continuacion se muestran varias capturas de pantalla para los listados de me-
joras y errores de la aplicacion dentro del gestor Taiga.
Taiga no es un programa tan poderoso y versatil como JIRA1, uno de los mas
conocidos en su campo, pero tiene la ventaja de ser software libre, con lo cual esta
al alcance de cualquiera.
6.2.3. Metodologıa Kanban
Antes de la entrega final se decide cambiar la metodologıa para llevar el control de
las partes pendientes. Si bien Agile funciona, se considera que el trabajo de controlar
los sprints, actualizar las pizarras y demas, tiene sentido dentro del contexto de un
equipo. Al ser este el trabajo de una sola persona, se cambia al metodo Kanban,
mucho mas apropiado y del cual se daran mas detalles en el apartado del proceso
de trabajo en el capıtulo 10.
1https://www.atlassian.com/software/jira
26 Capıtulo 6 Ruben Sanchez Garcıa
Cronic
Figura 6.2: Vista de las historias de usuario.
Figura 6.3: Vista del listado de errores.
Capıtulo 6 Ruben Sanchez Garcıa 27
Capıtulo 7
Arquitectura de la aplicacion
Figura 7.1: Arquitectura de la aplicacion.
En una aplicacion que utilice el paradigma de diseno MVC (Modelo Vista Con-
trolador)1, el usuario accede a la vista en la cual formula sus peticiones (en este
caso, las pantallas de la interfaz basadas en HTML, CSS, JS). La peticion se envıa
a procesar al Controlador (la logica de la aplicacion, en este caso programada en
PHP). De ser necesario, se realizaran peticiones al modelo de datos (almacenado
aquı en una base de datos PostgreSQL). El controlador recibira la respuesta del
modelo de datos, y lo enviara a la vista, que es lo que recibira el usuario.
1https://es.wikipedia.org/wiki/Modelo–vista–controlador
28
Capıtulo 8
Plataforma de desarrollo
Hardware Software Web apps
Mac mini intel i5 16GB RAM Virtual box 5.0 Lucidchart
Vagrant 1.8.1 Moqups
Heroku Gantter
Atom 1.6.0 Taiga
LATEX
TexStudio
Cuadro 8.1: Herramientas utilizadas.
Lenguajes Librerıas
PHP 7.0 Laravel 7.2
JavaScript 1.8 jQuery 2.2.2
CSS 3 Bootstrap 3.3.6
HTML 5 Font Awesome 4.5.0
Cuadro 8.2: Lenguajes y Librerıas.
El desarrollo se ha llevado a cabo en un ordenador Mac mini con una imagen
virtualizada del sistema operativo Ubuntu sin entorno grafico y con un conjunto
preconfigurado de herramientas para desarrollar en PHP con el framework Laravel.
No se ha ejecutado esta imagen virtualizada directamente, sino que se ha conectado a
ella mediante SSH1, lo cual nos ha permitido disfrutar de las ventajas de un entorno
de programacion correctamente configurado pero al mismo tiempo haciendo uso de
nuestras herramientas locales preferidas.
1https://en.wikipedia.org/wiki/Secure Shell
29
Cronic
Figura 8.1: El software Vagrant nos permite ejecutar un entorno Ubuntu preconfi-
gurado para desarrollo desde OSX.
La aplicacion se ha desplegado en la plataforma Heroku2, la cual ha servido no
solo como hosting sino tambien como control de versiones mediante GIT, siendo este
control gestionado por la herramienta de linea de comandos con el mismo nombre.
Durante el desarrollo se ha hecho uso de varias librerıas de gran popularidad como
jQuery o Bootstrap. Se ampliara informacion sobre estas en el apendice numero 5.
Son particularmente importantes las herramientas Gantter y Taiga. La primera
se ha utilizado para la gestion global del proyecto: Planificacion, hitos, recursos y
riesgos. La segunda se ha utilizado como gestora del metodo Scrum, registrando pro-
blemas, mejoras e historias de usuario para la aplicacion y gestionando los Backlogs
y Sprints. Dado que la lista de usuarios para los test de usabilidad es muy corta,
no se les solicitara que creen una cuenta en Taiga para registrar los problemas,
sino que estos seran comunicados por cualquier otro canal y seran insertados en la
herramienta posteriormente.
Se han utilizado tambien varias herramientas adicionales. Lucidchart para ela-
borar los graficos de workflow y Moqups para los wireframes. El presente documento
2http://heroku.com
30 Capıtulo 8 Ruben Sanchez Garcıa
Capıtulo 9
Planificacion
A continuacion se detalla el listado de tareas necesarias para completar el pro-
yecto. Existe un diagrama de Gantt reflejando esta planificacion en la siguiente
url: https://goo.gl/0JlFm4. El diagrama se ha realizado con la aplicacion Gantter,
disponible en http://gantter.com
Redactar la lista de requisitos para la aplicacion
Decidir las tecnologıas ideales para llevarla a cabo
Investigar conceptos teoricos para apoyar la idea de la aplicacion
Redactar la PAC1 y preparar entregables si los hay (8/3/2016)
Crear wireframes de la aplicacion
Crear graficos de workflow
Disenar la base de datos
Estudiar documentacion de Laravel
Crear pagina de login con funciones de crear usuario con dos perfiles, paciente
y doctor
Crear copia remota de la aplicacion en Heroku e ir sincronizando con regula-
ridad para ahorrarse el paso de desplegar la app completa una vez terminada.
Al crear un usuario, este debe crearse en la base de datos con la estructura
decidida anteriormente en el diseno
Crear formulario para introducir registro
Crear pagina para ver todos los registros introducidos
32
Cronic
Redactar la PAC2 y preparar entregables si los hay (6/4/2016)
Crear pagina de perfil de usuario para dar detalles de la enfermedad, nombre
del doctor y email para los avisos
Crear pagina para anadir evento de calendario
Crear vista de calendario
Crear pagina para anadir recordatorio o considerar fusionarlos en el calendario
Redactar la PAC3 y preparar entregables si los hay (8/5/2016)
Crear pagina para usuario doctor, para ver los registros de sus pacientes aso-
ciados
Revisar el codigo y refinar funciones cuando sea necesario
Crear documento con guıa de estilo visual
Aplicar estilo visual o realizar mejoras de interfaz si es necesario
Grabar video para la entrega final
Redactar la entrega final y preparar entregables si los hay (20/6/2016)
9.0.4. Imagenes del proceso
Capıtulo 9 Ruben Sanchez Garcıa 33
Capıtulo 10
Proceso de Trabajo
Se detalla a continuacion el proceso seguido para completar las distintas partes
expuestas en la planificacion:
Redactar la lista de requisitos: Una vez la idea ha sido aprobada por el profe-
sorado de la universidad, se redactan los requisitos estableciendo un equilibrio
entre lo que es ideal y lo que puede conseguirse de un modo realista en el plazo
de tiempo otorgado.
Decidir las tecnologıas ideales para llevarla a cabo: Durante el estudio del
Grado Multimedia, se ha hecho muy poco hincapie en lenguajes de servidor y
nunca a nivel suficientemente avanzado como para realizar gestiones complejas
(por ejemplo autenticar al usuario). Actualmente existen multitud de frame-
works que nos pueden facilitar la tarea, pero incluso la eleccion del mas simple
de ellos conlleva un tiempo de estudio y comprension, lo cual ha de tenerse en
cuenta para realizar la eleccion.
Inicialmente se considero una combinacion del llamado MEAN Stack, compues-
to por MongoDB para la base de datos en formato NoSQL, Angular.js como
framework MVC para el cliente, Node.js para la parte del backend y Express
como web framework de Node. Esta combinacion resultaba la mas atractiva,
ya que a priori ofrecıa un codigo simplificado (todos los lenguajes eran Ja-
vascript) y mucha facilidad para construir los servicios REST que deberıan
alimentar a una hipotetica aplicacion movil.
Sin embargo, durante el grado en la universidad no hemos trabajado con nin-
guna de esas tecnologıas, ası que el aprendizaje de todas las partes podrıa
llevar demasiado tiempo.
Una vez descartada esa opcion, la solucion mas interesante ha sido Laravel,
un framework de PHP creado por Taylor Otwell en 20111 con la finalidad de
1https://es.wikipedia.org/wiki/Laravel
36
Cronic
disponer de una sintaxis elegante, con separacion Modelo Vista Controlador
y facilidades adicionales como un motor de plantillas incorporado, gestion de
la base de datos simplificada y programacion de rutas de manera muy intui-
tiva. La ventaja es que existıan partes que ya se habıan visto en asignaturas
anteriores (PostgreSQL, jQuery...), aunque la estructura y funcionamiento de
Laravel era totalmente nueva, lo cual tambien requerıa tiempo de estudio.
Basar todo el proyecto en Laravel se presenta como una opcion mucho mas
interesante que utilizar PHP puro anadiendo clases y paquetes de Composer
para anadidos extra. Basando el proyecto completo, se adquiere un conoci-
miento global extrapolable a otros proyectos futuros, al mismo tiempo que se
ahonda en el proceso de aprender completamente un nuevo metodo partiendo
de cero.
La adicion de Vagrant2 al proceso ha sido muy positiva ya que ha permiti-
do disponer de un entorno perfectamente configurado con PHP, Composer,
PostgreSQL y toda una seleccion de herramientas como Node.js o REDIS que
incluso si no se han utilizado en este proyecto representan un gran descubri-
miento con perspectiva de utilizarlas en el futuro.
Investigar conceptos teoricos para apoyar la idea de la aplicacion: La ma-
yor parte de este concepto se trabajo como prologo al comienzo de la primera
PAC. Se han buscado ideas relevantes en varios libros y artıculos cientıficos
para apoyar las ideas basicas de la aplicacion, como por ejemplo el beneficio de
registrar el estado de salud con frecuencia o la idoneidad de utilizar el sistema
de caras para medir el dolor. Una vez estas ideas estan asimiladas, el marco
teorico pasa a un segundo plano y el grueso de la aplicacion se centra en crear
un producto funcional que cumpla dichos requisitos
Redactar la PAC1 y preparar entregables si los hay (8/3/2016): La prime-
ra entrega es de gran importancia, ya que sienta las bases de lo que seran las
entregas posteriores. Por una parte no existe parte tecnica para entregar, pero
se debe presentar la planificacion, lo cual requiere trabajo extra. Asimismo,
hay detalles que han de tenerse en cuenta como la preparacion de las plan-
tillas de LATEX, que pueden llevar mas tiempo del esperado si no se planean
correctamente. Afortunadamente, una correcta preparacion y planificacion de
esta PAC significara mayores facilidades para las entregas futuras
Crear wireframes de la aplicacion: El problema principal ha sido encontrar una
herramienta para realizar wireframes de manera eficiente y que al mismo tiem-
po no estuviera severamente limitada por una licencia. La suite de Adobe
2https://www.vagrantup.com/
Capıtulo 10 Ruben Sanchez Garcıa 37
Cronic
provista por la Universidad no ofrece ninguna herramienta especıfica para wi-
reframes, si bien es cierto que Illustrator o Indesign pueden servir para el
proposito, no tienen la facilidad y flexibilidad de una herramienta especıfica.
Se han valorado herramientas profesionales. Por ejemplo, el estandar de la
industria OmniGraffle, descartado por su precio, motivo que tambien ha dejado
a un lado alternativas como Moqups o Balsamiq. Al final la eleccion ha recaıdo
en NinjaMock 3, un programa con caracterısticas muy similares a Moqups pero
incluyendo la exportacion en .png, que en el resto de alternativas suele estar
incluida solo en la opcion de pago.
Figura 10.1: Interfaz de NinjaMock
Crear graficos de workflow : Este punto se ha visto beneficiado de lo aprendido
en la asignatura Arquitectura de la Informacion, lo cual ha resultado clarifica-
dor y de utilidad para desembocar en el diagrama final. Adicionalmente hay
que resenar que la estructura planteada no presenta gran complejidad, ası que
esta tarea no resulta nada problematica
Disenar la base de datos: Punto inicialmente previsto cuando la idea inicial su-
gerıa disenar una BD relacional y plasmarla en PostgreSQL. El cambio a Lara-
3http://ninjamock.com/
38 Capıtulo 10 Ruben Sanchez Garcıa
Cronic
vel ha traıdo consigo el esquema Eloquent, posibilitando gestionar las bases de
datos de una manera muy distinta a lo pretendido originalmente. Por ello, gran
parte del tiempo destinado a disenar la BD relacional se dedica a estudiar como
funciona Eloquent y de que forma puede simplificar nuestras interacciones.
Estudiar documentacion de Laravel : Uno de los puntos cruciales de todo el
trabajo. Partiendo de un conocimiento inexistente sobre este framework su-
mado a un conocimiento muy pobre de PHP, este trabajo se plantea como
una herramienta para aprender Laravel desde cero utilizando un proyecto de
ejemplo muy atrayente.
Crear pagina de login : Una vez generado el esqueleto de la aplicacion, el primer
paso es crear una estructura en la cual todos los pasos se lleven a cabo dentro
del contexto de usuario registrado. Para ello Laravel incorpora un modelo de
autenticacion que viene practicamente configurado de serie. Logicamente, su
configuracion de prueba no nos sirve, ya que hay que adaptar el usuario a los
requisitos de nuestra aplicacion. Por ejemplo, en el registro ha de especificarse
si la persona registrandose es un paciente o un doctor, con lo cual hay que
modificar tanto las plantillas de registro como los esquemas de la base de
datos.
Por suerte, el proceso no es difıcil, aunque en un principio puede parecer confu-
so por las diferencias entre el adaptar una base de datos normal (por ejemplo,
hacer un ALTER table en SQL) y modificarlo aquı, lo que conlleva rectificar
las migraciones y utilizar la aplicacion artesan para ejecutarlas.
Una vez se resuelve este asunto, nos encontramos ante un esqueleto provisto de
autenticacion, sobre el cual ya podemos empezar a construir nuestra aplicacion.
Crear copia remota de la aplicacion en Heroku : Si la version definitiva de la
aplicacion va a estar desplegada en Heroku, es razonable comenzar a desple-
garla cuanto antes. De ese modo se evitan hipoteticos problemas que pudieran
ocurrir al final del proceso, al intentar subir una aplicacion de gran tamano
en la cual es mas difıcil identificar de donde vienen los errores. Comenzando
a desplegarla desde su inicio, en cada commit que hagamos en GIT podemos
acotar el terreno de manera mucho mas refinada para identificar los posibles
fallos. A esto tambien ayuda la facilidad de desplegar en Heroku, lo cual puede
hacerse desde su propio servicio de GIT, desde un repositorio de GitHub o in-
cluso desde una carpeta de Dropbox. En el caso que nos ocupa se ha utilizado
el propio servicio GIT de Heroku.
Revisar que la estructura de la BD creada se ajusta al diseno: Este paso se
Capıtulo 10 Ruben Sanchez Garcıa 39
Cronic
planeo inicialmente antes de decidir el paso a Laravel, con lo cual una imple-
mentacion de tablas en la base de datos era mucho mas compleja y requerıa
de una revision mas cuidadosa para confirmar que el esquema se ajustaba al
comportamiento que esperabamos.
Al utilizar Laravel y Eloquent, la gestion se ve facilitada sobremanera, con lo
cual la revision deja de cobrar tanto protagonismo, ya que el sistema se encarga
de muchas de las tareas que anteriormente tendrıamos que haber revisado
manualmente.
Crear formulario para introducir un registro: Se crea el formulario para re-
gistrar en la base de datos una entrada del paciente. En una primera etapa
se anaden los datos no estructurales como tıtulo o texto. En el futuro se im-
plementara un sistema para poder insertar datos estructurales, ofreciendo al
usuario flexibilidad para elegir los mismos, ya que no todos tendran las mismas
necesidades (presion arterial, peso, nivel de azucar, etc...)
Crear pagina para ver todos los registros introducidos: El listado de todas
las entradas es un elemento en el cual de haberlo realizado en PHP puro hubie-
ran surgido varias dificultades, como por ejemplo la paginacion (que siempre
es algo mas compleja sin librerıas auxiliares). Laravel facilita esto y otras fun-
ciones necesarias. En una primera etapa se muestran todas las entradas sin
filtros. En una version futura, se implementaran filtros de busqueda.
Redactar la PAC2 y preparar entregables si los hay (6/4/2016): La clave
de la segunda PAC es el ser la primera entrega en la cual hay que presentar una
version del producto. Se adjuntara una version preliminar alojada en Heroku
junto con la direccion del repositorio del codigo. La version presentada incluye:
Posibilidad de registro de usuario
Introduccion de entradas en el diario incluyendo la escala de dolor
Vista general de todas las entradas
Vista ”Panel de controlcon la ultima entrada destacada
El resto de elementos se incorporaran en breve despues de la segunda entrega.
Tambien se adjunta un documento adicional con todas las imagenes de los
Wireframes y bocetos preliminares a tamano completo, los cuales tambien se
presentan resumidos en el capıtulo pertinente de esta memoria
Cambio en la metodologıa: Durante la realizacion de la PAC2 usando la me-
todologıa Scrum, se valoran otras alternativas. Scrum es muy poderoso para
40 Capıtulo 10 Ruben Sanchez Garcıa
Cronic
trabajos en equipo, pero para una idea simple como la que nos ocupa, el tiempo
en mantener las pizarras de los sprint no compensa con respecto al beneficio
que produce en un proyecto de una sola persona.
Debido a que no es posible aprovechar al maximo las ventajas de Scrum para el
trabajo en equipo, ya que no hay equipo, se opta por pasar al metodo Kanban,
que se compone de una unica pizarra con varios apartados en los cuales hay que
mover pequenas tarjetas con las tareas pendientes segun si estan en proceso,
listas para probar o finalizadas por completo.
El planteamiento es mucho mas simple, y tras trabajar con el sistema durante
varias semanas, decide adoptarse para el resto de tareas pendientes hasta la
finalizacion del trabajo.
Figura 10.2: Vista de la pizarra unica de Kanban.
Crear pagina de perfil de usuario: Se crea una pagina donde ademas de datos
triviales como peso y estatura, pueden seleccionarse alergias, detallar la enfer-
medad o enfermedades del usuario y especificar que doctores la estan tratando.
Para esto, se incorpora una rutina a las funciones de la pagina que explora el
listado de usuarios registrados y extrae aquellos que se han registrado con un
perfil de doctor. En el futuro, los doctores podran acceder a un panel de control
en el cual podran leer las entradas compartidas de sus pacientes.
Para conseguir esta funcionalidad, se han utilizado varias librerıas javascript
para la parte visible al usuario, ya que las alergias y los doctores se selec-
Capıtulo 10 Ruben Sanchez Garcıa 41
Cronic
cionan de una lista predeterminada, y los elementos seleccionados pueden ser
multiples. A nivel de backend, se resuelve utilizando sintaxis de Eloquent.
Lamentablemente un fallo de diseno a la hora de trazar las relaciones entre
paciente y doctor en la base de datos, ha dificultado sobremanera la realizacion
de la vista del panel de control en la cual el usuario doctor puede ver las
entradas de diario de sus pacientes. Este fallo sera subsanado en un futuro,
aunque fuera del ambito de la entrega de este proyecto.
Crear pagina para anadir evento de calendario Para esta funcion se pretendıa
utilizar la librerıa Laravel-FullCalendar, que facilita la creacion de eventos
compatibles con FullCalendar(ver siguiente punto), pero no ha sido necesario.
FullCalendar simple sin anadidos es lo suficientemente accesible como para
utilizarlo sin complementos. La instalacion de la librerıa del plugin de jQuery
permite recibir los datos sobre los eventos mediante un feed de JSON, con
lo cual sumado a las capacidades de Laravel para crearlo, obtenemos como
resultado un calendario con eventos realizado de manera simple y efectiva.
Crear vista de calendario Una vez anadido el plugin de jQuery FullCalendar 4,
un calendario al cual pueden anadırsele eventos dinamicamente, encontramos
un problema: Despues de haber anadido las rutas y funciones para editar y
borrar artıculos, el archivo de rutas comienza a ser bastante confuso, a causa
de no seguir los patrones establecidos de Laravel para rutas. Llegado a este
punto, se hace necesaria una reformulacion de todo el sistema de edicion, para
ası poder permitir no solo editar y borrar artıculos, sino tambien editar y
borrar eventos de calendario. Esto se consigue gracias a la unificacion de rutas
en recursos y a una simplificacion en los formularios gracias al uso de paginas
parciales
Crear pagina para anadir recordatorio: Lo que antes iban a ser dos funciones
distintas (calendario y recordatorios) se fusionaran en una para evitar confu-
siones. Al fin y al cabo, el intentar diferenciar que merece una entrada en
el calendario y que merece un recordatorio, puede resultar confuso para el
usuario, ası que este punto se cancela.
Redactar la PAC3 y preparar entregables si los hay (8/5/2016): La impor-
tancia de esta PAC ha radicado en el hecho que la funcionalidad presentada
debıa ser practicamente final. Finalmente se consigue llegar a un grado de fun-
cionalidad interesante en el cual practicamente todo lo planeado se encuentra
presente, salvo las opciones de visualizacion para los doctores. El redactado
4http://www.fullcalendar.io
42 Capıtulo 10 Ruben Sanchez Garcıa
Cronic
de la memoria necesita incluir algunos apartados para reflejar los cambios en
metodologıa desde la PAC anterior.
Crear pagina para usuario doctor: Este punto es quiza de los mas problemati-
cos que existen en la aplicacion, ya que es necesario aplicar tecnicas de Eloquent
avanzadas para gestionar la aparicion de informacion de un usuario en el perfil
de otro usuario. El problema basico radica en que la base de datos se diseno
con un problema que al inicio paso desapercibido. Actualmente se opta por no
solucionar la vista doctor, ya que otras partes son mas prioritarias.
Anadir formularios AJAX: Un punto importante que mejora la usabilidad de
la aplicacion es la posibilidad de introducir entradas tanto de diario como de
calendario vıa peticiones AJAX. Hasta el momento todas las peticiones eran
convencionales, lo cual conlleva que ante cada edicion o anadido fuera necesario
actualizar la pagina. Se incluyen las siguientes mejoras:
Formularios de entrada rapida de contenido desde el panel de control
principal
Borrado rapido de entradas desde la vista listado
Edicion rapida desde la vista listado
Edicion del perfil de usuario y actualizacion de la informacion en vivo.
Se decide mantener los formularios convencionales en otros apartados, y al
mismo tiempo se crea una funcion para garantizar que incluso si la peticion
AJAX falla por razones de lentitud o inaccesibilidad del servidor, el contenido
del usuario se intentara enviar de nuevo automaticamente a traves de una
peticion convencional.
Crear documento con guıa de estilo visual: Esta tarea comenzo siendo un do-
cumento separado con los disenos, aunque en la entrega final se integran en
un apendice de esta memoria.
Aplicar estilo visual o realizar mejoras de interfaz si es necesario: Se esta
utilizando Bootstrap como base para el estilo CSS. Una vez la parte de pro-
gramacion esta finalizada, se crean adaptaciones en un archivo css separado
para crear un estilo visual propio.
Grabar video para la entrega final: Utilizando Audacity para el audio y Afte-
rEffects para el video, se prepara una defensa visual del proyecto.
Capıtulo 10 Ruben Sanchez Garcıa 43
Cronic
Redactar la entrega final y preparar entregables (20/6/2016): Por ultimo
se entrega la compilacion de archivos que comprende la entrega final, esta vez
incluyendo todo el material disponible, el producto finalizado.
44 Capıtulo 10 Ruben Sanchez Garcıa
Capıtulo 11
Prototipos
Se adjuntan las imagenes de los prototipos utilizados para el diseno inicial. Al-
gunas distribuciones han cambiado ligeramente en comparacion con el resultado del
producto final (ver imagenes en el apendice Capturas de Pantalla). En un produc-
to donde hay varias personas involucradas, el arquitecto de la informacion debe
actualizar los wireframes cada vez que hay cambios.
En el contexto de un proyecto de una sola persona, tener una version inicial es
una buena herramienta para entender como estructurar la aplicacion, pero no es
necesario preparar una nueva version con cada cambio, ya que no aporta ninguna
mejora al proceso de trabajo, al ser el programador y el arquitecto la misma persona.
45
Cronic
Figura 11.1: Algunos bocetos preliminares anteriores a la realizacion de los prototi-
pos.
46 Capıtulo 11 Ruben Sanchez Garcıa
Cronic
Figura 11.2: Protitipo de la pantalla de introduccion del diario
Capıtulo 11 Ruben Sanchez Garcıa 47
Cronic
Figura 11.3: Protitipo de la pantalla de introduccion de recordatorios. La opcion de
email no ha sido incorporada en la version final
48 Capıtulo 11 Ruben Sanchez Garcıa
Cronic
Figura 11.4: Protitipo de la pantalla de vista del diario
Capıtulo 11 Ruben Sanchez Garcıa 49
Cronic
Figura 11.6: Protitipo de la pantalla de busqueda, no incluida en esta version.
Capıtulo 11 Ruben Sanchez Garcıa 51
Capıtulo 12
Perfiles de Usuario
En el siguiente apartado se detallaran los ”personajes de usuario”(user persona
en ingles). Puede encontrarse una descripcion sobre la interaccion y los test con
usuarios en el capıtulo siguiente: Usabilidad.
12.1. Personajes de usuario
Se introducen a continuacion dos perfiles distintos que representan un gran por-
centaje del usuario modelo al cual se enfoca la aplicacion.
12.1.1. Personaje 1: Roberto, 26 anos
Roberto trabaja como periodista de nuevas tecnologıas para un medio de comu-
nicacion. Por ello, esta habituado a utilizar todo tipo de aparatos e innovaciones
tecnologicas. Tras el diagnostico de una enfermedad de piel cronica, Roberto en-
cuentra que tiene dificultades para asociar los dıas de mayor o menor irritacion y
dolor con las medicinas tomadas, ya que el doctor varıa la dosis y tipologıa de estas
con cierta frecuencia.
Utilizando Cronic, Roberto toma anotaciones relacionando el nivel de dolor con
las medicinas tomadas. Igualmente, anota una breve descripcion de otros sıntomas
generales. Utiliza la aplicacion desde varios dispositivos: telefono movil, tablet u
ordenador segun el momento del dıa.
12.1.2. Personaje 2: Sonia, 58 anos
Sonia trabaja como camarera de pisos en un hotel. El psicologo le ha diagnostica-
do un trastorno de personalidad. Ya que no esta habituada a las nuevas tecnologıas,
ha sido su hija adolescente quien le ha mostrado el funcionamiento de la aplicacion.
52
Cronic
Sonia utiliza telefono movil, pero unicamente envıa mensajes, con lo cual siempre
utiliza la aplicacion desde el ordenador de casa.
Escribiendo una vez al dıa, Sonia no solo anade los datos indicados por el psicolo-
go, sino que aprovecha el apartado de texto libre para utilizarlo como un diario
generico.
Capıtulo 12 Ruben Sanchez Garcıa 53
Capıtulo 13
Usabilidad
La usabilidad de la aplicacion deberıa depender mucho de la disposicion de ele-
mentos en los prototipos, que al mismo tiempo esta muy influida por la disposicion
por defecto en el framework CSS utilizado, que a su vez recibe influencias de las
convenciones y habitos mas frecuentes en el ambito de diseno de interfaces.
El metodo ideal para comprobar la idoneidad de esta distribucion es el test de
usuarios.
En el capıtulo anterior se han descrito dos perfiles de usuario que corresponden
a los dos usuarios que se someteran al test. No son las mismas personas exactas,
pero su perfil es muy similar.
13.1. Partes del test
El test consta de dos partes. En la primera, tras una breve explicacion sobre para
que sirve la herramienta, se deja que el usuario la utilice de manera libre mientras
es observado. En la segunda parte se les solicita su opinion.
13.1.1. Perfil Roberto
Roberto llega a la prueba con un iPad Mini, ya que su test se realizara sobre
esta plataforma. Las conclusiones extraıdas son las siguientes:
Existen algunos fallos graves con la estructura responsiva del CSS. Durante
el desarrollo no se ha testeado suficiente, pero algunas pantallas muestran
la estructura para escritorio pese a visualizarse desde una tablet de tamano
pequeno.
Hay otros fallos de usabilidad menores, como algunos botones demasiado pe-
quenos para ser pulsados con un dedo en vez de un raton. Un ejemplo son las
checkbox.
54
Cronic
El usuario echa de menos mas apartados para anadir informacion estructurada
en las entradas, como presion sanguınea, etc.
Hay cierta confusion por tener dos pantallas distintas para la introduccion
de entradas y eventos. Se sugiere unificarlo todo y ofrecer una unica vıa de
introduccion
Se sugiere anadir un filtro para modificar las fechas mostradas en el grafico del
dolor
Se sugiere anadir una funcion de busqueda
13.1.2. Perfil Sonia
Sonia realizara la prueba en un ordenador de escritorio. Las conclusiones ex-
traıdas son las siguientes:
Cuando la pagina se muestra en disposicion de escritorio (los tıtulos de los
apartados desaparecen en el menu lateral), resulta confuso recordar donde
esta cada apartado. Se sugiere anadir los nombres de las secciones tambien en
esta disposicion.
Tras descubrir el boton de anadir una entrada rapida desde el panel de control,
se intenta pulsar al boton con el mismo icono en la barra lateral, y sorprende
que lleve a una pagina distinta (introduccion de la entrada a pantalla completa
en vez de con un popup modal)
El popup modal crea confusion porque al contrario que en la mayorıa de pagi-
nas, hacer clic fuera de su superficie no lo desactiva, teniendo que pulsar el
boton de cerrar en la esquina superior derecha.
No parece obvio que el carrusel de imagenes de caras de dolor se selecciona
simplemente moviendose a la cara apropiada. La usuario intenta hacer clic en
la cara para confirmar que esa es la elegida. Se echa de menos mas claridad en
este aspecto
13.1.3. Conclusiones
Se realiza una lista de tareas pendientes a mejorar. Debido al calendario de
entrega de la aplicacion, no va a ser posible finalizarlas todas antes de esa fecha. La
lista es la siguiente:
Retocar las resoluciones de los media query de CSS, para que las distribuciones
de pantalla se muestren correctamente en los dispositivos apropiados
Capıtulo 13 Ruben Sanchez Garcıa 55
Cronic
Sustituir los checkbox por interruptores tipo
toggle
Reconsiderar la necesidad de ofrecer dos paginas distintas para la introduccion
de entradas
Anadir una funcion para cerrar el modal al pulsar fuera de este
Aclarar en el formulario de entradas que la cara visible es la cara seleccionada
Considerar los textos del menu en la disposicion de escritorio
Anadir funcion de busqueda
Anadir filtro para las fechas del grafico de dolor
56 Capıtulo 13 Ruben Sanchez Garcıa
Capıtulo 14
Seguridad
Al ser una aplicacion basada en Laravel, la proteccion de Cronic esta estrecha-
mente ligada a las caracterısticas de seguridad que ofrece dicho framework. Dos de
las mas prominentes son:
Previene inyeccion SQL mediante PDO (Eloquent realiza la peticion por de-
fecto de este modo)
Previene el Cross Site Scripting mediante el escape de caracteres.
Y por supuesto, se le anade la capa de seguridad de Heroku:
Firewalls
Mitigador de DDoS
Proteccion contra textitspoofing
Proteccion contra escaneo de puertos
Cada aplicacion se ejecuta en un entorno aislado y no puede interactuar con
el resto de aplicaciones.
El acceso a las BBDD PostgreSQL requiere encriptacion SSL.
Cuando la complejidad del proyecto vaya en aumento, puede ser necesario revisar
las medidas de seguridad.
57
Capıtulo 15
Versiones
Al ser una aplicacion web, las versiones se plantean bajo el sistema de liberacion
continua ((rolling release). A excepcion de las tres versiones entregadas durante las
PAC, que segun los requisitos deberıa corresponder a alpha, beta y final, el resto de
versiones corresponderan unicamente a las actualizaciones de codigo que se muevan
al servidor remoto semanalmente con motivo de los sprint.
El unico indicador fiable para etiquetar las versiones en el servidor son los nume-
ros de referencia de los commit de Git. La version final presentada es el commit
numero 51.
58
Capıtulo 16
Instrucciones
Como cualquier aplicacion web moderna, no se redactan instrucciones de usuario,
ya que se presupone que el trabajo de usabilidad y diseno de interfaz es suficien-
temente claro como para que se entienda la funcionalidad sin necesidad de leer un
documento.
La unica opcion razonable es la del uso de overlays de ayuda sobre la panta-
lla la primera vez que el usuario entra tras registrarse. Existen algunas librerıas
interesantes como Impromptu1 o Chardin2
Se plantea utilizar estas librerıas en el futuro cuando la aplicacion se ofrezca al
publico, pero se descarta utilizarlas para la entrega final.
1http://trentrichardson.com/Impromptu2http://heelhook.github.io/
59
Cronic
Figura 16.1: Ejemplo de Impromptu
Figura 16.2: Ejemplo de Chardin
60 Capıtulo 16 Ruben Sanchez Garcıa
Capıtulo 17
Bugs conocidos
En la version final presentada, existen los siguientes bugs.
La pantalla de ver artıculo no muestra correctamente los saltos de linea. Estos
estan guardados en el texto (ası se puede ver si se edita un artıculo), pero a la
hora de mostrarse existen fallos.
Y ademas falta por implementar las siguientes funciones:
Anadir la opcion de enviar recordatorio por email para los eventos
Permitir anadir campos personalizados a la pantalla de crear entrada
Implementar la vista para doctores
Implementar pantalla de busqueda
Implementar filtros de fechas para los graficos.
61
Capıtulo 18
Proyeccion de Futuro
Una vez entregada la version final del trabajo, se contempla el continuar desa-
rrollando funcionalidades hasta convertirlo en un producto viable. Para ello, se es-
quematiza una serie de pasos:
Completar todos los requisitos de codigo iniciales. Principalmente se le da
importancia a la opcion de vista para doctores, ya que es la caracterıstica mas
notable que no ha sido posible incluir en la entrega final.
Ampliar la capacidad de hospedaje, ya que actualmente la aplicacion se en-
cuentra alojada en pruebas, lo cual es inviable para un producto publico
Profundizar en el estudio de mercado, entender con mas exactitud que pro-
ductos similares existen y en que lugar podrıa encajar esta aplicacion
Una vez decidido, trazar un plan de accion que encaje con esa idea (por ejem-
plo, si es prioritaria una aplicacion movil nativa, si es mas importante anadir
una funcionalidad u otra, etc.)
Como alternativa, incluso si se opta por la no continuacion del proyecto en su
faceta mas convencional, se publicara el codigo fuente en GitHub y se planteara
un crecimiento como proyecto comunitario en vez de oportunidad comercial.
62
Capıtulo 19
Presupuesto
Atendiendo a las caracterısticas detalladas de la aplicacion, tal y como se han
especificado a lo largo del siguiente texto, se plantea un posible presupuesto del coste
real de esta si tuviera que ser programada desde cero por terceros:
Concepto Precio en Euros
Diseno Grafico de la web 150
Programacion de la aplicacion y sus funcionalidades 500
Maquetacion del estilo a la imagen del diseno grafico 300
Registro del dominio y alojamiento por un ano 120
Servicios de Marketing por Internet (opcional) 250
Cuadro 19.1: Presupuesto.
Total con marketing: Mil trescientos veinte euros.
Total sin marketing: Mil setenta euros..
A estos precios es necesario sumarles el IVA.
63
Capıtulo 20
Analisis de mercado
20.1. Herramientas actuales
Un motivo por el cual las aplicaciones dedicadas al registro de la enfermedad no
han despegado totalmente, puede ser debido a la popularidad conseguida por las
herramientas genericas para publicar blogs. En algunos casos, plataformas de blogs
genericos dedican paginas especıficas a realizar publicidad sobre las posibilidades
de registrar la salud del usuario1. Podemos tambien encontrar otras plataformas
aparentemente mas especializadas en ese campo2, pero la gran mayorıa de artıculos
informales que recomiendan llevar este tipo de registros, suelen sugerir herramientas
genericas o incluso papel3.
20.1.1. Aplicaciones moviles
Con la llegada de las aplicaciones moviles, aparecio un escenario en el cual surgıan
aplicaciones de una variedad difıcilmente vista en otras plataformas anteriores. Parti-
cularmente esta gran variedad se noto en la plataforma Android, debido a la facilidad
de publicar en ella.
Sin embargo, tras examinar el listado de aplicaciones de este genero en la tienda
Google Play y en la App Store con un filtro que excluya los productos de pago,
podemos observar que la gran mayorıa de diarios de salud se dirigen a conceptos
muy concretos, como por ejemplo el ejercicio fısico y la dieta o los registros del dolor
en casos de dolor cronico.
El numero de aplicaciones que pretenden registrar y gestionar entradas medicas
sin importar la enfermedad en cuestion es extremadamente limitado, lo cual nos
abre la puerta para presentar un desarrollo de calidad que pueda alcanzar al mayor
1https://penzu.com/health-diary2http://www.mytherapyjournal.com3http://lifehacker.com/why-you-should-keep-a-journal-and-how-to-start-yours-1547057185
64
Capıtulo 21
Conclusiones
Las siguientes conclusiones preliminares pueden variar en la entrega final de este
documento.
21.1. Conclusiones sobre temas teoricos
El realizar una aplicacion dirigida a un tipo de publico tan especıfico ha servido
para enfatizar lo importante que es planear el diseno en concordancia con el usua-
rio. No sabemos que posibles enfermedades podemos encontrar en quienes utilizan
nuestro producto, ası que es necesario tener en cuenta todos los factores de accesibi-
lidad posibles. Daltonismo, problemas de movilidad, etc. Este punto es algo que no
siempre se tiene en cuenta en todos los desarrollos, pero trabajar en este proyecto
ha servido para comprender su importancia.
Igualmente, debido a ser la primera vez que se afrontaba una tarea de este ta-
mano, ha resultado interesante reflexionar sobre los aspectos teoricos en la planifi-
cacion de proyectos que se han ensenado en la UOC a lo largo de todo el grado.
Sin una planificacion logica y razonada, ordenar y dar prioridad a la multitud de
pequenas tareas que comprenden el cuerpo final, hubiera sido mucho mas difıcil.
21.2. Conclusiones sobre temas practicos
Las conclusiones mas interesantes son sobre asuntos practicos. Para una persona
que nunca antes habıa elaborado una aplicacion completa, el pasar de los pequenos
ejercicios vistos en el grado a algo de este calibre, supone un gran paso hacia adelante,
afianzando la capacidad de afrontar retos similares en el futuro.
Durante la elaboracion de CRONIC, se han visto tecnologıas y metodos de gran
utilidad, no solo a nivel teorico o practica con pequenos ejemplos, sino en el contexto
de un proyecto de gran tamano, lo cual aporta una perspectiva y un conocimiento
66
Cronic
de mucha utilidad con vistas al futuro.
Algunas de las tecnologıas aprendidas especialmente para este trabajo, y lo que
han aportado:
Heroku: El configurar los servidores, bases de datos y demas programas necesarios
para ejecutar una aplicacion web, ya no es un requisito indispensable. Con la
llegada de productos de Platform as a service como Heroku, el desarrollador
puede centrarse en programar su aplicacion, sin temor a fallos en la confi-
guracion del servidor o problemas con los permisos de la base de datos. Un
servicio extremadamente simple que ha sido a su vez un gran descubrimien-
to. Su uso es tan corriente a dıa de hoy que incluso deberıa mencionarse en
algunas asignaturas relevantes del Grado Multimedia.
Laravel: Con Laravel se confirma que una librerıa es la forma mas eficiente de
exprimir al maximo un lenguaje como PHP sin necesidad de tener un conoci-
miento experto de este. Por supuesto ha sido necesaria una fase de aprendizaje,
especialmente porque el modelo MVC era algo que no se habıa ensenado du-
rante el grado, lo cual tiene a causar cierta confusion cuando se ve por primera
vez. Tras un proceso de lectura de documentacion, ha sido posible construir la
estructura del programa en Laravel, siendo el resultado final totalmente satis-
factorio. Para futuros proyectos, se considerara esta librerıa con gran prioridad
sobre las demas.
Vagrant: Lo que Heroku ha conseguido en alojamiento de servidores, Vagrant lo
consigue en entorno local. Cuando desarrollamos con muchas dependencias
(PHP con Composer, Node.js, PostgreSQL, etc..), instalar y configurar todo
el entorno puede ser dificultoso. Las Vagrant box permiten comenzar a desa-
rrollar rapidamente sobre un entorno preconfigurado que puede restaurarse a
su estado original en cualquier momento. A partir de este proyecto actual, es
difıcil volver a concebir el desarrollo sin Vagrant.
Capıtulo Ruben Sanchez Garcıa 67
Apendice A
Lista de entregables
A.1. Documentos
El presente documento de memoria de la Practica Final:
PAC FINAL mem Sanchez Garcia Ruben.pdf
El documento de presentacion del proyecto:
PAC FINAL prs Sanchez Garcia Ruben.pdf
El archivo zip con el proyecto:
PAC FINAL prj Sanchez Garcia Ruben.zip. Este archivo contiene las siguien-
tes partes
• El documento con las instrucciones de instalacion
• Un archivo zip con el codigo
• Una copia de seguridad de la base de datos
• Los archivos originales del diseno de las caras del dolor en formato Adobe
Illustrator
El video de presentacion del proyecto PAC FINAL vid Sanchez Garcia Ruben.mp4
68
Apendice B
Codigo fuente
Debido a su tamano y la imposibilidad de insertarlo en este documento al mismo
tiempo que se mantiene legible, el codigo se incluye en el archivo adjunto cronic.zip
Es posible clonarlo via git en https://git.heroku.com/cronic.git
La version instalada se encuentra en http://cronic.herokuapp.com/
69
Cronic
Figura C.4: Panel de control.
Figura C.5: Introduccion de diario.
72 Capıtulo C Ruben Sanchez Garcıa
Cronic
Figura C.6: Introduccion de eventos.
Figura C.7: Listado de entradas.
Capıtulo C Ruben Sanchez Garcıa 73
Cronic
Figura C.8: Grafico de dolor.
Figura C.9: Vista de calendario.
74 Capıtulo C Ruben Sanchez Garcıa
Cronic
Figura C.10: Edicion de perfil.
Figura C.11: Perfil actualizado.
Capıtulo C Ruben Sanchez Garcıa 75
Apendice D
Librerıas utilizadas
D.1. Librerıas para PHP
Laravel 5.2
Laravel conforma el grueso de la logica de la aplicacion, ocupandose de ges-
tionar la base de datos a traves de Eloquent, las vistas, la creacion de feeds de
JSON y las plantillas de texto mediante Blade
D.2. Librerıas para Javascript
jQuery 2.2
jQuery se ocupa de gestionar la mayor parte de codigo ejecutado en el cliente,
como por ejemplo las llamadas AJAX, las sustituciones de imagenes y las
mejoras de interfaz como las opciones de maximizar y minimizar. Asimismo es
un requisito obligatorio para el uso de otras librerıas utilizadas en la aplicacion.
FullCalendar 2.7
FullCalendar toma un feed JSON construido con Laravel e incluye los eventos
detallados en una vista de calendario que requiere jQuery.
Highcharts 4.2.5
HighCharts muestra de manera grafica datos numericos. En esta aplicacion se
opta por crear un grafico con la evolucion del dolor del paciente.
Select2 4.0.2 La herramienta mas utilizada para convertir los menus select de
html en cajas inteligentes con funcion de busqueda
Datetimepicker 2.5.4 Potente selector de fechas con posibilidad de seleccionar
horas.
79
Cronic
Moment.js 2.13.0 Librerıa para transformar fechas a modo texto
D.3. Librerıas para CSS
Bootstrap 3.5.2 Librerıa de clases CSS para facilitar la creacion de estructuras
complejas y funcionalidades comunes.
Select2 for Bootstrap 3.5.2
Tema para utilizar con nuestros menus Select2 una estetica similar a la de
Bootstrap
Bootbox 4.4.0 Complemento para crear popups modales para Bootstrap
Bootstrap toggle 2.2.2 Complemento para sustituir los checkbox por interrup-
tores en los formularios.
80 Capıtulo D Ruben Sanchez Garcıa
CronicTÍTULOS Y CABECERAS
Cuerpo de texto
R: 31 G: 51 B: 28
R: 201 G: 217B: 150
R: 245 G: 243 B: 193
Lobster Regular
Ubuntu Condensed
Lato Regular
Bootstrap Toggle Success
Botones hover y normal
Entrada de texto sin foco
Entrada de texto con foco
R: 150 G: 187 B: 104
Bibliografıa
Dubord, Greg (2011). ((Part 9. Thought records)). En: Canadian Family Physi-
cian 57.8, pags. 913-914. url: http://www.ncbi.nlm.nih.gov/pmc/
articles/PMC3155448/.
Purcell, Maud (2006). ((The health benefits of journaling)). En: Psych Central.
Shetzer, Lucie (2007). ((Confronting Aging and Serious Illness through Journaling:
A Study of Writing as Therapy)). En: url: http://rave.ohiolink.edu/
etdc/view?acc_num=bgsu1192341678.
Smith, Susan y col. (2005). ((The effects of journaling for women with newly diagno-
sed breast cancer)). En: Psycho-Oncology 14.12, pags. 1075-1082. issn: 1099-1611.
doi: 10.1002/pon.912. url: http://dx.doi.org/10.1002/pon.912.
Taylor, Renee R (2006). Cognitive behavioral therapy for chronic illness and disabi-
lity. Springer Science & Business Media.
Bieri, Daiva y col. (1990). ((The Faces Pain Scale for the self-assessment of the
severity of pain experienced by children: development, initial validation, and
preliminary investigation for ratio scale properties)). En: Pain 41.2, pags. 139-150.
Beck, Kent y col. (2001). ((Manifesto for agile software development)). En:
83