implementaciÓn de un sistema de asignaciÓn de … · planteamiento del problema 16 2. marco...

IMPLEMENTACIÓN DE UN SISTEMA DE ASIGNACIÓN DE PACIENTES PARA EL ÁREA DE DMO (DIAGNÓSTICO MÉDICO OCUPACIONAL) DE LA

EMPRESA UNIDAD DE SALUD OCUPACIONAL (USO) S.A.S

CAMILO ERNESTO BALANTA TORRES CÓDIGO: 2126981

UNIVERSIDAD AUTÓNOMA DE OCCIDENTE FACULTAD DE INGENIERÍA

DEPARTAMENTO DE OPERACIONES Y SISTEMAS PROGRAMA INGENIERÍA INFORMÁTICA

SANTIAGO DE CALI 2018

IMPLEMENTACIÓN DE UN SISTEMA DE ASIGNACIÓN DE PACIENTES PARA EL ÁREA DE DMO (DIAGNÓSTICO MÉDICO OCUPACIONAL) DE LA

EMPRESA UNIDAD DE SALUD OCUPACIONAL (USO) S.A.S

CAMILO ERNESTO BALANTA TORRES

PASANTÍA INSTITUCIONAL para optar al título de Ingeniero en Informática

Director JESÚS ANTONIO LEMOS BENAVIDES Maestría en Ciencias computacionales

UNIVERSIDAD AUTÓNOMA DE OCCIDENTE FACULTAD DE INGENIERÍA

DEPARTAMENTO DE OPERACIONES Y SISTEMAS PROGRAMA INGENIERÍA INFORMÁTICA

SANTIAGO DE CALI 2018

3

Nota de aceptación:

Aprobado por el Comité de Grado en cumplimiento de los requisitos exigidos por la Universidad Autónoma de Occidente para optar al título de Ingeniero en Informática ANDRES FERNANDO SOLANO

Jurado

HERNANDO GONZALEZ UMAÑA

Jurado

Santiago de Cali, 6 de Abril de 2018

4

A mi familia, amigos y docentes que estuvieron presentes durante mi proceso de formación.

5

CONTENIDO p.

RESUMEN 12

INTRODUCCIÓN 14

1. PLANTEAMIENTO DEL PROBLEMA 16

2. MARCO TEÓRICO 18

2.1 SISTEMATIZAR 18

2.2 EXÁMENES OCUPACIONALES 18

2.2.1 Examen médico ocupacional 18

2.2.2 Examen médico ocupacional de ingreso 18

2.2.3 Examen médico ocupacional periódico programado 19

2.2.4 Examen médico ocupacional por cambio de ocupación 19

2.2.5 Examen médico ocupacional por reintegro 20

2.2.6 Examen médico ocupacional de egreso 20

2.2.7 Paraclínicos 20

2.2.8 Aptitud Médica 23

2.3 ORDENES DE SERVICIO 23

3. ANTECEDENTES 24

3.1 GUÍA PARA EL DISEÑO DE UNIDADES DE EMERGENCIA 24

3.2 GESTIÓN DE CAPACIDAD EN EL SERVICO DE URGENCIAS EN UN HOSPITAL PUBLICO EN CHILE 28

4. OBJETIVOS 30

6

4.1 OBJETIVO GENERAL 30

4.2 OBJETIVOS ESPECÍFICOS 30

5. JUSTIFICACIÓN 31

6. METODOLOGÍA 33

6.1 ANÁLISIS DE REQUISITOS 33

6.2 DISEÑO 34

6.3 CONSTRUCCIÓN (IMPLEMENTACIÓN) 35

6.4 PRUEBAS Y DEPURACIÓN (VALIDACIÓN) 35

7. DESARROLLO DEL PROYECTO 36

7.1 REQUERIMIENTOS 36

7.1.1 Requerimientos funcionales 38

7.1.2 Requerimientos no funcionales 42

7.1.3 Clasificación de los requerimientos 46

7.2 DISEÑO 68

7.2.1 Arquitectura Cliente/servidor 72

7.2.2 Red de la empresa 73

7.2.3 Diagrama de flujo 80

7.3 IMPLEMENTACIÓN 87

7.3.1 Diagrama de objetos 88

7.3.2 Rad Studio XE 91

7.3.3 SQL Server Management Studio (SSMS) 92

7.3.4 MYSQL 92

7.4 PRUEBAS 96

7

7.4.1 Objetivo general de pruebas del aplicativo 99

7.4.2 Objetivos específicos, en conjunto de los casos de prueba 99

7.4.3 Entorno y configuración de pruebas 100

7.4.4 Criterios de aprobación / rechazo 100

7.4.5 Base de datos de pruebas 101

7.4.6 Tipo de prueba de software a aplicar 101

7.4.7 Orden de ejecución de pruebas 102

7.4.8 Equipo de pruebas y responsabilidades 103

7.5 CASOS DE PRUEBAS 104

7.5.1 Caso de prueba 1 104

7.5.2 Caso de prueba 2 108

7.6 RELACIÓN DE CASOS DE PRUEBAS Y REQUERIMIENTOS 113

8. RESULTADOS 118

9. RECOMENDACIONES 120

10. CONCLUSIONES 122

BIBLIOGRAFÍA 124

ANEXOS 130

8

LISTA DE FIGURAS

p.

Figura 1. Modelo de atención 27

Figura 2. Diagrama general del proceso 57

Figura 3. Diagrama de creación de usuario 59

Figura 4. Diagrama de creación de empresas 61

Figura 5. Diagrama de creación de servicios 62

Figura 6. Diagrama de configuración del sistema 64

Figura 7. Caso de uso de ingreso de pacientes 66

Figura 8. Caso de uso de registro de pacientes 67

Figura 9. Diagrama general de entidad - relación 71

Figura 10. Arquitectura cliente/servidor 72

Figura 11. Red LAN interna 74

Figura 12. Diagrama de secuencia de orientación 75

Figura 13. Diagrama de secuencia de facturación 76

Figura 14. Diagrama de creación de usuario 77

Figura 15. Diagrama de creación de empresa 78

Figura 16. Diagrama de creación de servicio 79

Figura 17. Diagrama de flujo 81

Figura 18. Diagrama de flujo de Procedimiento consultorios 86

Figura 19. Diagrama de Objetos 89

Figura 20. Estructura de MyQSL 94

Figura 21. Aplicativo en funcionamiento 96

9

LISTA DE TABLAS p.

Tabla 1. Clasificación de los requerimientos 46

Tabla 2. Grado de prioridad 46

Tabla 3. Autores 47

Tabla 4. Análisis de Requerimientos Funcionales (RTM) 48

Tabla 5. Análisis de requerimientos no funcionales. 52

Tabla 6. Descripción paso a paso del diagrama general (figura 2) 58

Tabla 7. Descripción paso a paso de caso de uso (Figura 3) 59

Tabla 8. Descripción paso a paso de caso de uso extendido 60

Tabla 9. Descripción paso a paso de caso de uso alternativo 60














Tabla 23. Secuencia de pasos para la configuración 102

10

Tabla 24. Equipo de trabajo para pruebas y distribución de responsabilidades. 103

Tabla 25. Identificación general (caso de prueba 1) 105

Tabla 26. Tiempos de atención y exámenes realizado con N° de ID 125 106


Tabla 28. Validación de órdenes 107

Tabla 29. Identificación general de los casos de uso 108



Tabla 32. Validación de órdenes 112

Tabla 33. Relación de casos de prueba y requerimientos funcionales 113

Tabla 34. Relación de casos de prueba y requerimientos no funcionales 114

Tabla 35. Relación de cantidad usuarios y función o especialidad 115

Tabla 36. Relación de cantidad pacientes y servicios solicitados 116

11

LISTA DE ANEXOS p.

Anexo A. Diagrama de flujo de procedimiento “estadoinicio” 130

Anexo B. Diagrama de flujo de procedimiento “liberarpendientes” 131

Anexo C. Diagrama de flujo de procedimiento “refrescar” 132

Anexo D. Diagrama de flujo de procedimiento “cambioestado”. 133

Anexo E. Diagrama de flujo de procedimiento “cargatabla” 134

Anexo F. Diagrama de flujo de procedimiento “validaestado” 135

Anexo G. Cuestionario 136

Anexo H. Registros realizados por el aplicativo en jornada de atención al público (09/09/2017). 137

12

RESUMEN

La Implementación de un sistema de asignación de pacientes para el área de DMO (Diagnóstico Médico Ocupacional) de la empresa Unidad de Salud Ocupacional (USO) S.A.S, surge debido a la necesidad de agilizar los procesos administrativos y asistenciales de la USO, liberar cargas laborales y sistematizar el proceso de asignación de pacientes, favoreciendo la acogida de un mayor número de empresas clientes y por ende un mejor cubrimiento de las necesidades de las mismas.

Debido a lo anterior, se plantearon como objetivos, la identificación de necesidad de los principales usuarios, diseño, implementación, evaluación y pruebas del aplicativo. Para ello se llevó a cabo la metodología en cascada, ya que esta permitió el desarrollo del aplicativo, permitiendo el seguimiento de sus etapas y actividades, de tal manera que no permite avanzar hasta el siguiente paso, si el anterior no ha sido finalizado. Permitiendo entonces el desarrollo de las etapas que se llevaron a cabo, estas fueron 1. Análisis de requisitos, 2. Diseño, 3. Construcción y 4. Pruebas y depuración.

Como resultados, se destaca que gracias a la metodología implementada, se logró mantener un orden en relación con los objetivos planteados al inicio del proyecto, ya que no generó retrasos ni incomodidades durante el proceso de la USO, además agilizó el proceso de los usuarios del aplicativo, es decir, el personal de la empresa encargada directamente de la orientación, facturación, registro y atención de los pacientes. Así mismo, se evidenció un mayor aumento de vinculación de empresas clientes, disminución en los tiempos de atención de los profesionales y especialistas de la uso, además de un mayor reconocimiento de la empresa.

Palabras clave: Ingeniería, software, correctitud, sistematización.

13

ABSTRACT

The implementation of a patient allocation system for the area of BMD (Occupational Medical Diagnosis) of the company Occupational Health Unit (USO) SAS, arises due to the need to streamline the administrative and assistance processes of the USO, release labor burdens and to systematize the process of patient assignment, favoring the reception of a greater number of client companies and therefore a better coverage of the needs of the same.

Due to the above, the identification of need of the main users, design, implementation, evaluation and testing of the application were raised as objectives. For this, the cascade methodology was carried out, since it allowed the development of the application, allowing the monitoring of its stages and activities, in such a way that it does not allow advancing until the next step, if the previous one has not been finalized. Allowing then the development of the stages that were carried out, those was 1. Requirements analysis, 2. Design, 3. Construction and 4. Testing and debugging.

As results, it is highlighted that thanks to the implemented methodology, it was possible to maintain an order in relation to the objectives set at the beginning of the project, since it did not generate delays or discomfort during the USO process, as well as streamlined the process of users of the application, that is, the company's personnel directly responsible for orientation, billing, registration and patient care. Likewise, it was evidenced a greater increase of linking of client companies, decrease in the attention times of the professionals and specialists of the use, in addition to a greater recognition of the company.

Keywords: Engineering, software, correctness, systematization

14

INTRODUCCIÓN

La Unidad de Salud Ocupacional (USO) S.A.S es una empresa dedicada a la realización de exámenes ocupacionales y asesoramiento en salud ocupacional e industrial para empresas que requiere mantener en orden la documentación personal y la salud de todos sus empleados. Su misión principal es lograr la satisfacción de las necesidades de los clientes en materia de salud ocupacional, contribuyendo al mejoramiento de las condiciones de trabajo de la población objeto y al desarrollo integral de los colaboradores, con niveles óptimos de calidad, tecnología, efectividad, cumplimiento y rentabilidad para garantizar un crecimiento sostenible.

La empresa se encuentra localizada en el norte de la ciudad de Cali, cuenta con una estructura organizacional compuesta por áreas administrativas y asistenciales con funciones definidas para el cumplimiento de su objetivo social.

Además, cuenta con un sistema de información que está en constante desarrollo, dentro de este se realiza el ingreso de los pacientes y el registro de todos los exámenes a realizar, generando de esta manera una sala de espera de pacientes. El área encargada de administrar dicha sala y brindar información a los pacientes y a los profesionales y especialistas de la salud, es la de Diagnóstico Médico Ocupacional (DMO), está conformada por: exámenes especializados laborales, exámenes especializados psicológicos y exámenes médicos.

Los pacientes llegan de forma repentina a las instalaciones, solicitando diversos servicios, unos con un nivel de urgencia superior al de otros, estas situaciones generan desorden en el cumplimiento adecuado de la realización de los exámenes, además de desorden en la lista de espera de los pacientes, pérdida de tiempo, entre otros casos que intervienen en la óptima atención de los pacientes.

Por estos motivos, para la empresa es importante obtener el control de este proceso para generar encadenamiento de la información entre todos los procesos de atención, dando cumplimiento a las especificaciones previamente

15

establecidas y avaladas por normatividad de la salud y sin descuidar las necesidades de los clientes.

Teniendo en cuenta los puntos mencionados hasta el momento, se propuso la sistematización de la administración de la sala de espera de pacientes, con sus exámenes paraclínicos por realizar.

Partiendo de la propuesta previamente mencionada se diseñó, desarrolló e implementó un aplicativo que se encarga de la distribución adecuada de los pacientes de la sala de espera, teniendo en cuenta factores como la hora, orden de llega y los exámenes a realizar, procurando mantener ocupados a todos los especialistas que se encuentren activos para brindar la atención, siempre y cuando existan pacientes en la sala de espera.

16

1. PLANTEAMIENTO DEL PROBLEMA

En la actualidad la empresa USO S.A.S cuenta con un sistema de información que está constantemente en desarrollo y crecimiento, buscando mejorar el control y aprovechamiento de la información en la empresa, con el propósito de mantener la seguridad, integridad, disponibilidad y confiabilidad.

Dicho sistema de información es utilizado en todo el proceso de la prestación del servicio a los pacientes que asistan a las instalaciones de la empresa. El proceso de prestación del servicio se encuentra dividido en varias secciones, estas son: área de orientación y facturación, área de DMO, departamento comercial, entre otros, cada una cuenta con un número determinado de empleados que atienden la demanda del servicio. El área de DMO está conformada por: exámenes especializados laborales, exámenes especializados psicológicos y exámenes médicos.

Dado el volumen de personas que requieren el servicio, la forma repentina de llegada y la urgencia de los exámenes, la distribución de los pacientes hacia cada uno de estos procesos y cada uno de los especialistas es realizada de forma manual y con la posibilidad para que los médicos o especialistas elijan a quien atender, teniendo en cuenta características como: empresa, tipo de examen a realizar, sexo, entre otras particularidades, resaltando que se pierde el orden en el proceso de atención, teniendo en cuenta que este debe estar determinado por los exámenes a realizar, orden de llegada, prioridad que se debe dar a trabajadores de terminadas empresas que realizan programación masiva de personal con previo anuncio.

Cuando un paciente es enviado a la sala de espera una vez ha sido facturado, las órdenes de los pacientes son tomadas por los especialistas o médicos. Durante este proceso se pierde el orden de atención y de esta forma responder a los clientes por el estado de atención en un momento determinado se vuelve complicado.

En relación a lo anterior, el control de los tiempos de atención de los médicos o especialistas es precario ya que deben salir de sus consultorios para realizar el

17

llamado al paciente y hacer la entrega de las órdenes atendidas, para que DMO continúe con su respectivo proceso.

Realizar seguimiento a los tiempos de demora en la atención entre un paciente y otro, es un proceso tedioso ya que no están estandarizados los tiempos que se debe tomar por fuera el médico o especialista entre una consulta y otra, tampoco se cuenta con un proceso óptimo de distribución de carga laboral a cada especialista o médico. Esto desencadena quejas debido al número de pacientes que tienen asignados para un determinado día o por la diferencia en cantidad de pacientes atendidos, en comparación con otro médico especialista.

Situaciones como la anterior, resultan complejas cuando se tiene un volumen considerable de pacientes por ser atendidos en diferentes procesos de manera simultánea, y hay un conjunto de pacientes preguntando por el estado de sus exámenes (¿ya salieron? ¿Cuánto tiempo les falta para terminarlos? o ¿Qué exámenes hacen falta? ).

Por la problemática planteada hasta el momento, se tomó la decisión de desarrollar un aplicativo que se encargue de la administración de la sala de espera, para obtener control y garantizar el cumplimiento del orden y tiempo adecuado de la atención.

18

2. MARCO TEÓRICO

2.1 SISTEMATIZAR

“Sistematizar es un esfuerzo analítico que implica mirar la practica con distancia, reflexionarla, hacerle preguntas y no hacer obvias las actividades cotidianas. Es distinguir a nivel teórico lo que en la práctica se da sin distinciones dentro de todo un proceso, es buscar las relaciones que hay en lo que se hace. Sistematizar es organiza una práctica para volver a intervenir con mayor eficiencia y eficacia en una situación dada”1.

2.2 EXÁMENES OCUPACIONALES

2.2.1 Examen médico ocupacional

Acto médico mediante el cual se interroga y examina a un trabajador, con el fin de monitorear la exposición a factores de riesgo y determinar la existencia de consecuencias en la persona por dicha exposición. Incluye anamnesis, examen físico completo con énfasis en el órgano o sistema blanco, análisis de pruebas clínicas y paraclínicas, tales como: de laboratorio, imágenes diagnósticas, electrocardiograma, y su correlación entre ellos para emitir el diagnóstico y las recomendaciones2.

2.2.2 Examen médico ocupacional de ingreso

Este determina las condiciones de salud física, mental y social del trabajador antes de su contratación, en función de las condiciones de trabajo a las que estará expuesto, acorde con los requerimientos de la tarea y perfil del cargo. El objetivo

1 UNIVERSIDAD DE MONTREAL. Sobre el sistema [en línea]. Universidad de Montreal. Canadá. 2016. P. 28.

[Consultado: 10 de febrero de 2017]. Disponible en internet: https://bit.ly/2EG5Mz2.

2 OMNISALUD. Medicina laboral [en línea]. OMNISALUD. Medellín. 2016. [consultado: 10 de febrero de

2017]. Disponible en internet: https://omnisalud.co/medicina-laboral/.

https://omnisalud.co/medicina-laboral/

19

es determinar la aptitud del trabajador para desempeñar en forma eficiente las labores sin perjuicio de su salud o la de terceros, comparando las demandas del oficio para el cual se desea contratar con sus capacidades físicas y mentales; establecer la existencia de restricciones que ameriten alguna condición sujeta a modificación e identificar condiciones de salud que estando presentes en el trabajador, puedan agravarse en desarrollo del trabajo3.

2.2.3 Examen médico ocupacional periódico programado

Se realiza con el fin de monitorear la exposición a factores de riesgo e identificar de forma precoz alteraciones temporales, permanentes o agravadas del estado de salud del trabajador, ocasionadas por la labor o por la exposición al medio ambiente de trabajo. Así mismo, para detectar enfermedades de origen común, con el fin de establecer un manejo preventivo. Dichas evaluaciones deben ser realizadas de acuerdo con el tipo, magnitud y frecuencia de exposición a cada factor de riesgo, así como al estado de salud del trabajador. Los criterios, métodos, procedimientos de las evaluaciones médicas y la correspondiente interpretación de resultados, deberán estar previamente definidos y técnicamente justificados en los sistemas de vigilancia epidemiológica, programas de salud ocupacional o sistemas de gestión, según sea el caso4.

2.2.4 Examen médico ocupacional por cambio de ocupación

Se realiza con el fin de evaluar al trabajador cada vez que éste cambie de ocupación y ello implique cambio de medio ambiente laboral, de funciones, tareas o exposición a nuevos o mayores factores de riesgo, en los que detecte un incremento de su magnitud, intensidad o frecuencia. Su objetivo es garantizar que el trabajador se mantenga en condiciones de salud física, mental y social acorde con los requerimientos de las nuevas tareas y sin que las nuevas condiciones de exposición afecten su salud5.

3 Ibid., p. 01.

4 Ibid., p. 03.

5 Ibid., p. 02.

20

2.2.5 Examen médico ocupacional por reintegro

Se deberá ordenar la realización de otro tipo de evaluaciones médicas ocupacionales, tales como post – incapacidad o por reintegro, para identificar condiciones de salud que puedan verse agravadas o que puedan interferir en la labor o afectar a terceros, en razón de situaciones particulares6.

2.2.6 Examen médico ocupacional de egreso

Se realiza cuando se termina la relación laboral. Su objetivo es valorar y registrar las condiciones de salud en las que el trabajador se retira de las tareas o funciones asignadas7.

2.2.7 Paraclínicos

Exámenes complementarios (exámenes de laboratorios, audiometría, espirometría, optometría, Visiometría, val. ergonómica, etc.) al examen médico, tiene como fin esclarecer diagnósticos, seguimiento a patologías8.

1.1.1.1 Audiometría

La audiometría o (audiometría tonal) es la prueba que permite evaluar el funcionamiento del sistema auditivo y revela si la audición está alterada en la parte

6 Ibid., p. 03.

7 Ibid., p. 01

8 UNIVERSIDAD DE SAN BUENAVENTURA. Procedimiento de evaluaciones médicas [en línea]. Universidad

de san buenaventura. Medellín. (28 de noviembre de 2011), p. 02. [Consultado 10 de febrero de 2017]. Disponible en internet: http://web.usbmed.edu.co/usbmed /gestion_ocupacional/.

http://web.usbmed.edu.co/usbmed

21

de la transmisión del sonido o en la parte más relacionada con el sistema nervioso, lo que ayuda a definir el tratamiento a seguir9.

1.1.1.2 Espirometría

La espirometría es una prueba no invasiva que permite conocer la función pulmonar de una persona. Consiste en respirar por la boca a través de un pequeño tubo, y forzar la respiración para medir el flujo aéreo10.

1.1.1.3 Optometría

La optometría es una prueba no invasiva, que permite medir la agudeza visual del paciente, empleando diferentes test. El objetivo es la identificación de los defectos de la capacidad de refracción ocular y su adecuada corrección a través de la adaptación de gafas o lentes correctivos. También abarca los aspectos del cuidado integral del ojo y sus anexos11.

1.1.1.4 Visiometría

La Visiometría es una prueba utilizada para valorar la capacidad visual del individuo, que incluye tanto la visión a distancia como cercana, la capacidad para percepción de los colores, de profundidad y balance muscular básico; permitiendo

9 WIDEX. La audiometría [en línea]. Widex. España. (16 de diciembre de 2015), P. 01. [Consultado: 10 de febrero de 2017]. Disponible en internet: http://www.widex.es/perdida-auditiva/audiometria/.

10 SACEDA CORRALO, David. Espirometría [en línea]. Web consultas Healtcare SA. España. (29 de enero de

2017), P. 01. [Consultado: 09 de febrero de 2017]. Disponible en internet: http://www.webconsultas.com/pruebas- medicas/espirometria-13115/.

11 PAZ ANDRADE, Maria. Optometría [en línea]. Definición ABC. Chile. (20 de junio de 2015), Par. 01.

[consultado: 09 de febrero de 2017]. Disponible en internet: http://www.definicionabc.com/salud/optometria.php/.

http://www.widex.es/perdida-auditiva/audiometria/

http://www.webconsultas.com/pruebas-%20medicas/espirometria-13115/

http://www.definicionabc.com/salud/optometria.php/

22

clasificar la severidad de los defectos ópticos e identificando a quienes requieren exámenes complementarios con mayor prontitud12.

1.1.1.5 Valoración Ergonómica

La valoración ergonómica o prueba de esfuerzo es una técnica diagnóstica fundamental que se utiliza principalmente para el diagnóstico de la angina de pecho en pacientes con dolor torácico y para valorar la respuesta del corazón ante el ejercicio13.

1.1.1.6 Valoración Foniátrica

Es una valoración tamiz que trata de valorar la morfología de los órganos fonoarticuladores (lengua, mejillas, paladar, labios, buccinadores, entre otros.) su funcionalidad y analiza el resultado final en relación a la presión sonora. La cual se enfoca en aspectos como el examen funcional, subjetivo y psicoacústico de la voz en el que se miden los parámetros acústicos y el comportamiento vocal14.

12 UNIMSALUD. Visiometría laboral [en línea]. Unimsalud servicios de salud ocupacional. Bogotá. (04 de abril

de 2012), Par. 01. [Consultado: 09 de febrero de 2017]. Disponible en internet: http://www.unimsalud.com.co/index.php/visiometria-ocupacional.

13 HIGUERAS ORTEGA, Laura. Ergometría [en línea]. Fundación española del corazón. España. (Febrero de

2015), Par. 01. [Consultado: 09 de febrero de 2017]. Disponible en internet: https://bit.ly/TOqyoB.

14 PÉREZ SEREY, Jazmín. ORTIZ ARAYA, Virna. Instrumentos aplicados en la evaluación de la voz en

profesores: estudio bibliográfico [en línea]. Scielo. Chile. (18 de enero de 2012), P. 02. [Consultado: 12 de febrero de 2018]. Disponible en internet: http://www.scielo.br/pdf/rcefac/v15n5/v15n5a33.pdf.

http://www.unimsalud.com.co/index.php/visiometria-ocupacional

https://bit.ly/TOqyoB

http://www.scielo.br/pdf/rcefac/v15n5/v15n5a33.pdf

23

1.1.1.7 Laboratorios

Exámenes biológicos que se toman de un individuo, en los cuales se llevan a cabo mediciones de variables bioquímicas, fisiológicas, anatómicas, análisis moleculares y cultivos celulares15.

2.2.8 Aptitud Médica

conclusión a la que llega el médico que practica evaluaciones médicas ocupacionales cotejando el perfil del cargo a desempeñar con las condiciones físicas y mentales de un trabajador. Puede resultar en Apto, no apto o apto con limitaciones o restricciones para el desarrollo del cargo y tareas requeridas16.

2.3 ORDENES DE SERVICIO

Una orden de servicio u orden de trabajo es un documento escrito que la empresa le entrega a la persona que corresponda y que contiene una descripción pormenorizada del trabajo que debe llevar a cabo17.

Dentro de la USO, las ordenes de servicio son entendidas o interpretadas como el documento detallado de los servicios solicitados para un paciente, también se maneja una orden en la cual especifican el conjunto de exámenes ocupacionales a realizar y detalla una lista con los pacientes a los cuales se les debe realizar al conjunto de exámenes.

15 SECRETARIA DISTRITAL DE SALUD DE BOGOTÁ. Manual para la toma de muestras para análisis

microbiológico [en línea]. Secretaria distrital de salud de Bogotá, D.C. Dirección de salud pública. Bogotá. (Mayo de 2008), P. 12. [Consultado: 12 de febrero de 2018]. Disponible en internet: https://bit.ly/2pEUusy.

16 UNIVERSIDAD DE SAN BUENAVENTURA. Procedimiento de evaluaciones médicas [en línea]. Universidad

de San Buenaventura. Medellín. (28 de noviembre de 2011), p. 02. [Consultado 10 de febrero de 2017]. Disponible en internet: http://web.usbmed.edu.co/usbmed /gestion_ocupacional/.

17 UCHA, Florencia. Orden de trabajo [en línea]. Definición ABC. Chile. (23 de enero de 2013), Párr. 02. [09 de

febrero de 2017]. Disponible en internet: https://www.definicionabc.com/general/orden-de-trabajo.php.

https://bit.ly/2pEUusy

http://web.usbmed.edu.co/usbmed

https://www.definicionabc.com/general/orden-de-trabajo.php

24

3. ANTECEDENTES

La logística aplicada dentro de las empresas es un proceso que requiere control y seguimiento constante, cuando los procesos logísticos están atados a la intervención de los humanos, quienes son propensos a equivocaciones intencionadas o no, pueden generar traumatismos en la circulación del proceso para brindar un servicio acorde a las expectativas de las empresas cliente.

3.1 GUÍA PARA EL DISEÑO DE UNIDADES DE EMERGENCIA

En la República del Perú, desde su Ministerio de Salud y con la participación de del Programa Nacional de Equipamiento y Mantenimiento (PRONAME), se realizó un trabajo llamado “Guía para el diseño de unidades de emergencia” en el cual se sistematizo un proceso pero sin la intervención de las computadoras o maquinas, aplicando logística, orden y control, a todos los centro de salud medica hospitalarias, más específicamente a las áreas de la urgencias médicas, dentro de esta área se presentan ciertas similitudes a la hora de realizar la prestación del servicio, traduciendo el termino urgencia médica a una urgencia de tiempo de atención18.

De este estudio se destaca la categorización de los tipos de urgencias que se manejan, la cantidad de médicos disponibles para la atención de estas, la forma o modalidad de gestionar el orden de llegada, la distribución de los servicios solicitados por cada paciente y la prioridad de atención de cada uno, lo que se encuentra directamente relacionado con la problemática presentada en la empresa USO, siendo que la urgencia médica es prestar el servicio completo a la menor brevedad de tiempo posible.

Su modelo de atención también sirve como guía para entender el manejo y modo de dar orden a un proceso que puede llegar a causar saturación de los servicios prestados.

18 MINISTERIO DE SALUD DE PERÚ. Guía para el diseño de unidades de emergencia [en línea]. Ministerio

de salud de Perú PRONAME. Perú. 2016. , P. 02-04. [Consultado: 10 de diciembre de 2016]. Disponible en internet: https://bit.ly/2qr2QlE.

https://bit.ly/2qr2QlE

25

Dentro de la planeación y organización del ministerio de salud del Perú, se encuentran cuatros grupos que le dan el orden a todo el proceso, en el cual se recolecta la información necesaria para cumplir con el propósito principal que se plantea en Perú, los cuales son:

Instrumentos de gestión.

Planes y políticas.

Información adicional.

Recomendaciones.

La unidad de emergencia y planificación de hospitales es el lugar donde se concentran las facilidades físicas para la atención de niños y adultos que presentan urgencias médicas de forma individual, colectiva y/o atención masiva de pacientes en caso de desastres. Esta unidad pertenece al ministerio de salud del Perú. En relación a ello, se han categorizado las urgencias de la siguiente manera:

Urgencia Médica Leve: Situación clínica de un paciente en la que solo requiere tratamiento sintomático y su vida no corre peligro.

Urgencia Médica Moderada: Situación clínica de un paciente en la que requiere necesariamente de consulta médica y exámenes complementarios y una proporción puede requerir internamiento.

Urgencia Médica Grave: Situación clínica donde el paciente no puede movilizarse ni valerse por sus propios medios y requiere internamiento y/o intervención quirúrgica inmediata.

Cabe destacar que dicha categorización cuenta con actividades y procesos que complementan y dan un orden estructurado a la atención de las urgencias, estos son los siguientes:

26

Procesos y actividades en la unidad de emergencia (Modelo):

Selección y control de ingreso de pacientes.

Clasificación y tratamiento de casos con urgencia leve.

Diagnóstico y tratamiento de urgencias médico – quirúrgicas; moderadas y graves; vigilancia temporal de pacientes con diagnósticos de urgencias médico quirúrgicas.

Reanimación cardio – pulmonar.

Elaboración de informes.

En la figura 1 se muestra el orden secuencial de los procesos y las actividades realizadas durante la prestación del servicio en la unidad de emergencia19.

19 Ibid., p. 02.

27

Con la forma de distribución de las actividades, el paso a paso que se visualiza en este diseño, se encuentran similitudes en la estructura y las ventajas que se implementarán en el proyecto actual, incluyendo a las computadoras como parte de la solución.

Figura 1. Modelo de atención

Fuente: Tomado de Ministerio de salud de Perú, Pág. 02. Perú.

28

3.2 GESTIÓN DE CAPACIDAD EN EL SERVICO DE URGENCIAS EN UN HOSPITAL PUBLICO EN CHILE

“Saturación, elevados tiempos de espera, y cargas horarias de trabajo desbalanceadas son problemas comunes en la mayoría de los hospitales públicos de Chile20. A través de este trabajo se buscó mejorar el flujo de pacientes en el servicio de urgencia de un hospital pediátrico por medio de la gestión y programación de capacidad del personal asistencial. Se identificaron dos etapas principales. En la primera, se estimó la demanda diaria del servicio de urgencia del hospital. La segunda parte requirió determinar los niveles de personal óptimos para todo tipo de trabajadores asistenciales necesitados en el servicio. Para esto se propuso una estructura de turnos médicos, enfermeras y paramédicos óptima basada en programación lineal y con la información que se poseía de la demanda futura. Los sistemas propuestos mostraron excelentes resultados”21

Este trabajo tiene una gran incidencia sobre el modelo estructural que se desea aplicar en la empresa USO, ya que se manejan procesos semejantes a la propuesta planteada de solución, partiendo de los conceptos que se plantean sobre cómo realizar la clasificación de los pacientes, prosigue con el ingreso y la atención de los mismos. Este proceso tiene una serie de divisiones que llegan hasta el final de la prestación del servicio, también permite tener una visualización sobre opciones de mejoras o servicios que se pueden tener en cuenta dentro de la empresa USO para un pos-servicio, y de esta forma generar captación de clientes, recomendación y buen nombre.

El documento muestra una visión que se desea incluir en el aplicativo, no de forma directa, pero si participativa con el resto del sistema manejado dentro de la empresa, ayudando a marcar horas, usuarios, pacientes, consultorios, tipos de examen, entre otros puntos que sirven como referencia para generar más información a partir de ellos, con estos pasos, se ayuda en la generación de

20 BARROS, Oscar. Design of the emergency service production in a public hospital [en línea]. Universidad de chile, ingeniería industrial. Chile. (septiembre de 2017), par. 01. [consultado: 15 de diciembre de 2017]. Disponible en internet: https://www.researchgate.net/publication/320042367_design_of_the_emergency_service_production_in_a_public_hospital.

21 Ibid., p. 01.

https://www.researchgate.net/publication/320042367_DESIGN_OF_THE_EMERGENCY_SERVICE_PRODUCTION_IN_A_PUBLIC_HOSPITAL


29

informes y reportes para el mejoramiento y agilización de las tomas de decisiones a nivel gerencial y directivo de la empresa USO.

En el caso de los servicios hospitalarios la capacidad disponible de atención se ve determinada por las instalaciones físicas, tales como: box de atención. Y los recursos humanos, tales como: médicos, paramédicos y enfermeras, que realizan diagnósticos y tratamientos. Esta capacidad se debe planificar para garantizar un buen nivel de servicio brindado y a su vez, optimizando el uso de los recursos.

En este trabajo se presentan los dos enfoques principales del sistema que fue implementado en un hospital público y pediátrico en Santiago de Chile. El primer enfoque es la predicción de la demanda donde se aplican modelos econométricos y de minería de datos. El segundo enfoque consiste en la programación de los recursos mediante la optimización22.

22 Ibid., p. 02.

4. OBJETIVOS 4.1 OBJETIVO GENERAL

Desarrollar un aplicativo software, que seleccione los pacientes habilitados en la sala de espera, para su asignación en cada uno de los consultorios de la empresa Unidad de Salud Ocupacional (USO) S.AS.

4.2 OBJETIVOS ESPECÍFICOS

Identificar los requerimientos de los usuarios representativos del aplicativo.

Diseñar e implementar los módulos requeridos, asociados con el aplicativo para la selección y asignación de pacientes.

Diseñar un plan de pruebas, en el cual se pueda evaluar el funcionamiento del aplicativo.

Evaluar el aplicativo de asignación, con usuarios representativos del sistema del área de DMO de la empresa USO.

31

5. JUSTIFICACIÓN

Para la Empresa USO es de vital interés tomar el control de cada proceso, especialmente dentro del área de DMO, en que se logren cumplir con unas especificaciones previamente establecidas, formalmente avaladas por normatividad de la salud y teniendo en cuenta las necesidades de las empresas cliente. Dentro de este contexto, es de suma importancia manejar un orden para realizar cada uno de los exámenes que son requisitos y que el paciente reciba de manera oportuna el concepto de actitud laboral coherente a lo solicitado por la empresa contratante.

El presente proyecto busca organizar la sala de espera de los pacientes por atender, generar encadenamiento de la información entre todos los procesos de atención. Además, busca garantizar que los profesionales o especialistas tengan un paciente asignado para realizar su respectiva atención, siempre y cuando existan en la sala de espera, mejorar los tiempos de atención de cada uno de los servicios que se ofrecen dentro de las instalaciones de la empresa, cumplir con las especificaciones previamente establecidas y avaladas por normatividad de la salud y sin descuidar las necesidades de los clientes. De la misma forma contribuir con el medio ambiente, reduciendo en lo posible el consumo de papel; sistematizando la distribución de la información que requiere cada médico y especialista para realizar la prestación de su servicio. Permitiendo en conjunto la agilización en la búsqueda de información de cada paciente durante y después de todo su proceso, al tener toda la información y trazabilidad sistematizada.

Con la digitalización y automatización de la distribución de la información se mejorará la toma de decisiones durante la jornada laboral, el aplicativo libera a los auxiliares de DMO de estar pendientes de la ubicación y asignación de los pacientes a diferentes consultorios con sus especialistas o profesionales respectivos. Lo que brinda tiempo para realizar análisis de las cantidades de pacientes y de servicios que se encuentren represados, apoyados en un promedio de tiempos y de pacientes atendidos, previamente establecido, para mediar el tiempo y el número de especialistas para culminar de manera satisfactoria la jornada.

El proceso de medición que se pretende establecer a partir de la inclusión del aplicativo propuesto va a crear orden, control y mejorar el manejo de la sala de

32

espera de pacientes, esto dará la posibilidad que cada persona maneje una sola orden para todo el proceso. Siendo posible el control de dos órdenes diferentes para el mismo paciente de acuerdo a los tipos de exámenes solicitados, y de esta manera se brindarán repuestas oportunas a los clientes, sobre el estado del proceso de cada paciente.

El manejo ordenado y controlado de las actividades concernientes a la atención de los clientes, proporcionado desde el aplicativo, respetando el turno, la posición de acuerdo a la hora de llegada y la hora de la cita, hace que a todos se les atienda con igual consideración y respeto, sin que existan preferencias por parte de las recepcionistas, médicos ni especialistas, toda vez que la selección de forma manual genera represamiento en la sala de espera, además reduce ostensiblemente el nivel de estrés en las personas encargadas del área DMO.

Adicionalmente, el aplicativo brindará la posibilidad de generar rotación entre las diferentes especialidades, permitiendo con una orden direccionar los exámenes a un especialista específico. Con el enlace de información que se mantendría gracias al aplicativo, se dará la opción de extraer reportes de tiempos de atención, evitando y evidenciando los tiempos muertos que pueden ser generados por los médicos y especialistas; en su defecto algún retardo del sistema, con un grado de confiabilidad mayor.

Junto con todas las ayudas anteriormente mencionadas, con el aplicativo se busca también un distintivo en la estructura de funcionamiento de la empresa USO, al mostrar al mercado y a los clientes, el uso y aplicación de la tecnología para mejorar el servicio de atención y de tiempos de espera.

33

6. METODOLOGÍA

La metodología se escogió teniendo en cuenta los procesos que se llevan a cabo dentro del aplicativo, y la manejada actualmente dentro de la empresa.

El modelo en cascada23 es la metodología que mejor se ajusta a las necesidades de la empresa USO ya que favorece el desarrollo del aplicativo y permite el seguimiento de sus etapas y actividades, de tal manera que no se permitirá avanzar hasta que no se haya culminado la etapa precedente cumpliendo con las pautas que permiten la organización en el desarrollo del software a través de la implementación de sus características por etapas. De la metodología en cascada, se usarán los siguientes pasos:

Análisis de requisitos.

Diseño.

Construcción (Implementación).

Pruebas y depuración (Validación).

A continuación se describen los procesos.

6.1 ANÁLISIS DE REQUISITOS

Esta es la fase en la cual se analizan las necesidades de los usuarios finales del aplicativo24, para determinar qué objetivos debe cubrir. De esta fase surge una

23 BLE, Carlos. Modelo en cascada [en línea]. Libros Web. España. 2013. P. 02. [Consultado: 10 de diciembre de 2016]. Disponible en internet: http://librosweb.es/libro/tdd/capitulo_1/modelo_en_cascada.html.

24 Ibid., p. 02.

http://librosweb.es/libro/tdd/capitulo_1/modelo_en_cascada.html

34

memoria llamada Documento de Especificación de Requisitos (SRD*), que contiene la especificación completa de lo que debe hacer el aplicativo.

Teniendo siempre presente que los requerimientos son una especificación de lo que debería ser implementado. Estos son descripciones de como el sistema debería de comportarse y son también atributos o una propiedad del sistema. En este caso los requerimientos están enfocados en la asignación eficiente de tiempos y espacio para el área de DMO de la empresa USO.

6.2 DISEÑO

Esta fase se enfoca en describir cómo se va hacer lo que el sistema tiene que hacer25.

Se descompone el sistema en todas sus partes más elementales que se pueda, se realiza un planteamiento de solución con todos estos elementos, se efectúan los ajustes necesarios para reorganizar y agregar los pasos requeridos, teniendo en cuenta la tarea que debe cumplir, buscando el cumplimiento del objetivo general, con eficiencia en la atención y en los tiempos tanto de espera como de atención, con esta información se reconstruyó todo el sistema o proceso teniendo en cuenta la solución planteada, generando al finalizar un documento de diseño detallado.

En la fase de diseño es más efectivo utilizar patrones y modelos conocidos para ir resolviendo por partes el problema, es decir, dividir y proyectar la solución en módulos. Cabe resaltar que esta fase está dependida de cada tipo de proyecto, es decir, no está tan formalizado como las otras fases y por tanto se apoya en la experiencia e intuición de los diseñadores26.

* Por sus siglas en Inglés “System Reference Document”

25 Ibid., p. 02.

26 ARIAS CALLEJA, Manuel. Análisis, diseño y mantenimiento de software [en línea]. Departamentos de

inteligencia artificial de la UNED. (noviembre de 2010), P. 19. [Consultado: 11 de diciembre de 2017]. Disponible en internet: http://www.ia.uned.es/ia/regladas/adms/GuiaDidactica.pdf.

http://www.ia.uned.es/ia/regladas/adms/GuiaDidactica.pdf

35

6.3 CONSTRUCCIÓN (IMPLEMENTACIÓN)

La construcción del aplicativo estuvo basada en el documento de diseño que se realizó en la fase anterior. Durante el proceso se debe buscar el mayor nivel de eficiencia y eficacia en el cumplimiento de sus funciones27.

6.4 PRUEBAS Y DEPURACIÓN (VALIDACIÓN)

Una vez finalizada la construcción del aplicativo, se inició la fase de pruebas, se diseñó un plan de prueba que contemple el trabajo con un solo usuario interactuando con el sistema y con un número determinado de usuario grupal28.

Cabe resaltar que las pruebas individuales son el proceso básico de funcionamiento del aplicativo con un solo usuario y las pruebas grupales dependen de una cantidad de pacientes considerables. De esta forma se logró determinar el rendimiento y funcionamiento en dos contextos diferentes de sus funciones. Sin perder de vista que su principal función es apoyar al área de DMO, de la empresa USO.

27 BLE, Carlos. Modelo en cascada [en línea]. Libros Web. España. 2013. P. 02. [Consultado: 10 de diciembre

de 2016]. Disponible en internet: http://librosweb.es/libro/tdd/capitulo_1/modelo_en_cascada.html.

28 Ibid., p. 02.


36

7. DESARROLLO DEL PROYECTO

7.1 REQUERIMIENTOS

El proceso de recopilar, analizar y verificar las necesidades del cliente para un sistema de software es llamado ingeniería de requerimientos, la cual tiene como meta entregar una especificación de requerimientos de software correcto y completo. Además apunta a mejorar la forma en que se comprende y define sistemas de software complejos29.

Con el propósito de cumplir con los requerimientos del aplicativo, se realizó la recolección de la información mediante dos fases: La observación, que permitió conocer el proceso de cómo se lleva a cabo la atención de los usuarios. Y entrevistas semiestructuradas a determinado personal de la empresa USO para especificar el cómo debe desarrollarse el servicio y determinar las necesidades actuales.

En relación a lo anterior, cabe destacar que durante el proceso de observación, se recolectó información relevante para el análisis de la problemática actual. Con base en ello, se hizo seguimiento del proceso que debe cumplir cualquier paciente que ingresa a la USO buscando la prestación de un servicio completo. Inicialmente, se registran los exámenes a realizar, se genera una orden por cada examen, las cuales eran organizadas manualmente por los auxiliares y la coordinadora de DMO, ellos a su vez corroboraban que el paciente cumpliera con todos los exámenes acorde al perfil laboral y requerimientos de las empresas y que además cumplieran con los prerrequisitos necesarios para pasar a determinada consulta. Acto seguido, agrupaban las ordenes por especialidad y procuraban que los profesionales atendieran sin tener preferencias en cuanto al sexo, edad u ocupación, aun así, no había un control constante en ello debido a la multiplicad de tareas que tenía el personal del área (DMO), ocasionando continuamente que los profesionales tomaran ordenes por tiempos indefinidos, ya que no existía un monitoreo constante sobre el tiempo que no se realizaba atención a pacientes.

Con base en lo anterior, los pacientes eran llamados de diferentes consultorios al mismo tiempo, ya que cada profesional o especialista podía tener una orden de exámenes distinta del paciente.

29 RABEY, Eduardo Marcelo. Escenarios en la ingeniería de requerimientos, un modelo con componentes

formales e informales [en línea]. Sedici repositorio nacional de la unlp. La plata. (agosto de 1997), p. 09. [Consultado: 01 de noviembre de 2015]. Disponible en internet: http://sedici.unlp.edu.ar/handle/10915/2155.

http://sedici.unlp.edu.ar/handle/10915/2155

37

También se evidenció que los pacientes provienen de diferentes clientes o empresas, los cuales manejan dentro de su organización múltiples cargos, algunos iguales para todas las empresas, pero que dependiendo del nivel de riesgo ocupacional al que se ven expuestos los pacientes se les realizan un conjunto de exámenes para asegurar su salud durante su estadía en el puesto de trabajo. Cada cargo puede tener un conjunto diferente de exámenes a realizar, o en su defecto la empresa solo quiere estar seguro de una parte específica de la salud del paciente. Esto indica que no existe un patrón específico de exámenes determinados para los pacientes que estén registrados con el mismo cargo y de la misma empresa.

Por otra parte, se realizaron dos entrevista semiestructuradas, teniendo como objetivo que la persona entrevistada brindara información relacionada con su participación dentro de la empresa y conocimiento del proceso de atención a los pacientes. Por tanto, la información obtenida se enfocó en la atención al paciente, el tipo de servicio y exámenes que se prestan, los exámenes que tienen un paso previo obligatorio, exámenes acorde al profesional o especialista, cantidad promedio de profesionales que prestan sus servicios a diario durante la operación y un estimado de pacientes que se atienden por día.

Durante la entrevista realizada al líder del proceso de DMO se logró obtener información detallada sobre su jornada en relación a las funciones desarrolladas en el puesto de trabajo, la cual se enfoca en la atención del paciente. Además, su carga administrativa, que está orientada en coordinar a los especialistas o profesionales para cada día, revisar las cuentas de cobro de los profesionales, estar al tanto de la ejecución y asistencia de las actividades de atención al cliente antes, durante y después de la prestación de los servicios.

La entrevista realizada al coordinador del área de calidad permitió obtener mayor certeza del orden y de las condiciones de obligatoriedad que se deben tener en cuenta durante el proceso de atención de los pacientes, necesario para el desarrollo del aplicativo y la secuencia de atención que este debe de seguir. También confirmó el promedio de pacientes atendidos y de profesionales que prestan sus servicios por día, resaltó además que los profesionales de planta son limitados y los complementarios se citan a trabajar un día antes o durante la jornada de atención dependiendo del estado actual de la jornada laboral y sala de espera.

38

Con el propósito de unificar las percepciones en cuanto al orden de atención a los pacientes, se realizó una reunión con los dos coordinadores, identificando que las principales necesidades están puesta en ordenar y mejorar la atención de los pacientes, de acuerdo a sus condiciones de atención, como son hora de llegada, cita y turno. También asegurar que el ciclo de atención de cada paciente sea ejecutado por completo. Asegurando, manteniendo y mejorando el orden y tiempo de atención de acuerdo a los prerrequisitos de cada examen, así como el número de pacientes atendidos por día, que puede ser un promedio de 150 pacientes. De la misma forma se aclaró que el orden adecuado de atención de los exámenes debe ser “laboratorio, preconsulta, espirometría, audiometría, valoración ergonómica, protectores auditivos, optometría, visiometría, valoración foniátrica e historia ocupacional”. Los cuales son realizados por un promedio de 17 profesionales o especialistas, distribuidos entre “fisioterapeutas, fonoaudiólogos, médicos, optómetras y Auxiliares de enfermería”.

En resumen, se logró obtener la información necesaria sobre el proceso manual para poderlo recrear de manera sistemática. Las dos preguntas que permitieron identificar las dos acciones de mayor valor que debe de cumplir el aplicativo fueron: ¿Cuál es el orden adecuado de atención para los exámenes? Y ¿Qué exámenes puede realizar cada tipo de especialista o profesional? (Ver anexo 7).

Una vez sistematizado el proceso, se tiene en cuenta la información con la cual trabaja el aplicativo, la cual es tomada de los registros ingresados al sistema de información de la empresa, durante el procesos se maneja información como datos de las empresas, servicios, usuario del sistema, la configuración de atención de cada examen y el registro de los paciente, brindando mayor claridad de lo que realmente debe efectuar el aplicativo.

7.1.1 Requerimientos funcionales

Los requerimientos funcionales (RQF) son declaraciones de los servicios que debe proporcionar el sistema, de la manera en que éste debe reaccionar a entradas particulares y de cómo se debe comportar en situaciones particulares. En algunos casos, los requerimientos funcionales de los sistemas también pueden declarar explícitamente lo que el sistema no debe hacer30.

30 Ibid., p. 12.

39

Se identifican a los actores que intervienen en los requerimientos:

- Técnico de sistemas.

- Orientador.

- Facturador.

- Auxiliar DMO.

- Profesional o especialista.

Teniendo en cuenta lo anterior se anexa una lista de los requerimientos funcionales de acuerdo a la plantilla IEEE- 83031.

RQF-1 El sistema deberá permitir el ingreso de los usuarios, por medio de un usuario y una contraseña para validar su existencia y permisos.

RQF-2 El sistema deberá permitir al técnico de sistemas la creación de una empresa, con la siguiente información requerida de manera obligatoria para su creación: Fecha de ingreso, empresa, nombre comercial, NIT, dirección, teléfono, ciudad, número de empleados, representante comercial, encargado, cargo del encargado, teléfono de encargado, activar la empresa.

RQF-3 El sistema deberá permitir al técnico de sistemas la edición de la siguiente información de la empresa: Pago, segmento, responsable comercial, caracterización, telefono2, encargado, teléfono, cargo, encargado2, teléfono, cargo, annarlab, tipo, código ARL, actividad económica, y demás conjunto de información que conforman las características sobre su atención.

RQF-4 El sistema deberá permitir al técnico de sistemas la eliminación de una o más empresas.

31 RUIZ, Francisco. Ingeniería del software, requisitos [en línea]. Universidad de Cantabria. España. (1998), P.

02. [Consultado 5 de noviembre de 2016]. Disponible en internet: https://www.istr.unican.es/asignaturas/is1/is1-t03-trans.pdf.

https://www.istr.unican.es/asignaturas/is1/is1-t03-trans.pdf

40

RQF-5 El sistema deberá permitir al técnico de sistemas la creación de la siguiente información de los servicios o exámenes: código, servicio, tipo, grupo.

RQF-6 El sistema deberá permitir al técnico de sistemas editar la siguiente información de los servicios o exámenes: código, servicio, tipo, grupo.

RQF-7 El sistema deberá permitir al técnico de sistemas la eliminación de uno o más servicios o exámenes.

RQF-8 El sistema deberá permitir al técnico de sistemas activar los servicios que se le prestarán a una empresa.

RQF-9 El sistema deberá permitir al técnico de sistemas desactivar los servicios que se le prestarán a una empresa.

RQF-10 El sistema deberá permitir al técnico de sistemas ingresar la configuración de atención de los exámenes y especialistas que pueden atender dichos exámenes.

- Fisioterapeuta: Espirometría, visiometría, val. Ergonómica.

- Fonoaudiólogo: Audiometría, val. Foniátrica, protectores auditivos.

- Optómetra: Optometría, visiometría.

- Auxiliar de enfermería: Preconsulta, laboratorio.

41

- Medico: Val. Médica, Val. Ergonómica.

RQF-11 El sistema deberá permitir al Tecnico de sistemas editar la configuración de atención de los exámenes y especialistas que pueden atender dichos exámenes.

- Fisioterapeuta: Espirometría, visiometría, val. Ergonómica.

- Fonoaudiólogo: Audiometría, val. Foniátrica, protectores auditivos.

- Optómetra: Optometría, visiometría.

- Auxiliar de enfermería: Preconsulta, laboratorio.

- Medico: Val. Médica, Val. Ergonómica.

RQF-12 El aplicativo deberá permitir al técnico de sistemas actualizar la configuración de atención de la empresa, examen y especialidad que puede atender dicho examen.

RQF-13 El aplicativo deberá permitir al técnico de sistemas la actualización del puerto de trasmisión de datos para enviar los datos a los consultorios asignados.

RQF-14 El sistema deberá permitir al orientador el registro de los datos básicos del paciente como: nombre, identificación, empresa remitente.

42

RQF-15 El sistema deberá permitir al orientador la generación del turno de atención de cada paciente.

RQF-16 El sistema deberá permitir al facturador el registro de las ordenes de atención con la siguiente información básica: Nombre del paciente, identificación del paciente, empresa remitente, empresa en misión, cargo, tipo de examen, si el paciente tiene cita, toma de foto del paciente, captura de la firma del paciente, servicios a realizar, encargado del pago del servicio.

RQF-17 El sistema deberá de permitir al profesional o especialista la atención del paciente, que ha sido asignado a su consultorio.

7.1.2 Requerimientos no funcionales

Son restricciones de los servicios o funciones ofrecidos por el sistema. Incluyen restricciones de tiempo, sobre el proceso de desarrollo y estándares. Los requerimientos no funcionales (RQNF) a menudo se aplican al sistema en su totalidad. Normalmente apenas se aplican a características o servicios individuales del sistema32.

1.1.1.8 Producción.

RQNF-1 El aplicativo debe establecer la conexión a la base de datos principal de la empresa, para cargar la información y los registros, para su respectivo procesamiento. (Conexión a través de IP y puerto).

RQNF-2 El aplicativo debe cargar todos los pacientes de la sala de espera “tabla sala de espera”, cerciorarse que la fecha de ingreso sea la del día actual y se encuentre con un estado diferente de “salió” o “atendido”, con un orden que está

32 OLIVERA SOSA, Ángel Gabriel. Planificación y modelado [en línea]. SCRIB. Campeche. (06 de septiembre

de 2010), P. 03. [Consultado: 01 de noviembre de 2015]. Disponible en internet: https://es.scribd.com/doc/37187866/Requerimientos-funcionales-y-no-funcionales#scribd..

https://es.scribd.com/doc/37187866/Requerimientos-funcionales-y-no-funcionales#scribd

43

dado por las horas de ingreso a la sala, el tipo de turno y si el paciente tiene cita previa o no.

RQNF-3 El aplicativo debe asignar una posición a cada paciente dentro de la sala de espera, para identificar el número de pacientes que actualmente estén activos en la sala de espera.

RQNF-4 El aplicativo debe cargar la configuración de atención ingresada al sistema de la empresa. Examen y especialidad que puede atender dicho examen: (Fisioterapeuta: Espirometría, Visiometría y/o valoración ergonómica; Fonoaudiólogo: Audiometría, Valoración foniátrica y/o protectores auditivos; Optómetra: Optometría; Auxiliares de enfermería: laboratorio y/o preconsulta; Médico: Valoración).

RQNF-5 El aplicativo debe identificar y cargar los equipos de cómputo que estén con sesión iniciada en el sistema y activos en la sala individual (sala de recepción de pacientes por parte del médico o especialista) del sistema.

RQNF-6 El aplicativo debe validar los pacientes que se encuentre en pendientes de algún examen para continuar con la valoración médica.

RQNF-7 El aplicativo debe poner en espera a todos los pacientes que identifique que no tienen exámenes pendientes.

RQNF-8 El aplicativo antes de iniciar el recorrido de búsqueda de consultorios para los pacientes, debe verificar el estado de los consultorios, si figuran con paciente asignado pero no están atendiendo a ningún paciente, estos consultorios se ponen en estado disponible para que se le asigne un paciente que requiera sus servicios.

RQNF-9 El aplicativo debe identifica si el paciente tiene algún especialista designado para la valoración médica.

44

RQNF-10 El aplicativo debe evaluar los exámenes que tenga cada paciente cargado de la sala de espera y que tengan su estado “pendiente”, por cada examen de cada paciente debe asignarle un consultorio en el cual se encuentre un especialista o profesional que pueda realizar el examen y que se encuentre disponible, para poder continuar con el siguiente paciente, se debe repetir esta búsqueda por todos los exámenes que tenga el paciente asignado, de no encontrar un consultorio disponible se continua con el siguiente paciente.

RQNF-11 El aplicativo debe identificar los pacientes que figuran asignados en un consultorio pero no están siendo atendidos hasta el momento, todos los pacientes que cumplan con esta condición deben de ponerse en espera y libres para cualquier consultorio.

RQNF-12 El aplicativo debe identificar a los pacientes que tengan todos los exámenes realizados, marcar el estado de estos pacientes como “atendidos” y no ser tenidos en cuenta para una próxima asignación.

RQNF-13 El aplicativo realizará el respectivo registro de todas las sentencias que se ejecuten en la base de datos durante su proceso, para poder realizar seguimiento de las actividades ejecutadas.

RQNF-14 El aplicativo debe permanecer realizando el ciclo de búsqueda de acuerdo a la ronda que realiza con la carga de los pacientes que se encuentre en sala de espera que no estén siendo atendidos.

Seguridad

RQNF-15 El aplicativo debe correr sobre un servidor que este ubicado dentro de la red interna de la empresa o sede, para su apropiado consumo de transacciones y correcta comunicación (equipo en el cual este instalada la base de datos).

45

RQNF-16 El aplicativo debe contar con control de errores en la concesión a la base de datos.

RQNF-17 El aplicativo podrá ser manipulado y administrador por quien esté autorizado a ingresar con el usuario de administrador al servidor.

Mantenibilidad

RQNF-18 El aplicativo debe permitir la modificación del puerto de comunicación con las salas individual activas, (para facilitar algún movimiento en el uso de los puertos dentro de la red LAN).

RQNF-19 El mantenimiento de la base de datos con las cual se comunica el aplicativo deberá ser realizado de acuerdo a los tiempos estipulados del sistema principal de la empresa.

Disponibilidad

RQNF-20 El aplicativo debe estar lo más visible posible para su puesta en marcha, y debe permanecer activo durante toda la jornada laboral.

RQNF-21 El aplicativo debe estar constantemente consultado la existencia de pacientes disponibles para atender en la sala de espera.

Fiabilidad

RQNF-22 El aplicativo debe tener control de errores, de tal forma que genere un log de errores y manejar un nivel de excepciones que no permitan que aplicativo se detenga.

46

7.1.3 Clasificación de los requerimientos

La clasificación ayuda a determinar que requerimientos se desarrollan o no, a acotarlos en los requerimientos funcionales.

Para clasificarlos se deben tomar en cuenta los diferentes tipos de requerimientos que se muestran en la tabla N° 133.

Tabla 1. Clasificación de los requerimientos

CLASIFICACION DE LOS REQUERIMIENTOS

SW Requerimiento de Software (funcional)

SWC Requerimiento Restricción de Software (no funcional)

DR Requerimiento Derivado

D# Requerimiento Duplicado

HW Requerimiento de Hardware

NTH Requerimiento deseable pero no necesario para el sistema

A continuación se muestra la tabla de clasificación de prioridad para identificarlo en cada requerimiento.

Tabla 2. Grado de prioridad

P: Prioridad

A Alta

M Media

A continuación se muestra los autores encargados

33 PEREZ, J. Especificación de requerimientos de software [en línea]. SlideShare. (23 de junio de 2009), P. 56.

[Consultado: 01 de noviembre de 2015]. Disponible en internet: https://es.slideshare.net/Jgperez/especificacion-de-requerimentos-de-software.

https://es.slideshare.net/Jgperez/especificacion-de-requerimentos-de-software

47

Tabla 3. Autores

A continuación se muestra una matriz de los requisitos trazados funcionales (RTM).

AU: Autores

CB Camilo Balanta

Tabla 4. Análisis de Requerimientos Funcionales (RTM)

ANALISIS DE REQUERIMIENTOS FUNCIONALES

ID. REQ. DESCRIPCIÓN AU SW SWC DR D# HW NTH P

RQF- 01 El sistema deberá permitir el ingreso de los usuarios, por medio de un usuario y una contraseña para validar su existencia y permisos. CB X M

RQF- 02

El sistema deberá permitir al técnico de sistemas la creación de una empresa, con la siguiente información requerida de manera obligatoria para su creación: Fecha de ingreso, empresa, nombre comercial, NIT, dirección, teléfono, ciudad, número de empleados, representante comercial, encargado, cargo del encargado, teléfono de encargado, activar la empresa.

CB X A

RQF- 03

El sistema deberá permitir al técnico de sistemas la edición de la siguiente información de la empresa: Pago, segmento, responsable comercial, caracterización, telefono2, encargado, teléfono, cargo, encargado2, teléfono, cargo, annarlab, tipo, código ARL, actividad económica, y demás conjunto de información que conforman las características sobre su atención.

CB X X M

RQF- 04 El sistema deberá permitir al técnico de sistemas la eliminación de una o más empresas. CB X X M

RQF- 05 El sistema deberá permitir al técnico de sistemas la creación de la siguiente información de los servicios o exámenes: código, servicio, tipo, grupo.

CB X A

RQF- 06 El sistema deberá permitir al técnico de sistemas editar la siguiente información de los servicios o exámenes: código, servicio, tipo, grupo.

CB X X M

49

Tabla 4. (Continuación).


RQF- 07 El sistema deberá permitir al técnico de sistemas la eliminación de uno o más servicios o exámenes.

CB X X M

RQF- 08 El sistema deberá permitir al técnico de sistemas activar los servicios que se le prestarán a una empresa.

CB X M

RQF -09 El sistema deberá permitir al técnico de sistemas desactivar los servicios que se le prestarán a una empresa.

CB X X A

RQF- 10

El sistema deberá permitir al técnico de sistemas ingresar la configuración de atención de los exámenes y especialistas que pueden atender dichos exámenes.

Fisioterapeuta: Espirometría, visiometría, val. Ergonómica.

Fonoaudiólogo: Audiometría, val. Foniátrica, protectores auditivos.

Optómetra: Optometría, visiometría.

Auxiliar de enfermería: Preconsulta, laboratorio

Médico: Val. Médica, Val. Ergonómica.

CB X A

50



RQF- 11

El sistema deberá permitir al técnico de sistemas editar la configuración de atención de los exámenes y especialistas que pueden atender dichos exámenes.

Fisioterapeuta: Espirometría, visiometría, val. Ergonómica.

Fonoaudiólogo: Audiometría, val. Foniátrica, protectores auditivos.

Optómetra: Optometría, visiometría.

Auxiliar de enfermería: Preconsulta, laboratorio

Médico: Val. Médica, Val. Ergonómica.

CB X X M

RQF- 12

El aplicativo deberá permitir al técnico de sistemas actualizar la configuración de atención de la empresa, examen y especialidad que puede atender dicho examen.

CB X M

RQF- 13

El aplicativo deberá permitir al técnico de sistemas la actualización del puerto de trasmisión de datos para enviar los datos a los consultorios asignados.

CB X M

51

Tabla 4. Continuación.


RQF-14

El sistema deberá permitir al orientador el registro de los datos básicos del paciente como: nombre, identificación, empresa remitente.

CB X M

RQF- 14 El sistema deberá permitir al orientador la generación del turno de atención de cada paciente. CB X A

RQF- 15

El sistema deberá permitir al facturador el registro de las ordenes de atención con la siguiente información básica: Nombre del paciente, identificación del paciente, empresa remitente, empresa en misión, cargo, tipo de examen, si el paciente tiene cita, toma de foto del paciente, captura de la firma del paciente, servicios a realizar, encargado del pago del servicio.

CB X A

RQF- 16 El sistema deberá de permitir al profesional o especialista la atención del paciente, que ha sido asignado a su consultorio.

CB X M

52

A continuación se muestra una matriz de los requisitos trazados no funcionales (RTM).

Tabla 5. Análisis de requerimientos no funcionales.

ANALISIS DE REQUERIMIENTOS NO FUNCIONALES


RQNF-1

El aplicativo debe establecer la conexión a la base de datos principal de la empresa, para cargar la información y los registros, para su respectivo procesamiento. (Conexión a través de IP y puerto).

CB X A

RQNF-2

El aplicativo debe cargar todos los pacientes de la sala de espera “tabla sala de espera”, cerciorarse que la fecha de ingreso sea la del día actual y se encuentre con un estado diferente de “salió” o “atendido”, con un orden que está dado por las horas de ingreso a la sala, el tipo de turno y si el paciente tiene cita previa o no.

CB X M

RQNF-3 El aplicativo debe asignar una posición a cada paciente dentro de la sala de espera, para identificar el número de pacientes que actualmente estén activos en la sala de espera.

CB X A

RQNF-4

El aplicativo debe cargar la configuración de atención ingresada al sistema de la empresa. Examen y especialidad que puede atender dicho examen: (Fisioterapeuta: Espirometría, Visiometría y/o valoración ergonómica; Fonoaudiólogo: Audiometría, Valoración foniátrica y/o protectores auditivos; Optómetra: Optometría; Auxiliares de enfermería: laboratorio y/o preconsulta; Médico: Valoración).

CB X A

53



RQNF-5

El aplicativo debe identificar y cargar los equipos de cómputo que estén con sesión iniciada en el sistema y activos en la sala individual (sala de recepción de pacientes por parte del médico o especialista) del sistema.

CB X A

RQNF-6 El aplicativo debe validar los pacientes que se encuentre en pendientes de algún examen para continuar con la valoración médica.

CB X A

RQNF-7 El aplicativo debe poner en espera a todos los pacientes que identifique que no tienen exámenes pendientes.

CB X A

RQNF-8

El aplicativo antes de iniciar el recorrido de búsqueda de consultorios para los pacientes, debe verificar el estado de los consultorios, si figuran con paciente asignado pero no están atendiendo a ningún paciente, estos consultorios se ponen en estado disponible para que se le asigne un paciente que requiera sus servicios.

CB X A

RQNF-9 El aplicativo debe identifica si el paciente tiene algún especialista designado para la valoración médica.

CB X A

54



RQNF-10

El aplicativo debe evaluar los exámenes que tenga cada paciente cargado de la sala de espera y que tengan su estado “pendiente”, por cada examen de cada paciente debe asignarle un consultorio en el cual se encuentre un especialista o profesional que pueda realizar el examen y que se encuentre disponible, para poder continuar con el siguiente paciente, se debe repetir esta búsqueda por todos los exámenes que tenga el paciente asignado, de no encontrar un consultorio disponible se continua con el siguiente paciente.

CB X A

RQNF-11

El aplicativo debe identificar los pacientes que figuran asignados en un consultorio pero no están siendo atendidos hasta el momento, todos los pacientes que cumplan con esta condición deben de ponerse en espera y libres para cualquier consultorio.

CB X A

RQNF-12

El aplicativo debe identificar a los pacientes que tengan todos los exámenes realizados, marcar el estado de estos pacientes como “atendidos” y no ser tenidos en cuenta para una próxima asignación.

CB X A

RQNF-13

El aplicativo realizará el respectivo registro de todas las sentencias que se ejecuten en la base de datos durante su proceso, para poder realizar seguimiento de las actividades ejecutadas.

CB X A

55



RQNF-14

El aplicativo debe permanecer realizando el ciclo de búsqueda de acuerdo a la ronda que realiza con la carga de los pacientes que se encuentre en sala de espera que no estén siendo atendidos.

CB X A

RQNF-15

El aplicativo debe correr sobre un servidor que este ubicado dentro de la red interna de la empresa o sede para su apropiado consumo de transacciones y correcta comunicación (equipo en el cual este instalada la base de datos).

CB

X X A

RQNF-15

El aplicativo debe contar con control de errores en la concesión a la base de datos.

CB X X A

RQNF-17

El aplicativo podrá ser manipulado y administrador por quien esté autorizado a ingresar con el usuario de administrador al servidor.

CB X X A

RQNF-18

El aplicativo debe permitir la modificación del puerto de comunicación con las salas individual activas, (para facilitar algún movimiento en el uso de los puertos dentro de la red LAN).

CB X X M

RQNF-19

El mantenimiento de la base de datos con las cual se comunica el aplicativo deberá ser realizado de acuerdo a los tiempos estipulados del sistema principal de la empresa.

CB X X M

RQNF-20

El aplicativo debe estar lo más visible posible para su puesta en marcha, y debe permanecer activo durante toda la jornada laboral.

CB X M

56



RQNF-21

El aplicativo debe estar constantemente consultando la existencia de pacientes disponibles para atender en la sala de espera. CB X M

RQNF-22

El aplicativo debe tener control de errores, de tal forma que genere un log de errores y manejar un nivel de excepciones que no permitan que aflictivo se detenga.

CB X A

Para tener mayor claridad sobre el punto en el cual el aplicativo (repartidor) interviene durante el proceso operativo y la función que este debe desempeñar, se diseña un diagrama general del proceso, que ilustra un paciente y un servicio tal y como se muestra en la figura N° 2. Es importante tener en cuenta los siguientes conceptos:

Orientación: Proceso de orientación del paciente en el inicio de su proceso y asignación de turno, dirigido por el orientador.

Facturación: Proceso de registro del paciente y vinculación de los servicios que se debe realizar, dirigido por el facturador.

Sala de espera: Proceso en el cual el paciente espera su llamado a los diferentes consultorios, para la realización de los exámenes registrados previamente por el facturador.

Repartidor: Proceso mediante el cual se distribuyen los pacientes en espera, a los consultorios que cumplan con sus condiciones de atención. Actividad realizada por el aplicativo.

Consultorio: Lugar en el cual se llevan a cabo los procesos de los exámenes registrados por parte de un profesional de la salud.

Figura 2. Diagrama general del proceso

Fuente: Elaboración propia.

Para describir el esquema general previamente presentado, se presenta la tabla N° 6.

58

Tabla 6. Descripción paso a paso del diagrama general (figura 2)

DESCRIPCIÓN ESQUEMA GENERAL

DIAGRAMA GENERAL: Proceso completo de un paciente, con un servicio

Actor: Paciente.

1. Paciente pasa con el orientador para el registro de datos básicos.

2. Paciente pasa a la caja para registrar los exámenes a realizar.

3. Paciente pasa a la sala de espera y es orientado por el auxiliar de DMO.

4. El paciente recibe un llamado, en el cual le informan que lo esperan en un consultorio determinado

5. Paciente se dirige al consultorio en el cual es atendido por un profesional.

6. En el momento en el cual el profesional termine de atender al paciente, este finaliza su proceso y debe dirigirse al auxiliar DMO para ser despachado.

Se presenta el caso de uso de las acciones que realiza el técnico en sistemas para garantizar el servicio dentro de la empresa. Son las actividades que se requieren realizar en el sistema de información de la empresa para poder alimentar la fuente de datos del aplicativo (Ver figura 3).

Cabe destacar las siguientes características que se deben tener en cuenta en los casos de uso del aplicativo

- Actores:

Son una agrupación uniforme de personas, sistemas o máquinas que interactúan con el sistema que está en construcción de la misma forma. Por ejemplo, para una empresa que recibe pedidos en forma telefónica, todos los operadores que reciban pedidos y los ingresen en un sistema de ventas, si pueden hacer las mismas cosas con el sistema, son considerados un único actor34.

34 BERZAL GALIANO, Fernando. Relaciones entre clases, diagramas de clases UML [en línea]. Elvex.

España. (01 de julio de 2015), P. 01.[Consultado: 01 de noviembre de 2015]. Disponible en internet: http://elvex.ugr.es/decsai/java/pdf/3C-Relaciones.pdf.

http://elvex.ugr.es/decsai/java/pdf/3C-Relaciones.pdf

59

- Relaciones:

Son formas de conectividad, para objetos del presente estudio, se hará uso de la relación de asociación, ya que es la más básica que indica la invocación desde un actor o caso de uso a otra operación (caso de uso). Dicha relación se denota con una flecha simple35.

Figura 3. Diagrama de creación de usuario


Tabla 7. Descripción paso a paso de caso de uso (Figura 3)

DESCRIPCIÓN CASO DE USO

CASO DE USO: El técnico de sistemas ingresa un usuario al sistema.

Actor: Técnico de sistemas

1. El técnico de sistemas registra los datos básicos del usuario.

35 Ibid., p. 02.

60

A continuación se presentan la descripción de los dos casos extendidos del proceso del caso de uso anterior. Cabe mencionar que estos pueden ser ejecutados una vez se haya ingresado un usuario.

Tabla 8. Descripción paso a paso de caso de uso extendido

DESCRIPCIÓN CASO DE USO EXTENDIDO



1. El técnico de sistemas edita la información registrada con anterioridad de un usuario.

2. El técnico de sistemas elimina información de un usuario

A continuación se presenta una alternativa del proceso del caso de uso anterior.

Tabla 9. Descripción paso a paso de caso de uso alternativo

DESCRIPCIÓN CASO DE USO ALTERNATIVO



1. El técnico de sistemas registra los datos básicos del usuario.

2. El técnico de sistemas edita la información registrada con anterioridad de un usuario.

2.1. Si no se registran los datos básicos del usuario, no se ejecuta esta acción.

3. El técnico de sistemas elimina información de un usuario

3.1. Si no se registran los datos básicos del usuario, no se ejecuta esta acción.

61

Figura 4. Diagrama de creación de empresas

Fuente: Elaboración propia



CASO DE USO: El técnico de sistemas ingresa una empresa al sistema.


2. El técnico de sistemas registra los datos básicos de la empresa.

A continuación se presentan la descripción de los dos casos extendidos del proceso del caso de uso anterior. Una vez realizado el caso de uso anterior, es posible ejecutar alguno de los dos casos de uso asociados.





3. El técnico de sistemas edita la información registrada con anterioridad de una empresa.

4. El técnico de sistemas elimina información de una empresa

62



DESCRIPCIÓN CASO DE USO ALTERNATIVA



4. El técnico de sistemas registra los datos básicos de la empresa.

5. El técnico de sistemas edita la información registrada con anterioridad de la empresa.

5.1. Si no se registran los datos básicos de la empresa, no se ejecuta esta acción.

6. El técnico de sistemas elimina información la empresa

6.1. Si no se registran los datos básicos de la empresa, no se ejecuta esta acción.

Figura 5. Diagrama de creación de servicios


63





3. El técnico de sistemas registra los datos del servicio.




CASO DE USO: El técnico de sistemas ingresa un servicio al sistema.


5. El técnico de sistemas edita la información registrada con anterioridad de un servicio.

6. El técnico de sistemas elimina información de un servicio




CASO DE USO: El técnico de sistemas ingresa un servicio al sistema.


7. El técnico de sistemas registra los datos del servicio.

8. El técnico de sistemas edita la información registrada con anterioridad del servicio.

8.1. Si no se registran los datos básicos de los servicios, no se ejecuta esta acción.

9. El técnico de sistemas elimina información del servicio.

9.1. Si no se registran los datos básicos de los servicios, no se ejecuta esta acción.

64

Figura 6. Diagrama de configuración del sistema

Fuente: Elaboración propia


DESCRIPCIÓN CASO DE USO CASO DE USO: El técnico de sistemas ingresa la configuración de atención

al sistema. Actor: Técnico de sistemas

1. El técnico de sistemas, asigna eximes para cada tipo de especialista o profesional.



DESCRIPCIÓN CASO DE USO EXTENDIDO CASO DE USO: El técnico de sistemas ingresa la configuración de atención

al sistema. Actor: Técnico de sistemas

1. El técnico de sistemas, edita la asignación de exámenes para cada tipo de especialista o profesional.

2. El técnico de sistemas, elimina la asignación de exámenes para cada tipo de especialista o profesional.


65


DESCRIPCIÓN CASO DE USO ALTERNATIVO CASO DE USO: El técnico de sistemas ingresa la configuración de

atención al sistema. Actor: Técnico de sistemas

1. El técnico de sistemas, asigna examenes para cada tipo de especialista o profesional.

2. El técnico de sistemas edita la información registrada con anterioridad de la configuración de atención.

2.1. Si no se registran los datos de asignación de exámenes para cada tipo de especialista o profesional, no se ejecuta esta acción.

3. El técnico de sistemas eliminar la información registrada con anterioridad de la configuración de atención.

3.1. Si no se registran los datos de asignación de exámenes para cada tipo de especialista o profesional, no se ejecuta esta acción.

66

Figura 7. Caso de uso de ingreso de pacientes




CASO DE USO: El orientador ingresa y genera turno, para la atención del paciente.

Actor: Orientador

1. El orientador registra los datos básicos del paciente.

2. El orientador genera el turno de atención para el paciente.



DESCRIPCIÓN CASO DE USO ALTERNATIVO

CASO DE USO: El orientador ingresa y genera turno, para la atención del paciente.

Actor: Orientador

1. El orientador Registra los datos básico del paciente.

2. El orientador genera el turno de atención para el paciente.

2.1. Si no se registran los datos básicos del paciente, no se ejecuta esta acción.

67

En el siguiente caso de uso se muestra las acciones requeridas para el registro de los paciente, este genera de manera automática por parte del sistema él envió del paciente a la sala de espera.

Figura 8. Caso de uso de registro de pacientes




CASO DE USO: El cajero registra al paciente y los exámenes a realizarse.

Actor: Cajero

1. El cajero registra los datos del paciente.

2. El cajero registra los servicios o exámenes que se va a realizar el paciente.


68



CASO DE USO: El cajero registra al paciente y los exámenes a realizarse.

Actor: Cajero

1. El cajero registra los datos del paciente.

1.1. Si el paciente no tiene turno, debe de ser enviado al área de orientación al cliente.

2. El cajero registra los servicios o exámenes que se va a realizar el paciente.

2.1. Si no se registran los datos del paciente, no se ejecuta esta acción.

7.2 DISEÑO

Una vez identificado el problema, el departamento de sistemas de la empresa USO, se reunió y realizó una lluvia de ideas, en la que se pretendía solucionar o darle manejo al problema identificado, además se expusieron diferentes soluciones en las que en un momento inicial destacaron: aumentar el personal en el área de DMO para lograr mayor control con las ordenes de los pacientes, tener una orden por cada paciente y no por cada examen, permitir que cada médico seleccionara el paciente desde al sistema de información directamente, entre otras. El proceso de selección de la alternativa escogida finalizó con una solicitud puntual para el departamento de sistemas, el cual logró concluir en la creación de un aplicativo que se encargara de dicha problemática.

La solicitud del aplicativo se analizó con la recolección de la información que se ejecutó para tener mayor claridad y conocimiento sobre la problemática puntual que se estaba presentando en la empresa. Una vez terminada la fase de recolección de los requerimientos, empezó un proceso de diseño, estructurando la forma de crear este aplicativo con las herramientas necesarias y con las que estuvieran dentro del alcance de las personas encargadas.

Con una mayor claridad de la intervención del aplicativo y con los requerimientos recolectados, empezó la estructuración del cuerpo a proyecto, para esto se hizo

69

uso del lenguaje grafico UML ya que además de ser reconocida y de fácil manejo, responde de manera adecuada a los requerimientos del aplicativo a diseñar.

Normalmente los diagramas de entidad relación están orientados a esquemas de bases de datos, permitiendo representar la estructura lógica de cualquier sistema de datos36. Los elementos de este diagrama son:

Entidad: Es un objeto que existe y que es distinto de otros. puede ser abstracta o física.

Atributo: es una propiedad de una entidad.

Relación: es una asociación entre dos o más entidades.37

Haciendo uso de estos elementos se modelan los datos que interviene en el proceso de atención al paciente.

El proceso de atención se divide en seis etapas, en las que en cada una de ellas el paciente es el principal actor (figura 9)

Etapa 1: Los pacientes ingresan al sistema desde orientación al usuario y luego pasan pos caja, donde se realiza el paso a la sala de espera. Se requiere identificar el ingreso a la sala de espera para iniciar el ciclo de atención.

Etapa 2: Los pacientes ingresados a la sala de espera son organizados por prioridades previamente definidas, también ingresan con información necesaria para ser atendidos por los profesionales o especialista. Los datos obligatorios para su proceso normal son: hora de ingreso, hora de la cita, cita, empresa, nombre, cedula, consultorio, estado, laboratorio, preconsulta, audiometría, espirometría,

36 SANCHEZ, Salvador., SICILIA, Miguel., RODRIGUEZ, Daniel. Ingeniería de software. Un enfoque desde la guía SWEBOK. Colombia. 2012. . Alfaomega, P. 152.

37 Ibid., p. 152.

70

laboratorio, visiometría, valoración ergonómica, valoración foniátrica, protectores auditivos, optometría, medico ocupacional y especialista asignado.

Etapa 3: Los consultorios son utilizados por los profesionales o especialistas, estos son usuarios de sistema y deben estar activos para poder prestar la debida atención, además, no deben estar atendiendo a ningún otro paciente. Para esto se debe de conocer el cargo, el estado, la disponibilidad y consultorio.

Etapa 4: El usuario debe estar activo en el sistema para poder ingresar y realizar su labor. Para esto se debe saber si está activo, el cargo, nombre y el área.

Etapa 5: La asignación de los paciente a los consultorios está controlada por la configuración de atención del sistema, si se va a asignar un paciente a un consultorio, fuera de que el paciente debe está disponible, el consultorio también debe estar disponible, el usuario que se encuentre activo en el consultorio debe corresponder al cargo que está especificado en la configuración que puede realizar dicho examen. Para esto se debe conocer cuál es la especificación de atención por examen para cada cargo.

Etapa 6: El paciente es llamado para su atención en el consultorio que cumpla con la configuración de atención y estado activo y disponible.

Figura 9. Diagrama general de entidad - relación


72

7.2.1 Arquitectura Cliente/servidor

La empresa actualmente cuenta con un sistema que funciona bajo la arquitectura cliente/servidor, esta estructura es la utilizada por el sistema de información de actual de la empresa. El aplicativo trabajara bajo la misma arquitectura, permitiendo la adecuada compatibilidad y minimizando el riesgo de traumatismos en la implantación, evitando modificaciones físicas o lógicas en la estructura ya implementada. Cabe mencionar que esta arquitectura se divide en dos partes claramente diferenciadas. La primera es la parte del servidor y la segunda son los clientes38.

Normalmente el servidor es una maquina bastante potente que actúa de depósito de datos y funciona como un sistema gestor de bases de datos (SGBD). Y los clientes, suelen ser estaciones de trabajo que solicitan varios servicios al servidor. Ambas partes deben estar conectadas entre sí mediante una red, como se muestra en la figura N° 10.

Figura 10. Arquitectura cliente/servidor


38 ALVAREZ, Sara. Arquitectura cliente-servidor [en línea]. Desarrollo web. (30 de agosto de 2007), Par. 02.

[consultado: 10 de septiembre de 2017]. Disponible en internet: https://desarrolloweb.com/articulos/arquitectura-cliente-servidor.html.

https://desarrolloweb.com/articulos/arquitectura-cliente-servidor.html

73

Esta arquitectura necesita de tres tipos de software para su correcto funcionamiento:

Software de gestión de datos: Este software se encarga de la manipulación y gestión de los datos almacenados y requeridos por las diferentes aplicaciones. Normalmente este software se aloja en el servidor.

Software de desarrollo: Este tipo de software se aloja en los clientes y solo en aquellos que se dediquen al desarrollo de aplicaciones.

Software de interacción con los usuarios: También reside en los clientes y es la aplicación grafica de usuario para la manipulación de datos, siempre claro a nivel usuario (consultas principalmente)39.

Se realizó un levantamiento de la estructura de la Red de la empresa para estar seguros de que esta no presentaría obstáculos al momento de la conectividad en la implantación del aplicativo.

7.2.2 Red de la empresa

La empresa USO, cuanta con una Red LAN interna, la cual está distribuida por toda la empresa, dentro de esta red se han separados tres zonas, dos operativas y la administrativa, se cuenta con un datacenter que está compuesto por un rack principal, dentro del cual se encuentran los servidores de diversas aplicaciones como la telefonía e CGUNO, etc., se encuentran swichis y patch panel, el servidor de control de dominio y el servidor principal que contiene la base de datos, el sistema de información empresarial y el aplicativo. De este datacenter principal se desprenden la comunicación hacia todas las áreas de la empresa.

Esta arquitectura se puede interpretar teniendo en cuenta la Figura N° 11.

39 VASQUEZ, Sol. Definición de sistema operativo [en línea]. Wordpress. (25 de enero de 2011), Par. 16.

[Consultado 10 de septiembre de 2017]. Disponible en internet: https://solvasquez.wordpress.com/2011/01/24/definicion-de-sistema-operativo/.

https://solvasquez.wordpress.com/2011/01/24/definicion-de-sistema-operativo/

74

Figura 11. Red LAN interna


A continuación se describe mediante un diagrama de secuencia la interacción que tiene el usuario con el sistema de información en el proceso de orientación al usuario (Figura 12).

75

Figura 12. Diagrama de secuencia de orientación


A continuación Se describe mediante un diagrama de secuencia la interacción que tiene el usuario con el sistema de información, en el proceso de facturar al usuario (Figura 13).

76

Figura 13. Diagrama de secuencia de facturación


A continuación se describe mediante un diagrama de secuencia la interacción que tiene el técnico de sistemas con el sistema de información, en el proceso de creación de un usuario del sistema (Figura 14).

77

Figura 14. Diagrama de creación de usuario


A continuación Se describe mediante un diagrama de secuencia la interacción que tiene el técnico de sistemas con el sistema de información, en el proceso de creación de una empresa en el sistema (Figura 15).

78

Figura 15. Diagrama de creación de empresa


A continuación Se describe mediante un diagrama de secuencia la interacción que tiene el técnico de sistemas con el sistema de información, en el proceso de creación de un servicio del sistema (Figura 16).

79

Figura 16. Diagrama de creación de servicio


80

7.2.3 Diagrama de flujo

Un diagrama de flujo es una representación gráfica de un proceso. Cada paso del proceso es representado por un símbolo diferente que contiene una breve descripción de la etapa del proceso40. Se realizará una aclaración de las operaciones que se llevaron a cabo dentro de cada uno de los procedimientos.

El formulario se llama e inicia su actividad mediante la activación de un procedimiento que activa todos los demás subprocesos, sin este llamado inicial los demás procesos no podrían ser ejecutados, por este motivo es necesario tener claridad sobre qué es un proceso y qué son subprocesos.

Los procesos son equivalentes a los procedimientos informáticos, donde los procedimientos terminan siendo un conjunto de instrucciones para realizar una sola tarea determinada. Los subprocesos hacen parte de un proceso lógico más grande que ellos.

A continuación se presenta el diagrama de flujo del aplicativo (ver figura 17).

40 AITECO CONSULTORES. Qué es un diagrama de flujo, gestión de procesos [en línea]. Aiteco consultores.

España. 2016, Par. 01. [Consultado: 16 de mayo de 2017]. Disponible en internet: https://www.aiteco.com/diagrama-de-flujo/.

https://www.aiteco.com/diagrama-de-flujo/

81

Fuente: Elaboración propia. |

Figura 17. Diagrama de flujo

82

8.2.1.1 Evento Temporizador

Inicia tiempo mínimo para ejecutar el proceso de distribución, dentro de este se obtiene el llamado a “estadoinicio” procedimiento que ejecuta el proceso de “liberarpendiente”. También se inicia la variable “ronda”, esta es la encargada de marcar he identificar si un consultorio está ocupado o no.

8.2.1.2 Liberar pendiente

“Dentro del sistema de información de la empresa se realizan las historias clínicas ocupacionales, estas tiene la opción de poner las historias en estado pendiente (PEN), permitiendo que el paciente no sea re-asignado a ningún consultorio hasta que no se cumpla una cierta condición, que es la que se evalúa dentro del procedimiento “liberarpendiente” (Ver anexo 2).

Lo que se valida, es que el paciente no tenga ningún examen en espera, que los resultados de laboratorios estén completos, que no le haga falta ningún otro examen solo la finalización de las historia clínica ocupacional.

8.2.1.3 Procedimiento “estadoinicio”

Dentro de este procedimiento se realiza la asignación del puerto y la activación del serversocket.

También se realiza la validación y la toma de información de si se le ha marcado de forma manual que se está atendiendo en el segundo piso, o si la atención es por consultorios (Ver anexo 1).

8.2.1.4 Procedimiento “posicionar”

Este procedimiento cumple la función de asignar un número o posición a cada paciente dentro de la sala de espera.

83

8.2.1.5 Procedimiento “reconectar”

Este procedimiento es el encargado de recordarle al socket cuál es su puerto de comunicaciones.

8.2.1.6 Procedimiento “refrescar”

Este procedimiento se encarga de evaluar el estado de los consultorios para determinar si está atendiendo, disponible u ocupado con algún paciente.

También valida el estado de los pacientes solicitando el procedimiento “CambioEstado”, cuando es validado el estado de los consultorios y de los pacientes, se envía señal para que los consultorios refresquen su estado a través de la función SendToAllClients del componente Socket.

Una vez enviada la señal, se ejecuta el procedimiento “cargatabla” para continuar con las validaciones y la asignación de pacientes a los consultorios (Ver anexo 3).

8.2.1.7 Procedimiento “Validaestado”

Se cargan todos los pacientes del día que no estén en estado de “salió”, se evalúa examen por examen si el estado es igual a “no” o por el contrario el estado de cada examen es igual a “ATE”, cada paciente que el conjunto de exámenes que tenga, cumplan con una de estas dos características para poder dar por atendido a un paciente para que en sala de espera lo puedan despachar (Ver anexo 6).

84

8.2.1.8 Procedimiento “Cambioestado”

Este procedimiento cumple la función de validar si los estados cumplen con las características necesarias para determinar si un paciente debe estar en estado pendiente “disponible para que lo atiendan”, todas las variables necesarias quedan en estado disponible (Ver anexo 4).

8.2.1.9 Procedimiento “cargatabla”

Dentro de este procedimiento se ejecuta el procedimiento “validaestado”. Luego se realiza el proceso de reordenar las posiciones de los pacientes en las sala de espera, mediante el procedimiento posicionar.

Se cargan los pacientes para asignarlos a los consultorios disponibles, con estos se identifican la cantidad de turnos “B” que hay listos para ser repartidos en la sala vip, conociendo la cantidad de turnos B que son los primeros en la lista se ejecuta el procedimiento “Consultorios”, que es el encargado de asignar y marcar el paciente a cada consultorio especifico se ejecuta la función SendToAllClients este envía la señal para que los consultorios refresquen su estado y llamen al paciente asignado (ver anexo 5).

8.2.1.10 Procedimiento “consultorios”

Este procedimiento es el encargado de realizar el filtro inicial para poder asignar un paciente con un médico. Primero debe cumplir con unos requisitos como la preconsulta y los demás exámenes paraclínicos que se le hayan registrado en su orden de servicio, para poder pasar a su examen ocupacional.

Dentro de todo este procedimiento de validación, se encuentra el proceso de asignación de los usuarios a todos los demás exámenes paraclínicos que tenga registrados, teniendo en cuenta que no solo el examen médico tiene restricciones para poder ser asignados. Un paso que es prácticamente obligatorio para la mayoría de los paraclínicos es la preconsulta. Una vez que se haya identificado un examen dentro de los paraclínicos que tiene registrado un paciente, se continua revisando el tipo de turno que tiene; con este turno se valida si esta activa la sala

85

VIP (que es el lugar donde se atienden a los turnos “B” por preferencia) y se validan que no esté activa la asignación de consultorios por tuno que tenga el paciente:

A = paciente con antecedentes en el sistema.

B = paciente con prefectura realizada o con cita previa.

C = paciente que no posee antecedentes en la empresa.

De acuerdo a esto se comienza a armar las condicionales para la búsqueda del consultorio. Luego se evalúa si la ronda entre distribución y búsqueda de consultorios se realizó en orden ascendente, o descendente para mantener equilibrada la forma de distribución sobre los consultorios, que todos tenga el mismo número de oportunidades de atender pacientes (se agrega un “Order by” a la búsqueda de consultorios).

Con las condicionales y el examen identificado se realiza el cargue de la información sobre los consultorios. Siempre se toma la primera opción de consultorio disponible.

En el momento en el cual se realiza el cargue sobre los consultorios, se ejecuta el marcado en la sala de espera, una vez actualizada la sala, se efectúa el registro del paciente, la especialidad, la fecha, la hora; entre otros datos básicos para medir y garantizar trazabilidad de la distribución realizada.

Si en dado caso no es posible encontrar consultorio disponible para examen en este preciso momento, el proceso se inicia de nuevo pero para el siguiente examen que tenga registrado el paciente, y de esta manera se realiza el recorrido sobre los exámenes registrados a cada paciente (ver figura 18).

86

Figura 18. Diagrama de flujo de Procedimiento consultorios


87

7.3 IMPLEMENTACIÓN

Para el adecuado funcionamiento y prestación del servicio en la USO, el sistema de información trabaja con el motor de base de datos MYSQL que “se encarga de los detalles de entrada-salida y representación de la información en memoria secundaria”41, este sistema está diseñado bajo el concepto de cliente-servidor, contando a su vez con una red LAN interna la cual permite la intercomunicación entre todos los equipos de la empresa, como se explica en el siguiente apartado. De esta manera el aplicativo, usa la información existente en el MYSQL para lograr el respectivo proceso de distribución de pacientes que se encuentran en sala de espera, de la misma forma hace uso de la red interna ya construida para identificar cada uno de los consultorios.

El sistema de información de la USO, está desarrollado bajo el IDE Rad Estudio, y es la plataforma usada por defecto dentro de la empresa, por este motivo se continúa haciendo uso de las herramientas tecnológicas con la que cuenta la empresa.

En relación a lo anterior, en la figura N° 21 se muestra el aplicativo en funcionamiento con la operación, después de haber pasado las pruebas de correctitud de distribución de los pacientes de la sala de espera.

Además, En el anexo N° 8 se observa la secuencia distribución por tiempos de tiempos de los pacientes en el aplicativo, a través de un reporte que es alimentado por el aplicativo, sobre la base de datos del sistema de información de la empresa, el reporte se puede generar desde el sistema de información de la USO.

41 OPENSTAX. Arquitectura de MySQL [en línea]. OpenStax. Houston. (15 de diciembre de 2008), Par. 01.

[Consultado: 08 de septiembre de 2017]. Disponible en internet: https://archive.cnx.org/contents/fa33ef02-f882-4b8d-9f67-4be268dd6d03@1/.

https://archive.cnx.org/contents/fa33ef02-f882-4b8d-9f67-4be268dd6d03@1/


88

7.3.1 Diagrama de objetos

El IDE de Rad Studio es completamente orientado a objetos, por este motivo se decide realizar un diagrama de objetos. (En las versiones superiores Architect, se permite unos grados más de profundidad de la ramificación de su estructura).

Un objeto es básicamente un bloque de memoria que se ha asignado y configurado de acuerdo con un plano. Un programa puede crear muchos objetos de la misma clase, también se denominan instancias y pueden almacenar en una variable con nombre, o en una matriz o colección42.

Un método es un bloque de código que contiene una serie de instrucciones. Un programa hace que se ejecuten las instrucciones al llamar al método y específicamente los argumentos de método necesarios43.

Una propiedad es un miembro que proporciona un mecanismo flexible para leer, escribir o calcular el valor de un campo privado. Las propiedades se pueden usar como si fueran miembros de datos públicos, pero en realidad son métodos especiales denominados descriptores de acceso. Esto permite acceder fácilmente a los datos a la vez que proporciona la seguridad y la flexibilidad de los métodos44.

El siguiente diagrama presenta los objetos utilizados dentro del proyecto, su conectividad, propiedades y métodos utilizados dentro de cada uno. Además se logra observar todos los objetos que permiten el adecuado funcionamiento del aplicativo, cada objeto cumple una función vital para el cumplimiento del objetivo, no todos los objetos dependen de otro, pero todos los objetos son usados por los procedimientos estipulados para darle inicio a la actividad de cada objeto, todos están contenidos sobre un objeto principal.

42 WAGNER, Bill., HOFFMAN, Matt., WENZEL, Maira., at. All. Objects C# programming guide [en linea].

Microsoft. Estados Unidos. (20 de Julio de 2015), Par. 01. [Consultado: 15 de mayo de 2017]. Disponible en internet: https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/classes-and-structs/objects.

43 Ibid., p. 01.

44 Ibid., p. 01.

https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/classes-and-structs/objects

89

Figura 19. Diagrama de Objetos


90

Los objetos que se encargan de la conectividad a la base de datos son de la Clase TMyQuery, esto objetos son los de mayor participación por su cantidad de iteraciones de datos que pasan atreves de ellos.

El objeto encargado de enviar y recibir señal de actualización al sistema de información de la empresa es ServerSocket, una vez se han realizado las acciones necesarias sobre la base de datos del sistema de información de la empresa, se encarga de informarle a los respectivos módulos de sistema que es momento de actualizar la información y continuar con los respectivos procesos, a este componente le brinda apoyo el objeto Antifreezet que evita el frecuente bloqueo del envío de mensajes en el momento en los cual se pueda presentar eventos externos o saturación de datos sobre el mismo componte, es en resumen un controlador de exenciones.

Los demás objetos como son Label, Panel, Button, Edit, Memo, Cheachbox, Temporizador y quien los contiene a todos TJivaro, no permiten visualizar datos actuales de la operación del aplicativo y ejecutar actualizaciones de configuración del aplicativo.

Dentro de lDE de desarrollo de Rad Studio “Embarcadero” es completamente orientado a objeto por este motivo se decide realizar un diagrama de objetos, además la ramificación estructurada de su arquitectura está organizada de la siguiente manera: Librerías (Superclases), clases, objetos, métodos y atributos.

Las librerías son las que contienen las súper clases de todas las clases que se utilizaron en el proyecto, las que se seleccionaron para el desarrollo del proyecto fueron:

Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms, Dialogs, ExtCtrls, DB, MemDS, DBAccess, MyAccess, IdContext, IdCustomTCPServer, IdTCPServer, IdBaseComponent, IdComponent, IdTCPConnection, IdTCPClient, Sockets, ScktComp, StdCtrls, PgAccess, ActnList, DdeMan, IdAntiFreezeBase, IdAntiFreeze;

91

Por otra parte, algunas de las herramientas utilizada para la creación del aplicativo que se detallan más adelante, son la que utiliza la empresa, se decidió continuar con las mismas para efectos de compatibilidad con el sistema.

7.3.2 Rad Studio XE

La herramienta de desarrollo utilizada por la empresa USO es Rad Studio XE, dentro de la empresa se requiere trabajar de manera rápido y óptima para poder ajustarse a las necesidades de los clientes y estar en constante evolución, uno de los pilares de la empresa dentro del valor agregado a los servicio es la adaptación del sistema a las necesidades del cliente, con esta herramienta el proceso de desarrollo es muy ágil y rápido. Con el uso de la misma herramienta que maneja la empresa se garantiza una fácil administración futura del proyecto, por parte de la empresa. Esta herramienta es de uso privado, no de uso gratuito.

Embarcadero RAD Studio XE es una suite integral para el desarrollo de aplicaciones y la manera más rápida de crear visualmente aplicaciones intensivas GUI a partir de datos para Windows, .NET, PHP y Web. RAD Studio incluye Delphi®, C++Builder®, Delphi Prism y RadPHP™ permitiendo a los desarrolladores entregar aplicaciones hasta 5 veces más rápido entre múltiples plataformas de Windows, Web y bases de datos45.

Este IDE de desarrollo utiliza como lenguaje de programación Object Pascal, este lenguaje de programación es la “evolución del lenguaje de programación Pascal, que incluye elementos del paradigma orientado a objetos. Es más conocido como el ‘lenguaje de programación de Borland Delphi’, que modifica algunas características del Object Pascal original. Borland vende entornos de desarrollo integrando (IDE) que compilan en lenguajes Delphi a Microsoft y Linux”46.

45 SOFTWARE. RAD studio xe [en línea]. Software.com.co. Colombia. 2016. , Par. 02. [Consultado: 11 de

diciembre de 2017]. Disponible en internet: http://www.software.com.co/p/rad-studio-xe#product-description.

46 ALEGSA, Leandro. Lenguaje de programación, object Pascal [en línea]. Alegsa.com.ar. Argentina. (05 de

diciembre de 2010), Par. 01. [Consultado: 09 de julio de 2017]. Disponible en internet: http://www.alegsa.com.ar/Dic/object_pascal.php.

http://www.software.com.co/p/rad-studio-xe#product-description

http://www.alegsa.com.ar/Dic/object_pascal.php

92

7.3.3 SQL Server Management Studio (SSMS)

La empresa USO, maneja la base de datos de su sistema de información con la herramienta SQL server management studio, se utiliza esta misma herramienta para continuar el proceso de compatibilidad y fácil administración posterior del proyecto, en los procesos de creación de los scrip’s necesarios, esta herramienta está en opción paga y una limitada gratuita.

Es un entorno integrado para administrar cualquier infraestructura SQL, desde SQL Server a SQL Database. SSMS proporciona herramientas para configurar, supervisar y administrar instancias de SQL desde donde quiera que se despliegue. SSMS proporciona herramientas para implementar, supervisar y actualizar los componentes de nivel de datos, como bases de datos y almacenes de datos utilizados por las aplicaciones, y crear consultas y secuencias de comandos47.

Rad Studio proporciona todos los componentes y utilidades necesarias para la creación del aplicativo, MySQL es la base de datos que se maneja en la empresa y es a la cual se conectará el aplicativo para realizar su procesamiento de información y SQLServer Management Studio es el IDE con el cual se maneja la base de datos para poder realizar validaciones y pruebas de las sentencias SQL que serán utilizadas dentro del aplicativo. Estas son las tres herramientas bases sobre las cuales se realizará al aplicativo.

7.3.4 MYSQL

Es un sistema de gestión de base de datos relacional (RDBMS) de código abierto, basado en lenguaje de consulta estructurado (SQL)48.

47 STEIN, Steve; RABELER, Carl; HUBBARD, Jennifer; VANCE, Jim; GUYER, Craig. SQL server management

studio SSMS [en línea]. Microsoft. Estados Unidos. (02 de febrero de 2017), Par. 02. [Consultado: 15 de mayo de 2017]. Disponible en internet: https://docs.microsoft.com/en-us/sql/ssms/sql-server-management-studio-ssms.

48 ROUSE, Margaret. MySQL [en línea]. SearchDataCenter. Estados Unidos. (enero de 2015), Par. 01.

[Consultado: 15 de mayo de 2017]. Disponible en internet: https://searchdatacenter.techtarget.com/es/definicion/MySQL.

https://docs.microsoft.com/en-us/sql/ssms/sql-server-management-studio-ssms


https://searchdatacenter.techtarget.com/es/definicion/MySQL

93

Este es el motor de base de datos utilizado por la empresa para todos sus proyectos, es un motor de muy amplio reconocimiento y estabilidad, cuenta con muy buena información de soporte.

Al utilizar en el proyecto del aplicativo información registrada sobre la base de datos del sistema esto no ancla a usar la misma base de datos para continuar con la paridad en la información y evitar reproceso como crear una base de datos nueva, una interface de comunicación y todo esto repercutiría en aumento en los tiempos de transacción para poder ejecutar algunas tareas.

Esta herramienta tiene como característica más notable el separar el motor de almacenamiento del resto de los componentes de la arquitectura (Ver figura 20). Es decir, el diseño del gestor está preparado para que se pueda cambiar el gestor de almacenamiento. Esto permite incluso crear nuevos motores de almacenamiento especializados para ciertas tareas o tipos de aplicaciones49.

Las utilidades y herramientas de MySQL son los programas y aplicaciones que se incluyen con la distribución del gestor, o que pueden instalarse como aplicaciones adicionales. Estas incluyen las herramientas de backup, el navegador de consultas (QueryBrowser), las aplicaciones administrativas de interfaz gráfico y la herramienta de diseño MySQL Workbench, entre otras50.

49 Ibid., p. 02.

50 Ibid., p. 05.

94

Fuente: ROUSE, Margaret. MySQL [en línea]. SearchDataCenter. Estados Unidos. (Enero de 2015), párr. 01. [Consultado: 15 de mayo de 2017]. Disponible en internet: https://searchdatacenter.techtarget.com/es/definicion/MySQL.

Diseño de la interface gráfica del aplicativo.

En el diseño de la interface gráfica del aplicativo se tuvo en cuenta las necesidades de un usuario al momento de interactuar con él. El usuario requiere un espacio donde pueda ingresar el número del puerto de comunicación, requiere poder visualizar la configuración de atención con la que esté trabajando actualmente el aplicativo. El usuario requiere la alternativa de actualizar la configuración de atención mediante un botón de carga, es bueno poder visualizar los equipos que se conectan al aplicativo, también la manera en la cual son identificados. Con la visualización de los equipos que se conectan al aplicativo se puede evidenciar el estado de funcionamiento, por cada equipo que se conecte o se desconecte se verá reflejado en la lista de conexiones generada.

Figura 20. Estructura de MyQSL

https://searchdatacenter.techtarget.com/es/definicion/MySQL

95

Existen unos principios básicos para el diseño e implementación de las interfaces gráfica, los cuales fueron tenidos en cuente para el diseño de la interface gráfica, estos principios son51.

Anticipación: Las aplicaciones deberían intentar anticiparse a las necesidades del usuario y no esperar a que el usuario tenga que buscar la información, recopilarla o invocar las herramientas que va a utilizar52.

Autonomía: La computadora, la interfaz de usuario y el entorno de trabajo deben estar a disposición del usuario. Se debe dar al usuario el ambiente flexible para que pueda aprender rápidamente a usar la aplicación. Sin embargo, está comprobado que el entorno de trabajo debe tener ciertas cotas, es decir, ser explorable pero no azaroso. Es importante utilizar mecanismos indicadores de estado del sistema que mantengan a los usuarios alertas e informados. No puede existir autonomía en ausencia de control, y el control no puede ser ejercido sin información suficiente. Además, se debe mantener información del estado del sistema en ubicaciones fáciles de visualizar53.

Valores por defecto: No se debe utilizar la palabra “Defecto” en una aplicación o servicio. Puede ser reemplazada por “Estándar” o “Definida por el Usuario”, “Restaurar Valores Iniciales” o algún otro término especifico que describa lo que está sucediendo. Los valores por defecto deberían ser opciones inteligentes y sensatas. Además, los mismos tienen que ser fáciles de modificar54.

Eficiencia del Usuario: Se debe considerar la productividad del usuario antes que la productividad de la máquina. Si el usuario debe esperar la respuesta del sistema por un período prolongado, estas pérdidas de tiempo se pueden convertir en pérdidas económicas para la organización. Los mensajes de ayuda deben ser

51 UNIVERSIDAD ALAS PERUANAS. Diseño de interfaces de usuario, principios, prototipos y heurísticas para

evaluación [en línea]. Universidad alas peruanas. Perú. (24 de julio de 2010), P. 02-05. [Consultado: 11 de marzo de 2018]. Disponible en internet: http://www.uap.edu.pe/intranet/fac/material/02/20101CA020102407020108011/20101CA02010240702010801116881.pdf.

52 Ibid., p. 02.

53 Ibid., p. 02.

54 Ibid., p. 03.

http://www.uap.edu.pe/intranet/fac/material/02/20101CA020102407020108011/20101CA02010240702010801116881.pdf


96

sencillos y proveer respuestas a los problemas. Los menús y etiquetas de botones deberían tener las palabras claves del proceso55.

En la siguiente grafica se puede observar el aplicativo en ejecución interactuando con el sistema de información de la empresa.

7.4 PRUEBAS

Las pruebas del software son un elemento crítico para la garantía de calidad y representa una revisión final de las especificaciones, del diseño y de la codificación56.

55 Ibid., p. 05.

Figura 21. Aplicativo en funcionamiento

Fuente: Tomado de servidor de la Unidad de Salud Ocupacional.

97

Un programa es funcionalmente correcto si se comporta de acuerdo a la especificación de las funciones (especificación de requerimientos funcionales) que debería proveer. Esta definición de correctitud asume que existe una especificación de requerimientos funcionales del sistema y que es posible determinar en forma no ambigua si las cumple o no57.

La correctitud es una propiedad matemática que establece la equivalencia entre el software y su especificación, por lo que cuanto más riguroso haya sido en la especificación, más precisa y sistemática podrá ser en la evaluación.

Posteriormente se verá que la correctitud puede ser evaluada mediante diversos métodos, algunos de enfoque experimental como las pruebas, otros de enfoque analítico como verificación formal de la correctitud58.

Es de notar que esta definición de correctitud no toma en consideración el que la especificación en sí misma puede ser incorrecta por contener inconsistencias internas, o no corresponder de forma adecuada a las necesidades para las que fue concebido el programa59.

Objetivos de pruebas de software60

La prueba es un proceso de ejecución de un programa con la intención de descubrir un error.

56 SANCHEZ, Salvador., SICILIA, Miguel., RODRIGUEZ, Daniel. Ingeniería de software. Un enfoque desde la guía SWEBOK. Colombia. 2012. Alfaomega, P. 152.

57 UNIVERSIDAD DE LA REPUBLICA. Cualidades del software [en línea]. Universidad de la republica de

Uruguay. Uruguay. 2002, P. 01. [Consultado: 18 de septiembre de 2017]. Disponible en internet: https://www.fing.edu.uy/tecnoinf/maldonado/cursos/ingsoft/materiales/teorico/CualidadesSoftware.pdf.

58 Ibid., p. 01.

59 Ibid., p. 01.

60 PRESSMAN, Roger. Ingeniería del software, un enfoque práctico [en línea]. Cotana. Connecticut. 2010, P.

95-96. [Consultado: 16 de mayo de 2017]. Disponible en internet: https://bit.ly/2qjIMTM.

https://www.fing.edu.uy/tecnoinf/maldonado/cursos/ingsoft/materiales/teorico/CualidadesSoftware.pdf

https://bit.ly/2qjIMTM

98

Un buen caso de prueba es aquel que tiene una alta probabilidad de mostrar un error no descubierto hasta entonces.

Una prueba tiene éxito si descubre un error no determinado hasta entonces.

Principios que deben cumplir las pruebas

A todas las pruebas se le deben hacer un seguimiento hasta los requisitos del cliente.

Las pruebas deberían planificarse mucho antes que empiecen.

El principio de Pareto es aplicable a la prueba del software.

Las pruebas debería empezar lo pequeño y progresar hacia lo grande.

No son posibles las pruebas exhaustivas.

Se hace la depuración del aplicativo, en búsqueda de errores de arranque y de conectividad con la base de datos, en esta parte no se encontró ningún tipo de interferencia en la conectividad de la nueva herramienta61.

Con la base del aplicativo funcionando se inicia el proceso de validación o pruebas para validar que realmente cumpla con sus funciones básicas para las cual fue creado.

El primer caso de prueba que se pondrá en consideración es evaluar un paciente con un solo servicio de los más fundamentales dentro de los procesos operativos de la empresa, como lo es la historia clínica ocupacional, siendo que esta historia obliga a la realización previa de la preconsulta.

Esto permite al tiempo realizar la validación de prioridades que debe tener el aplicativo para realizar la distribución del paciente.

61 Ibid., p. 96.

99

El proceso de diseño de un plan de pruebas está compuesto por diferentes fases, objetivos, entornos, configuraciones de los entornos, tipo de pruebas a realizar, criterios de aprobación, orden de ejecución de las pruebas y análisis. A continuación se detallan los puntos que permitirán la realización de las pruebas:

7.4.1 Objetivo general de pruebas del aplicativo

Durante la realización del proceso de pruebas se espera validar la correctitud del aplicativo. Que se realice lo esperado con las diversas entradas que son recibidas u obtenidas de la sala de espera del aplicativo interno de la empresa, que cumple la función de insumo para el funcionamiento del aplicativo62.

Validar que el aplicativo cumpla con todas las condicionales especificadas en el proceso de levantamiento de requerimientos.

Validar que el aplicativo pueda seguir una secuencia de exámenes en su respectiva distribución.

7.4.2 Objetivos específicos, en conjunto de los casos de prueba

Fluidez de los datos a través del aplicativo.

Independencia del aplicativo del resto del sistema.

Interfaz de usuario.

La secuencia lógica de las funcionalidades y transacciones.

62 Ibid., p. 95.

100

Establecer rangos de tiempos de ejecución.63

7.4.3 Entorno y configuración de pruebas

Para el proceso de pruebas del proyecto se requiere de la disponibilidad de los siguientes entornos64, a saber:

Servidor Windows Server 2003 con Internet Information Server ASP 2.0.

Equipo marca DELL PowerEdge Intel(R) Xeon(R) CPU, 32 GB RAM, 2 TERA 5400rpm HDD, 12.1in 1280x800 LCD, Intel X3100, 802.11bg wireless, Windows XP Pro sp 2, IE version 7.

Equipos Cliente: Equipos de Prueba.

Equipo marca HP Dual cor 1.80 GHz Windows 7 Profeccional 2 GB RAM 120 HDD, 802.11bg wireless, IE versión 6.

Equipo marca DELL Inspiron 1300, Pentium 1.70 GHz 2 Mb RAM, 80 HDD, Windows 7 Profeccional, IE versión 7.

Base de Datos MySQL 1.4 Versión 5.7.15 X64. Reside en equipo de servidor de Pruebas.

7.4.4 Criterios de aprobación / rechazo

Errores Graves: información crítica presentada erróneamente, información mal registrada en la base de datos, caídas de programas, incumplimiento de objetivos en funciones principales.

63 Ibid., p. 96.

64 Ibid., p. 397.

101

Errores Medios (comunes): errores en presentación de datos, incumplimiento de objetivos en funciones secundarias, caídas de programas auxiliares.

Errores Leves: no adecuación a estándares, comportamientos correctos pero diferentes en situaciones similares, dificultades de operación65.

7.4.5 Base de datos de pruebas

Base de datos:

unidadso Servidor

Susos

Datos: D: /unidadso/mysql/data/unidadso66

7.4.6 Tipo de prueba de software a aplicar

Las pruebas a aplicar, son las funcionales, para la evaluación del cumplimiento de los objetivos del proyecto y las pruebas de estrés para evaluar el comportamiento del aplicativo con un número representativo de pacientes (la cantidad de pacientes que llegue el día que se realice la prueba de estrés) y usuarios del sistema en actividad. Con estas dos clases de pruebas damos cumplimiento de los requerimientos, también son un proceso de control de calidad que consiste en asegurar el cumplimiento de un sistema o componente con requerimientos funcionales.

El objetivo principal de las pruebas funcionales es analizar el producto terminado y determinar si hace todo lo que debería hacer y si lo hace correctamente67.

65 Ibid., p. 96.

66 Ibid., p. 397.

102

7.4.7 Orden de ejecución de pruebas

Las pruebas se llevaran acabo de la siguiente forma:

Para determinar la se secuencia de pasos para la configuración, es importante tener en cuenta la Tabla N° 2368.

Tabla 23. Secuencia de pasos para la configuración

SECUENCIA PARA LA CONFIGURACIÓN.

1. Se pone el ejecutable del aplicativo dentro de la carpeta unidadso ubicada dentro del servidor.

2. Iniciar el sistema de la empresa en el servidor, en orientación al usuario, caja1, auxiliar DMO y en los consultorios con sus respectivos profesionales.

3. Iniciar el Aplicativo repartidor en el servidor.

4. Realizar el registro del paciente en orientación.

5. Realizar la validación del ingreso del paciente en la sala de espera.

6. Inicialización del proceso del paciente en la sala de espera.

7. Inicialización de la distribución y envió del paciente al consultorio determinado, de acuerdo a los exámenes registrados.

8. Inicio de la atención medica al paciente.

9. Fin de la atención medica del paciente.

10. Si el paciente termina su proceso marcar el estado del paciente como atendido.

67 CROUDSOURCED. ¿Qué son pruebas funcionales? [en línea]. Crowdsurced testing, smarter software

testing. (2017), Par. 03. [Consultado: 18 de febrero de 2018]. Disponible en internet: http://crowdsourcedtesting.com/es/pruebas-funcionales.

68 Ibid., p. 01.

http://crowdsourcedtesting.com/es/pruebas-funcionales

103

7.4.8 Equipo de pruebas y responsabilidades

La tabla N° 24 presenta el equipo de trabajo seleccionado para la realización de las pruebas funcionales del aplicativo69.

Tabla 24. Equipo de trabajo para pruebas y distribución de responsabilidades.

EQUIPO DE TRABAJO PARA REALIZACION DE PRUEBAS FUNCIONALES

Camilo Steanli Auxiliar operativo, responsable de realizar el registro inicial y asignación de turno a los pacientes.

Camilo Alvares Auxiliar operativo, responsable de realizar la facturación de los servicios para cada paciente

Adriana Ramírez Auxiliar DMO, responsable de mantener y darle orden a la sala de espera, validar que el paciente siga el orden apropiado de atención.

Edwin Rojas

Auxiliar de sistemas, responsable de cumplir con el papel de la especialista, validar que el paciente llegue a la ventana del especialista, validar que cuando se asigna un paciente a un médico en la ventana del médico aparezca el nombre del paciente.

Ronal Brand Médico coordinador, apoya y avala las funciones realizadas por el auxiliar de sistemas Edwin Rojas

Alexander Ospitia

Asesor Externo del Dpto. de sistemas, responsable de certificar que efectivamente se cumpla con los procesos planeados y el paso a paso se efectué de manera apropiada.

Camilo E. Balanta

Responsable del proyecto, coordinar todo el conjunto de pruebas a realizar, validar la correctitud del aplicativo en el cumplimiento de su labor.

69 Ibid., p. 01.

104

7.5 CASOS DE PRUEBAS

El número de casos de pruebas fue definido bajo el modelo de funcionamiento de la USO, el cual de manera interna presta 8 servicios y pensando en asegurar el cumplimiento de la distribución de los pacientes, para cada uno de los servicios se tiene un determinado número de profesionales o especialistas, para suplir con la demanda de atención.

Debido al flujo constante de personas y a la multiplicidad de servicios a los que pueden acceder los pacientes (8 servicios), se debe evaluar el comportamiento del aplicativo con más de un solo paciente.

Pensando en la diversidad de número de servicios se propuso realizar un caso de prueba para la cantidad de tres servicios y uno para la cantidad de los ocho servicios, también se propuso que los dos casos de prueba se realizaran con dos pacientes registrados en la sala de espera.

7.5.1 Caso de prueba 1

Caso de prueba aplicado con los exámenes más solicitados, audiometría, Visiometría, Optometría, V. ergonómica y la historia clínica ocupacional. Se ejecuta con dos pacientes, cada uno con 3 exámenes (Tabla 25). Cabe mencionar que el orden de atención de las personas que serán atendidas en la empresa inicia por orientación donde se toman datos básicos del paciente. Continua a facturación donde se registra al paciente y los servicios a los que este accederá, seguido pasa a la sala de espera donde inicia el proceso de llamado a los servicios previamente facturados.

105

Tabla 25. Identificación general (caso de prueba 1)

IDENTIFICACION GENERAL

Identificación del paciente: datos generales

Cantidad de pacientes en el sistema

2 Paciente

Cantidad de pacientes para pruebas

2 Paciente

Identificación de los pacientes 125, 122

Orientación: El orientador es la persona encargada de iniciar y finalizar este proceso.

Nombre de los pacientes Nombre prueba1, Nombre prueba 2

Empresa Unidad de salud Ocupacional S.A.S

Facturación: El facturador es la persona encargada de iniciar y finalizar este proceso

Paga los servicios Unidad de salud Ocupacional S.A.S

Servicios registrados para el número de identificación 125

Preconsulta, Historia clínica ocupacional de ingreso, Audiometría y optometría

Servicios registrados para el número de identificación 122

Preconsulta, Historia clínica ocupacional de ingreso, Visiometría, V. Ergonómica

Sala de espera: Auxiliar de DMO valida que los datos ingresados por facturación sean los correctos y está atento del proceso de atención de los pacientes.

Hora de ingreso del paciente a la sala

08:21:15am, 08:22:20am

Fecha de Ingreso del paciente 26/07/2017

Hora de ingreso de los pacientes

08:20:21am, 08:21:19am

A continuación se presentan los datos recolectados de la prueba de correctitud.

106

Datos del paciente con el número de identificación 125 en relación a tiempos de atención y exámenes realizado (Tabla 26).

Tabla 26. Tiempos de atención y exámenes realizado con N° de ID 125

TIEMPOS DE ATENCIÓN Y EXÁMENES REALIZADOS

Tiempo de asignación 08:30:15 Examen asignado: Preconsulta

Tiempo de la valoración 08:30:50 a 08:35:10

Tiempo de asignación 08:37:23 Examen asignado: Audiometría

Tiempo de la valoración 08:37:31 – 08:42:21

Tiempo de asignación 08:45:28 Examen asignado: Optometría


Tiempo de asignación 08:52:30 Examen asignado:

Historia clínica ocupacional


Final de la atención

08:49:12

Datos del paciente con el número de identificación 122 en relación a tiempos de atención y exámenes realizado (Tabla 27).



Tiempo de asignación 08:31:15 Examen asignado: Preconsulta

Tiempo de la valoración 08:31:17 a 08:36:10

Tiempo de asignación 08:37:23 Examen asignado: Visiometría


107


Tiempo de asignación 09:01:10 Examen asignado: V. Ergonómica


Tiempo de asignación 09:17:21 Examen asignado: Historia clínica ocupacional


Final de la atención

09:33:12

Validar el orden de las asignaciones realizadas por el aplicativo (Tabla 28).

Tabla 28. Validación de órdenes

VALIDACION DE ORDENES

Para Preconsulta Previo: NO hay requisitos

Para laboratorios Previo: No hay requisitos

Para Audiometría Previo: No hay requisitos

Para Espirometría Previo: Preconsulta

Para Optometría Previo: No hay requisitos

Para Visiometría Previo: No hay requisitos

Para V. Ergonómica Previo: Preconsulta

Para V. Foniátrica Previo: No hay requisitos

Para protectores auditivos Previo: No hay requisitos

Para Historia Medica Previo: Preconsulta, y todos los demás exámenes que tenga registrado el paciente.

- Análisis

Para la realización satisfactoria de los exámenes propuestos, se debe tener en cuenta las prioridades de atención, y las precondiciones, también la disponibilidad de los profesionales o especialistas en los consultorios. Para el efecto de la prueba, estuvieron dos personas encargadas de validar que los pacientes fueran

108

asignados a los consultorios en los cuales se encuentran con la sesión iniciada, en el sistema de información de la empresa con los profesionales para la prestación del servicio.

Con esto se cumple con la búsqueda del consultorio y con la asignación del paciente adecuado.

7.5.2 Caso de prueba 2

Para este caso de prueba se realizó la evaluación de la correcta secuencia de exámenes, se registraron 2 pacientes, cada uno con 9 servicios, estos fueron siendo asignados a cada consultorio según sus órdenes. En la tabla N° 29 se presentan los datos recolectados de la prueba unitaria realizada.

Tabla 29. Identificación general de los casos de uso

IDENTIFICACION GENERAL

Identificación del paciente: datos generales

Cantidad de pacientes en el sistema

2 Paciente

Cantidad de pacientes para pruebas

2 Paciente

Identificación de los pacientes

125, 122

Orientación: El orientador es la persona encargada de iniciar y finalizar este proceso.

Nombre de los pacientes

Nombre prueba1, Nombre prueba 2

Empresa Unidad de salud Ocupacional S.A.S

Facturación: El facturador es la persona encargada de iniciar y finalizar este proceso

Paga los servicios Unidad de salud Ocupacional S.A.S

Servicios registrados a los dos pacientes

Preconsulta, Laboratorios, Audiometría, Optometría, Visiometría, V. Ergonómica, V. Foniátrica, protectores auditivos, Historia Clínica Ocupacional

109


Sala de espera: Auxiliar de DMO valida que los datos ingresados por facturación sean los correctos y está atento del proceso de atención de los pacientes.

Hora de ingreso del paciente a la sala

08:11:02am, 08:17:20am

Fecha de Ingreso del paciente

27/07/2017

Hora de ingreso de los pacientes

08:10:31am, 08:16:28am

A continuación se presentan los registros de los tiempos de asignación a cada servicio y duración de cada consulta. Del paciente con el número de identificación 125 (Tabla 30).



Tiempo de asignación 08:11:20 am Examen asignado:

Preconsulta

Tiempo de la valoración 08:11:40am – 08:17:27am

Tiempo de asignación 08:19:21am Examen asignado:

Laboratorio

Tiempo de la valoración 08:19:41 am –

08:21:12am


Audiometría


08:26:12am


Espirometría



Optometría

110




Visiometría


Tiempo de asignación 08:43:24am Examen asignado: Val. ergonómica

Tiempo de la valoración 08:43:31am - 08:52:28am


V. Foniátrica



Protectores auditivos



Historia Ocupacional


Fin de la prueba 09:35:06am

Registros de los tiempos de asignación a cada servicio y duración de cada consulta. Del paciente con el número de identificación 122 (Tabla 31)



Tiempo de asignación 08:18:13 am Examen asignado:

Preconsulta



Laboratorio

111



08:26:12am


Audiometría


08:30:45am


Espirometría



Optometría



Visiometría



V. Ergonómica



V. Foniátrica



Protectores auditivos



Historia Ocupacional


Fin de la prueba 09:43:06am

Validar el orden de las asignaciones realizadas por el aplicativo (Tabla 32).

112

Tabla 32. Validación de órdenes

VALIDACION DE ORDENES

Para Preconsulta Previo: NO hay requisitos

Para laboratorios Previo: No hay requisitos

Para Audiometría Previo: No hay requisitos

Para Espirometría Previo: Preconsulta

Para Optometría Previo: No hay requisitos

Para Visiometría Previo: No hay requisitos

Para V. Ergonómica Previo: Preconsulta

Para V. Foniátrica Previo: No hay requisitos

Para protectores auditivos Previo: No hay requisitos

Para Historia Medica Previo: Preconsulta, y todos los demás exámenes que tenga registrado el paciente.

- Análisis

En esta prueba se tuvo en cuenta gran parte de los servicios en la USO, se le asignaron la misma cantidad de exámenes a dos pacientes de prueba para evaluar el comportamiento del aplicativo, que realice su distribución de manera correcta, y que a su vez lo pueda realizar con más de un solo paciente, la cantidad de exámenes permite validar que el aplicativo es capaz de revisar los exámenes que tiene el paciente registrados en la sala y ubicar un consultorio con un profesional o especialista disponible para su atención. Si no encuentra un profesional, para un examen determinado continuo con el siguiente examen y le busca un consultorio que cumpla con las características para su atención, de la manera lo realiza con cada uno de los pacientes en la sala hasta que la validación de finalizar el proceso se cumpla.

113

7.6 RELACIÓN DE CASOS DE PRUEBAS Y REQUERIMIENTOS

En la tabla N° 33, se encuentra la relación entre los casos de pruebas realizados y los requerimientos funcionales que actúan dentro del proceso de atención directa con un usuario (tabla 4) con los que cumple cada uno70.

RQF: Requerimiento funcional.

CP: Caso de prueba.

Tabla 33. Relación de casos de prueba y requerimientos funcionales

RELACIÓN CASOS DE PRUEBA Y RQF

RQF 14 15 16 17

CP

CP-1 X X X X

CP-2 X X X X

En la tabla N° 34, se encuentra la relación entre los casos de pruebas realizados y los requerimientos NO funcionales de producción, entendiendo que estos actúan dentro del aplicativo para garantizar el cumplimiento de su objetivo (tabla 5).

RQNF: Requerimiento no funcional.

CP: Caso de prueba.

70 JUNTA DE ANDALUCIA. Plantilla plan de pruebas funcionales [en linea]. Marco de desarrollo de la junta de

Andalucía. España (15 de enero de 2010), P. 03. [Consultado: 18 de febrero de 2018]. Disponible en internet: http://www.juntadeandalucia.es/servicios/madeja/contenido/recurso/462.

http://www.juntadeandalucia.es/servicios/madeja/contenido/recurso/462

114

Tabla 34. Relación de casos de prueba y requerimientos no funcionales

RELACIÓN CASOS DE PRUEBA Y REQUERIMIENTOS NO FUNCIONALES DE PRODUCCIÓN

RQF 1 2 3 4 5 6 7 8 9 10 11 12 13 14

CP

CP-1 X X X X X X X X X X X X X X

CP-2 X X X X X X X X X X X X X X

Con los dos casos de pruebas que se realizaron se buscó abarcar todos los requerimientos del aplicativo que actúan dentro del proceso de atención directa con un usuario. Por ello, todo paciente que ingrese a la sala de espera y que este en estado pendiente siempre realizará el proceso completo a través del aplicativo para poder ser distribuido a su respectiva atención en un consultorio.

Finalizado el proceso de las pruebas de correctitud, se llevó a cabo la evaluación del comportamiento del aplicativo con una cantidad representativa de usuarios y de pacientes. Para la realización de esta prueba se designó un día sábado durante una jornada especial.

Durante esta jornada el aplicativo cumplió satisfactoriamente con su cometido, realizando la debida asignación de los pacientes a los consultorios respectivos. Como muestra de ello se presenta el anexo N° 8 donde se presentan algunos registros de las transacciones que realizó el aplicativo.

Dicha prueba abarca todos los pasos que se evaluaron en las pruebas de correctitud y funcionalidad, pero con un mayor número de pacientes a procesar por el aplicativo y un mayor número de usuario en sus respectivos consultorios, esta utiliza los mismos procesos operativos que fueron realizados durante las pruebas de correctitud del aplicativo. Con esta prueba tipo estrés se busca someter el aplicativo a un alto nivel de transacciones, generado por los especialistas desde sus consultorios, el grupo de trabajo del área de DMO y el grupo de cajeros quienes ingresan los pacientes a la sala de espera, con esta cantidad de usuario y un buen número de pacientes que ingresen a las instalación, se espera que el aplicativo responda de la manera más adecuada.

115

Usuarios participantes.

Durante esta jornada se contó con los siguientes especialistas o profesionales, para la prestación del servicio (Tabla 35)

Tabla 35. Relación de cantidad usuarios y función o especialidad

RELACIÓN ENTRE CANTIDAD DE USUARIOS Y FUNCIÓN O ESPECIALIDAD

Cantidad de usuarios Función o especialidad

5 Medico Ocupacional

3 Fonoaudiólogos

2 Fisioterapeutas

2 Optómetras

2 Laboratorio

4 Preconsulta.

3 Auxiliares DMO

1 Coordinadora operativa DMO

2 Cajeros

5 Facturación

Pacientes participantes.

Durante la jornada de pruebas en producción, se llegó a presentar un pico máximo de 70 pacientes en la sala de espera, a los cuales se les brindo la atención en los servicios requeridos. Los servicios solicitados están distribuidos de la siguiente manera (Tabla 36)

116

Tabla 36. Relación de cantidad pacientes y servicios solicitados

RELACION ENTRE CANTIDAD DE PACIENTE Y SERVICIOS SOLICITADOS

Cantidad pacientes Servicio solicitado

70 Laboratorios

64 Valoración médica ocupacional

64 Preconsultas

52 Audiometrías

56 Optometrías

48 Espirometrías

33 Visiometrías

12 Valoraciones Ergonómicas

2 Valoraciones Foniátricas

La jornada de atención se inició desde las 7:00am hasta las 12:30 pm del medio día. Los médicos ocupacionales atendieron un promedio de 3 pacientes por hora, que es un tiempo óptimo, pensando en la sostenibilidad de la calidad de las historias realizadas.

Análisis general de comportamiento.

El aplicativo tuvo un rendimiento adecuado en su proceso de búsqueda de pacientes, búsqueda de consultorios, medico activos en el sistema y en la asignación de los pacientes, también en el área de DMO se sintió una baja en el nivel de estrés de los auxiliares encargados del área, los cuales normalmente se encargan del flujo de pacientes en la sala de espera a través de la asignación manual de los pacientes a cada consultorio.

Durante la prueba se observó que el aplicativo mantenía su estabilidad con los ingresos y salidas de los pacientes ya que no todos llegaron a la misma hora, su llegada fue inesperada durante la jornada, de la misma forma esto convierte en aleatorio la cantidad de exámenes del mismo tipo a realizar en cada momento que ingresa o sale un paciente de la sala de espera. También se observó el buen nivel

117

de identificación de los especialistas conectados al sistema y dispuestos a atender, aunque durante la jornada laboral los especialistas salen de sus consultorios para realizar sus necesidades o para realizar algunos trámites de operación, no se tuvo inconveniente en el momento de retomar la labor de atender los pacientes.

118

8. RESULTADOS

Los resultados de la investigación corresponden a los objetivos planteados, los cuales dan cuenta de un panorama general sobre la mejora en los tiempos de atención de los usuarios, así como la adecuada asignación de pacientes a los profesionales asistenciales de la USO, gracias a la implementación del aplicativo software.

A pesar de no contar con un registro de atención para utilizarlo como punto de comparación, se cuenta con los auxiliares del área de DMO y sus reacciones en cuanto a la utilidad del aplicativo, los comentarios de los profesionales y especialistas. Estos comentarios sobre los resultados de la implementación del aplicativo permitieron dar un grado óptimo de satisfacción del trabajo realizado

Cabe destacar que las personas principalmente beneficiadas fueron los usuarios del sistema de información de la empresa, como lo son los auxiliares de DMO, ya que la labor de encargarse de la distribución y control de los pacientes durante su recorrido y estadía dentro de la empresa en el día a día, así como la adecuada distribución y control en los tiempos de atención de cada uno de los profesionales, se realiza de manera automática, evitando a su vez congestión innecesaria en la sala de espera, debido a los malos manejos internos en cuestiones de preferencias que se presentaban con anterioridad. Claro está que la sala de espera que es la encargada de alimentar los registros de los pacientes, requiere un manejo adecuado para garantizar la atención prioritaria en determinados casos que se requiera.

Esto a su vez, logró la captación de un mayor número de pacientes, así como más vínculos con empresas medianas y grandes, debido a la efectividad y agilidad adquirida por la distribución automática del aplicativo. Además de la generación de reportes con base en una lista de chequeo de las asignaciones a la sala de espera, teniendo en cuenta el tiempo de asignación, profesional o especialista, nombre del paciente y cantidad de pacientes en sala, como se visualiza en el anexo Nº 8.

Debido a las características de programación y desarrollo, el aplicativo no permite la manipulación de ningún usuario no autorizado, lo ideal es que solo sea

119

manipulado por el personal del departamento de sistemas, quienes son los encargados de la ejecución, cierre y edición de las características de atención.

Gracias a la objetividad y buen funcionamiento del aplicativo, que se evidencia en los tiempos de atención, así como la adecuada distribución de pacientes en los consultorios y atención de los profesionales de la salud, es de gran satisfacción que para del asesor empresarial, el Ingeniero Alexander Ospitia, el resultado del proyecto sea satisfactorio, ya que cumple con los objetivos planteados.

120

9. RECOMENDACIONES

El aplicativo puede ser ampliado y adaptado a diferentes tipos de necesidades, no solamente en el área de la salud, sino también en diversas áreas, pues la base de su lógica es la distribución bajo parámetros de ordenamientos secuenciales, que permiten seguir un orden de distribución de una fila de espera con diferentes solicitudes ante una cantidad de receptores dispuestos a atender los diferentes tipos de solicitudes que tenga cada elemento de la sala de espera.

Además, el aplicativo permite realizar escalabilidad, agregar más exámenes que sean tenidos en cuenta para su atención y a su vez, la cantidad de tipos de especialistas. De manera general se trata de poder brindar mayor cantidad de solicitudes por parte de un paciente y mayor diversidad de respuestas por parte de especialistas; se puede agregar funciones de diferentes tipos, reportes propios, que permita visualizar datos más específicos sobre sus asignaciones. Entre muchas otras características que le pueden dar mayor valor agregado al aplicativo y mejorar la integración con al sistema de información de la empresa.

A su vez, el buen sostenimiento de la infraestructura de la red es de vital importancia para el adecuado funcionamiento de este aplicativo y para el sistema de información de la empresa, ya que es el conducto regular de comunicación. Un mal funcionamiento de esta infraestructura generaría pérdida de paquetes entre los tramos de un lugar a otro.

La base de datos debe estar siempre en un óptimo estado para garantizar el buen funcionamiento y fluidez para que el aplicativo pueda realizar la cantidad de transacciones necesarias en los momentos en los cuales se presente una gran cantidad de pacientes. Esto conlleva a un adecuado plan de mantenimiento de la base de datos del sistema de información de la empresa.

Teniendo en cuenta las experiencias adquiridas a lo largo de la investigación, se logra destacar que las bases de datos MySQL tienen un archivo my.ini, este archivo permite la configuración de los log de memoria que pueden separar el motor de MySQL para el almacenamiento de la fila de transacciones que debe registrar. De la misma forma, es posible indicar los tiempos máximos de espera para la ejecución de todos estos registros. También es conveniente tener en

121

cuenta el número de conexiones permitidas a la base de datos, contando no solo con los usuarios, sino también con los aplicativos extras que logran establecer conexión con la base de datos.

Cabe destacar que cuando se realiza un aplicativo que realice múltiples transacciones de manera continua y aleatoria, es conveniente realizar un ajuste a este archivo de configuración para evitar perdida de datos, eventos inesperados de desconexión. Es por lo mencionado hasta el momento que dentro de la formación académica de un ingeniero informático se debe desarrollar la capacidad de investigación, partiendo desde los planteamientos y problemáticas reales presentes en las empresas, favoreciendo el desarrollo de aplicaciones y de sistemas de información personalizados, ya que en la mayoría de los casos no se piensa desde el principio en la evolución de la empresa, la cual va directamente relacionada a las herramientas informáticas con las cuales cuenta para la realización de sus procesos.

122

10. CONCLUSIONES

El desarrollo de este trabajo permite identificar otros puntos de acción sobre los cuales se puede entrar a realizar trabajos de correctitud en el momento de la ejecución de un proceso, esta correctitud lleva a que lo principal para los proyectos empresariales es que realmente realicen la tares para la cual fue construido, y los procesos de continuar incluyéndole funciones y elementos para una mejor compresión.

Realizar el ciclo de vida de un software casi de manera completa es una gran experiencia, ya que es ir elaborando cada escalón para poder garantizar una estructura fuerte y sólida que permita la evolución del aplicativo de acuerdo a las necesidades del usuario y de la misma manera de los pacientes.

La aplicación de una metodología en cascada permitió mantener un orden en relación con los objetivos planteados al inicio del proyecto, siendo que este no es en tamaño de funcionalidades muy grande, la metodología escogida por consenso dentro de la empresa fue apropiada, ya que no generó retrasos ni incomodidades durante el proceso. También se recalca el uso de los casos de pruebas ya que fueron de gran importancia para evaluar y validar el aplicativo que se estaba construyendo, generando a su vez contacto y mejor interacción con el cliente, ya que se logró validar que las necesidades estaban siendo suplidas y que dentro de las pruebas se pudieron incluir a beneficiarios y usuarios del aplicativo, logrando generar confianza en el grupo de trabajo con respecto a la solución planteada e implementada.

Los objetivos fueron alcanzados de manera satisfactoria, partiendo que la recolección de la información fue realizada de manera interactiva y buscando generar confianza desde el principio con los usuarios y/o beneficiarios finales.

El modulo desarrollado es de una interacción mínima con los usuarios que tienen acceso a él, buscando minimizar el riesgo de errores y/o alteraciones en su funcionalidad, las pruebas de funcionalidad diseñada y realizada fueron exitosas, ya que el aplicativo realizó la función para la cual fue desarrollado durante las pruebas controladas y las pruebas realizadas dentro del proceso de su construcción.

123

El aplicativo fue activado durante una jornada laboral normal, en la cual el número de paciente aumentaba de manera gradual con el tiempo, permitiendo evidenciar que el aplicativo respondía de manera adecuada, permitiendo llenar de confianza a los usuarios que eran responsables de su labor. Por ende, se destaca la fiabilidad que el aplicativo brinda tanto al investigador, como a la empresa USO

Cabe mencionar que siempre es posible mejorar los tiempos de ejecución de los algoritmos, minimizarlos; también evaluar las actualizaciones que sean necesarias para incluirlas y permitir el crecimiento del aplicativo con las necesidades de la empresa USO.

Por último, con la elaboración de este proyecto se evidencia que durante el desarrollo del aplicativo, se fortalecieron los conocimientos teóricos y prácticos de la ingeniera de software, que sirven como punto de partida para futuros proyectos dentro de la comunidad académica, personal y laboral.

124

BIBLIOGRAFÍA

AITECO CONSULTORES. Qué es un diagrama de flujo, gestión de procesos [en línea]. Aiteco consultores. España. 2016, párr. 01. [Consultado: 16 de mayo de 2017]. Disponible en internet: https://www.aiteco.com/diagrama-de-flujo/.

ALEGSA, Leandro. Lenguaje de programación, object Pascal [en línea]. Alegsa.com.ar. Argentina. (05 de diciembre de 2010), párr. 01. [Consultado: 09 de julio de 2017]. Disponible en internet: http://www.alegsa.com.ar/Dic/object_pascal.php.

ALVAREZ, Sara. Arquitectura cliente-servidor [en línea]. Desarrollo web. (30 de agosto de 2007), párr. 02. [consultado: 10 de septiembre de 2017]. Disponible en internet: https://desarrolloweb.com/articulos/arquitectura-cliente-servidor.html.

ARIAS CALLEJA, Manuel. Análisis, diseño y mantenimiento de software [en línea]. Departamentos de inteligencia artificial de la UNED. (noviembre de 2010), P. 19. [Consultado: 11 de diciembre de 2017]. Disponible en internet: http://www.ia.uned.es/ia/regladas/adms/GuiaDidactica.pdf.

BARROS, Oscar. Design of the emergency service production in a public hospital [en línea]. Universidad de Chile, ingeniería industrial. Chile. (septiembre de 2017), párr. 01. [Consultado: 15 de diciembre de 2017]. Disponible en internet: https://www.researchgate.net/publication/320042367_DESIGN_OF_THE_EMERGENCY_SERVICE_PRODUCTION_IN_A_PUBLIC_HOSPITAL.

BERZAL GALIANO, Fernando. Relaciones entre clases, diagramas de clases UML [en línea]. Elvex. España. (01 de julio de 2015), P. 01.[Consultado: 01 de noviembre de 2015]. Disponible en internet: http://elvex.ugr.es/decsai/java/pdf/3C-Relaciones.pdf.

https://www.aiteco.com/diagrama-de-flujo/

http://www.alegsa.com.ar/Dic/object_pascal.php

https://desarrolloweb.com/articulos/arquitectura-cliente-servidor.html

http://www.ia.uned.es/ia/regladas/adms/GuiaDidactica.pdf





125

BLE, Carlos. Modelo en cascada [en línea]. Libros Web. España. 2013, P. 02. [Consultado: 10 de diciembre de 2016]. Disponible en internet: http://librosweb.es/libro/tdd/capitulo_1/modelo_en_cascada.html.

CROUDSOURCED. ¿Qué son pruebas funcionales? [en línea]. Crowdsurced testing, smarter software testing. (2017), párr. 03. [Consultado: 18 de febrero de 2018]. Disponible en internet: http://crowdsourcedtesting.com/es/pruebas-funcionales.

HIGUERAS ORTEGA, Laura. Ergometría [en línea]. Fundación española del corazón. España. (Febrero de 2015), párr. 01. [Consultado: 09 de febrero de 2017]. Disponible en internet: https://bit.ly/TOqyoB.

JUNTA DE ANDALUCIA. Plantilla plan de pruebas funcionales [en linea]. Marco de desarrollo de la junta de Andalucía. España (15 de enero de 2010), P. 03. [Consultado: 18 de febrero de 2018]. Disponible en internet: http://www.juntadeandalucia.es/servicios/madeja/contenido/recurso/462.

MINISTERIO DE SALUD DE PERÚ. Guía para el diseño de unidades de emergencia [en línea]. Ministerio de salud de Perú PRONAME. Perú. 2016, P. 02-04. [Consultado: 10 de diciembre de 2016]. Disponible en internet: https://bit.ly/2qr2QlE.

OLIVERA SOSA, Ángel Gabriel. Planificación y modelado [en línea]. SCRIB. Campeche. (06 de septiembre de 2010), P. 03. [Consultado: 01 de noviembre de 2015]. Disponible en internet: https://es.scribd.com/doc/37187866/Requerimientos-funcionales-y-no-funcionales#scribd.

OMNISALUD. Medicina laboral [en línea]. OMNISALUD. Medellín. 2016, [consultado: 10 de febrero de 2017]. Disponible en internet: https://omnisalud.co/medicina-laboral/.




https://bit.ly/TOqyoB

http://www.juntadeandalucia.es/servicios/madeja/contenido/recurso/462

https://bit.ly/2qr2QlE



126

OPENSTAX. Arquitectura de MySQL [en línea]. OpenStax. Houston. (15 de diciembre de 2008), párr. 01. [Consultado: 08 de septiembre de 2017]. Disponible en internet: https://archive.cnx.org/contents/fa33ef02-f882-4b8d-9f67-4be268dd6d03@1/.

PAZ ANDRADE, Maria. Optometría [en línea]. Definición ABC. Chile. (20 de junio de 2015), párr. 01. [consultado: 09 de febrero de 2017]. Disponible en internet: http://www.definicionabc.com/salud/optometria.php/.

PÉREZ SEREY, Jazmín. ORTIZ ARAYA, Virna. Instrumentos aplicados en la evaluación de la voz en profesores: estudio bibliográfico [en línea]. Scielo. Chile. (18 de enero de 2012), P. 02. [Consultado: 12 de febrero de 2018]. Disponible en internet: http://www.scielo.br/pdf/rcefac/v15n5/v15n5a33.pdf.

PEREZ, J. Especificación de requerimientos de software [en línea]. SlideShare. (23 de junio de 2009), P. 56. [Consultado: 01 de noviembre de 2015]. Disponible en internet: https://es.slideshare.net/Jgperez/especificacion-de-requerimentos-de-software.

PRESSMAN, Roger. Ingeniería del software, un enfoque práctico [en línea]. Cotana. Connecticut. 2010, P. 95-96. [Consultado: 16 de mayo de 2017]. Disponible en internet: https://bit.ly/2qjIMTM.

RABEY, Eduardo Marcelo. Escenarios en la ingeniería de requerimientos, Un modelo con componentes formales e informales [en línea]. SEDICI repositorio nacional de la UNLP. La plata. (agosto de 1997), P. 09. [Consultado: 01 de noviembre de 2015]. Disponible en internet: http://sedici.unlp.edu.ar/handle/10915/2155.

ROUSE, Margaret. MySQL [en línea]. SearchDataCenter. Estados Unidos. (enero de 2015), párr. 01. [Consultado: 15 de mayo de 2017]. Disponible en internet: https://searchdatacenter.techtarget.com/es/definicion/MySQL.



http://www.definicionabc.com/salud/optometria.php/

http://www.scielo.br/pdf/rcefac/v15n5/v15n5a33.pdf



https://bit.ly/2qjIMTM

http://sedici.unlp.edu.ar/handle/10915/2155

127

RUIZ, Francisco. Ingeniería del software, requisitos [en línea]. Universidad de Cantabria. España. (1998), P. 02. [Consultado 5 de noviembre de 2016]. Disponible en internet: https://www.istr.unican.es/asignaturas/is1/is1-t03-trans.pdf.

SACEDA CORRALO, David. Espirometría [en línea]. Web consultas Healtcare SA. España. (29 de enero de 2017), P. 01. [Consultado: 09 de febrero de 2017]. Disponible en internet: http://www.webconsultas.com/pruebas- medicas/espirometria-13115/.

SANCHEZ, Salvador., SICILIA, Miguel., RODRIGUEZ, Daniel. Ingeniería de software. Un enfoque desde la guía SWEBOK. Colombia. 2012. Alfaomega, P. 152.

SECRETARIA DISTRITAL DE SALUD DE BOGOTÁ. Manual para la toma de muestras para análisis microbiológico [en línea]. Secretaria distrital de salud de Bogotá, D.C. Dirección de salud pública. Bogotá. (Mayo de 2008), P. 12. [Consultado: 12 de febrero de 2018]. Disponible en internet: https://bit.ly/2pEUusy.

SOFTWARE. RAD studio xe [en línea]. Software.com.co. Colombia. 2016, , párr. 02. [Consultado: 11 de diciembre de 2017]. Disponible en internet: http://www.software.com.co/p/rad-studio-xe#product-description.

STEIN, Steve; RABELER, Carl; HUBBARD, Jennifer; VANCE, Jim; GUYER, Craig. SQL server management studio SSMS [en línea]. Microsoft. Estados Unidos. (02 de febrero de 2017), párr. 02. [Consultado: 15 de mayo de 2017]. Disponible en internet: https://docs.microsoft.com/en-us/sql/ssms/sql-server-management-studio-ssms.

UCHA, Florencia. Orden de trabajo [en línea]. Definición ABC. Chile. (23 de enero de 2013), párr. 02. [09 de febrero de 2017]. Disponible en internet: https://www.definicionabc.com/general/orden-de-trabajo.php.

https://bit.ly/2pEUusy

http://www.software.com.co/p/rad-studio-xe#product-description



https://www.definicionabc.com/general/orden-de-trabajo.php

128

UNIMSALUD. Visiometría laboral [en línea]. Unimsalud servicios de salud ocupacional. Bogotá. (04 de abril de 2012), párr. 01. [Consultado: 09 de febrero de 2017]. Disponible en internet: http://www.unimsalud.com.co/index.php/visiometria-ocupacional.

UNIVERSIDAD ALAS PERUANAS. Diseño de interfaces de usuario, principios, prototipos y heurísticas para evaluación [en línea]. Universidad alas peruanas. Perú. (24 de julio de 2010), P. 02-05. [Consultado: 11 de marzo de 2018]. Disponible en internet: http://www.uap.edu.pe/intranet/fac/material/02/20101CA020102407020108011/20101CA02010240702010801116881.pdf.

UNIVERSIDAD DE LA REPUBLICA. Cualidades del software [en línea]. Universidad de la república de Uruguay. Uruguay. 2002, P. 01. [Consultado: 18 de septiembre de 2017]. Disponible en internet: https://www.fing.edu.uy/tecnoinf/maldonado/cursos/ingsoft/materiales/teorico/CualidadesSoftware.pdf.

UNIVERSIDAD DE MONTREAO. Sobre el sistema [en línea]. Universidad de Montreal. Canadá. 2016, , P. 28. [Consultado: 10 de febrero de 2017]. Disponible en internet: https://bit.ly/2EG5Mz2.

UNIVERSIDAD DE SAN BUENAVENTURA. Procedimiento de evaluaciones médicas [en línea]. Universidad de san buenaventura. Medellín. (28 de noviembre de 2011), p. 02. [Consultado 10 de febrero de 2017]. Disponible en internet: http://web.usbmed.edu.co/usbmed /gestion_ocupacional/.

VASQUEZ, Sol. Definición de sistema operativo [en línea]. Wordpress. (25 de enero de 2011), párr. 16. [Consultado 10 de septiembre de 2017]. Disponible en internet: https://solvasquez.wordpress.com/2011/01/24/definicion-de-sistema-operativo/.

WAGNER, Bill., HOFFMAN, Matt., WENZEL, Maira., at. All. Objects C# programming guide [en linea]. Microsoft. Estados Unidos. (20 de Julio de 2015),







https://bit.ly/2EG5Mz2



129

párr. 01. [Consultado: 15 de mayo de 2017]. Disponible en internet: https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/classes-and-structs/objects.

WIDEX. La audiometría [en línea]. Widex. España. (16 de diciembre de 2015), P. 01. [Consultado: 10 de febrero de 2017]. Disponible en internet: http://www.widex.es/perdida-auditiva/audiometria/.



130

ANEXOS

Anexo A. Diagrama de flujo de procedimiento “estadoinicio”


131

Anexo B. Diagrama de flujo de procedimiento “liberarpendientes”


132

Anexo C. Diagrama de flujo de procedimiento “refrescar”


133

Anexo D. Diagrama de flujo de procedimiento “cambioestado”.


134

Anexo E. Diagrama de flujo de procedimiento “cargatabla”


135

Anexo F. Diagrama de flujo de procedimiento “validaestado”


136

Anexo G. Cuestionario

CUESTIONARIO

Fecha: Cargo:

Antigüedad en el cargo: Área:

Profesión: Edad: Sexo:

PREGUNTAS

A modo de lista, exponer cuáles son sus funciones en el cargo que desempeña actualmente

Del listado anterior, determine al menos 3 funciones que sean indispensables en su puesto de trabajo.

1) 2) 3)

¿Qué servicios se prestan en la empresa? (mencione aquellos de los cuales tiene certeza)

¿Qué tipo de orden de atención se presta?

¿Cuál es el orden adecuado de atención para los exámenes? (de ser posible, enumere el orden)

¿Existen pasos obligatorios o previos a algún examen? (de ser así, mencione cuales son)

¿Qué exámenes puede realizar cada tipo de especialista o profesional?

¿Qué datos del paciente puede conocer el profesional antes del ingreso a la consulta?

¿Cuál es el estimado de pacientes atendidos por día?

¿Cuál es el estimado de profesionales y especialistas por día?

Anexo H. Registros realizados por el aplicativo en jornada de atención al público (09/09/2017) 71.

Hora Profesional Paciente Especialidad Inicio

ronda72

Fin

ronda73

Cantidad de pacientes

15:18 Maria del carmen uni piamba ALEXANDER ALVAREZ FAJARDO PRECONSULTA 15:18 null 20

15:18 Jairo Orlando Ojeda Cardenas FREDY RICARDO ACOSTA HERNANDEZ MEDICO null null null

15:18 Sonia Astrith Leguizamon

Rendon HEIDY DAIAN RAMIREZ TRIVIÑO FONOAUDIOLOGO null null null

15:18 Samira Nadia amar JUAN GABRIEL PINZON ARTEAGA MEDICO null null null

15:21 Mónica Viviana Guerra

Perdomo JAIRO ARMANDO BLANCO RINCON OPTOMETRIA null null null


Perdomo PAOLA ANDREA VASQUEZ QUIROGA OPTOMETRIA null 15:23 null

15:23 Maria del carmen uni piamba CESAR AUGUSTO ARROYAVE JIMENEZ PRECONSULTA 15:23 null null

15:24 Mónica Viviana Guerra ALEXANDER ALVAREZ FAJARDO OPTOMETRIA null null null

71 Estos registros fueron tomados por un corto tiempo debido a la cantidad de registros que genera en periodos cortos.

72 Se entiende como el inicio del recorrido de la lectura de los pacientes que están en la sala de espera.

73 Se entiende como el final del recorrido de la lectura de los pacientes que están en la sala de espera.

138

Anexo H. (Continuación).


ronda

Fin

ronda


15:26 Aura Cristina Guerra CARLOS ARTURO MOSQUERA PALOMO LABORATORIO null null null


Rendon MAICOL TOQUICA PARDO FONOAUDIOLOGO null null null

15:28 Natalia Gordillo Vargas ALEXANDER ALVAREZ FAJARDO FONOAUDIOLOGO null null 19


Perdomo CARLOS ARTURO MOSQUERA PALOMO OPTOMETRIA null null null


Rendon ANDRES DAVID ORTIZ AROCA FONOAUDIOLOGO null 15:33 null

15:33 Maria del carmen uni piamba CARLOS ARTURO MOSQUERA PALOMO PRECONSULTA 15:33 null null

15:33 Yaneiby Emilia Serrano

Martinez JASBLEIDY TRIANA VELASQUEZ MEDICO null null null

15:34 Natalia Gordillo Vargas WILLIAM ENRIQUE CORTEZ FONOAUDIOLOGO null null null


Perdomo CESAR AUGUSTO ARROYAVE JIMENEZ OPTOMETRIA null null null

15:36 Aura Cristina Guerra LUIS EDUARDO URIBE SIZA LABORATORIO null null 19

139

Anexo H. (Continuación).


ronda

Fin

ronda


15:40 Jairo Orlando Ojeda Cardenas MAICOL TOQUICA PARDO MEDICO null 15:40 null

15:40 Maria del carmen uni piamba LUIS EDUARDO URIBE SIZA PRECONSULTA 15:40 null 18

15:41 Jairo Orlando Ojeda Cardenas JUAN DAVID FRANCO TORO MEDICO null null null

15:42 Aura Cristina Guerra NELSON LIBARDO DIMATE PERALTA LABORATORIO null null null

15:43 Natalia Gordillo Vargas JHAN CARLOS BARRETO LOMBANA FONOAUDIOLOGO null null null


Rendon JOSIAS CAICEDO GRUESCO FONOAUDIOLOGO null 15:43 null

15:43 Diana Marcela Guecha NELSON LIBARDO DIMATE PERALTA PRECONSULTA 15:43 null 18

15:44 Yaneiby Emilia Serrano

Martinez CLAUDIA JULIETH PAIPA LOPEZ MEDICO null null null


Perdomo LUIS EDUARDO URIBE SIZA OPTOMETRIA null null null

implementaciÓn de un sistema de asignaciÓn de … · planteamiento del problema 16 2. marco...

Documents