PLATAFORMA MÓVIL PARA EL MANEJO Y EL DE LOS EQUIPOS

LainformaciónpresentadaenestedocumentoesdeexclusivaresponsabilidaddelosautoresynocomprometealaEIA.

1

PLATAFORMA MÓVIL PARA EL MANEJO Y EL CONTROL DE LOS EQUIPOS BIOMÉDICOS DE LA

EMPRESA ST. JUDE COLOMBIA.

ISABEL CORREA MESA

Trabajo de grado para optar al título de

Ingeniera Biomédica

Diego Alejandro Silva

Ingeniero Biomédico- Gerente de Ingeniería AF

UNIVERSIDAD EIA-CES

ABBOTT- FORMALMENTE ST. JUDE MEDICAL COLOMBIA ENVIGADO-MEDELLÍN

2017


2

AGRADECIMIENTOS

En primer lugar, agradecer a Dios, por ser durante estos cinco años de carrera mi compañero, mi apoyo incondicional para seguir adelante y permitirme aprender y disfrutar de esta experiencia.

A mi familia por su completo amor, por su paciencia y por ser siempre mi guía para continuar y crecer.

A la universidad EIA, a la universidad CES y a todos los profesores que fueron parte de mi formación académica y me brindaron los conocimientos necesarios para mi desarrollo profesional. A Juan Camilo Hincapié por su paciencia a la hora explicar y su apoyo durante todo este proyecto.

Por último, agradecerle a la empresa St. Jude Medical Colombia por abrirme sus puertas y permitirme realizar este proyecto. A mi director de trabajo de grado, Diego Silva por su ayuda.


3

CONTENIDO pág.

INTRODUCCIÓN .................................................................................................... 12

1 PRELIMINARES .............................................................................................. 13

1.1 Contextualización y antecedentes ............................................................ 13

1.2 Justificación ............................................................................................... 14

1.3 Objetivos del proyecto ............................................................................... 14

1.3.1 Objetivo General ................................................................................. 14

1.3.2 Objetivos Específicos ......................................................................... 15

1.4 Marco de referencia .................................................................................. 15

1.4.1 Lenguaje Unificado de Modelado (UML) ............................................ 15

1.4.2 Bases de datos ................................................................................... 20

1.4.3 Framework .......................................................................................... 21

1.4.4 Lenguaje de programación Swift ........................................................ 21

1.4.5 Ruby y Rubi on rails: .......................................................................... 22

2 ENFOQUE Y METODOLOGÍA ........................................................................ 24

2.1 Etapa uno: ................................................................................................. 24

2.2 Etapa dos: ................................................................................................. 24

2.3 Etapa tres: ................................................................................................. 25

2.4 Etapa cuatro: ............................................................................................. 25

3 PRODUCTOS, RESULTADOS Y ENTREGABLES OBTENIDOS .................. 27

3.1 Primer entragable: ..................................................................................... 27

3.1.1 Diagrama de Entidad-Relación: .......................................................... 28

3.1.2 Diagrama de clases: ........................................................................... 29


4

3.1.3 Casos de uso: ..................................................................................... 29

3.2 Segundo entragable: ................................................................................. 57

3.2.1 Modelos y relaciones: ......................................................................... 57

3.2.2 Validación de usuarios e inicio de sesión: .......................................... 59

3.2.3 Gestión de equipos y accesorios: ....................................................... 63

3.2.4 Gestión las instituciones: .................................................................... 65

3.2.5 Eventos y cronograma: ....................................................................... 67

3.2.6 Reportes de servicio técnico: ............................................................. 68

3.2.7 Implementación en el servidor: ........................................................... 70

3.3 Tercer entragable: ..................................................................................... 70

4 CONCLUSIONES Y RECOMENDACIONES ................................................... 75

REFERENCIAS ...................................................................................................... 76

ANEXO 1 ................................................................................................................ 78

................................................................................................................................ 79


5

LISTA DE TABLAS

pág.

Tabla 1 Primer entregable .................................................................................................. 27

Tabla 2 Gestionar los equipos ............................................................................................ 32

Tabla 3 Crear un equipo ..................................................................................................... 33

Tabla 4 Eliminar equipo ...................................................................................................... 34

Tabla 5 Editar equipo ......................................................................................................... 35

Tabla 6 Ver equipo ............................................................................................................. 36

Tabla 7 Listar equipos ........................................................................................................ 36

Tabla 8 Gestionar tipos de equipo ..................................................................................... 37

Tabla 9 Crear tipo de equipo .............................................................................................. 38

Tabla 10 Eliminar tipo de equipo ........................................................................................ 39

Tabla 11 Listar tipo de equipo ............................................................................................ 40

Tabla 12 Editar tipo de equipo ........................................................................................... 40

Tabla 13 Ver tipo de equipo ............................................................................................... 41

Tabla 14 Gestionar Instituciones ........................................................................................ 42

Tabla 15 Crear una Institución ........................................................................................... 43

Tabla 16 Eliminar una Institución ....................................................................................... 43

Tabla 17 Editar una Institución ........................................................................................... 44

Tabla 18 Listar Instituciones ............................................................................................... 44

Tabla 19 Ver Institución ...................................................................................................... 45

Tabla 20 Gestionar Herramientas de medición .................................................................. 46


6

Tabla 21 Crear Herramienta de medición .......................................................................... 46

Tabla 22 Eliminar Herramienta de medición ...................................................................... 47

Tabla 23 Listar Herramientas de medición ......................................................................... 47

Tabla 24 Editar Herramienta de medición .......................................................................... 48

Tabla 25 Gestionar reportes de servicio ............................................................................ 49

Tabla 26 Crear reporte de servicio ..................................................................................... 50

Tabla 27 Ver reporte de servicio ........................................................................................ 51

Tabla 28 Eliminar reporte de servicio ................................................................................. 51

Tabla 29 Editar reporte de servicio .................................................................................... 52

Tabla 30 Listar reportes de servicio ................................................................................... 53

Tabla 31 Imprimir reporte de servicio ................................................................................. 53

Tabla 32 Gestionar el cronograma ..................................................................................... 54

Tabla 33 Crear nuevo evento en el cronograma ................................................................ 55

Tabla 34 Ver los eventos del cronograma .......................................................................... 56

Tabla 36 Segundo entregable ............................................................................................ 57

Tabla 37 Relaciones entre modelos ................................................................................... 59

Tabla 38 Tercer entregable ................................................................................................ 71


7

LISTA DE FIGURAS

pág.

Figura 1 Ejemplo de diagrama de clases (Hernandez, 2002). ........................................... 18

Figura 2 Ejemplo de diagrama de casos de uso (Hernandez, 2002). ................................ 19

Figura 3 Ejemplo de diagrama de E/R. (Lucidchart, 2017). ............................................... 20

Figura 4 Patrón MVC (Gutiérrez, 2017) ............................................................................. 21

Figura 4 Diagrama Entidad Relación ................................................................................. 28

Figura 5 Diagrama de clases ............................................................................................. 29

Figura 6 Actores del sistema .............................................................................................. 30

Figura 7 Casos de uso ....................................................................................................... 31

Figura 8 Gestión de equipos .............................................................................................. 32

Figura 9 Gestión de tipos de equipos ................................................................................. 37

Figura 10 Gestión de Instituciones ..................................................................................... 42

Figura 11 Gestión de Herramientas de medición ............................................................... 45

Figura 12 Gestión de Reportes de servicio ........................................................................ 49

Figura 13 Gestión del cronograma ..................................................................................... 54

Figura 14 Inicio de sesión .................................................................................................. 60

Figura 15 Crear nuevo usuario ........................................................................................... 61

Figura 16 Lista de usuarios ................................................................................................ 61

Figura 17 Formulario de petición para recuperar contraseña ............................................ 62

Figura 18 Contraseña nueva .............................................................................................. 62

Figura 19 Listar tipos de equipos ....................................................................................... 63


8

Figura 20 Agregar un nuevo equipo ................................................................................... 64

Figura 21 Búsqueda de equipos ........................................................................................ 65

Figura 22 Agregar una nueva institución ............................................................................ 66

Figura 23 Búsqueda de instituciones ................................................................................. 67

Figura 24 Cronograma ....................................................................................................... 68

Figura 25 Agregar reporte de servicio ................................................................................ 69

Figura 26 Búsqueda de reportes de servicio ...................................................................... 70

Figura 27 Pregunta nº1 de la encuesta .............................................................................. 72






9

GLOSARIO

OBJETO: en programación se entiende por objeto a la unidad dentro de un programa que consta de un estado y de un comportamiento (Schildt 2009).

REST: son las siglas en inglés de “Representational State Transfer”, es un tipo de arquitectura de desarrollo web que permite crear servicios y aplicaciones que pueden ser usadas por cualquier dispositivo o cliente que entienda HTTP (Marqués 2013).

CASCADINGSTYLE SHEETS (CSS): en español son hojas de estilo en cascada, es un tipo de lenguaje de estilos, que especifica cómo se presentan los documentos frente a los usuarios (Barcia 2003).


10

RESUMEN St. Jude Medical Colombia es una de las compañías comercializadoras de equipos y dispositivos biomédicos más grandes del país, teniendo así bajo su control un aproximado de 600 equipos distribuidos en 113 instituciones prestadoras de servicios de salud en todo el país. De este modo nace la necesidad de un sistema que les permita manejar de manera óptima y ordenada cierta información relacionada a dichos equipos, tal como su ubicación, su estado, su serie y sus accesorios.

Teniendo en cuenta dicha necesidad, se decidió implementar por medio de los lenguajes de programación Ruby on Rails y Swift una aplicación móvil y web, que realiza las funciones de base de datos. Para su desarrollo, en primer lugar, se realizó una recopilación de información mediante una revisión bibliográfica profunda, la cual ayudo a definir la metodología que se utilizó. A partir de esta metodología se lograron diseñar tres diferentes entregables para la empresa. El primero de ellos consistió en una serie tablas y diagramas donde se plasma la estructura lógica que lleva BD y las funciones que pueden realizar los diversos usuarios en esta, el segundo consistió en la entrega de la aplicación web y móvil como tal y el ultimo en los resultados de una encuesta realizada una vez fue puesta en marcha la app.

Los resultados obtenidos fueron bastante positivos, sin embargo, se llegó a la conclusión de que el proyecto debe seguir de tal modo que se construya una base de datos más completa y amigable.

Palabras clave: St. Jude Medical Colombia, equipos biomédicos, base de datos, ruby on rails, Swift, control de información.


11

ABSTRACT

Resumen en inglés.

Keywords:


12

INTRODUCCIÓN

Toda empresa productora o comercializadora de equipos biomédicos requiere de un sistema que le permita ordenar y controlar de una manera fácil la información de los diferentes equipos que tiene a cargo la compañía o de aquellos que a pesar de ya ser propiedad del cliente poseen algún tipo de contrato de prestación de servicios. Para esto, muchas de las empresas han optado por la implementación de una base de datos, ya sea en forma de página web, de aplicación o por medio de una plataforma como SAP.

En el presente trabajo se muestra el diseño y el desarrollo de una aplicación tanto móvil como web que hace las funciones de base de datos para el manejo y control de los equipos biomédicos de la empresa St. Jude Medical Colombia, más específicamente para los equipos que están a cargo del departamento técnico o de ingeniería de la compañía.

En la primera parte del trabajo se realiza una breve contextualización sobre la situación actual de la empresa, sus necesidades y los beneficios que en un futuro puede llegar a traer para esta la implementación de una nueva base de datos. Posteriormente se muestra una breve indagación sobre algunos conceptos fundamentales para el desarrollo del prototipo, tales como los diversos lenguajes de programación que se utilizaron y los diagramas que permitieron crear la estructura lógica.

Este proyecto consta de tres entregables. El primero consiste en una serie de tablas y diagramas donde se muestran las diversas clases, funciones, atributos y autores del sistema. El segundo es el prototipo funcional de la base de datos y el ultimo consiste en una encuesta realizada a los ingenieros de la empresa, donde se les pidió, después de haber puesto en marcha el prototipo, que respondan una serie de preguntas sobre su funcionamiento.


13

1 PRELIMINARES

1.1 CONTEXTUALIZACIÓN Y ANTECEDENTES

La empresa St. Jude Medical fue fundada en 1976 en Little Canadá, Minnesota un suburbio de Saint Paul EEUU (St Jude Medical 2017). En un principio, esta compañía tenía como propósito fundamental el desarrollo y la comercialización de las válvulas cardíacas mecánicas artificiales bileaflet, las cuales fueron diseñadas por el Dr. Demetre Nicoloff en la universidad de Minnesota. Sin embargo, con el paso de los años esta empresa fue creciendo tanto como su portafolio de productos, como su cobertura de servicio, de comercialización y de atención. Este crecimiento fue tal, que para finales del año 2016 St. Jude Medical era una compañía global con 18,000 empleados en 40 países y un portafolio con más de 527 productos dividido en 6 áreas estratégicas: fibrilación auricular, gestión del ritmo cardiaco, vascular, enfermedades cardiacas estructurales, falla cardiaca y neuromodulación (Medical 2016).

A finales del año 2016, St. Jude Medical empieza a despertar el interés del laboratorio mundialmente reconocido Abbott, el cual adquiere la compañía en enero del presente año por un valor de 25 billones de dólares, causando cambios en las líneas de mercado existentes y generando un mayor crecimiento de la compañía (Abbott 2016).

St. Jude Medical Colombia, por su lado, es fundada en el año 2000 en la ciudad de Medellín como única sede (St Jude Medical 2017). Sin embargo, como era de esperarse en pocos años la empresa logro expandir su cobertura de servicio a muchas más ciudades, de tal modo que actualmente posee sedes en las cuatro ciudades principales y suficiente personal para cubrir la gran demanda nacional. Dicho crecimiento se ha visto reflejado en todas las áreas de la compañía, entre las cuales se encuentra el área de ingeniería, encargada, entre otras cosas, del sistema de mapeo 3D Ensite (permite el tratamiento de problemas de electrofisiología cardiaca) y del manejo, mantenimiento y ubicación de todos los equipos biomédicos de la compañía.

Por otro lado al crecer la empresa y sus áreas, también crece el número de equipos y servicios que esta posee o brinda. En términos generales esto significa un gran beneficio para la empresa y a sus trabajadores, sin embargo si no se posee un correcto manejo y control sobre los equipos y clientes, puede llegar a causar grandes pérdidas económicas y comerciales. De este modo y teniendo en cuenta que el sistema para el manejo y control que maneja la compañía actualmente no posee las herramientas suficientes para cubrir dicho aumente, se encuentra la


14

necesidad en el área de ingeniería de un mejor manejo y control en la información de los equipos y una forma más ágil y segura de relacionarla y modificarla.

1.2 JUSTIFICACIÓN

St. Jude Medical Colombia, como una de las empresas comercializadoras de equipos biomédicos más grandes del país, se enfrenta a diversos retos en términos económicos, comerciales y logísticos. Estos retos pueden llegar a significar un beneficio para la empresa si se enfrentan de la manera más óptima y con las herramientas adecuadas. De este modo, el poseer una plataforma digital o una aplicaciónn móvil que permita el manejo y control de los dispositivos biomédicos, puede significar un gran beneficio para la compañía, ayudando así a reducir el tiempo de respuesta frente a las solicitudes de los clientes, ya sean sobre equipos o procedimientos y a aumentar la proactividad de los ingenieros encargados.

En la actualidad el equipo de ingeniería de la empresa está conformado por 12 personas, las cuales están encargadas del manejo y control de más 600 equipos distribuidos en 133 instituciones en todo el país, esto significa que en promedio hay 50 equipos por ingeniero (Acces St. Jude Medical Colombia 2017). Lo anterior puede llegar a significar un problema para la empresa si no se le da un manejo óptimo y si no se tienen las herramientas necesarias para un buen control del inventario. Es por esto que una buena aplicación movil donde la información pueda encontrarse de manera ordenada, de fácil manejo, con una interfaz amigable y bastante ágil, puede llegar a reducir casi por completo el factor de riesgo que esto significa para la empresa.

Por otro lado, el aumento en la productividad de los ingenieros que brinda la implementación de dicha aplicación, permitirá un mayor tiempo disponible, el cual podrá ser usado en pro de las actividades comerciales y de mercadeo, lo cual se traduce en un aumento en los clientes y en las ventas por parte del equipo.

1.3 OBJETIVOS DEL PROYECTO

1.3.1 Objetivo General

Desarrollar una plataforma móvil que permita un mejor manejo y trazabilidad de la información sobre los equipos biomédicos a cargo del área de ingeniería de la empresa St. Jude Medical Colombia.


15

1.3.2 Objetivos Específicos

• Establecer una estructura lógica para el manejo de la información por medio del lenguaje de modelación UML, que permita el futuro desarrollo del software según las necesidades actuales presentadas por el área de ingeniería de la empresa St. Jude Medical Colombia.

• Mejorar el control existente sobre los equipos biomédicos de la compañía, por medio de la implementación de una aplicación que permita consultar y recolectar datos de manera de manera rápida.

• Verificar el correcto funcionamiento de la aplicación mediante la puesta en marcha de esta y el seguimiento a su operación por parte de los empleados de la empresa St. Jude Medical.

1.4 MARCO DE REFERENCIA

Con el fin de construir un buen marco teórico que oriente de manera positiva el desarrollo del proyecto planteado, es necesario indagar con mayor profundidad sobre algunos conceptos, temas y herramientas de desarrollo.

1.4.1 Lenguaje Unificado de Modelado (UML)

El lenguaje Unificado de Modelado o por sus siglas en ingles UML es un conjunto de notaciones, diagramas y estándares creado con el fin de unificar los métodos de comunicación y de diseño de software existentes. Este estándar empezó en 1994 como una consolidación del trabajo de Grade Booch, James Rumbaugh, e Ivar Jacobson, investigadores y creadores reputados en el área de metodología de software. (Popkin, 2001). Adicionalmente este lenguaje estuvo abierto a comentarios durante un breve periodo de tiempo con el fin de que otras empresas aportaran nuevas ideas y así formar una versión universal de UML (Hernandez, 2002).

A pesar de ser conocido como un tipo de lenguaje, UML consiste realmente en una serie de normas y estándares gráficos que buscan entre otras cosas dar una estructura más sólida, clara y universal a los diferentes softwares. De este modo UML puede traer un gran número de beneficios tanto para las grandes empresas como para pequeños desarrolladores de software, pues permite entender de mejor manera los códigos y así corregirlos o modificarlos de manera más eficiente.


16

Los estándares de modelado deben realizarse antes de empezar la etapa de codificación, es decir que desempeñan el papel analógico en el desarrollo del software. Su función es la de permitir la visualización el diseño y la comprobación de un correcto funcionamiento antes de que sea realizado el programa como tal. Por otro lado, los modelos ayudan a trabajar en un nivel más alto de abstracción, permitiendo una vista más detallada del código y el entorno en el que se ejecuta (Garrido 2003).

Para realizar dichos modelos analógicos, UML ofrece trece tipos de diagramas divididos en las siguientes tres grandes categorías:

• Diagramas de Estructura: Muestran la estructura estática de los objetos del sistema. Dentro de estos se encuentran los diagramas de clases, diagramas de objetos, diagramas de entidad-relación, diagramas de componentes, diagramas de estructura compuesta, diagramas de paquetes y diagramas de despliegue (UML, 2005).

• Diagramas de Comportamiento: Muestran el comportamiento dinámico de los objetos del sistema. Entre estos se incluye los diagramas de casos de Uso (utilizado por algunas metodologías durante la recolección de requisitos), diagramas de actividad y diagramas de máquina de estado (UML, 2005).

• Diagramas de interacción: Muestran la interacción usuario-aplicación. Incluye los diagramas de secuencias, diagramas de comunicación, diagrama de tiempo y diagrama de Interacción (UML, 2005).

El uso de estos diagramas depende directamente de la aplicación que se desee modelar. Sin embargo, existen tres diagramas que son comúnmente más utilizados por los usuarios pues además de tener un fácil manejo, brindan información de manera ordenada y concreta. A continuación, se realiza una breve descripción de estos:

1. Diagrama de clases:

Son, sin duda, el tipo de diagrama UML más utilizado por los usuarios. Esto se debe a que permiten modelar y construir cualquier solución orientada a objetos. De este modo, permite describir la estructura del sistema mostrando las clases del sistema, sus atributos, métodos y relaciones entre objetos.(Rumbaugh, Jacobson, and Booch 1999).

Un diagrama de clases está compuesto por los siguientes elementos:


17

▪ Clase: Es la unidad base, donde se encuentra toda la información de un objeto. Es representada por un rectángulo dividido por tres secciones.(Salinas 1996).

▪ Atributos: Son los encargados de caracterizar las clases. Se ubican en la parte intermedia del rectángulo. (Salinas 1996).

▪ Métodos: Es la forma en la que interactúa la clase con el entorno. Se ubica en la parte inferior del rectángulo.(Salinas 1996).

Los atributos y los métodos pueden ser o no accesibles fuera de la definición de clase. Los valores permitidos son los siguientes:

a. Publico (+): Indica que será visible tanto dentro como fuera de la clase, es decir, es accesible desde todos lados.(Salinas 1996).

b. Privado (-): Indica que será solo accesible únicamente desde dentro de la clase.(Salinas 1996).

c. Protegido (#): Solamente se puede obtener acceso a este tipo y sus tipos heredados.(Salinas 1996).

Adicionalmente, las clases pueden asociarse entre sí por medio de conexiones lógicas. Estas relaciones son las siguientes:

▪ Asociación: Permite asociar objetos que colaboran entre sí. Es normalmente representada por una línea continua y puede relacionar cualquier número de clases. (Salinas 1996).

▪ Agregación: Es una variante de la relación anterior. Puede utilizarse para indicar que las instancias del rol que se están agregando o contienen instancias de otro rol. No puede incluir más de dos clases (relación binaria). Es representada con un rombo. (Salinas 1996).

▪ Herencia: Indica que una subclase hereda los atributos y métodos de una Súper-clase. Es representada por medio de una flecha. (Salinas 1996).

Ejemplo:


18

Figura 1 Ejemplo de diagrama de clases (Peinado 2012)

2. Diagrama de casos de uso:

Este diagrama ayuda a representar la forma en como un usuario interactúa con el sistema de desarrollo. De este modo, éstos se emplean para definir los requisitos funcionales del sistema, y todas las etapas del proceso (planificación de las iteraciones, análisis, diseño y pruebas). (García et al. 2007).

Un diagrama de casos de uso consta de los siguientes elementos:

▪ Actor: Se refiere a el rol que jugara el usuario con respecto al sistema. Es decir que no necesariamente está representando a una persona en particular, si no la labor que representa frente al sistema. (Salinas 1996).

▪ Caso de Uso: Operación o tarea que se realiza tras recibir una orden de algún agente externo.(Salinas 1996).

▪ Relaciones: El estándar de UML soporta tres relaciones principales: a. Asociación: Es representado con una flecha continua. Indica que

la clase de actor principal se comunican con el sistema que contiene clases de casos de uso. (Si Alhir 2017).

b. Inclusión: Es utilizada para indicar que las clases de casos de uso base contendrán las clases de casos de uso de inclusión.(Si Alhir 2017).


19

c. Extensión: Es utilizada para indicar que las clases de caso de uso base pueden ser aumentadas por otras clases de uso. (Si Alhir 2017).

Ejemplo:

Figura 2 Ejemplo de diagrama de casos de uso (Ceria 2001).

3. Diagrama de Entidad-Relación:

Es una herramienta para el modelado de datos que permite representar las entidades mas relevantes de un sistema de información, sus propiedad y su forma de interactuar. Son comunmente utilizados para el diseño de bases de datos, solucion de problemas de bases de datos, sistemas de información empresarial, reingeniería de procesos de negocio, educación e investigación.(Lucidchart 2017).

Esta coopuesto por los siguientes elementos:

▪ Entidad: Se puede definir como la representacion de una persona, objeto o concepto del mundo real. Puede ser un objeto con existencia física.(Lucidchart 2017).

▪ Relación: Se refiere a como las entidades interactúan o se asocian entre sí. Son representadas como diamantes o etiquetas directamente en las lineas de conexión. (Lucidchart 2017).

▪ Atributo: Se refiere a una propiedad o caracteristica de una entidad. (Lucidchart 2017)

▪ Cardinalidad: Se refiere a la relación numérica entre dos o más entidades. Las tres más comunes son: uno-uno, uno-mucho y muchos-muchos.(Lucidchart 2017).


20

Ejemplo:

Figura 3 Ejemplo de diagrama de E/R. (Lucidchart 2017).

1.4.2 Bases de datos

En informática una base de datos se define como una colección de datos que se encuentran lógicamente interrelacionados y un conjunto de programas para poder acceder a dichos datos. En términos generales es entonces un conjunto de información relacionada que se encuentra agrupada o estructurada. Estas son muy utilizadas en la ingeniería de software, tanto así que la mayoría de los sitios web dependen de cierto tipo de bases de datos para organizar y presentar los datos a los usuarios. (Gómez 2013).

El conjunto de programas que se utilizan para administrar y procesar los datos de la base se conoce como sistema de gestión de bases de datos (SGBD) o motores de bases de datos. Esta es una herramienta de propósito general que permite crear bases de datos de cualquier tamaño y complejidad. Existen una gran variedad de motores de bases de datos, sin embargo, los más utilizados son: SQL server, MySQL y PostgresSQL. (Gómez 2013).

▪ PostgresSQL: Es un sistema de gestión de datos racional, libre y orientado a objetos. Está programado en C y C++ y es dirigido por una comunidad de


21

desarrolladores que trabajan de forma desinteresada, altruista, libre o apoyados por organizaciones comerciales.

1.4.3 Framework

Consiste en una estructura de software compuesta de elementos personalizables e intercambiables, que permiten el correcto desarrollo de una aplicación. Es decir, son librerías de funciones o clases que proveen el esqueleto o forma a un programa web. Sus objetivos principales son: acelerar el proceso de desarrollo, reutilizar código pre-existente y promover las buenas prácticas de desarrollo. (Gutiérrez 2017).

La arquitectura más utilizada por la mayoría de los framework es la MVC. Este patrón organiza la aplicación en tres modelos separados; El primero es el modelo, el cual es el encargado de representar los datos y su forma de interactuar, el segundo es un conjunto de vistas que representa la entrada y salida de información y el ultimo es el controlador encargado de procesar los datos y dar una estructura al flujo de información. (Gutiérrez 2017)

Figura 4 Patrón MVC (Gutiérrez 2017)

1.4.4 Lenguaje de programación Swift

Swift es un lenguaje de programación intuitivo de uso general diseñado por la marca


22

Apple en el 2014 con un enfoque moderno de seguridad, rendimiento y patrones de diseño de software. Este lenguaje busca a futuro poder llegar a ser la mejor forma de programación para sistemas, aplicaciones móviles y de escritorio. De este modo también pretende llegar a remplazar a los lenguajes basados en C (C, C ++ y Objective-C) y ser el más utilizado tanto en el desarrollo de aplicaciones para IOS, como para Linux o Android (Apple Inc ,2017).

En un principio Swift fue diseñado con el fin de ser una herramienta para el desarrollo de aplicaciones en IOS, Mac, Apple TV y Apple Watch, sin embargo, con el tiempo este lenguaje fue tomando bastante popularidad, debido a que tiene un enfoque bastante moderno y seguro, causando que otros servidores se empezaran a interesar en él. Parte de la gran popularidad de este lenguaje se debe a que también permite la edición de código en tiempo real en Cocoa y Cocoa Touch, los cuales son respectivamente entornos de trabajo para Mac OSX y para IOS. Además, se integra con las herramientas de desarrollo de Xcode incluyendo soporte completo para el sistema de compilación Xcode, finalización de código en el editor y depuración integrada.

Otra gran ventaja que tiene este lenguaje es que requiere una curva de aprendizaje algo menor que otros idiomas, además que cuenta con un gran número de plataformas de ayuda, libros y hasta aplicaciones interactivas para facilitar su correcto aprendizaje. Un ejemplo de esto es la aplicación para iPad “Swift Playgrounds”, la cual ayuda a aprender y explorar la codificación en Swift por medio de lecciones interactivas y desafíos. De este modo es un lenguaje que permite ser utilizado tanto por programadores expertos como por principiantes que apenas están entrando en el mundo de la programación.

1.4.5 Ruby y Rubi on rails: Ruby es un lenguaje de programación orientado a objetos, expresivo y dinámico, creado en 1995 por el japonés Yukihiro Matsumoto con el fin de diseñar un lenguaje que enfatizara más en las necesidades humanas que en las de la computadora. Este combina la sintaxis de los lenguajes previamente existentes Python, Perl y Smalltalk y es usualmente utilizado para el desarrollo de páginas web, desarrollo de aplicaciones móviles, procesar textos o crear videojuegos. Al ser un idioma orientado a objetos, hasta el más mínimo valor es un objeto, lo que permite un manejo más fácil (Flanagan & Matsumoto, 2008).

Ruby on rails es el entorno de trabajo (framework) de código abierto más poderoso y popular. Fue diseñado en el 2003 por David Heinemeier mediante el lenguaje de programación Ruby de tal modo que permitiera de una manera simple y con poco código desarrollar aplicaciones para el mundo real. Este se diferencia de los demás entornos de trabajo existentes pues al ser dogmático asume que existe una forma


23

"mejor" de hacer las cosas, y permite varias alternativas de código, causando que el desarrollo de aplicaciones sea mucho más divertido y productivo. Técnicamente hablando es una biblioteca de software y una API que permite el desarrollo web del lado back-end conocido también como lado del servidor (Williams, 2017).


24

2 ENFOQUE Y METODOLOGÍA

2.1 ETAPA UNO:

Búsqueda sistemática y recolección de información:

Para el correcto desarrollo de este proyecto, es necesario en primer lugar hacer una revisión bibliográfica profunda. Esta búsqueda permitirá adquirir los conocimientos de programación y modelación necesarios para construir la aplicación de manera óptima.

Entre los elementos fundamentales que se deben investigar en la revisión bibliográfica están:

• Analizar las necesidades que tiene la empresa St. Jude Medical Colombia, respecto a el manejo y control de los equipos biomédicos. Para este análisis es importante tener como base los aspectos de la gestión de tecnologías de salud que ayudan a determinar la adquisición de equipos y las necesidades que además tiene el sistema de salud colombiano en este ámbito.

• Estudiar y comprender el lenguaje unificado de modelado UML. Esta información es importante pues ayudara a entender de forma correcta cómo funciona el lenguaje y de qué manera puede ser utilizado en pro del desarrollo del proyecto.

• Investigar sobre los diferentes lenguajes de programación, sus clases, métodos y atributos. Además, realizar una buena búsqueda que permita comprender a la perfección el funcionamiento de estos.

Esta revisión bibliográfica se realizará a través de libros, informes, artículos científicos, trabajos de pregrado, tutoriales, guías y cursos de programación en ruby, ruby on rails, HTML, CSS y Swift y páginas web como GitHub, que brindan una información muy clara para el aprendizaje de estos lenguajes de programación.

2.2 ETAPA DOS:

Establecer por medio del lenguaje de modelación UML una estructura lógica del software:

Para el correcto desarrollo de este objetivo específico es necesario construir al menos tres diferentes diagramas. Estos diagramas se harán a en base a las


25

necesidades de la empresa previamente encontradas. De este modo se tendrá en cuenta cual es el rol que debe tomar cada uno de los usuarios, y dependiendo de este cuales actividades puede realizar dentro de la aplicación y cuales deben tener cierta privacidad. Teniendo en cuenta lo anterior, se realizarán los siguientes tres diagramas:

• Un diagrama de Entidad Relación(E/R) basado en la base de datos que actualmente tiene la empresa

• Un diagrama de clases a partir del diagrama E/R, para conocer los atributos y métodos de las clases.

• Un diagrama de casos de usos, donde se muestre la interacción de los usuarios con la aplicación.

2.3 ETAPA TRES:

Implementar la aplicación:

Tomando como base el diagrama de E/R diseñado en el objetivo anterior, se construirá la base de datos del sistema, la cual consistirá en una serie de modelos, vistas y controladores.

Posteriormente se procederá a implementar la funcionalidad del servidor para consumir la base de datos y exponer una API REST pública.

En primer lugar, se realizará una interfaz de visualización web por medio de HTML, CSS y bootstrap, luego se implementará la aplicación móvil que se comunique con el API REST para consultar y guardar información.

Adicionalmente se probará por medio de datos de prueba el funcionamiento de la aplicación, tanto en el servidor local como en un servidor web.

2.4 ETAPA CUATRO:

Puesta en marcha de la aplicación y seguimiento al funcionamiento:

Para el desarrollo de esta etapa se les proporcionara a los ingenieros de la compañía, el acceso al prototipo de aplicación generado en el objetivo específico anterior, con el fin de que realicen pruebas de funcionamiento, usabilidad y complejidad.


26

Posteriormente se les pedirá que respondan una serie de preguntas plasmadas en una encuesta, las cuales permitirán conocer cuál es el verdadero impacto de la aplicación y saber si efectivamente la aplicación cumple con lo propuesto.


27

3 PRODUCTOS, RESULTADOS Y ENTREGABLES OBTENIDOS

3.1 PRIMER ENTRAGABLE:

Para el desarrollo de este primer entregable se tuvo en cuenta el papel que desempeña cada uno de los ingenieros en la compañía, cuáles son sus funciones y actividades diarias. A partir de esto se determinaron una serie de requerimientos bases para el desarrollo de la aplicación. Estos se plasman en un primer lugar por medio de diagramas diseñados mediante la metodología de UML.

Tabla 1 Primer entregable

PRODUCTO ESPERADO

INDICADOR DE CUMPLIMIENTO

OBSERVACIONES (indique si se logró o no su cumplimiento y por

qué)

ENTREGABLE

Modelo del sistema de base de datos que facilite la futura implementación

Mínimo tres tipos de diagramas diferentes que permitan comprobar el funcionamiento del software

A partir de la metodología UML se logró el diseño de los siguientes diagramas:

• Diagrama E/R • Diagrama de Clases • Diagrama casos de

uso

Diagramas del software en UML


28

3.1.1 Diagrama de Entidad-Relación:

Figura 4 Diagrama Entidad Relación


29

3.1.2 Diagrama de clases:

Figura 5 Diagrama de clases

3.1.3 Casos de uso:

Este diagrama permite representar la forma en como los usuarios interactuaran con la aplicación, según sus roles o funciones. Adicionalmente permite ordenar de forma coherente las funciones que realizara la aplicación y sus posibles resultados. (Rumbaugh et al. 1999)

Para el desarrollo de este diagrama, en primer lugar, se definieron los actores del sistema, los cuales para el correcto desarrollo de este trabajo fueron los siguientes:


30

Figura 6 Actores del sistema

• Usuario ingeniero: Este tiene acceso limitado a la base de datos. Este puede

agregar, modificar o eliminar contenido de los reportes de servicio de mantenimiento, de los cronogramas y de su propio perfil, sin embargo, tendrá el papel de espectador en los demás aspectos de la aplicación.

• Usuario Editor: Este usuario es el encargado de la actualización continua de la base de datos, debe revisar constantemente que los datos agregados por los dos anteriores usuarios si sean los correctos. Este tiene accesos a la edición de todas las tablas de la base de datos, sin embargo, no debe encargarse de añadir nuevas.

• Usuario Administrador: Este tiene acceso ilimitado a toda la base de datos. Es el encargado de editar, crear o eliminar los usuarios, tipos de equipo, instituciones y herramientas de medición. Adicionalmente posee los mismos accesos que un usuario tradicional, es decir posee un doble rol.

Las funciones de gestión que realizaran estos usuarios, se definieron mediante el siguiente diagrama de casos de usos, teniendo en cuenta que de cada una de los ítems se desprenden funciones específicas, las cuáles serán mencionadas posteriormente.


31

Figura 7 Casos de uso Este diagrama muestra de forma general las fundiciones que podrá desarrollar cada

usuario en la aplicación, sin embargo, vale la pena aclarar que cada función de

gestión tiene una gran cantidad de sub-funciones, por lo que puede ocurrir que un

usuario no realice de manera completa los casos de uso mencionados en este

diagrama.

A continuación, se describen a mayor detalla casa uno de los casos de uso:

• Gestión de equipos:


32

Figura 8 Gestión de equipos

NOMBRE Gestionar los equipos

ACTORES Gerente Practicante Ingeniero

DESCRIPCIÓN Permite administrar los equipos con sus accesorios y movimientos

PRECONDICIONES Iniciar sesión

Tabla 2 Gestionar los equipos


33

NOMBRE Crear equipo

ACTORES Gerente Ingeniero

DESCRIPCIÓN Permite crear un equipo


FLUJO NORMAL 1. El usuario hace clic en el icono de “Nuevo Equipos”

2. El usuario dirigencia el formulario con la información del equipo y accesorios

3. El usuario hace clic en “Guardar” 4. La información es almacenada

FLUJO ALTERNATIVO

1. El usuario hace clic en el icono de “Nuevo Equipos”

2. El usuario diligenciar el formulario con la información del equipo y accesorios

3. El usuario hace clic en “Guardar” 4. El sistema no permite almacenar la

información por error en el formulario diligenciado.

5. El sistema notifica al usuario del error

Tabla 3 Crear un equipo

NOMBRE Eliminar equipo

ACTORES Gerente, Ingeniero

DESCRIPCIÓN Permite eliminar un equipo, sus accesorios y movimientos existentes


34


FLUJO NORMAL 1. El usuario selecciona el equipo 2. Clic en “Eliminar equipo” 3. El sistema muestra mensaje de confirmación 4. El sistema elimina el equipo y sus accesorios

y movimientos relacionados

FLUJO ALTERNATIVO

1. El usuario selecciona el equipo 2. Clic en “Eliminar equipo” 3. El sistema encuentra que el usuario no tiene

permiso para realizar esta acción.

POSCONDICIONES Tipo de equipo seleccionado eliminado

Tabla 4 Eliminar equipo


35

Tabla 5 Editar equipo

NOMBRE Editar equipo

ACTORES Gerente, Ingeniero, Practicante

DESCRIPCIÓN Permite editar un equipo existente


FLUJO NORMAL 1. El usuario selecciona el equipo 2. Clic en el icono de “Editar” 3. El usuario edita información en el formulario

de equipo y de ser necesario agrega un movimiento o accesorio

4. El sistema valida la información y la almacena

FLUJO ALTERNATIVO

1. El usuario selecciona el tipo de equipo 2. Clic en el icono de “Editar” 3. El usuario edita información en el formulario

de equipo y de ser necesario agrega un movimiento o accesorio

4. El sistema valida la información ingresada y al no ser correcta le notifica al usuario para realizar correcciones

POSCONDICIONES Información de un equipo actualizada

NOMBRE Ver equipo, accesorios y movimientos


DESCRIPCIÓN Permite ver la información de un equipo existente


FLUJO NORMAL 1. El usuario selecciona el tipo de equipo 2. Clic en “Ver Info” 3. El sistema carga los datos existentes


36

Tabla 6 Ver equipo

Tabla 7 Listar equipos

• Gestión de tipo de equipos:

FLUJO ALTERNATIVO

No Aplica

POSCONDICIONES No Aplica

NOMBRE Listar los equipos


DESCRIPCIÓN Permite observar todos los equipos existentes


FLUJO NORMAL 1. El usuario hace Clic en el icono de “Buscar equipo”

2. El sistema carga los datos existentes

FLUJO ALTERNATIVO

No Aplica



37

Figura 9 Gestión de tipos de equipos

NOMBRE Gestionar los tipos de equipos


DESCRIPCIÓN Permite administrar los tipos de equipo


Tabla 8 Gestionar tipos de equipo

NOMBRE Crear tipo de equipo


38

ACTORES Gerente

DESCRIPCIÓN Permite crear un nuevo tipo de equipo


FLUJO NORMAL 1. El usuario se dirige al link de Tipo de Equipos

2. El usuario hace clic en “crear tipo de equipo”

3. El usuario dirigencia el formulario con la información del equipo

4. El usuario hace clic en “Guardar tipo de equipo”

5. La información es almacenada

FLUJO ALTERNATIVO

1. El usuario se dirige al link de Tipos de Equipos

2. El usuario hace clic en “crear tipo de equipo”

3. El usuario diligenciar el formulario con la información

4. El usuario hace clic en “Guardar tipo de equipo”

5. El sistema no permite almacenar la información por error en el formulario diligenciado.


Tabla 9 Crear tipo de equipo

NOMBRE Eliminar tipo de equipo

ACTORES Gerente, Practicante


39

DESCRIPCIÓN Permite eliminar un tipo de equipo existente


FLUJO NORMAL 1. El usuario selecciona el tipo de equipo 2. Clic en “Eliminar tipo de equipo” 3. El sistema muestra mensaje de

confirmación 4. El sistema elimina el tipo de equipo

seleccionado

FLUJO ALTERNATIVO

1. El usuario selecciona el tipo de equipo 2. Clic en “Eliminar tipo de equipo” 3. El sistema encuentra que el usuario no

tiene permiso para realizar esta acción.

POSCONDICIONES Tipo de equipo seleccionado eliminado

Tabla 10 Eliminar tipo de equipo

NOMBRE Listar tipo de equipo


DESCRIPCIÓN Permite observar todos los tipos de equipo existentes


FLUJO NORMAL 3. El usuario hace Clic en el icono de “Tipos de equipo”



40

Tabla 11 Listar tipo de equipo

Tabla 12 Editar tipo de equipo

FLUJO ALTERNATIVO

No Aplica


NOMBRE Editar tipo de equipo

ACTORES Gerente

DESCRIPCIÓN Permite editar un tipo de equipo existente


FLUJO NORMAL 1. El usuario selecciona el tipo de equipo 2. Clic en el icono de “Editar” 3. El usuario edita información en el

formulario de tipo de equipo 4. El sistema valida la información y la

almacena

FLUJO ALTERNATIVO

1. El usuario selecciona el tipo de equipo 2. Clic en el icono de “Editar” 3. El usuario edita información en el

formulario 4. El sistema valida la información

ingresada y al no ser correcta le notifica al usuario para realizar correcciones

POSCONDICIONES Información de un tipo de equipo actualizada


41

Tabla 13 Ver tipo de equipo

• Gestióndeinstituciones:

NOMBRE Ver tipo de equipo


DESCRIPCIÓN Permite ver la información un tipo de equipo existente


FLUJO NORMAL 1. El usuario selecciona el tipo de equipo 2. Clic en “Ver Info” 3. El sistema carga los datos existentes

FLUJO ALTERNATIVO

No Aplica



42

Figura 10 Gestión de Instituciones

NOMBRE Gestionar las instituciones


DESCRIPCIÓN Permite administrar las instituciones


Tabla 14 Gestionar Instituciones

NOMBRE Crear una institución


DESCRIPCIÓN Permite crear una nueva institución


FLUJO NORMAL 1. El usuario hace clic en “Nueva Institución” 2. El usuario diligencia el formulario 3. El usuario hace clic en “Guardar” 4. El sistema almacena la información

correctamente

FLUJO ALTERNATIVO

1. El usuario hace clic en “Nueva Institución” 2. El usuario diligencia el formulario 3. El usuario hace clic en “Guardar” 4. El sistema no permite almacenar la




43

POSCONDICIONES Nueva institución agregada al sistema

Tabla 15 Crear una Institución

ACTORES Gerente, Practicante

DESCRIPCIÓN Permite eliminar una institución existente


FLUJO NORMAL 1. El usuario selecciona la institución 2. El usuario hace clic en eliminar 3. El sistema elimina la institución

FLUJO ALTERNATIVO

No aplica

POSCONDICIONES Una institución es eliminada

Tabla 16 Eliminar una Institución

ACTORES Gerente, Practicante; Ingeniero

DESCRIPCIÓN Permite editar una institución existente


FLUJO NORMAL 1. El usuario selecciona la institución y hace clic en “editar”

2. El usuario modifica la información en el formulario

3. El sistema valida la información ingresada y la almacena

FLUJO ALTERNATIVO

1. El usuario selecciona la institución y hace clic en “editar”

2. El usuario modifica la información en el


44

formulario 3. El sistema valida la información ingresada y

al no ser correcta le notifica al usuario para realizar correcciones

POSCONDICIONES La información de una institución es editada

Tabla 17 Editar una Institución

ACTORES Gerente, Practicante, ingeniero

DESCRIPCIÓN Permite ver una lista de las instituciones


FLUJO NORMAL 1. El usuario hace clic en “Listar instituciones” 2. El sistema muestra una lista de todas las

instituciones

FLUJO ALTERNATIVO

No Aplica


Tabla 18 Listar Instituciones

ACTORES Gerente, ingeniero, Practicante

DESCRIPCIÓN Permite ver los equipos que hay en una institución


FLUJO NORMAL 1. El usuario selecciona la institución 2. El usuario hace clic en “Ver Equipos” 3. El sistema muestra todos los equipos que


45

posee la institución

FLUJO ALTERNATIVO

No Aplica


Tabla 19 Ver Institución

• GestióndeHerramientasdemedición:

Figura 11 Gestión de Herramientas de medición

NOMBRE Gestionar las herramientas de medición

ACTORES Gerente Ingeniero


46

Practicante

DESCRIPCIÓN Permite administrar las herramientas de medición


Tabla 20 Gestionar Herramientas de medición

NOMBRE Crear Herramienta de medición

ACTORES Gerente

DESCRIPCIÓN Permite crear una nueva institución


FLUJO NORMAL 1. El usuario hace clic en “Nueva Herramienta de medición”

2. El usuario diligencia el formulario 3. El usuario hace clic en “Guardar” 4. El sistema almacena la información

correctamente

FLUJO ALTERNATIVO

1. El usuario hace clic en “Nueva Herramienta de medición”

2. El usuario diligencia el formulario 3. El usuario hace clic en “Guardar” 4. El sistema no permite almacenar la



POSCONDICIONES Nueva Herramienta de medición agregada al sistema

Tabla 21 Crear Herramienta de medición


47

ACTORES Gerente

DESCRIPCIÓN Permite eliminar una Herramienta de medición existente


FLUJO NORMAL 1. El usuario selecciona la Herramienta 2. El usuario hace clic en “eliminar” 3. El sistema elimina la Herramienta

FLUJO ALTERNATIVO

No aplica

POSCONDICIONES Una Herramienta de medición es eliminada

Tabla 22 Eliminar Herramienta de medición


DESCRIPCIÓN Permite listar los datos de las herramientas de medición


FLUJO NORMAL 1. El usuario hace clic en Herramienta de medición

2. El sistema muestra el formulario con la información

FLUJO ALTERNATIVO

No Aplica


Tabla 23 Listar Herramientas de medición


48


DESCRIPCIÓN Permite editar una herramienta existente


FLUJO NORMAL 1. El usuario selecciona la herramienta y hace clic en “editar”



FLUJO ALTERNATIVO

1. El usuario selecciona la herramienta y hace clic en “editar”



POSCONDICIONES La información de una institución es editada

Tabla 24 Editar Herramienta de medición

• GestióndeReportesdeservicio:


49

Figura 12 Gestión de Reportes de servicio

NOMBRE Gestionar los reportes de servicio


DESCRIPCIÓN Permite administrar los reportes de servició


Tabla 25 Gestionar reportes de servicio

NOMBRE Crear Reportes de servicio


50


DESCRIPCIÓN Permite crear un nuevo reporte de servicio


FLUJO NORMAL 1. El usuario hace clic en el icono de “Nuevo reporte de servicio”


correctamente

FLUJO ALTERNATIVO

1. El usuario hace clic en el icono de “Nuevo reporte de servicio”




POSCONDICIONES Nuevo Reporte de servicio es agregado al sistema

Tabla 26 Crear reporte de servicio

NOMBRE Ver un Reportes de servicio


DESCRIPCIÓN Permite ver información de un reporte de servicio



51

FLUJO NORMAL 1. El usuario hace clic en el icono de “Buscar reporte de servicio”

2. El usuario entra en el buscador el OS del reporte que deseado

3. El sistema carga el reporte y el usuario hace clic en “ver info”

4. El sistema carga la información del reporte seleccionado

FLUJO ALTERNATIVO

No aplica

POSCONDICIONES No aplica

Tabla 27 Ver reporte de servicio

Tabla 28 Eliminar reporte de servicio

NOMBRE Eliminar Reporte de servicio


DESCRIPCIÓN Permite crear un nuevo reporte de servicio


FLUJO NORMAL 1. El usuario selecciona el reporte de servicio por su OS

2. El usuario hace clic en el icono de “eliminar” 3. El sistema elimina el reporte de servicio

FLUJO ALTERNATIVO

No Aplica

POSCONDICIONES Reporte de servicio eliminado de la base de datos


52

NOMBRE Editar Reportes de servicio


DESCRIPCIÓN Permite modificar un reporte de servicio existente


FLUJO NORMAL 1. El usuario selecciona el reporte de servicio por medio de su OS y hace clic en “editar”



FLUJO ALTERNATIVO

1. El usuario selecciona el reporte de servicio por medio de su OS y hace clic en “editar”



POSCONDICIONES Información de un reporte de servicio editada

Tabla 29 Editar reporte de servicio

NOMBRE Listar Reportes de servicio


DESCRIPCIÓN Permite observar todos los reportes de servicio existentes



53

Tabla 30 Listar reportes de servicio

NOMBRE Imprimir Reportes de servicio


DESCRIPCIÓN Permite imprimir un reporte de servicio en formato PDF


FLUJO NORMAL 1. El usuario entra en el buscador el OS del reporte que deseado

2. El usuario hace clic en el botón de “más info” y luego en “imprimir”

3. El sistema genera un documento en formato PDF con la información del reporte deseado

FLUJO ALTERNATIVO

No Aplica


Tabla 31 Imprimir reporte de servicio

FLUJO NORMAL 1. El usuario hace Clic en el icono de “Buscar Reporte”


FLUJO ALTERNATIVO

No Aplica



54

• GestióndelCronogramadeeventos:

Figura 13 Gestión del cronograma

NOMBRE Gestionar el cronograma


DESCRIPCIÓN Permite administrar los eventos del cronograma


Tabla 32 Gestionar el cronograma

NOMBRE Crear un evento


55


DESCRIPCIÓN Permite crear un nuevo evento en el cronograma


FLUJO NORMAL 1. El usuario hace clic en el icono de” Nuevo” en cronograma


correctamente

FLUJO ALTERNATIVO

1. El usuario hace clic en el icono de” Nuevo” en cronograma




POSCONDICIONES Nuevo evento es agregado al cronograma

Tabla 33 Crear nuevo evento en el cronograma

NOMBRE Ver los eventos


DESCRIPCIÓN Permite ver los eventos en el cronograma



56

FLUJO NORMAL 1. El usuario hace clic en el icono de “Ver cronograma”

2. El sistema carga el cronograma por meses

FLUJO ALTERNATIVO

No aplica

POSCONDICIONES No aplica

Tabla 34 Ver los eventos del cronograma

NOMBRE Editar un evento


DESCRIPCIÓN Permite modificar un evento existente


FLUJO NORMAL 1. El usuario selecciona el evento 2. El usuario modifica la información en el

formulario 3. El sistema valida la información ingresada

y la almacena

FLUJO ALTERNATIVO

1. El usuario selecciona el evento 2. El usuario modifica la información en el

formulario 3. El sistema valida la información ingresada

y al no ser correcta le notifica al usuario para realizar correcciones

POSCONDICIONES Información de un evento es editada

Tabla 35 Editar evento del cronograma


57

3.2 SEGUNDO ENTRAGABLE:

Este entregable consiste en una aplicación web y móvil realizada en Ruby on Rails y Swift. Esta aplicación trabaja mediante una serie de peticiones realizadas a un servidor, el cual de acuerdo con el tipo de entrada y los permisos retorna una respuesta final al usuario.

Tabla 36 Segundo entregable

3.2.1 Modelos y relaciones: En primer lugar, se crearon los modelos necesarios para el control y el almacenamiento de datos. Estos se hicieron a partir de los diagramas diseñados en el entregable anterior y teniendo en cuenta las tablas asociadas. Los modelos son los siguientes:

• Usuario • Tipo_de_equipo • Reportes_de_servicio • Institución • Herramientas_medicion • Equipo • Historial • Crono_mantenimiento

PRODUCTO ESPERADO


OBSERVACIONES (indique si se logró o no su cumplimiento y

por qué)

ENTREGABLE

Aplicación móvil que ayude a disminuir el tiempo de respuesta a clientes, gracias a que permite un mejor manejo de la información.

Una aplicación móvil para IOS que permita reducir tiempo de búsqueda y aumentar la productividad de los ingenieros.

A partir del primer entregable se logró el correcto diseño de una aplicación móvil programada en Ruby on rails y Swift.

Aplicación web y para Celular IOS operando.


58

• Accesorio

Estos modelos están asociados a las tablas descritas en el primer entregable, es decir que poseen como atributos todos los descritos en el diagrama de Entidad-Relación.

Ruby on Rails permite crear los modelos de manera fácil e intuitiva mediante migraciones, las cuales son las encargadas de cambiar el esquema de la base de datos a través del tiempo, es decir un esquema que comienza vacío, empieza a llenarse con cada migración, modificando, añadiendo o eliminando tablas. Por ejemplo, ejecutando: $ rails generate model Equipo remisión:text serie:text fecha_instalacion:date garantía:boolean Se generó el modelo y las migraciones correspondientes a la tabla de Equipos.

Una vez generados todos los modelos, se prosiguió con la generación de todas las relaciones existentes entre modelos. Este paso se realizó en base a lo planteado en el diagrama de Entidad-relación. Esto permitió, en términos generales, utilizar los atributos de una tabla especifica en otra. Estas relaciones también se generan por medio de migraciones, las cuales fueron las siguientes:

MODELO TIENE UNO O MUCHOS:

PERTENECE A:

Equipo • Accesorios • Reportes de

servicio • Historiales

• Tipo de equipos

Accesorios N/A • Equipo

Cronograma de mantenimiento

N/A • Institución • Usuario

Historial N/A • Equipo • Institución


59

Tabla 37 Relaciones entre modelos

3.2.2 Validación de usuarios e inicio de sesión:

Cada uno de los ingenieros de St. Jude Medical puede iniciar sesión en la aplicación y de este modo acceder a todas las funciones que esta posee, por medio del email que brinda la compañía y una contraseña. El sistema valida que estos datos efectivamente existan en la tabla de usuarios y que su sintaxis sea la correcta. En caso de que no sea así, el sistema mostrara un mensaje notificando al usuario de la aparición de un error.

Institución • Historiales • Cronograma de

mantenimiento

N/A

Reportes de servicio N/A • Equipo • Usuario

Tipo de Equipo • Equipos N/A

Usuario • Reportes de servicio

• Cronograma de mantenimiento

N/A


60

Figura 14 Inicio de sesión

Para ingresa un nuevo ingeniero a la tabla de usuarios, existe un formulario en el cual se ingresan determinados datos. Este formulario posee un acceso restringido, de tal modo que únicamente el usuario con rol de gerente puede agregar un nuevo ingeniero. Esto se realiza con el fin de dar mayor protección a los datos almacenados, y así poder garantizar que únicamente trabajadores autorizados podrán tener una cuenta en la aplicación.


61

Figura 15 Crear nuevo usuario

La aplicación permite a cada usuario acceder a su información personal, de tal modo que pueden agregar, editar y eliminar nuevos datos. Además, sin importar el rol en la aplicación, los usuarios pueden ver determinada información de los demás usuarios. Sin embargo, únicamente el usuario con rol de gerente puede editar y borrar la información de los demás ingenieros.

Figura 16 Lista de usuarios


62

Para mayor seguridad la aplicación cuenta con un método que permite encriptar la contraseña de cada usuario una vez es ingresada. Es decir, la base de datos almacena no almacena como tal la contraseña de cada usuario, si no una versión encriptada de esto. Por otro lado, cuando un usuario olvida su contraseña, podrá recuperarla por medio de un formulario de recuperación de contraseña. Para acceder a este formulario, en primer lugar, el usuario debe hacer clic en el link en “He olvidado mi contraseña”, donde se le pedirá que ingrese su correo electrónico. Acto seguido, el sistema valida el correo ingresado y verifica si efectivamente está almacenado en la base de datos. En el caso afirmativo, el sistema le enviara al usuario vía email el link del formulario de recuperación de contraseña.

Figura 17 Formulario de petición para recuperar contraseña

Figura 18 Contraseña nueva


63

3.2.3 Gestión de equipos y accesorios:

La gestión de equipos es uno de los aspectos más importantes para la empresa St. Jude Medical. Es por esto, que la aplicación cuenta con diversas funciones, formularios y tablas que permiten a los ingenieros ingresar, buscar y editar la información de cada uno de los equipos de una manera rápida y eficiente.

Respecto al modelo de “tipo de equipos” únicamente el usuario con rol de “Gerente” puede agregar uno nuevo a la tabla, editarlo y borrarlo. Sin embargo, los demás usuarios pueden utilizar esta información y visualizarla en el modelo general de Equipos.

Figura 19 Listar tipos de equipos

Todos los usuarios, sin importar su rol, pueden ingresar la información de un nuevo equipo por medio de un formulario. En este formulario se ingresa diversa información perteneciente tanto a la tabla de equipos, como a las tablas con las que se ve relacionado. De este modo el usuario además de ingresar información como: serie y fecha de ingreso, tiene la posibilidad de escoger la institución, el tipo de equipo e ingresar los accesorios relacionados.


64

Figura 20 Agregar un nuevo equipo

Todos los usuarios pueden acceder desde la página de inicio, al “índex” de la tabla de equipos. En este link se encuentra una barra de búsqueda que permite encontrar un equipo por medio de su serie, además de que se ven relacionadas las acciones de: Imprimir, editar y borrar.


65

Figura 21 Búsqueda de equipos

Para la compañía es muy importante conocer y almacenar la trayectoria que ha tenido cada equipo, es por esto que los usuarios pueden, además de editar la información de los equipos, agregar un nuevo historial, es decir que pueden mover de institución el equipo las veces que deseen, pues estos movimientos quedaran guardados en la base de datos por medio de la tabla “Historial”.

En la sección “imprimir” se puede ver un formulario en formato PDF con la información más relevante para cada equipo, el cual puede ser impreso y entregado al cliente de ser necesario.

3.2.4 Gestión las instituciones: De manera muy similar a la gestión de equipos, los usuarios tienen la posibilidad de crear, editar, buscar e imprimir la información de las instituciones prestadoras de servicios de salud que tienen algún tipo de contrato o convenio con St. Jude Medical.

Para crear una nueva institución existe un formulario, al cual pueden acceder desde la página de inicio de manera rápida y fácil. En este formulario se agrega la


66

información básica, como nombre, ciudad, dirección y teléfono.

Figura 22 Agregar una nueva institución Cuando el usuario accede al “índex” de la tabla, puede buscar una institución por su nombre o ciudad. En esta pantalla también se listan las funciones de ver, editar y borrar las instituciones.


67

Figura 23 Búsqueda de instituciones Mediante la opción de “mas info” el usuario tiene la posibilidad de ver todos los equipos que actualmente se encuentran en la institución y su fecha de ingreso a ella. Adicionalmente tienen la posibilidad de imprimir o guardar esta información por medio de un formulario en formato PDF.

3.2.5 Eventos y cronograma:

La aplicación cuenta con un calendario, donde todo tipo de usuario tiene la posibilidad de agregar un nuevo evento, ya sea un procedimiento, un mantenimiento, una instalación o una consulta. Este cronograma busca garantizar el correcto control de todas las actividades que realizan los ingenieros, de tal modo que todas sean cumplidas a tiempo y de manera oportuna.

Para la creación de un nuevo evento, se le pide al usuario que llene ciertos capos de un formulario, con una breve descripción, la fecha de inicio y la fecha de fin de la actividad.


68

Figura 24 Cronograma

3.2.6 Reportes de servicio técnico:

Cuando los ingenieros de la compañía realizan un mantenimiento preventivo, correctivo o una instalación de un equipo, es necesario para el sistema colombiano generar una constancia de lo realizado por medio de un reporte, el cual debe ser firmado tanto por la institución responsable como por el ingeniero que realizo la actividad. Para agilizar y mejorar este proceso la aplicación cuenta con un formulario donde los usuarios pueden ingresar de manera fácil y rápida lo realizado durante la intervención. Esta información queda almacenada en el sistema, para que posteriormente pueda ser consultada de forma fácil por los demás usuarios.


69

Figura 25 Agregar reporte de servicio

En la ventada de inicio de esta tabla, se encuentre una barra de búsqueda, para filtrar un reporte según se necesite. De igual forma que con los equipos, el usuario puede seleccionar el reporte e imprimir su información en formato PDF. Esto busca agilizar el proceso de entrega al cliente y la firma.


70

Figura 26 Búsqueda de reportes de servicio

3.2.7 Implementación en el servidor: En primer lugar, la aplicación se desarrolló en el local Host, por medio de vistas en HTML. Posteriormente se decidió alojar en Heroku, la cual es una plataforma como servicio de computación en la nube. Esto se hizo para poder acceder a la app desde cualquier computador, y así poner a prueba el verdadero funcionamiento de esta. Heroku permite realizar un gran número de funciones y actividades, sin embargo, lo que se busca en un futuro es montar la aplicación en el servidor que maneja la empresa, pues de este modo se garantiza una verdadera seguridad.

Adicionalmente la aplicación fue montada en la “App Store” de Apple, para que los usuarios pudieran descargarla en sus celulares.

3.3 TERCER ENTRAGABLE:

Este entregable consiste en una encuesta con una serie de preguntas, que tienen como fin evaluar el prototipo de aplicación, su modo de operación y la percepción de los ingenieros sobre esta.


71

Tabla 38 Tercer entregable

Para el desarrollo de la encuesta se usó la herramienta de diseño que brinda “Survey monkey”, pues es bastante intuitiva, de fácil manejo y brinda una interfaz bastante agradable a los usuarios. Adicionalmente esta herramienta brinda gratuitamente un análisis estadístico a las respuestas de los usuarios por medio de diversas gráficas y diagramas.

La encuesta se envió a los nueve ingenieros que hacen parte de la compañía en Colombia. Sin embargo, únicamente seis dieron una respuesta oportuna a la encuesta, por cuestiones de tiempo y trabajo.

Se plantearon cinco preguntas bastante básicas y cerradas y una abierta para sugerencias (ver anexo 1). Los resultados obtenidos se representan mediante graficas de la siguiente forma:

1. ¿Cuál es su opinión respecto a una nueva base de datos?

PRODUCTO ESPERADO


OBSERVACIONES (indique si se logró o no su cumplimiento y

por qué)

ENTREGABLE

Datos estadísticos que permitan identificar el éxito de la aplicación móvil.

Respuesta positiva frente a la aplicación por al menos el 70% de los ingenieros de la empresa.

Mediante la puesta en marcha de la aplicación y la realización de una encuesta se logró cumplir con el objetivo.

Una encuesta que se puede visualizar en Anexo 1.


72

Figura 27 Pregunta nº1 de la encuesta Para esta pregunta se dieron tres opciones de respuesta. Ninguno de los seis ingenieros que respondieron la encuesta decidió omitir esta pregunta, además todos opinan que es una buena idea el desarrollo de una nueva base de datos.

2. ¿Cuál es su primera impresión al ver la nueva aplicación?

Figura 28 Pregunta nº2 de la encuesta

Al igual que la anterior todos los encuestados respondieron la pregunta. Cinco de ellos opinan que a primera vista la aplicación es bonita y creativa, y


73

tan solo uno opina que la aplicación esta algo simple. 3. Estéticamente, ¿Como califica la app? (5: Muy Linda; 1: Muy Fea)

Figura 29 Pregunta nº3 de la encuesta En esta pregunta los encuestados debían calificar de 1 a 5 (siendo 5 muy linda y 1 muy fea) la parte estética de la aplicación. Tres de los encuestados le dieron una calificación de 4, los otros 3 le dieron una calificación de 5, dando así un promedio ponderado de 4,5.

4. Respecto al funcionamiento, ¿Como califica la app? (5: corre rápido y sin problemas; 1: no funciona)

Figura 30 Pregunta nº4 de la encuesta En esta pregunta los encuestados debían calificar de 1 a 5 (siendo 5 respuesta rápida y 1 no funciona) la parte funcional de la aplicación. Dos de


74

los encuestados le dieron una calificación de 4, los otros 4 le dieron una calificación de 5, dando así un promedio ponderado de 4,67.

5. ¿Cree que la implementación de la nueva base de datos puede ayudar a mejorar el control de los equipos?

Figura 31 Pregunta nº5 de la encuesta El 100% de los encuestados opina que el control de los equipos efectivamente mejorara si se implementa una nueva base de datos.

6. ¿Que sugerencias tienes? Esta pregunta tenía un carácter más opcional por lo que fue omitida por tres de los entrevistados, los otros respondieron lo siguiente:

• Implementar una función que permita crear los reportes de servicio por institución y no por equipo.

• Revisar el control de usuarios para el ingreso • Realizar remisiones desde la app


75

4 CONCLUSIONES Y RECOMENDACIONES

Durante el desarrollo de este proyecto se adquirieron una gran cantidad de nuevos conocimientos y utilizaron algunos otros adquiridos durante los diez semestres de ingeniería biomédica. De este modo, los conocimientos adquiridos sobre gestión de tecnologías en salud y en programación orientada a objetos, permitieron la realización de este primer prototipo de una manera óptima, ordenada y rápida.

El lenguaje de modelado unificado UML permitió desarrollar de una manera simple, ordenada y didáctica la estructura lógica de la aplicación, de tal modo que por medio de diagramas se definieron las clases, funciones, atributos y los autores del sistema.

Se logró el diseño de un primer prototipo de una aplicación tanto móvil como web que además de hacer las funciones de la base de datos anterior de una forma más ordenada, contiene nuevas herramientas que permiten consultar y administrar la información de una forma ordenada.

Gracias a la implementación de una encuesta se logró identificar que la respuesta de los ingenieros de la compañía frente a una nueva base de datos es bastante positiva, sin embargo, son conscientes que es el primer prototipo y que requiere una serie de mejoras, especialmente en la parte estética.

La empresa St. Jude Medical brindo las herramientas y los recursos necesarios para el correcto desarrollo de la aplicación. Adicionalmente el apoyo y la ayuda que brindaron los ingenieros del área fue un motivador para seguir adelante con el proyecto.

Una base de datos de este tamaño requiere de un mantenimiento continuo, por lo que se recomienda capacitar a alguno de los empleados en este tema o contratar personal ya entrenado. Adicionalmente, para que esta aplicación sea completamente funcional, se debe seguir con el proyecto tomando en cuenta las sugerencias hechas por los usuarios y migrando todos los datos previamente existentes en la base de datos anterior.

Para trabajos futuros se sugiere implementar una interfaz de usuario más amigable, de tal modo que cualquier tipo de usuario sin importar su edad o su empatía con la tecnología pueda hacer uso de esta. Por otro lado, en un futuro se debe pensar en un mecanismo de lectura de códigos QR, que permita al usuario acceder a la información de los equipos de una forma más rápida. También se sugiere implementar la app en dispositivos Android para que los usuarios también puedan instalarla en sus celulares personales de ser el caso de necesitarla.


76

REFERENCIAS

Abbott. 2016. “2016 ANNUAL REPORT.” 80.

Barcia, Diego. 2003. “¿Qué Es CSS?” Retrieved September 20, 2017 (http://www.maestrosdelweb.com/introcss/).

Ceria, Santiago. 2001. Ingeniería de Software I.

Colombia, St Jude. 2017. “Access.”

García, Jesús, M.Jos. Ortín, Begoña Moros, Joaquín Nicolás, and Ambrosio Tova. 2007. “De Los Procesos Del Negocio a Los Casos de Uso.” Cyta 6(4).

Garrido, Manuel Fandos. 2003. “Formación Basada En Las Tecnologías de La Información Y Comunicación: Análisis Didáctico Del Proceso de Enseñanza-Aprendizaje.” Universitat Rovira I Virgili.

Gómez, María del Carmen. 2013. Bases de Datos. 1st ed. México D.F: Universidad Autónoma Metropolitana.

Gutiérrez, Javier J. 2017. “¿Qué Es Un Framework Web?” Retrieved (http://www.lsi.us.es/~javierj/investigacion_ficheros/Framework.pdf).

Lucidchart. 2017. “Qué Es Un Diagrama Entidad-Relación.” Retrieved June 30, 2017 (https://www.lucidchart.com/pages/es/qué-es-un-diagrama-entidad-relación#).

Marqués, Asier. 2013. “Conceptos Sobre APIs REST.” Retrieved September 11, 2017 (http://asiermarques.com/2013/conceptos-sobre-apis-rest/).

Medical, St.Jude. 2016. Anual Report. Minnesota.

Peinado, Mauricio. 2012. “UML.” Retrieved March 10, 2017 (http://www.mauriciomatamala.net/ED/uml.php).

Rumbaugh, J., I. Jacobson, and G. Booch. 1999. El Lenguaje Unificado de Modelado. Retrieved (http://portal.acm.org/citation.cfm?id=993859&dl=).

Salinas, Patricio (Universidad de chile). 1996. “Modelo de Clases.” Retrieved July 29, 2017 (https://users.dcc.uchile.cl/~psalinas/uml/modelo.html).

Schildt, Herbert. 2009. “Objetos.” in Java: Manual de referencia. Mexico.


77

Si Alhir, Sinan. 2017. “Understanding Use Case Modeling.” Methods & Tools 3. Retrieved (http://www.methodsandtools.com/archive/archive.php?id=24).

StJudeMedical. 2017. “Company History.” Retrieved March 15, 2017 (https://www.sjm.com/en/about/company-facts/history).


78

ANEXO 1


79

Documents

PLATAFORMA MÓVIL PARA EL MANEJO Y EL DE LOS EQUIPOS