Diseño e implementación de un sistema de información para una organización social

Proyecto de Fin de Carrera de la Escuela de Ingeniería Informática de la Universidad de Las Palmas de Gran Canaria presentado por los alumnos: Alberto Cardona López José Antonio Martín García Título del proyecto: Diseño e implementación de un sistema de información para una organización social. Tutor: D. Francisco Javier Carreras Riudavets 2 Contenido Contenido ......................................................................................................................... 2 1. INTRODUCCIÓN ......................................................................................................... 7 1.1. SISTEMAS DE INFORMACIÓN ............................................................................. 7 1.2. ESTADO DEL ARTE .............................................................................................. 7 1.3. SITUACIÓN DE PARTIDA ..................................................................................... 9 1.4. ESTRUCTURA DE LA MEMORIA ........................................................................ 10 2. OBJETIVOS ............................................................................................................... 11 2.1. OBJETIVOS PARA LA ORGANIZACIÓN .............................................................. 11 2.2. OBJETIVOS PARA LOS AUTORES DEL PROYECTO ............................................. 11 3. METODOLOGÍA DE DESARROLLO SOFTWARE ......................................................... 13 3.1. DOCUMENTACIÓN ........................................................................................... 14 3.2. GESTIÓN ........................................................................................................... 15 3.3. FLUJO DE TRABAJO .......................................................................................... 16 3.3.1. Sobre Git ................................................................................................... 16 3.3.2. Revisiones de código ................................................................................ 16 3.4. EQUIPO DE TRABAJO ....................................................................................... 17 4. RECURSOS SOFTWARE Y HARDWARE ..................................................................... 18 4.1. RECURSOS SOFTWARE ..................................................................................... 18 4.1.1. Herramientas de desarrollo ...................................................................... 18 4.1.2. Extensiones de Visual Studio: ................................................................... 18 4.1.3. Librería principalñes ................................................................................. 19 4.2. RECURSOS HARDWARE .................................................................................... 19 5. PLAN DE TRABAJO ................................................................................................... 21 5.1. ESTUDIO DE LA TECNOLOGÍA........................................................................... 21 5.2. ANÁLISIS INICIAL DE REQUISITOS .................................................................... 22 5.3. DISEÑO DE LA ARQUITECTURA ........................................................................ 23 5.4. DESARROLLO ITERATIVO .................................................................................. 23 3 5.5. FINALIZACIÓN .................................................................................................. 24 6. ESTIMACIÓN DE ESFUERZO Y PRESUPUESTO ESTIMADO ....................................... 25 6.1. ESTIMACIÓM DE ESFUERZO ............................................................................. 25 6.2. ORGANIZACIÓN DEL ESFUERZO ....................................................................... 26 6.3. PRESUPUESTO ESTIMADO ............................................................................... 27 6.3.1. Supuesto 1: Presupuesto Junior ............................................................... 27 6.3.2. Supuesto 2: Presupuesto Senior............................................................... 27 7. ESTUDIO DEL DOMINIO DEL PROBLEMA ................................................................ 28 7.1. ACTORES .......................................................................................................... 28 7.2. ENTIDADES ....................................................................................................... 29 7.2.1. Servicio de atenciones .............................................................................. 29 7.2.2. Gestión de socios ...................................................................................... 30 7.2.3. Cooperación .............................................................................................. 31 8. ANÁLISIS DE REQUISITOS ........................................................................................ 32 8.1. CARACTERÍSTICAS COMUNES ENTRE LOS MÓDULOS ..................................... 32 8.2. CARACTERÍSTICAS DEL MÓDULO DE ATENCIONES .......................................... 35 8.3. CARACTERÍSTICAS DEL MÓDULO DE SOCIOS ................................................... 37 8.4. CARACTERÍSTICAS DEL MÓDULO DE COOPERACIÓN ...................................... 39 8.5. CARACTERÍSTICAS DE LA EXTRANET ................................................................ 41 9. DISEÑO ARQUITECTÓNICO ...................................................................................... 43 9.1. ARQUITECTURA GLOBAL .................................................................................. 44 9.2. ORGANIZACIÓN DE ENSAMBLADOS ................................................................ 46 9.3. DESPLIEGUE ..................................................................................................... 48 9.3.1. Funcionamiento del servidor de sincronización ....................................... 49 9.3.2. Organización de carpetas de la aplicación en el cliente ........................... 50 9.4. ARRANQUE DE LA APLICACIÓN ........................................................................ 50 9.5. MVVM (MODEL-VIEW-VIEWMODEL) .............................................................. 51 9.5.1. Motivación para usar MVVM ................................................................... 51 4 9.5.2. MVVM (Model-View-ViewModel) ............................................................ 52 9.6. CLASES DE LOS ENSAMBLADOS COMUNES ..................................................... 53 9.6.1. Ensamblado Core ...................................................................................... 54 9.6.2. Ensamblado Gama.Common .................................................................... 55 9.7. CLASES DEL MÓDULO DE ATENCIONES ........................................................... 60 9.7.1. Capa de acceso a datos (Gama.Atenciones.DataAcces)........................... 61 9.7.2. Capa de negocio (Gama.Atenciones.Business) ......................................... 62 9.7.3. Eventos (Gama.Atenciones.Wpf.Eventos) ................................................ 63 9.8. CLASES DEL MÓDULO DE SOCIOS .................................................................... 64 9.8.1. Capa de acceso a datos (Gama.Socios.DataAccess) ................................. 64 9.8.2. Capa de negocio (Gama.Socios.Business) ................................................ 65 9.8.3. Eventos (Gama.Socios.Wpf.Eventos) ........................................................ 66 9.9. CLASES DEL MÓDULO DE COOPERACIÓN ........................................................ 66 9.9.1. Capa de acceso a datos (Gama.Cooperacion.DataAccess) ...................... 67 9.9.2. Capa de negocio (Gama.Cooperacion.Business) ...................................... 68 9.9.3. Eventos (Gama.Cooperacion.Wpf.Eventos) ............................................. 69 9.10. ARQUITECTURA CLIENTE-SERVIDOR ............................................................ 69 9.11. DISEÑO DE LA BASE DE DATOS .................................................................... 70 9.11.1. Servicio de atenciones .......................................................................... 71 9.11.2. Gestión de socios .................................................................................. 72 9.11.3. Cooperación .......................................................................................... 73 9.12. DECISIONES DE RENDIMIENTO .................................................................... 74 9.12.1. Sobre WPF ............................................................................................. 74 9.12.2. Sobre el calendario ............................................................................... 74 9.12.3. Sobre el arranque de los módulos ........................................................ 74 9.12.4. Sobre la Extranet ................................................................................... 75 10. DISEÑO DE LA INTERFAZ DE USUARIO................................................................. 76 10.1. SELECCIÓN DE MÓDULO .............................................................................. 76 5 10.2. ESQUEMA VISUAL COMPARTIDO ................................................................. 77 10.3. ASPECTOS VISUALES COMUNES ................................................................... 78 10.3.1. Seguimiento de cambios ....................................................................... 78 10.3.2. Validación .............................................................................................. 80 10.3.3. Habilitación de botones ........................................................................ 80 10.3.4. Notificar a través del Status Bar ........................................................... 82 10.4. DISEÑO DE LA INTERFAZ DEL MÓDULO DE ATENCIONES ............................ 82 10.4.1. Dashboard ............................................................................................. 83 10.4.2. Cuadro de búsqueda ............................................................................. 85 10.4.3. Acciones de la barra de herramientas .................................................. 86 10.4.4. Panel de personas ................................................................................. 87 10.4.5. Panel de citas ........................................................................................ 91 10.4.6. Panel de asistentes ............................................................................... 92 10.4.7. Panel de gráficas ................................................................................... 93 10.4.8. Preferencias .......................................................................................... 94 10.5. DISEÑO DE LA INTERFAZ DEL MÓDULO DE SOCIOS ..................................... 95 10.5.1. Dashboard. ............................................................................................ 96 10.5.2. Panel de Socios ..................................................................................... 98 10.6. DISEÑO DE LA INTERFAZ DEL MÓDULO DE COOPERACIÓN ....................... 102 10.6.1. Dashboard. .......................................................................................... 103 10.6.2. Actividades. ......................................................................................... 105 10.6.3. Cooperantes. ....................................................................................... 108 10.6.4. Nueva actividad. ................................................................................. 110 10.6.5. Nuevo Cooperante. ............................................................................. 110 10.6.6. Nueva Tareas. ..................................................................................... 111 10.6.7. Foros de discusión .............................................................................. 112 10.6.8. Seguimiento. ....................................................................................... 112 10.6.9. Incidencias. ......................................................................................... 113 6 10.6.10. Calendario. .......................................................................................... 114 10.7. DISEÑO DE LA INTERFAZ DE LA EXTRANET ................................................ 115 11. TRABAJO FUTURO .............................................................................................. 117 11.1. TRABAJO FUTURO GENERAL ...................................................................... 117 11.2. TRABAJO FUTURO PARA EL MÓDULO DE ATENCIONES ............................. 118 11.3. TRABAJO FUTURO PARA EL MÓDULO DE SOCIOS ..................................... 118 11.4. TRABAJO FURUTO PARA EL MÓDULO DE COOPERACIÓN ......................... 118 11.5. TRABAJO FUTURO PARA LA EXTRANET ...................................................... 119 12. CONCLUSIÓN ..................................................................................................... 120 13. BIBLIOGRAFÍA .................................................................................................... 122 13.1. LIBROS Y DOCUMENTOS ............................................................................ 122 13.2. SITIOS WEB CON RECURSOS TEXTUALES Y AUDIOVISUALES ..................... 122 13.3. ARTÍCULOS.................................................................................................. 123 14. ANEXO I: INSTRUCCIONES DE USO .................................................................... 124 14.1. CÓMO USAR LA APLICACIÓN ..................................................................... 124 14.2. CÓMO USAR LA APLICACIÓN CON VISUAL STUDIO ................................... 124 14.2.1. Preparación de la base de datos ......................................................... 125 7 _______________________________________________________ 1. INTRODUCCIÓN _______________________________________________________ SISTEMAS DE INFORMACIÓN 1.1. SISTEMAS DE INFORMACIÓN Los sistemas de información permiten aumentar la competitividad de las organizaciones, optimizando sus procesos y permitiéndoles diferenciarse de la competencia. En el contexto de las organizaciones sin ánimo de lucro suponen también más posibilidades para colaborar y crear sinergias con otras organizaciones. Por otra parte, el estudio y análisis continuo característicos de un desarrollo iterativo –el utilizado en este proyecto– permite la racionalización de procesos, esto es, el repensar la forma, contenido y relaciones entre los distintos procesos y roles laborales de la organización. Este proyecto ha propuesto analizar la situación de la organización sin ánimo de lucro “Colectivo Gamá LGTB” (en adelante Gamá) en cuanto a la gestión de los socios, el servicio de atenciones, y las relaciones con otras organizaciones o instituciones, y desarrollar un sistema de información que lo soporte. ESTADO DEL ARTE 1.2. ESTADO DEL ARTE En el mercado podemos encontrar infinidad de programas, tanto gratuitos como de pago, que cubran por separado alguna de las necesidades de gestión del sistema de información de Gamá. Para la gestión de socios, su información, sus cuotas y pagos, encontramos programas como “GestCli”, “Gym Control”, “Asociaciones XL” y muchos más que en un principio el soporte que prestarían estaría por encima de las necesidades de Gamá, al contar con paquetes de contabilidad y facturación. 8 Para la gestión de las atenciones los programas del mercado que mejor cubriría las necesidades de Gamá son los diseñados para la gestión de consultorios médicos como “PsicoClinic” o “DoctorGes”. Permiten llevar un control de los usuarios y las citas con reserva online y demás cosas, pero no permite llevar el control de las atenciones y el seguimiento que realiza Gamá, así como de generar informes personalizados según la atención prestada, que es de muy distinta índole. En lo que concierne a la gestión de proyectos encontramos muchos programas en el mercado. La mayorías están indicados para gestionar proyectos de ingeniería como “GanttProject” o “Task Juggler”, que no están orientados al tipo de actividades que desarrolla Gamá. Gestores como “BaseCamp” o “Trello” están más orientados a esa gestión de actividades o tareas generales. La siguiente tabla indica las competencias que cubrirían esos programas del mercado frente al alcance de nuestro proyecto: Competencia Actualidad Proyecto GestCli DoctorGes Trello Gestión de Socios Gestión de Usuarios Gestión de Personal Gestión de pagos Informes personalizados Gestión de citas Gestión de atenciones Estadísticas Exportar Notificación de Eventos Gestión de proyectos 9 Podemos ver claramente como por separado ninguno de los programas indicados podrían dar un soporte integral para la gestión de la información de la organización debido a la gran disparidad de datos con los que trabajan. Además tienen un sistema de gestión de atenciones con el que se generan informes y seguimientos de los usuarios que solicitan atención de muy distinta naturaleza, desde una atención medica hasta un asesoramiento jurídico. SITUACIÓN DE PARTIDA 1.3. SITUACIÓN DE PARTIDA Previo al comienzo del desarrollo, Gamá realizaba las actividades relacionadas a la gestión de socios y a la gestión del servicio de atenciones en formato físico. En cuanto a la generación de otros documentos sí utilizan el formato digital, en concreto Microsoft Word y Excel. En relación a los socios, han de gestionar información personal, cómo llegaron a conocer a Gamá, etc., así como los pagos de las cuotas. Deben controlar pagos atrasados (o adelantados), que se ajusten a las cantidades correspondientes, etc., en lo que dan a llamar la gestión de la morosidad. Gamá ofrece un servicio de atenciones individuales a personas LGTB así como a organizaciones que requieran información. Estas atenciones son de distinto tipo (psicológico, jurídico, de acogida, de orientación, de prevención para la salud,…). Según el caso se derivarán a un profesional, a la propia organización o a una institución, estando estas derivaciones en correspondencia con la atención solicitada. Las atenciones cuentan con un seguimiento por parte de Gamá independientemente de la derivación que tenga lugar. Las fichas personales de cada atención se ajustan a una categorías específicas (identidad sexual, orientación afectivo-sexual, edad, nacionalidad, nivel de estudios,…), y se integran al resto de datos para extraer estadísticas personalizadas (presentadas en forma gráfica). Esta información la utilizan para la elaboración de memorias y documentos varios, algunos de los cuales requieren para pedir y justificar subvenciones. En cuanto a la cooperación con otras entidades o proyectos particulares, se requiere poder gestionar proyectos y su información relacionada. Esto es: plazos, actividades, 16 FLUJO DE TRABAJ O 3.3. FLUJO DE TRABAJO Al comenzar la iteración, lo primero que se hace es acordar cómo se van a integrar las nuevas características o modificaciones en la arquitectura presente. Dependiendo del caso no se requiere realizar modificaciones en la arquitectura, o se han de aplica cambios leves, o ésta evoluciona para dar soporte a las nuevas necesidades. Una vez se ha analizado el problema, se procede a la implementación de las características. Según la situación se opta por un enfoque más cercano o más alejado a TDD. Esta dinámica de TDD se seguía sobretodo en las primeras iteraciones, ya que permitía pensar más pausadamente sobre cada cambio además de consolidar las técnicas de pruebas pronto (para evitar el riesgo de acabar no haciendo pruebas). Más adelante la dinámica pasó a ser una posición intermedia, en la que a veces se hacía TDD como al principio, otras veces se implementaban las pruebas a posteriori, y en otras ocasiones se implementaba un boceto de solución para probar si la solución tenía cabida. Si no tenía cabida, se probaba otra opción. Cuando ésta fuera apropiada, entonces se implementaba o se seguía TDD según preferencias personales. En relación al diseño de interfaces de usuario, esto es, al diseño de vistas, respecto al desarrollo back-end, se siguió un orden arbitrario a la hora de implementarlos. 3.3.1. Sobre Git Se usó Git desde la primera fase del proyecto, esto es, desde el estudio de la tecnología. Familiarizarse con Git y aprender a integrarlo en el flujo de trabajo ha sido un objetivo importante del proyecto. Durante el resto del desarrollo se ha seguido usando. El proyecto está alojado en GitHub: https://github.com/PFC-aclamg/GamaPFC. 3.3.2. Revisiones de código Las revisiones de código. Se hacían de manera informal, normalmente aprovechando momentos de menos energía. Resultaron ser beneficiosos, ya que servían para tener una comprensión mayor del creciente sistema, así como para detectar code smells, mejoras varias refactorizando de forma ligera o incluso para plantear cambios arquitectónicos, que los hubo. 17 EQUIPO DE TR ABAJO 3.4. EQUIPO DE TRABAJO Esta metodología de trabajo requiere de un equipo de más de una persona. Por ello, y por las aspiraciones de alcance de la aplicación, se decidió formar el equipo con dos personas. Ser dos personas ha permitido una organización y unos resultados más realistas, además de poder poner en práctica técnicas como la programación por parejas. 18 _______________________________________________________ 4. RECURSOS SOFTWARE Y HARDWARE _______________________________________________________ En este capítulo de describen las dependencias hardware y software que se requirieron para la realización del proyecto. RECURSOS SOFTWARE 4.1. RECURSOS SOFTWARE El proyecto se ha desarrollado usando la tecnología WPF de Microsoft para la aplicación cliente, ASP.NET MVC 5 para la extranet, y el lenguaje de programación C# 6 para ambos. 4.1.1. Herramientas de desarrollo HERRAMIENTA DESCRIPCIÓN Y USO Microsoft Visual Studio 2015 Community Edition IDE (Integrated Development Environment) usado. phpMyAdmin Herramienta de gestión de bases datos MySQL. MySQL DBMS (DataBase Management System) usado. IIS (Internet Information Services) Servidor web escogido par a alojar la Extranet. MySQL Workbench Herramienta de gestión de bases de datos MySQL con múltiples utilidades. Entre ellas generar diagramas sofisticados. Git VCS (Version Control System) usado. 4.1.2. Extensiones de Visual Studio: HERRAMIENTA DESCRIPCIÓN Y USO Git for Visual Studio Herramienta de Git integrada en Visual Studio. Facilita el flujo de trabajo con git. Inline Color Picker Permite seleccionar un color personalizado desde el editor de código XAML. Visual Studio Installer Project Permite crear instaladores simples con facilidad. Nuget Package Manager Gestor de paquetes/dependencias. 19 4.1.3. Librería principalñes LIBRERÍA DESCRIPCIÓN Y USO .NET Framework 4.6.1 Framework de .NET. Prism Framework de MVVM de código libre, desarrollado hasta su versión 5 por Microsoft. Usamos la versión 6. Ofrece todo tipo de facilidades a la hora de implementar MVVM. Se han usado algunas de estas funciones. Unity Contenedor de gestión de dependencia para implementar el patrón Dependency Injection / Inversion Of Control. MahApps.Metro Conjunto de estilos, iconos, recursos y utilidades para aplicaciones basadas en XAML. Se ha tomado como base sobre la que personalizar el aspecto visual de la aplicación. Se han usado algunas de estas utilidades. NHibernate ORM basado en el famoso ORM de Java Hibernate. FluentNHibernate Extensión de NHibernate que basa su configuración en código en forma Fluent, en lugar de MySql.Data Conector de MySQL para .NET (C# en este caso) xUnit Utilidad para facilitar el desarrollo de pruebas unitarias. Faker Utilidad para generar datos falsos. Facilita el popular la base de datos de desarrollo con nombres, fechas, direcciones, etc.. DocX Permite exportar a formato docx sin pasar por las librerías de InterOP de Microsoft. MySqlBackup Facilita la creación de copias de seguridad y la restauración de las mismas. Modern UI Charts Librería usada para la generación de gráficos. RECURSOS HARDWARE 4.2. RECURSOS HARDWARE RECURSO DESCRIPCIÓN Servidor dedicado Ordenador propiedad de Gamá donde alojar el servidor de sincronización y la base de datos MySQL. Se contó 20 con uno específico para el desarrollo también. Portátil personal Ordenadores personales de los autores del proyecto. 21 _______________________________________________________ 5. PLAN DE TRABAJO _______________________________________________________ El desarrollo del proyecto se ha divido en cinco fases: estudio de la tecnología, toma de requisitos, diseño de la arquitectura base, proceso iterativo de desarrollo, finalización. En este capítulo se describe brevemente en qué consistió cada fase, señalando las particularidades dadas por nuestro caso y justificando algunas decisiones tomadas. Las tres primeras se solaparon en el tiempo de una forma u otra. La fase de finalización atiende a las exigencias académicas, pues de no existir éstas se habría continuado con el proceso iterativo habitual de desarrollo mientras así se acordara. En el enfoque ágil que se ha planteado no hay tal cosa como iteración final. Cuestiones como la elaboración de esta memoria y las modificaciones finales (de cara a la entrega académica) han hecho que estas últimas modificaciones no cuenten con todo el respaldo de pruebas unitarias convenientemente actualizadas (pruebas que hay que ir actualizando), sustituyéndose estas pruebas automatizadas por pruebas manuales. Pruebas manuales que, por otra parte, siempre hay que llevar a cabo, ya que todo lo concerniente a la interfaz gráfica (layout, estilos, bindings) no es objeto de trabajo de las pruebas unitarias. ESTUDIO DE LA TECNOLOGÍA 5.1. ESTUDIO DE LA TECNOLOGÍA Esta fase comenzó antes de iniciarse formalmente el proyecto. En ella se siguieron distintos recursos educativos (véase la bibliografía). Lo primero fue familiarizarse con el código XAML y las formas más sencillas de implementar MVVM. Se siguió aumentando la complejidad a medida que se iba profundizando en el aprendizaje. Con esto se pretendió conocer la potencia, limitaciones y riesgos de esta tecnología. En cuanto a potencia o alcance cumple con las expectativas de desarrollo de una interfaz de usuario sofisticada (rich user interaface). 22 La limitación principal que encontramos en WPF es que puede volverse pesado (i.e. lento para transitar entre vistas, para cargarlas, y para refrescarlas) con facilidad. Esta limitación crea el riesgo de tener que reformular el diseño gráfico e incluso la arquitectura para hacer frente a las ineficiencias. Hay que señalar que es raro que un proyecto software no requiera de profundizar en algún aspecto o aprender algo nuevo independientemente de la experiencia previa. En esta fase nos referimos al estudio inicial, que como decimos tuvo sus inicios bastante antes de la aprobación del proyecto. Desde la fase iterativa hasta la finalización del proyecto se ha continuado aprendiendo, pero no consideramos parte de esta fase todo ese aprendizaje habitual a cualquier desarrollo software. ANÁLISIS INICIAL DE REQUISITOS 5.2. ANÁLISIS INICIAL DE REQUISITOS Una vez se toma conciencia del alcance, limitaciones y riesgos de WPF se puede comenzar la actividad de análisis sabiendo asesorar al cliente. Esta fase consistió en la realización de varias entrevistas donde se plantearon los actores, lista de características inicial, y aspectos de calidad y usabilidad. Como buena parte de lo desarrollado ya era llevado a cabo por Gamá en formato físico, las necesidades de información estuvieron a nuestra disposición desde un primer momento. Se enfocó la actividad de obtención de requisitos en facilitar el posterior diseño de una arquitectura que diera soporta al conjunto de funcionalidades. Es decir, se llevó a cabo con vistas a reducir riesgos futuros. Los cambios arquitectónicos pueden tener un impacto impredecible y en ocasiones catastrófico para el conjunto del software y el desarrollo. 23 DISEÑO DE LA ARQUITECTURA 5.3. DISEÑO DE LA ARQUITECTURA Esta fase tiene bastante de estudio de la tecnología, aunque enfocado en los aspectos arquitectónicos, guiados estos por algunos de los objetivos del proyecto. Para ello, se profundizó en MVVM y en el diseño de aplicaciones débilmente acopladas. Todo esto se traduce en el aprendizaje, diseño y desarrollo tanto de MVVM como de distintos patrones de diseño, entre ellos: Command Pattern, Composite View, Dependency Injectio, Invesion of Control, Event Aggregator, Observer, Registry, Repository. El diseño de la arquitectura depende del resultado obtenido en el análisis en relación a los actores y a las características (funcionales y de calidad). DESARROLLO ITERATIVO 5.4. DESARROLLO ITERATIVO Una vez planteada la arquitectura, y después de un tiempo de formación continua en las tecnologías a usar, comienza el proceso iterativo que se describió en Capítulo 3. Metodología de Desarrollo Software. Este proceso consiste en 1. Tomar un subconjunto de características de la lista de características para ser desarrolladas en la iteración. 2. Detallar los requisitos seleccionados y hacer prototipos (en papel o directamente en código según conveniencia, como por ejemplo si se está en una entrevista con el cliente o no). Estos se aceptan o modifican hasta considerarse satisfactorios. 3. Implementar y probar las características seleccionadas. La comunicación con el cliente es activa cuando se requiere. 4. Entregar y mostrar la nueva versión al cliente. Se toma feedback. 5. Retrospectiva del equipo de desarrollo, vuelta al paso 1. 24 FINALIZACIÓN 5.5. FINALIZACIÓN Para terminar el proyecto se hizo necesario acotar el alcance del proyecto de forma temporal. Esto es, establecer un límite de cara a la entrega académica. Es en esta fase donde se desarrolla la memoria. Debido a ello, se han dado aún más prioridad a los principios ágiles que han regido el desarrollo, en particular el principio de “Software funcionando frente a documentación extensiva”. Esto ha tenido impacto en las pruebas unitarias. Siendo las pruebas unitarias una forma de documentación activa (nos dicen, en tiempo real, que un cierto porcentaje del código no contiene fallos) consideramos coherente haberlas descuidado en esta última fase, máxime cuando se han realizado extensas pruebas manuales (que por otra parte son necesarias igualmente, ya que las pruebas unitarias no cubren todas las capas, como la visual o la de acceso real a la base de datos –pruebas funcionales–). Para finalizar, es importante señalar que el software desarrollado no es un producto final, sino que se seguirá desarrollando. Por ello, es probable que entre el día de presentación de esta memoria junto con el código, hasta el día de la defensa ante un tribunal, se hayan introducido cambios en los programas. Hay que tener en cuenta que de cara a la presentación, con el cambio de prioridades que ello implica, algunos aspectos se han dejado un poco de lado, como la batería de pruebas unitarias. Se siguen manteniendo las del código de infraestructura pero muchas de los ViewModels están desactualizadas. La primera iteración tras consistirá precisamente en recuperar toda esa batería actualizada de pruebas y volver a sentar las bases para reiniciar la fase iterativa. 25 _______________________________________________________ 6. ESTIMACIÓN DE ESFUERZO Y PRESUPUESTO ESTIMADO _______________________________________________________ Una de las características del proyecto es que el desarrollo ha sido gratuito. Con ello pretendíamos eliminar algunos riesgos inherentes a nuestro contexto (falta de experiencia en la tecnología, etc.) al tiempo de contar con más flexibilidad, tanto para los desarrolladores como para el cliente. De todas formas, se expone a continuación un análisis presupuestario que cubriría las fases dos, tres y cuatro: análisis de requisitos, diseño de la arquitectura, desarrollo iterativo. ESTIMACIÓM DE ESFUERZO 6.1. ESTIMACIÓM DE ESFUERZO Con un esfuerzo medio dedicado de cuatro horas diarias (entre los dos desarrolladores) durante un periodo aproximado de dos años (tomando cuarenta y cuatro semanas en cada uno) a razón de cinco días por semana, y teniendo en cuenta los porcentajes estimados dedicados a cada actividad, nos resulta la siguiente estimación: 4 x 2 x 44 x 5 = 1.760 horas 32 _______________________________________________________ 8. ANÁLISIS DE REQUISITOS _______________________________________________________ El análisis se ha divido en las siguientes secciones:  Lista de características funcionales y de calidad comunes entre los módulos  Lista de características del módulo de atenciones  Lista de características del módulo de socios  Lista de características del módulo de cooperación  Lista de característica de la extranet CARACTERÍSTICAS COMUNES ENTRE LOS MÓDULOS 8.1. CARACTERÍSTICAS COMUNES ENTRE LOS MÓDULOS Característica Descripción Seguimiento de cambios Seguimiento de los cambios que el usuario introduce en los modelos con los que trabaja. Permite:  Mostrar en la interfaz qué campos han sido modificados – cambiando el color de fondo del campo– y su valor original –a través del tooltip–  Revertir las modificaciones introducidas, devolviendo el modelo tratado a su estado original, antes de introducir cambios. Validación Validación en el lado cliente. Cada vez que se introduce un cambio, se somete el modelo a una validación.  Se muestran en la interfaz qué campos son inválidos, cambiando el estilo del campo y mostrando el mensaje de error específico en cada uno. Habilitación de botones Se utiliza la información que nos proporcionan las dos características anteriores (seguimiento de cambios y validación) para habilitar o deshabilitar botones cuyas acciones impliquen persistir datos. El modelo deberá haber sido cambiado y además ser válido para que se 33 permita llevar a cabo la acción. La primera condición atiende a la usabilidad. La segunda a la consistencia de los datos y robustez de la aplicación (al imposibilitar un conjunto de excepciones en tiempo de ejecución). El estado del botón (habilitado o deshabilitado) hace que se muestre con un estilo visual u otro. Preferencias Preferencias de usuario sobre varios aspectos de usabilidad, así como para indicar si deben realizarse copias de seguridad automáticas o no y en qué carpeta guardarlas. Gestión de copias de seguridad Todos los módulos cuentan con funcionalidad de generación automática de copias de seguridad. También se permite realizar una en cualquier momento. Cambio de módulo Pequeña facilidad para cambiar entre módulos desde la propia aplicación. La acción consiste en cerrar el módulo actual y relanzar el selector de módulo. Por otra parte, se permite tener varias instancias de uno o varios módulos al mismo tiempo en un mismo terminal. Sincronización de datos Los clientes lanzados notificarán, a través del servidor central de sincronización, las modificaciones que realicen, instando al resto de cliente a actualizar sus datos en tiempo real. Este requisito implica que se debe poder visualizar el estado de conexión al servidor. Control de acceso Cada módulo cuenta con sus propios usuarios para el control de acceso. Dentro de cada módulo, sus usuarios gozan de los mismos privilegios. Exportación de datos Exportar fichas y listados a docx. Generación de gráficas Donde se ha considerado necesario o deseable se han introducido gráficas mostrando datos estadísticos varios. Navegación Facilidad para navegar por las distintas vistas. Se traduce en que se presentan casos en lo que desde distintos sitios se pueden realizar las mismas acciones, así como navegar cómodamente entre vistas. Esto se consigue con dos tipos de acciones: acciones Ir a y acciones Editar. La primera permite navegar hacia el modelo relacionado seleccionado (e.g. a la persona asociada a una cierta cita). La segunda permite editar algunos modelos sin tener que navegar a una vista específica para ello, sino abriéndose un diálogo en esa misma vista. 34 Notificación de cambios La barra de estado se ilumina y muestra un mensaje durante unos segundos cada vez que se ha realiza una acción que implica persistir datos en la base de datos. Propagación de cambios Al realizarse un cambio en el modelo a través de una vista, los cambios se propagan a aquellas vistas donde corresponda. 35 CARACTERÍS TICAS DEL MÓDU LO DE ATENCIO NES 8.2. CARACTERÍSTICAS DEL MÓDULO DE ATENCIONES Característica Descripción Detalle Añadir persona Añade a una persona nueva a la base de datos. La acción debe ser accesible desde la barra de herramientas (Toolbar). Editar persona Modifica los datos personales de una persona existente. Esta edición ha de compartir vista con la edición de citas y atenciones de la persona. Este requisito incluye la visualización de los datos de la persona así como de sus citas (con su calendario personal) y las atenciones asociadas a las citas. Eliminar persona Elimina a la persona y todos sus registros asociados de la base de datos. Esto significa que se eliminan todas sus citas y atenciones asociadas, por eso esta lista carece de funciones de eliminar citas y atenciones. Añadir asistente Añade un nuevo asistente a la base de datos. La acción debe ser accesible desde la barra de herramientas (Toolbar). Editar asistente Modifica los datos personales de un asistente existente. Esta edición comparte la vista con el listado del resto de asistentes así como de las citas en las que el asistente en edición está presente. Eliminar asistente No implementado. Una cita requiere que se establezca un asistente. Por ello, aunque un asistente deje de formar parte de la organización o de colaborar con ella, es necesario que permanezca en la base de datos. Añadir cita Añade una cita en la base de datos. Las citas se podrán añadir desde el calendario general, y desde el calendario específico de cada persona. La creación requiere que se indique la persona a la que afecta y el asistente que asistirá en la cita cuando esta se efectúe. Si el asistente ya 36 tiene una cita cercana (entre una hora menos y una hora más), se indica al usuario que solaparían y se impide la acción. Al crearse la cita se crea automáticamente una atención asociada nueva y vacía, por eso no existe la función explícita de añadir atención. Editar cita Modifica los datos de una cita existente. La acción debe poder realizarse tanto desde la vista de citas general, como las particulares de cada persona, como en el registro de citas asociadas a cada asistente. Editar atención Modifica la información de una atención. Cuando se crea una cita, esta ya contiene una atención, pues es lo que se rellena al tener lugar la cita. Por ello, sólo existe la función para el usuario de editar atención, y no las de crear o eliminar. Buscar persona Buscar persona por nombre. Se podrá buscar a una persona por nombre, listando los resultados que encajen, y pudiendo navegar a la persona que se seleccione. El formulario de búsqueda debe ser accesible y permanecer visible en todo momento. Visualizar personas Visualizar de forma paginada al conjunto de personas. Disponer de un panel donde se vean todas las personas listadas en forma de matriz mostrando su imagen, nombre y NIF. Visualizar atenciones Visualizar el conjunto de atenciones Visualizar un listado de todas las atenciones del sistema Calendario de citas Visualización de todas las citas del sistema en formato de calendario y formato tabular. Se trata de un calendario mensual navegable por semanas desde el que se deben poder crear citas y visualizar todas las citas del sistema. El formato tabular, al que se accederá como opción de cambio de vista, 37 mostrará todas las citas en una tabla y permitirá filtrar por fecha. Visualizar asistentes Visualizar al conjunto de los asistentes Estará conformado por un listado de asistentes junto a una sección dinámica de contenido donde se mostrará la información y citas asociadas al asistente seleccionado. Visualizar gráficas Visualizar gráficos de ciertos datos sobre personas y atenciones Se deberán poder visualizar gráficas de estilo pastel para los campos de edad, identidad sexual, orientación sexual, estado civil, y tipo de atención solicitada. Las derivaciones propuestas y realizadas se mostrarán integradas en un gráfico de barras. Exportar Exportar fichas y listados Dependiendo de la pantalla donde se esté situado, se exportará un listado de todas las personas, o la ficha de la persona en pantalla junto a todas sus citas. CARACTERÍSTICAS DEL MÓDULO DE SOCIOS 8.3. CARACTERÍSTICAS DEL MÓDULO DE SOCIOS Característica Descripción Detalle Añadir socio Añade a un socio nuevo a la base de datos. La acción debe ser accesible desde la barra de herramientas (Toolbar). Editar socio Modifica los datos personales de un socio existente. Esta edición ha de compartir vista con la edición de periodos de alta y cuotas del socio. Este requisito incluye la visualización de los datos del socio así como de sus periodos de alta y e información sobre cuotas. Eliminar socio No implementado Un socio puede estar dado de alta o de baja, pero en tanto que información contable que puede tener validez incluso mucho tiempo después de que un socio se dé de baja, sólo 38 se podrá eliminar un socio accediendo directamente a la base de datos como administrador. Añadir periodo de alta Asigna un nuevo periodo de alta a un socio existente Al añadirse un periodo de alta, éste se crea con la fecha actual y sin fecha de fin. Editar periodo de alta Modifica los datos personales de un asistente existente Cuando se edita la fecha de inicio o de fin del intervalo, se deben generar tantas cuotas vacías como nuevos meses haya, manteniéndose la información de cuotas preexistentes. Si el periodo de alta se acorta, las cuotas que queden fuera del intervalo sí serán eliminadas. Añadir cuota Añade una cuota a un periodo de alta Las cuotas se autogeneran al editarse los periodos de alta. Editar cuota Modifica los datos de una cuota existente. Eliminar cuota Elimina una cuota del sistema. Esto tiene lugar de forma indirecta al editarse un periodo de alta. Véase este requisito para más información. Buscar socio Buscar socio por nombre. Se podrá buscar a un socio por nombre, listando los resultados que encajen, y pudiendo navegar al socio que se seleccione. El formulario de búsqueda debe ser accesible y permanecer visible en todo momento. Visualizar socios Visualizar de forma paginada al conjunto de socios. Disponer de un panel donde se vean todas los socios listadas en forma de matriz mostrando su imagen, nombre y NIF. CARACTERÍSTICAS DEL MÓDULO DE COOPERACIÓN 39 8.4. CARACTERÍSTICAS DEL MÓDULO DE COOPERACIÓN Característica Descripción Detalle Añadir Actividad Añade una nueva Actividad a la base de datos. La acción está accesible desde la barra de herramientas (Toolbar). Visualizar Actividades Visualizar de forma paginada al conjunto de actividades. Disponer de un panel donde se vean todas las actividades listadas en forma de matriz mostrando su título y descripción. Añadir Cooperante Añade a un nuevo Cooperante a la base de datos. La acción está accesible desde la barra de herramientas (Toolbar). Editar Actividad Modifica los datos de una Actividad existente en la base de datos. La edición de una Actividad se permite desde varias vistas. Está disponible en la vista principal (Dashboard), así como en la vista donde se visualizan los datos de los Cooperantes, donde se indican en las Actividades en que participan. Los cambios en los Datos de una Actividad se verán reflejados en todas las vistas que incluyan dicha información. Borrar Actividad Borra una actividad de la base de datos. Con ésta se borran las tareas y los foros asociados a dicha actividad. Borrar una Actividad se permite desde varias vistas. Está disponible en la vista principal (Dashboard), así como en la vista donde se visualizan los datos de los Cooperantes, donde se indican en las Actividades en que participan. Los cambios en los Datos de una Actividad se verán reflejados en todas las vistas que incluyan dicha información. Ir Actividad Permite cargar los datos de una actividad. Al ir a una Actividad tendremos disponible en la interfaz sus datos de creación y el entorno necesario para la creación y modificación de las tareas y foros de la actividad. Esta acción se permite desde la vista de 40 gestión de los cooperantes, donde vemos las Actividades en que trabajan y desde el gestor de eventos, que con la información del evento nos permite ir a la actividad donde se generó dicho evento Filtrar Actividades Permite filtrar la lista de actividades. Las opciones para filtrar una actividad están en función de dos parámetros. El primero según el estado de la actividad y el segundo por meses, indicando las actividades que finalizan en los meses seleccionados. Filtrar Eventos Permite filtrar los eventos por fechas. Permite filtrar todos los eventos desde una fecha o filtrar los eventos en un intervalo de tiempo concreto. Editar Cooperante Modifica los datos personales de un cooperante. Sólo disponible desde el entorno de visualización del listado de cooperantes con que cuenta la asociación. Exportar Cooperante Exporta los datos del cooperante seleccionado. Permite pasar todos los datos personales del cooperante así como las actividades en que participa a formato Word. Añadir Tarea Añade una tarea a la actividad seleccionada. Acción disponible en el desarrollo de la actividad, permite crear las diferentes tareas en las que se subdivide una actividad. Tareas Finalizadas Visualizar una lista con las tareas finalizadas. Permite ver cada una de las tareas con toda la información asociada que ya se han finalizado. Finalizar Tarea Permite dar por concluida una tarea. Al dar por terminada una tarea, se modificará en la base de datos su estado a finalizado. Editar Tarea Modifica los datos de una tarea. Nos permite modificar los datos asociados a una tarea como son su descripción, el responsable de llevar a cabo la tarea o la fecha de finalización. Borrar Tarea Borra una tarea de la base de datos Borra la tarea seleccionada junto con todo el historial de desarrollo de la tarea. 41 Añadir Incidencia Añade Incidencias en la actividad seleccionada Acción disponible en el desarrollo de la actividad, permite crear un historial de incidencias donde se indica cada uno de los problemas surgidos durante el desarrollo de la actividad, informando al resto de cooperantes de las complicaciones surgidas. Ir Tarea Carga los trabajos realizados en la tarea. Permite cargar todos los trabajos realizados necesarios para el desarrollo de la tarea seleccionada. Añadir Foro Añade un Foro de discusión a la actividad seleccionada Acción disponible en el desarrollo de la actividad, permite crear diferentes Foros de discusión donde los Cooperantes pueden intercambiar opiniones sobre la Actividad o alguna de sus Tareas. Borrar Foro Borrar un foro de discusión de la actividad seleccionada. Borra el Foro seleccionado junto con todos los mensajes que se han enviado al foro. Ir Foro Permite cargar los mensajes del foro. Permite ir al entorno de gestión del foro. Estarán disponibles todos los mensajes enviados al foro de discusión así como la posibilidad de enviar nuevos mensajes. Añadir trabajo Tarea Inserta un trabajo en el historial de la Tarea Permite añadir un nuevo trabajo el historial de desarrollo de la tarea seleccionada. Añadir Incidencia Inserta una nueva incidencia en el historial de la tarea. Permite añadir al historial de problemas encontrados durante el desarrollo de la tarea nuevas incidencias. CARACTERÍSTICAS DE LA EXTRANET 8.5. CARACTERÍSTICAS DE LA EXTRANET Características Descripción Detalle 48 5. Organización de ensamblados en Visu al Studio DESPLIEGUE 9.3. DESPLIEGUE En este capítulo se muestra el diagrama de despliegue y se describen brevemente su funcionamiento. 49 6. Diagrama de despliegue Donde: 1. Aplicación servidor: Aplicación en constante funcionamiento donde corre el programa que permite la sincronización en tiempo real de las actualizaciones que emiten los clientes. 2. Servidor MySQL: Servidor de base de datos. 3. Servidor IIS: Servidor Web para permitir peticiones a la extranet. 4. Aplicación Web ASP.NET: La extranet. 9.3.1. Funcionamiento del servidor de sincronización El servidor de sincronización está diseñado con tecnología de sockets, de forma que está siempre esperando a recibir nuevas conexiones (que solicitan los clientes al lanzarse un módulo). Cuando un cliente realiza una actualización, emite un mensaje al servidor, el cual emite un broadcast al resto de clientes para que se actualice el módulo correspondiente (se controla que si emite un cliente de socios, no se actualice un módulo de atenciones receptor del mensaje, por ejemplo). En caso de que el servidor no esté activo, el cliente se intentará conectar en segundo plano cada varios segundos. Una vez vuelva a estar en funcionamiento el servidor de sincronización, el módulo se conectará rápidamente. 50 9.3.2. Organización de carpetas de la aplicación en el cliente Debido a que hay que guardar en el cliente una copia de la serialización de la configuración de acceso a la base de datos, las preferencias de usuario, las imágenes cacheadas de la base de datos por cuestiones de rendimiento y las imágenes por defecto, para cada módulo, se ha tenido que plantear una estructura de carpetas que lo soporte. Esta estructura se comprueba cada vez que se lanza la aplicación, creando las carpetas y archivos que por alguna razón no estuvieran presentes (porque los ha borrado el usuario, por ejemplo). ARRANQUE DE LA APLICACIÓN 9.4. ARRANQUE DE LA APLICACIÓN Ilustración 7. Flujo de etapas del arranque de la aplicación MVVM (MODEL-VIEW-VIEWMODEL) Lanzar aplicación (Gama.Boostrapper) Seleccionar Módulo Hacer login Lanzar Splash Screen Lanzar Bootstrapper del módulo seleccionado Crear y configurar el contenedor de dependencia Crear e inicializar el Shell (la ventana principal) Cerrar Splash Screen Inicializar el módulo (mostrar la ventana principal) 51 9.5. MVVM (MODEL-VIEW-VIEWMODEL) Sin pretender ser exhaustivos, sí se ha considerado relevante dedicar un apartado a los aspectos más importantes del patrón de diseño arquitectónico que se ha adoptado, debido a la relación directa que tiene con varios de los objetivos planteados para este proyecto, así como porque no resulta difícil desestimar superficialmente, por excesivo, el uso de un patrón como este. Esto último puede atender a varias razones. Entre ellas se encuentra la acusada curva de aprendizaje que supone desarrollar software con WPF (Windows Presentation Foundation) junto a MVVM. Otro motivo podría tener que ver con la tendencia general en la comunidad de desarrolladores a no dedicar mucho tiempo a las pruebas automatizadas. Esto se puede deber a que las consideran una pérdida de tiempo, pero también hay que considerar que escribir pruebas requiere tener otro mindset, que hay que aprender teoría y técnicas específicas, y que el impacto se hace mayor ya que te obliga a diseñar y programar el resto de código de otra manera. Todos estos elementos generan resistencia. A continuación se explica la motivación que hay para usar MVVM, y las características principales de este patrón de diseño arquitectónico. 9.5.1. Motivación para usar MVVM Cuando una aplicación que se ha desarrollado sin atender a la arquitectura crece en tamaño y alcance, el testeo y el mantenimiento se vuelven complejos. Es entonces cuando aparecen problemas, como el alto acoplamiento entre las vistas y la lógica de negocio. Esto dificulta la introducción de modificaciones en la capa visual así como el desarrollo de pruebas unitarias. MVVM fue desarrollado por Microsoft con estas cuestiones en mente, tratando además de aprovecharse de las características específicas de WPF. Los beneficios se MVVM para el flujo de trabajo se pueden son:  Durante el proceso de desarrollo, las actividades de desarrollo y diseño (de interfaces de usuario) se pueden lleva a cabo de forma más independiente y concurrente en sus componentes. Los diseñadores pueden concentrarse en la 52 vista, usando por ejemplo Expression Blend para ayudarse, mientras los desarrolladores programan los view models y el resto de componentes.  Se pueden crear pruebas unitarias para el modelo y los view models sin utilizar la vista. Esta podría ni existir y aún así se podrían desarrollar el modelo y los view models completamente (aunque se recomienda un flujo donde haya retroalimentación entre actividades).  Es fácil rediseñar la interfaz de usuario de la aplicación sin tocar el código porque las vistas están implementadas completamente en XAML. Nuevas versiones de las vistas funcionarán con los view models existentes en el caso general.  Encapsular, adaptando, a través del view model las clases del modelo para las vistas permite dejar intacto el modelo, lo cual podría resultar difícil, arriesgado o incluso imposible (si por cuestiones organizativas, de compatibilidad o de otro tipo no es posible modificarlo) modificarlo. Otros motivos para adoptar MVVM vienen dados por las expectativas futuras sobre MVVM y WPF en general. El mecanismo de Data Binding parece que va encontrado su lugar en el mundo del desarrollo software. Por ejemplo, tenemos algunos frameworks de Javascript que lo usan (como KnockoutJS, Kendo MVVM, Knockback.js), entre los cuales se encuentra Angular 2, que es mantenido por Google en código abierto. El mecanismo de Data Binding facilita el desarrollo de componentes desacoplados, en particular entre las vistas y la lógica de negocio. Siendo este un sempiterno objetivo de la ingeniería del software, se entiende que es razonable que la industria esté evolucionando en esa dirección. 9.5.2. MVVM (Model-View-ViewModel) MVVM es un patrón de diseño arquitectónico que facilita la separación entre la interfaz gráfica de usuario (front-end) y la lógica de negocio (back-end) en cuanto a su desarrollo se refiere. Es decir, que permite desarrollarlos de forma independiente. Para hacer esto posible, MVVM ha de contar con los siguientes componentes: 53 Ilustración 8. Arquitectura MVVM Donde, además de los componentes habituales (views y models), encontramos:  El ViewModel es una interfaz o intermediario entre el back-end y el front-end que se encarga de preparar los datos que recibe del back-end (transformándolos o disponiendo de ellos en distintas formas) de forma que facilite a la capa visual los datos consumir y presentar los datos de forma cómoda. Se puede entender como que un view model es, en efecto, un modelo para una vista. Es práctica extendida el asociar cada vista con un único view model.  Notifications y Data Binding se refieren a las notificaciones que se envían entre el ViewModel y la vista cuando alguno de los dos ha actualizado algún objeto que esté enlazado (que tenga un binding entre el ViewModel y la vista).  Commands como forma de encapsular las acciones disponibles para el usuario. Basta con hacer referencia a éstos en la vista e implementarlos después en el ViewModel. Incluso si no se implementan en absoluto, no tendrá lugar ningún error, si bien esas acciones no surtirán efecto alguno. Para finalizar, cabe mencionar que tanto MVVM como la librería Prism han sido desarrollados por Microsoft, si bien a día de hoy Prism es de código abierto y se aloja en GitHub. CLASES DE LOS ENSAMBLADOS COMUNES 9.6. CLASES DE LOS ENSAMBLADOS COMUNES En este capítulo de muestran los componentes más relevantes de los ensamblados comunes (Core y Gama.Common). 54 9.6.1. Ensamblado Core Ilustración 9. Clases comunes en Core 55 9.6.2. Ensamblado Gama.Common Ilustración 10. Clases base y comunicación 56 Ilustración 11. Eventos comunes 57 Ilustración 12. Controles personalizados (1/3) 9.8. CLASES DEL MÓDULO DE SOCIOS Se muestran en esta sección los diagramas de clases para los ensamblados del módulo de socios. No se incluyen todas las clases por una cuestión de presentación. El conjunto de vistas, view-models y resto de clases específicas quedan ya reflejadas en el esquema global de la arquitectura al principio de este capítulo. 9.8.1. Capa de acceso a datos (Gama.Socios.DataAccess) Ilustración 19. Diagrama de clases de Gama.Socios.DataAccess 9.8.2. Capa de negocio (Gama.Socios.Business) Ilustración 20. Diagrama de clases de Gama.Socios.Business 9.8.3. Eventos (Gama.Socios.Wpf.Eventos) Ilustración 21. Eventos específicos para el módulo de socios CLASES DEL MÓDULO DE COOPERACIÓN 9.9. CLASES DEL MÓDULO DE COOPERACIÓN Se muestran en esta sección los diagramas de clases para los ensamblados del módulo de cooperación. No se incluyen todas las clases por una cuestión de presentación. El conjunto de vistas, view-models y resto de clases específicas quedan ya reflejadas en el esquema global de la arquitectura al principio de este capítulo. 9.9.1. Capa de acceso a datos (Gama.Cooperacion.DataAccess) 22. Diagrama de clases de Gama.Cooperacion.DataAccess 9.9.2. Capa de negocio (Gama.Cooperacion.Business) 23. Diagrama de clases de Gama.Cooperacion.Business 9.9.3. Eventos (Gama.Cooperacion.Wpf.Eventos) 24. Eventos específicos para el módulo de cooperacion ARQUITECTURA CLIENTE-SERVIDOR 9.10. ARQUITECTURA CLIENTE-SERVIDOR No se considera oportuno explicar en qué consiste y cuál es el funcionamiento de una arquitectura cliente-servidor basada en sockets. No obstante, se incluye el siguiente diagrama de clases de la implementación concreta. Ilustración 25. Diagrama de las clases que intervienen en la dinámica cliente-servidor DISEÑO DE LA BASE DE DATOS 9.11. DISEÑO DE LA BASE DE DATOS En este capítulo se muestran los diagramas entidad-relación de la base de datos. 9.11.1. Servicio de atenciones Ilustración 26. Diagrama entidad-relación de la base de datos de atenciones 9.11.2. Gestión de socios Ilustración 27. Diagrama entidad-relación de la base de datos de socios 9.11.3. Cooperación Ilustración 28. Diagrama entidad-relación de la base de datos de cooperación 10.3.2. Validación La validación tiene en cuenta errores como un NIF repetido, un campo obligatorio vacío, una fecha en formato incorrecto o un email inválido. Se muestra a continuación un caso a modo ilustrativo. Ilustración 34. Validación de datos 10.3.3. Habilitación de botones Las acciones que requiere de algún tipo de validación no se podrán llevar a cabo si el estado actual no es válido. Esto es llevado a la interfaz en forma de inhabilitación de los botones involucrados, mostrándolos con una opacidad menor. A continuación se muestra tal transición. Ilustración 35. Botón de guardar inhabilitado Ilustración 36. Botón de guardar habilitado 10.3.4. Notificar a través del Status Bar La barra de estado se ilumina durante unos segundos cuando una acción que ha persistido la base de datos tiene lugar. Ilustración 37. Notificación mediante la barra de estado DISEÑO DE LA INTERFAZ DEL MÓDULO DE ATENCIONES 10.4. DISEÑO DE LA INTERFAZ DEL MÓDULO DE ATENCIONES En esta sección de incluye una relación entre todas las vistas del módulo de atenciones y los requisitos de usuario que satisfacen. Se adjunta una captura de pantalla cada vista a continuación. VISTA REQUISITOS QUE CUBRE Borde superior de la ventana Acciones para acceder a los sitios Web de Gamá y para volver al selector de módulo. Ver estado de conexión con el servidor de sincronización. Panel de navegación Navegar a los distintos paneles Cuadro de búsqueda Buscar persona, navegar a persona Barra de herramientas Añadir persona, añadir asistente, exportar persona, exportar listado, hacer copia de seguridad, restaurar copia de seguridad Barra de estado Notificar acciones completadas exitosamente Dashboard Visualizar personas, visualizar citas, visualizar atenciones, filtrar listados por fecha, filtrar por persona seleccionada, navegar a persona, navegar a cita, navegar a atención Panel de personas Listado Visualizar personas, navegar a persona Personas individuales Editar persona, editar cita, editar atención, visualizar citas de una persona, visualizar atenciones de una persona , eliminar persona (con sus citas y atenciones) Panel de citas Visualizar citas, crear cita, editar cita, navegar a persona, navegar a cita, navegar a atención Panel de asistentes Visualizar asistente, visualizar asistentes, editar asistente, editar cita, navegar a cita, navegar a persona Gráficas Visualizar gráficas Preferencias Modificar preferencias de usuario 10.4.1. Dashboard El dashboard sirve como vista global donde poder acceder de forma rápida a cualquier elemento, sea buscando por nombre a la persona, buscando el elemento en alguna de las listas o filtrando por fecha todos los datos mostrados. Ilustración 38. Dashboard Ilustración 39. Dashboard aplica filtro al seleccionar una persona de la lista 10.4.2. Cuadro de búsqueda El cuadro de búsqueda permite buscar a una persona por nombre. Aunque se muestran resultados limitados en el cuadro de resultados, el conjunto de resultados se muestran en la lista de personas. Durante la búsqueda sólo se ven las personas del conjunto filtrado. Ilustración 40. Cuadro de búsqueda afecta a los datos mostrados Cuando sólo hay un resultado, se autoselecciona la persona, propagando el filtro hacia las citas y atenciones también. Ilustración 41. Cuadro de búsqueda con un sólo resultado 10.4.3. Acciones de la barra de herramientas La barra de herramientas permite el acceso rápido a algunas funciones generales como añadir personas y atenciones, exportar, o hacer y recuperar copias de seguridad. Sólo se muestran las pantallas de las dos primeras pues las otras son acciones sin vista asociada. Ilustración 42. Añadir una nueva persona Ilustración 43. Añadir un nuevo asistente 10.4.4. Panel de personas El panel de persona se trata de un control de pestañas en el que siempre está incluida una primera pestaña con un listado paginado de todas las personas, junto a una pestaña más por cada persona que se haya abierto. La vista de la edición de la persona cuenta con dos sub-vistas: la edición personal de citas (tanto en formato de calendario como tabular) y la edición de atenciones. Ilustración 44. Listado paginado de personas Ilustración 45. Edición de citas de una persona Ilustración 46. Edición de citas en formato tabular En ocasiones conviene disponer de más espacio para ver el calendario. Por ello, la información personal se puede ocultar, como se muestra a continuación: Ilustración 47. Información de persona oculta 10.5.1. Dashboard. El Dashboard sirve como vista global donde poder acceder de forma rápida a cualquier elemento, sea buscando por nombre a cualquier socio, buscando a los socios en la lista principal. Se puede filtrar a los socios por tres categorías, edad, nacionalidad o estado de alta. Podemos realizar las tareas básicas desde esta vista, podemos modificar la información personal de cada socio, como navegar hacia la vista que nos muestra todos los datos personales del socio seleccionado así como el estado de sus cuentas. Ilustración 22. Dashboard general. La lista completa de socios que se muestra en el Dashboard se puede filtrar según tres categorías:  Edad: Con rangos de filtrados son menos de 25 años, entre 26 y 40 años, entre 41 y 55 años, entre 56 y 65 años y mayores de 65 años.  Nacionalidad: Generar una lista con los socios de una concreta nacionalidad.  Estado de alta como socio. Ilustración 23. Dashboard con filtrado de socios. En el Dashboard también se muestra dos apartados más se gran importancia. Se generan unos datos contables generales que permiten con un vistazo rápido conocer el estado de las cuentas. Muestra el número total de cuotas con la cantidad total de las cuotas pagadas, de las que están por pagar según los periodos de alta de los socios y las cuotas que están impagadas por fuera de plazo. Ilustración 24. Dashboard con listado de impagos y contabilidad general 10.5.2. Panel de Socios Se muestran todos los socios mediante una lista paginada, permitiendo navegar a la información personal de cada socio haciendo doble click en cada elemento de la lista sin tener que volver al Dashboard para navegar al socio escogido. Ilustración 25. Socios con listado completo paginado. Una vez tenemos un socio seleccionado nos presentamos en la vista con los datos del mismo. Aquí podremos también modificarlos datos personales además de crear los periodos de alta en la organización del socio y las cuotas que conlleva dicho periodo. A medida que se vallan abonando en el control de periodos de alta podemos modificar el estado de las cuotas correspondientes a los meses de pago. Ilustración 26. Socios con socio seleccionado y sus periodos de alta. Además en esta vista está disponible información contable relacionada con el socio seleccionado. Se generan listas de cuotas que están por pagar así como listas con las cuotas impagadas si tuviera alguna, indicando la fecha correspondiente a dichas cuotas. Ilustración 27. Socios con socio seleccionado y sus periodos de alta. Para añadir un socio bastará con hacer click en la acción correspondiente en la barra de herramientas. Ilustración 27. Añadir socio. En las preferencias se configuran algunos aspectos de la interfaz de usuario. También es aquí donde se configuran las opciones de la gestión automática de copias de seguridad. Ilustración 28. Preferencias DISEÑO DE LA INTERFAZ DEL MÓDULO DE COOPERACIÓN 10.6. DISEÑO DE LA INTERFAZ DEL MÓDULO DE COOPERACIÓN VISTA REQUISITOS QUE CUBRE Borde superior de la ventana Acciones para acceder a los sitios Web de Gamá y para volver al selector de módulo. Ver estado de conexión con el servidor de sincronización. Cambiar de módulo. Mostrar el cuadro de preferencias. Panel de navegación Navegar a los distintos paneles. Cuadro de búsqueda Buscar Actividad. Navegar a la actividad seleccionada Barra de herramientas Añadir Actividad. Añadir cooperante Exportar lista de actividades o una actividad seleccionada. Exportar la lista de cooperantes o un cooperante seleccionado. Hacer copia de seguridad. Restaurar copia de seguridad Barra de estado Notificar acciones completadas exitosamente Dashboard Visualizar lista de Actividades y editar la información de cada actividad. Navegar a cada actividad. Eliminar cada actividad. Filtrar listados de actividades. Mostrar la lista de eventos de las actividades. Navegar a la actividad desde el evento acaecido. Filtrar la lista de eventos por fechas. Actividades Listado actividades Visualizar lista completa de actividades y navegar a una actividad seleccionado Actividad seleccionado Mostar lista tareas que componen la actividad. Crear y borrar tareas. Borrar tareas Mostrar el historial de desarrollo de la tarea. Mostrar incidencia y complicaciones en el desarrollo de la tarea. Crear y borrar foros de discusión Mostar lista de foros de discusión sobre la tarea o la actividad. Mostrar los mensajes enviados a los foros de discusión. Mostar lista de eventos acaecidos en la actividad seleccionada. Filtrar la lista de eventos por fechas. Cooperantes Mostar información del cooperante seleccionado. Mostrar lista de actividades en las que trabaja. Modificar datos del cooperante seleccionado. Exportar los datos del cooperante seleccionado. Mostar lista completa de cooperantes. Seleccionar cooperantes que mostrar de la lista completa de cooperantes Calendario Mostar las actividades en formato de calendario según la fecha de entrega. Crear actividades desde la fecha del calendario. Gráficas Visualizar gráficas. Desarrollo de la tarea Ver lista de trabajos realizados. Añadir nuevos trabajos realizados en la tarea. Incidencias Ver listado de complicaciones surgidas en el desarrollo de la tarea. Añadir nuevas incidencias. Foro seleccionado Ver todos los mensajes enviados al foro de discusión. Añadir nuevos mensajes. 10.6.1. Dashboard. El Dashboard sirve como vista global donde poder acceder de forma rápida a cualquier actividad creada en el módulo así como de todos los eventos ocurridos en todas las actividades. Desde la lista de actividades se podrá modificar la información de cada una, así como las acciones de borrado y navegación al detalle de cada actividad. Desde los eventos también se puede navegar al detalle de la actividad donde se originó dicho evento. En esta lista de eventos se indica la fecha y hora en que se generó el evento, que evento se genero y la actividad donde se originó. Ilustración 29. Dashboard general. En esta vista también se nos permite poder filtrar la lista de actividades y la lista de eventos. Para la lista de actividades se cuenta de filtrado por el estado de la actividad y filtrado por meses, mostrando las actividades cuyas fechas de finalización se sitúan en los meses y año indicados. La lista de eventos se puede filtrar por fechas, todos los generados desde una fecha concreta o todos los generados en un rango de fechas concreto. Ilustración 30. Dashboard con filtrado de actividades y eventos. 10.6.2. Actividades. Se muestran todas las actividades mediante una lista paginada, permitiendo navegar a la información de cada actividad haciendo doble click en cada elemento de la lista sin tener que volver al Dashboard para navegar a la actividad escogida. Ilustración 31. Actividades con listado completo paginado 10.6.7. Foros de discusión Para tener un entorno donde poder intercambiar ideas u opiniones sobre las tareas a realizar o sobre la propia actividad se crean los foros de discusión. Con esta vista podemos añadir todos los foros necesarios. Ilustración 40. Nuevo foro de discusión 10.6.8. Seguimiento. Para llevar a cabo una tarea concreta se puede necesitar llevar a cabo diferentes actuaciones o trabajos. Se dispone un historial de trabajos realizados en la tarea para tener una visión completa de lo que se ha realizado. Se podrán añadir a este seguimiento cualquier trabajo realizado. Ilustración 41. Historial de trabajos realizados en una tarea. 10.6.9. Incidencias. Cuando se lleva a cabo una tarea pueden surgir contratiempos en la ejecución de los trabajos para completarla. En incidencias se cree un entorno donde poder llevar un control de los problemas surgidos y que los demás cooperantes de la actividad y su coordinar puedan conocer los detalles de las complicaciones surgidas. Ilustración 42. Incidencias en el desarrollo de una tarea. 10.6.10. Calendario. Para tener una visión global de las actividades según su fecha de finalización se genera este calendario. Ilustración 58. Calendario con las fechas de fin de las actividades DISEÑO DE LA INTERFAZ DE LA EXTRANET 10.7. DISEÑO DE LA INTERFAZ DE LA EXTRANET La extranet cuenta con un diseño sencillo y se limita a mostrados listados. Hay una sección por cada listado que se muestra. Las secciones son: personas, citas, asistentes, socios, cooperantes. A continuación de muestra una de estas listas, a modo representativo del resto. 59. Uno de los listados mostrados en la Extranet. En este caso, el listado de personas. _______________________________________________________ 11. TRABAJO FUTURO _______________________________________________________ Aunque se han cumplido los objetivos satisfactoriamente, la aplicación, concebida en sus inicios como base tecnológica a escalar en el futuro, cuenta a día de hoy con expectativas prometedoras. Algunas de las ideas que se barajan se listan a continuación. TRABAJO FUTURO GENERAL 11.1. TRABAJO FUTURO GENERAL En relación a cuestiones generales, algunas líneas de trabajo futuro consideradas han sido las siguientes:  Ofrecer más opciones se configuración de usuario  Interacción e integración entre módulos (un socio podría ser un cooperante, o un atendido, y diferentes combinaciones)  Enriquecer la interfaz con más feedback visual. Hay bastantes situaciones donde, por ejemplo, una iluminación transitoria ayudaría a llevar la vista del usuario a donde corresponde, mejorando la eficiencia así como la experiencia de uso. Poder trabajar offline y luego sincronizar. Ahora mismo se requiere conexión a Internet para poder acceder a cualquier de los módulos.  Replantear la arquitectura del ensamblado Gama.*.Wpf para tratar de organizarlo mejor en distintos ensamblados, de forma que, por ejemplo, el ensamblado Gama.Extranet no dependa de dicho ensamblado completamente sino de partes diferenciadas que hayan sido separadas.  Abstraer el sistema personalizado de navegación que se implementó como alternativa a la navegación con Prism.  Hacer más sofisticado (aumentando las prestaciones) el sistema de comunicación entre los clientes y el servidor de sincronización.  Plantear el uso de librerías libres de inteligencia artificial (machine learning probablemente) al modo que se utilizan en centros médicos (al menos en EEUU) para predecir distintas necesidades asistenciales de las personas que pasan por Gamá. TRABAJO FUTURO PARA EL MÓDULO DE ATENCIONES 11.2. TRABAJO FUTURO PARA EL MÓDULO DE ATENCIONES En relación al servicio de atenciones, algunas líneas de trabajo futuro consideradas han sido las siguientes:  Añadir vista de calendario en formato de planificador semanal (scheduler).  Generar gráficas sobre más conjuntos de datos  Exportar gráficas a formato CSV o XLSX.  Establecer, en la barra superior de acciones, notificaciones al arrancar el programa de las citas programadas para hoy.  Permitir la programación de avisos al email o teléfono de un asistente que tenga una cita próxima en el tiempo. TRABAJO FUTURO PARA EL MÓDULO DE SOCIOS 11.3. TRABAJO FUTURO PARA EL MÓDULO DE SOCIOS En relación a la gestión de socios, algunas líneas de trabajo futuro consideradas han sido las siguientes:  Sistema de aviso de socios próximos a cumplir años o que cumplen el día presente.  Permitir el envío de correos electrónicos y mensajes de teléfono desde la aplicación para notificar de cuestiones como el impago de cuotas. TRABAJO FURUTO PARA EL MÓDULO DE COOPERACIÓN 11.4. TRABAJO FURUTO PARA EL MÓDULO DE COOPERACIÓN En relación al módulo de cooperación, algunas líneas de trabajo futuro consideradas han sido las siguientes:  Dividir cooperantes en distintas categorías, como voluntarios, colaboradores parciales, entidades específicas, etc., de forma que se facilite la gestión de cooperación en relación a las distintas actividades. Estas nuevas categorías contarían con nueva información asociada, como preferencias de actuación, disponibilidad, seguimiento de relación con ellos, etc.  Plantear un sistema de mensajería más sofisticado e integrado. TRABAJO FUTURO PARA LA EXTRANET 11.5. TRABAJO FUTURO PARA LA EXTRANET Finalmente, en relación a la extranet, algunas líneas de trabajo futuro consideradas han sido las siguientes:  Aumentar la cantidad de información accesible  Diferenciar entre distintos usuarios y permisos de acceso a la información _______________________________________________________ 12. CONCLUSIÓN _______________________________________________________ Si se hubieran de resumir y abstraer los objetivos de este proyecto, tendríamos, por un lado, ofrecer a Gamá una aplicación moderna (con una experiencia de usuario rica) y eficiente y, por otro lado, que ha tratado sobre el desarrollo de aplicaciones altamente estructuradas y de bajo acoplamiento, donde se enfatiza el diseño de una arquitectura que facilite la creación de pruebas y el mantenimiento, así como dar soporte a los desarrolladores para trabajar con mayor independencia y productividad. Todo esto supone retos técnicos y organizativos que no deben ser infravalorados. Los costes de tener un código acoplado se conocen, de ahí que surgieran y sigan creándose alternativas de diseño como las adoptadas en este proyecto. No obstante, hay que ser conscientes de los costes de hacer un diseño desacoplado [véase el artículo 1 de la bibliografía], para analizar si se ajusta a la idiosincrasia de un desarrollo determinado y si es por tanto apropiado adoptar tal diseño. Dadas las características de este proyecto, en el que los requisitos han sido cambiantes tanto en detalle como en número (aparecieron nuevos requisitos durante del desarrollo), y en el que el diseño ha tenido por tanto que ir evolucionando, el impacto de un cambio (número y peso de los cambios que a su vez provoca) se vuelve un criterio prioritario a la hora de elegir la metodología de desarrollo y el enfoque arquitectónica. A la luz de los resultados, que se muestran en esta memoria en forma de requisitos implementados –funcionales y de calidad–, así como de argumentaciones varias y múltiples esquemas y diagramas, se concluye lo siguiente: En primer lugar, que los objetivos planteados para Gamá han sido alcanzados, ya que los objetivos mínimos de funcionalidad y calidad se han alcanzado y superado ampliamente, se ha implementado un diseño visual moderno y una interacción userfriendly, y se han mantenido buenos niveles de rendimiento. En segundo lugar, que el desarrollo ha sido en efecto satisfactorio: 1. En términos de impacto de los cambios propios a la constante evolución del sistema, ya que en general se pudieron abordar de forma ordenada, además de suponer un ejercicio periódico de re-entendimiento, de revisión informal de código, de la arquitectura tanto a nivel global como a niveles más locales. 2. En términos organizativos, ya que se permitió el desarrollo independiente no sólo de vistas y resto de componentes en general para un mismo desarrollador, sino entre los desarrolladores y los ensamblados, pudiendo, como se ha mostrado, trabajar en un módulo aun cuando los otros ni siquiera compilen, lo cual contribuye al aumento de productividad. 3. En términos académico y profesionales, se ha podido en efecto poner en práctica y aprender ampliamente sobre las tecnologías, técnicas, método organizativo y flujo de trabajo.