Desarrollo de un sistema de seguimiento extrahospitalario de pacientes con Enfermedad Inflamatoria Intestinal

UNIVERSIDADE DE SANTIAGO DE COMPOSTELA ESCOLA T´ ECNICA SUPERIOR DE ENXE ˜ NAR´ IA Desarrollo de un sistema de seguimiento extrahospitalario de pacientes con Enfermedad Inflamatoria Intestinal Autor: Cristina S´anchez Barreiro Directores: Paulo F´elix Lamas Jorge Rodr´ıguez Gra˜na Grao en Enxe˜nar´ıa Inform´atica Xullo 2016 Traballo de Fin de Grao presentado na Escola T´ecnica Superior de Enxe˜nar´ıa da Universidade de Santiago de Compostela para a obtenci´on do Grao en Enxe˜nar´ıa Inform´atica D. Paulo F´elix Lamas, Profesor del Departamento de Electr´onica y Computaci´on de la Universidad de Santiago de Compostela, y D. Jorge Rodr´ıguez Gra˜na, jefe de proyecto en el ´area de eHealth de everis Coru˜na, INFORMAN: Que la presente memoria, titulada Desarrollo de un sistema de seguimiento extrahospitalario de pacientes con Enfermedad Inflamatoria Intestinal, presentada por D. Cristina S´anchez Barreiro para superar los cr´editos correspondientes al Trabajo de Fin de Grado de la titulaci´on de Grao en Enxe˜nar´ıa Inform´atica, se realiz´o bajo nuestra direcci´on en el eHealth Joint Knowledge Centre de Santiago de Compostela. Y para que as´ı conste a los efectos oportunos, expiden el presente informe en Santiago de Compostela, a 6 de julio de 2016: El director, El codirector, La alumna, Paulo F´elix Lamas Jorge Rodr´ıguez Gra˜na Cristina S´anchez Barreiro i ii Agradecimientos A mis padres, mi hermana y los Patatatroncos, porque sin ellos no hubiese sido posible. A´ Alvaro, por sus ´animos y por confiar en m´ı m´as que yo misma. A mis tutores, Paulo y Jorge, por haberme echado una mano siempre que lo he necesitado. A everis Coru˜na, por haberme dado la oportunidad de realizar este proyecto. A Carlos Dabarca, Fabi´an, Yago, Ana, Sol, Adam y Adri´an, por sus ´animos, ayuda y apoyo. A Patricia, Luc´ıa, V´ıctor, Alejandro, Pablo, Carlos Lamosa y Pilar, por echarme una mano desde la distancia. A Iago, por haber contado conmigo para la realizaci´on de este proyecto. iii iv ´ Indice general 1. Introducci´on 1 1.1. La Enfermedad Inflamatoria Intestinal . . . . . . . . . . . . . . . 3 1.1.1. Causas de la enfermedad de Crohn y la colitis ulcerosa . . 4 1.1.2. Evoluci´on de la enfermedad . . . . . . . . . . . . . . . . . 4 1.1.3. Perfil del paciente . . . . . . . . . . . . . . . . . . . . . . . 4 1.1.4. El papel de los cuestionarios . . . . . . . . . . . . . . . . . 5 1.1.5. Problem´atica ......................... 6 1.1.6. Estadoactual......................... 6 1.1.7. Motivaci´on del proyecto . . . . . . . . . . . . . . . . . . . 6 1.2. Objetivos Generales . . . . . . . . . . . . . . . . . . . . . . . . . . 7 1.3. Organizaci´on del documento . . . . . . . . . . . . . . . . . . . . . 8 2. Gesti´on del proyecto 11 2.1. Gesti´onderiesgos........................... 13 2.1.1. Medidores de riesgo . . . . . . . . . . . . . . . . . . . . . . 13 2.1.2. Activos ............................ 15 2.1.3. Riesgos............................. 16 2.2. Metodolog´ıa de desarrollo . . . . . . . . . . . . . . . . . . . . . . 23 2.2.1. Metodolog´ıa iterativa e incremental . . . . . . . . . . . . . 24 2.3. Gesti´on de la configuraci´on . . . . . . . . . . . . . . . . . . . . . . 27 2.3.1. Control del c´odigo fuente . . . . . . . . . . . . . . . . . . . 27 2.3.2. Control de la documentaci´on . . . . . . . . . . . . . . . . . 27 2.3.3. Control de la memoria del Trabajo Fin de Grado . . . . . 28 2.4. Planificaci´on temporal . . . . . . . . . . . . . . . . . . . . . . . . 28 2.4.1. Estructura de Descomposici´on del Trabajo . . . . . . . . . 29 2.4.2. Fases principales del proyecto . . . . . . . . . . . . . . . . 29 2.5. Gesti´on de RRHH y costes . . . . . . . . . . . . . . . . . . . . . . 31 2.5.1. Recursos humanos . . . . . . . . . . . . . . . . . . . . . . 31 2.6. Enunciado del alcance . . . . . . . . . . . . . . . . . . . . . . . . 34 2.6.1. Descripci´on del alcance del proyecto . . . . . . . . . . . . . 34 2.6.2. Criterios de aceptaci´on del producto . . . . . . . . . . . . 34 2.6.3. Entregables del proyecto . . . . . . . . . . . . . . . . . . . 34 2.6.4. Exclusiones del proyecto . . . . . . . . . . . . . . . . . . . 35 v 2.6.5. Supuestos del proyecto . . . . . . . . . . . . . . . . . . . . 35 3. An´alisis de requisitos 37 3.1. Casos de uso del sistema . . . . . . . . . . . . . . . . . . . . . . . 39 3.2. Descripci´on de los actores del sistema . . . . . . . . . . . . . . . . 39 3.3. Descripci´on de casos de uso . . . . . . . . . . . . . . . . . . . . . 39 3.4. Requisitos funcionales . . . . . . . . . . . . . . . . . . . . . . . . 54 3.4.1. Identificaci´on de requisitos funcionales . . . . . . . . . . . 54 3.4.2. Especificaci´on de requisitos funcionales . . . . . . . . . . . 56 3.5. Matriz de trazabilidad . . . . . . . . . . . . . . . . . . . . . . . . 66 3.6. Requisitos no funcionales . . . . . . . . . . . . . . . . . . . . . . . 66 3.6.1. Requisitos del producto . . . . . . . . . . . . . . . . . . . 66 3.6.2. Requisitos de eficiencia . . . . . . . . . . . . . . . . . . . . 70 3.6.3. Requisitos externos . . . . . . . . . . . . . . . . . . . . . . 70 3.7. Restricciones de dise˜no . . . . . . . . . . . . . . . . . . . . . . . . 71 3.8. Seguridad ............................... 73 4. Dise˜no 75 4.1. Arquitectura del sistema . . . . . . . . . . . . . . . . . . . . . . . 77 4.1.1. Ventajas del modelo cliente-servidor . . . . . . . . . . . . . 77 4.1.2. Desventajas del modelo cliente-servidor . . . . . . . . . . . 79 4.1.3. Justificaci´on de la elecci´on . . . . . . . . . . . . . . . . . . 79 4.2. Patronesdedise˜no .......................... 79 4.2.1. Patr´onMVC ......................... 79 4.2.2. Patr´onDTO.......................... 80 4.2.3. Patr´onDAO.......................... 82 4.3. Subsistema servidor . . . . . . . . . . . . . . . . . . . . . . . . . . 82 4.4. Subsistema aplicaci´on web . . . . . . . . . . . . . . . . . . . . . . 83 4.5. Subsistema aplicaci´on m´ovil . . . . . . . . . . . . . . . . . . . . . 83 4.6. Basededatos ............................. 88 4.7. Diagramas de secuencia . . . . . . . . . . . . . . . . . . . . . . . . 88 4.8. An´alisis de tecnolog´ıas . . . . . . . . . . . . . . . . . . . . . . . . 94 4.8.1. Sistema operativo . . . . . . . . . . . . . . . . . . . . . . . 94 4.8.2. Sistema Gestor de Bases de datos . . . . . . . . . . . . . . 94 4.8.3. Seguimiento de incidencias . . . . . . . . . . . . . . . . . . 97 4.8.4. Entorno de desarrollo . . . . . . . . . . . . . . . . . . . . . 97 4.8.5. Comunicaci´on entre sistemas . . . . . . . . . . . . . . . . . 97 4.8.6. Librer´ıa de gr´aficos . . . . . . . . . . . . . . . . . . . . . . 97 4.8.7. Acceso a datos . . . . . . . . . . . . . . . . . . . . . . . . 98 4.8.8. Inyecci´on de dependencias . . . . . . . . . . . . . . . . . . 99 4.8.9. Librer´ıa de serializaci´on/deserializaci´on . . . . . . . . . . . 99 vi 5. Desarrollo 101 5.1. Organizaci´on del trabajo . . . . . . . . . . . . . . . . . . . . . . . 103 6. Pruebas 107 6.1. Proceso de pruebas . . . . . . . . . . . . . . . . . . . . . . . . . . 109 6.1.1. Pruebas unitarias . . . . . . . . . . . . . . . . . . . . . . . 109 6.1.2. Pruebas de integraci´on . . . . . . . . . . . . . . . . . . . . 117 6.1.3. Pruebas de sistema . . . . . . . . . . . . . . . . . . . . . . 117 6.1.4. Evaluaci´on de usabilidad . . . . . . . . . . . . . . . . . . . 118 7. Conclusiones y trabajo futuro 119 7.1. Conclusiones.............................. 121 7.2. Trabajofuturo ............................ 122 A. Manual de despliegue 123 A.1. Componentes de la instalaci´on . . . . . . . . . . . . . . . . . . . . 125 A.1.1.Cliente............................. 125 A.1.2.Servidor............................ 125 A.1.3.Basededatos......................... 125 A.2. Procedimiento de instalaci´on . . . . . . . . . . . . . . . . . . . . . 125 A.2.1.Cliente............................. 126 A.2.2.Servidor............................ 126 A.2.3.Basededatos......................... 127 A.3. Procedimiento de desinstalaci´on . . . . . . . . . . . . . . . . . . . 127 A.4. Configuraci´on de la redirecci´on de puertos . . . . . . . . . . . . . 127 B. Manual de usuario - Aplicaci´on web 131 B.1.Introducci´on.............................. 133 B.2.Iniciodesesi´on ............................ 133 B.3. Vista de pacientes . . . . . . . . . . . . . . . . . . . . . . . . . . . 133 B.3.1. Detalles del paciente . . . . . . . . . . . . . . . . . . . . . 134 B.4. Gesti´on de cuestionarios . . . . . . . . . . . . . . . . . . . . . . . 136 B.4.1. Detalles del cuestionario . . . . . . . . . . . . . . . . . . . 137 B.4.2. Creaci´on de cuestionarios . . . . . . . . . . . . . . . . . . . 139 C. Manual de usuario - Aplicaci´on m´ovil 145 C.1.Introducci´on.............................. 147 C.2.Iniciodesesi´on ............................ 147 C.3. Pantalla principal . . . . . . . . . . . . . . . . . . . . . . . . . . . 148 C.4.Men´udeopciones........................... 149 C.5.Ayuda................................. 150 C.6. Selecci´on de cuestionarios . . . . . . . . . . . . . . . . . . . . . . 151 C.7. Responder cuestionarios . . . . . . . . . . . . . . . . . . . . . . . 152 vii xiv Cap´ıtulo 1 Introducci´on 1.1. La Enfermedad Inflamatoria Intestinal . . . . . . . . . 3 1.1.1. Causas de la enfermedad de Crohn y la colitis ulcerosa 4 1.1.2. Evoluci´on de la enfermedad . . . . . . . . . . . . . . . 4 1.1.3. Perfil del paciente . . . . . . . . . . . . . . . . . . . . 4 1.1.4. El papel de los cuestionarios . . . . . . . . . . . . . . 5 1.1.5. Problem´atica . . . . . . . . . . . . . . . . . . . . . . . 6 1.1.6. Estadoactual....................... 6 1.1.7. Motivaci´on del proyecto . . . . . . . . . . . . . . . . . 6 1.2. Objetivos Generales . . . . . . . . . . . . . . . . . . . . 7 1.3. Organizaci´on del documento . . . . . . . . . . . . . . . 8 1 2CAP´ ITULO 1. INTRODUCCI ´ ON 1.1. LA ENFERMEDAD INFLAMATORIA INTESTINAL 3 1.1. La Enfermedad Inflamatoria Intestinal La Enfermedad Inflamatoria Intestinal engloba dos patolog´ıas, la colitis ulcerosa y la enfermedad de Crohn. Ambas se caracterizan por ser enfermedades autoinmunes, inflamatorias y cr´onicas, que evolucionan en brotes (fases activas) y periodos de remisi´on (fases inactivas) [1]. Ambas alteran la capacidad del organismo para digerir alimentos y absorber nutrientes, y comparten adem´as caracter´ısticas cl´ınicas y patol´ogicas. Sus s´ıntomas m´as comunes son diarrea, sangre en las heces, cansancio, dolor abdominal, p´erdida de apetito, p´erdida de peso y fiebre. La figura 1.1 muestra la evoluci´on en brotes de la Enfermedad Inflamatoria Intestinal. Figura 1.1: Fases de la EII Sin embargo, existen diferencias entre ambas patolog´ıas. La m´as notable es la zona de afectaci´on, ya que, mientras que la colitis ulcerosa se caracteriza por lesiones cr´onicas en la pared del colon, la enfermedad de Crohn puede aparecer en cualquier parte del aparato digestivo, desde la boca hasta el ano. No es posible padecer ambas patolog´ıas al mismo tiempo, aunque en algunos casos es dif´ıcil 4CAP´ ITULO 1. INTRODUCCI ´ ON determinar cu´al de las dos patolog´ıas padece un paciente, en cuyo caso se usa el t´ermino colitis indeterminada. 1.1.1. Causas de la enfermedad de Crohn y la colitis ulcerosa Se desconoce la causa que origina la aparici´on de la EII, aunque se cree que puede deberse a la interacci´on de factores gen´eticos, ambientales y a cambios en la microbiota intestinal. Sin embargo, algunos datos indican que: La EII es m´as com´un en los pa´ıses desarrollados y en las zonas urbanas Espa˜na ha aumentado el n´umero de casos de EII en las ´ultimas d´ecadas Puede afectar a cualquier raza o grupo ´etnico Afecta por igual a hombres y a mujeres Pueden diagnosticarse a cualquier edad, pero con mayor frecuencia antes de los 30 a˜nos La enfermedad de Crohn se ha duplicado en ni˜nos menores de 10 a˜nos desde 1996. 1.1.2. Evoluci´on de la enfermedad Tanto la enfermedad de Crohn como la colitis ulcerosa son patolog´ıas cr´onicas sin tratamiento definitivo. Sin embargo, disponen de tratamientos paliativos. La evoluci´on de estas patolog´ıas puede variar en funci´on de los tratamientos administrados, y algunos de ellos han demostrado producir cambios positivos en el pron´ostico y evoluci´on de la enfermedad a corto y largo plazo. No obstante, la eficacia de estos medicamentos var´ıa de unos pacientes a otros y a veces es necesario probar con diferentes medicamentos hasta dar con el m´as efectivo para el paciente, por lo que es necesario realizar un seguimiento exhaustivo una vez se empieza el tratamiento con un nuevo medicamento, para as´ı poder medir la eficacia del mismo. 1.1.3. Perfil del paciente La enfermedad de Crohn y la colitis ulcerosa son enfermedades que se manifiestan en edades tempranas, situ´andose la media de diagn´ostico alrededor de los 30 a˜nos, aunque el n´umero de casos que aparecen en edad pedi´atrica aumenta cada a˜no. Actualmente, la mitad de los pacientes que padecen estas enfermedades son adultos j´ovenes entre 20 y 39 a˜nos, y un 25 % de los pacientes inician el proceso inflamatorio antes de los 20 %. 1.1. LA ENFERMEDAD INFLAMATORIA INTESTINAL 5 Concretamente, Espa˜na es uno de los pa´ıses desarrollados donde se concentra una mayor proporci´on de pacientes con edades comprendidas entre los 20 y los 29 a˜nos [2]. Estas enfermedades producen un gran impacto en la calidad de vida de sus pacientes, afectando tanto a su desarrollo personal como profesional. De manera detallada, un 74 % de los pacientes declara estar altamente afectado por la sensaci´on de evacuaci´on incompleta; a un 72 % les preocupa la diarrea, y el 46 % afirma que la enfermedad Intestinal Inflamatoria le provoca demasiada fatiga y cansancio para llevar a cabo sus actividades diarias con normalidad. 1.1.4. El papel de los cuestionarios Los cuestionarios de autocontrol consisten en una serie de preguntas y posibles respuestas que ayudan a identificar problemas o necesidades de cada persona, a partir de la percepci´on que se tiene de la propia enfermedad. Con estos cuestionarios, pueden evaluarse diferentes aspectos que se pueden ver afectados por la presencia de la enfermedad y que pueden afectar al paciente en diferentes ´ambitos como sintomatolog´ıa, aspectos funcionales, afectaci´on psicol´ogica o emocional, o actividades sociales, valorados desde la perspectiva de quien padece la enfermedad. Los cuestionarios que se realizan a pacientes con Enfermedad Inflamatoria Intestinal pueden clasificarse en tres grandes grupos: Adherencia Seguimiento cl´ınico Calidad de vida Los cuestionarios de adherencia permiten medir el nivel de adherencia de un paciente a la medicaci´on, esto es, permite evaluar si el paciente est´a tomando su medicaci´on de manera correcta. Por otro lado, el cuestionario de seguimiento cl´ınico permite evaluar la actividad de la enfermedad, para determinar si el paciente se encuentra en un periodo de remisi´on o de brote. Por ´ultimo, el cuestionario de calidad de vida permite evaluar el estado general del paciente. Estos datos complementan la informaci´on de las pruebas cl´ınicas y de la consulta m´edica, integrados en una estrategia de tratamiento m´as amplia, que pretende adem´as de obtener la remisi´on cl´ınica de la enfermedad, disminuir el n´umero de complicaciones e incrementar la calidad de vida del paciente [3]. Adem´as, la integraci´on del paciente en el proceso de su enfermedad, el tomar conciencia de ciertos aspectos u s´ıntomas, puede facilitar la comprensi´on y aceptaci´on del proceso, mejorando la adherencia al tratamiento y la relaci´on con su m´edico, al asumir parte de responsabilidad con respecto a la enfermedad. 6CAP´ ITULO 1. INTRODUCCI ´ ON 1.1.5. Problem´atica Los pacientes con Enfermedad Inflamatoria Intestinal suponen una alta carga para el sistema sanitario, ya que deben acudir a consulta con una frecuencia muy alta. Sin embargo, seg´un relata el cliente, muchas de estas visitas no se realizan con el objetivo de practicar ninguna prueba cl´ınica, sino que en muchas ocasiones s´olo se realizan cuestionarios de seguimiento, que permiten evaluar la evoluci´on de la patolog´ıa en base a una serie de preguntas sobre el estado de salud del paciente. As´ı, el hecho de poder realizar estos cuestionarios fuera de la consulta, permitir´ıa reducir en gran medida la carga asistencial del sistema sanitario. 1.1.6. Estado actual Actualmente, existen varios cuestionarios cl´ınicos que han sido validados para su uso fuera de consulta, al considerarse que los resultados obtenidos tienen un alto nivel de coherencia con las exploraciones realizadas por facultativos. Ejemplo de esto son los cuestionarios SCCAI [4, 5], P-SCCAI [6], CDAI [7] y HarveyBradshaw [8]. Los dos primeros se emplean para el seguimiento de pacientes con colitis ulcerosa, mientras que los dos ´ultimos se utilizan en el seguimiento cl´ınico de pacientes con enfermedad de Crohn. Figura 1.2: Clasificaci´on seg´un el ´ındice de actividad (SCCAI) Existen en el mercado algunas aplicaciones que permiten a los pacientes con Enfermedad Inflamatoria Intestinal la realizaci´on de cuestionarios desde su domicilio, lo que les permite conocer su estado, como myIBD [9], desarrollada en Canad´a, o GI Monitor [10]. 1.1.7. Motivaci´on del proyecto Como puede apreciarse en el apartado anterior, ya existen aplicaciones m´oviles que permiten el seguimiento de pacientes con enfermedad de Crohn y colitis ulcerosa. Sin embargo, se trata de aplicaciones orientadas fundamentalmente a su uso por parte de los pacientes y que presentan una serie de desventajas de cara a su uso cl´ınico: 1.2. OBJETIVOS GENERALES 7 No ofrecen una plataforma para facultativos, de modo que es necesario que el paciente acuda a consulta para que el facultativo pueda ver los resultados. Se trata de aplicaciones que cuentan con una serie de cuestionarios preconfigurados, por lo que los facultativos no pueden utilizarlas como soporte para el desarrollo de ensayos cl´ınicos de validaci´on de nuevos cuestionarios. Son aplicaciones enfocadas al seguimiento de la patolog´ıa concreta, sin tener en cuenta los patrones que puede cursar la misma. Por los motivos expuestos anteriormente, son aplicaciones que no responden al problema de la alta carga asistencial generada por los pacientes con Enfermedad Inflamatoria Intestinal. Por ello, se considera necesaria la creaci´on de una herramienta que satisfaga estos problemas, de modo que pueda ser utilizada por los facultativos para obtener datos de pacientes sin necesidad de llamarlos a consulta, y que permita la creaci´on de nuevos cuestionarios, lo que facilita la innovaci´on y el desarrollo de nuevas t´ecnicas que ayuden a realizar un seguimiento de los pacientes. Adem´as, seg´un datos facilitados por el propio cliente, los pacientes con Enfermedad Inflamatoria Intestinal son, en su mayor´ıa, gente familiarizada con las nuevas tecnolog´ıas, plenamente consciente de su enfermedad, y con predisposici´on a la participaci´on en ensayos cl´ınicos en los que se prueben nuevas soluciones que puedan ayudar a mejorar su calidad de vida. Las caracter´ısticas que presentan estos pacientes hacen que sean id´oneos para la prueba de soluciones basadas en las nuevas tecnolog´ıas, como la que se desarrollar´a en el presente proyecto. 1.2. Objetivos Generales Los objetivos del presente trabajo son: 1. Dise˜nar e implementar una aplicaci´on m´ovil que permita: a) Obtener informaci´on sobre el estado de salud del paciente, en base a indicadores m´edicos establecidos, a trav´es de la realizaci´on de cuestionarios. b) Obtener informaci´on sobre la adherencia del paciente al tratamiento, a trav´es de cuestionarios. 2. Implementar una base de datos donde se almacenen los datos de evoluci´on de los pacientes. 3. Dise˜nar una aplicaci´on web que permita a los facultativos: a) Dise˜nar nuevos cuestionarios. 8CAP´ ITULO 1. INTRODUCCI ´ ON b) Visualizar el estado de los pacientes. c) Visualizar la evoluci´on de los pacientes en forma de gr´afica. Lo que se pretende es la creaci´on de una aplicaci´on din´amica, que d´e libertad a los facultativos a la hora de crear nuevos cuestionarios, en lugar de tener que depender del equipo de desarrollo para tal efecto. Se desea, adem´as, construir la aplicaci´on de tal forma que pueda ser extensible a nuevos tipos de cuestionarios (calidad de vida, vacunaci´on, tabaquismo, etc) o patolog´ıas, tan s´olo realizando modificaciones en la base de datos, sin necesidad de realizar modificaciones en el c´odigo de la aplicaci´on. Por otra parte, tambi´en se permite al facultativo asociar los cuestionarios no s´olo a una patolog´ıa, sino tambi´en a un patr´on concreto de la misma, lo que proporciona un seguimiento individualizado de los pacientes, teniendo en cuenta las particularidades de su patolog´ıa. De este modo, al permitir al facultativo consultar los datos relativos a los cuestionarios respondidos, se eliminar´ıan aquellas consultas cuyo ´unico prop´osito sea la realizaci´on de cuestionarios, por lo que el paciente tan s´olo tendr´ıa que acudir a revisiones o a pruebas cl´ınicas tales como anal´ıticas, ecograf´ıas, endoscopias, etc. lo que ayuda a reducir la carga del sistema. 1.3. Organizaci´on del documento A lo largo de este documento se expondr´an todos los procesos y metodolog´ıas utilizados para alcanzar los objetivos del proyecto. El documento se divide en los siguientes apartados: En el Cap´ıtulo 2 se abordan los aspectos relativos a la gesti´on del proyecto, comprendiendo la metodolog´ıa de desarrollo, planificaci´on temporal y la gesti´on de recursos humanos, costes, riesgos y configuraci´on, as´ı como una relaci´on de las herramientas empleadas. En el Cap´ıtulo 3 se presenta el proceso de an´alisis del software, empezando por la identificaci´on de los casos de uso del sistema, para luego extraer los requisitos funcionales. Posteriormente, se enuncia el alcance del proyecto y se muestra c´omo se ha organizado el trabajo. En el Cap´ıtulo 4 se muestra la arquitectura del sistema, y se exponen los patrones de dise˜no empleados. A continuaci´on, se explica cada uno de los subsistemas de los que se compone el proyecto. Por ´ultimo, se realiza un an´alisis de las tecnolog´ıas que se pueden emplear para la realizaci´on del proyecto, justificando en cada caso las razones por las cuales se ha optado por el uso de unas tecnolog´ıas frente a otras. En el Cap´ıtulo 5 se muestra la organizaci´on del trabajo, explicando cada una de las iteraciones que se han llevado a cabo, y el contenido de las mismas. 1.3. ORGANIZACI ´ ON DEL DOCUMENTO 9 En el Cap´ıtulo 6 se expone el proceso de pruebas, listando y explicando cada una de las pruebas que se han llevado a cabo sobre el producto software desarrollado. En el Cap´ıtulo 7 se exponen las conclusiones extra´ıdas del presente trabajo, as´ı como las mejoras o ampliaciones que se podr´ıan hacer en un futuro. El Ap´endice A contiene el manual de despliegue de la aplicaci´on, mientras que los Ap´endices B y C constituyen los manuales de usuario de la aplicaci´on web y m´ovil, respectivamente. Por ´ultimo, el Ap´endice D contiene la relaci´on de documentos anexos a la presente memoria. 16 CAP´ ITULO 2. GESTI ´ ON DEL PROYECTO 2.1.3. Riesgos Consideraciones previas Una vez identificados los posibles riesgos que pueden afectar al proyecto, es necesario realizar un an´alisis de cada uno de ellos, para as´ı poder catalogarlos en base a su relevancia en el transcurso del trabajo, y relacionarlos con los diferentes activos del proyecto. Cabe destacar que, al ser el lugar de trabajo un edificio p´ublico donde no se lleva a cabo un control de acceso, existen ciertos riesgos asociados a este hecho. Existen tres tipos de respuesta posible ante los riesgos: Prevenci´on: Consiste en reducir la probabilidad de que un riesgo aparezca. Minimizaci´on: Consiste en reducir el impacto del riesgo. Elaboraci´on de un plan de contingencia: Actuaci´on en el caso de que un riesgo se produzca, para que afecte lo menos posible al transcurso del proyecto. An´alisis de riesgos Cuadro 2.4: Fallo de seguridad l´ogica Identificador R1 Nombre Fallo de seguridad l´ogica Exposici´on Alta Activos afectados A3, A9, A10, A13 Probabilidad Media Grado de impacto Alto Descripci´on Falta de seguridad o medidas insuficientes ante un posible ataque inform´atico Tratamiento Minimizaci´on: Realizaci´on de copias de seguridad. Prevenci´on: Instalaci´on de antivirus y firewall Indicadores N´umero de infecciones detectadas >0 2.1. GESTI ´ ON DE RIESGOS 17 Cuadro 2.5: Aver´ıa del hardware Identificador R2 Nombre Aver´ıa del hardware Exposici´on Alta Activos afectados A1, A5, A9, A10, A12, A13 Probabilidad Moderada Grado de impacto Alto Descripci´on Fallo o deterioro del hardware empleado para desarrollar el proyecto. Tratamiento Transferir: Contratar una ampliaci´on de garant´ıa. Minimizaci´on: Realizaci´on de copias de seguridad. Contingencia: Llamar al servicio t´ecnico. Indicadores Uno o m´as equipos no funcionan. Cuadro 2.6: Robo de material Identificador R3 Nombre Robo de material Exposici´on Alta Activos afectados A1, A4, A5, A9, A10, A12, A13 Probabilidad Moderada Grado de impacto Alto Descripci´on Sustracci´on de material debido a un robo en el local Tratamiento Transferir: Contratar un seguro. Minimizaci´on: Realizaci´on de copias de seguridad. Contingencia: Llamar a la polic´ıa. Prevenci´on: Instalaci´on de alarmas y c´amaras de videovigilancia. Uso de candados de tipo Kensington en los equipos. Indicadores Ausencia de material. Presencia de desperfectos. 18 CAP´ ITULO 2. GESTI ´ ON DEL PROYECTO Cuadro 2.7: Cambio en los requisitos Identificador R4 Nombre Cambio en los requisitos Exposici´on Alta Activos afectados A10, A13, A14 Probabilidad Alta Grado de impacto Alto Descripci´on Alteraci´on de los requisitos por parte del cliente, quien demanda funcionalidades no pactadas o modificaciones de funcionalidades ya contempladas. Tratamiento Minimizaci´on: Elecci´on de un ciclo de vida tolerante a los cambios. Realizaci´on de un dise˜no que permita la introducci´on de cambios con facilidad. Realizaci´on de reuniones peri´odicas con el cliente que permitan detectar las necesidades de cambio lo antes posible. Indicadores N´umero de nuevos requisitos demandados por el cliente > 0 N´umero de modificaciones demandadas por el cliente >0 Cuadro 2.8: Incumplimiento de los plazos de entrega Identificador R5 Nombre Incumplimiento de los plazos de entrega Exposici´on Alta Activos afectados A8, A16 Probabilidad Alta Grado de impacto Alto Descripci´on Una o m´as entregas del proyecto se realizan con retraso respecto a lo planificado en el cronograma. Tratamiento Realizaci´on de una buena planificaci´on. Indicadores N´umero de entregas con un retraso mayor a 3 d´ıas >0 2.1. GESTI ´ ON DE RIESGOS 19 Cuadro 2.9: Mala especificaci´on de requisitos Identificador R6 Nombre Mala especificaci´on de requisitos Exposici´on Alta Activos afectados A10, A13 Probabilidad Moderada Grado de impacto Alto Descripci´on Aporte escaso de informaci´on acerca de los requisitos por parte del cliente, o especificaci´on inexacta de los mismos en el proyecto. Tratamiento Minimizaci´on: Realizaci´on de reuniones peri´odicas con el cliente para analizar requisitos. Prevenci´on: Revisi´on de los requisitos con el cliente. Elecci´on de un ciclo de vida que permita la presentaci´on de prototipos al cliente de forma regular. Indicadores Existencia de requisitos mal especificados. Cuadro 2.10: Dise˜no incorrecto Identificador R7 Nombre Dise˜no incorrecto Exposici´on Alta Activos afectados A10 Probabilidad Moderada Grado de impacto Alto Descripci´on El dise˜no resultante de la fase hom´onima del proyecto contiene errores que afectan a la calidad del producto a desarrollar. Tratamiento Prevenci´on: Refinamiento de las etapas anteriores al dise˜no, con el fin de minimizar los errores de ´este. Revisi´on del dise˜no tras su elaboraci´on Indicadores N´umero de design smells >0 [11]. 20 CAP´ ITULO 2. GESTI ´ ON DEL PROYECTO Cuadro 2.11: Retraso en la autorizaci´on de la prueba piloto Identificador R8 Nombre Retraso en la autorizaci´on de la prueba piloto Exposici´on Media Activos afectados A1, A2, A4, A5, A9, A10, A12, A13 Probabilidad Media Grado de impacto Alto Descripci´on Se produce un retraso en la autorizaci´on de la prueba piloto por parte del comit´e ´etico. Tratamiento Prevenci´on: Realizar la petici´on de prueba piloto al inicio del proyecto, con el objetivo de que est´e resuelta con antelaci´on a la fecha establecida en el cronograma para su realizaci´on. Indicadores Altura alcanzada por el agua >1cm Cuadro 2.12: Retrasos burocr´aticos internos Identificador R9 Nombre Retrasos burocr´aticos internos Exposici´on Media Activos afectados A3 Probabilidad Media Grado de impacto Medio Descripci´on Retraso en la concesi´on de acceso a herramientas o datos propiedad de la empresa. Tratamiento Minimizaci´on: Tratar de realizar, en al medida de lo posible, otras tareas que no dependan de los tr´amites burocr´aticos solicitados. Prevenci´on: Realizar un estudio donde se eval´uen las necesidades, para as´ı realizar las solicitudes pertinentes con la mayor antelaci´on posible. Indicadores Altura alcanzada por el agua >1cm 2.1. GESTI ´ ON DE RIESGOS 21 Cuadro 2.13: No detecci´on de riesgos importantes Identificador R10 Nombre No detecci´on de riesgos importantes Exposici´on Media Activos afectados Potencialmente todos los activos Probabilidad Baja Grado de impacto Alto Descripci´on La implicaci´on en la gesti´on de riesgos es baja, lo que puede provocar que surjan riesgos no contemplados en etapas posteriores, los cuales no se sabe c´omo tratar. Tratamiento Prevenci´on: Realizaci´on de una revisi´on rigurosa de los riesgos tras su identificaci´on. Indicadores N´umero de riesgos que aparecen en el transcurso del proyecto y que no est´an contemplados en el plan de gesti´on de riesgos >0. Cuadro 2.14: Planificaci´on demasiado optimista Identificador R11 Nombre Planificaci´on demasiado optimista Exposici´on Media Activos afectados A10, A16, A8 Probabilidad Baja Grado de impacto Alto Descripci´on La estimaci´on de la duraci´on de las tareas no es realista, con lo que se estima una duraci´on total menor que la real. Tratamiento Prevenci´on: Revisi´on de la planificaci´on del proyecto tras su realizaci´on. Indicadores N´umero de tareas que no se completan en el tiempo esperado >3. 22 CAP´ ITULO 2. GESTI ´ ON DEL PROYECTO Cuadro 2.15: Fallo en las comunicaciones Identificador R12 Nombre Fallo en las comunicaciones Exposici´on Media Activos afectados A5, A7 Probabilidad Media Grado de impacto Medio Descripci´on Se produce un error en los sistemas de comunicaciones (Internet, tel´efono, etc.) que impide acceder a los recursos necesarios. Tratamiento Prevenci´on: Refinamiento de las etapas anteriores al dise˜no, con el fin de minimizar los errores de ´este. Contingencia: Continuar con el trabajo offline en la medida de lo posible hasta que los sistemas est´en disponibles. Indicadores N´umero de sistemas de comunicaciones que no se pueden utilizar >0. Cuadro 2.16: El cliente no est´a disponible para la reuni´on Identificador R13 Nombre El cliente no est´a disponible para la reuni´on Exposici´on Media Activos afectados A16 Probabilidad Alta Grado de impacto Bajo Descripci´on El cliente no puede acudir a alguna reuni´on en la fecha planificada, retrasando el avance del proyecto. Tratamiento Prevenci´on: Pactar las fechas de reuni´on con el cliente con al menos una semana de antelaci´on. Contingencia: Mover la fecha de la reuni´on a otro d´ıa lo m´as pronto posible e intentar continuar con el trabajo en la medida de lo posible. Indicadores N´umero de negativas por parte del cliente sobre la fecha de reuni´on propuesta >0. 2.2. METODOLOG´ IA DE DESARROLLO 23 Cuadro 2.17: Recorte del tiempo disponible para el proyecto Identificador R14 Nombre Recorte del tiempo disponible para el proyecto Exposici´on Media Activos afectados A16 Probabilidad Media Grado de impacto Medio Descripci´on El cliente exige que se disminuya el plazo de finalizaci´on previsto para el proyecto. Tratamiento Contingencia: Reducci´on de funcionalidades en funci´on del tiempo disponible. Asunci´on de horas extra. Indicadores N´umero de d´ıas en los que se adelanta la entrega del proyecto > 0. Cuadro 2.18: Baja por enfermedad Identificador R15 Nombre Baja por enfermedad Exposici´on Media Activos afectados A10, A13 Probabilidad Baja Grado de impacto Alto Descripci´on La persona encargada de la realizaci´on del proyecto sufre una enfermedad y que lo incapacita temporalmente para trabajar en el mismo. Tratamiento Contingencia: Replanificar el proyecto en la medida de lo posible. Pactar con el cliente una nueva fecha de entrega. Indicadores N´umero de bajas por enfermedad de la persona encargada de la realizaci´on del proyecto >0. 2.2. Metodolog´ıa de desarrollo Uno de los primeros pasos a seguir en la elaboraci´on de cualquier proyecto es la elecci´on de la metodolog´ıa que se emplear´a para llevar a cabo su desarrollo. Es fundamental tomar esta decisi´on de forma acertada, ya que una elecci´on err´onea puede llevar a que no se cumplan fechas de entrega y/o costes, e incluso llevar a la cancelaci´on del proyecto. Sin embargo, no existe una metodolog´ıa v´alida por excelencia, sino que es necesario analizar las caracter´ısticas del proyecto, el equipo de trabajo y el cliente para poder escoger cu´al seguir. Las metodolog´ıas empleadas en gesti´on de proyectos se dividen en dos grandes bloques: Metodolog´ıas pesadas y metodolog´ıas ´agiles. 24 CAP´ ITULO 2. GESTI ´ ON DEL PROYECTO Las metodolog´ıas pesadas se caracterizan por estar basadas en una planificaci´on inicial que se debe seguir de manera estricta durante todo el desarrollo, y por disponer de un cat´alogo de requisitos invariable. Se trata por tanto, de una metodolog´ıa muy poco tolerante a cambios. Por otro lado, las metodolog´ıas ´agiles parten de la base de que el proyecto sufrir´a cambios en los requisitos a lo largo de su desarrollo. En estas metodolog´ıas, se mantiene un contacto continuo con el cliente, al que se le presentan diferentes m´odulos funcionales de la aplicaci´on, para que pueda evaluarlos y as´ı proporcionar feedback al equipo de desarrollo. Son, por tanto, de un tipo de metodolog´ıa mucho m´as flexible y tolerante a potenciales cambios. En el caso de este proyecto, existe un alto nivel de incertidumbre, ya que en las reuniones iniciales se ha percibido que el cliente tiene tendencia a introducir requisitos no planteados en reuniones previas. Por otra parte, el desarrollo se lleva a cabo en el lugar de trabajo del cliente, lo que facilita el establecimiento de reuniones de seguimiento con el mismo. Adem´as, hay que tener en cuenta que el proyecto ser´a desarrollado por una persona que carece de experiencia en la realizaci´on de proyectos de envergadura, y que se manejar´an tecnolog´ıas desconocidas hasta el momento, algunas de ellas incluso con escasa documentaci´on. Por estas razones, se considera que la aplicaci´on de metodolog´ıas ´agiles resulta id´onea para el proyecto. 2.2.1. Metodolog´ıa iterativa e incremental En un desarrollo iterativo e incremental [12] el proyecto se planifica en diversos bloques temporales llamados iteraciones. Las iteraciones pueden entenderse como peque˜nos proyectos en los que se repite un proceso de trabajo similar para proporcionar un resultado completo, de forma que el cliente pueda obtener los resultados del proyecto de modo incremental. Para ello, cada uno de los requisitos solicitados por el cliente debe ser completado en una ´unica iteraci´on, incluyendo las pruebas y documentaci´on asociadas. En cada iteraci´on, se hace una entrega incremental a partir de los resultados obtenidos en iteraciones anteriores, a˜nadiendo nuevos requisitos o mejorando aquellos que ya fueron completados. Este tipo de desarrollo se realiza a trav´es de la priorizaci´on de los requisitos en funci´on del valor que aportan al cliente. Beneficios Esta metodolog´ıa presenta una serie de beneficios sobre otras metodolog´ıas: Pueden gestionarse las expectativas del cliente de manera regular, ya que ´este puede tomar decisiones en cada iteraci´on. Esto es especialmente interesante cuando: 2.2. METODOLOG´ IA DE DESARROLLO 25 •El cliente no sabe exactamente qu´e necesita al inicio del proyecto, sino que lo va sabiendo a medida que aprecia los resultados del mismo. •El cliente necesita hacer cambios a corto plazo. •El equipo necesita saber si lo que ha entendido es lo que el cliente espera. El cliente puede comenzar el proyecto con requisitos de alto nivel, quiz´a no totalmente completos, para luego refinarlos en sucesivas iteraciones. De este modo, puede comenzarse el proyecto conociendo en detalle s´olo aquellos requisitos que m´as valor aportan al cliente, y no es necesario realizar una recolecci´on completa y detallada de los mismos antes de empezar el desarrollo del proyecto. El cliente puede obtener resultados usables desde las primeras iteraciones. Los cambios pueden ser gestionados de forma natural. Al finalizar cada iteraci´on, el cliente puede examinar el producto obtenido y proporcionar feedback al equipo, lo que permite recopilar informaci´on acerca de la necesidad de realizaci´on de cambios para cumplir con las expectativas del cliente. El cliente puede perder como m´aximo los recursos dedicados a una iteraci´on, no los del proyecto completo. Elimina la posibilidad de no aceptaci´on del proyecto, ya que en caso de que el cliente no est´e satisfecho, se eliminar´ıa la ´ultima iteraci´on. La finalizaci´on de cada iteraci´on es el lugar donde el equipo puede decidir c´omo mejorar el proceso de trabajo, lo que permite planificar cambios para aumentar la productividad y la calidad del desarrollo. Permite conocer el progreso real del proyecto desde las primeras iteraciones, lo que permite extrapolar si su finalizaci´on es viable en la fecha prevista. Permite mitigar los riesgos del proyecto al inicio. Permite gestionar la complejidad del proyecto. Se minimiza el n´umero de errores que se producen en el desarrollo y se aumenta la calidad, al presentar requisitos ya terminados al final de cada iteraci´on. Restricciones Sin embargo, esta metodolog´ıa tambi´en dispone de una serie de restricciones: 32 CAP´ ITULO 2. GESTI ´ ON DEL PROYECTO Cuadro 2.19: Recursos humanos Nombre Rol Participaci´on Cristina S´anchez Responsable del proyecto Participa en todas las tareas del proyecto, asumiendo funciones de directora de proyecto, analista, dise˜nadora, programadora, gestora documental y responsable de pruebas Costes asociados a los RRHH Para realizar la estimaci´on de costes del proyecto, tendr´a en cuenta el salario percibido por un becario a media jornada en everis, que se sit´ua en 5040 euros anuales. Para calcular el coste de Cristina S´anchez en este proyecto, se calcular´a el coste por hora y se multiplicar´a por el n´umero de horas que dedicar´a al proyecto. Cuadro 2.20: Coste RRHH Recurso Coste/hora Total horas Coste empresa Cristina S´anchez 5.70 euros 412.5 3080.14 Asumiendo que el coste de la Seguridad Social asumido por la empresa se sit´ua alrededor del 31 %, el coste que representa un trabajador para la empresa, representado en la tabla 2.20, se obtiene sumando al salario del trabajador el 31 % del mismo. Costes materiales Los recursos materiales que se computar´an en el presente proyecto son el ordenador empleado para el desarrollo y el m´ovil destinado a la prueba del funcionamiento de la aplicaci´on Android. Cuadro 2.21: Costes materiales Material Precio Port´atil Dell Latitude E5550 1000 euros Smartphone Xiaomi Mi 4S 300 euros 2.5. GESTI ´ ON DE RRHH Y COSTES 33 El servidor utilizado para producci´on ser´a aportado por el cliente, por lo que no computa como gasto del proyecto. Dado que el equipo port´atil pertenece al inmoviliado de la empresa, el coste atribuible al proyecto es el de su amortizaci´on. Tomando como base el precio de compra del art´ıculo, 1000 euros y asumiendo una vida ´util del mismo de 4 a˜nos y un valor residual de 200 euros, el coste de amortizaci´on anual es: Coste de amortizaci´on anual = (Precio adquisici´on - Valor residual) * Coeficiente de amortizaci´on Asumiendo que la amortizaci´on es lineal, el coeficiente de amortizaci´on es del 25 % por lo que la amortizaci´on anual ser´a igual a: (1000 −200) ∗0,25 = 200 e Ponderando el resultado anterior por el n´umero de horas del proyecto con respecto a las horas anuales de uso del port´atil, se obtiene un coste para el proyecto de: 200 ∗(412,5/1768) = 46,66 e En cuanto al m´ovil, ser´a adquirido expresamente para el proyecto y, a la finalizaci´on del mismo ser´a entregado al cliente. Por lo tanto, se computar´a el coste ´ıntegro del mismo en el coste del proyecto. Costes indirectos Por ´ultimo, es preciso calcular los costes indirectos del proyecto, es decir, aquellos que no pueden ser directamente atribuibles al proyecto como luz, agua, alquiler del local, etc. El coste indirecto a imputar a los proyectos se fija por parte de la empresa. Este coste se establece en 6.5 euros por hora. La duraci´on estimada del proyecto es de 412.5 horas, por lo que los costes indirectos ascienden a 2681.25 euros. Coste total del proyecto Teniendo en cuenta todos los costes anteriores, se ha realizado el c´alculo del coste total del proyecto. Como puede observarse en la tabla 2.22, el coste total del proyecto asciende a 6108.05 euros 34 CAP´ ITULO 2. GESTI ´ ON DEL PROYECTO Cuadro 2.22: Coste total del proyecto Recurso Coste total Recursos humanos 3080.14 euros Material 346.66 euros Costes indirectos 2681.25 euros Total 6108.05 euros 2.6. Enunciado del alcance 2.6.1. Descripci´on del alcance del proyecto La finalidad del presente proyecto es desarrollar un sistema que permita realizar un seguimiento de pacientes en base a una serie de cuestionarios cl´ınicos designados por los facultativos. As´ı, ´estos asignar´an cada nuevo cuestionario a un tipo o grupo de pacientes, en funci´on de su patolog´ıa. Una vez el paciente haya contestado a un cuestionario, los facultativos podr´an acceder a informaci´on acerca del mismo. 2.6.2. Criterios de aceptaci´on del producto Al utilizarse una metodolog´ıa basada en iteraciones incrementales, la aceptaci´on del producto se llevar´a a cabo en diferentes fases a lo largo de todo el proyecto. Para ello, se mantendr´an reuniones con el cliente al finalizar cada iteraci´on, en las que ´este podr´a vertir sus opiniones acerca del producto presentado. El hecho de involucrar al cliente durante todo el proceso de desarrollo e irle mostrando los diversos productos incrementales que se desarrollan, lleva a que el producto final tenga altas probabilidades de satisfacer las expectativas del cliente. 2.6.3. Entregables del proyecto Tal y como se ha expuesto en diversos apartados anteriores, al final de cada iteraci´on el cliente dispone de un producto funcional que incluye los requisitos satisfechos hasta la ´ultima iteraci´on. De este modo, aunque el producto est´e inacabado, el cliente puede, si as´ı lo desea, empezar a trabajar con ´el. Al terminar el proyecto, el cliente recibir´a no s´olo el producto software desarrollado, sino tambi´en los manuales de usuario e instalaci´on del mismo. 2.6. ENUNCIADO DEL ALCANCE 35 2.6.4. Exclusiones del proyecto Se excluir´an del proyecto todos aquellos requisitos que no fuesen acordados con el cliente al inicio del mismo y que por su complejidad puedan dificultar o impedir la finalizaci´on del mismo en tiempo y forma. A pesar de que la metodolog´ıa escogida ofrece una alta tolerancia al cambio, no puede olvidarse que el presente proyecto se desarrolla en el marco de un Trabajo Fin de Grado, lo que implica que se dispone de una restricci´on temporal muy fuerte. 2.6.5. Supuestos del proyecto Se asume que el equipo de desarrollo contar´a con el material y el acceso a las herramientas necesarias al inicio del proyecto. 36 CAP´ ITULO 2. GESTI ´ ON DEL PROYECTO Cap´ıtulo 3 An´alisis de requisitos 3.1. Casos de uso del sistema . . . . . . . . . . . . . . . . . 39 3.2. Descripci´on de los actores del sistema . . . . . . . . . 39 3.3. Descripci´on de casos de uso . . . . . . . . . . . . . . . 39 3.4. Requisitos funcionales . . . . . . . . . . . . . . . . . . . 54 3.4.1. Identificaci´on de requisitos funcionales . . . . . . . . . 54 3.4.2. Especificaci´on de requisitos funcionales . . . . . . . . . 56 3.5. Matriz de trazabilidad . . . . . . . . . . . . . . . . . . 66 3.6. Requisitos no funcionales . . . . . . . . . . . . . . . . . 66 3.6.1. Requisitos del producto . . . . . . . . . . . . . . . . . 66 3.6.2. Requisitos de eficiencia . . . . . . . . . . . . . . . . . . 70 3.6.3. Requisitos externos . . . . . . . . . . . . . . . . . . . . 70 3.7. Restricciones de dise˜no . . . . . . . . . . . . . . . . . . 71 3.8. Seguridad .......................... 73 37 38 CAP´ ITULO 3. AN ´ ALISIS DE REQUISITOS 3.1. CASOS DE USO DEL SISTEMA 39 3.1. Casos de uso del sistema La extracci´on de casos de uso es una t´ecnica muy empleada para la captura de informaci´on procedente del cliente. Los casos de uso describen de forma informal la interacci´on entre los usuarios del sistema, que en este ´ambito se denominan actores, y el sistema a desarrollar. El conjunto de todos los casos de uso debe ilustrar a alto nivel la forma en la que se desea que el sistema funcione, sin abordar cuestiones propias de implementaci´on. Los actores son representaciones gen´ericas de los tipos de usuario que van a emplear el sistema. La relaci´on de un determinado actor con los casos de uso define la forma en la que ´este interaccionar´a con el sistema. 3.2. Descripci´on de los actores del sistema Facultativo: Actor que representa a un facultativo. Paciente: Actor que representa a un paciente. Es preciso explicar que el actor Facultativo s´olo se relacionar´a con la aplicaci´on web, mientras que el actor Paciente s´olo se relacionar´a con la aplicaci´on web. 3.3. Descripci´on de casos de uso Las reuniones preliminares con el cliente muestran una divisi´on del sistema en dos partes claramente diferenciadas: La gesti´on de cuestionarios y pacientes, que se realizar´a a trav´es de una aplicaci´on web a la que tendr´an acceso los facultativos. La respuesta de cuestionarios, que se realizar´a a trav´es de una aplicaci´on m´ovil a la que tendr´an acceso los pacientes. La figura 3.1 muestra el diagrama de casos de uso del sistema. 40 CAP´ ITULO 3. AN ´ ALISIS DE REQUISITOS Figura 3.1: Diagrama de casos de uso del sistema En primer lugar, se muestra un listado de los casos de uso identificados en el sistema a desarrollar: CU.1: Iniciar sesi´on facultativos CU.2: Crear cuestionario 3.3. DESCRIPCI ´ ON DE CASOS DE USO 41 CU.3: Bloquear cuestionario CU.4: Desbloquear cuestionario CU.5: Eliminar cuestionario CU.6: Listar cuestionarios CU.7: Listar pacientes CU.8: Mostrar gr´afico de puntuaciones CU.9: Mostrar tabla de puntuaciones CU.10: Modificar frecuencia CU.11: Cerrar sesi´on facultativos CU.12: Iniciar sesi´on pacientes CU.13: Responder cuestionario CU.14: Cerrar sesi´on pacientes A continuaci´on, se muestran los casos de uso que se identificaron en las reuniones mantenidas con el cliente. Las tablas 3.1 a 3.14 muestran la especificaci´on de los casos de uso identificados. 48 CAP´ ITULO 3. AN ´ ALISIS DE REQUISITOS Cuadro 3.7: Listar pacientes Identificador CU.07 Nombre Listar pacientes Prioridad Alta Subsistema Aplicaci´on web Dependencias CU.01 Descripci´on El sistema debe permitir listar pacientes Precondiciones El facultativo ha iniciado sesi´on en la aplicaci´on Existen pacientes en la base de datos Escenario principal 1. El facultativo selecciona la pesta˜na de gesti´on de pacientes. 2. El sistema recupera los pacientes 3. El sistema muestra los pacientes existentes 3.3. DESCRIPCI ´ ON DE CASOS DE USO 49 Cuadro 3.8: Mostrar gr´afico de puntuaciones Identificador CU.08 Nombre Mostrar gr´afico de puntuaciones Prioridad Alta Subsistema Aplicaci´on web Dependencias CU.01, CU.02, CU.13 Descripci´on El sistema debe permitir mostrar una gr´afica en la que se vean los resultados obtenidos en los cuestionarios respondidos por un paciente. Precondiciones El facultativo ha iniciado sesi´on en la aplicaci´on Existen cuestionarios en la base de datos Existen pacientes en la base de datos El paciente seleccionado ha respondido alg´un cuestionario Escenario principal 1. El facultativo selecciona la pesta˜na de vista general. 2. El sistema recupera los cuestionarios respondidos por el paciente 3. El sistema muestra las puntuaciones obtenidas de forma gr´afica 50 CAP´ ITULO 3. AN ´ ALISIS DE REQUISITOS Cuadro 3.9: Mostrar tabla de puntuaciones Identificador CU.09 Nombre Mostrar tabla de puntuaciones Prioridad Alta Subsistema Aplicaci´on web Dependencias CU.01, CU.02, CU.13 Descripci´on El sistema debe permitir mostrar una tabla en la que se vean los resultados obtenidos en los cuestionarios respondidos por un paciente junto con la puntuaci´on alcanzada. Precondiciones El facultativo ha iniciado sesi´on en la aplicaci´on Existen cuestionarios en la base de datos Existen pacientes en la base de datos El paciente seleccionado ha respondido alg´un cuestionario Escenario principal 1. El facultativo selecciona la pesta˜na de hist´orico. 2. El sistema recupera los cuestionarios respondidos por el paciente 3. El sistema muestra las puntuaciones obtenidas en una tabla 3.3. DESCRIPCI ´ ON DE CASOS DE USO 51 Cuadro 3.10: Modificar frecuencia Identificador CU.10 Nombre Modificar frecuencia Prioridad Alta Subsistema Aplicaci´on web Dependencias CU.01, CU.02 Descripci´on El sistema debe modificar la frecuencia con que cada cuestionario se env´ıa a los pacientes. Precondiciones El facultativo ha iniciado sesi´on en la aplicaci´on Existen cuestionarios en la base de datos Escenario principal 1. El facultativo selecciona la pesta˜na Gestionar cuestionarios en el men´u principal 2. El sistema muestra la pantalla de gesti´on de cuestionarios 3. El facultativo selecciona un cuestionario. 4. El sistema muestra la pesta˜na de edici´on del cuestionario. 5. El facultativo introduce la nueva frecuencia y pulsa Guardar 6. El sistema modifica la frecuencia de env´ıo del cuestionario seleccionado. 52 CAP´ ITULO 3. AN ´ ALISIS DE REQUISITOS Cuadro 3.11: Cerrar sesi´on facultativos Identificador CU.11 Nombre Cerrar sesi´on facultativos Prioridad Alta Subsistema Aplicaci´on web Dependencias CU.01 Descripci´on El sistema debe permitir cerrar la sesi´on a los facultativos. Precondiciones El facultativo ha iniciado sesi´on en la aplicaci´on Escenario principal 1. El facultativo pulsa el bot´on cerrar sesi´on 2. El sistema elimina todos los datos asociados a la sesi´on del usuario 3. El sistema redirige a la p´agina de login Cuadro 3.12: Iniciar sesi´on pacientes Identificador CU.12 Nombre Iniciar sesi´on pacientes Prioridad Alta Subsistema Aplicaci´on Android Dependencias Descripci´on El sistema debe disponer de un mecanismo de autenticaci´on que permita a los pacientes iniciar sesi´on en la aplicaci´on m´ovil. Precondiciones Existen pacientes en la base de datos Escenario principal 1. El usuario introduce sus datos de inicio de sesi´on 2. El sistema comprueba que el usuario y la contrase˜na sean correctos 3. Si los datos son correctos, el sistema almacena los datos del usuario en la sesi´on y muestra la pantalla principal de la aplicaci´on. 3.3. DESCRIPCI ´ ON DE CASOS DE USO 53 Cuadro 3.13: Responder cuestionario Identificador CU.13 Nombre Responder cuestionario Prioridad Alta Subsistema Aplicaci´on Android Dependencias CU.02, CU.12 Descripci´on El sistema debe permitir a los pacientes responder cuestionarios Precondiciones 1. El paciente ha iniciado sesi´on en la aplicaci´on 2. Existen cuestionarios en la base de datos 3. Existen cuestionarios que deben ser respondidos por el paciente Escenario principal 1. El usuario accede a la ventana principal de la aplicaci´on 2. El sistema muestra los tipos de cuestionario existentes 3. El sistema muestra los cuestionarios del tipo seleccionado que el paciente debe realizar, bas´andose en su patolog´ıa y en la ´ultima vez que realiz´o cada cuestionario 4. El paciente selecciona un cuestionario 5. El sistema muestra la lista de preguntas del cuestionario 6. El paciente responde a cada una de las preguntas que se le presentan 7. El sistema muestra la puntuaci´on del cuestionario 8. El sistema almacena el cuestionario en la base de datos 9. El paciente pulsa finalizar 10. El sistema muestra de nuevo la ventana principal de la aplicaci´on 54 CAP´ ITULO 3. AN ´ ALISIS DE REQUISITOS Cuadro 3.14: Cerrar sesi´on pacientes Identificador CU.14 Nombre Cerrar sesi´on pacientes Prioridad Alta Subsistema Aplicaci´on Android Dependencias CU.12 Descripci´on El sistema debe permitir cerrar la sesi´on a los pacientes. Precondiciones El facultativo ha iniciado sesi´on en la aplicaci´on Escenario principal 1. El paciente pulsa el bot´on cerrar sesi´on 2. El sistema elimina todos los datos asociados a la sesi´on del usuario 3. El sistema redirige a la p´agina de login 3.4. Requisitos funcionales Una vez se han identificado los casos de uso y tras realizar un an´alisis exhaustivo de los mismos, se procede a extraer las funcionalidades que definen el software tal y como el cliente lo entiende. Este proceso nos lleva a la identificaci´on y posterior especificaci´on de los requisitos funcionales. 3.4.1. Identificaci´on de requisitos funcionales En el presente proyecto, se han identificado los siguientes requisitos funcionales: RF.1: Asignar nombre a cuestionario RF.2: Asignar tipo a cuestionario RF.3: Asignar patolog´ıa a cuestionario RF.4: Asignar patr´on a cuestionario RF.5: Asignar frecuencia a cuestionario RF.6: Asignar pregunta a cuestionario RF.7: Asignar tipo a pregunta RF.8: Asignar respuesta a pregunta 3.4. REQUISITOS FUNCIONALES 55 RF.9: Asignar umbrales a cuestionario RF.10: Validar umbrales RF.11: Guardar cuestionario RF.12: Bloquear cuestionario RF.13: Desbloquear cuestionario RF.14: Eliminar cuestionario RF.15: Iniciar sesi´on facultativos RF.16: Listar cuestionarios RF.17: Listar pacientes RF.18: Obtener hist´orico de puntuaciones RF.19: Modificar frecuencia RF.20: Cerrar sesi´on facultativos RF.21: Cerrar sesi´on facultativos RF.22: Recuperar tipos de cuestionario RF.23: Recuperar patolog´ıas RF.24: Recuperar cuestionarios por tipo RF.25: Recuperar cuestionarios por patolog´ıa RF.26: Recuperar cuestionarios por pacientes RF.27: Listar preguntas y respuestas RF.28: Guardar cuestionario respondido RF.29: Asignar estado RF.30: Cerrar sesi´on pacientes RF.31: Recuperar datos de cuestionario 56 CAP´ ITULO 3. AN ´ ALISIS DE REQUISITOS 3.4.2. Especificaci´on de requisitos funcionales Las tablas 3.15 a 3.46 muestran la especificaci´on de los requisitos funcionales listados en el apartado anterior. Cuadro 3.15: Asignar nombre a cuestionario Identificador RF.01 Nombre Asignar nombre a cuestionario Prioridad Alta Versi´on 1.0 Dependencias CU.02 Descripci´on El sistema debe permitir a los facultativos asignar un nombre al cuestionario a crear. Cuadro 3.16: Asignar tipo a cuestionario Identificador RF.02 Nombre Asignar tipo a cuestionario Prioridad Alta Versi´on 1.0 Dependencias CU.02, RF.21 Descripci´on El sistema debe permitir a los facultativos asignar al cuestionario a crear un tipo de entre los disponibles en la base de datos. Se desarrollar´an los siguientes ejemplos particulares: Adherencia Seguimiento cl´ınico 3.4. REQUISITOS FUNCIONALES 57 Cuadro 3.17: Asignar patolog´ıa a cuestionario Identificador RF.03 Nombre Asignar patolog´ıa a cuestionario Prioridad Alta Versi´on 1.0 Dependencias CU.02, RF.22 Descripci´on El sistema debe permitir a los facultativos asignar una patolog´ıa al cuestionario de seguimiento a crear de entre las existentes en la base de datos. Se desarrollar´an los siguientes ejemplos particulares Enfermedad de Crohn Colitis ulcerosa Cuadro 3.18: Asignar patr´on a cuestionario Identificador RF.04 Nombre Asignar patr´on a cuestionario Prioridad Baja Versi´on 1.0 Dependencias CU.02 Descripci´on El sistema debe permitir a los facultativos asignar un patr´on a los cuestionarios para pacientes que padezcan patolog´ıas con patrones asociados. Cuadro 3.19: Asignar frecuencia a cuestionario Identificador RF.05 Nombre Asignar frecuencia a cuestionario Prioridad Alta Versi´on 1.0 Dependencias CU.02 Descripci´on El sistema debe permitir a los facultativos asignar una frecuencia al cuestionario a crear. 64 CAP´ ITULO 3. AN ´ ALISIS DE REQUISITOS Cuadro 3.39: Recuperar cuestionarios por paciente Identificador RF.25 Nombre Recuperar cuestionarios por paciente Prioridad Alta Versi´on 1.0 Dependencias CU.13 Descripci´on El sistema debe permitir los cuestionarios que un paciente debe hacer bas´andose en la ´ultima vez que realiz´o un cuestionario y la frecuencia del mismo. Cuadro 3.40: Listar preguntas y respuestas Identificador RF.26 Nombre Listar preguntas y respuestas Prioridad Alta Versi´on 1.0 Dependencias CU.13 Descripci´on El sistema debe mostrar cada una de las preguntas de un cuestionario junto con sus posibles respuestas Cuadro 3.41: Guardar cuestionario respondido Identificador RF.27 Nombre Guardar cuestionario respondido Prioridad Alta Versi´on 1.0 Dependencias CU.13 Descripci´on El sistema debe permitir guardar los datos asociados a cada cuestionario respondido por un paciente Cuadro 3.42: Iniciar sesi´on pacientes Identificador RF.28 Nombre Iniciar sesi´on pacientes Prioridad Alta Versi´on 1.0 Dependencias CU.12 Descripci´on El sistema debe disponer de un sistema de autenticaci´on que permita a los pacientes iniciar sesi´on en la aplicaci´on m´ovil 3.4. REQUISITOS FUNCIONALES 65 Cuadro 3.43: Calcular puntuaci´on Identificador RF.29 Nombre Calcular puntuaci´on Prioridad Alta Versi´on 1.0 Dependencias CU.13 Descripci´on El sistema debe asignar una puntuaci´on a cada cuestionario respondido, mediante la suma de las puntuaciones asociadas a cada una de las respuestas dadas por el paciente. Cuadro 3.44: Asignar estado Identificador RF.30 Nombre Asignar estado Prioridad Alta Versi´on 1.0 Dependencias CU.13 Descripci´on El sistema debe asignar un estado a cada cuestionario respondido, en funci´on de los umbrales definidos para el cuestionario correspondiente Cuadro 3.45: Cerrar sesi´on pacientes Identificador RF.31 Nombre Cerrar sesi´on pacientes Prioridad Alta Versi´on 1.0 Dependencias CU.11 Descripci´on El sistema debe permitir cerrar la sesi´on a los pacientes. Cuadro 3.46: Recuperar datos de cuestionario Identificador RF.32 Nombre Recuperar datos de cuestionario Prioridad Alta Versi´on 1.0 Dependencias CU.13 Descripci´on El sistema debe recuperar los datos asociados a un cuestionario a partir de su identificador. 66 CAP´ ITULO 3. AN ´ ALISIS DE REQUISITOS 3.5. Matriz de trazabilidad La tabla 3.47 muestra la matriz de trazabilidad, que relaciona los casos de uso con los requisitos funcionales. 3.6. Requisitos no funcionales Los requisitos no funcionales son aquellos que. si bien describen el proyecto, no pueden ser considerados como funcionalidades. En primer lugar, se listar´an los requisitos o funcionales que se han identificado y, posteriormente, ser´an especificados y clasificados seg´un su naturaleza. RNF.1: Localizaci´on material RNF.2: Facilidad de comprensi´on RNF.3: Localizaci´on de funcionalidades RNF.4: Documentaci´on eficaz RNF.5: Documentaci´on prescindible RNF.6: Coherencia orden botones RNF.7: Coherencia texto acciones RNF.8: Tiempo de respuesta RNF.9: Internacionalizaci´on RNF.10: Cumplimiento LOPD RNF.11: Plataforma RNF.12: Compatibilidad 3.6.1. Requisitos del producto Los requisitos del producto son restricciones sobre el comportamiento del sistema, por lo que establecen l´ımites sobre lo que los arquitectos e ingenieros software pueden hacer. 3.6. REQUISITOS NO FUNCIONALES 67 Cuadro 3.47: Matriz de trazabilidad CU-RF Casos de uso CU.01 CU.02 CU.03 CU.04 CU.05 CU.06 CU.07 CU.08 CU.09 CU.10 CU.11 CU.12 CU.13 CU.14 Requisitos funcionales RF.01 RF.02 RF.03 RF.04 RF.05 RF,06 RF.07 RF.08 RF.09 RF.10 RF.11 RF.12 RF.13 RF.14 RF.15 RF.16 RF.17 RF.18 RF.19 RF.20 RF.21 RF.22 RF.23 RF.24 RF.25 RF.26 RF.27 RF.28 RF.29 RF.30 RF.31 RF.32 68 CAP´ ITULO 3. AN ´ ALISIS DE REQUISITOS Requisitos de usabilidad Los requisitos de usabilidad son aquellos que definen el esfuerzo que necesita hacer un usuario para aprender, usar, ingresar datos e interpretar los resultados obtenidos de una aplicaci´on. Cuadro 3.48: Localizaci´on material Identificador RNF.USA.01 Nombre Localizaci´on material Prioridad Alta Versi´on 1.0 Descripci´on Los usuarios ser´an capaces de localizar el material de formaci´on r´apidamente Cuadro 3.49: Facilidad de comprensi´on Identificador RNF.USA.02 Nombre Facilidad de comprensi´on Prioridad Alta Versi´on 1.0 Descripci´on Los usuarios estar´an en condiciones de utilizar correctamente cualquier funcionalidad principal del sistema tras la lectura del material de formaci´on. Una funcionalidad se considera principal si aparece en el diagrama de casos de uso general del sistema. Cuadro 3.50: Localizaci´on de funcionalidades Identificador RNF.USA.03 Nombre Localizaci´on de funcionalidades Prioridad Alta Versi´on 1.0 Descripci´on Los usuarios podr´an localizar cualquier funcionalidad principal del sistema r´apidamente. Una funcionalidad se considera principal si aparece en el diagrama de casos de uso general del sistema. 3.6. REQUISITOS NO FUNCIONALES 69 Cuadro 3.51: Documentaci´on eficaz Identificador RNF.USA.04 Nombre Documentaci´on eficaz Prioridad Alta Versi´on 1.0 Descripci´on Los usuarios estar´an en condiciones de utilizar correctamente cualquier funcionalidad del sistema tras la lectura del material de formaci´on. Cuadro 3.52: Documentaci´on prescindible Identificador RNF.USA.05 Nombre Documentaci´on prescindible Prioridad Alta Versi´on 1.0 Descripci´on Los usuarios estar´an en condiciones de utilizar correctamente y sin consultar el material de formaci´on cualquier funcionalidad principal del sistema tras un breve periodo de uso. Una funcionalidad se considera principal si aparece en el diagrama de casos de uso general del sistema. Cuadro 3.53: Coherencia orden botones Identificador RNF.USA.06 Nombre Coherencia orden botones Prioridad Alta Versi´on 1.0 Descripci´on Dos botones siempre deben aparecer en el mismo orden en cualquier p´agina. Cuadro 3.54: Coherencia texto acciones Identificador RNF.USA.07 Nombre Coherencia texto acciones Prioridad Alta Versi´on 1.0 Descripci´on El texto relacionado con acciones del mismo tipo est´andar har´an uso siempre del mismo verbo. Los tipos est´andar de acciones ser´an guardar, eliminar, suprimir, modificar y ver detalle. 70 CAP´ ITULO 3. AN ´ ALISIS DE REQUISITOS 3.6.2. Requisitos de eficiencia Los requisitos de eficiencia est´an relacionados con el desempe˜no en cuanto a tiempo de respuesta, n´umero de operaciones por segundo, consumo de memoria, etc. Cuadro 3.55: Tiempo de respuesta Identificador RNF.EFI.01 Nombre Tiempo de respuesta Prioridad Alta Versi´on 1.0 Descripci´on El tiempo de respuesta ante cualquier petici´on HTTP debe ser inferior a 2 segundos. La medici´on se realizar´a desde el entorno de preproducci´on, considerando un acceso concurrente de 50 usuarios, y sin que interfiera ning´un otro sistema con el que comparta recursos. En caso de que en alguna petici´on concreta, por motivos de complejidad, no sea viable t´ecnicamente satisfacer esta medida, se justificar´a adecuadamente.” Requisitos de mantenibilidad Cuadro 3.56: Internacionalizaci´on Identificador RNF.MAN.01 Nombre Internacionalizaci´on Prioridad Alta Versi´on 1.0 Descripci´on La aplicaci´on debe poder traducirse a otros idiomas sin necesidad de modificar ninguna l´ınea de c´odigo m´as que enumerados en caso de que el dise˜no as´ı lo requiera. 3.6.3. Requisitos externos Los requisitos externos se derivan del entorno organizacional en el cual se desarrolla el sistema y pueden hacerse tanto sobre el producto como sobre el proceso de desarrollo de software. Requisitos legales Los requisitos legales hacen referencia a leyes y reglamentos que establecen qu´e debe hacer el sistema y c´omo debe hacerlo para cumplir con las disposiciones legales. 3.7. RESTRICCIONES DE DISE ˜ NO 71 Cuadro 3.57: Cumplimiento LOPD Identificador RNF.LEG.01 Nombre Cumplimiento LOPD Prioridad Alta Versi´on 1.0 Descripci´on Las medidas t´ecnicas aplicables sobre cada nivel y tipo de dato recogido de car´acter personal ser´an las establecidas por la Ley Org´anica 15/1999, de 13 de diciembre, de Protecci´on de Datos de Car´acter Personal [16]. Requisitos de implementaci´on Los requisitos de implementaci´on indican las pautas que deben seguirse a la hora de implementar el sistema. Cuadro 3.58: Plataforma Identificador RNF.IMP.01 Nombre Plataforma Prioridad Alta Versi´on 1.0 Descripci´on La aplicaci´on m´ovil debe ser compatible con dispositivos Android 4.2 y posterior (API Level 17) Cuadro 3.59: Compatibilidad Identificador RNF.IMP.02 Nombre Compatibilidad Prioridad Alta Versi´on 1.0 Descripci´on La aplicaci´on web debe visualizarse correctamente en el navegador Internet Explorer 8. 3.7. Restricciones de dise˜no En este ep´ıgrafe se expondr´an las restricciones de dise˜no que debe tener en cuenta el equipo de desarrollo a la hora de enfrentarse al proyecto. Estas restricciones pueden venir impuestas por el cliente, por everis o por las propias caracter´ısticas del proyecto. 72 CAP´ ITULO 3. AN ´ ALISIS DE REQUISITOS Cuadro 3.60: Framework de desarrollo - ehCOS Identificador RD.01 Nombre Framework de desarrollo - ehCOS Prioridad Alta Origen everis Dependencias Descripci´on El desarrollo de la aplicaci´on web debe hacerse utilizando el framework de desarrollo ehCOS, propiedad de everis. Cuadro 3.61: Framework de desarrollo - ehCOS mobile Identificador RD.02 Nombre Framework de desarrollo - ehCOS mobile Prioridad Alta Origen everis Dependencias Descripci´on El desarrollo de la aplicaci´on m´ovil debe hacerse utilizando el framework de desarrollo ehCOS mobile, propiedad de everis. Cuadro 3.62: Framework de desarrollo - ZK Identificador RD.03 Nombre Framework de desarrollo - ZK Prioridad Alta Origen everis Dependencias Descripci´on El desarrollo front-end de la aplicaci´on m´ovil debe hacerse utilizando el framework ZK. Cuadro 3.63: lenguaje de programaci´on - Java Identificador RD.04 Nombre Lenguaje de programaci´on - Java Prioridad Alta Origen everis Dependencias Descripci´on El desarrollo back-end de la aplicaci´on web debe realizarse utilizando Java como lenguaje de programaci´on. 3.8. SEGURIDAD 73 Cuadro 3.64: Versi´on de Java - 1.6 Identificador RD.05 Nombre Versi´on de Java - 1.6 Prioridad Alta Origen Cliente Dependencias Descripci´on El desarrollo de la aplicaci´on web debe realizarse utilizando Java en su versi´on 1.6. 3.8. Seguridad En un principio, las peticiones que se hagan al servidor no estar´an securizadas, ya que, para ello, ser´ıa necesario disponer de un certificado, lo que requiere que la aplicaci´on se encuentre desplegada en una direcci´on IP con dominio asignado. Dado que antes de lanzar la aplicaci´on, se har´a un piloto con pacientes, se ha decidido esperar a comprar el dominio y solicitar el certificado una vez el piloto haya finalizado de forma exitosa. Sin embargo, para garantizar la confidencialidad de los datos durante el piloto, no se trabajar´a con datos reales de pacientes en la aplicaci´on, sino que cada paciente estar´a identificado por un c´odigo aleatorio, de modo que s´olo los facultativos de la unidad de digestivo conozcan la correspondencia entre el c´odigo y el paciente real. 80 CAP´ ITULO 4. DISE ˜ NO Figura 4.3: Arquitectura Modelo-Vista-Controlador Modelo: El modelo gestiona el comportamiento y los datos del dominio de la aplicaci´on, responde a peticiones de informaci´on sobre su estado (t´ıpicamente desde la vista), y a instrucciones de cambio de estado (t´ıpicamente desde el controlador). Vista: La vista maneja la representaci´on de la informaci´on. Controlador: El controlador interpreta las ´ordenes del usuario, informando al modelo y/o la vista para que cambien de la forma correspondiente. De este modo, es posible modificar el comportamiento interno de la aplicaci´on sin necesidad de realizar cambios en la interfaz gr´afica. Es decir, por un lado tenemos componentes que definen la representaci´on de la informaci´on, y por otro, la interacci´on con el usuario. Es importante destacar que tanto la Vista como el Controlador son dependientes del Modelo. Sin embargo, el Modelo no depende ni de la Vista ni del Controlador. Esta es una de las claves que fomentan la separaci´on, lo que permite que el modelo sea testado independientemente de la representaci´on visual. La separaci´on entre vista y controlador es secundaria en muchas ocasiones y, de hecho, muchos frameworks implementan ambos roles como un solo objeto [17]. En aplicaciones web, sin embargo, la separaci´on entre la Vista y el Controlador suele estar muy bien definida. 4.2.2. Patr´on DTO El patr´on DTO es un patr´on de dise˜no que se utiliza para aislar el dominio de la presentaci´on [18]. As´ı, cuando una entidad se recupera de la base de datos, es convertida a un DTO, de modo que tanto el controlador como la capa de servicios de la aplicaci´on trabajar´an con el objeto DTO, en lugar de trabajar directamente sobre la entidad, mientras que las entidades o clases persistentes s´olo se usar´an en la capa de servicios para la comunicaci´on con la capa de acceso a datos. La figura 4.4 ilustra el patr´on DTO. 4.2. PATRONES DE DISE ˜ NO 81 Figura 4.4: Patr´on DTO Las ventajas de utilizar DTOs en lugar de usar siempre objetos persistentes son las siguientes: Supone una capa de abstracci´on que permite ocultar aquellos componentes propios del m´odulo de datos que no se quiera que sean visibles a trav´es de los servicios. Por ejemplo, la tabla usuario de la aplicaci´on contiene un campo contrase˜na. Sin embargo, este campo s´olo es necesario a la hora de iniciar sesi´on, y puede ser que no queramos que el resto de servicios de la aplicaci´on que necesiten datos del usuario reciban este campo. Para ello, podr´ıamos hacer una conversi´on de la clase persistente Usuario a UsuarioDTO, siendo este ´ultimo una clase que contenga todos los campos de Usuario, a excepci´on de contrase˜na. Permite eliminar aquellos par´ametros de auditor´ıa presentes en las tablas y clases persistentes que no sean necesarios para el funcionamiento de la aplicaci´on. Por ejemplo, imaginemos que queremos llevar un registro de qu´e usuario ha modificado qu´e filas de la base de datos y en qu´e momento. Para ello, a la hora de crear o modificar objetos en la base de datos, la consulta SQL que se generar´a, y por tanto el objeto persistente, contendr´an datos referentes al usuario que realiza la modificaci´on y la fecha. Sin embargo, estos datos no son necesarios para el correcto funcionamiento de la aplicaci´on, por lo que suponen un tr´afico de datos innecesario. Las clases persistentes est´an condicionadas por el mapeo que se realiza con la base de datos, sin embargo, en ocasiones, es necesario que un servicio 82 CAP´ ITULO 4. DISE ˜ NO Figura 4.5: Patr´on DAO devuelva informaci´on que se encuentra en diferentes clases, o incluso informaci´on que no se relaciona directamente con contenido de la base de datos, y que es calculada a partir de los datos de una clase. El patr´on DTO permite la creaci´on de una clase personalizada que contenga los datos necesarios que debe recibir o devolver un servicio. Por ejemplo, si vamos a utilizar servicios REST, s´olo podemos enviar un objeto en el cuerpo de la llamada. Sin embargo, es posible que tengamos que transmitir datos pertenecientes a dos o m´as entidades diferentes, por lo que necesitar´ıamos crear un objeto DTO que encapsule todos los par´ametros necesarios para llamar al servicio. 4.2.3. Patr´on DAO Para la implementaci´on de la capa de acceso a datos se har´a uso del patr´on DAO (Data Access Object). Se trata de un patr´on introducido en el desarrollo de aplicaciones J2EE y consiste en la definici´on de una capa de acceso a los datos, de forma que la aplicaci´on no tiene por qu´e conocer el destino de los mismos ni su tipo de almacenamiento, tan s´olo las operaciones definidas para cada tipo de dato. La figura 4.5 ilustra el patr´on DAO [19]. T´ıpicamente, este patr´on se implementa mediante la definici´on de interfaces DAO, que son las que utilizar´an los servicios que acceden a los datos para conocer cu´ales son las operaciones que pueden utilizar. Siguiendo este patr´on, se crear´a un DAO por cada clase persistente o entity. 4.3. Subsistema servidor El subsistema servidor es el encargado del procesamiento de peticiones por parte de los clientes, actuando como un intermediario entre ´estos y el almacenamiento de datos. 4.4. SUBSISTEMA APLICACI ´ ON WEB 83 El subsistema servidor se comunica con los clientes mediante el intercambio de Data Transfer Objects, y aplica el patr´on DAO para el acceso a datos. Tal y como refleja la figura 4.1, la comunicaci´on con la aplicaci´on web se realiza a trav´es de peticiones HTTP, mientras que la comunicaci´on con la aplicaci´on m´ovil se realiza a trav´es de servicios REST. Dada la envergadura del diagrama de clases del servidor, se ha decidido dividirlo en diagramas m´as peque˜nos donde se muestre la relaci´on de cada uno de los servicios con el resto de clases del sistema. Los servicios act´uan como puente entre los controladores y los datos del sistema, por lo que, de este modo, podemos conocer sus relaciones y se da lugar a diagramas lo suficientemente sencillos como para que ´estas se puedan apreciar f´acilmente. El diagrama completo ser´a entregado como anexo al presente documento. Los diagramas correspondientes a los servicios pueden consultarse en las figuras 4.6 a 4.16. 4.4. Subsistema aplicaci´on web El subsistema aplicaci´on web act´ua como uno de los clientes del sistema, siendo una interfaz entre los facultativos y los servicios asociados a la gesti´on de pacientes y cuestionarios. El cliente web trabaja con DTOs obtenidos del servidor a trav´es de peticiones HTTP, y su arquitectura est´a basada en el Modelo-VistaControlador. El diagrama de clases de este subsistema puede consultarse en la figura 4.17. Por simplicidad del diagrama, y para facilitar su inclusi´on en la memoria, no se muestran las interfaces, ni tampoco los atributos y m´etodos de las clases. Por otro lado, tampoco se muestra la relaci´on de este sistema con los datos, si bien se puede inferir de los servicios con los que se relaciona cada una de las clases, y de las relaciones presentes en las figuras 4.6 a 4.16. 4.5. Subsistema aplicaci´on m´ovil El subsistema aplicaci´on m´ovil act´ua como otro cliente del sistema, siendo una interfaz entre los pacientes y los servicios asociados a la respuesta de cuestionarios. En este subsistema se trabaja con DTOs obtenidos del servidor a trav´es de servicios REST, y su arquitectura est´a basada en el Modelo-Vista-Controlador. Dado que los facultativos pueden crear, editar o eliminar cuestionarios en cualquier momento, la aplicaci´on obtiene siempre los datos del servidor, en lugar de almacenar una copia en la base de datos de Android, de modo que se asegura que siempre se trabaje con datos actualizados. La figura 4.18 muestra el diagrama de clases de la aplicaci´on web. Por simplicidad del diagrama, y para facilitar su inclusi´on en la memoria, no se muestran 84 CAP´ ITULO 4. DISE ˜ NO Figura 4.6: CuestionarioService 4.5. SUBSISTEMA APLICACI ´ ON M ´ OVIL 85 Figura 4.7: LineChartEngine Figura 4.8: EstadoService Figura 4.9: PacienteService Figura 4.10: PatologiaService 86 CAP´ ITULO 4. DISE ˜ NO Figura 4.11: RespuestaService Figura 4.12: MasterService 4.5. SUBSISTEMA APLICACI ´ ON M ´ OVIL 87 Figura 4.13: RespuestaCuestionarioService 88 CAP´ ITULO 4. DISE ˜ NO Figura 4.14: UmbralService las interfaces, ni tampoco los atributos y m´etodos de las clases. Por otro lado, tampoco se muestra la relaci´on de este sistema con los datos, si bien se puede inferir de los servicios con los que se relaciona cada una de las clases. En la figura 4.19 se muestra la relaci´on entre la aplicaci´on Android y los servicios del servidor, por medio de servicios REST. 4.6. Base de datos En este ep´ıgrafe se presenta el diagrama entidad-relaci´on que define la base de datos que se implementar´a en el sistema. En este caso, tan s´olo se especificar´an en el dise˜no las tablas implementadas ad-hoc para el proyecto, aunque el sistema har´a uso tambi´en de tablas correspondientes al framework ehCOS. El diagrama entidad-relaci´on se muestra en la figura 4.20. 4.7. Diagramas de secuencia Un diagrama de secuencia muestra la interacci´on de un conjunto de objetos en una aplicaci´on a trav´es del tiempo y permite modelar cada caso de uso. Mientras que el diagrama de casos de uso es independiente de la implementaci´on, 4.7. DIAGRAMAS DE SECUENCIA 89 Figura 4.15: PreguntaService 96 CAP´ ITULO 4. DISE ˜ NO Figura 4.22: Diagrama de secuencia del caso de uso Responder Cuestionario 4.8. AN ´ ALISIS DE TECNOLOG´ IAS 97 Base de datos de pruebas En cuanto a la base de datos de pruebas, se ha contemplado el uso de una base de datos en disco o en memoria. Finalmente, dado que su rendimiento es mayor, y no se necesita que los datos de los tests sean persistentes, se ha decidido emplear una base de datos en memoria que se crea antes de cada test, y se vac´ıa al final del mismo, lo que garantiza que sucesivas ejecuciones de un mismo test produzcan siempre el mismo resultado. La tecnolog´ıa concreta que se emplear´a es H2, configurada en modo PostgreSQL, por ser un sistema que cuenta con amplia documentaci´on y facilidad de uso. 4.8.3. Seguimiento de incidencias La gesti´on de incidencias del proyecto se llevar´a a cabo utilizando Atlassian Jira, por ser la herramienta utilizada por la empresa. 4.8.4. Entorno de desarrollo El IDE utilizado para desarrollar el servidor y la aplicaci´on web para facultativos ser´a Eclipse, al ser el IDE utilizado habitualmente en everis. Adem´as, se trata de un IDE con el que hab´ıa trabajado anteriormente, por lo que se elimina la necesidad de formaci´on. Por su parte, la aplicaci´on Android se ha desarrollado utilizando Android Studio, pues as´ı se recomienda en las gu´ıas de desarrollo de Google. 4.8.5. Comunicaci´on entre sistemas La comunicaci´on entre el servidor y la aplicaci´on web se hace a trav´es de servicios REST. Se ha optado por usar servicios REST en lugar de SOAP, ya que los servicios REST son m´as indicados en el caso de aplicaciones m´oviles, donde una buena gesti´on de los recursos es fundamental. En este caso, se ha optado por el uso de la librer´ıa Retrofit, pues, aunque en un principio las peticiones no van a estar securizadas, soporta tambi´en peticiones HTTPS. Se trata adem´as de una librer´ıa gratuita, de c´odigo abierto y ampliamente documentada, lo que facilita la formaci´on del equipo de desarrollo en esta tecnolog´ıa. 4.8.6. Librer´ıa de gr´aficos A la hora de escoger una librer´ıa que permitiese la creaci´on de gr´aficos en la aplicaci´on web, se han contemplado las siguientes opciones: ZK Charts 98 CAP´ ITULO 4. DISE ˜ NO Google Charts ZK Google Charts JFreeChart Inicialmente, se plante´o ZK Charts como la opci´on id´onea, por ofrecer integraci´on plena con ZK, uno de los frameworks de desarrollo empleados en el proyecto. Sin embargo, no es gratuita, y, aunque ofrece 60 d´ıas de prueba gratis, la posible introducci´on de modificaciones posteriores a este periodo encarecer´ıa el coste del proyecto u obligar´ıa a reimplementar la creaci´on de gr´aficas empleado una librer´ıa diferente. Por este motivo, se ha desestimado su uso. En cuanto a Google Charts, se trata de una alternativa gratuita y ampliamente documentada. Sin embargo, funciona sobre JavaScript, y no sobre Java, que es el lenguaje que se ha empleado en el proyecto. A pesar de que ser´ıa posible emplearlo a´un teniendo en cuenta esta restricci´on, se ha desestimado su uso dada la existencia de librer´ıas para Java. Por su parte, ZK Google Charts es una librer´ıa intermedia que permite el uso de Google Charts sobre Java yZK. Sin embargo, se encuentra en una fase muy temprana de su desarrollo, y s´olo soporta algunas de las gr´aficas soportadas por Google Charts. Concretamente, no soporta la creaci´on de gr´aficos de l´ıneas, necesarios en este proyecto, por lo que su uso no es posible. Por ´ultimo, JFreeChart es una librer´ıa gratuita para Java, que soporta el tipo de gr´afico necesario para la aplicaci´on. Presenta como inconveniente que es una librer´ıa algo antigua, por lo que est´eticamente no es demasiado bonita, y su documentaci´on es bastante escueta. Sin embargo, al correr directamente sobre Java, se presenta como la mejor opci´on en t´erminos de rendimiento, y ha sido utilizada por compa˜neros del lugar de trabajo, lo que minimiza el impacto de disponer de escasa documentaci´on. 4.8.7. Acceso a datos La empresa en la que se ha desarrollado el proyecto cuenta con un framework de desarrollo propio que dispone de m´etodos de acceso a datos que funcionan sobre Hibernate. Dado que este framework es utilizado en todos los proyectos sanitarios desarrollados por everis, se ha empleado dicho framework para el desarrollo, lo que ha condicionado a su vez el framework de acceso a datos. En los casos en que ha sido necesario modificar las consultas proporcionadas por el framework ehCOS, se ha hecho uso de QueryDSL, al ser una tecnolog´ıa tambi´en utilizada por el propio framework. 4.8. AN ´ ALISIS DE TECNOLOG´ IAS 99 4.8.8. Inyecci´on de dependencias El framework propietario de la empresa para desarrollo web (ehCOS) incluye tambi´en dependencias con Spring IoC, por lo que se ha empleado esta tecnolog´ıa como framework para inyecci´on de dependencias en la aplicaci´on web. Por su parte, en el caso de la aplicaci´on m´ovil, se usar´a para tal efecto el framework ehCOS mobile, empleado por everis en todos sus desarrollos de aplicaciones nativas Android en entornos sanitarios. 4.8.9. Librer´ıa de serializaci´on/deserializaci´on En la aplicaci´on m´ovil es necesario disponer de un m´etodo de conversi´on de objetos Java aJSON, para as´ı poder comunicarse con los servicios REST. En este caso, se ha optado por utilizar gson, librer´ıa propiedad de Google, por ser plenamente compatible con el SDK Android y disponer de una amplia documentaci´on. Adem´as, esta librer´ıa est´a incorporada en las ´ultimas versiones de ehCOS mobile, por lo que su uso optimiza el tama˜no de la aplicaci´on que se genere, frente al uso de otras librer´ıas. 100 CAP´ ITULO 4. DISE ˜ NO Cap´ıtulo 5 Desarrollo 5.1. Organizaci´on del trabajo . . . . . . . . . . . . . . . . . 103 101 102 CAP´ ITULO 5. DESARROLLO 5.1. ORGANIZACI ´ ON DEL TRABAJO 103 5.1. Organizaci´on del trabajo A pesar de que tradicionalmente la metodolog´ıa escogida est´a pensada de forma que el dise˜no de la aplicaci´on se realice de forma incremental al comienzo de cada iteraci´on, la alta incertidumbre presente al inicio del proyecto ha llevado al equipo de desarrollo a realizar una breve descripci´on de los requisitos capturados, as´ı como un prototipo horizontal en forma de mockups, para present´arselos al cliente antes de comenzar el desarrollo del proyecto. De este modo, es posible evaluar desde un primer momento la correcta comprensi´on de las necesidades del cliente. Adem´as, durante esta fase tambi´en se ha realizado un estudio de las tecnolog´ıas a emplear y de las necesidades de formaci´on del equipo de desarrollo. Sin embargo, es posible que surjan necesidades de formaci´on en fases posteriores del proyecto debido a cambios en los requisitos o en las tecnolog´ıas a emplear. Iteraci´on 0 Duraci´on: 80 horas (15 de febrero - 13 de marzo) Descripci´on: La iteraci´on 0 incluye tareas de gesti´on del proyecto y an´alisis previo. Tareas: Enunciado del alcance Objetivos del proyecto Estudio de tecnolog´ıas Formaci´on inicial Elecci´on de la metodolog´ıa de desarrollo Breve descripci´on de requisitos Prototipo horizontal Iteraci´on 1 Duraci´on: 100 horas (14 de marzo - 17 de abril) Descripci´on: La iteraci´on 1 incluye tareas de la fase de desarrollo. Requisitos implementados: RF.01, RF.02, RF.03, RF.04, RF.05, RF.06, RF.07, RF.08, RF.09, RF.10, RF.11, RF.15, RF.21, RF.22 Tareas: Creaci´on de cuestionarios Inicio de sesi´on para facultativos 104 CAP´ ITULO 5. DESARROLLO Iteraci´on 2 Duraci´on: 60 horas (18 de abril - 8 de mayo) Descripci´on: La iteraci´on 2 incluye tareas de la fase de desarrollo. Requisitos implementados: RF.12, RF.13, RF.14, RF.16, RF.19, RF.20, RF.23 Tareas: Visualizaci´on de cuestionarios creados Modificar frecuencia de cuestionarios Bloquear cuestionarios Eliminar cuestionarios Desbloquear cuestionarios Iteraci´on 3 Duraci´on: 80 horas (9 de mayo - 5 de junio) Descripci´on: La iteraci´on 3 incluye tareas de la fase de desarrollo. Requisitos implementados: RF.24, RF.25, RF.26, RF.27, RF.28, RF.29, RF.30, RF.31 Tareas: Recuperar cuestionarios disponibles para cada paciente Mostrar preguntas del cuestionario Almacenar cuestionario respondido Iteraci´on 4 Duraci´on: 70 horas (6 de junio - 29 de junio) Descripci´on: La iteraci´on 4 incluye tareas de la fase de desarrollo. Requisitos implementados: RF.17, RF.18 Tareas: Listar pacientes con su estado asociado Mostrar gr´afica de resultados Mostrar gr´afica de resultados Mostrar respuestas a los cuestionarios respondidos 5.1. ORGANIZACI ´ ON DEL TRABAJO 105 Iteraci´on 5 Duraci´on: 45 horas (30 de junio - 7 de julio) Descripci´on: La iteraci´on 5 incluye tareas de las fases de gesti´on del proyecto y cierre Requisitos implementados: N/A Tareas: Finalizar memoria del proyecto Cierre del proyecto Entrega La duraci´on de las iteraciones mostradas no representa una planificaci´on, sino el tiempo aproximado que se ha tardado en terminar las mismas. Para obtener esta informaci´on, se han consultado tanto la lista de tareas en Jira como los commits realizados en el SVN del proyecto. Como se puede observar, la duraci´on de las iteraciones oscila entre las 45 y las 100 horas, y entre las 60 y las 80 horas si s´olo tomamos en cuenta la duraci´on de las iteraciones de desarrollo propiamente dichas. Teniendo en cuenta que partimos de una jornada laboral de 20 horas semanales, cada iteraci´on tiene una duraci´on de entre 3 y 4 semanas. Dado que la metodolog´ıa escogida implica la secuenciaci´on de iteraciones, es decir, una iteraci´on comienza inmediatamente despu´es de finalizar al anterior, no se ha considerado necesaria la inclusi´on de un cronograma en forma de diagrama de Gantt. Globalmente, el producto que se ha desarrollado en los incrementos presentados anteriormente satisface los requisitos planteados de mayor importancia, por lo que se puede concluir que el resultado ha sido satisfactorio. 112 CAP´ ITULO 6. PRUEBAS Cuadro 6.6: Guardar cuestionario sin patolog´ıa Identificador PU.06 Nombre Guardar cuestionario sin patolog´ıa RF/CU a probar CU.02 Descripci´on Se realiza una llamada al servicio de guardado de cuestionarios, indicando un cuestionario con el campo patolog´ıa vac´ıo Resultado esperado Se lanza una excepci´on Resultado Validaci´on correcta Cuadro 6.7: Guardar cuestionario sin preguntas Identificador PU.07 Nombre Guardar cuestionario sin preguntas RF/CU a probar CU.02 Descripci´on Se realiza una llamada al servicio de guardado de cuestionarios, indicando un cuestionario con el campo preguntas vac´ıo Resultado esperado Se lanza una excepci´on Resultado Validaci´on correcta Cuadro 6.8: Guardar cuestionario sin respuestas Identificador PU.08 Nombre Guardar cuestionario sin respuestas RF/CU a probar CU.02 Descripci´on Se realiza una llamada al servicio de guardado de cuestionarios, indicando un cuestionario con el campo respuestas vac´ıo Resultado esperado Se lanza una excepci´on Resultado Validaci´on correcta 6.1. PROCESO DE PRUEBAS 113 Cuadro 6.9: Guardar cuestionario sin tipo Identificador PU.09 Nombre Guardar cuestionario sin tipo RF/CU a probar CU.02 Descripci´on Se realiza una llamada al servicio de guardado de cuestionarios, indicando un cuestionario con el campo tipo vac´ıo Resultado esperado Se lanza una excepci´on Resultado Validaci´on correcta Cuadro 6.10: Bloquear cuestionario existente Identificador PU.10 Nombre Bloquear cuestionario existente RF/CU a probar RF.12 Descripci´on Se realiza una llamada al servicio de bloqueo de cuestionarios, indicando un cuestionario existente Resultado esperado El cuestionario seleccionado aparece como bloqueado Resultado Validaci´on correcta Cuadro 6.11: Bloquear cuestionario no existente Identificador PU.11 Nombre Bloquear cuestionario no existente RF/CU a probar RF.12 Descripci´on Se realiza una llamada al servicio de bloqueo de cuestionarios, indicando un cuestionario que no existe Resultado esperado Se lanza una excepci´on Resultado Validaci´on correcta 114 CAP´ ITULO 6. PRUEBAS Cuadro 6.12: Desbloquear cuestionario existente Identificador PU.12 Nombre Desbloquear cuestionario existente RF/CU a probar RF.13 Descripci´on Se realiza una llamada al servicio de desbloqueo de cuestionarios, indicando un cuestionario existente Resultado esperado El cuestionario seleccionado aparece como bloqueado Resultado Validaci´on correcta Cuadro 6.13: Desbloquear cuestionario no existente Identificador PU.13 Nombre Desbloquear cuestionario no existente RF/CU a probar RF.13 Descripci´on Se realiza una llamada al servicio de desbloqueo de cuestionarios, indicando un cuestionario que no existe Resultado esperado Se lanza una excepci´on Resultado Validaci´on correcta Cuadro 6.14: Modificar frecuencia Identificador PU.14 Nombre Modificar frecuencia RF/CU a probar RF.19 Descripci´on Se realiza una llamada al servicio de bloqueo de cuestionarios, indicando un cuestionario existente y una frecuencia entera positiva Resultado esperado Se modifica el cuestionario y su frecuencia pasa a ser la frecuencia indicada Resultado Validaci´on correcta 6.1. PROCESO DE PRUEBAS 115 Cuadro 6.15: Modificar frecuencia cuestionario no existente Identificador PU.15 Nombre Modificar frecuencia cuestionario no existente RF/CU a probar RF.19 Descripci´on Se realiza una llamada al servicio de modificaci´on de frecuencia de cuestionarios, indicando como par´ametro un cuestionario no existente (id = 1) Resultado esperado Se lanza una excepci´on Resultado Validaci´on correcta Cuadro 6.16: Modificar frecuencia cuestionario con frecuencia negativa Identificador PU.16 Nombre Modificar cuestionario con frecuencia negativa RF/CU a probar RF.19 Descripci´on Se realiza una llamada al servicio de modificaci´on de cuestionarios, indicando un cuestionario existente y una frecuencia entera negativa Resultado esperado Se lanza una excepci´on Resultado Validaci´on correcta Cuadro 6.17: Eliminar cuestionario Identificador PU.17 Nombre Eliminar cuestionario RF/CU a probar RF.14 Descripci´on Se realiza una llamada al servicio de borrado de cuestionarios, indicando como par´ametro un cuestionario existente Resultado esperado El cuestionario indicado se elimina de la base de datos Resultado Validaci´on correcta 116 CAP´ ITULO 6. PRUEBAS Cuadro 6.18: Eliminar cuestionario no existente Identificador PU.18 Nombre Eliminar cuestionario no existente RF/CU a probar RF.14 Descripci´on Se realiza una llamada al servicio de borrado de cuestionarios, indicando como par´ametro un cuestionario que no existe Resultado esperado Se lanza una excepci´on Resultado Validaci´on correcta Cuadro 6.19: Guardar cuestionario respondido Identificador PU.19 Nombre Guardar cuestionario respondido RF/CU a probar CU.13 Descripci´on Se realiza una llamada al servicio de guardado de cuestionarios respondidos, indicando un cuestionario respondido con todos sus par´ametros debidamente cumplimentados Resultado esperado Se almacenan los datos correspondientes al nuevo cuestionario respondido en la base de datos Resultado Validaci´on correcta Cuadro 6.20: Guardar cuestionario respondido sin paciente Identificador PU.20 Nombre Guardar cuestionario respondido sin paciente RF/CU a probar CU.13 Descripci´on Se realiza una llamada al servicio de guardado de cuestionarios respondidos, indicando un cuestionario respondido al que le falte el par´ametro paciente Resultado esperado Se lanza una excepci´on Resultado Validaci´on correcta 6.1. PROCESO DE PRUEBAS 117 Cuadro 6.21: Guardar cuestionario respondido sin puntuaci´on Identificador PU.21 Nombre Guardar cuestionario respondido sin puntuaci´on RF/CU a probar CU.13 Descripci´on Se realiza una llamada al servicio de guardado de cuestionarios respondidos, indicando un cuestionario respondido al que le falte el par´ametro puntuaci´on Resultado esperado Se lanza una excepci´on Resultado Validaci´on correcta Cuadro 6.22: Guardar cuestionario respondido sin paciente Identificador PU.22 Nombre Guardar cuestionario respondido sin respuestas RF/CU a probar CU.13 Descripci´on Se realiza una llamada al servicio de guardado de cuestionarios respondidos, indicando un cuestionario respondido al que le falte el par´ametro respuestas Resultado esperado Se lanza una excepci´on Resultado Validaci´on correcta 6.1.2. Pruebas de integraci´on Tal y como se ha expuesto al principio de este cap´ıtulo, no se realizar´an pruebas de integraci´on como tal. Sin embargo, dado que algunos de los m´etodos probados en las pruebas unitarias interaccionan con varios servicios, algunas de las pruebas unitarias desarrolladas constituyen, en ´ultima instancia, pruebas de integraci´on, al no haberse realizado mock alguno de los servicios. 6.1.3. Pruebas de sistema Tal y como se ha explicado en el anteproyecto correspondiente al presente proyecto, no se realizar´an pruebas de sistema como tal, sino que se probar´a la correcta interacci´on de los dos clientes una vez se haya ensamblado el sistema. As´ı, es necesario probar los casos que se especifican en las tablas 6.23 y 6.24. 118 CAP´ ITULO 6. PRUEBAS Cuadro 6.23: Creaci´on/recuperaci´on de cuestionarios Identificador PS.01 Nombre Creaci´on/recuperaci´on de cuestionarios RF/CU a probar RF.32 Descripci´on Se crea un nuevo cuestionario desde la aplicaci´on m´ovil Resultado esperado El cuestionario creado se muestra a los pacientes en la aplicaci´on m´ovil Resultado Validaci´on correcta Cuadro 6.24: Respuesta/consulta de cuestionarios Identificador PS.01 Nombre Respuesta/Consulta de cuestionarios RF/CU a probar RF.32 Descripci´on Un paciente responde un cuestionario desde la aplicaci´on m´ovil Resultado esperado Los datos asociados al cuestionario aparecen en detalles de paciente en la aplicaci´on web Resultado Validaci´on correcta 6.1.4. Evaluaci´on de usabilidad Inicialmente, estaba planteada la realizaci´on de una prueba piloto con usuarios antes de la finalizaci´on del presente proyecto. En esta prueba, no s´olo se evaluar´ıa el correcto funcionamiento del software desarrollado, sino que tambi´en se evaluar´ıa la usabilidad de la aplicaci´on m´ovil. Sin embargo, debido a retrasos en la autorizaci´on del piloto con pacientes, no ha sido posible realizar esta prueba todav´ıa, aunque se espera poder llevarla a cabo pr´oximamente. As´ı, la usabilidad de dicha aplicaci´on ha sido evaluada por los dos tutores del proyecto, siguiendo los principios de usabilidad de Nielsen [20], obteni´endose un resultado satisfactorio por parte de ambos. Por otro lado, la usabilidad de la aplicaci´on web ha podido probarse con los facultativos que la utilizar´an, obteni´endose, tambi´en en este caso, resultados satisfactorios. Cap´ıtulo 7 Conclusiones y trabajo futuro 7.1. Conclusiones ........................121 7.2. Trabajofuturo .......................122 119 120 CAP´ ITULO 7. CONCLUSIONES Y TRABAJO FUTURO 7.1. CONCLUSIONES 121 7.1. Conclusiones En este apartado se expondr´an las conclusiones obtenidas una vez finalizado el proyecto. En primer lugar, es necesario evaluar si se han cumplido los objetivos establecidos al inicio del mismo. El sistema desarrollado ofrece la posibilidad de a˜nadir nuevos cuestionarios, as´ı como visualizar los ya creados, bloquearlos, desbloquearlos y cambiar su frecuencia. Adem´as, tambi´en permite visualizar el listado de pacientes, y observar su evoluci´on a trav´es de las puntuaciones logradas en diversos cuestionarios. Por otro lado, permite a los pacientes responder a cuestionarios de seguimiento cl´ınico y adherencia creados por sus facultativos. Por lo tanto, podemos concluir que los objetivos planteados al inicio del proyecto han sido satisfechos. De entre todas las tareas llevadas a cabo a lo largo del proyecto, cabe destacar el hecho de que el sistema desarrollado permita la introducci´on de nuevos cuestionarios. Esta funcionalidad no fue demandada por los facultativos al inicio del proyecto, sin embargo, el equipo de desarrollo consider´o que su implementaci´on podr´ıa ser interesante y ´util para los mismos. De hecho, una vez comenzado el desarrollo del proyecto, los facultativos demandaron la inclusi´on de un nuevo tipo de cuestionario diferente de los planteados inicialmente. Dado el dise˜no realizado, este hecho no ha tenido impacto alguno en el proyecto, pero en caso de que el dise˜no se ajustase ´unica y exclusivamente a lo demandado inicialmente por el cliente, la inclusi´on de este cambio u otros semejantes hubiese implicado un redise˜no de la aplicaci´on, lo que inevitablemente llevar´ıa a un retraso en su entrega. Por lo tanto, se observa que se ha gestionado de forma correcta un riesgo de cambio en los requisitos. El hecho de utilizar una metodolog´ıa de desarrollo ´agil como la iterativa e incremental, ha permitido introducir este cambio de forma sencilla una vez comenzado el proyecto, sin que ello tuviese consecuencias negativas en el correcto desarrollo del mismo, algo que no podr´ıa hacerse de utilizar una metodolog´ıa en cascada. Por lo tanto, se concluye que la elecci´on de la metodolog´ıa ha sido satisfactoria y ha ayudado a cumplir los objetivos del proyecto en tiempo y forma. Por otro lado, el hecho de permitir a los facultativos la inclusi´on de nuevos cuestionarios permite no s´olo incluir cuestionarios ya validados para su uso fuera de consulta, sino tambi´en la realizaci´on de ensayos cl´ınicos con nuevos cuestionarios, de cara a una posible validaci´on. Adem´as, el dise˜no realizado tambi´en permite la inclusi´on de nuevas patolog´ıas o tipos de cuestionario sin necesidad de realizar cambios significativos en el c´odigo, o de realizar un redise˜no en la aplicaci´on. De hecho, el cliente ha manifestado, una vez implementada la creaci´on de cuestionarios, que podr´ıan incluirse otros tipos de cuestionario tales como calidad de vida, tabaquismo o vacunaci´on, algo que es perfectamente compatible con el dise˜no realizado y, cuya inclusi´on, tan s´olo llevar´ıa asociados cambios a nivel de base de datos. Para concluir, es preciso destacar que el software desarrollado ha sido presen- 128 AP´ ENDICE A. MANUAL DE DESPLIEGUE 2. Activar la depuraci´on USB en el dispositivo m´ovil Ajustes->Informaci´on del tel´efono->Pulsar 7 veces sobre el N´umero de compilaci´on Ajustes->Opciones de desarrollo->Activar depuraci´on por USB 3. Conectar el m´ovil al ordenador 4. Instalar ADB en el ordenador. Para ello puede utilizarse la herramienta 15 seconds ADB installer disponible en http://forum.xda-developers.com /showthread.php?p=48915118#post48915118 Ejecutar el archivo descargado con permisos de administrador Pulsar N/No para saltar la instalaci´on de Fastboot Pulsar Y/Yes para instalar ADB Pulsar Y/Yes para instalar los drivers de ADB 5. Aceptar la huella digital que se mostrar´a en la pantalla del m´ovil 6. Abrir Google Chrome y escribir chrome://inspect 7. Pulsar el checkbox Discover USB devices 8. Pulsar el bot´on Port forwarding... 9. Escribir 8080 en el recuadro Port ylocalhost:8080 en el apartado IP address and port. Figura A.1 10. Marcar el checkbox Enable port forwarding 11. Pulsar el bot´on Done Una vez finalizada la configuraci´on, deber´ıa aparecer una burbuja verde al lado del dispositivo, tal y como se muestra en la figura A.2 A.4. CONFIGURACI ´ ON DE LA REDIRECCI ´ ON DE PUERTOS 129 Figura A.1: Configuraci´on de la redirecci´on de puertos Figura A.2: Configuraci´on de la redirecci´on de puertos 130 AP´ ENDICE A. MANUAL DE DESPLIEGUE Ap´endice B Manual de usuario - Aplicaci´on web 131 132 AP´ ENDICE B. MANUAL DE USUARIO - APLICACI ´ ON WEB B.1. INTRODUCCI ´ ON 133 El presente manual tiene como objetivo ayudar a los usuarios a saber qu´e acciones pueden realizar utilizando la herramienta web del sistema de seguimiento de pacientes, y c´omo. B.1. Introducci´on La presente aplicaci´on es una herramienta de administraci´on que permite a los facultativos la gesti´on de cuestionarios de seguimiento, con el fin de evaluar la evoluci´on de los pacientes. B.2. Inicio de sesi´on Para poder utilizar la aplicaci´on, es necesario introducir las credenciales de acceso. En caso de no disponer de credenciales, o de haberlas olvidado, p´ongase el contacto con soporte. Si desea probar la aplicaci´on, puede utilizar para ello las siguientes credenciales: oper/oper Figura B.1: Pantalla de inicio de sesi´on B.3. Vista de pacientes Esta secci´on se mostrar´a autom´aticamente una vez se haya iniciado sesi´on en la aplicaci´on, y en ella se mostrar´a una serie de datos b´asicos sobre los pacientes. 134 AP´ ENDICE B. MANUAL DE USUARIO - APLICACI ´ ON WEB Figura B.2: Pantalla de vista de pacientes En la parte superior izquierda se muestran los datos de inicio de sesi´on del facultativo. En la parte superior derecha de la ventana se encuentra el bot´on de cierre de sesi´on. Una vez pulsado, el usuario ser´a redirigido a la pantalla de login. Justo debajo, se muestra un bloque de pesta˜nas, que permite moverse entre las diferentes p´aginas de la aplicaci´on. En la parte central de la pantalla, se muestra una lista con datos de los pacientes que forman parte del sistema, entre los que encontraremos: 1. id: El identificador un´ıvoco del paciente en el sistema sanitario. 2. Patolog´ıa: La patolog´ıa de la que adolece el paciente. 3. Puntuaci´on: Puntuaci´on obtenida en el ´ultimo cuestionario de seguimiento cl´ınico realizado por el paciente. 4. Estado: Estado en el que se encuentra el paciente, en base a la puntuaci´on obtenida en el ´ultimo cuestionario realizado A continuaci´on, se muestra la columna Acci´on, que permite el acceso a la informaci´on detallada acerca del paciente seleccionado. Para ello debe pulsarse el icono con forma de flecha B.3.1. Detalles del paciente En la parte superior de la ventana de detalles del paciente se muestra un bloque de pesta˜nas, que permiten al usuario desplazarse entre las diferentes pantallas de detalles del paciente. B.3. VISTA DE PACIENTES 135 Vista general Una vez el usuario accede a la vista detallada del paciente, lo primero que se le mostrar´a es una gr´afica donde se exponen los resultados obtenidos en los cuestionarios realizados por el paciente, a modo de vista general de la evoluci´on del mismo. Figura B.3: Pantalla de vista detalles del paciente Hist´orico La pantalla de hist´orico muestra informaci´on general acerca de los cuestionarios realizados por el paciente seleccionado. As´ı, se ofrece una tabla con los siguientes datos: 1. Cuestionario: Nombre del cuestionario realizado 2. Fecha: Fecha y hora en que se ha realizado el cuestionario 3. Puntuaci´on: Puntuaci´on obtenida en el cuestionario 4. Estado: Estado en el que se encontraba el paciente en el momento de realizar el cuestionario, en base a la puntuaci´on obtenida. 136 AP´ ENDICE B. MANUAL DE USUARIO - APLICACI ´ ON WEB Figura B.4: Pantalla de hist´orico B.4. Gesti´on de cuestionarios Al pulsar sobre la pesta˜na Gestionar cuestionarios, el usuario es redirigido a la pantalla de gesti´on de cuestionarios. En la parte superior derecha de la ventana se sit´ua el bot´on de creaci´on de cuestionarios. En la parte central de la ventana, una tabla con informaci´on acerca de los cuestionarios existentes en el sistema, separados por tipo y patolog´ıa. Esta tabla contiene los siguientes elementos: 1. Cuestionario: Nombre del cuestionario 2. Bloque de umbrales: Estados que se pueden asociar a un paciente que realiza un cuestionario, junto con las puntuaciones asociadas a cada uno de ellos. 3. Estado: Muestra si el cuestionario est´a activo (se env´ıa a los pacientes para que lo contesten) o bloqueado (no se env´ıa a los pacientes) 4. Acciones: Muestra las acciones disponibles sobre el cuestionario seleccionado. Para ello, es necesario pulsar el icono con forma de flecha B.4. GESTI ´ ON DE CUESTIONARIOS 137 Figura B.5: Pantalla de gesti´on de cuestionarios B.4.1. Detalles del cuestionario En esta pantalla se permite al usuario modificar ciertos aspectos relativos al cuestionario seleccionado. El contenido de la pantalla var´ıa dependiendo de si el cuestionario est´a activo o bloqueado. Cuestionario Activo Si el cuestionario est´a activo, se mostrar´a una ventana con una divisi´on vertical. A la izquierda de la pantalla, se mostrar´an dos selectores con los que el usuario podr´a modificar la frecuencia con la que un cuestionario es enviado a un paciente. El primer selector permite seleccionar un n´umero, mientras que el segundo se seleccionar´a la unidad de tiempo (d´ıas, semanas, meses o a˜nos). Una vez introducida la nueva frecuencia, el usuario debe pulsar el bot´on GUARDAR para hacer persistentes los cambios. A la derecha de la ventana, se muestra el bot´on de bloqueo de cuestionarios. La funcionalidad de bloqueo de cuestionarios hace que un cuestionario deje de enviarse a los pacientes, pero mantiene sus datos almacenados, para que puedan ser consultados por los facultativos.