UNIVERSIDAD SIMÓN BOLÍVAR

Transcripción

1 UNIVERSIDAD SIMÓN BOLÍVAR DECANATO DE ESTUDIOS PROFESIONALES COORDINACIÓN DE INGENIERÍA DE LA COMPUTACIÓN SOLUCIÓN BASADA EN TABLETAS PARA LA CLÍNICA SANTA SOFÍA Por: JOSÉ FRANCISCO FIORILLO VERENZUELA INFORME DE PASANTÍA Presentado ante la Ilustre Universidad Simón Bolívar Como Requisito Parcial para Optar al título de Ingeniero de Computación Sartenejas, Junio del 2012

2 UNIVERSIDAD SIMÓN BOLÍVAR DECANATO DE ESTUDIOS PROFESIONALES COORDINACIÓN DE INGENIERÍA DE LA COMPUTACIÓN SOLUCIÓN BASADA EN TABLETAS PARA LA CLÍNICA SANTA SOFÍA Por: JOSÉ FRANCISCO FIORILLO VERENZUELA Realizado con la asesoría de: Tutor Académico: Prof. Carmen Rosseline Rodríguez Tutor Industrial: Ing. Alejandro Azcunes INFORME DE PASANTÍA Presentado ante la Ilustre Universidad Simón Bolívar Como Requisito Parcial para Optar al título de Ingeniero de Computación Sartenejas, Junio del 2012

3

4 Resumen Este proyecto describe todas las actividades desarrolladas durante el proyecto de pasantía larga dentro de la empresa Global Consultants Group. El proyecto se basó en diseñar e implementar dos aplicaciones móviles para la clínica Santa Sofía. Una aplicación fue diseñada para el módulo de orientación diagnóstica y otra para el módulo de emergencia. El módulo de orientación diagnóstica es el encargado de registrar los datos de los pacientes que quieren ingresar a la clínica sin previa cita, en donde se priorizan los pacientes y se decide, dependiendo de una serie de variables que el médico del área evalúa, hacía que módulo de la clínica o fuera de la clínica se envía el paciente. La otra aplicación es para el módulo de emergencias, en el cual se atienden a los pacientes con emergencias y en este sistema desarrollado se registra la información del caso de cada paciente. El proyecto se llevó a cabo con éxito y se lograron desarrollar ambas aplicaciones completamente funcionales y con calidad aprobada por el cliente. Durante el desarrollo del proyecto se utilizó la metodología RUP, en conjunto con el kit de desarrollo de Android. iv

5 Dedicatoria A mi madre Ligia Margarita por todo el apoyo que me dio en los momentos más difíciles de mi vida y durante mi etapa universitaria. A mi padre, hermanas, familiares y amigos que me ayudaron y estuvieron apoyándome y auspiciándome a finalizar mis estudios. v

6 Agradecimientos En la elaboración de este proyecto de pasantía colaboraron muchas personas a las que quiero agradecer enormemente y que sin ellos hubiese sido más difícil esta etapa. A mis padres Ligia y José, por ofrecerme su apoyo incondicional durante toda mi vida, guiarme en el trayecto y ayudarme en cada decisión relevante para llevarme por los mejores caminos. A mis amigos y personas cercanas que estuvieron allí cada vez que necesité un momento de felicidad, tranquilidad, diversión y distracción para formar parte de éstos. A Audra, gracias por estar cerca de mí en grandes e importantes momentos para brindarme todo tu cariño, apoyo y llenarme de tantos momentos felices que en mi vida quedarán marcados para siempre. Tanto tiempo contando contigo y recibiendo tantas cosas de ti, no se puede dejar pasar. A mi tutor académico la profesora Carmen Rosseline Rodriguez, por brindarme su apoyo en este proyecto y el proyecto anterior, además de ofrecerme su valioso tiempo, sus conocimientos y sus consejos durante mi pasantía. A mi tutor industrial el ingeniero Alejandro Azcunes, por guiarme durante la pasantía, ofrecerme todo sus conocimientos y tener la mejor disposición para atenderme cuando lo necesité. A todos y cada uno de los profesores que me dieron clases en la universidad, gracias a ellos logré completar este proyecto. Ustedes dejaron una experiencia en mí, a la que espero sacarle el mayor provecho. Muchas gracias por su todo su tiempo y dedicación hacia los estudiantes. Son el corazón de esta sociedad que tanto requiere de sus conocimientos y tan poca estimación tiene con ustedes. vi

7 ÍNDICE GENERAL Introducción 1 1. Entorno Empresarial Descripción de la Empresa Estructura Organizacional de la Empresa Ubicación del Pasante 5 2. Marco Teórico Dispositivo Móvil Tableta Arquitectura Cliente-Servidor Arquitectura Tres Capas Arquitectura de Sistemas Operativos Móviles Arquitectura Aplicaciones Móviles Marco Tecnológico Formato JSON Protocolo SOAP Android Kit de Desarrollo de Android Microsoft Visual Studio Microsoft SQL Server Marco Metodológico Característica y Estructura RUP Fases de RUP Fase de Inicio Fase de Elaboración Fase de Construcción Fase de Transición 21 vii

8 5. Desarrollo del Sistema Fase de Inicio Visión del sistema Riesgos Stakeholders (Partes Interesadas) Usuarios Herramientas de Desarrollo Infraestructura de Desarrollo Hardware Software Fase de Elaboración Planificación de la Fase Arquitectura del Sistema Vista de Implementación A Nivel de Aplicación Móvil A Nivel de Servicio Web Vista de Datos Vista de Casos de Uso Actores Descripción de Caso de Uso Fase de Construcción Primera Iteración Orientación Diagnóstica Servicio Web Aplicación Móvil para la Tableta Manejo de Sesiones Reportar Nuevo Paciente en el Módulo Reportar Toma de Signos Vitales 37 viii

9 Reportar Motivo de Consulta Reportar Prioridad del Paciente Reportar Destino del Paciente Reportar Alta de un Paciente Deshacer Alta de un Paciente Documentación de Prioridad según Síntoma Primera Iteración Emergencia Servicio Web Aplicación Móvil para Tableta Listar Casos Activos en el Área de Emergencia Registrar Información del Paciente Solicitar Examen Médico, Medicamento y MMQ Deshacer y Colocar Historia Médica Como Definitiva Ejecución de Pruebas Dificultades Presentadas en la Implementación del Sistema Conclusiones y Recomendaciones Bibliografía 47 Apéndices 49 A. Lista de Riesgos 51 B. Skateholders con sus Respectivas Responsabilidades 53 C. Usuario de las Aplicaciones 55 D. Diagrama ER 57 E. Diagrama Relacional 59 F. Metodología de Comparación de Tabletas 61 G. Ejecución de la Comparación de Tabletas 66 H. Documento de Visión del Sistema 68 I. Documento de Requerimientos del Sistema 81 ix

10 J. Especificación de Casos de Uso 95 K. Glosario 119 L. Lista de Riesgos 126 M. Documento de Arquitectura 136 N. Plan de Pruebas 150 O. Manual de Instalación 160 P. Casos de Prueba 187 x

11 ÍNDICE DE FIGURAS 1.1 Estructura organizacional de Global Consultants Group Arquitectura del sistema operativo Android Arquitectura del sistema operativo ios Diagrama de ciclo de vida de RUP Arquitectura de la aplicación nativa de Android Arquitectura de la aplicación en el servidor Diagrama de Casos de Uso de Médico Especialista de Emergencia Diagrama de Casos de Uso de Médico Especialista de Orientación Diagnóstica Diagrama de Casos de Uso de Enfermera de Orientación Diagnóstica 32 xi

12 LISTA DE ABREVIATURAS GCG Global Consultants Group 2021 IDE OHA CSS SOAP XML W3C.NET CIL MSIL C++ Integrated Development Environment (Entorno de Desarrollo Integrado) Open Handset Alliance Clínica Santa Sofía Simple Object Access Protocol Extensible Markup Language World Wide Web Consortium Framework de Microsoft para desarrollo de aplicaciones. Common Intermediate Language Microsoft Intermediate Language Lenguaje de programación desarrollado por Microsoft. C# Lenguaje de programación desarrollado por Microsoft ASP Framework desarrollado y comercializado por Microsoft para aplicaciones web. J# Lenguaje creado para la plataforma ASP.NET basado en Java y J++. RUP RIM Rational Unified Process Research In Motion xii

13 1 Introducción La población venezolana aumenta cada día más y la cantidad de clínicas en el país se mantiene casi constante, lo cual causa un déficit de atención médica para los pobladores y se podría decir que el mismo problema lo presentan los venezolanos en otras regiones del país. La insaciable búsqueda del mejoramiento del servicio que ofrecen las clínicas del país en pro de atender a la mayor cantidad de personas que requieran sus servicios, ha impulsado a la clínica Santa Sofía a realizar un esfuerzo por volver más eficientes sus procesos internos lo cual directa e indirectamente se ve reflejado en la calidad del servicio ofrecido. Para ello, ha evaluado y decidido incluir la tecnología de tabletas (Tablets) a su equipo de trabajo estratégicamente en áreas donde se obtiene un gran provecho de las facilidades que este dispositivo ofrece. Para ello, han decidido desarrollar aplicaciones móviles que sean ejecutadas en estas tabletas. La clínica Santa Sofía se dio cuenta que uno de los principales problemas que tienen las clínicas caraqueñas es que debido a la sobrepoblación el módulo de emergencia se encuentra gran parte del tiempo repleto de personas esperando por ser atendidas. Además, se dieron cuenta que atender a los pacientes por el orden de llegada no era la forma más segura y eficiente para los pacientes, debido a que podía llegar un paciente con una emergencia más grave que otro, pero si llegaba más tarde debía ser atendido luego del que llego antes, lo cual es peligroso para el paciente más grave ya que su vida puede correr peligro mientras espera. Por lo antes planteado, la clínica se vio en la necesidad de crear un módulo que se encargara de ordenar a los pacientes de una forma más razonable, tomando en cuenta tanto la urgencia de la emergencia del paciente como el tiempo de espera que lleva en el recinto. El objetivo general del siguiente proyecto es analizar, diseñar e implementar una solución que simplifique actualizar los servicios de orientación diagnóstica, al inicio de proyecto se llamaba triaje, y emergencia de la clínica Santa Sofía, a través de tecnología basada en tabletas. El desarrollo del proyecto se llevó a cabo utilizando la metodología RUP, adecuada a las necesidades del proyecto y utilizando las

14 herramientas que el proyecto requería de esta metodología. La fase de transición de la metodología RUP no está incluida en el proyecto debido a las limitaciones de tiempo. 2 Los objetivos específicos son listados a continuación. 1. Adquirir una visión general sobre la empresa, la tecnología y el sistema a desarrollar. 2. Evaluación y selección de tecnologías. 3. Ejecutar el análisis de la solución a implementar de acuerdo a la metodología y los artefactos seleccionados. 4. Formalizar los documentos de inicio y elaboración en los que se especifican los detalles de la solución. 5. Completar la Fase de construcción de acuerdo a la metodología RUP. 6. Documentar el proceso realizado. 7. Sujeto a las limitaciones de tiempo de la pasantía, dejar operativa la aplicación desarrollada en una tableta. Durante la pasantía se desarrollaron la gran mayoría de los casos de uso definidos para el proyecto. Los casos de uso que faltaron por desarrollar fueron debido a que la clínica no contaba con los módulos requeridos en su sistema para interactuar con las aplicaciones desarrolladas en este proyecto. El desarrollo de las aplicaciones de este proyecto forma parte del plan con el cual la clínica busca mejorar y hacer más eficientes sus procesos internos. Estas aplicaciones junto con la tableta en la cual se ejecutan, representan un puesto de trabajo ligero, portable y eficiente que ayuda a médicos y enfermeras en sus labores cotidianas dentro de la clínica. De esta manera, indirectamente se contribuye a prestar un mejor servicio al paciente de forma tal que éste se sienta bien atendido y que la clínica esté bien preparada y dotando a sus empleados de una tecnología de punta que brinda muchas facilidades.

15 3 Vale destacar, que sería el primer proyecto de este tipo a desarrollar en el país, por lo que se espera que se tengan buenos resultados usando la tecnología de tabletas y aplicaciones para que las otras clínicas puedan seguir este proyecto pionero en el país. El presente documento detalla los procesos de análisis, diseño y construcción de las aplicaciones móviles desarrolladas por Global Consultants Group para la clínica Santa Sofía. Primero se presenta la motivación del proyecto, el planteamiento del problema, el objetivo del desarrollo del proyecto de pasantía y el alcance del mismo, junto con justificación en importancia de su desarrollo. En el primer capítulo se expone el entorno empresarial; en el segundo se muestra el marco teórico y en el tercero el marco tecnológico en los cuales se muestra los conceptos necesarios para comprender el proyecto; luego en el capítulo cuarto se expone el marco metodológico en donde se encuentra todo lo referente a la metodología utilizada durante el proyecto; seguido del capítulo quinto en donde se describe todo el proceso de análisis, diseño e implementación del proyecto mostrando cada fase e iteración realizada durante el mismo; finalmente en el capítulo sexto presenta todas las conclusiones obtenidas al culminar el proyecto de pasantía y se sugieren algunas recomendaciones para futuros desarrollos.

16 Capítulo 1 4 Entorno Empresarial Este capítulo muestra una visión de la empresa en la cual se desarrolló el proyecto y bajo las condiciones que se llevó a cabo. 1.1 Descripción de la empresa Global Consultants Group (GCG) es una empresa que presta servicios de consultoría de proyectos en Tecnologías de Información y comunicaciones [1]. GCG se diferencia de otras empresas de consultoría en que ha incursionado y ha orientado sus prácticas de negocio a dos industrias particulares: telecomunicaciones y entretenimiento. En el área de entretenimiento, específicamente para los establecimientos de bingos y casinos, GCG ha desarrollado e implantado una aplicación propia que actualmente se encuentra instalada en cuatro casinos y un bingo en Venezuela. En la industria de telecomunicaciones GCG brinda servicios que abarcan soluciones como interconexión, mediación, facturación, aprovisionamiento e inteligencia de negocio, lo cual ha permitido extender sus servicios más allá de Venezuela y apoyar nuevos mercados tales como: Colombia, Curazao, España, Ecuador, República Dominicana, Perú y varios países de Centro América. Además, GCG desde el año 2008 tiene una alianza estratégica con la Clínica Santa Sofía ofreciéndole proyectos adaptados a sus necesidades y acercando la tecnología al día a día de sus empleados/socios. Su misión es servir a nuestros clientes como facilitadores en el logro de soluciones tecnológicas que les permitan cubrir sus necesidades de negocios, a través de servicios de consultoría, brindando oportunidades de desarrollo profesional y económico a nuestro personal [1].

17 5 La visión de GCG es convertirnos en aliados estratégicos de nuestros clientes, con miras a lograr el reconocimiento del mercado en la prestación de servicios de consultoría que responden a altos estándares de calidad [1]. 1.2 Estructura Organizacional de la Empresa GCG se ha enfocado en dirigir sus recursos al área clave del negocio: la consultoría de proyectos. Reciben apoyo externo u outsourcing (tercerización) en las unidades de asesoramiento legal y contaduría. La ubicación del personal de GCG no es estática en una sola área de la estructura organizacional de la empresa. Un consultor puede ocuparse de la gerencia de un proyecto mientras que forma parte del grupo de desarrolladores para otro proyecto distinto, todo dependerá de las destrezas y aptitudes que posea el empleado. En la Figura 1.1 se ilustra la estructura organizacional de GCG. 1.3 Ubicación del Pasante Durante el desarrollo del proyecto de pasantía, el pasante realizó sus actividades en el área de consultoría de proyectos, resaltada en la figura bajo el Grupo de Consultores. Figura 1.1. Estructura Organizacional de Global Consultants Group.[1]

18 Capítulo 2 6 Marco Teórico del proyecto. En este capítulo se define términos y conceptos utilizados durante este informe para la explicación 2.1. Dispositivo Móvil Un dispositivo móvil no es más que un aparato pequeño y portátil, con capacidad de procesamiento, pudieran tener una conexión permanente o intermitente a una red de datos y con memoria limitada. De acuerdo con esta definición existen multitud de dispositivos móviles, desde los reproductores de audio portátiles hasta los navegadores GPS, pasando por los teléfonos móviles, los PDAs o los Tablets. Al inicio eran desarrollados para una finalidad en específico, ya que no se contaba con la tecnología necesaria para que estos dispositivos fueran multipropósitos. Con el pasar del tiempo, se ha ido descubriendo y desarrollando la tecnología necesaria para desarrollar dispositivos móviles que no solo sea multipropósito, si no que hayan convertido en un pilar importante del día a día de la sociedad. Dado el variado número de niveles de funcionalidad asociado con dispositivos móviles, era necesario hacer una clasificación de los mismos, por ello T38 y DuPont Global Mobility Innovation Team en el año 2005 propusieron los siguientes estándares para la definición de dispositivos móviles. Dispositivo Móvil de Datos Limitados (Limited Data Mobile Device): teléfonos móviles clásicos. Se caracterizan por tener una pantalla pequeña de tipo texto. Ofrecen servicios de datos generalmente limitados a SMS y acceso WAP. Como ejemplo de este tipo podemos hablar de teléfonos genéricos que ofrecen servicios de llamada y mensajes de texto. Dispositivo Móvil de Datos Básicos (Basic Data Mobile Device): se caracterizan por tener una pantalla de mediano tamaño, menú o navegación basada en iconos y ofrecer acceso a s, lista de

19 7 direcciones, SMS, y en algunos casos un navegador web básico. Un típico ejemplo de este tipo de dispositivos son los teléfonos básicos. Dispositivo Móvil de Datos Mejorados (Enhanced Data Mobile Device): se caracterizan por tener pantallas de medianas a grandes (por encima de los 240 x 120 pixels) y que ofrecen las mismas características que el "Dispositivo Móvil de Datos Básicos" (Basic Data Mobile Devices) más aplicaciones nativas como aplicaciones de Microsoft Office Mobile (Word, Excel, PowerPoint), aplicaciones corporativas usuales, en versión móvil, como Sap, portales intranet, etc. Este tipo de dispositivos incluyen los S.O. como Windows Mobile, Android, Symbian, ios, entre otros. Además, ofrece una serie de aplicaciones que cualquier desarrollador del área podría realizar. Un ejemplo de esta categoría son los teléfonos inteligentes (smartphones), las tablets y PDA Tableta (Tablets) Es un dispositivo móvil portátil, con un tamaño estándar de pantalla entre 7 y 11 aproximadamente. Posee una pantalla táctil con la que el usuario interactúa con el dispositivo. Esta interacción podría ser con una pluma o con el dedo del usuario, dependiendo del tipo de tableta. No requiere ni un mouse ni un teclado físico, ya que toda la interacción con el dispositivo se basa principalmente en la comunicación mediante la pantalla. La pantalla ofrece un teclado estándar cuando el usuario lo requiera para escribir algún tipo de información. Algunas tabletas ofrecen la opción de conectarse a un teclado físico y/o mouse mediante bluetooth, cable USB o algún otro medio de comunicación. El primer dispositivo lanzado por alguna empresa para su venta fue el Microsoft Tablet PC lanzado en el año 2000 por la empresa Microsoft [2]. No logró mucho éxito en ese momento en el mercado en general, si no en nichos específicos (clínicas, depósitos, empresas de envió, entre otros). En el año 2010, la empresa Apple Inc. lanza al mercado su primera versión del dispositivo ipad, tableta que revoluciona este mercado y consigue la atención del público en general. Hoy en día, son muchas las empresas que se dedican a desarrollar tabletas y ofrecen una gran variedad de tamaños, modelos y características. En cuanto al sistema operativo, se cuentan con dos

20 8 grandes sistemas fuertes en el mercado: el ios desarrollado por Apple y Android, desarrollado por Android Inc. empresa que forma parte del grupo de Google Inc. En la actualidad es un mercado que produce gran cantidad de ganancias económicas en el mercado, por lo que existe una gran competencia, y evolución que esta desencadena, de las tabletas Arquitectura Cliente-Servidor Es un modelo de aplicación distribuida en el cual se cuenta con uno o varios servidores que atienden y ofrecen servicios o recursos a uno o varios clientes. En el concepto principal de este modelo el cliente realiza una petición al servidor, y éste le envía una respuesta a su petición. Este modelo provee la facilidad de que el cliente y el servidor puedan estar en diferentes maquinas, desarrollados en diferentes lenguajes y, de ser el caso, ejecutándose en distintas plataformas, lo cual permite la comunicación entre dos procesos distribuidos en distintos dispositivos. Bajo este concepto, el cliente y el servidor se distribuyen la capacidad de procesamiento, dependiendo de las necesidades de cada implementación, buscando sacarle el mayor provecho al modelo. Existen varias implementaciones de esta arquitectura que son frecuentemente utilizadas, entre ellas se puede nombrar: servidores de correo, servidores web, servidores de archivos, servidores de música, servidores de videos, bases de datos. Entre las características principales de un modelo cliente-servidor se pueden mencionar: El cliente es quien inicia las solicitudes al servidor, por lo que tiene una actitud activa en la comunicación. El servidor espera las peticiones que algún cliente pueda hacerle, por lo que tiene una actitud pasiva. El servidor al recibir una petición, la procesa y envía una respuesta al cliente. El cliente espera y recibe respuestas del servidor. Por lo general, el servidor permite conexiones de varios clientes simultáneamente. El cliente puede realizar conexiones con distintos servidores simultáneamente. Generalmente, si el servidor es privado, solicita algunos datos para el reconocimiento del usuario y posteriormente procesar sus solicitudes.

21 9 El cliente generalmente es quien interactúa con el usuario final, mientras que el servidor generalmente no interactúa con el usuario final, si no que interactúa con el cliente. El estado normal de un servidor es esperar alguna conexión de un cliente Arquitectura Tres Capas. Es un patrón de programación que tiene como objetivo principal la separación de la capa de presentación, capa de negocio y capa de datos. La principal ventaja de este modelo de programación es que se ejecuta el desarrollo en varios niveles, lo cual puede ser un modelo muy tolerante a modificaciones, debido a que se puede modificar cada una de las capas internamente sin que esto implique directamente modificar alguna otra capa. Además, permite distribuir el desarrollo de un proyecto en distintos niveles de forma tal que cada nivel esta abstraído totalmente de los otros niveles existente. Basta con conocer el conjunto de funciones, procedimientos o métodos que ofrece cada capa. Este último concepto es comúnmente conocido como API, por sus siglas en inglés Application Programming Interface. Capa de presentación: Esta capa es la que el usuario visualiza, presenta la parte grafica al usuario, le comunica la información y captura la información que éste desea ingresar al sistema. Esta capa se comunica únicamente con la capa de negocio y debe tener la característica de ser amigable a la vista del usuario. Capa lógica: Es denominada capa de negocio o capa lógica, su función principal es recibir las peticiones del usuario y enviar a la capa de presentación las respuestas a estas peticiones. Esta capa es la que se encarga de generar el enlace entre la capa de datos y la capa de presentación para que finalmente el usuario logre visualizar la información necesaria. Capa de datos: En esta capa es donde residen los datos de la aplicación y es la delegada de manejar estos datos. Generalmente está formada por uno o varios gestores de bases de datos que realizan el ingreso, almacenamiento, borrado y recuperación de la información desde la capa lógica.

22 Arquitectura de sistemas operativos móviles Los sistemas operativos móviles se caracterizan por tener una arquitectura divida en capas, las cuales cumplen cierta función específica y ofrecen servicios a las capas superiores. En la figura 2.1 se muestra la arquitectura del sistema operativo de Android, en donde se puede ver claramente como este sistema operativo fue desarrollado bajo un modelo de capas y la función de cada una. La capa más baja del sistema es la encargada de manejar los drivers del hardware del dispositivo y ofrecer las funciones que ofrece cada uno de estos a la capa superior. En la segunda capa se encuentran una serie de librerías que ofrece el sistema operativo a los desarrolladores junto con la maquina virtual de Android. La tercera es la capa encargada del manejo y prestarles servicios a las aplicaciones. La última es la capa donde se ejecutan las aplicaciones como tal. Figura 2.1. Arquitectura del sistema operativo Android [3]. Otro ejemplo de esta arquitectura en capas, es la arquitectura del ios, descrita en la figura 2.2 en donde se aprecia el modelo seguido por los desarrolladores de este sistema operativo propietario de Apple Inc. Se puede ver que la capa inferior es la encargada de manejar los drivers del hardware del dispositivo

23 y donde se encuentra el núcleo del sistema operativo. En la siguiente capa se encuentran las librerías que el sistema operativo ofrece a las aplicaciones. 11 Figura 2.2. Arquitectura del sistema operativo ios [4] Arquitectura aplicaciones móviles Las aplicaciones móviles son desarrolladas generalmente usando la arquitectura de tres capas descrita anteriormente. Se crea una capa de presentación que es con la que el usuario interactúa, de las distintas formas que tiene el usuario de interactuar con un dispositivo móvil (tocando la pantalla, moviendo el dispositivo, teclado físico conectado de alguna forma al dispositivo móvil, entre otras) y ésta se encarga de enviar la información a la capa lógica. Esta capa procesa la información y dependiendo del caso podría hacer uso de una capa de datos o no. Existen aplicaciones móviles que no poseen la capa de datos, ya que no la necesitan. También hay otro tipo de aplicaciones (dependiendo de las necesidades de esta) que la capa de datos es suplantada por una capa que funciona como un cliente de la arquitectura cliente-servidor descrita anteriormente. De esta forma, la capa de datos realmente se encuentra en un servidor y no en la aplicación como tal, lo cual es indiferente para las capas superiores.

24 Capítulo 3 12 Marco Tecnológico En este capítulo serán definidos algunos términos, conceptos y tecnologías que son necesarios para la comprensión del proyecto. Estas tecnologías son: El formato JSON, protocolo SOAP, el sistema operativo Android, el kit de desarrollo de Android, el IDE Microsoft Visual Studio 2008 y Microsoft SQL Server Para cada concepto se plantea la justificación para su uso en el proyecto Formato JSON JSON es un formato ligero para el intercambio de datos, basado en un subconjunto de la notación utilizada en JavaScript [5]. Es una notación fácil de analizar sintácticamente ( parsear ) para una computadora y amigable/entendible para la lectura de un humano. Es un protocolo bastante utilizado en estos momentos por las facilidades que brinda, como ejemplo se tiene el uso de esta tecnología por Google, Yahoo, entre otras empresas reconocidas [5]. Este formato tiene sus inicios en el Fue utilizado en el proyecto para la serialización/deserialización de información entre la base de datos manejada por el servicio web instalado en el servidor y la aplicación para el dispositivo inteligente Android. Android es el sistema operativo en el que se implementó la parte del dispositivo móvil o tableta del proyecto, más adelante se explica detalladamente porque se eligió. Este protocolo se amolda fácilmente a las necesidades que tenía este proyecto para la comunicación, además, tanto en Android como en C# existen librerías que se encargan de serializar/deserializar los objetos a formato JSON. C# es un lenguaje de programación en el que se desarrolló el módulo del servicio web del proyecto

25 Protocolo SOAP SOAP (siglas de Simple Object Access Protocol) es un protocolo para comunicación entre procesos, permitiendo el intercambio de objetos en un formato derivado del XML. SOAP fue creado por Microsoft, IBM y otros y está actualmente bajo el auspicio de la W3C. Es uno de los protocolos más utilizados en los servicios web [6]. En este proyecto, se utilizó para llevar a cabo la comunicación entre el servicio web y la aplicación en Android. La aplicación en Android envía una consulta bajo el protocolo SOAP al servicio web y éste responde bajo el mismo protocolo con la información requerida por la aplicación serializada en formato SOAP. Con esta información disponible en la aplicación lo que resta es deserializarla e interpretarla según sea el caso Android Android es un sistema operativo para dispositivos móviles como celulares o tabletas. El proyecto Android fue iniciado por un grupo de desarrolladores en 2003 el cual fue posteriormente adquirido por Google en 2005 y anunciado al público en el 2007 [7]. El sistema consiste en un kernel basado en el kernel de Linux, con librerías, Interfaz de programación de aplicaciones API (por sus siglas en inglés, Aplication Programmation Interface) y middleware (software que ayuda a que un software se comunique con otros) escrito en C y aplicaciones que se ejecutan usando un framework (marco de trabajo) compatible con Java. Dichas aplicaciones son ejecutadas por una máquina virtual conocida como Dalvik Machine la cual trasforma los archivo.class de java en archivos.dex, los cuales están diseñados para optimizar la ejecución de esas aplicaciones en dispositivos con bajo procesador y memoria. El sistema operativo Android es Software Libre bajo la licencia de Apache [3]. Entre las principales características que posee el sistema operativo Android se encuentran: multitáreas, multigestos, multilenguaje, soporte para Java, streaming, audio y video, conectividad con internet y múltiples redes celulares, Bluetooth, soporte para distintos hardware como sistemas de

26 14 posicionamiento global GPS (por sus siglas en inglés, Global Positioning System), sensores de movimiento, entre otros [8]. Además uno de los principales puntos fuertes de Android es su Mercado de Aplicaciones en el que se encuentran cientos de miles de aplicaciones para descargar que amplían la utilidad de los dispositivos que cuentan con este sistema operativo [9]. Este sistema operativo fue el seleccionado para utilizar en esta pasantía, luego de un estudio detallado realizado durante el proyecto, el cual nos llevó a la conclusión de que los dispositivos móviles con Android son los que mejores se adaptan a las necesidades del cliente (CSS). Los otros sistemas operativos estudiados fueron: Blackberry OS: es el sistema operativo desarrollo por RIM (por sus siglas en inglés, Research In Motion) para la tableta de ésta empresa que lleva por nombre Blackberry Playbook. La principal desventaja de este sistema es su carácter privativo y su especificidad para las tabletas de la empresa RIM, por lo que si se quiere cambiar de Tablet a otra producida por otro fabricante, se tendría que desarrollar la aplicación bajo otro sistema operativo. ios: es el sistema operativo desarrollado por Apple para su línea de iphone, ipod Touch y ipad. Es un sistema operativo privativo que solo puede ser instalado en hardware desarrollado por Apple, no permite ser instalado en otros dispositivos. Este es uno de los principales problemas de este sistema, al desarrollar la aplicación para ser ejecutada en ios, se limita a que el hardware comprado sea de Apple. Siendo esto un hardware bastante costoso para el uso que le piensa dar el cliente. Otra limitante de este sistema operativo, es que solo se puede desarrollar aplicaciones para éste si se cuenta con una computadora desarrollada por Apple. Finalmente, se enumeran a continuación las principales razones por las que se escogió Android como el sistema operativo en el que se desarrolló el proyecto.

27 1. Es un sistema operativo de código abierto, por lo que puede ser modificado y adaptado para ser instalado en cualquier Tablet Es el más usado en las Tablet del mercado. 3. Es usado en dispositivos que tienen todo tipo de costo, desde los más costosos hasta los más económicos Kit de Desarrollo de Android Un kit de desarrollo de Software SDK (por sus siglas en ingles Software Development Kit) es un conjunto de herramientas que permiten crear software para una cierta plataforma o con un cierto objetivo. Puede ser un framework (marco de trabajo), un conjunto de librerías o una serie de controladores que permitan realizar software de forma más efectiva y eficiente [10]. Existe Android SDK el cual contiene una implementación de las librerías más básicas de Java en conjunto con aquellas que provean facilidades para el desarrollo de programas en tecnología móvil. Además provee librerías desarrolladas especialmente para dispositivos con la plataforma Android, framework para ejecutar y manejar las aplicaciones en esta plataforma, conectividad con el dispositivo y con la base de datos, además de una serie de funciones y clases optimizadas para el ambiente móvil. Actualmente el SDK de Android se encuentra en su versión 15, la cual permite el desarrollo de aplicaciones para su más reciente sistema operativo conocido como Ice Cream Sandwich que corresponde a la versión 4 [10]. Este SDK provee facilidades para realizar la depuración de sus aplicaciones la cual se encuentra integrada con el software de desarrollo Eclipse Microsoft Visual Studio 2008 Es un entorno de desarrollo integrado IDE (por sus siglas en inglés, Integrated Development Environment) lanzado al mercado por Microsoft inicialmente en 1998 [11]. En el año 2002 se produjo un

28 16 cambio sustancial, ya que en esta actualización presumió la introducción de la plataforma.net de Microsoft. Ésta es una plataforma de ejecución intermedia multilenguaje, de forma que los programas desarrollados en.net no se compilan en lenguaje máquina, sino en un lenguaje intermedio (CIL, por sus siglas en inglés Common Intermediate Language) denominado Microsoft Intermediate Language (MSIL, por sus siglas en inglés) [11]. En una aplicación MSIL, el código no se convierte a lenguaje máquina hasta que ésta se ejecuta, de manera que el código puede ser independiente de plataforma (al menos de las soportadas actualmente por.net) [11]. En el año 2003 ocurrió la actualización del IDE en donde se agregan los siguientes cambios: el framework.net se actualiza a la versión 1.1, se incluyen mejoras en el compilador de C++, se añade soporte para escribir aplicaciones para algunos dispositivos móviles, entre otros [11]. A partir de Octubre 2005, se empieza a comercializar este producto a través de internet. Luego tiene dos actualizaciones más (año 2008 y 2010) en donde se agregan más facilidades al programador [11]. En estos momentos el mayor uso que recibe este IDE es la implementación de proyectos básicamente enfocados en entornos web, además ofrece para programar en varios lenguajes, entre ellos: C#, C++, ASP.NET, J# y Visual Basic. Visual Studio permite a los desarrolladores crear sitios web, aplicaciones web y servicios web, entre otras cosas. La idea es crear programas que estén a la vanguardia de la tecnología, permitiendo que en este entorno se puedan desarrollar programas que sean vistos desde el monitor de un computador hasta aplicaciones móviles que se comunican con un servicio web. Esta herramienta fue utilizada en el proyecto para el desarrollo de los servicios web que requieren ambas aplicaciones para la comunicación con la base de datos en el servidor. Además fue un requisito del cliente que la aplicación de servicio web fuese desarrollada en este ambiente Microsoft SQL Server 2008 SQL Server es un manejador de bases de datos basado en el modelo relacional desarrollado por Microsoft. Su primera versión fue sacada al mercado en 1989, y lleva doce versiones distintas desde el año anterior mencionado hasta el Esta última es la versión 11.0 [12].

29 17 Este manejador de bases de datos es de los más usados por programadores y desarrolladores en el ambiente de Microsoft Windows [12]. Está desarrollado para ser ejecutado solamente en el sistema operativo Windows. La escogencia de este manejador se debió a un requerimiento del cliente, la Clínica Santa Sofía. Éste es el ambiente instalado en el servidor del cliente para ejecutar la base de datos.

30 Capítulo 4 18 Marco Metodológico El presente capítulo tiene como objetivo dar a conocer los aspectos metodológicos en los que se basó la ejecución del proyecto de pasantía. A continuación se explicará en detalle la metodología de desarrollo de Software propuesta por Rational (RUP, por sus siglas en inglés, Rational Unified Process), la cual se define como un proceso iterativo de desarrollo de Software que no consta de pasos firmemente establecidos sino que por el contrario, se adapta al contexto y necesidades de cada organización Características y Estructura de RUP RUP es un proceso de desarrollo de software que define una metodología bastante moldeable para el análisis, implementación y documentación de proyecto en el área de computación [13]. Posee tres características esenciales las cuales son mencionadas a continuación: Es una metodología enfocada hacia los Casos de Uso, en base a éstos se crean los modelos de análisis, diseño, implementación y pruebas necesarias. Está centrado en la arquitectura: puesto que ella es la guía en la construcción del sistema y dictamina el orden, además su definición debe tomar en consideración elementos de calidad: rendimiento, reutilización, capacidad de evolución por lo que debe ser flexible durante todo el desarrollo. Es iterativo e incremental. RUP consta de dos dimensiones (Figura 4.1), a saber: Dimensión Estática: describe el proceso en términos de componentes de proceso, disciplinas, flujos de trabajo, actividades, artefactos y roles de la metodología.

31 19 Dimensión Dinámica: representa el tiempo e indica las características del ciclo de vida del proceso expresado en términos de fases, iteraciones e hitos. Consta de cuatro (4) fases: Inicio, Elaboración, Construcción y Transición. Figura 4.1: Diagrama del ciclo de vida de RUP [13]. La Figura 4.1 presenta gráficamente la estructura de la metodología. El eje vertical está representado por la dimensión estática y el horizontal por la dimensión dinámica Fases de RUP RUP se conforma a través de ciclos los cuales constituyen la vida de un producto. Cada ciclo está representado por cuatro fases: Inicio, Elaboración, Construcción y Transición las cuales se detallarán brevemente a continuación. Cada fase presenta sus propios criterios de evaluación, los cuales deben ser revisados inmediatamente después de su finalización. Si los criterios no son satisfechos se debe abandonar el desarrollo o realizar una reestructuración del proyecto.

32 Fase de Inicio Es la primera fase del proceso de desarrollo. En ella se definen el modelo del negocio y el alcance del proyecto. Otros objetivos de esta fase son: primero, establecer los Casos de Uso críticos del sistema que definirán su funcionalidad; segundo, mostrar una arquitectura candidata para los escenarios principales; tercero, estimar el costo en recursos y tiempo de desarrollo de todo el proyecto; cuarto, determinar y estimar los riesgos que conllevará el proceso; quinto, producir la primera versión del Documento de Visión, que incluya una visión general de los requerimientos del proyecto, sus características claves y principales restricciones, así como también un glosario inicial y el Documento de Caso del Negocio. Los criterios de evaluación en esta fase están representados por: coincidencias entre las definiciones y estimaciones del proyecto por parte del equipo de trabajo, el correcto entendimiento de los requerimientos, las credibilidad y aceptación de las estimaciones de costo, tiempo y riesgos, y por último el total entendimiento del proyecto Fase de Elaboración Su propósito es analizar el dominio del problema y definir la arquitectura base del proyecto. Entre sus objetivos se encuentran: primero, definir y validar la arquitectura base, y demostrar que la misma es capaz de soportar y satisfacer los requerimientos del sistema; segundo, completar el Documento de Visión; tercero, culminar la elaboración del Modelo de Casos de Uso del sistema; cuarto, abarcar todo el proyecto a una profundidad mínima; quinto, establecer y probar el ambiente de desarrollo que soportará el proyecto; sexto, definir los requerimientos que se implementarán en la primera iteración de la Fase de Construcción y realizar un plan de desarrollo. Los criterios de evaluación en esta fase son: la arquitectura y visión del producto son estables, el plan de desarrollo es detallado y las estimaciones son factibles, los principales elementos de riesgos han sido abordados y controlados con la primera prueba del ambiente de desarrollo.

33 Fase de Construcción Su objetivo principal es alcanzar la capacidad funcional del sistema de forma incremental, a través de iteraciones y refinamientos sucesivos. Otros objetivos contemplados en esta fase son: primero, minimizar los costos de desarrollo optimizando los recursos; segundo, lograr la calidad esperada de forma rápida y práctica; tercero, implementar versiones funcionales tan pronto como sea posible; cuarto, completar el análisis, diseño y desarrollo de las funcionalidades planificadas; quinto, desarrollar de forma iterativa e incremental un producto que cumpla con los requerimientos y las expectativas planteadas al inicio. Los criterios de evaluación son: la finalización de la funcionalidad del sistema y la consecución de un nivel mínimo de pruebas Fase de Transición Es la última fase del proceso de desarrollo y tiene como principal función la de poner el producto en manos de los usuarios finales. Entre los objetivos de esta fase se pueden mencionar: primero, realizar pruebas de aceptación al producto final; segundo, entregar un prototipo totalmente funcional; tercero, ofrecer una descripción de la arquitectura completa y corregida; cuarto, entrenar a los usuarios finales y a los encargados del mantenimiento; quinto, obtener la mayor satisfacción posible de parte del cliente. En este punto del desarrollo el criterio de evaluación es el grado de satisfacción que presenta el cliente. Es ahora cuando corresponde decidir si se debe iniciar un nuevo ciclo de desarrollo.

34 Capítulo 5 22 Desarrollo del sistema El presente capítulo describe en detalle el proceso de desarrollo del proyecto de pasantía. El mismo está dividido en secciones las cuales corresponden a cada una de las fases de inicio, elaboración y construcción de RUP contempladas durante el proceso de desarrollo Fase de Inicio Esta fase estuvo caracterizada por las actividades de investigación orientadas a la selección objetiva de la herramienta adecuada para la programación del proyecto. Se realizaron las pruebas básicas sobre las herramientas seleccionada para garantizar su correcta integración con las demás herramientas que conformaban el ambiente de desarrollo del proyecto. Las actividades más importantes realizadas en esta etapa se enumeran a continuación: 1. Inducción al caso de estudio. 2. Primer estudio de las tecnologías de tabletas a evaluar en el proyecto de pasantía. 3. Se estableció una primera versión del documento de visión y límites del proyecto, a muy grandes rasgos. 4. Se investigó sobre distintas metodologías que pudiesen ayudar en el proceso de seleccionar la tableta. 5. Se propuso una metodología (propia) para seleccionar la tableta. 6. Se discutieron y seleccionaron los parámetros en base a los cuales realizar la metodología de selección. 7. Se dieron como propuesta, discutieron y eligieron los pesos de los parámetros escogidos en la metodología de selección.

35 23 8. Se ejecutó la metodología de selección, en la que se evaluaron, en base a los parámetros y pesos seleccionados, dos tecnologías distintas de tabletas, procurando determinar la tableta que mejor se adecuará a las necesidades del proyecto Visión del Sistema La visión del sistema está representada en el Documento de Visión (Apéndice B). El propósito de este documento es recopilar, analizar y definir las características y necesidades de alto nivel del sistema. El Sistema de Control de pacientes activos en cada unidad es un elemento esencial en el manejo de cada módulo, ya que es la columna vertebral de la aplicación. Mostrar los pacientes que se encuentran activos y poder acceder a sus respectivos casos para registrar la información relevante en cada proceso es un tema importante y en base a él se diseñan ambas aplicaciones. Actualmente el Módulo de Orientación Diagnóstica es nuevo, por lo que las principales decisiones de diseño fueron acordadas con el cliente, pudiendo de esta manera ofrecer otro punto de vista y algunas recomendaciones. Sin embargo, para el Módulo de Emergencia, ya se encuentra operativo un flujo de procesos y una aplicación para escritorios, por lo que simplemente en ese caso tuvimos que apegarnos a las decisiones, flujo y diseño de esta aplicación. Nos enfocamos en llevar las funciones principales de la aplicación para escritorios a nuestra aplicación para tableta. Este proyecto está orientado a brindar las facilidades que la tecnología de tableta ofrece a este ámbito médico. Entre las capacidades que se espera que sean explotadas por los médicos y que la tecnología de tabletas ofrece, se resalta la movilidad que representa poder registrar la información del caso en una tableta, una herramienta de siete pulgadas portable en lugar de tener que ir a la estación de trabajo para hacerlo. Se agiliza el proceso, ya que el médico mientras consulta, evalúa y diagnostica los casos, va registrando directamente en el sistema de la clínica mediante la tableta Riesgos La lista de riesgos, detallada en el documento de riesgos (Apéndice F), tiene como propósito recopilar, analizar y enumerar los riesgos que se pueden presentar en el desarrollo del proyecto. La tabla 5.1 muestra un resumen de la lista de riesgos presentada en el documento de riesgos.

36 Stakeholders (Partes Interesadas) Se consideran stakeholders a todos los individuos involucrados, directa o indirectamente, en el desarrollo, diseño e implementación de la solución. La Tabla 5.2 describe brevemente los stakeholders identificados en el proyecto Usuarios En la tabla 5.3 se describen los distintos perfiles de usuarios junto con sus respectivas responsabilidades Herramientas de Desarrollo A continuación se presenta un listado de herramientas de Software utilizadas en el desarrollo de la pasantía. Estas herramientas fueron descritas en el capítulo del marco tecnológico. Visual Studio 2008: Utilizado para la implementación de los servicios webs requeridos para cada módulo. Fueron desarrollados en este IDE bajo el lenguaje de C#. SQL Server 2005: Empleado para el manejo de las bases de datos de cada módulo. Microsoft Visio 2010: Herramienta utilizada para el desarrollo de los respectivos Diagramas de Casos de Uso de cada aplicación. ERWin: Herramienta utilizada para el desarrollo del modelo relacional propuesto al cliente para la base de datos del módulo de Orientación Diagnóstica. Eclipse: IDE para el desarrollo de las aplicaciones en Android. A éste IDE es al que se le instala el Kit de Desarrollo en Android002E Infraestructura de Desarrollo En esta sección se darán las especificaciones técnicas del Hardware y del Software que se utilizó para desarrollar el proyecto.

37 Hardware: Para el desarrollo del sistema se utilizó como estación de trabajo una computadora portátil marca Lenovo, con acceso a Internet y las siguientes características: 250 GB de disco duro. 2 GB de memoria RAM. Procesador Intel Core 2 Duo de 1,80 GHz. Sistema Operativo Windows Software: continuación. El software que se utilizó durante el período de pasantía para desarrollar el proyecto se lista a Lenguaje de Programación y Tecnología: Visual C#.NET, ASP.NET,.NET Framework3.5 y Java. Servidores: IIS en su versión 6.0, usado para ejecutar el servicio web. Manejador de Base de Datos: SQL Server Documentación: Microsoft Office Fase de Elaboración Siguiendo las indicaciones de la Metodología por la cual se llevó a cabo el proyecto, en esta fase se definieron los Casos de Uso a ser implementados en la fase de construcción tanto para el Módulo de Orientación Diagnóstica como para el Módulo de Emergencia mediante la creación del Modelo de Casos de Uso del sistema. Los casos de uso y flujos de procesos definidos en el proyecto fueron realizados en base a información recabada en reuniones que se sostuvieron con el área de tecnología del cliente. En el Documento de Arquitectura (Apéndice G) que se realizó en esta fase puede obtenerse más detalles sobre los casos de uso Planificación de la Fase Las actividades más importantes realizadas en la fase de Elaboración se enumeran a continuación:

38 26 1. Creación, refinamiento y validación con la CSS el Documento de Requerimientos. 2. Creación, refinamiento y validación con la CSS el Documento de Casos de Uso. 3. Creación, análisis, refinamiento y validación con la CSS del Diagrama de Casos de Uso. 4. Creación de Documento de Arquitectura. 5. Análisis y Creación de Documento de Riesgos del proyecto, donde se plantea las estrategias de mitigación para cada riesgo. 6. Creación de la versión definitiva del Documento de Visión. 7. Propuesta a la CSS de Diagrama Entidad Relacional de base de datos del Módulo de Orientación Diagnóstica Arquitectura del Sistema Para el desarrollo de la arquitectura, la metodología RUP se basa en el Modelo de las 4+1 Vistas propuesto por Philippe Kruchten [14] mediante el cual se propone describir la arquitectura del Software basado en cuatro vistas principales y una última vista en la que convergen las anteriores. Las vistas propuestas en este modelo son: Vista Lógica: describe los conceptos involucrados y sus relaciones a través del Modelo Conceptual y describe la descomposición del sistema en capas y componentes a través de diagramas de componentes y diagramas de paquetes. Vista de Implementación: describe la organización estática del software en su ambiente de desarrollo. Vista de Procesos: describe los aspectos de concurrencia y sincronización del diseño. Vista de Despliegue: muestra la distribución física del sistema a través de diagramas de despliegue, representando los nodos principales del mismo. Vista de Casos de Uso: es la vista por la que se trazan las demás, en ella se describen los actores del sistema, bajo una estructura jerárquica y las funcionalidades más representativas del sistema a través de los diagramas de Casos de Uso. Para el caso particular del desarrollo de este proyecto no se tomaron en cuenta la vista de despliegue ni la vista lógica. Esto fue debido a que el proyecto solo contempla la creación de un prototipo

39 que no incluye la fase de transición. La vista lógica no fue necesaria ni tomada en cuenta en el desarrollo del proyecto Vista de Implementación A continuación se explica la implementación del proyecto dividida en dos partes, una vista a nivel de aplicación móvil y otra a nivel del servicio web A nivel de aplicación móvil El sistema se desarrolló en tres capas: la capa de control, la capa de vista y la capa de comunicación. En la figura 5.1. se puede ver una explicación gráfica del uso de las capas en el proyecto. La capa de control se encarga de manejar el comportamiento de la aplicación, haciendo uso de las funciones que facilita la capa de comunicación y la capa de vista. La capa de vista se encarga de mostrarle al usuario la información. El cuerpo de las ventanas es definido en un archivo XML. La capa de comunicación se encarga de: Serializar la información a enviar al servicio web. La información es serializada en formato JSON. Enviar la información al servicio web. Para la comunicación con el servicio web se utiliza el protocolo SOAP. Recibir información del servicio web. Para la comunicación con el servicio web se utiliza el protocolo SOAP. Facilitar métodos y funciones que serán utilizados por la capa de control según necesite. Esta capa utiliza una librería llamada ksoap2-android v.2.5.7, que se encarga de serializar, deserializar enviar y recibir la información al servicio web. Para el desarrollo de la aplicación en el sistema operativo Android se utiliza el SDK Eclipse Indigo v3.7.1, Android SDK y Android Development Tools ADT plug-in.

40 A nivel de servicio web La aplicación que se encarga de prestar el servicio web, se implementó en Microsoft Visual Studio 2008 utilizando C#. Fue realizada bajo un modelo de tres capas: una capa de datos, una capa de control o gestión de servicios y una capa de prestación de servicios o comunicación. En la figura 5.2 se muestra de forma gráfica las distintas capas. En la capa de datos se encuentra toda lo referente a consultas, inserciones y comunicación con la base de datos. Esta capa se implementó en Microsoft SQL Server APLICACIÓN NATIVA Vista Control Objetos Comunicación Serialización Servicio Web Archivo XML Estructura de control Comunicación Manejo de Sesión Deserialización Figura 5.1. Arquitectura de la aplicación nativa de Android Fuente: Realización Propia. En la capa de control o gestión de servicios se encuentra todo lo referente al manejo de la información. Se encarga de manejar las solicitudes recibidas mediante la capa de comunicación. Realiza las rutinas y funciones necesarias para procesarlas y luego mediante la capa de comunicación les envía una respuesta.

41 29 En la capa de prestación de servicios o comunicación se encuentra todo lo referente al intercambio de información entre la aplicación móvil y las demás capas de ésta aplicación, así como el serializado de la información bajo el formato JSON y recibir los parámetros enviados por la aplicación Vista de Datos En las siguientes figuras 5.3 y 5.4 se muestra el Diagrama Entidad Relación y el Diagrama Relacional de la Base de Datos respectivamente, pertenecientes al módulo de Orientación Diagnóstica. Para más detalles, revisar el apéndice G. APLICACIÓN SERVICIO WEB APLICACIÓN NATIVA Servicio Serialización Control Objetos Datos SQL Estructura de Control Comunicación HTTP Manejo de Sesión Figura 5.2. Arquitectura de la aplicación en el servidor Vista de Casos de Uso Esta sección se divide en dos partes, en una se muestra los actores presente en cada aplicación y en la otra se muestra el diagrama de casos de uso de cada módulo Actores El único actor de la aplicación del área de Emergencia es el médico especialista de emergencia, el cual se encarga de atender y evaluar el estado de los pacientes que llegan al área de emergencia. De ser necesario, si el paciente requiere los servicios de algún médico especializado, el médico especialista de emergencia se encarga de contactar a dicho médico.

42 30 Los actores de la aplicación del área de Orientación diagnóstica son: 1. Médico especialista de orientación diagnóstica: Es el actor principal del módulo. Se encarga de atender al paciente y evaluar su condición. Debe registrar la información recabada y asignarle una prioridad y un destino. 2. Enfermera de orientación diagnóstica: Se encarga de atender al paciente mientras el médico se encuentra ocupado. Los actores nombrados anteriormente son los encargados de utilizar, manejar y poner en funcionamiento la aplicación, cada uno desde un punto de vista distinto y con responsabilidades bien definidas Descripción de Caso de Uso A continuación se muestra en la figura 5.3 el diagrama de casos de uso de la aplicación del Módulo de Emergencia. En ella se puede ver todos los casos de uso que se definieron para el proyecto. CUGS0 Iniciar sesión: Este caso de uso se encarga de manejar la sesión del usuario. Lo primero que el usuario debe hacer al entrar a la aplicación es iniciar sesión. CUGS1 Cambiar clave: Este caso de uso se encarga de ofrecerle al usuario la opción de cambiar su clave. CUGS2 Cerrar sesión: permite al usuario cerrar la sesión luego de haber finalizado su interacción con la aplicación. CUME0 Listar casos en historia médica: Este caso de uso se refiere a listar todos los pacientes que

43 31 Figura 5.3. Diagrama de Casos de Uso de Médico Especialista de Emergencia. se encuentran activos en el área de emergencias a tiempo real. CUME1 Información del paciente: Permite mostrar la información detallada del paciente junto con la información que se lleva registrada del caso. CUME2 Registrar información del paciente: Permite al usuario registrar información que va surgiendo del caso del paciente. CUME3 Solicitar examen: este caso de uso ofrece al usuario solicitar a otro módulo de la clínica, algún examen que sea necesario hacerle al paciente para una mejor evaluación. CUME4 Solicitar medicamento: Los medicamentos que algún paciente requiera, pueden ser solicitados al módulo de la clínica respectivo para que sean trasladados y aplicados al paciente. CUME5 Solicitar Material Médico Quirúrgico (MMQ): El caso que requiera MMQ para realizar alguna acción, el usuario puede solicitar este material al área de la clínica indicada. CUME6 Colocar historia definitiva: Esto ocurre cuando un paciente es dado de alta de módulo de emergencia y se ha colocado toda la información referente al caso asociado. Esto indica al sistema que el caso no puede ser modificado. CUME7 Deshacer colocar historia definitiva: permite cambiar el estado de un caso marcado como definitivo a activo lo cual permite que sea modificado nuevamente.

44 32 A continuación se muestran en las figuras 5.4 y 5.5 los diagramas de casos de uso para los usuarios médicos y enfermeras respectivamente, de la aplicación del Módulo de Orientación Diagnóstica. En cada diagrama se ve los casos de uso del proyecto para cada usuario. Figura 5.4. Diagrama de Casos de Uso de Médico Especialista de Orientación Diagnóstica. Figura 5.5. Diagrama de Casos de Uso de Enfermera de Orientación Diagnóstica.

45 33 CUODG0 Registrar datos del paciente: Este caso de uso permite al usuario registrar los datos de un paciente que va a ingresar al módulo. CUODG1 Listar pacientes: Esta opción permite al usuario listar todos los pacientes activos en el módulo de orientación diagnóstica. CUODG2 Ver lista de signos vitales: A los pacientes en este módulo, se les debe registrar cada cierto tiempo los signos vitales. El usuario puede en cualquier momento que el caso esté activo, listar y observar todas las tomas realizadas a un paciente y sus respectivos resultados. CUODG3 Registrar nueva toma de signos vitales: Este caso de uso permite al usuario registrar una nueva toma de signos vitales a un paciente. CUODG4 Ver información del paciente: Este caso de uso trata de mostrar al usuario la información registrada en el sistema de un paciente junto con los datos registrados de su caso actual. CUMOD0, CUMOD 1 y CUMOD2 Administrar motivo de consulta: Estos casos de uso tratan de administrar el motivo de consulta de un paciente. Cuando un paciente es atendido por el médico del área, éste último debe registrar el motivo de la consulta del paciente. Este caso de uso sólo puede ser realizado por usuarios que sean de tipo médicos. CUMOD3, CUMOD4 y CUMOD5 Administrar prioridad del paciente: Estos casos de uso tratan de administrar la prioridad de un paciente. Luego de que el médico del área registra el motivo de consulta del paciente, éste debe asignarle una prioridad al mismo. Esto es para indicar el estado del paciente. Esta acción solo puede ser realizada por un usuario de tipo médico. CUMOD6, CUMOD7 y CUMOD8 Administrar destino del paciente: Cuando el paciente recibe un destino, el usuario debe registrar en el sistema cuál destino le asignó al paciente. Este caso de uso trata de administrar los destinos que se le asignan al caso. Sólo puede ser realizado por un usuario de tipo médico. Para más detalles de los casos definidos para el proyecto, revisar el Apéndice D.

46 Fase de Construcción Luego de definir los casos de uso en la fase de elaboración, se estimó el tiempo que debería tomar la fase de construcción. Se dividió la fase de construcción en dos (2) iteraciones: en la primera iteración se enfocó en realizar las aplicaciones necesarias para el módulo de Orientación Diagnóstica y en la segunda iteración se implementó todo lo necesario para el módulo de Emergencia Primera Iteración A continuación se enumeran las actividades más importantes llevadas a cabo durante la primera iteración de la Fase de Construcción. 1. Implementación del servicio web que comunica la base de datos del módulo de Orientación Diagnóstica ubicada en el servidor de la CSS con la aplicación en la tableta. 2. Diseño e implementación del sistema de comunicación entre el servicio web y la aplicación en la tableta. 3. Diseño e implementación de la interfaz de todas las ventanas de la aplicación en la tableta. 4. Instalación del servicio web en la computadora local para realizar las pruebas de comunicación. 5. Instalación de la base de datos del módulo a desarrollar en la computadora local para realizar las pruebas de comunicación. 6. Implementación de la aplicación de la tableta desarrollada en Android, cubriendo los casos de uso definidos con el cliente Servicio Web La aplicación desarrollada para el módulo de Orientación Diagnóstica requería comunicarse con la base de datos que se encuentra en el servidor de la clínica, por lo que se necesitó un servicio web que se encargara de comunicar la aplicación con la base de datos. Este servicio web, por requerimientos del cliente, fue desarrollado en C# en el IDE Microsoft Visual Studio 2008 para ser ejecutado en el servidor que tiene sistema operativo de Microsoft.

47 35 Se utilizó el protocolo SOAP para ejecutar la comunicación entre el servicio web y la aplicación móvil. Se utilizó el formato JSON para serializar y deserializar la información enviada. Se diseñó e implementó un método de comunicación entre el servicio web y la aplicación en la tableta, el cual se basa en una clase llamada en el proyecto de Android Objeto de Comunicación con los siguientes atributos: Un número, el cual indica el número del error o del contenido del atributo objeto. Un objeto, el cual podría ser recursivamente otro objeto de comunicación o el mensaje en sí. Se concibió este método por la flexibilidad que brinda tener un atributo de tipo objeto ya que, de esta manera se facilita la detección de los distintos tipos de errores que puede dar el servicio web. Mediante este método, el servicio web respondía a las peticiones de la aplicación. La comunicación normal entre la aplicación móvil y el servicio web empieza con un intento de inicio de sesión, en el que la aplicación le envía al servicio web un usuario y una clave que éste tiene que validar. El servicio web verifica en la base de datos de la clínica si la información recibida pertenece a un usuario válido. De ser los datos correctos, el servicio web le envía un mensaje a la aplicación indicando que el inicio de sesión fue exitoso junto con un pequeño archivo (Cookie) que tiene un tiempo de inactividad definido. Al vencerse el tiempo de inactividad previamente definido para el pequeño archivo (Cookie) ésta deja de tener validez para el servicio web y el usuario debe iniciar sesión nuevamente. Luego de iniciar sesión el usuario puede hacer cualquier petición al servicio web y éste último le responderá con la información. Si se realiza una petición al servidor sin indicarle una Cookie válida, este le enviará un mensaje de error indicando que debe iniciar sesión antes de realizar una petición. El servicio web se comunica con la base de datos implementada en SQL Server, la cual realiza las acciones requeridas para cada caso Aplicación Móvil para la Tableta La aplicación móvil se encarga de guiar al usuario de forma tal que siga con el flujo de proceso definido para el módulo. Android maneja la interfaz gráfica bajo el concepto de Activity, que representa lo que se conoce comúnmente como ventanas. La primera ventana que ve el usuario al iniciar la aplicación

48 36 por primera vez es la de inicio de sesión. En ésta se solicita que el usuario introduzca su nombre de usuario y luego debe introducir su contraseña para iniciar su sesión. Luego que el usuario inicia sesión satisfactoriamente, la aplicación muestra una ventana en la que se listan a todos los pacientes activos en este módulo. Ésta es la ventana principal del programa y desde ella el usuario tiene acceso a todas las funciones que requiere. Dependiendo del estatus de cada caso, el sistema permitirá realizar algunas acciones respectivas al caso. De esta manera es como la aplicación obliga al usuario a seguir el flujo de proceso definido para el módulo. A continuación se listan los casos de uso que se planearon cubrir para esta primera iteración del Módulo de Orientación Diagnostica: manejo de Sesiones, reportar nuevo paciente en el módulo, reportar y visualizar toma de signos vitales, reportar motivo de consulta, reportar prioridad de un paciente, reportar destino de un paciente, reportar alta de un paciente, deshacer alta de un paciente y documentación de prioridad según síntoma Manejo de Sesiones El usuario al entrar a la aplicación debe iniciar su sesión, para ello debe introducir su nombre de usuario y luego introducir su contraseña. Para introducir su clave tiene dos tipos de contraseña posible: una es una clave gráfica que consta de presionar una serie de imágenes que previamente tiene definida el usuario y la otra es introducir por teclado una clave alfanumérica. Al iniciar sesión exitosamente, la aplicación obtiene el tipo de usuario que inicia sesión (enfermera o médico), nombre del usuario, entre otras cosas. La sesión del usuario tiene 15 minutos de inactividad, trascurrido ese tiempo cuando el usuario nuevamente trate de actualizar o solicitar alguna información al servicio web, la aplicación le informará que su sesión ha vencido y que debe iniciar sesión nuevamente. El usuario desde cualquier ventana de la aplicación puede cerrar su sesión para indicar a la aplicación que ha dejado de trabajar en el dispositivo.

49 Reportar Nuevo Paciente en el Módulo Al llegar un paciente al módulo de Orientación Diagnostica, éste debe ser reportado en el sistema antes o durante es atendido y es recomendable, dependiendo del estado del paciente, registrar una toma de signos vitales. Para reportarlo en el sistema el usuario debe introducir la cédula del paciente y la aplicación revisará en la base de datos de la clínica si ya se tiene la información del paciente registrada (nombre, apellido, edad, dirección, teléfono, sexo y fecha de nacimiento). De encontrarse registrado, la aplicación muestra al usuario toda esta información para el que éste último la valide con el paciente. El usuario solo debe registrar la estatura y peso del paciente. De no estar registrado, le solicita al usuario que registre la información del paciente para agregarla a la base de datos de la clínica, además de la estatura y peso actual del paciente. Luego de esto el paciente entra a la lista de pacientes activos en el módulo. Esta acción la puede realizar cualquier tipo de usuario, enfermera o médico Reportar Toma de Signos Vitales En cualquier momento que el usuario desee, puede reportar una toma de signos vitales a un paciente registrado en el módulo y que no haya sido dado de alta. Esto es reportar al menos uno de los siguientes valores: temperatura, frecuencia cardíaca, frecuencia respiratoria, pulso y presión arterial. Esta toma es reporta junto con el usuario que la registra en la base de datos de la clínica a través de la aplicación. Esto permite que si a un paciente se le registra una toma desde una tableta, simplemente con actualizar la información en cualquier otro dispositivo del módulo, bien sea tableta o PC se podrá visualizar este registro. La idea de registrar esta información es llevar un control del estatus del paciente durante su estadía en la clínica y de ser el caso, poder detectar algún patrón que presente el paciente en estas tomas. Además, la clínica desea que el paciente se sienta atendido durante su estadía y ésta es una forma de lograrlo, ya que existe la posibilidad de que el paciente tenga que esperar un tiempo antes de ser atendido por el médico del área.

50 38 Luego de que un paciente es dado de alta del módulo, no se puede modificar más el caso, por lo que no se le podrán registrar más tomas de signos vitales a menos que se le cambie el estatus. De esto se hablará más adelante. Esta acción la puede realizar cualquier tipo de usuario, enfermera (o) o médico Reportar Motivo de Consulta Cuando el médico del módulo atiende al paciente, éste primero debe registrar el motivo de la consulta del paciente a la clínica. Para ello, la aplicación le facilita al usuario un cuadro de texto donde el médico debe registrar toda la información que considere relevante junto con el motivo de consulta. Esta función se encuentra sólo para los usuarios que son médicos, ya que sólo ellos pueden registrar en el sistema esta información mientras atienden al paciente Reportar Prioridad del Paciente Luego de conocer el motivo de consulta del paciente y las tomas registradas de signos vitales, el médico posee suficiente información para asignarle una prioridad al paciente. Esto indica cual es el estatus del paciente en el módulo. Las posibles prioridades son las siguientes: Prioridad I: Es la máxima prioridad que se le puede asignar a un paciente. Este paciente debería ser enviado a emergencias lo antes posible, o ser remitido a otro centro hospitalario de urgencia en caso de no haber cupo en el módulo de Emergencia y corra peligro su vida. Prioridad II: Esta es una prioridad intermedia, indica que el paciente no se encuentra en ninguna condición de emergencia ni que su salud puede empeorar mientras no es atendido en emergencia. Generalmente a los pacientes con esta prioridad deben ser enviados a emergencia para realizarle estudios más exhaustivos. Estos pacientes tienen menos prioridad que los de Prioridad I y por consiguiente deben esperar más para ser trasladados al módulo de emergencia. Prioridad III: Esta es la prioridad más baja. Estos pacientes generalmente serán enviados a alguna consulta médica. No presentan ningún problema grave. Prioridad IV: Esta prioridad indica que el paciente se retiró bien sea contra indicación médica o sin ser atendido.

51 Reportar Destino del Paciente Luego de que al paciente se le registre la el motivo de consulta y la prioridad, el médico le asigna un destino y este debe ser registrado en el sistema. Para ello el sistema muestra los posibles destinos y el usuario debe seleccionar a cual se envía el paciente según su estado de salud. Al igual que el reporte de motivo de consulta, esta acción solo puede ser realizada por un médico, ya que es el personal capacitado para asignar un destino según el estado del paciente. Dependiendo de la prioridad que tenga asignada el paciente, la aplicación le ofrece un destino sugerido al usuario. Al paciente no se le puede asignar destino si no tiene una prioridad previamente asignada Reportar Alta de un Paciente Luego de que un paciente ya tiene destino asignado, este debe esperar o no, y se registra el momento exacto en el que al paciente se da de alta del módulo y se remite a su destino asignado. Esta acción solo puede ser realizada por un médico. Luego de que un paciente se reporte como dado de alta, ningún usuario podrá modificar el caso, ya que el paciente no se encuentra en el módulo Deshacer Alta de un Paciente Existe la posibilidad de que un paciente se le quiera deshacer el alta por varias razones, las principales son listadas a continuación: Fue dado de alta por algún error usuario, seleccionó al paciente que equivocadamente y dio de alta a otro paciente. Se desea agregar información adicional al caso que no fue correctamente registrada en el sistema. Por lo antes nombrado, se agregó la opción de deshacer el alta de un paciente, es decir, el paciente vuelve a tener su caso activo en el módulo de Orientación Diagnostica y su caso puede ser modificado nuevamente. Para realizar esta acción se tiene que cumplir las siguientes condiciones: El caso no lleva más de veinte y cuatro (24) horas desde el momento que se dio de alta.

52 40 El caso no ha sido facturado en algún otro módulo de la clínica. Esta acción solo puede ser ejecutada por un usuario tipo médico y queda registrado en el sistema quien realizó la acción, fecha y hora, entre otras cosas Documentación de Prioridad según Síntoma Suponiendo que algún médico tenga la información de motivo de consulta del paciente más la información de las toma de signos vitales registradas y no sepa que prioridad asignarle al paciente, el usuario cuenta con una documentación que trae la aplicación para estos casos. Según la especialidad médica del caso del paciente y los síntomas que el paciente presente, el usuario puede encontrar un destino sugerido por esta documentación. Esta opción es solo para los médicos, ya que solo ellos pueden asignar prioridad a los casos del módulo Segunda Iteración Durante la segunda iteración se desarrolló el módulo de Emergencia, el servicio web perteneciente a este módulo y se realizaron las pruebas de ambas aplicaciones, la desarrollada para el módulo de Orientación Diagnóstica y la desarrollada para el módulo de Emergencia Servicio Web Este servicio fue desarrollado en C# bajo el IDE Microsoft Visual Studio. Sirve de puente para la comunicación entre la base de datos y la aplicación móvil. El desarrollo del servicio web fue la parte más difícil de esta iteración, debido a que las acciones que implican ciertas decisiones en el sistema de la clínica, debían implicar las mismas acciones para la aplicación móvil y el encargado de ejecutarlas principalmente es el servicio web.

53 Aplicación Móvil para Tableta Esta aplicación es desarrolla para uso exclusivo de los médicos de emergencia de la clínica, por lo que sólo pueden acceder a ella los médicos de emergencia. Es diseñada para que en ella el médico registre la información referente al caso. De la manera como se encuentra implementado en estos momentos, el médico debe ir a revisar y hablar con el paciente para luego dirigirse a su puesto de trabajo a registrar esta información. Esta aplicación fue realizada con la visión de romper este paradigma y lograr que el médico traslade su lugar de trabajo al paciente y mientras recaba la información la va registrando instantáneamente. La interfaz de la aplicación fue desarrollada con la idea de tener la mayor similitud posible a la interfaz del sistema que ya la clínica tiene en este módulo para ayudar al usuario a familiarizarse más rápido con la aplicación. Los casos de uso que se plantearon cubrir en esta iteración del módulo de Emergencia son: listar los casos activos en el área de emergencia, registrar información del paciente, colocar historia médica como definitiva, deshacer colocar historia médica como definitiva y solicitar examen médico, medicamente y material médico quirúrgico Listar casos activos en el área de emergencia Los pacientes para ingresar al módulo de emergencia deben inicialmente pasar por el servicio de Admisión de la clínica, en donde se registra el ingreso del paciente junto con una serie de datos administrados que la clínica requiere y que no están relacionados con este proyecto. Luego de finalizar todo esto, el sistema de Admisión registra al paciente y está información es escrita en la base de datos, de la que se lee los casos activos en el módulo de Emergencia. La aplicación lista los casos activos en el área de Emergencia, siendo ésta la ventana principal de la aplicación. Desde ella se puede acceder a cualquier caso activo para registrar información al paciente Registrar información del paciente Luego de que un paciente haya sido ingresado al módulo de Emergencia y se encuentre activo en él, se le puede registrar información del caso. Todos los casos tienen unos campos específicos donde el

54 42 médico coloca la información necesaria. Entre ellos está el indicar que médico especialista trato al paciente, las indicaciones que dio el médico especialista, informe de ingreso, informe de egreso, entre otras cosas Solicitar examen médico, medicamento y material médico quirúrgico Inicialmente se planteó la opción de que el médico pudiera directamente desde la aplicación solicitar la realización de un examen médico, solicitar algún medicamento o material médico quirúrgico para el paciente. Sin embargo, éste caso de uso no se llegó a implementar debido a que la clínica no tenía desarrollado completamente el soporte necesario en el sistema para que los demás módulos de la clínica manejaran estas solicitudes a cabalidad. Se dejó como un caso de uso para otra iteración del proyecto luego de que la clínica cuente con el soporte para estos requerimientos en los módulos pertinentes Deshacer y colocar historia médica como definitiva Luego de que un paciente es atendido en Emergencia, se debe indicar el cierre de este caso en el área. Para ello existe la función de marcar la historia médica como definitiva. Luego de ejecutar esta acción, no se puede realizar ninguna modificación al caso. Por otro lado, también existe la opción de quitar esta historia marcada como definitiva y volver a activar el caso para realizar en él alguna modificación. Cuando un caso se vuelve a activar, se registra en el sistema la fecha, hora y usuario realizó esta acción Ejecución de pruebas Durante esta segunda iteración, se ejecutaron las pruebas definidas en la fase anterior para ambas aplicaciones: la del módulo de Orientación Diagnóstica y la del módulo de Emergencia. Se verificó para cada caso de uso que realizará su función correctamente. En el Apéndice J, puede encontrar más detalladamente los resultados de estas pruebas. Para llevar a cabo estas pruebas, se contó la facilidad de que la parte del servicio web del módulo de Orientación Diagnóstica se instaló en el servidor de la clínica junto con la base de datos, lo que permitió realizar las pruebas desde un dispositivo móvil real ofreciendo más rapidez y realismo que el

55 emulador en la estación de desarrollo. Lamentablemente no se contó con la misma facilidad para el módulo de Emergencia, por lo que las pruebas se realizaron en el emulador de Android Dificultades Presentadas en la Implementación del Sistema Las principales dificultades encontradas en la implementación del proyecto fueron ocasionadas por el desconocimiento de la tecnología. Muchas funciones del API de Android tienen muchos detalles que no están bien documentados y que puede requerir mucho tiempo detectar las diferencias. La interfaz gráfica de las ventanas fueron bastante difíciles de cuadrar, debido a que el modulo del SDK de Android que ofrece esta opción tiene muchos errores, entre ellos vale resaltar el de no dibujar bien los objetos, el de no mostrar los objetos en el SDK como se ven en los dispositivos aunque se les asigne el mismo tamaño y características de pantalla. Cuando se ejecuta la aplicación en el emulador del SDK, éste último es bastante lento. El emulador puede llegar a tardar hasta 60 segundos aproximadamente según la experiencia en cargar la aplicación, por lo que es bastante tedioso corregir los errores que se esté teniendo en la interfaz. Además de esto, que el emulador se conecte con el servicio web también toma bastante tiempo. En la computadora que se desarrolló la aplicación, la conexión del servicio web con la base de datos puede llegar a tomar mucho tiempo, es realmente aleatorio. Algunas veces no toma ni un segundo. Pero en otras llega a tomar más de 60 segundos por lo que la aplicación en Android muchas veces cuando trataba de realizar la conexión con el servicio web terminaba arrojando error de Timeout (tiempo agotado). Este error no ocurre con el servicio web ejecutándose en el servidor del cliente. Nunca se llegó a detectar una razón específica de esta tardanza, mas sin embargo se piensa que está relacionado con el SQL Server. Hubo varias modificaciones que realizó el cliente en el módulo de Orientación Diagnóstica sin previo aviso, por lo que se tuvo que volver a implementar varias funciones y algunas se agregaron nuevas.

56 Capítulo 6 44 Conclusiones y Recomendaciones Todas las actividades que conformaban el proyecto de pasantía fueron realizadas con éxito, lo que generó dos aplicaciones móviles para el cliente: una para el módulo de Orientación Diagnóstica y otra para el módulo de Emergencia. Se estudió el comportamiento general y estándar a nivel mundial del área de Triaje (llamado por la clínica Orientación Diagnóstica) y en base a ello se discutió y acordó con el cliente el flujo de proceso que deseaba seguir la clínica en este módulo y que a su vez está directamente relacionado con el comportamiento de la aplicación. En base a este estudio, discusiones, propuestas y acuerdos conseguidos entre ambas partes, personal del área de sistemas de la clínica y grupo de desarrollo de Global Consultants Group, se pudo diseñar y concretar las funcionalidades que debe ofrecer la aplicación al usuario y el comportamiento en general de la misma. Se analizó el estado actual del sistema que el cliente tiene para el módulo de Emergencia y los requerimientos que se deseaba que fuesen implementados en la aplicación móvil. A partir de esto se pudo definir el diseño y las funcionalidades de la aplicación que se desarrolló para el módulo de Emergencia. Para poder construir las aplicaciones fue necesario definir, diseñar e implementar una serie de servicios web que ofrecería el servidor de la Clínica Santa Sofía, los cuales serían utilizados por las aplicaciones móviles para su funcionamiento. Aunque este desarrollo no formaba parte del proyecto de pasantía, fue implementado durante el mismo en conjunto con las aplicaciones. Los servicios web y las aplicaciones fueron desarrollados en conjunto para cada módulo, debido a que se necesita una buena compaginación entre los servicios web que alimentan a cada aplicación respectivamente. Para construir las aplicaciones móviles se tomaron en consideración las mejores prácticas y lineamientos propuestas por el equipo de desarrollo de Android, así como los patrones de diseño de interfaz, de usabilidad y las de herramientas de desarrollo propuestas este equipo. Esto con el

57 45 fin de construir un producto que cumpla con los estándares de calidad propuestos por Google como empresa propietaria de Android. Para garantizar la entrega de un producto de calidad, que cumpla con los requerimientos planteados por la organización se llevaron a cabo una serie de pruebas a nivel de sistema. Entre estas pruebas se encuentran pruebas funcionales y pruebas de aceptación en las que las aplicaciones obtuvieron los resultados que se esperaba obtener en dichas pruebas. El desarrollo de estas aplicaciones les ofrece a los empleados de la clínica una herramienta que les facilita el trabajo desde muchos puntos de vista. Entre ellos vale la pena nombrar el beneficio que representa trasladar el área de trabajo del médico al paciente y de esta manera se vuelva algo menos tedioso el registro de la información en el sistema de la clínica, que el empleado sienta la tecnología más cercana a su trabajo y a su realidad diaria, entre otras cosas. Para Global Consultants Group el desarrollo de estas aplicaciones representa una nueva rama de incursión en las nuevas tecnologías, ya que para la empresa éste fue el primer proyecto en el que se desarrolló para el sistema operativo Android y también las primeras aplicaciones diseñadas para tabletas. Otro logro adicional realizado durante la pasantía fue el establecimiento de estándares de desarrollo para la plataforma Android en la empresa que facilitan la construcción de futuras aplicaciones. Esto amplía el mercado tecnológico y comercial al que Global Consultants Group tiene acceso. Otro punto importante a destacar es que este proyecto representa una innovación para el personal de la clínica, ya que en ésta es la primera vez que utiliza tabletas como herramientas de trabajo. Luego de llevar a cabo el desarrollo del proyecto de pasantía y los conocimientos obtenidos, durante la realización de la misma, se presentan las siguientes recomendaciones: Continuar con el desarrollo de aplicaciones para los distintos módulos de la clínica: esto con el objetivo de ofrecer más poder de información al usuario sobre el paciente, el estatus de la clínica, entre otras cosas. Una de las visiones a futuro que se tuvo durante el desarrollo de esta aplicación, es lograr la integración de toda la información que la clínica posee de un paciente (radiografías, exámenes médicos, exámenes de sangre, previos ingresos en la clínica, causas e informes finales y

58 cualquier otra información relevante para el médico en la toma de decisiones). Esta información sería mostrada al médico de forma asertiva para su manipulación inmediata. 46 Mantener actualizada la documentación: así como se propone continuar con nuevas funcionalidades para las aplicaciones también es necesario actualizar la documentación correspondiente a éstas, de manera que sea fácil el mantenimiento de tales aplicaciones. Transferir el conocimiento al área de tecnología de la clínica: es un punto importante, para que si en algún momento requieren realizar mantenimiento o corrección de algún error grave en alguna aplicación, se evita la dependencia de la clínica para-con Global Consultants Group. Aunque siga siendo Global Consultants Group quien desarrolló las nuevas aplicaciones antes recomendadas. Mantener un producto al nivel de los estándares tecnológicos: con el fin de proveer un producto que siempre esté a la vanguardia, es importante que las nuevas versiones del sistema se implementen siguiendo los estándares recomendados por los desarrolladores de Android. Promover el uso de las aplicaciones móviles en el personal médico de la clínica: Para realizar esta promoción, es necesario que inicialmente el personal del área de información de la clínica adiestre a los médicos usuarios de las tabletas y al personal en general en el uso de dispositivos táctiles. De esta manera, el personal de la clínica se sentirá cómodo cuando tenga que utilizar aplicaciones instaladas en tabletas o dispositivos táctiles. Con esto se logra mostrar al gremio médico que el uso de estos dispositivos en su área de trabajo ayuda al personal a realizar su trabajo más eficientemente y a la vez se sienten incentivados a expandir el uso de estos dispositivos a los demás módulos de la clínica. Mantener el contacto con los usuarios de las aplicaciones para verificar cualquier mejoría que éstos puedan sugerir: nadie mejor que los propios usuarios para sugerir mejoras a una aplicación. Éstos son los que interactúan más a menudo con el sistema que los propios desarrolladores. Por esto, es importante que el área de tecnología una vez implantado el sistema y dado el adiestramiento a los usuarios en el uso de las aplicaciones sobre tabletas, mantenga el contacto directo con estos usuarios (personal médico y enfermeras de la clínica) para detectar nuevos requerimientos.

59 47 Bibliografía [1] Global Consultants Group Disponible en internet: [2] Wikipedia, Tableta. Disponible en internet. consultado el 24 de Abril de [3] Desarrolladores de Android. 2011, Qué es Android?, Disponible en internet: consultado el 24 de Abril de [4] Pagina de desarrolladores del sistema operativo de Apple ios. Disponible en internet. w/iphoneosoverview/iphoneosoverview.html, consultado el 30 de Abril del [5] Wikipedia, JSON. Disponible en internet: consultada el 24 de Abril del [6] Wikipedia, Simple Object Access Protocol. Disponible en internet: consultada el 24 de Abril del [7] BusinessWeek.com Google compra Android. Disponible en internet: consultado el 24 de Abril del [8] Android. 2012, Qué es Android?, Disponible en internet: consultado el 24 de Abril de 2012.

60 48 [9] Google Play. 2012, Mercado de Aplicaciones de Android. Disponible en internet: consultado el 24 de Abril de [10] Android SDK Página del kit de desarrollo de software de Android. Disponible en internet: consultado el 24 de Abril de [11] Wikipedia, Microsoft Visual Studio. Disponible en internet: consultado el 24 de Abril de [12] Wikipedia, Microsoft SQL Server. Disponible en internet: consultado el 26 de Abril de [13] Wikipedia, Proceso Unificado de Rational. Disponible en internet: consultado el 2 de Mayo de [14] Wikipedia, Philippe Kruchten. Disponible en internet. consultado el 2 de Mayo del 2012.

61 APÉNDICES

62 Apéndice A Lista de Riesgos

63 51 Código Nombre Impacto R0 Desarrollos en nuevas Retraso en los tiempos estipulados durante el desarrollo de tecnologías para la la aplicación. El proyecto podría presentar fallas en los empresa. tiempos de entrega debido al uso incorrecto de la herramienta de desarrollo. R1 R2 R3 Adopción de la tecnología por parte de los usuarios. Integración con los sistemas de la Clínica Santa Sofía (CSS). Determinación inadecuada de los tiempos de ejecución de las actividades del proyecto. R4 La clínica decide finalmente no implantar la solución por el riesgo de daño o perdida de los equipos. R5 Cambio de estructura en el proceso del área de Orientación Diagnóstica Podría representar desde una curva de aprendizaje elevada y resistencia al cambio, por parte de los usuarios, hasta la NO ADOPCION de la aplicación y que se decida manejar estas áreas con otra tecnología de uso más común (PC o laptop). El impacto puede variar, dependiendo del grado de integración que se pueda lograr con los distintos sistemas, desde limitar algunas funcionalidades hasta cancelar el proyecto por falta de acoplamiento con los sistemas de la clínica. El proyecto no llega a término o sólo se logra un subconjunto limitado de las funcionalidades del sistema. Representaría un atraso en la culminación del proyecto, faltándole funcionalidades iníciales contempladas como principales para el correcto funcionamiento de la aplicación. Además, el descontento por parte del cliente, la empresa que apoya el proyecto y el pasante que lleva a cabo el proyecto. La clínica no implanta el proyecto. Representaría un cambio en la aplicación para adaptarse al proceso que termine por implantarse.

64 Apéndice B Skateholders con sus Respectivas Responsabilidades

65 53 Nombre Descripción Responsabilidades Alejandro Azcunes José Francisco Fiorillo Belkis Velazco Representante de Global Consultants Group. (Empresa Desarrolladora) Encargado del seguimiento y supervisión del proyecto. Pasante encargado del proyecto. Gerente de Tecnología de Información de la CSS Establecer junto con José Francisco Fiorillo los límites del proyecto. Establecer riesgos del proyecto. Monitorear la evolución del proyecto. Enlazar a Global Consultants Group con la CSS. Velar por el cumplimiento de los objetivos planteados. Establecer junto con Alejandro Azcunes los límites del proyecto. Contextualizar las ideas del proyecto. Documentar la evolución del proyecto. Análisis, diseño, desarrollo y pruebas del proyecto, siguiendo los pasos de la metodología RUP. Establecer riesgos del proyecto. Escoger una metodología para seleccionar la tableta que mejor se adecue al proyecto. Seguir la metodología previamente seleccionada, para escoger la tableta que mejor se adecue al proyecto. Facilitar la información necesaria para entender el proceso de emergencia. Definir junto con José Francisco Fiorillo, Alejandro Azcunes y Junta Directiva de la CSS el proceso de Orientación Diagnóstica. Revisar y corregir (de ser el caso) la información levantada por Global Consultants Group en las reuniones. Mediar entre los usuarios finales (médicos y enfermeras) de la aplicación y Global Consultants Group para ayudar a concretar las ideas.

66 Apéndice C Usuarios de las Aplicaciones

67 55 Nombre Descripción Responsabilidades Médicos especialistas de Emergencia. Médicos especialistas de Orientación Diagnostica. Enfermeras de Orientación Diagnóstica. Son usuarios finales que podrán manejar su trabajo en el área mediante el proyecto propuesto. Son los médicos que asignan la prioridad a un paciente, y le indica los pasos a seguir para atender su caso. Junto con los médicos especialistas de Orientación Diagnóstica, son el personal de la clínica que se encarga de atender el área de Orientación Diagnóstica. Utilizar la aplicación para llevar el informe de emergencia de cada caso. Utilizar la aplicación para manejar el área de Orientación Diagnóstica, asignarle prioridad a cada paciente según su estado de salud, reportar en la aplicación información relevante y pertinente de cada caso. Abordar al paciente a su llegada, tomar los datos del paciente y tomar los signos vitales del paciente.

68 Apéndice D Diagrama ER

69 57 Valor Descripción Síntomas N Referencia Especialidad M Peso Fecha de Ingreso Estatura Paciente 1 Signo vital registrado Hora de Registro Ingresa a OD N Datos básicos Caso Registra OD 1 signos vitales N Signos Vitales 1 N 1 Descripción id 1 Prioridad N 1 Pertenece N Prioridad Asignada 0,1 Recibe Destino Sugerido Es de tipo 1 Destinos 1 Pertenece N Destino Asignado 0,1 Es de tipo 1 1 N Atenciones Hora de Registro Tiene id Nombre Status del caso 0,1 Es de tipo 1 1 N Toma 0,1 Observaciones Es de tipo N Motivo de consulta 0,1 Registra Realiza Hora de registro Observación 1 1 Persona Tratante 1

70 Apéndice E Diagrama Relacional

71 59

72 Apéndice F Metodología de Comparación de Tabletas

73

74

75

76

77 Apéndice G Ejecución de la Metodología de Comparación

78

79 Apéndice H Documento de Visión del Sistema

80

81

82

83

84

85

86

87

88

89

90

91

92 Apéndice I Documento de Requerimientos del Sistema

93

94

95

96

97

98

99

100

101

102

103

104

105

106 Apéndice J Especificación de Casos de Uso

107

108

109

110

111

112

113

114

115

116

117

118

119

120

121

122

123

124

125

126

127

128

129

130 Apéndice K Glosario

131

132

133

134

135

136

137 Apéndice L Lista de Riesgos

138

139

140

141

142

143

144

145

146

147 Apéndice M Documento de Arquitectura

148

149

150

151

152

153

154

155

156

157

158

159

160

161 Apéndice N Plan de Pruebas

162

163

164

165

166

167

168

169

170

171 Apéndice O Manual de Instalación

172

173

174

175

176

177

178

179

180

181

182

183

184

185

186

187

188

189

190

191

192

193

194