Repositorio Institucional de Documentos

Trabajo Fin de Máster Máster en Ingeniería de Sistemas e Informática Septiembre de 2012 Tipo B PROCUR@: Plataforma abieRta de sOporte a la prevenCión y rehabilitación de enfermedades neUrodegeneRativAs Joaquín Pérez Marco Director: Dr. Álvaro Marco Marco (I3A) Ponente: Dr. Francisco José Serón Arbeloa (DIIS) Agradecimientos A mi director Álvaro Marco, por confiar en mí para este proyecto, implicándose en éste desde el primer momento. A mi ponente Francisco J. Serón, por aceptar la tarea como ponente. Al grupo de trabajo HOWLab, por su amabilidad y paciencia conmigo. Al resto de entidades involucradas en PROCUR@ (Universidad de Sevilla, Logica, Flowlab, AIJU, Solutio, Hospital Virgen del Rocío) por su ayuda y consejos para mejorar el proyecto. Y por supuesto, a mis compañeros de clase, amigos, familia, y en general a todas aquellas personas que me han apoyado durante estos meses de trabajo. PROCUR@: Plataforma abieRta de sOporte a la prevenCión y rehabilitación de enfermedades neurodegenerativas Resumen El Trabajo Fin de Máster (TFM) propuesto se enmarca dentro de los trabajos a realizar en el proyecto Procur@, perteneciente a la convocatoria INNPACTO, y que pretende desarrollar una plataforma para la prevención, teleasistencia y rehabilitación de pacientes con enfermedades neurodegenerativas (Alzheimer, Parkinson, etc) en la que tengan cabida los propios pacientes, sus familiares y cuidadores, y los profesionales que atienden a todos ellos. Como resultado, se logrará un menor coste económico de la asistencia a este colectivo de personas, junto con una mayor calidad de vida. Dentro de las primeras fases del proyecto, se pretende desarrollar una primera versión que ofrezca las funcionalidades típicas de una red social, orientadas y particularizadas al contexto de los enfermos de Parkinson y otras patologías neurodegenerativas, y es donde se concreta el TFM propuesto. Este TFM es la base para el primer ciclo de los Espacios Sociales de Innovación (ESdI), metodología que pretende la participación de los usuarios finales del proyecto desde el primer momento, de modo que es seguro en todo momento el éxito de su puesta en marcha, al participar éstos en todas las fases de definición, desarrollo e implementación. Particularmente, se desarrollará el ESdI en Parkinson auspiciado por la Asociación de Parkinson de Aragón, entidad privada sin ánimo de lucro integrada en la Federación Española de Parkinson, declarada de Interés Social por el Gobierno de Aragón y Entidad de Utilidad Pública por el Ministerio de Interior debido a la labor que desempeña con el colectivo de enfermos y familiares. Los objetivos de esta primera fase y del TFM comprenden:  Revisión de plataformas que faciliten la creación de una red social  Revisión de redes sociales de temáticas afines para identificar funcionalidades requeridas.  Puesta a punto de la red social, programación de módulos necesarios para personalizar la plataforma según los requisitos de usuario y de funcionalidad  Propuesta de despliegue de la red social en el entorno de evaluación del ESdI de Parkinson  Propuesta de evaluación por parte de los usuarios implicados en el proyecto Índice general 1Introducción ....................................................................................... 1 1.1Motivación .................................................................................... 1 1.2Objetivos del proyecto .................................................................... 1 1.3Contenido y alcance del documento .................................................. 1 1.4Marco de trabajo ............................................................................ 2 2Estado del arte sobre redes sociales en el ámbito de la salud .................... 5 3Diseño de la plataforma ....................................................................... 9 3.1Especificaciones de la plataforma ..................................................... 9 3.1.1Perfiles de usuario .................................................................. 10 3.1.2Módulo de tratamientos ........................................................... 10 3.1.3Otras necesidades identificadas ................................................ 11 3.2Propuesta de módulos a desarrollar ................................................ 11 3.2.1Módulo Perfiles – relaciones – permisos ..................................... 11 3.2.2Módulo Tratamientos ............................................................... 11 3.3Propuesta de módulos a integrar .................................................... 12 3.3.1Módulo eLearning ................................................................... 12 3.3.2Módulo Información ................................................................ 13 3.3.3Módulo de Foro ...................................................................... 13 3.3.4Módulo de Mensajería.............................................................. 14 3.3.5Módulo de log de actividad y exportación a base de datos para explotación ...................................................................................... 14 3.3.6Módulo de encriptación y seguridad ........................................... 15 3.3.7Módulo de integración con otras redes sociales ........................... 15 3.3.8Otros módulos utilizados.......................................................... 16 4Ciclo de desarrollo software ................................................................ 17 4.1Metodología y Entorno de trabajo ................................................... 17 4.2Descripción de la arquitectura de Elgg ............................................. 17 4.3Resultados del desarrollo .............................................................. 19 4.4Implantación y evaluación de la plataforma ..................................... 20 5Conclusiones y trabajo futuro ............................................................. 21 5.1Resultados obtenidos .................................................................... 21 5.2Problemas encontrados ................................................................. 21 5.3Líneas futuras .............................................................................. 21 5.4Valoración personal ...................................................................... 22 BIBLIOGRAFÍA ........................................................................................ 25 ANEXOS ................................................................................................ 29 Anexo A. Trabajo previo ........................................................................... 31 A.1 Estado del arte redes sociales del ámbito de la salud ........................... 31 Redes Sociales de la Salud ................................................................. 32 Proyectos con sistemas orientados a teleasistencia ................................ 33 Comparativa funcional de sistemas orientados a salud............................ 33 A.2 Comparativa de plataformas de creación de redes sociales ................... 40 Selección previa ................................................................................ 41 Comparativa funcional ....................................................................... 42 Selección de plataforma: Elgg ............................................................. 44 Anexo B. Descripción ampliada de los perfiles de usuario .............................. 47 Anexo C. Documentación ampliada de los módulos desarrollados ................... 51 C.1 Módulo Perfiles-Relaciones-Permisos ................................................. 51 Casos de uso .................................................................................... 53 Modelo de datos ............................................................................... 61 Anexo C.2. Módulo Tratamientos ............................................................ 66 Casos de uso módulo Tratamientos ..................................................... 66 Modelo de datos módulo Tratamientos ................................................. 75 Anexo D. Distribución temporal del proyecto ............................................ 81 Anexo E. Licencia de uso ....................................................................... 83 1 1 Introducción En el primer capítulo de esta memoria se va a introducir el Trabajo Fin de Máster (TFM), exponiendo en primer lugar la motivación para llevarlo a cabo, así como los objetivos que se buscaban con su realización. Se explicará además el contenido y alcance de este documento y por último el marco del trabajo a realizar. 1.1 Motivación En el momento de buscar un trabajo para acabar mi máster lo que perseguía principalmente era plasmar los conocimientos que había adquirido en algo que fuera útil para otras personas. No quería que quedara en el ámbito universitario como una simple prueba para finalizar el máster y por esto no me lo pensé dos veces cuando me propusieron hacer un trabajo que tenía una repercusión social directa. 1.2 Objetivos del proyecto El objetivo principal del proyecto es la creación de una plataforma de red social aplicada al ámbito de la salud, y en particular que sirva a la Asociación de Parkinson de Aragón para desarrollar las terapias que involucran a sus usuarios (pacientes, familiares, etc). Para ello, se plantean distintas tareas:  Revisión de plataformas que faciliten la creación de una red social  Revisión de redes sociales de temáticas afines para identificar funcionalidades requeridas.  Puesta a punto de la red social, programación de módulos necesarios para personalizar la plataforma según los requisitos de usuario y de funcionalidad  Propuesta de despliegue de la red social en el entorno de evaluación del ESdI de Parkinson  Propuesta de evaluación por parte de los usuarios implicados en el proyecto 1.3 Contenido y alcance del documento Este documento se estructura en dos partes: una memoria que resume el trabajo realizado y algunos anexos con documentación técnica más detallada del mismo. La memoria está dividida en una serie de capítulos siendo el primero de ellos la presente introducción. El capítulo Estado del arte describe la búsqueda de información previa respecto a redes sociales en el ámbito de la salud. El capítulo Diseño de la plataforma está dedicado a describir el proceso de desarrollo de los 9 3 Diseño de la plataforma Este capítulo está dedicado a explicar el trabajo previo al diseño de la plataforma y el proceso seguido durante su diseño y desarrollo. Se expone el desarrollo de cada una de las partes que han compuesto el trabajo por separado, haciendo especial hincapié en las decisiones tomadas y explicando los motivos que llevaron a cada elección. 3.1 Especificaciones de la plataforma Se realizaron diversas reuniones e intercambios de correos electrónicos entre todos los miembros del consorcio, para definir las especificaciones, requisitos y funcionalidades que debería ofrecer Procur@. Entre ellas, destaca la plenaria, que fue una reunión de dos días de duración en las instalaciones de la Asociación de Parkinson de Aragón así como en las del I3A, en la que nos dimos cita representantes de las distintas entidades que trabajan en el proyecto junto con personal de la propia asociación. Ello sirvió para afinar los requisitos necesarios de la plataforma, así como tener un contacto de primera mano con la problemática específica de la asociación. Plenaria Procur@, brainstorming.16-04-2012 Entre las necesidades identificadas destacan las siguientes: 10 3.1.1 Perfiles de usuario Uno de los puntos fuertes de Procur@ es que no considera que todos sus usuarios son esencialmente iguales (como por ejemplo, sí hace Facebook) sino que cada uno desempeña en ella un rol, que hemos decidido categorizar en perfiles. Los médicos desarrollan su actividad en el hospital o centro de salud. Cada cierto tiempo (variable en función del estado de la enfermedad) el paciente les visita (acompañado previsiblemente de un familiar o cuidador) y éste evalúa su enfermedad y le prescribe algún tratamiento o medicación. En las primeras fases de Procura se pensó que podrían hacerlo a través de la plataforma, pero en sucesivas reuniones con responsables de la asociación quedó bastante claro que tienen mucha faena y no están dispuestos a ello. A lo más que se podría aspirar a día de hoy sería a que leyesen los informes enviados por la asociación a través de la plataforma (mensajería interna) y prescribiesen también a través de ella actividades que pudiera realizar el paciente. Los profesionales de la Asociación prescriben también tratamientos (los sugeridos por médicos, o ideados por ellos mismos de acuerdo a su experiencia), realizan el seguimiento de los pacientes día a día, proporcionan información en la plataforma, y responden a dudas de los familiares, pacientes y cuidadores, tanto en persona, como en la plataforma, a través del Foro y de mensajería privada. Los pacientes, familiares y cuidadores tienen habitualmente una estrecha relación personal y afectiva, con lo que comparten continuamente información entre ellos y con miembros de la asociación, lo que permite adaptar los tratamientos más rápidamente de acuerdo a las posibles nuevas circunstancias (empeoramiento de la movilidad, etc). Una descripción más detallada de los diferentes perfiles y sus características puede encontrarse en el anexo B. Parece evidente que cada perfil posee necesidades muy diferentes, y entre ellas, está la visualización adecuada de la información. Un paciente típico, por ejemplo un anciano de 80 años con Alzheimer en estado no muy avanzado, necesita poca información que le distraiga, e iconos y tamaño de fuente grandes. Un médico, sin embargo, puede procesar más información sin que le sea incómodo, aparte de necesitar más opciones para controlar algunas características de la plataforma, como los tratamientos (crearlos, asignarlos a pacientes, modificarlos, eliminarlos...). 3.1.2 Módulo de tratamientos Una de las primeras necesidades detectadas por la Asociación fue que la plataforma permita prescribir tratamientos a los usuarios para que los realicen de forma remota, y que los terapeutas puedan verificar que los han realizado, evaluarlos y hacer un seguimiento de los mismos. Inicialmente se planteó que los médicos también estarían muy involucrados en ello. Sin embargo, tras algunas reuniones, se constató que la mayor parte de médicos ya están saturados de trabajo y es muy poco probable que usen el sistema como un terapeuta, al menos en un primer momento. 11 3.1.3 Otras necesidades identificadas Se requería posibilidad de definir relaciones entre usuarios, seguridad y encriptación, módulos de aprendizaje, juegos, foro, log de actividad, etc. 3.2 Propuesta de módulos a desarrollar Para satisfacer las necesidades planteadas por la Asociación y detectadas mediante reuniones y talleres, se plantea desarrollar una serie de módulos especializados que proporcionan una solución a los diferentes requisitos. 3.2.1 Módulo Perfiles – relaciones – permisos El comportamiento general de la plataforma Procur@ está condicionado por los perfiles de los usuarios y las relaciones que se establecen entre ellos. Por ese motivo, parece lógico que la gestión de los perfiles de usuario, las relaciones entre usuarios y los privilegios para realizar acciones se centralicen en un único módulo, configurable y personalizable fundamentalmente por el administrador de la plataforma. Los perfiles de usuario definen cuáles son las características del mismo, y va a tener un efecto importante sobre el comportamiento de la plataforma de cara al usuario. Las relaciones entre los usuarios pueden ser diferentes a la típica relación de amistad que podemos encontrar en cualquier red social, y modifican el comportamiento de la plataforma respecto al usuario. También hay que definir las acciones que pueden realizar en la plataforma, y los privilegios de un usuario para ejecutarlas en según qué condiciones. La funcionalidad de la plataforma se construye a partir de módulos que implementan diferentes funcionalidades, pudiendo manejar contenidos específicos, como pueda ser un tratamiento. Por su extensión, la documentación detallada del módulo PRP queda recogida en el anexo C. 3.2.2 Módulo Tratamientos Este módulo permite a los profesionales (médicos, terapeutas, psicólogos, etc.) prescribir tratamientos a sus pacientes. Esto es útil por ser la base para el tratamiento de muchas de estas dolencias de larga duración y neurodegenerativas, y fue uno de los primeros requisitos solicitados por parte de la asociación. El módulo contempla las características personales de los usuarios de la plataforma, y presenta a los diferentes usuarios vistas de la información muy diferentes. Los pacientes sólo pueden ver sus tratamientos. Los cuidadores y familiares pueden ver los tratamientos de los pacientes a los que cuidan, así como los médicos que se encargan de ponerles tratamientos. Los prescriptores tienen control total: pueden crear, asignar, modificar y eliminar tratamientos, así 12 como comunicarse con los cuidadores e incluso con los pacientes (en los casos en que esto sea razonable). Se ha basado (como la mayor parte de plugins Elgg existentes) en código de plugins ya realizados anteriormente. Concretamente, se ha basado en blog, un plugin proporcionado por defecto que permite a sus usuarios crear un blog, añadirle entradas, y consultar los blogs de los demás. Por su extensión, la documentación detallada del módulo de Tratamientos queda recogida en el anexo C. 3.3 Propuesta de módulos a integrar También se requiere la integración con otros módulos y plataformas que no han requerido un estudio tan exhaustivo como el módulo PRP y el de Tratamientos, sino que se han basado más en integración con otras soluciones ya existentes, modificar código mínimamente o directamente instalar plugins disponibles libremente de Elgg. 3.3.1 Módulo eLearning Muy ligado al módulo de Tratamientos (aunque podría ser independiente de ser necesario) se encuentra un módulo de e-Learning capaz de trabajar a nivel básico con SCORM. SCORM (del inglés Sharable Content Object Reference Model) es un conjunto de estándares y especificaciones que permite crear objetos pedagógicos estructurados. Los sistemas de gestión de contenidos en web originales usaban formatos propietarios para los contenidos que distribuían. Como resultado, no era posible el intercambio de tales contenidos. Con SCORM se hace posible crear contenidos que puedan importarse dentro de sistemas de gestión de aprendizaje diferentes, siempre que estos soporten la norma SCORM. Los principales requerimientos que el modelo SCORM trata de satisfacer son:  Accesibilidad: capacidad de acceder a los componentes de enseñanza desde un sitio distante a través de las tecnologías web, así como distribuirlos a otros sitios.  Adaptabilidad: capacidad de personalizar la formación en función de las necesidades de las personas y organizaciones.  Durabilidad: capacidad de resistir a la evolución de la tecnología sin necesitar una reconcepción, una reconfiguración o una reescritura del código.  Interoperabilidad: capacidad de utilizarse en otro emplazamiento y con otro conjunto de herramientas o sobre otra plataforma de componentes de enseñanza desarrolladas dentro de un sitio, con un cierto conjunto de herramientas o sobre una cierta plataforma. Existen numerosos niveles de interoperabilidad.  Reusabilidad: flexibilidad que permite integrar componentes de enseñanza dentro de múltiples contextos y aplicaciones. 13 Se buscó algún sistema para integración de Elgg con SCORM, y al no encontrar ninguno libre o al menos gratuito, se decidió utilizar un servicio web de terceros. Concretamente, se escogió SCORM Cloud, de Rustici Software2. Es gratuito hasta cierto límite, teniendo que pagar una licencia mensual en función de la carga de trabajo (número de cursos subidos, accesos, etc.) que necesitemos. 3.3.2 Módulo Información Los profesionales de la Asociación querían disponer de un espacio exclusivo para ellos en el que situar información de interés general para pacientes con Parkinson y personas de su entorno: descripción de la enfermedad, mitos a desterrar sobre la misma, información variada sobre tratamientos, etc. Se consideró la posibilidad de incluirlo como una página web estática modificable por el administrador, pero finalmente se optó por un sistema de tipo blog, con diferentes entradas gestionables de forma independiente. 3.3.3 Módulo de Foro La Asociación quería que Procura sirviese también como punto de encuentro para los pacientes, familiares, etc. en Internet, como una extensión de sus periódicos encuentros presenciales en su sede. Así, los usuarios pueden preguntar y responder cuestiones relacionadas con su enfermedad, o incluso charlar de temas variados para distraerse un poco. Tras un análisis de las posibilidades, se consideró que un foro podría ser una opción adecuada. De cara a implementarlo, se utilizó el plugin hypeForum3. Este sistema presenta la gran ventaja de estar integrado en Elgg, de forma que se simplifica el 2 http://www.scorm.com 3 http://community.elgg.org/pg/plugins/project/837511/developer/ihayredinov/hypeforum-18 14 mantenimiento de una base de datos unificada de usuarios Procura – usuarios foro. Comentar que si las necesidades del foro creciesen y el plugin se quedase limitado, existen también hay plugins que conectan Elgg con foros ya existentes que utilicen phpBB34 o Vanilla5. 3.3.4 Módulo de Mensajería Esencial en cualquier red social, Procura no es ninguna excepción. Además, complementa a la perfección el Foro, ya que sirve para el envío de información privada entre usuarios, ya sea entre profesional y paciente, profesional y familiar, entre pacientes (que sean amigos, por ejemplo), familiares, etc. Elgg dispone de serie de un sistema de mensajería privada, bastante potente y cómodo. La única tarea a realizar es personalizar las vistas para que aquellos usuarios con pocas habilidades tecnológicas (fundamentalmente, personas de edad avanzada) puedan utilizar al menos una parte de su funcionalidad. 3.3.5 Módulo de log de actividad y exportación a base de datos para explotación Sería deseable poder monitorizar la actividad de los usuarios en la plataforma, por multitud de motivos. Por ejemplo, los médicos podrían saber cuánto tiempo invierten sus pacientes en las diferentes secciones, o el número de intentos necesarios para completar una actividad, o si una sección de información es visitada por los usuarios, etc. Esto, que podría considerarse una violación inaceptable de la intimidad personal en otros contextos, en teleasistencia y telerehabilitación es algo muy útil para los profesionales del campo. Para lograrlo, tenemos a nuestra disposición varios logs. Al margen de los propios del servidor web (Apache) o de la base de datos MySQL, Elgg guarda también un log en el que se refleja toda la actividad de las entidades (creación, modificación o eliminación) así como el login de los usuarios. No obstante, se quería un mecanismo más flexible (acceso a módulos o a información concreta, etc.) por lo que se creó un sencillo plugin que permite insertar entradas de log en la base de datos de Elgg (con usuario, fecha del evento y tipo del evento, sin restricciones) en los puntos de código que necesitemos. Alternativamente, puede emplearse el mecanismo incorporado por Elgg para ello (eventos y plugin hooks, lugares del código donde pueden engancharse otros módulos para compartir información). La información que en una primera fase va a ser guardada es el login de los usuarios (proporcionado por defecto) y los accesos al módulo de Tratamientos, por ser de momento suficiente para satisfacer las necesidades de la asociación. 4 http://community.elgg.org/pg/plugins/project/384508/developer/SGr33n/phpbb3-integration-plugin 5 http://community.elgg.org/pg/plugins/project/384743/developer/kevin/vanilla-forum-integration 15 Por último, decir que aunque el objetivo de este módulo es la recopilación de información de modo flexible, quedando su procesamiento y explotación fuera del alcance de este TFM, para verificar su correcto funcionamiento sí se ha utilizado una pequeña vista web incluida en Procura (sólo visible por el administrador). 3.3.6 Módulo de encriptación y seguridad En cuanto a encriptación y seguridad, es una red social cerrada, a la que no se puede acceder sin usuario y contraseña, y que requiere el alta manual de usuarios (no está pensada para visitantes casuales). Por lo demás, incorpora por defecto mecanismo de protección contra los típicos ataques de inyección SQL, XSS, etc.… y finalmente es algo que también depende de la propia seguridad del servidor de hosting ante otros ataques (vulnerabilidades de un LAMP conocidas ante una mala configuración, ataques DDoS…). 3.3.7 Módulo de integración con otras redes sociales Este módulo se encarga de permitir el login en Procura usando algunas de las redes sociales más extendidas (Facebook, Google+, etc.). Esta funcionalidad era necesaria pues muchos usuarios no querrían pasar por el proceso de creación de una cuenta de usuario en “otra red social más”, y aumenta la aceptación general del sistema. Para la implementación efectiva de este módulo, tras investigar y buscar el método más adecuado para ello, se decidió optar por un plugin externo, Elgg Social Login 1.86. Este plugin es también muy popular en la comunidad Elgg, ya que permite login con Facebook, Google, Yahoo, Twitter, Linkedin, etc. 6 http://community.elgg.org/pg/plugins/project/822077/developer/miled/social-login-for-elgg-18 16 Este plugin tan sólo requiere seguir los pasos normales de creación de una app para Facebook, ligada a una cuenta, con lo que se obtiene una Application Key (mecanismo típico en multitud de servicios web) adecuada para Procura. El único problema que surgió fue con la carga de esta página de login externo. Al ser Procura una red social privada, no accesible desde fuera sin usuario y contraseña válidos (por privacidad, seguridad, etc. lo que se suele denominar walled garden7) había que usar un plugin específico diferente al proporcionado por defecto en Elgg. Se utilizó Elgg LoginRequired 1.88 para dotar a Procura de un walled garden personalizable, y se modificó ligeramente el código fuente para permitir el funcionamiento público de la ventana de login externo, manteniendo el resto de la red social privada. 3.3.8 Otros módulos utilizados Por supuesto, también se han empleado otros plugins de third-parties que son de utilidad: Traducción al castellano9 casi completa. Comentar que Elgg no tiene una buena compatibilidad con caracteres fuera del ASCII estándar, particularmente en tipos de usuario (Medico en vez de Médico), pero por lo demás, proporciona una traducción al castellano aceptable. Esta traducción se ha extendido manualmente para plugins específicos o para corregir fallos evidentes en la traducción. Theme Purity10 (se instala como cualquier otro plugin). Es un tema que precisamente fue pensado para diseños minimalistas que no molesten al usuario, etc. Será personalizado y extendido en futuras versiones. 7 http://en.wikipedia.org/wiki/Walled_garden_%28technology%29 8 http://community.elgg.org/pg/plugins/project/804349/developer/iionly/elgg-18-login-required 9 http://community.elgg.org/pg/plugins/project/791438/developer/nnimis/espaol-spanish-language-pack-v18 10 http://community.elgg.org/pg/plugins/project/793822/developer/sbarron/purity-theme-18 17 4 Ciclo de desarrollo software 4.1 Metodología y Entorno de trabajo Para el desarrollo de las tareas se ha seguido la metodología de trabajo llamada Scrum, que se enmarca dentro de las llamadas metodologías ágiles de programación. Scrum es una metodología para la gestión y desarrollo de software basada en un proceso iterativo e incremental utilizado comúnmente en entornos basados en el desarrollo ágil de software. Utiliza un sistema de pequeños avances, llamados sprints. Durante cada sprint, un periodo entre 15 y 30 días (la magnitud es definida por el equipo), el equipo crea un incremento de software potencialmente entregable (utilizable) mediante un pequeño ciclo del modelo clásico en cascada (requisitos-análisis-diseño-implementación-pruebas). El conjunto de características que forma parte de cada sprint viene derivado del Product Backlog, que es un conjunto de requisitos de alto nivel priorizados que definen el trabajo a realizar. Un principio clave de Scrum es el reconocimiento de que durante un proyecto los clientes pueden cambiar de idea sobre lo que quieren y necesitan (a menudo llamado requirements churn), y que los desafíos impredecibles no pueden ser fácilmente planificados. Por lo tanto, Scrum adopta una aproximación pragmática, aceptando que el problema no puede ser completamente entendido o definido al principio, y centrándose en maximizar la capacidad del equipo de entregar rápidamente y responder a requisitos emergentes. Para el desarrollo de Procura, al trabaja en cooperación con otros equipos de trabajo, se decidió utilizar Sourceforge11 como plataforma de desarrollo, lo cual proporcionaba diversas herramientas como control de versiones o la gestión de releases. La organización del proyecto Procur@ contempla una serie de paquetes de trabajo para realizar el desarrollo, que ha sido replicada en el sistema de control de versiones para que cada paquete de trabajo pueda trabajar de manera independiente. Como herramientas de desarrollo local se ha utilizado Eclipse como IDE, TortoiseSVN para trabajar con el control de versiones, y una plataforma WAMP instalada localmente. 4.2 Descripción de la arquitectura de Elgg Elgg es un framework PHP-MySQL con arquitectura modular que permite a los diseñadores de la red social desplegar los componentes que consideren necesarios, así como una fácil actualización del core del sistema (imprescindible debido a la frecuencia de actualización, una vez al mes aproximadamente). 11 http://sourceforge.net/projects/procura 25 BIBLIOGRAFÍA [1] Wei-Lun Chang and Soe-Tsyer Yuan. 2005. Ambient iCare e-Services for Quality Aging: Framework and Roadmap. In Proceedings of the Seventh IEEE International Conference on E-Commerce Technology (CEC '05). IEEE Computer Society, Washington, DC, USA, 467-470. DOI=10.1109/ICECT.2005.14 [2] Hong Sun; De Florio, V.; Ning Gui; Blondia, C.; , "Participant: A New Concept for Optimally Assisting the Elder People," Computer-Based Medical Systems, 2007. CBMS '07. Twentieth IEEE International Symposium on , vol., no., pp.295-300, 20-22 June 2007. doi: 10.1109/CBMS.2007.82 [3] Banihashem, S.Y.; Shishehchi, S.; Zin, N.A.M.; , "Accessible e-learning approach for handicaps: A proposed interaction technique for arm muscle disorders, Parkinson and hand tremors," Information Technology (ITSim), 2010 International Symposium in , vol.1, no., pp.1-3, 15-17 June 2010 doi: 10.1109/ITSIM.2010.5561326 [4] Fryia, G.D.; Wachowiak-Smolikova, R.; Wachowiak, M.P.; , "Humancomputer interface design in an e-Learning system for individuals with cognitive and learning disabilities," Digital Information Management, 2009. ICDIM 2009. Fourth International Conference on , vol., no., pp.1-6, 1-4 Nov. 2009 doi: 10.1109/ICDIM.2009.5356784 [5] Niskanen, I.; Toivonen, J.; Kantorovitch, J.; , "MuistiKoti - Towards Better Awareness of the Technological Solutions Designed for People with Alzheimer's Disease," Advanced Learning Technologies (ICALT), 2011 11th IEEE International Conference on , vol., no., pp.384-385, 6-8 July 2011 doi: 10.1109/ICALT.2011.121 [6] Escobar-Bravo MÁ, Puga-González D, Martín-Baranera M. “Protective effects of social networks on disability among older adults in Madrid and Barcelona, Spain, in 2005”, Arch Gerontol Geriatr. 54(1):109-16. 2008 [7] van den Hoogen, W.; Ijsselsteijn, W.; de Kort, Y.; , "Yes Wii can! Using digital games as a rehabilitation platform after stroke - The role of social support," Virtual Rehabilitation International Conference, 2009 , vol., no., pp.195, June 29 2009-July 2 2009 doi: 10.1109/ICVR.2009.5174233 [8] Brennan DM, Lum PS, Uswatte G, Taub E, Gilmore BM, Barman J. “A telerehabilitation platform for home-based automated therapy of arm function.” Conf Proc IEEE Eng Med Biol Soc. 2011;2011:1819-22. [9] Zapirain, B.G.; Zorrilla, A.M.; Larrañaga, S.; , "Psycho-stimulation for elderly people using puzzle game," Games Innovations Conference (ICEGIC), 2010 International IEEE Consumer Electronics Society's , vol., no., pp.1-8, 21-23 Dec. 2010 doi: 10.1109/ICEGIC.2010.5716903 26 [10] Li-Der Chou; Nien-Hwa Lai; Yen-Wen Chen; Yao-Jen Chang; Jyun-Yan Yang; Lien-Fu Huang; Wen-Ling Chiang; Hung-Yi Chiu; Haw-Yun Shin; , "Mobile Social Network Services for Families With Children With Developmental Disabilities," Information Technology in Biomedicine, IEEE Transactions on , vol.15, no.4, pp.585-593, July 2011 doi: 10.1109/TITB.2011.2155663 [11] Cabrera-Umpiérrez, M.F.; Jiménez, V.; Fernández, M.M.; Salazar, J.; Huerta, M.A.; , "eHealth services for the elderly at home and on the move," IST-Africa, 2010 , vol., no., pp.1-6, 19-21 May 2010 [12] Marcelino, I.; Barroso, J.; Cruz, J.B.; Pereira, A.; , "Elder Care Architecture," Systems and Networks Communications, 2008. ICSNC '08. 3rd International Conference on , vol., no., pp.349-354, 26-31 Oct. 2008 doi: 10.1109/ICSNC.2008.66 [13] Armstrong, N.; Nugent, C.D.; Moore, G.; Finlay, D.D.; , "Developing smartphone applications for people with Alzheimer's disease," Information Technology and Applications in Biomedicine (ITAB), 2010 10th IEEE International Conference on , vol., no., pp.1-5, 3-5 Nov. 2010 doi: 10.1109/ITAB.2010.5687795 [14] Sposaro F, Danielson J, Tyson G. “iWander An Android application for dementia patients” Conf Proc IEEE Eng Med Biol Soc. 2010;2010:3875-8. [15] Wills, C.; Moumtzi, V.; Vontas, A.; , "A real case study of assistive living ecosystems," Digital Ecosystems and Technologies (DEST), 2010 4th IEEE International Conference on , vol., no., pp.147-151, 13-16 April 2010 doi: 10.1109/DEST.2010.5610654 [16] Kuzma, Joanne (2010) Empirical Study of Privacy Issues Among Social Networking Sites. In: Private Law: Rights, Duties and Conflicts. International Association of IT Lawyers, The Fifth International Conference on Legal,Security and Privacy Issues in IT Law (LSPI) - Barcelona, Spain, pp. 218-230. ISBN 978-87-991385-8-6 [17] Domingo, M.C.; , "Managing Healthcare through Social Networks," Computer , vol.43, no.7, pp.20-25, July 2010 doi: 10.1109/MC.2010.92 [18] Gachet Paez, D.; de Buenaga, M.; Villalba, M.; Lara, P.; , "An Open and Adaptable Platform for the elderly people and persons with disability to access the Information Society. The Naviga project," Pervasive Computing Technologies for Healthcare (PervasiveHealth), 2010 4th International Conference on-NO PERMISSIONS , vol., no., pp.1-5, 22-25 March 2010 doi: 10.4108/ICST.PERVASIVEHEALTH2010.8882 [19] Grgurić, A.; Benc, I.; Desić, S.; Mosmondor, M.; Krizanić, J.; Lazarevski, P.; , "Designing user interfaces for elderly: A case study in applicability of thin vs. fat clients," e-Health Networking Applications and Services (Healthcom), 2010 12th IEEE International Conference on , vol., no., pp.99-105, 1-3 July 2010 27 [20] Murenin, C.A.; Tabrizi, M.H.N.; , "Development of usable and accessible Web-portals using W3C standards," Information Technology: Coding and Computing, 2005. ITCC 2005. International Conference on , vol.2, no., pp. 829- 831 Vol. 2, 4-6 April 2005 doi: 10.1109/ITCC.2005.129 [21] Mavridis, N.; Kazmi, W.; Toulis, P.; Ben-Abdelkader, C.; , "On the Synergies between Online Social Networking, Face Recognition and Interactive Robotics," Computational Aspects of Social Networks, 2009. CASON '09. International Conference on , vol., no., pp.48-56, 24-27 June 2009 doi: 10.1109/CASoN.2009.28 [22] Gjorgjevska, Katerina; Donev, Martin; , "Analysis of Healthcare Social Networking sites and applicability in Macedonian e-society," MIPRO, 2010 Proceedings of the 33rd International Convention , vol., no., pp.1142- 1147, 24-28 May 2010 [23] John A. Waterworth, Soledad Ballesteros, and Christian Peter. 2009. Usersensitive home-based systems for successful ageing. In Proceedings of the 2nd conference on Human System Interactions (HSI'09). IEEE Press, Piscataway, NJ, USA, 539-542. [24] Bellini, S.; Mambretti, C.; Mitseva, A.; Mamelli, A.; Barone, P.; Litke, A.; Papadakis, N.; Dafoulas, G.; , "An innovative platform to enhance the quality of life of people with mild dementia," Applied Sciences in Biomedical and Communication Technologies (ISABEL), 2010 3rd International Symposium on , vol., no., pp.1-8, 7-10 Nov. 2010 doi: 10.1109/ISABEL.2010.5702874 [25] Puscoci, S.; Stoicu-Tivadar, L.; Stoicu-Tivadar, V.; Berian, D.; Serbanescu, F.; Ionita, S.; Bajan, F.; , "Integrated teleassistance platform with enhanced accessibility to information - TELEASIS," Applied Computational Intelligence and Informatics (SACI), 2011 6th IEEE International Symposium on , vol., no., pp.577-582, 19-21 May 2011 doi: 10.1109/SACI.2011.5873069 [26] Mohan, S.; Eunmi Choi; Dugki Min; , "Conceptual Modeling of Enterprise Application System Using Social Networking and Web 2.0 “Social CRM System”," Convergence and Hybrid Information Technology, 2008. ICHIT '08. International Conference on , vol., no., pp.237-244, 28-30 Aug. 2008 doi: 10.1109/ICHIT.2008.263 29 ANEXOS 31 Anexo A. Trabajo previo A.1 Estado del arte redes sociales del ámbito de la salud La revolución que ha supuesto el despliegue de las redes sociales en Internet es un hecho innegable, siendo un componente principal de la denominada web 2.0. En la web 2.0, en lugar de un modelo en el que los contenidos son ofrecidos por un determinado proveedor, se potencia que éstos sean generados y mantenidos por los propios usuarios, fomentándose la participación y la interacción entre ellos. Esto ha provocado el establecimiento de auténticas comunidades virtuales que aglutinan miles de usuarios, en las cuales el valor está precisamente en las relaciones que se establecen entre ellos y en la información que intercambian. En general, las redes sociales permiten la creación de un perfil de usuario en el que publicar información acerca de nosotros y nuestros intereses, de forma que otros usuarios tienen la posibilidad de relacionarse con nosotros en base a intereses comunes. El éxito de una red social, además de los contenidos que albergue, depende en gran medida de los usuarios y de cómo estos se relacionan entre sí y propaguen las bondades de la plataforma. El ejemplo más notorio de red social lo encontramos en Facebook, que aglutina ya a más de 600 millones de usuarios en todo el mundo, bajo una temática de tipo general, pero hay otras redes también muy populares como Myspace, Last.fm o Spotify, en el ámbito musical, o Twitter, que se basa en la publicación de mensajes cortos para compartir qué estamos haciendo en cada momento. De temáticas específicas, destacan por su popularidad, Habbo o Tuenti, de orientación adolescente, Blogger o WordPress, de temática blogging, Delicious o Digg, redes de gestión de enlaces, Flickr o Picasa, para almacenar fotos on-line, YouTube, para publicar vídeos, LinkedIn y Xing, de temática profesional, Match.com o Meetic de citas… y la lista sería interminable. Asímismo, existen plataformas que pueden ser utilizadas para la creación de una red social personalizada. Entre estas plataformas se presentan dos tipos alternativas, plataformas cerradas (la gran mayoría de estas plataformas son de pago), que ofrecen una serie de funcionalidades concretas y plataformas de código abierto que son mantenidas por comunidades de desarrolladores, permitiendo además de las funcionalidades propias, el acceso a todos los recursos del proyecto (incluido el código) y permiten adaptar la plataforma a los requerimientos específicos con absoluta libertad. Entre las plataformas cerradas y de pago, caben destacar Get Satisfaction o Ning, y entre las plataformas gratuitas y open-source, cabe destacar Elgg. Los modelos de negocio para el mantenimiento de las redes sociales son de lo más diverso. La mayoría de redes permiten su uso de forma gratuita y se financian mediante la publicidad que insertan en sus páginas. Utilizando la información almacenada en los perfiles de los usuarios, la publicidad mostrada será acorde a su perfil. Otras redes ofrecen un acceso gratuito, pero requieren de un registro con una cuenta de pago para acceder a servicios más avanzados. Como ejemplo de este modelo de negocio se encuentra LinkedIn, que en la 32 modalidad de acceso gratuito te informa del acceso a tu perfil por parte de otros usuarios, pero se hace imprescindible una cuenta de pago para ser conocedor de las personas concretas que han accedido. Otras redes exigen una suscripción de pago para poder acceder y no ofrecen servicios gratuitos. Tal es el caso de las redes de citas como Match.com o Meetic. Otra forma de financiación es la venta directa de productos relacionados y merchandising. Finalmente, y sintetizando la información localizada en este documento, para la creación de una comunidad de usuarios en una red social, existen varias alternativas: utilización y personalización de una red social existente como Facebook, creación y personalización de una red social basándose en una plataforma existente como Ning, o la creación, personalización y modificación de una red social basándose en una plataforma existente de código abierto como Elgg. Redes Sociales de la Salud Por lo general, los sistemas existentes se limitan a aplicaciones específicas o centradas en una patología o discapacidad concreta. PatientsLikeMe permite a sus usuarios compartir tratamientos y síntomas de sus enfermedades con el fin de hacer un seguimiento y aprender de otros resultados médicos. Los pacientes que sufren estas enfermedades pueden conversar con otros, permitiéndoles compartir los avances en su recuperación a través de los datos de sus resultados, o hablar de técnicas específicas que les vayan bien. Los médicos e investigadores pueden consultar datos de los pacientes, como los tratamientos que han tomado, cuáles han sido satisfactorios médicamente y las sensaciones del paciente al seguirlos. Es un servicio gratuito para los usuarios, sin embargo, la web tiene ánimo de lucro ya que puede vender los datos de los usuarios a terceros como empresas farmacéuticas o compañías médicas. El número de usuarios crece cada día. A junio de 2011 hay 106.517 pacientes registrados en esta web. Adicionalmente, existen algunas redes sociales específicas del ámbito de la salud que se presentan brevemente a continuación:  Acor: Los pacientes de cáncer y trastornos relacionados, que buscan apoyo e información.  CureTogether: Los pacientes pueden apoyarse mutuamente, comparar síntomas, factores desencadenantes, tratamientos disponibles. Obtener ideas que poder comentar al médico, así como, conexión online con otras personas que trabajan en temas de salud, o que sufren la misma dolencia.  Forumclinic: Programa interactivo para pacientes, destinado a que aumenten su grado de autonomía con respecto a su salud.  Im too young for this: Específico para gente joven que sufre cáncer. Busca ayudar al millón de jóvenes que padecen cáncer en los Estados Unidos con herramientas sociales que les sean familiares.  RareShare: Pacientes, familias y profesionales sanitarios afectados por enfermedades raras. 33  Reliefinsite.com: Permite llevar un registro exhaustivo de cualquier tipo de dolor que se pueda sufrir, de cara a poder dar una información más precisa al médico que lleva el tratamiento.  WeAreBreathless.org: Quiere dar aliento a los enfermos crónicos de pulmón con enfisema, bronquitis crónica y asmas, que quieren compartir su experiencia y buscar personas con intereses y objetivos similares.  Www.Puedoser.es : Red social especializada en personas que sufren trastorno bipolar. Patrocinada por un laboratorio farmacéutico y en la que colabora de forma activa el Hospital Clínico de Barcelona.  Www.medhelp.com : La que se denomina la comunidad de salud más grande del mundo, ha conseguido que más de 1 millón de descargas de aplicaciones relacionadas con la salud. De una forma sencilla permite que sus usuarios comuniquen cómo se encuentran esa semana, cuánto han dormido o cuánto ejercicio han realizado. Proyectos con sistemas orientados a teleasistencia  REMOTE: Proyecto europeo (colaboración entre entidades y universidades griegas, españolas, israelíes, noruegas, belgas, rumanas, italianas y alemanas) que mezcla hardware y software en una arquitectura abierta (previsiblemente usando servicios web). Se desarrollan fundamentalmente soluciones de monitorización del paciente, así como análisis de los datos médicos del mismo.  OASIS: Proyecto europeo (colaboración entre empresas y universidades de distintos países, no sólo europeos) que define una arquitectura abierta para creación de servicios de e-health.  TELEASIS: Proyecto de diferentes universidades y entidades de Rumanía que ofrece teleasistencia a ancianos desde su casa, que permita el desarrollo de ayuda médica y servicios de teleasistencia en Rumanía, usando componentes hardware y software. Comparativa funcional de sistemas orientados a salud Acor Dirección web http://www.acor.org/ Propiedad Association of Cancer Online Resources, Inc Registro Libre Acceso Página web Tipos usuarios (roles) Pacientes (preguntan y responden dudas), moderadores de listas de correo (monitorizan y vigilan el buen uso del sistema) Foro No Mensajería Sí (listas de correos, no mensajería privada) Notificaciones No Actividades No Juegos No 40 Actividades No Juegos No Muro No Comentarios Es un sistema que ofrece teleasistencia a ancianos desde su casa, que permita el desarrollo de ayuda médica y servicios de teleasistencia en Rumanía, usando componentes hardware y software. Temática / Enfermedad Indeterminadas Procura Dirección web http://procurai3a.dyndns.org Propiedad AIJU- Centro Tecnológico del Juguete Flowlab Hospital Universitario Virgen del Rocío Solutio Universidad de Sevilla Universidad de Zaragoza Registro Bajo demanda (para pruebas iniciales, al menos). Controlado por algún administrador. Acceso Página web Tipos usuarios (roles) Sí (Paciente, Familiar, Cuidador, Profesional de salud (médico, psicoterapeuta, etc…)). Cada uno tiene funcionalidades específicas. Foro Sí (de ser necesario: plugin hypeForum o cualquier otro de los que ya hay disponibles) Mensajería Sí (de serie) Notificaciones Sí (de serie) Actividades Sí (módulo de tratamientos, por el momento) Juegos Sí (puede incluirse cualquiera ya disponible en Internet, con HTML o Javascript, o desarrollar algunos propios) Muro No (de serie está disponible, pero se ha desactivado. Si es necesario, puede activarse) Comentarios Es tan personalizable como queramos, con lo que pueden cubrirse todas las necesidades de todo tipo de pacientes, presentes y futuras. Temática / Enfermedad Alzheimer, Parkinson, ACV... ampliable en un futuro. A.2 Comparativa de plataformas de creación de redes sociales Se han analizado algunas de las alternativas que existen en la actualidad para crear una red social. 41 Elgg, software libre. Inspirado en xAMP (sistema operativo, Apache, MySQL y PHP), ofrece un completo pack para gestionar redes sociales. Con una comunidad de usuarios muy activa, puede personalizarse y extenderse indefinidamente, mediante plugins proporcionados por otros usuarios (miles disponibles) o mediante plugins diseñados a medida (permite acceso web por REST). Ning es un sistema de creación de redes sociales de pago. Provee una interfaz sencilla para personalizar la web, y ofrece alojamiento incluido en el precio. Sin embargo, la cantidad de temas diferentes es menor que Elgg, y sobre todo, no permite la personalización de plugins, fundamental para las necesidades de PROCURA. Diáspora es un servidor web libre que implementa una red social descentralizada y privada, como alternativa a Facebook y otras redes sociales con modelo centralizado. Se encuentra actualmente en desarrollo, su código fuente está en fase alpha. La documentación y grupo de discusión para desarrolladores se lanzó según se había programado el 15 de septiembre de 2010. Aquí, el usuario es quien mantiene el control sobre sus contenidos (manteniéndolos en su propio ordenador) a través de un sistema de pods. OpenSocial no es una red social por sí misma, sino un conjunto de API comunes destinadas a la creación de aplicaciones sociales en múltiples sitios web, de modo que los desarrolladores sólo tienen que aprender las API una vez para crear aplicaciones que funcionen con cualquier sitio web compatible con OpenSocial. Potenciada por Google, su mayor problema es que no ofrece conexión con las redes sociales mayoritarias (Facebook fundamentalmente) y que aún está en proceso de desarrollo. Get Satisfaction es un sistema de creación de redes sociales de pago, similar a Ning, especializado en soluciones simples para búsquedas rápidas de información, particularmente soporte técnico, tutoriales, etcétera. Igualmente, adolece de problemas de personalización e incapacidad de crear nuestros propios servicios en la plataforma de Procura. Selección previa Tras un análisis preliminar se han seleccionado las siguientes redes sociales para una comparativa en detalle: Elgg Tiene una comunidad de usuarios muy activa, puede personalizarse y extenderse indefinidamente, mediante plugins proporcionados por otros usuarios (miles disponibles) o mediante nuestros propios plugins (permite acceso web por REST). A nivel de desarrollo, ya que se instala en un equipo local (o en un servidor externo) es posibe modificar y extender lo que se desee. Visualmente, hay temas ya diseñados muy buenos, y pueden personalizarse (logos, combinaciones de colores, etc) mediante CSS estándar. La seguridad de la red depende de la del servidor en el que se encuentre, y por supuesto, de un cuidadoso testeo de las personalizaciones diseñadas. 42 Dispone de una licencia dual GPL-MIT (la mayor parte de plugins son GPL). La única desventaja es que es algo más compleja de utilizar (casi siempre, complejidad y personalización extrema van de la mano) y no incluye alojamiento, pero tras desarrollar la web en servidor local se puede pagar un alojamiento externo e incluirlo allí (la inmensa mayoría de servidores de hosting soportan LAMP, con Linux). De cara al rendimiento bajo altas cargas de trabajo, los tests realizados por los responsables de Elgg afirman que la caída de rendimiento es inapreciable hasta unos 100.000 usuarios, y siguen trabajando para mejorar las prestaciones bajo alta demanda de peticiones o elevado volumen de usuarios. Ning Es de pago (anteriormente era gratuito), con un coste de 35$ mensuales. Provee una interfaz sencilla para personalizar la web, y ofrece alojamiento incluido en el precio. Sin embargo, la cantidad de temas diferentes es menor que en Elgg, y sobre todo, no permite la personalización de plugins , fundamental para las necesidades de PROCURA (sólo permite elegir entre una lista cerrada proporcionada por la empresa). Algunos plugins extra son también de pago. En realidad, tiene una API RESTful, pero sólo permite funcionalidades muy restringidas. En cuanto a las posibilidades de futuro, pese a ser un proyecto veterano, estable, seguro y con buenas críticas, desde que decidieron abandonar el soporte a redes gratuitas, el número de usuarios no ha hecho más que decrecer, además de adolecer de un modelo propietario demasiado restrictivo con respecto a la competencia. Eso sí, los temas incluidos, pese a ser pocos, son de buena calidad. Diáspora Es aún experimental y su número de usuarios, relativamente reducido. Actualmente, permite conectar usando API de Facebook, Twitter y Tumblr. No especifica servicios web ni una API propia (probablemente sean aspectos que se incorporarán con el tiempo). En cuanto a seguridad, será la que proporcione el pod al que se una el usuario, sea propio o ajeno. Está programado con Ruby on Rails y distribuido bajo una doble licencia GPL-MIT. El coste de mantenimiento es nulo si se opta por el alojamiento en un pod externo que ofrezca alguno de los colaboradores, o el coste de un servidor externo si se decide desplegar el pod de forma autónoma. No parece haber grandes facilidades para crear temas, ni crear funcionalidades específicas para una red social concreta. Además, el triste fallecimiento reciente de uno de los programadores líderes del proyecto puede tener consecuencias en su desarrollo. Su instalación es compleja (es necesario descargar el código fuente de GitHub y compilarlo, etc) y no parece ser sencillo de gestionar. En resumen, es un proyecto interesante (por novedoso, sin control central de la información del usuario, con altísima escalabilidad...) pero aún muy inmaduro en todos los aspectos. Comparativa funcional Para evaluar las distintas plataformas, se han considerado los siguientes indicadores: 43  Evaluables Objetivamente o Actividad del proyecto (se define como se va a evaluar de forma objetiva la actividad: releases, descargas, modificaciones en el código en el último tiempo, cambios, usuarios, etc) o Comunicación con la red social (OpenSocial, servicios web, RPC, etc.) o Comunicación con otras redes sociales populares (Facebook, Twitter...) o Estabilidad del proyecto o Seguridad. o Licencia. o Coste de mantenimiento (servidor, etc) o Modularidad o Temas. o Nuevas funcionalidades o plugins.  Evaluables Subjetivamente o Calidad visual o Facilidad de gestión y mantenimiento. o Calidad de la documentación. Tablaresumen Elgg Ning Diáspora Actividad del proyecto Muy alta (gran comunidad de desarrolladores, posibilidad de adaptar plugins PHP de casi cualquier sitio) Media (escasez de desarrolladores, bajada importante de actividad tras el paso a ser de pago) Alta (una comunidad pequeña pero muy creciente de desarrolladores, aún está en fase alpha) Comunicaci ón con la red social Excelente (API completa RESTful, soporte para servicios web ilimitadamente personalizables) Baja (no podemos desarrollar nuestros plugins al gusto) Alta (incorporará funcionalidades de comunicación, pero aún no está plenamente desarrollada) Comunicaci ón con otras redes sociales populares Muy buena (módulos para manejar API de Facebook, Twitter, etc). Buena (OpenSocial, Facebook) Alta (incorporará funcionalidades de comunicación, pero aún no está plenamente desarrollada) Estabilidad Alta (sistema veterano extensamente probado y fiable) Muy alta (sistema veterano y red de servidores incorporada de pago) Baja (es una versión experimental aún, puede haber cambios importantes) 44 Seguridad Media: depende de la pericia del que desarrolla el sistema. Requerirá tests cuidadosos. Alta (incapacidad de tocar sistemas críticos para su funcionamiento) Baja (unión a pods hosteados por la comunidad), estructura descentralizada experimental. Licencia Gratuita (GPL-MIT) Propietaria Gratuita (GPL-MIT) Coste mantenimi ento Coste cero en la fase de desarrollo, coste de un hosting externo en la fase de producción. 35 $ / mes Coste cero en la fase de desarrollo, coste de un hosting externo en la fase de producción. Modularida d Muy alta (es una colección de plugins activables o desactivables a voluntad y necesidad del administrador) Muy baja (podemos activar unos pocos plugins disponibles de una lista cerrada) Alta (incorporamos las características que necesitamos, aún por desarrollar). Calidad visual Alta (por defecto bastante mala, pero hay muy buenos temas disponibles) Muy alta (excelentes temas por defecto, pero no muy personalizables). Mala (la mayor parte de pods se ven aún feos, lógico pues están aún probando funcionalidad más que estética) Gestión y mantenimi ento Media (requiere conocimientos de PHP, permite modificar la plataforma en todos los niveles.) Sencilla (todo a través de interfaz web amigable) Difícil (requiere compilar el código fuente del proyecto y lidiar con multitud de bugs aún presentes ya que se encuentra en fase alpha). Documenta ción Buena Buena Buena Selección de plataforma: Elgg Elgg es una plataforma de servicios de red social de código abierto que ofrece blogging, trabajo en red, comunidad, recolección de noticias vías feeds e intercambio de archivos, así como posibilidad de personalización sin límites. Todo puede ser compartido entre los usuarios, utilizando los controles de acceso y puede ser catalogado mediante tags (etiquetas). Ha estado en desarrollo desde 2004. El uso de Elgg no es muy habitual en estos proyectos de redes sociales, aunque hay alguna referencia [26] al respecto. 45 Dispone de una doble licencia GPL-MIT, y corre sobre la solution stack llamada xAMP (sistema operativo, Apache, MySQL y PHP). Los detalles pueden ser encontrados en la página web del proyecto. En agosto de 2008, Elgg fue nombrado como la mejor plataforma social de trabajo en red de código abierto por InfoWorld. Finalmente se consideró que este sistema es el más apropiado por muchas razones. La fundamental es que es la única que permite personalización absoluta de la red social, incluyendo funcionalidades que es probable que sean necesarias (módulos de tratamientos, medicación, aplicaciones para el paciente, quizá juegos sincronizables con Microsoft Kinect, etc). Por supuesto, el hecho de que sea software libre encaja también muy bien con la filosofía del proyecto y del grupo. Además, usa tecnologías estandarizadas, sólidas y extremadamente maduras, excelentemente documentadas en la red, y que cualquier servidor de hosting acepta sin problemas, además de que con ello se desarrollarán unos conocimientos y habilidades fácilmente reaprovechables en otros proyectos de ámbitos quizá totalmente diferentes. 47 Anexo B. Descripción ampliada de los perfiles de usuario Los perfiles principales quedan descritos a continuación: a) Paciente: Es aquella persona con alguna dolencia y que probablemente deba seguir un conjunto de tratamientos y medicación prescritos por un médico. En el ESdI desarrollado, padece Parkinson en estado más o menos avanzado. Se dividen en diferentes tipos: ‐ Pacientes de diagnóstico reciente o Persona de edad media 40 – 50 años o Problemas de movilidad y lentitud de movimientos o Poco conocimiento de la enfermedad, terapias y tratamientos. o Conoce las nuevas tecnologías. ‐ Pacientes moderadamente afectados o Persona de edad media avanzada 50 - 70 años o Problemas de movilidad y lentitud de movimientos o Problemas de autonomía. o Problemas comunicativos o Conocimiento de la enfermedad, terapias y tratamientos. o Limitaciones cognitivas leves ‐ Pacientes severamente afectados o Persona de edad avanzada 70 - 90 años o Dependiente. o Poco conocimiento de las nuevas tecnologías. o Dificultades comunicativas o Movilidad reducida. o Limitaciones cognitivas graves o Aislamiento b) Cuidadores: Pueden ser familiares o no, son aquellos que cuidan y conviven directamente con el enfermo (para aquellos casos en los que no son totalmente autónomos). La teleasistencia es capaz de paliar los casos más leves, pero en los estadios más avanzados de enfermedades neurodegenerativas sigue siendo fundamental la asistencia presencial. Algunos tipos: ‐ Pareja: o Personas de edad media-avanzada. o Limitaciones de movimiento. o Poco conocimiento de las nuevas tecnologías. 48 o Importante vinculo sentimental con el enfermo. ‐ Hijos: o Personas de edad comprendida entre 30 – 50 años o Conocimiento de las nuevas tecnologías. o Conocen directamente las necesidades del enfermo o Importante vinculo sentimental con el enfermo ‐ Cuidador: o Personas de edad comprendida entre 20 – 50 años o Conocimiento de las nuevas tecnologías. o Conocimientos sanitarios. o Conoce la enfermedad. o Conocen directamente las necesidades del enfermo. o Importante vínculo sentimental con el enfermo. c) Amigos y otros familiares: Usuarios dentro del círculo social del enfermo que no cuidan directamente de él directamente. ‐ Nietos / sobrinos: o Personas de edad comprendida hasta los 40 años o Nativos tecnológicos. o Importante vinculo sentimental con el enfermo. ‐ Otros familiares y amigos: o Importante vinculo sentimental con el enfermo. o Conocimientos básicos de la enfermedad o Pueden tener prejuicios que supongan un alejamiento del paciente d) Profesionales: Los hay de diversas profesiones: médicos, fisioterapeutas, terapeutas ocupacionales, trabajadores sociales, psicólogos y logopedas. En el ESdI desarrollado, se va a diferenciar entre médicos y el resto de profesionales, ya que los primeros desarrollan su labor en el hospital o centro de salud, y los segundos en la Asociación. Además, el seguimiento diario de los pacientes no es llevado a cabo por los médicos de forma habitual. ‐ Fisioterapeuta. o Contribuir a la consecución de una movilidad más cómoda y fácil en la actividad diaria, dentro de unos patrones motores correctos. o Al mismo tiempo, tratar de desarrollar estrategias para afrontar y/o superar las dificultades motoras. o Ayudar a la persona a mantenerse activa ‐ Logopedas. 49 o Contribuir a los trastornos en el habla, dificultades de pronunciación, inexpresividad facial, ritmo del habla acelerado, enlentecimiento del pensamiento, y trastornos de la deglución. ‐ Terapeuta ocupacional. o Establecer o rehabilitar capacidades perdidas, mejorar y/o mantener las actividades cotidianas o Adaptar el entorno a la persona, para mejorar su aumentando así su calidad de vida o Trabajando en todo momento con otros profesionales. ‐ Psicólogo. o Ayuda a los pacientes a superar trastornos del estado de ánimo, la ansiedad o la depresión. o La ayuda psicológica para los pacientes y los familiares. ‐ Atención social. o Información, orientación y asesoramiento a pacientes y familias cuidadoras. En general se caracterizan por: o Conocen profundamente la enfermedad (diagnostico, tratamiento y consecuencias) o Hacen seguimiento del paciente, sus tratamientos y terapias o Procuran mejorar la calidad de vida de los afectados y de su entorno. o Conocen el historial del paciente. o Conocen a otros pacientes. o Conocen a otros profesionales. o Poseen una visión global de la enfermedad e) Usuarios secundarios: ‐ Aseguradoras ‐ Asociaciones o Información acerca de la afectación, sus características, causas o Primeros consejos encaminados a la comprensión y aceptación de la nueva situación familiar y de salud del afectado. Toma de consciencia o Consejos sobre tratamientos sanitarios, de atención sociosanitaria, servicios disponibles o Apoyo psicológico profesional o Apoyo de grupo para afectado y su entorno, que se suele realizar de forma informal o Necesidad de información muy variable a lo largo del tiempo, dada la variabilidad de situaciones puntuales, y a la evolución en largo 56 los valores predeterminados para cada campo Nombre Visualizar perfil de usuario asignado a usuario Resumen Actores Propietario del perfil o cualquier otro usuario Precondiciones Flujo principal 1. El usuario que quiere visualizar el perfil, accede al perfil del usuario que quiere visualizar 2. La plataforma verifica los permisos de visualización de campos del perfil para el usuario, mostrando sólo aquellos que puede visualizar. 3. El usuario visualiza los valores de los campos del perfil que le estén permitidos. Resultado Nombre Modificar perfil de usuario asignado a usuario Resumen Actores Propietario del perfil o cualquier otro usuario Precondiciones Flujo principal 1. El usuario que quiere modificar el perfil, accede al perfil del usuario que quiere modificar 2. La plataforma verifica los permisos de visualización y edición de campos del perfil para el usuario, mostrando sólo aquellos que puede visualizar, y permitiendo la modificación de sólo aquellos que puede modificar. 3. El usuario modifica los valores de los campos del perfil que quiera modificar y le estén permitidos. Resultado El perfil de usuario queda modificado 57 Relacionesdeusuario Nombre Definir relaciones Resumen Actores Configurador PT7, Administrador Precondiciones Flujo principal 1. El configurador/administrador accede a la configuración del módulo de relaciones 2. El configurador/administrador define las relaciones permitidas (alta/baja/modificación) Resultado Quedan registradas en la plataforma las relaciones que se pueden establecer entre usuarios Nombre Configurar las relaciones que puede establecer cada perfil Resumen Actores Configurador PT7, Administrador Precondiciones Flujo principal 1. El configurador/administrador accede a la configuración del módulo de relaciones 2. El configurador/administrador accede al perfil de usuario para el que quiere establecer las relaciones 3. El configurador/administrador configura (alta/baja) las relaciones que pueden establecer los usuarios que tienen asignado ese perfil 58 Resultado Quedan registradas en la plataforma las relaciones que puede establecer el perfil de usuario Nombre Crear relación con otro usuario Resumen Actores Usuario Precondiciones Flujo principal 1. El usuario accede a la configuración de sus relaciones con otro usuario 2. El usuario selecciona el otro usuario con el que quiere establecer una relación 3. El usuario establece la relación con el otro usuario de entre las relaciones que tiene permitido establecer Flujo alternativo 1. El usuario está visualizando un contenido asociado a un usuario con el que quiere establecer una relación 2. El usuario establece la relación con el otro usuario de entre las relaciones que tiene permitido establecer Resultado Quedan registrada en la plataforma la relación entre los dos usuarios Nombre Borrar relación con otro usuario Resumen Actores Usuario Precondiciones Flujo principal 1. El usuario accede a la configuración de sus relaciones con otro usuario 2. El usuario selecciona el otro usuario con el que quiere eliminar la relación 3. El usuario elimina la relación con el otro usuario de entre las relaciones que tiene permitido establecer Flujo alternativo 1. El usuario está visualizando un contenido asociado a un usuario con el que quiere establecer una relación 2. El usuario elimina la relación con el otro usuario de entre las relaciones que tiene permitido establecer Resultado Quedan eliminada de la plataforma la relación entre los dos usuarios Nombre Crear relación Resumen Actores Administrador Precondiciones Flujo principal 1. El administrador accede a la configuración de relaciones del usuario al que quiere establecer la relación con otro usuario 2. El administrador selecciona el otro usuario con el que quiere establecer una relación 59 3. El administrador establece la relación con el otro usuario Resultado Quedan registrada en la plataforma la relación entre los dos usuarios Nombre Borrar relación Resumen Actores Administrador Precondiciones Flujo principal 1. El administrador accede a la configuración de relaciones del usuario al que quiere eliminar una relación con otro usuario 2. El administrador elimina la relación con el otro usuario que quiere eliminar Resultado Quedan eliminada de la plataforma la relación entre los dos usuarios Permisos Nombre Registrar acciones privilegiadas del módulo Resumen Da de alta las acciones del módulo que requieren control de permisos Actores Sistema Precondiciones Flujo principal 1. El administrador activa el módulo 2. El modulo solicita al módulo de permisos el registro de todas las acciones privilegiadas 3. El módulo de permisos comprueba si ya están dadas de alta las acciones (por una activación anterior) a. Si no están dadas de alta, las registra 60 b. Si ya están dadas de alta, únicamente registra las nuevas (si las hubiera) Resultado El módulo de permisos tiene registradas todas las acciones privilegiadas del módulo, pudiéndose establecer los privilegios en función del perfil y las relaciones Nombre Eliminar acciones privilegiadas del módulo Resumen Da de baja las acciones del módulo que requieren control de permisos Actores Sistema Precondiciones Flujo principal 1. El administrador desactiva el módulo 2. El modulo solicita al módulo de permisos que elimine las acciones registradas por el módulo 3. El módulo de premisos solicita confirmación al administrador para borrar las acciones registradas, advirtiéndole de que perderá la configuración a. Si el administrador contesta afirmativamente, borra las acciones registradas b. Si dice que no, no hace nada, quedando disponibles las acciones para una reactivación posterior del módulo Resultado Las acciones del módulo dejan de estar registradas en la plataforma, si se vuelve activar el módulo, sería necesario volver a registrarlas y configurarlas, o quedan disponibles para una reactivación del módulo. Nombre Configurar privilegios de acciones Resumen Configura los privilegios necesarios para poder realizar una acción Actores Administrador, configurador PT7 Precondiciones Acciones del módulo registradas, módulo activo Flujo principal 1. El administrador accede a la configuración del módulo de permisos, y selecciona privilegios de acciones, y el módulo cuyas acciones le interese configurar 2. El administrador establece para cada acción del módulo:  Perfiles de usuario que pueden ejecutar esa acción (eligiéndolos de los perfiles registrados). Si no establece ningún perfil, no se establece ningún requisito de perfil de usuario para ejecutar la acción, con lo que cualquier usuario podría realizarla independientemente de su perfil (siempre y cuando cumpla el resto de requisitos si los hubiera)  Para las acciones que tienen un efecto sobre un usuario objetivo, los tipos de relación que puede (debe) tener el usuario que realiza la acción con el usuario objetivo para que se autorice la ejecución (eligiéndolos de los tipos de relaciones registrados). Si no se establece ningún tipo de relación, no se establece ningún requisito de 61 relaciones con el usuario objetivo, por lo que cualquier usuario podría realizar la acción independientemente de que tenga o no relación con el usuario objetivo (siempre y cuando cumpla el resto de requisitos si los hubiera). En las acciones que no declaran un tipo objetivo, no se establecen relaciones requeridas. Resultado Quedan configurados los privilegios que definen los requisitos que deben verificar los usuarios para poder realizar una acción, tanto a nivel de perfil requerido como a nivel de relaciones requeridas con el usuario objetivo de cada acción (si lo hubiera). Modelo de datos Perfildeusuario El modelo de datos para soportar los perfiles de usuario es el siguiente: El modelo de datos se basa en las siguientes tablas:  Perfiles: Enumera cuales son los perfiles contemplados en la plataforma (medico, paciente, etc.)  Campos: Determina cuales son los campos que almacenan información del usuario. Los campos que corresponden a cada perfil se establecen con la tabla CamposPerfil (que relaciona las tablas Perfiles y Campos), mientras que el perfil al que corresponde cada usuario se establece con la tabla PerfilesUsuario (que relaciona la tabla de perfiles con la tabla de usuarios general de la plataforma). Los valores concretos de los campos del perfil de un usuario determinado se establecen en la tabla CamposPerfilUsuario. Por otra parte, la tabla PermisosPerfil (que relaciona la tabla Campos con la tabla Perfiles) establece qué perfiles de usuario tienen capacidad para visualizar/editar cada campo, mientras que la tabla PermisosRelacion (que relaciona la tabla Campos con la tabla TiposRelaciones) establece además las relaciones que tiene que tener el usuario que accede al campo con el propietario del campo. 62 Dejando a un lado los campos que actúan como clave primaria de las tablas, y que no requieren mayor explicación, para el resto de campos tenemos:  Tabla Perfiles: o NombrePerfil: valor textual que describe el perfil.  Tabla Campos: o NombreCampo: nombre del campo o TipoValor: Tipo de valor del campo (numérico, texto, booleano, lista de valores…) o ValoresPosibles: establece los valores admitidos en el campo (para el caso de lista de valores) o ValorPredeterminado: establece cual es el valor predeterminado del campo, que se utiliza para inicializar un perfil de usuario o BloquearAlPropietario: establece si el campo es de sólo lectura para el propietario del perfil, con lo que no podrá modificarlo. Por defecto será FALSE, con lo que el usuario podrá modificar el campo. o OcultarAlPropietario: establece si el campo está oculto al propietario del perfil, con lo cual no tendrá acceso al mismo. Por defecto será FALSE, con lo que el usuario tendrá acceso al campo. o Publico: establece que cualquier usuario, independientemente de su perfil y de las relaciones que tenga establecidas con el propietario del perfil, podrá visualizar ese campo  Tabla CamposPerfilUsuario: o ValorCampo: almacena el valor del campo del perfil del usuario, de acuerdo al tipo de valor y a los valores admitidos en la tabla Campos.  Tabla PermisosPerfil: o ReadOnly: establece que aunque el usuario tenga un perfil apropiado para visualizar el campo, no podrá modificarlo (por defecto es FALSE).  Tabla PermisosRelacion: o ReadOnly: establece que aunque el usuario tenga una relación apropiada con el propietario del perfil para visualizar el campo, no podrá modificarlo (por defecto es FALSE). Reglas de funcionamiento y verificación  El administrador de la plataforma es el único que puede establecer: o Tipos de perfiles o Campos de perfiles o Campos que corresponden a un perfil o Perfiles que pueden acceder a un campo o Relaciones requeridas para acceder a un campo o Perfil que corresponde a cada usuario  NO se permite eliminar un perfil de usuario si algún usuario tiene asignado a ese perfil. Previamente debe asignarse un perfil nuevo a los usuario afectados 63  Al asignar un perfil a un usuario, se inicializan los campos del perfil con los valores predeterminados  Si se modifica un campo (de la tabla Campos), los usuarios que tengan el perfil al que corresponde el campo verán el valor del campo inicializado al valor predeterminado. En el caso de que la modificación implique un cambio de perfil, se inicializará el valor del campo en los usuarios que tengan el perfil nuevo, y se borrará en los usuarios que tuvieran el valor nuevo. Esto mismo se aplica en el caso de eliminar un campo.  Dado un perfil de usuario: o El propietario del perfil puede visualizar el valor de todos los campos que no estén ocultos al propietario, y puede modificar el valor de todos los campos que no estén bloqueados al propietario. o El administrador de la plataforma tiene acceso de lectura y escritura a todos los campos. o Un usuario podrá visualizar un campo de un perfil de otro usuario, si:  El campo es público, o  Su perfil coincide con uno de los recogidos en la tabla PermisosPerfil para el campo correspondiente, y  Si la tabla PermisosRelaciones tiene registrada una o más tipos de relación para ese campo, el usuario tiene establecida una relación con el propietario del perfil que coincida con alguna de las establecidas en esa tabla, o  El campo no tiene establecidas restricciones en cuanto a las relaciones requeridas o Un usuario podrá o un campo de un perfil de otro usuario si:  Su perfil coincide con uno de los recogidos en la tabla PermisosPerfil para el campo correspondiente, y no está marcado como ReadOnly, y  Si la tabla PermisosRelaciones tiene registrada una o más tipos de relación para ese campo, el usuario tiene establecida una relación con el propietario del perfil que coincida con alguna de las establecidas en esa tabla y no esté marcada como ReadOnly, o  El campo no tiene establecidas restricciones en cuanto a las relaciones requeridas  Respecto a los perfiles y relaciones necesarios para poder editar un campo, es deseable un procedimiento de verificación que asegure que un campo es editable/visualizable por algún usuario. Relacionesdeusuario El modelo de datos para soportar las relaciones entre usuarios es el siguiente: 64 TiposRelaciones PK idRelacion Nombre Descripcion Relaciones PK,FK2 idUsuario1 PK,FK3 idUsuario2 PK,FK1 idRelacion Usuarios PK idUsuario NombreUsuario Otroscampos Perfiles PK idPerfil NombrePerfil PerfilesTipoRelacion PK,FK1 idRelacion PK,FK2 idPerfil El modelo de datos se basa en las siguientes tablas:  TiposRelaciones: Enumera cuales son los tipos de relación contemplados en la plataforma (medico-paciente, familiar-paciente, etc.)  Relaciones: Determina cuales son las relaciones que tiene un usuario con otro usuario.  PerfilesTipoRelacion: Define para cada tipo de relación, cuales son los perfiles que pueden establecerlas. Dejando a un lado los campos que actúan como clave primaria de las tablas, y que no requieren mayor explicación, para el resto de campos tenemos:  Tabla TiposRelaciones: o Nombre: valor textual que describe la relación o Descripción: Descripción ampliada de la relación. Reglas de funcionamiento y verificación  El administrador puede establecer relaciones de cualquier tipo entre dos usuarios cualesquiera.  Un usuario puede establecer (o elimina) una relación de un tipo dado con otro usuario, sólo si su perfil de usuario corresponde con uno de los registrados en la tabla PerfilesTipoRelacion para el tipo de relación de interés (un cambio en el perfil del usuario implicaría la perdida de privilegios para establecer relaciones). Nota: puede ser necesario limitar entre qué perfiles pueden establecerse las relaciones, lo cual requeriría un modelo algo más complejo, incluyendo otra tabla que registre esos perfiles. Sin embargo, aunque se añadiría una capa de control, la complejidad tanto de gestión como de programación puede no hacer aconsejable ampliar el modelo. Permisos El modelo de datos para soportar las relaciones entre usuarios es el siguiente: 65 El modelo de datos se basa en las siguientes tablas:  Módulos: Registra los módulos de la plataforma que están contemplados por el modelo de permisos (tratamientos, mensajería…)  AccionesModulos: Registra cuales son las acciones de cada módulo sometidas al control de permisos.  PerfilesUsuarioAccion: Define para cada acción, los perfiles de usuario requeridos para poder realizarla.  TiposRelacionesAccion: Para las acciones que tengan efecto sobre un usuario, recoge los tipos de relación que debe mantener el usuario que realiza la acción con el usuario objetivo. Dejando a un lado los campos que actúan como clave primaria de las tablas, y que no requieren mayor explicación, para el resto de campos tenemos:  Tabla Módulos: o NombreModulo: valor identificativo del módulo.  Tabla AccionesModulos: o NombreAccion: nombre identificativo de la acción o idModulo: Modulo al que pertenece la acción o RequiereRelacion: Indica que la acción a realizar se aplicará sobre un usuario, para lo cual se requiere que el usuario que intenta ejecutar la acción tenga una relación con el usuario sobre el que se aplica (ejemplo: asignar tratamiento). Por defecto es FALSE. o RequierePropietario: Indica que la acción a realizar se aplicará sobre un contenido, para lo cual se requiere que el usuario que intenta ejecutar la acción sea el propietario del contenido sobre el cual se intenta aplicar (ejemplo: modificar plantilla de tratamiento). Por defecto es FALSE. o Descripción: Descripción ampliada de la relación. Reglas de funcionamiento y verificación  El administrador es el único que puede establecer cuales son los permisos requeridos para cada acción. 72 Realizacióntratamientos Prescriptor Paciente Medico Plataformaprocura Realizar tratamiento Visualizar evaluaciondetratamiento Comentarevaluacion detratamiento «uses» Evaluarrealizacion detratamiento Marcartratamiento norealizado Sistema Notificar evaluacionpendiente Nombre Realizar tratamiento Resumen Actores Paciente Precondiciones El tratamiento está asignado al paciente Flujo principal 1. El usuario accede a la plataforma 2. Visualiza los tratamientos que tiene asignados, junto con siguiente fecha programada de realización 3. Selecciona el tratamiento a realizar 4. Realiza el tratamiento, mientras la plataforma recopila información asociada a la realización del tratamiento (tiempo de realización, videos del usuario, información capturada sobre ejercicios físicos…13) 5. Marca el tratamiento como realizado, proporcionando una evaluación sobre el tratamiento Resultado En la base de datos se crea una instancia de realización de tratamiento en estado REALIZADO asociado al tratamiento asignado, en la fecha actual, con la evaluación proporcionada por el paciente y la información recopilada por la plataforma, y listo para ser evaluado por el prescriptor Nombre Marcar tratamiento no realizado Resumen Actores Sistema Precondiciones Paciente con tratamiento asignado Flujo principal 1. De forma periódica, el sistema analiza los tratamientos asignados a cada paciente 2. Para cada tratamiento asignado, comprueba que se haya realizado el tratamiento en el periodo 13 La información sobre la realización del ejercicio dependerá de las capacidades del módulo cliente, se considera que es algo que variará con las sucesivas iteraciones del proyecto. 73 correspondiente 3. Si no se ha realizado el tratamiento, crea una marca de tratamiento no realizado, tras lo cual no se indicará al usuario que deba realizar el tratamiento en la programación vencida, sino en la siguiente (saltando una realización) Resultado En la base de datos se crea una instancia de realización de tratamiento en estado NO REALIZADO asociada al tratamiento asignado, en la fecha en que debería haberse realizado el tratamiento, y listo para ser evaluado por el prescriptor Nombre Evaluar tratamiento Resumen Actores Prescriptor Precondiciones El tratamiento asignado tiene realizaciones pendientes de evaluar Flujo principal 1. El prescriptor accede a la plataforma 2. Selecciona el usuario para ver los tratamientos asignados 3. Entre los tratamientos asignados, selecciona aquel que quiere evaluar, que tiene realizaciones pendientes de evaluar 4. Visualiza la realización del tratamiento y la evaluación proporcionada por el paciente 5. Proporciona su evaluación respecto a la realización visualizada Resultado En la base de datos se actualiza la instancia de realización de tratamiento con la evaluación proporcionada por el prescriptor Nombre Notificar evaluación pendiente Resumen Actores Sistema Precondiciones Prescriptor con tratamientos asignados pendientes de evaluar Flujo principal 1. De forma periódica, el sistema analiza los tratamientos asignados por cada prescriptor 2. Para cada tratamiento asignado, comprueba si se han registrado realizaciones del tratamiento por parte del paciente, que estén pendientes de evaluar. 3. Para cada realización pendiente de evaluar con anterioridad a una semana14, se notifica al prescriptor de que debe realizar la evaluación de las realizaciones pendientes. Resultado Se envía un mensaje al prescriptor indicando que tiene evaluaciones pendientes, con un link a cada realización de tratamiento pendiente de evaluar. Nombre Visualizar evaluación de tratamiento Resumen 14 Este tiempo puede ser modificado en la configuración del módulo 74 Actores Prescriptor, medico Precondiciones Tener una relación con el paciente Flujo principal 1. El usuario accede a la plataforma 2. Selecciona el usuario sobre el que quiere revisar los tratamientos 3. Selecciona el tratamiento que quiere revisar 4. Visualiza la evaluación introducida por el prescriptor en la realización del tratamiento Resultado Nombre Comentar evaluación de tratamiento Resumen Actores Prescriptor, medico Precondiciones Tener una relación con el paciente Flujo principal 1. El usuario accede a la plataforma 2. Selecciona el usuario sobre el que quiere revisar los tratamientos 3. Selecciona el tratamiento que quiere revisar 4. Visualiza la evaluación introducida por el prescriptor en la realización del tratamiento 5. Visualiza los comentarios añadidos a la evaluación 6. Añade un comentario Resultado Se crea un comentario asociado a la evaluación del tratamiento Configuracióndelmódulodetratamientos Administrador Plataformaprocura Configurarusode SCORM Gestionarcategorías detratamientos Gestionar parámetrosdeevaluación Nombre Configurar uso de SCORM Resumen Actores Administrador 75 Precondiciones El módulo de SCORM debe estar activado Flujo principal 1. El administrador accede a la configuración de la plataforma, y selecciona la configuración del módulo de tratamientos 2. Se establece si se va a utilizar SCORM, y en ese caso, se indica la APIKEY necesaria para acceder a los cursos Resultado El módulo de Tratamientos queda configurado para poder acceder a los cursos de SCORM e incluirlos en los tratamientos Nombre Gestionar categorías de tratamientos Resumen Actores Administrador Precondiciones Flujo principal 1. El administrador accede a la configuración de la plataforma, y selecciona la configuración del módulo de tratamientos 2. El administrador establece las categorías (etiquetas) a utilizar por los tratamientos definidos en la plataforma. Si se elimina o se modifica una categoría ya asignada a un tratamiento o plantilla de tratamiento, esta se actualiza en todas las entidades que hacen referencia (eliminándola o actualizándola según sea el caso) Resultado El módulo de tratamientos queda configurado con las categorías que pueden asignarse a los tratamientos Nombre Gestionar parámetros de evaluación Resumen Actores Administrador Precondiciones Flujo principal 1. El administrador accede a la configuración de la plataforma, y selecciona la configuración del módulo de tratamientos 2. El administrador establece los parámetros a usar en la evaluación, indicando para cada uno de ellos: parámetro, tipo de parámetro (booleano, numérico, lista de valores, texto), posibles valores (en el caso de tipo = listas de valores) y si la evaluación corresponde al usuario o al prescriptor. Si se elimina un parámetro de evaluación o se hace una modificación de los valores admitidos, éste se eliminará de todos los tratamientos evaluados, por lo que no se recomienda hacer cambios una vez que ya hay tratamientos evaluados. Resultado El módulo de tratamientos queda configurado con los parámetros de evaluación que se deben utilizar en la realización de tratamientos. Modelo de datos módulo Tratamientos Se contemplan las siguientes entidades: 76 PlantillaTratamiento Tratamiento Realizacion tratamiento Programacion Tratamiento 11 Evaluacion ParametroEvaluacion 11 1 * Comentario 1 *1 * Las clases principales del modelo de datos son:  PlantillaTratamiento se refiere a un tratamiento tipo definido por un terapeuta, que sirve como base para asignar tratamientos personalizados a los pacientes  Tratamiento define el tratamiento personalizado asignado a un paciente, que contiene todos los atributos incluidos en PlantillaTratamiento, permitiendo su personalización al paciente concreto, más los campos asociados al tratamiento específico, como la programación y las realizaciones  Programación define cuando tiene que realizar el tratamiento el paciente15.  RealizacionTratamiento define las realizaciones del tratamiento por parte del paciente, permitiendo el seguimiento y la evaluación  Evaluacion define un conjunto de parámetros para evaluar, los cuales son de tipo ParametroEvaluacion Los comentarios se adecuarían al modelo de comentarios en Elgg. 15 Aunque podría estar incluido en la definición de Tratamiento, se considera como un elemento aparte, ya que la realización natural sería un evento de calendario conforme al estándar icalendar, pero la implementación podría ser costosa, por lo que se simplifica con una definición de tipo sencillo. 77 DetalledeClases Plantilla Tratamiento Nombre Tipo Descripción Titulo Texto Nombre del tratamiento Cuerpo Texto con formato Define el contenido del tratamiento, qué es lo que debe realizar el paciente Categoría Lista de palabras clave (tag) Permiten establecer una organización del tratamiento. Las tags que se pueden asignar se establecen en la configuración del módulo por parte del administrador SCORM Identificador de curso Identificador de curso SCORM relacionado con el tratamiento. Requiere que esté instalado el módulo SCORM que facilita el acceso a los cursos (identificación y ejecución/visualización). Además, debe estar habilitado en la configuración del módulo de tratamientos Video Identificador video Youtube Identificador de un video Youtube que permite proporcionar instrucciones adicionales sobre la realización del tratamiento. Necesario un módulo que permita acceder a un sistema de video (YouTube), e idealmente que permitiera cargar videos. Misma consideración que el módulo de SCORM, en cuanto a habilitación del campo Audio Indicador de archivo de audio Misma consideración que el video, pero con archivos de audio Propietario Identificador de usuario Registra quien es el usuario que ha creado la plantilla Archivado Booleano Indicador de objeto archivado (no visible) 78 Tratamiento Nombre Tipo Descripción Prescriptor Identificador usuario Registra quien es el usuario que ha prescrito el tratamiento Paciente Identificador usuario Registra quien es el usuario al que se le ha prescrito el tratamiento Fecha Asignación Fecha Fecha de prescripción del tratamiento, cuando el prescriptor lo asigna al paciente Programación Programación Registra cuando debe realizarse el tratamiento por parte del paciente Visualizado Booleano Registra si el usuario ha visualizado el tratamiento Realizaciones Realización [*] Registro (vector) de realizaciones del tratamiento por parte del usuario Comentarios Comentario16 Cadena de comentarios realizados sobre el tratamiento Archivado Booleano Indicador de objeto archivado (no visible) Programación Tratamiento Nombre Tipo Descripción Fecha Inicio Fecha Establece la fecha de inicio del tratamiento Fecha Fin Fecha Establecer la fecha de finalización del tratamiento Periodicidad Numérico Define el intervalo de periodicidad del tratamiento Tipo Periodicidad Tipo enumerado:  Días  Semanas Define las unidades para la periodicidad. Conjuntamente con la periodicidad define cada cuanto tiempo se tiene que realizar el tratamiento, desde la fecha de inicio hasta la fecha de finalización 16 Dependiente de Elgg 79 Realización Tratamiento Nombre Tipo Descripción Fecha Realización Fecha Registra la fecha en la que el paciente ha realizado el ejercicio Evaluación Paciente Evaluación [*] Registra la evaluación del ejercicio por parte el paciente (vector con los parámetros de evaluación establecidos en la configuración del módulo para el tipo paciente) Fecha Evaluación Fecha Establecer la fecha de finalización del tratamiento Evaluación Prescriptor Evaluación [*] Registra la evaluación del ejercicio por parte el prescriptor (vector con los parámetros de evaluación establecidos en la configuración del módulo para el tipo prescriptor) NoRealizado Booleano Indicador de ejercicio no realizado (cuando un ejercicio no se realiza en el plazo establecido, se crea una instancia de ejercicio realizado con este indicador marcado) Evaluación Tratamiento Nombre Tipo Descripción Parámetro Texto Nombre del parámetro de evaluación Tipo Parámetro Parámetro evaluación Tipo de parámetro de evaluación Valor Texto Valor de la evaluación, se debe corresponder con los valores admitidos por el parámetro Parámetro Evaluación Tratamiento Nombre Tipo Descripción TipoParametro Texto Nombre del tipo de parámetro para la evaluación TipoValores Tipo enumerado:  Texto  Booleano  Numérico  Lista Tipo de valor para el parámetro de evaluación Valores Lista de valores Valores admitidos, cuando el TipoValor es lista de valores Paciente Booleano Indicador para marcar que el parámetro corresponde a la evaluación por parte del paciente Prescriptor Booleano Indicador para marcar que el parámetro corresponde a la evaluación por parte del prescriptor17 17 Si un parámetro corresponde al paciente y al prescriptor, deberá ser evaluado por ambos. 81 Anexo D. Distribución temporal del proyecto Este anexo tiene por objetivo explicar cómo se ha distribuido el tiempo para llevar a cabo cada una de las distintas partes de este TFM. Comienza en noviembre de 2011 y finaliza en septiembre de 2012. En la página siguiente se muestra el Diagrama de Gantt donde se reflejan las diferentes tareas realizadas y el tiempo dedicado al desarrollo de cada una de ellas. La primera tarea a realizar fue el estudio del estado del arte y comparativa de plataformas disponibles para creación de redes sociales. Ello era necesario como investigación básica sobre el asunto y porque elegir una plataforma u otra condiciona completamente el resto de tareas a realizar (facilitándolas o imposibilitándolas completamente). Tras ello, se hizo una primera descarga del framework de Elgg y se realizaron las primeras pruebas de instalación, modificaciones sencillas de plugins y apariencia, etc. para irse familiarizando con el entorno. Posteriormente vino el desarrollo de los módulos principales, que son lo que más tiempo ha costado (con sus múltiples refinamientos, añadidos y cambios, evidentemente). Del resto de módulos, sólo se comentan los que por su naturaleza costaron más (había que desarrollarlos casi desde cero, no eran modificaciones sencillas de otros). Las pruebas de implantación y evaluación quedaron en unas pruebas sencillas en servidores externos por falta de tiempo para reunirse en persona con miembros de la Asociación, quedando pendientes para dentro de poco tiempo. La memoria del TFM, por último, se fue realizando a lo largo de todo el proceso de desarrollo. El único punto que quizá requiere una explicación adicional es el de “Plenaria Procura”. Fue una reunión de dos días de duración en las instalaciones de la Asociación de Parkinson de Aragón así como en las del I3A, en la que nos dimos cita representantes de las distintas entidades que trabajan en el proyecto junto con personal de la propia asociación. Ello sirvió para afinar los requisitos necesarios de la plataforma, así como tener un contacto de primera mano con la problemática específica de la asociación. 88 Installation Information. But this requirement does not apply if neither you nor any third party retains the ability to install modified object code on the User Product (for example, the work has been installed in ROM). The requirement to provide Installation Information does not include a requirement to continue to provide support service, warranty, or updates for a work that has been modified or installed by the recipient, or for the User Product in which it has been modified or installed. Access to a network may be denied when the modification itself materially and adversely affects the operation of the network or violates the rules and protocols for communication across the network. Corresponding Source conveyed, and Installation Information provided, in accord with this section must be in a format that is publicly documented (and with an implementation available to the public in source code form), and must require no special password or key for unpacking, reading or copying. 7. Additional Terms. “Additional permissions” are terms that supplement the terms of this License by making exceptions from one or more of its conditions. Additional permissions that are applicable to the entire Program shall be treated as though they were included in this License, to the extent that they are valid under applicable law. If additional permissions apply only to part of the Program, that part may be used separately under those permissions, but the entire Program remains governed by this License without regard to the additional permissions. When you convey a copy of a covered work, you may at your option remove any additional permissions from that copy, or from any part of it. (Additional permissions may be written to require their own removal in certain cases when you modify the work.) You may place additional permissions on material, added by you to a covered work, for which you have or can give appropriate copyright permission. Notwithstanding any other provision of this License, for material you add to a covered work, you may (if authorized by the copyright holders of that material) supplement the terms of this License with terms:  a) Disclaiming warranty or limiting liability differently from the terms of sections 15 and 16 of this License; or  b) Requiring preservation of specified reasonable legal notices or author attributions in that material or in the Appropriate Legal Notices displayed by works containing it; or  c) Prohibiting misrepresentation of the origin of that material, or requiring that modified versions of such material be marked in reasonable ways as different from the original version; or  d) Limiting the use for publicity purposes of names of licensors or authors of the material; or  e) Declining to grant rights under trademark law for use of some trade names, trademarks, or service marks; or  f) Requiring indemnification of licensors and authors of that material by anyone who conveys the material (or modified versions of it) with contractual assumptions of liability to the recipient, for any liability that these contractual assumptions directly impose on those licensors and authors. All other non-permissive additional terms are considered “further restrictions” within the meaning of section 10. If the Program as you received it, or any part of it, contains a notice stating that it is governed by this License along with a term that is a 89 further restriction, you may remove that term. If a license document contains a further restriction but permits relicensing or conveying under this License, you may add to a covered work material governed by the terms of that license document, provided that the further restriction does not survive such relicensing or conveying. If you add terms to a covered work in accord with this section, you must place, in the relevant source files, a statement of the additional terms that apply to those files, or a notice indicating where to find the applicable terms. Additional terms, permissive or non-permissive, may be stated in the form of a separately written license, or stated as exceptions; the above requirements apply either way. 8. Termination. You may not propagate or modify a covered work except as expressly provided under this License. Any attempt otherwise to propagate or modify it is void, and will automatically terminate your rights under this License (including any patent licenses granted under the third paragraph of section 11). However, if you cease all violation of this License, then your license from a particular copyright holder is reinstated (a) provisionally, unless and until the copyright holder explicitly and finally terminates your license, and (b) permanently, if the copyright holder fails to notify you of the violation by some reasonable means prior to 60 days after the cessation. Moreover, your license from a particular copyright holder is reinstated permanently if the copyright holder notifies you of the violation by some reasonable means, this is the first time you have received notice of violation of this License (for any work) from that copyright holder, and you cure the violation prior to 30 days after your receipt of the notice. Termination of your rights under this section does not terminate the licenses of parties who have received copies or rights from you under this License. If your rights have been terminated and not permanently reinstated, you do not qualify to receive new licenses for the same material under section 10. 9. Acceptance Not Required for Having Copies. You are not required to accept this License in order to receive or run a copy of the Program. Ancillary propagation of a covered work occurring solely as a consequence of using peer-to-peer transmission to receive a copy likewise does not require acceptance. However, nothing other than this License grants you permission to propagate or modify any covered work. These actions infringe copyright if you do not accept this License. Therefore, by modifying or propagating a covered work, you indicate your acceptance of this License to do so. 10. Automatic Licensing of Downstream Recipients. Each time you convey a covered work, the recipient automatically receives a license from the original licensors, to run, modify and propagate that work, subject to this License. You are not responsible for enforcing compliance by third parties with this License. 90 An “entity transaction” is a transaction transferring control of an organization, or substantially all assets of one, or subdividing an organization, or merging organizations. If propagation of a covered work results from an entity transaction, each party to that transaction who receives a copy of the work also receives whatever licenses to the work the party's predecessor in interest had or could give under the previous paragraph, plus a right to possession of the Corresponding Source of the work from the predecessor in interest, if the predecessor has it or can get it with reasonable efforts. You may not impose any further restrictions on the exercise of the rights granted or affirmed under this License. For example, you may not impose a license fee, royalty, or other charge for exercise of rights granted under this License, and you may not initiate litigation (including a cross-claim or counterclaim in a lawsuit) alleging that any patent claim is infringed by making, using, selling, offering for sale, or importing the Program or any portion of it. 11. Patents. A “contributor” is a copyright holder who authorizes use under this License of the Program or a work on which the Program is based. The work thus licensed is called the contributor's “contributor version”. A contributor's “essential patent claims” are all patent claims owned or controlled by the contributor, whether already acquired or hereafter acquired, that would be infringed by some manner, permitted by this License, of making, using, or selling its contributor version, but do not include claims that would be infringed only as a consequence of further modification of the contributor version. For purposes of this definition, “control” includes the right to grant patent sublicenses in a manner consistent with the requirements of this License. Each contributor grants you a non-exclusive, worldwide, royalty-free patent license under the contributor's essential patent claims, to make, use, sell, offer for sale, import and otherwise run, modify and propagate the contents of its contributor version. In the following three paragraphs, a “patent license” is any express agreement or commitment, however denominated, not to enforce a patent (such as an express permission to practice a patent or covenant not to sue for patent infringement). To “grant” such a patent license to a party means to make such an agreement or commitment not to enforce a patent against the party. If you convey a covered work, knowingly relying on a patent license, and the Corresponding Source of the work is not available for anyone to copy, free of charge and under the terms of this License, through a publicly available network server or other readily accessible means, then you must either (1) cause the Corresponding Source to be so available, or (2) arrange to deprive yourself of the benefit of the patent license for this particular work, or (3) arrange, in a manner consistent with the requirements of this License, to extend the patent license to downstream recipients. “Knowingly relying” means you have actual knowledge that, but for the patent license, your conveying the covered work in a country, or your recipient's use of the covered work in a country, would infringe one or more identifiable patents in that country that you have reason to believe are valid. If, pursuant to or in connection with a single transaction or arrangement, you convey, or propagate by procuring conveyance of, a covered work, and grant a patent license to some of the parties receiving the covered work authorizing them to use, propagate, 91 modify or convey a specific copy of the covered work, then the patent license you grant is automatically extended to all recipients of the covered work and works based on it. A patent license is “discriminatory” if it does not include within the scope of its coverage, prohibits the exercise of, or is conditioned on the non-exercise of one or more of the rights that are specifically granted under this License. You may not convey a covered work if you are a party to an arrangement with a third party that is in the business of distributing software, under which you make payment to the third party based on the extent of your activity of conveying the work, and under which the third party grants, to any of the parties who would receive the covered work from you, a discriminatory patent license (a) in connection with copies of the covered work conveyed by you (or copies made from those copies), or (b) primarily for and in connection with specific products or compilations that contain the covered work, unless you entered into that arrangement, or that patent license was granted, prior to 28 March 2007. Nothing in this License shall be construed as excluding or limiting any implied license or other defenses to infringement that may otherwise be available to you under applicable patent law. 12. No Surrender of Others' Freedom. If conditions are imposed on you (whether by court order, agreement or otherwise) that contradict the conditions of this License, they do not excuse you from the conditions of this License. If you cannot convey a covered work so as to satisfy simultaneously your obligations under this License and any other pertinent obligations, then as a consequence you may not convey it at all. For example, if you agree to terms that obligate you to collect a royalty for further conveying from those to whom you convey the Program, the only way you could satisfy both those terms and this License would be to refrain entirely from conveying the Program. 13. Use with the GNU Affero General Public License. Notwithstanding any other provision of this License, you have permission to link or combine any covered work with a work licensed under version 3 of the GNU Affero General Public License into a single combined work, and to convey the resulting work. The terms of this License will continue to apply to the part which is the covered work, but the special requirements of the GNU Affero General Public License, section 13, concerning interaction through a network will apply to the combination as such. 14. Revised Versions of this License. The Free Software Foundation may publish revised and/or new versions of the GNU General Public License from time to time. Such new versions will be similar in spirit to the present version, but may differ in detail to address new problems or concerns. Each version is given a distinguishing version number. If the Program specifies that a certain numbered version of the GNU General Public License “or any later version” applies to it, you have the option of following the terms and conditions either of that numbered version or of any later version published by the Free Software Foundation. If the Program does not specify a version number of the GNU General Public License, you may choose any version ever published by the Free Software Foundation. 92 If the Program specifies that a proxy can decide which future versions of the GNU General Public License can be used, that proxy's public statement of acceptance of a version permanently authorizes you to choose that version for the Program. Later license versions may give you additional or different permissions. However, no additional obligations are imposed on any author or copyright holder as a result of your choosing to follow a later version. 15. Disclaimer of Warranty. THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM “AS IS” WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION. 16. Limitation of Liability. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MODIFIES AND/OR CONVEYS THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. 17. Interpretation of Sections 15 and 16. If the disclaimer of warranty and limitation of liability provided above cannot be given local legal effect according to their terms, reviewing courts shall apply local law that most closely approximates an absolute waiver of all civil liability in connection with the Program, unless a warranty or assumption of liability accompanies a copy of the Program in return for a fee. END OF TERMS AND CONDITIONS