 |
| Trabajo final realizado para el Grado Superior en Desarrollo de Aplicaciones Web. |
Análisis previo
Descripción del producto o proyecto a realizar.
La idea de realizar un sistema gestor de apneas, tiene como finalidad poder elaborar informes, resúmenes y estadísticas sobre la calidad del sueño, al igual que ofrecer al usuario que padece apneas del sueño la posibilidad de revisar los propios datos que ha ido introduciendo a lo largo del tiempo.
En principio cada usuario podrá introducir los datos de su sueño (número de apneas o promedio por hora, tiempo de sueño, hora de inicio y final…), almacenarlos en la base de datos, consultar promedios y estadísticas de sus datos, imprimir informes que presentar a su médico para orientar al docente, registrar el tipo de máquina que tiene actualmente, consultar otras que están en el mercado y guardar notas en cada registro de sueño.
Además, existe la posibilidad de poder subir noticias o documentación para mejorar la calidad del resto de usuarios, noticas de interés, documentación, nuevos descubrimientos o simplemente compartir su opinión con el resto de usuarios.
Descripción de la empresa.
Descripción general de la empresa
La idea principal es encontrar un socio que pusiera el 75% del capital financiero para empezar una Sociedad Laboral Limitada, aportando un capital de en torno a los 2250€, junto al 48% de las acciones de la empresa; yo como socio principal, tendría el 52% de las acciones y llevaría toda la gestión de la aplicación, aportando como capital la idea de negocio y el resto de 750€ para poder registrarnos como empresa SL.
Descripción del negocio y mercado de la empresa.
SGA está enfocado a usuarios específicos ya que, aunque puede usarse por cualquier usuario registrado, su funcionalidad se basa en el registro manual de la calidad de sueño de los usuarios que padecen apneas durante las etapas de sueño; de manera que cualquier persona portadora de un Smartphone o un dispositivo conectado a la red podría hacer uso de la aplicación.
Ahora bien, esta aplicación también está orientada a todo el ámbito sanitario ya que permite al docente, poder revisar la información que van introduciendo sus pacientes día a día, con el objetivo de realizar informes o introducir cambios en los diagnósticos establecidos.
Tanto es así, que favorece la continua comunicación entre médico y paciente, dando un espacio de noticias, semejante a un blog o foro, en el que pueden compartir noticias y/o experiencias, al igual que sus propias recomendaciones a otros usuarios; esta opción puede ser consultada de forma anónima.
Justificación del proyecto
Como persona que duerme con una de estas mascarillas, es difícil localizar una herramienta o aplicación que sea sencilla de entender, totalmente funcional y gratuita, que ofrezca un seguimiento específico y diario, con la opción de generar e imprimir informes, con los datos almacenados previamente.
La parte más útil que quiero implantar es ésta última, ya que muchas veces las empresas que gestionan y dan soporte a las mascarillas, no están coordinadas con los centros de salud, por lo que los médicos no pueden tener informes actualizados de la mejoría o empeoramiento del paciente.
Como explicaremos en la memoria económica, se calcula que alrededor del 48% de la población padece un tipo de Narcolepsia, es decir que casi 350.000 de habitantes en Zaragoza padecen algún problema que empeora la calidad de sueño; ensayos clínicos apuntan además, a que solamente el 10% de casos esta diagnosticados como apneas, ya que mayoritariamente estas patologías se achacan estos síntomas a dolores de cabezas puntuales, cansancio o tabaquismo.
Este tema se desarrolla más detalladamente en el apartado memoria económica
Planificación del proyecto
 |
Planificación estimada inicial |
 |
Planificación real al acabar el proyecto |
Modelado: Análisis y diseño.
Diagramas de casos de uso
Diagrama de entidad-relación
Diagrama relacional
Scripts
CREATE DATABASE IF NOT EXISTS `apneas` DEFAULT CHARACTER SET utf8 COLLATE utf8_general_ci; USE `apneas`; SET SQL_MODE = "NO_AUTO_VALUE_ON_ZERO"; SET time_zone = "+00:00";
DROP TABLE IF EXISTS `users`;
ALTER TABLE `users` ADD PRIMARY KEY (`id`), ADD UNIQUE KEY `id` (`id`); ALTER TABLE `users` MODIFY `id` int(11) NOT NULL AUTO_INCREMENT, AUTO_INCREMENT=17;
DROP TABLE IF EXISTS `posts`;
ALTER TABLE `posts` ADD PRIMARY KEY (`id`), ADD UNIQUE KEY `id` (`id`), ADD UNIQUE KEY `id_2` (`id`);
ALTER TABLE `posts` MODIFY `id` int(11) NOT NULL AUTO_INCREMENT, AUTO_INCREMENT=22;
Diagrama de Clases
Diagrama de secuencias de ejecución
Diseño de Interfaces
Abstract
Administrator System of Apneas (ASA), was established with the main objective of providing people a software that stored all the daily sleep quality information. This is useful because, nowadays, there is no other tool able to store and write reports by using the data previously registered. This web application is user-friendly and easy to use.
It has only three options: 'create', 'log in' and 'sleep history'. As it is to understand, the function 'create', stores dreams' data. Secondly, the function 'log in' allows users to identify his own sleep information, and finally, 'history' offers users the possibility to check their dreams history data so far.
The advantage of all of this is that hospitals and recovery doctors have such information to change the treatment just in time; furthermore this information is constantly being updated. However, on the other hand, the patient has to store day-to-day the information provided by the machine every time the user wakes up which is: bedtime, number of apneas per hour, dream quality, etc.
We could conclude that the final goal is to achieve enough independency to gather information without the need of nightly human interaction, with the purpose, in the end, of persisting in helping people.
Implementación, despliegue y pruebas realizadas
Implementación de la aplicación
Los principales problemas que hemos encontrado a la hora de realizar el proyecto han sido respecto a la estructura base en la que se apoya el mismo, principalmente en la base de datos.
Al principio del mismo, se perdió demasiado tiempo en el desarrollo, sin éxito, de la base de datos, que constaba de muchas relaciones, claves ajenas y atributos, por lo que al cabo de casi tres semanas sin progreso se decidió borrar el proyecto entero y replantear de nuevo como íbamos a subsanar los errores, intentando recuperar el tiempo que se había estado invirtiendo hasta el momento.
Así pues y tras varias noches de planificación, se decide cambiar a una estructura mucho mas básica de modelo vista controlador, que principalmente se iba a desarrollar en php puro, con ayuda de estilos sencillos y bases de datos sencillas.
Se decide entonces, prescindir de las ventajas que podría ofrecernos frameworks como Laravel, a la hora de dinamizar y reutilizar código, y la incorporación de javascript hasta que no se tuviera un prototipo definido que pudiera ser presentado a un cliente real.
Con la reciente decisión, se recupera el tiempo y se gana rapidez en el desarrollo de la aplicación, consiguiendo que en menos de un mes se consiga acabar un prototipo que pueda ser presentado, y desarrollando una memoria que estaba por encima de los puntos obligatorios que se pedían en aquel momento.
A un mes de la entrega, y una vez se empieza con las pruebas de caja negra, nos damos cuenta de que, aunque realmente el prototipo funciona, no cumple del todo con los principios de usabilidad y entorno amigable.
Se reestructura toda la interfaz con el objetivo de eliminar elementos que provoquen dudas o incertidumbres en el usuario; se suprimen funciones filtrando según los privilegios y necesidades del usuario, se arreglan direccionamientos y se añade de información adicional en formularios y entradas de datos que consiguen mejorar la experiencia de usuario, según pruebas que se desarrollan a posteriori.
Respecto al diseño, se ha tenido en cuenta la elección de colores, tamaños y formato de letra; se opto por un azul como simbología a la rama sanitaria, una familia de letra sencilla y una página sencilla sin ningún tipo de recargo de decoración.
Ahora bien, se ha cumplido con el 50% de la funcionalidad total de lo que se planteaba originalmente, principalmente por la falta de tiempo del que he podido disponer, debido a factores externos al tiempo real que se ha tenido desde el inicio del proyecto.
Para finalizar este apartado, explicare todas las implementaciones pendientes de realizar pero que si se habían tenido presentes teóricamente; básicamente era generar una funcionalidad del tipo foro, en el que los usuarios pudieran compartir sus experiencias, noticias o consejos a la comunidad, estableciendo una entidad mas (roles), que designara las posibilidades de cada usuario.
Como ampliación a esta última, surgió la idea de realizar una pequeña intranet de incidencias similar a programas básicos de ‘ticketing’ que usan los centros de atención a usuarios (CAU), para resolver dudas e incidencias que les fueran ocurriendo a los usuarios de la aplicación, ya bien siendo tramitadas directamente por el administrador o yendo a parar a la sección de soporte que explicamos.
Despliegue del servicio en servidor
Hemos realizado la instalación de apache, a través de un sistema operativo gratuito Unix (Linux Mint); para poder generar nuestro sitio en local tendremos que descargar apache, instarlo o simplemente situar la carpeta principal en la raíz, de manera que detecte directamente el servicio web.
A la hora de activar nuestro sitio web local, deberemos situar un fichero con el formato nombreSitio.conf (en nuestro caso apneas.conf). En el tendremos que escribir todas las directivas y permisos de acceso a los archivos que tendrá nuestra página (acceso de usuarios, privilegios o creación de diferentes grupos de acceso).
En nuestro caso se presenta el siguiente contenido.
<VirtualHost *:80>
ServerName apneas.local
ServerAdmin webmaster@localhost
DocumentRoot /home/alumno/apneas/public
ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined
<Directory /home/alumno/apneas/public>
Options Indexes FollowSymLinks MultiViews
AllowOverride All
Require all granted
</Directory>
</VirtualHost>
Instrucciones para la creación de un servicio web.
Abrimos una terminal desde el menú de opciones situado en la barra inferior del escritorio:
Nos situamos en el directorio raíz, o bien podemos directamente movernos al directorio al que queremos llegar mediante el comando cd /etc/apache2/sites-available
A continuación, creamos un fichero en el que meteremos las directivas anteriores: touch apneas.conf
Para poder abrir el archivo y trabajar normalmente, lo mas cómodo es ejecutar el editor de texto nano, así que ejecutaremos: nano apneas.conf
En el caso, de que no hayamos generado el archivo anteriormente se auto-creará, hay que prestar importancia al nombre que indicamos del archivo, ya que en el caso de equivocarnos, generaríamos otro archivo diferente al ejecutar nano.
Se nos abrira la siguiente interfaz en la que incluiremos la directiva11.1, cambiando los datos siguientes:
ServerName: sera la ruta que tendremos que buscar en los buscadores para poder ver nuestro servicio web, pondremos entonces apneas.local
DocumentRoot: designa el directorio al que tiene que acceder la maquina para cargar la pagina principal y el resto de implementaciones que lleve.
Directiva de directorio ‘Directory’: sirve para otorgar privilegios y permisos a uno o varios usuarios sobre esa carpeta y sus hijas; en nuestros caso, Options Indexes FollowSymLinks MultiViews (permitimos seguir enlaces simbolicos e indexar nuestras paginas y vistas), AllowOverride All (indicamos que cualquiera puede sobreescribir la informacion que aquí depositemos); y por ultimo Require all granted, indicamos que cualquier persona tiene permisos para acceder.
Importante: en la apertura de la etiqueta Directory tenemos que declarar la ruta explicita a la que se aplicaran dichas directivas o reglas. Sera entonces la carpeta public donde residen todos nuestras vistas.
Nuestro caso: /home/alumno/apneas/public
Salimos de esta interfaz guardando los datos pulsando ctrl+x, e indicando que queremos guardar los cambios.
Para habilitar el nuevo sitio deberemos introducir el comando sudo a2ensite apneas.conf, que sirve para indicarle a Ubuntu que de una manera explícita, el sitio y las directivas que contiene ese archivo de configuración esta activo.
Deberemos entonces, reiniciar el servicio apache y salvar los datos con el comando sudo service apache2 restart, nos pedirá la clave de administrador que coincide con la contraseña de usuario que tengamos actualmente.
Ahora bien, debemos indicar en qué dirección ip debe buscar el registro DNS, para cargar el servicio web; esto debe indicarse en el archivo /etc/hosts.Como anteriormente, nos situamos en el directorio /etc y ejecutamos nano hosts, que nos abrirá de nuevo el editor de texto con el contenido del fichero.
Deberemos añadir nuestro registro con la ip asociada al mismo, en nuestro caso y para evitar errores podemos poner la dirección de localhost 127.0.0.1, que apunta a nuestra ip sea cual sea.
Fase de pruebas y testeo
Caso de prueba 1
Identificador: v0206_01
Precondiciones: El usuario nunca ha visitado nuestra web y no ve el código (prueba de caja negra).
Objetivos: Revisar la usabilidad de la interfaz, asegurar las restricciones de los usuarios anónimos, asegurar la claridad y validez del formulario, y mejorar la experiencia de usuario
Conclusiones: la usabilidad de la interfaz es amigable aunque diferentes departamentos confunden al usuarioEl apartado 'Historial' no está restringido a usuarios anónimos, y debería
Enlaces a paginas mal construidos o que redirigen a sitios erróneos
Enlaces sin función o relevancia ante el usuario
No hay validación previa en el formulario
El formulario no guía al usuario
Caso de prueba 2
Identificador: v0206_01
Precondiciones: el usuario no conoce los cambios realizados ni está registrado
Objetivos: Revisar los cambios introducidos, comprobar si los cambios realizados mejoran la experiencia de usuario y asegurar la buena localización de los recursos (enlaces, ayudas…etc.).
Conclusiones:
Los botones de los formularios no son explicativos
El usuario consigue registrarse e iniciar sesión sin problemas
Mejora de la experiencia de usuario pero sigue habiendo conflictos a la hora registrar un sueño.
No funciona el método ‘delete’ posiblemente, a un error en la base de de datos
Caso de prueba 3
Identificador: v0906_01
Precondiciones: El usuario nunca ha usado nuestra aplicación web
Objetivos: Revisar los cambios reflejados y comprobar si los cambios realizados mejoran la experiencia de usuario. Revisar la funcionalidad de nuestra aplicación y la usabilidad de la interfaz.
Conclusiones:
Los botones de los formularios siguen sin ser descriptivos
El usuario genera incertidumbres a la hora de registrarse
Conseguimos iniciar sesión y eliminar su perfil
Comprobamos que los nuevos enlaces si son descriptivos
Caso de prueba 4
Identificador: v0906_02
Precondiciones: El usuario desconoce los cambios realizados
Objetivos: Revisar la funcionalidad final de la aplicación y la usabilidad
Conclusiones
La interfaz es amigable y fácil de usar
El usuario consigue registrarse e iniciar sesión
El usuario consigue modificar sus datos de perfil
El usuario consigue crear, modificar y eliminar entradas correctamente
El usuario consigue cerrar sesión con éxito
Memoria económica
Los gastos recursos necesarios, se han minimizado al máximo, puesto que solamente se han utilizado versiones de software libre (visual studio, sublime text…etc.), herramientas online (Excel online, draw.io…) y el equipo que dispone el desarrollador de la aplicación.
En total y hasta el momento el conjunto de horas totales y contabilizadas según la tarea es de 64 horas, lo que equivaldría a dos semanas de trabajo, con 7 horas de jornada diaria.
Todos los datos han sido extraídos y calculados a través de la información encontrada en documentos publicados, expuestos en la bibliografía localizada al final de este documento:
Para establecer un precio de mantenimiento, se ha realizado una investigación de mercado, para valorar qué precio es el idóneo para que nuestros clientes estén dispuestos a pagarlo, sin perder la competitividad con otro tipo de aplicaciones online de la rama sanitaria.
Clientes proclives a comprar la aplicación: se realiza un estudio, con el total de habitantes en Zaragoza capital, estableciendo los porcentajes recogidos por estudios clínicos acerca de la Narcolepsia y suponiendo que el 60% de los afectados serán suscriptores de la aplicación.
Respecto a los gastos de coste fijo o variable, hemos incluido todos aquellos que tienen que ver con el mantenimiento de los equipos, los gastos del alquiler y los derivados del mismo (servicios de luz, agua…etc.); por último se han incluido todos los costes derivados de la representación tanto en publicidad y medios locales, como la persona física de la empresa que nos representa frente a las instituciones interesadas en contratar nuestros servicios.
DATOS ESPECIFICOS SOBRE LA POBLACION CON APNEAS
Se calcula, como hemos detallado anteriormente que alrededor del 48% de la población padece alguna Narcolepsia, lo que nos sitúa en 339.314 habitantes, solamente en Zaragoza capital.
De todos estos habitantes, se calcula que el 10% padecen Apneas, puntuales, generales o crónicas, que en cifras se resumen en que 33.931 personas tienen apneas del sueño; sabiendo que el 90% de los afectados no tienen diagnostico, hemos basado nuestras estadísticas en casos generales, arrojando los siguientes datos:
Habitantes en Zaragoza: 706907
Personas con algunas Narcolepsia diagnosticada: 339.314, de las cuales 33.931 son apneas del sueño.
Personas sin diagnosticar que podrían hacer uso de nuestra aplicación: 305.382, lo que se traduce en un 43% los habitantes de Zaragoza.
Según rangos de edad, hemos diferenciado tres grandes sectores:
Menores de edad (<18 años)
Edades intermedias: personas con una salud estable ni condiciones que le expongan directamente con estas patologías.
Edades limite: (>50): empeoramiento de aparato respiratorio y aumento de problemas cardiovasculares.
Bibliografía
Admin. (7 de Febrero de 2016). Testing Colombia. Recuperado el 2 de Junio de 2019, de https://www.testingcolombia.com/un-caso-de-prueba-de-ejemplo/
Google Play Store. (s.f.). Recuperado el 05 de Junio de 2019, de Aplicaciones de medicina con pago previa: https://play.google.com/store
INAEM - Sociedad Laboral Limita. (s.f.). Recuperado el 31 de Marzo de 2019, de https://inaem.aragon.es/sociedades-laborales-0
INE. (1 de Enero de 2018). Instituto Nacional de Estadistica. Recuperado el 5 de Junio de 2019, de https://www.ine.es/jaxiT3/Datos.htm?t=2907
Perez, A. (06 de Marzo de 2016). Sociedad Española de Neurologia. Recuperado el 05 de Junio de 2019, de http://www.sen.es/saladeprensa/pdf/Link182.pdf
Rebolledo, U. (16 de Julio de 2013). SlideShare. Recuperado el 5 de Mayo de 2019, de https://es.slideshare.net/ulisesr/configuracin-de-word-para-trabajos-de-grado
Torrellas Marco, A. (30 de Mayo de 2019). Youtube. Recuperado el 04 de Junio de 2019, de Presentacion del prototipo: https://www.youtube.com/watch?v=7xU2AYHVdu0
Torrellas, A. (04 de Junio de 2019). SGApneas. Obtenido de Bitbucket: https://bitbucket.org/gsuperior2017/proyectodaw19/src/proyecto/
Torres, G. SGApneas. Logo principal de la aplicacion. Diseñado con Photoshop, Zaragoza.
W3Schools. (s.f.). Recuperado el 2 de Junio de 2019, de https://www.w3schools.com/sql/sql_orderby.asp
Comentarios
Publicar un comentario