Upload
others
View
14
Download
0
Embed Size (px)
Citation preview
CTC COMITÉ TÉCNICO CIENTÍFICO
JENNIFER POSSO HENAO
UNIVERSIDAD AUTÓNOMA DE OCCIDENTE FACULTAD DE INGENIERIA
DEPARTAMENTO DE CIENCIAS DE LA INFORMACION PROGRAMA DE INGENIERIA INFORMATICA
SANTIAGO DE CALI 2008
CTC COMITÉ TÉCNICO CIENTÍFICO
JENNIFER POSSO HENAO
Pasantía para optar al título de Ingeniero Informático
Director JESÚS ANTONIO LEMOS
Ingeniero Electricista Magíster en ciencias Computacionales
UNIVERSIDAD AUTÓNOMA DE OCCIDENTE FACULTAD DE INGENIERIA
DEPARTAMENTO DE CIENCIAS DE LA INFORMACION PROGRAMA DE INGENIERIA INFORMATICA
SANTIAGO DE CALI 2008
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 Informático.
Ing. JESÚS ANTONIO LEMOS ___________________________ Director
Santiago de Cali, Febrero de 2008.
AGRADECIMIENTOS
Porque gracias a su cariño, guía y apoyo he llegado a realizar uno de mis anhelos más grandes de mi vida, fruto del inmenso apoyo, amor y confianza que en mi se deposito y con los cuales he logrado terminar mis estudios profesionales que constituyen el legado más grande que pudiera recibir y por los cuales les viviré eternamente agradecida. Con cariño y respeto.
CONTENIDO
Pág.
GLOSARIO 15
RESUMEN 16
INTRODUCCIÓN 17
1. PLANTEAMIENTO DEL PROBLEMA 18
2. MARCO TEÓRICO 19
2.1 LEVANTAMIENTO DE REQUISITOS 19
2.2 ANÁLISIS Y DISEÑO 20
2.3 DIAGRAMA DE CASOS DE USO 21
2.4 DIAGRAMAS DE SECUENCIA 21
2.5 IMPLEMENTACIÓN 22
2.6 LENGUAJES DE PROGRAMACIÓN 22
2.6.1 Visual basic 22
2.6.2 Visual basic .net 23
2.6.3 Sybase 24
3. ANTECEDENTES 26
4. OBJETIVOS 27
4.1 OBJETIVOS GENERAL 27
4.2 OBJETIVOS ESPECIFICOS 27
5. JUSTIFICACIÓN 28
6. METODOLOGÍA 29
7. DESARROLLO DEL PROYECTO 30
8. ESPECIFICACIÓN DE REQUERIMIENTOS DEL SOFTWARE 31
8.1 ANTECEDENTES 31
8.2 ALCANCE 31
8.3 OBJETIVO DEL PROYECTO 32
8.3.1 Objetivos específicos 32
9. DEFINICIÓN DEL SISTEMA 33
10. LISTA DE REQUISITOS FUNCIONALES 34
11. ESPECIFICACIONES SUPLEMENTARIOS (NO FUNCIONALES) 36
11.1 Seguridad 36
11.2 CONFIABILIDAD 37
11.3 USABLE 37
11.4 ADAPTABILIDAD 37
11.5 PORTABILIDAD 37
11.6 UTILIDAD 38
12. DEFINICIÓN DE ACTORES 39
12.1 ACTORES 39
13. LISTADO DE CASOS DE USO 40
13.1 DIAGRAMA DE CASOS DE USO 41
13.2 DESCRIPCIÓN DE CASOS DE USO 41
13.2.1 CU_01 Ingresar al sistema 41
13.2.2 CU_02 Crear usuario 43
13.2.3 CU_03 Modificar usuario 45
13.2.4 CU_04 Consultar usuario 48
13.2.5 CU_05 Deshabilitar/habilitar usuario 50
13.2.6 CU_06 Ingresar solicitud 52
13.2.7 CU_07 Modificar solicitud 54
13.2.8 CU_08 Consultar solicitud 57
13.2.9 CU_09 Estudio médico 60
13.2.10 CU_10 Evaluar solicitud 62
13.2.11 CU_11 Modificar estudio medico 65
13.2.12 CU_12 Ingresar medico tratante 68
13.2.13 CU_13 Ingresar ips 70
13.2.14 CU_14 Ingresar paciente 72
13.2.15 CU_15 Ingresar medicamento 74
13.2.16 CU_16 Realizar informe 76
14. MATRIZ CASOS DE USO – REQUISITOS 78
15. INTERFACES 80
16. MODELO DE ARQUITECTURA DE CASO DE USO 81
16.1 CASOS DE USO SIGNIFICATIVOS 81
16.2 DESCRIPCIÓN TEXTUAL 81
17. MODELO DE ANÁLISIS DEL SISTEMA 83
17.1 REALIZACIÓN DE CASOS DE USO 83
17.1.1 CU_01 Ingresar al sistema 83
17.1.2 CU_02 Crear usuario 85
17.1.3 CU_03 Modificar usuario 87
17.1.4 CU_04 Consular usuario 89
17.1.5 CU_05 Deshabilitar/habilitar usuario 91
17.1.6 CU_06 Ingresar solicitud 92
17.1.7 CU_07 Modificar solicitud 95
17.1.8 CU_08 Consultar solicitud 97
17.1.9 CU_09 Estudio médico 99
17.1.10 CU_10 Evaluar solicitud 101
17.1.11 CU_11 Modificar estudio medico 103
17.1.12 CU_12 Ingresar medico tratante 105
17.1.13 CU_13 Ingresar ips 107
17.1.14 CU_14 Ingresar paciente 108
17.1.15 CU_15 Ingresar medicamento 110
17.1.16 CU_16 Realizar informe 111
18. PAQUETES DE ANÁLISIS 113
19. DESCRIPCIÓN DE PAQUETES DE ANÁLISIS 116
19.1 PAQUETE: “UI PACKAGE” 116
19.2 PAQUETE: “CONTROL PACKAGE” 116
19.3 PAQUETE: “ENTITY PACKAGE” 117
20. DESCRIPCIÓN DE ARQUITECTURA 118
21. DISEÑO Y MODELO DE DATOS 121
21.1 MODELO ENTIDAD RELACIÓN MER 121
21.2 MODELO RELACIONAL DE DATOS 122
22. CONCLUSIONES 127
23. RECOMENDACIONES 128
BIBLIOGRAFIA 129
ANEXOS 130
LISTA DE TABLAS
Pág. Tabla 1. Requerimientos Funcionales del Sistema 34 Tabla 2. Requerimientos No Funcionales del Sistema 36 Tabla 3. Lista de Casos de Uso 40 Tabla 4. CU_01 Ingresar al Sistema 42 Tabla 5. CU _ 02 Crear Usuario 43 Tabla 6. CU_03 Modificar Usuario 45 Tabla 7. CU_04 Consultar Usuario 48 Tabla 8. CU_05 Deshabilitar / Habilitar Usuario 50 Tabla 9. CU_06 Ingresar Solicitud 52 Tabla 10. CU_07 Modificar Solicitud 55 Tabla 11. CU_08 Consultar Solicitud 58 Tabla 12. CU_09 Estudio Médico 60 Tabla 13. CU_10 Evaluar Solicitud 63 Tabla 14. CU_11 Modificar Estudio Medico 65 Tabla 15. CU_12 Ingresar Médico Tratante 68 Tabla 16. CU_13 Ingresar IPS 70 Tabla 17. CU_14 Ingresar Paciente 72 Tabla 18. CU_15 Ingresar Medicamentos 74 Tabla 19. CU_16 Realizar Informe 76 Tabla 20. Matriz de Requisitos 78
Tabla 21. MRD Paciente. 122 Tabla 22. MRD Médico Tratante. 122 Tabla 23. MRD Tabla Ciudad. 123 Tabla 24. MRD Departamento. 123 Tabla 25. MRD Medicamento. 123 Tabla 26. MRD Evaluación Solicitud. 124 Tabla 27. MRD Solicitud. 124 Tabla 28. MRD IPS. 124 Tabla 29. MRD Entidad Patológica. 125 Tabla 30. MRD Actas. 125 Tabla 31. MRD Presentación Medicamento. 125 Tabla 32. Unidades de Concentración. 125 Tabla 33. MRD Perfil de Usuario. 126 Tabla 34. MRD Usuario 126 Tabla 35. MRD Bitácora. 126
LISTA DE FIGURAS
Pág.
Figura 1. Diagrama de Casos de Uso 41
Figura 2. Interfaz del Sistema 80
Figura 3. Modelo de la Arquitectura 81
Figura 4. Diagrama de Clase CU_01 83
Figura 5. Diagrama de Secuencia CU_01 84
Figura 6. Diagrama de Clase CU_02 85
Figura 7. Diagrama de Secuencia CU_02 86
Figura 8. Diagrama de Clase CU_03 87
Figura 9. Diagrama de Secuencia CU_03 88
Figura 10. Diagrama de Clase CU_04 89
Figura 11. Diagrama de Secuencia CU_04 90
Figura 12. Diagrama de Clase CU_05 91
Figura 13. Diagrama de Secuencia CU_05 91
Figura 14. Diagrama de Clase CU_06. 92
Figura 15. Diagrama de Secuencia CU_06 93
Figura 16. Diagrama de Clase CU_07 95
Figura 17. Diagrama de Secuencia CU_07 96
Figura 18. Diagrama de Clase CU_08 97
Figura 19. Diagrama de Secuencia CU_08 98
Figura 20. Diagrama de Clase CU_09 99
Figura 21. Diagrama de Secuencia 100
Figura 22. Diagrama de Clase CU_10 101
Figura 23. Diagrama de Secuencia CU_10 102
Figura 24. Diagrama de Clase CU_11 103
Figura 25. Diagrama de Secuencia CU_11 104
Figura 26. Diagrama de Clase 105
Figura 27. Diagrama de Secuencia CU_12 106
Figura 28. Diagrama de Clase CU_13 107
Figura 29. Diagrama de Secuencia CU_13 107
Figura 30. Diagrama de Clase CU_14 108
Figura 31. Diagrama de Secuencia CU_14 109
Figura 32. Diagrama de Clase CU_15 110
Figura 33. Diagrama de Secuencia CU_15 110
Figura 34. Diagrama de Clase CU_16 111
Figura 35. Diagrama de Secuencia CU_16 112
Figura 36. Arquitectura Cliente/Servidor 118
Figura 37. Modelo de Capas 119
Figura 38. Modelo Entidad Relación. 121
LISTA DE ANEXOS
Pág.
Anexo 1. Formato Ingreso de Solicitud 130
GLOSARIO ADMINISTRADOR: es el encargado del manejo general del sistema para el Comité Técnico Científico CTC, puede ser del personal de informática o el correspondiente asignado por la empresa del Seguro Social. CASO DE USO: en ingeniería del software, un caso de uso es una técnica para la captura de requisitos potenciales de un nuevo sistema o una actualización software. Cada caso de uso proporciona uno o más escenarios que indican cómo debería interactuar el sistema con el usuario o con otro sistema para conseguir un objetivo específico. COMITÉ TÉCNICO CIENTÍFICO (CTC): el Comité Técnico Científico se ha creado para funcionar por la Superintendencia Nacional de Salud. Las entidades promotoras de Salud, EPS y demás entidades obligatorias a compensar, EOC y las administradoras del régimen subsidiado, ARS, integraron un Comité Técnico Científico CTC, que está conformado por un representante de la EPS, EOC o ARS, según corresponda, un representante de las Instituciones Prestadoras de Salud, IPS, y un representante de los usuarios. CONSULTOR: es el encargado solo y únicamente de consultar las solicitudes que se ingresan en el sistema del Comité Técnico Científico, sean estas aprobadas, negadas o aplazados por el CTC. DIGITADOR: es el encargado de digitar las solicitudes de medicamentos que se encuentran en el Comité Técnico Científico CTC. FOSYGA: es el Fondo de Solidaridad y Garantía, a la cual se envían los formatos de las solicitudes por concepto de medicamentos no incluidos en el Plan Obligatorio de Salud, Pos y fallos de tutela. IU: (User Interface) interfaz grafica de usuario MEDICO: es el encargado de la aprobación, negación o aplazo de las solicitudes de medicamentos en el Comité Técnico Científico, puede ser médico general, químico, farmacéutico o profesional de la salud, este último con experiencia comprobada en el área de farmacología de mínimo dos (2) años. SYBASE: base de datos que maneja el Seguro Social.
RESUMEN
La historia de la humanidad ha pasado por diferentes etapas de evolución de sus formas de producción y organización, correspondiendo a cada una de ellas su respectivo modo de vivir, pensar conocer, es decir, ética, razón y ciencia. En la actualidad los cambios sociales, económicos y culturales están dando pie a una nueva sociedad que se ha dado cuenta que la información es la parte principal y el activo más importante de las empresas y gracias al surgimiento de nuevas tecnologías, se ha logrado realizar sistemas que nos ayudan a administrar y acceder a ella cuando lo necesitamos, donde lo necesitemos con gran eficiencia y eficacia. Con este trabajo de grado planteó diseñar y construir un sistema de información que permita automatizar los procesos del comité Técnico Científico CTC de la Empresa Del Seguro Social, permitiendo a diferentes usuarios (digitador, medico, consultor y administrador) tener acceso a la información que el proyecto genere. Con este sistema se pretende contribuir de forma positiva en los siguientes aspectos: • Cultural: resguarda la creación de una nueva cultura en los usuarios al ofrecer un nuevo estilo sobre cómo realizar estos procesos y propicia que cada uno de los usuarios se apersone de su información y siempre este pendiente de cómo avanza el proceso, teniendo en cuenta que estos procesos son de gran importancia para el Comité Técnico Científico CTC. • Administrativo: soporta que el Comité Técnico Científico CTC administre mejor la información ya que esta se encuentra almacenadas en sistemas gestores de datos que garantizan la disponibilidad, integridad y fácil acceso a la misma.
17
INTRODUCCIÓN Lo más importante de toda empresa es llevar a cabo una gran administración de su información, para así lograr confiabilidad y mayor control a la hora de tomar decisiones contribuyendo al éxito de la misma. Actualmente las grandes Empresas ejercen sus funciones bajo sistemas que permiten almacenar toda su información, logrando una mejor eficiencia al momento de ingresar todos los datos con procesos computarizados, definiendo así, la calidad del software como la concordancia entre los requerimientos funcionales, el rendimiento explícitamente establecido, los estándares de desarrollo explícitamente documentados y las características implícitas que se espera de todo software desarrollado profesionalmente. El Instituto Seguro Social, es una de las Empresas más importante del Estado y el principal actor en el campo de la seguridad social en Colombia, con la misión de brindar aseguramiento a los trabajadores, Empresas y jubilados colombianos y a sus familias en los rubros de pensión, salud y riesgos profesionales. Hoy en día la EPS Seguro Social cuenta con el Comité Técnico Científico (CTC), que surge como respuesta a las dificultades presentadas en el manejo de solicitudes de medicamentos, las cuales son estudiadas y evaluadas de acuerdo a criterios médicos establecidos para los procedimientos, los formatos y los registros para la solicitud y aprobación de medicamentos esenciales que no están incluidos en el Plan Obligatorio de Salud (POS). El propósito de este proyecto es agilizar el ingreso de las solicitudes de medicamentos mediante procesos automatizados, de tal manera que tengan un registro confiable en el transcurso del procesamiento de esta información.
18
1. PLANTEAMIENTO DEL PROBLEMA
La EPS Seguro Social, sede Bellavista en Cali, en su obligación de prestar un servicio oportuno a sus afiliados, en cuanto a las solicitudes de medicamentos que no están incluidos dentro del Plan obligatorio de Salud (POS), crea la oficina Comité Técnico Científico (CTC), encargada de recepcionar, estudiar y evaluar de acuerdo a criterios médicos, la aprobación, prórroga y/o negación de la solicitud de medicamentos y, así mismo, de enviar a la oficina de recobros las solicitudes aprobadas por el Comité Técnico Científico(CTC), en el respectivo formato establecido, para luego ser enviadas al Fondo de Solidaridad y Garantía (FOSYGA), y hacer su respectivo cobro. Debido al elevado crecimiento de las solicitudes de medicamentos y a la necesidad de brindar una respuesta oportuna, fiable y estadística al afiliado, se crea un software para tal fin, el cual está presentando inconvenientes. A partir de este problema se redefinen cuáles son las necesidades que requiere el software para lograr un óptimo desempeño, ya que a partir de esas necesidades se da a conocer cuál es la importancia y las funciones que debe realizar la aplicación, de no ser así, se ocasionan diversos problemas, como los de diseño e implementación, al punto de convertirse en la necesidad de desarrollar un nuevo software aplicativo que resuelva los inconvenientes que actualmente está presentando.
19
2. MARCO TEÓRICO Este proyecto tiene la finalidad de analizar, diseñar e implementar un software aplicativo haciendo uso de la ingeniería de software, y del lenguaje unificado UML para: visualizar, especificar, construir y documentar la aplicación a desarrollar, ofreciendo un estándar para describir correctamente el sistema que se va a establecer. Los objetivos de la ingeniería de software son: • Mejorar la calidad de los productos software.
• Facilitar el control del proceso de desarrollo de software. • Suministrar a los desarrolladores las bases para construir software de alta calidad de una forma eficiente. • Definir una disciplina que garantice la producción y el mantenimiento de los productos de software desarrollados en el plazo fijado y dentro del costo estimado. A continuación se ilustran las fases del desarrollo aplicadas a contexto del Proyecto. 2.1 LEVANTAMIENTO DE REQUISITOS El levantamiento de requisitos son aquellas descripciones de los servicios proporcionados por el sistema y sus restricciones operativas donde se reflejan las necesidades de los interesados, que ayuda a resolver algún problema. Este proceso establece los servicios que el cliente requiere de su sistema y los limites bajo los cuales opera y se desarrolla. La necesidad de establecer requisitos es fundamental en el momento de realizar el proyecto, ya que estos requerimientos especifican las prioridades de las funcionalidades y los niveles de operaciones que requiere el software. Durante el levantamiento de requerimientos se tendrá en cuenta el análisis previo del funcionamiento que realiza el aplicativo para el almacenamiento de datos e igualmente, ir definiendo poco a poco los requerimientos funcionales y no funcionales.
20
Para el presente proyecto se debe realizar un sistema de información administrativa destinada al almacenamiento de las solicitudes de medicamentos al sistema, además de permitir modificar ciertos datos únicamente bajo criterios médicos, permitiendo hacer consultas de las solicitudes ingresadas anteriormente. Este sistema debe guardar automáticamente los datos ingresados por el digitador de manera que el usuario pueda registrar un nuevo proceso. Como otros requerimientos para el sistema, hay que asegurar que el tiempo de respuesta del sistema sea el apropiado dentro de las factibilidades técnicas y de las necesidades del usuario. El sistema debe operar, ordenar y estandarizar datos y reportes de los distintos procesos que requiera el Comité Técnico Científico (CTC), para que genere su respectivo formato y facilite la interpretación de los datos que contenga. En el proceso de levantamiento de requerimientos, el sistema debe generar ciertas actividades que durante el proceso de esta primera etapa se definirán de acuerdo a las solicitudes que el cliente requiera. La definición de los requisitos se llevara a cabo mediante la participación de comités, los cuales se organizarán en convenio con el Comité Técnico Científico (CTC). 2.2 ANÁLISIS Y DISEÑO
Durante el análisis y el diseño del proyecto, se analizan los requisitos que se describieron en la anterior etapa, refinándolos y estructurándolos con el objetivo de conseguir una comprensión más precisa de los requisitos y una descripción de los mismos, para que sea fácil mantener y estructurar el sistema entero en el cual se va a trabajar. La descripción se hace en tres pasos: Identificación de artefactos, roles y actividades. Para la identificación de artefactos a desarrollar, se debe tener en cuenta los recursos que maneja el Comité Técnico Científico (CTC) para su respectiva documentación y, así, poder construir adecuadamente el software a implementar; los roles que participan, son las relaciones de usuarios que hacen uso directamente de esta aplicación y las actividades que se desarrollan, es decir, son las funciones principales que maneja el Comité Técnico Científico (CTC). Con el análisis nos enfocamos a estructurar los requisitos de un modo que facilita su compresión, su preparación, su modificación y en general su mantenimiento para considerar una primera aproximación al Diseño. El diseño del sistema describe la forma en cómo el sistema cumplirá con los requisitos identificados. El
21
diseñador realiza esquemas, describe estructuras de archivos, identifica datos de entrada y salida, y los representa mediante diagramas, tablas y símbolos. Para la etapa de diseño se hace referencia a la integración de los Diagramas de Casos de Uso y los Diagramas de Secuencia, la información detallada en esta fase se proporciona al equipo de programación para comenzar con la fase de desarrollo y, así llevar a cabo una estructura detallada del sistema, para seguir al paso de implementación. 2.3 DIAGRAMA DE CASOS DE USO En un diagrama de casos de uso se representa gráficamente parte o el total de las personas involucradas y casos de uso, es decir, acciones que realiza el software incluyendo sus interacciones, donde se ve el entorno del sistema a realizar y su funcionalidad principal. Durante el desarrollo del los casos de uso del proyecto “CTC Comité Técnico Científico” se especificará cada actividad y función que debe realizar el software y las personas involucradas, haciendo una descripción detallada de las actividades correspondientes a realizar en el software aplicativo. Estas descripciones ayudarán en la formación adecuada de un buen desarrollo, especificando paso a paso lo que se debe hacer y cómo se desempeña cada actividad, es decir, si la actividad a realizar es el ingreso de una nueva solicitud, el diagrama de caso de uso me especificara gradualmente como se hace el respectivo ingreso de la solicitud. Se tendrá en cuenta para la realización de cada Caso de Uso los prerrequisitos, antecedentes y post- condiciones que abarca cada una de las actividades a desarrollar. En el diagrama de casos de uso se mostrara, por tanto, los distintos requisitos funcionales que se establecieron en la primera etapa de levantamiento de requisitos, en el que se aplican todas las exigencias que cumple el Comité Técnico Científico (CTC) para el funcionamiento adecuado del aplicativo software a realizar. 2.4 DIAGRAMAS DE SECUENCIA
El Diagrama de Secuencia es uno de los diagramas más efectivos para modelar interacción entre objetos que realiza el proyecto, este diagrama se modela para cada caso de uso, en donde el diagrama de secuencia contiene los detalles de
22
implementación del escenario, incluyendo los objetos y clases que se usan para implementar, y mensajes pasados entre los objetos. En esta etapa, las clases tienen ya definidas las operaciones que debe realizar el software requerido por el Comité Técnico Científico (CTC), estas clases se definen durante el proceso de construcción de los diagramas de secuencia para cada respectivo caso de uso y así poder realizar la implementación necesaria en la siguiente etapa. Propiamente se evalúa la descripción de un caso de uso para determinar qué objetos son necesarios para la implementación del escenario. Al terminar la etapa de diseño, hemos refinado suficientemente los Diagrama de Casos de Uso, Diagramas de Secuencia y las relaciones entre estas. También conocemos mejor los mensajes que se intercambian los objetos para realizar las tareas necesarias. Durante la siguiente etapa nuevamente entraremos en otro ciclo para mejorar algunos detalles que se hacen visibles sólo al momento de la implementación. 2.5 IMPLEMENTACIÓN
La implementación del proyecto tiene como significado el análisis lógico, para así mismo efectuar la implementación física, donde se lleva a cabo la forma cómo se va a desarrollar el sistema y cómo es capaz de responder a las peticiones descritas por el conjunto de requerimientos, análisis e interfaces a las que proporciona su realización. Para realizar la implementación del sistema software se tendrá en cuenta bajo que lenguaje de programación se va a realizar, operando sobre las herramientas que trabaja el Seguro Social. Dentro de los lenguajes de programación más utilizados en la Empresa, la cual maneja la mayor parte de sus aplicaciones bajo las siguientes herramientas de programación: 2.6 LENGUAJES DE PROGRAMACIÓN
2.6.1 Visual Basic . “Visual Basic es una herramienta de diseño de aplicaciones para Windows, en la que se desarrollan en una gran parte, a partir del diseño de una interfaz grafica. En una aplicación visual Basic, el programa está formado por
23
una parte de código puro, y otras partes asociadas a los objetos que forman la interfaz grafica”1. Es un lenguaje de fácil aprendizaje pensado, guiado por eventos, y centrado en un motor de formularios que facilita el rápido desarrollo de aplicaciones graficas. No requiere de manejo de punteros y posee un manejo muy sencillo de cadenas de caracteres, permitiendo varias bibliotecas para maneo de bases de datos, es por tanto un término medio entre la programación Visual Basic es una herramienta de diseño de aplicaciones para Windows, en la que se desarrollan en una gran parte, a partir del diseño de una interfaz grafica. En una aplicación visual Basic, el programa está formado por una parte de código puro, y otras partes asociadas a los objetos que forman la interfaz grafica. Es un lenguaje de fácil aprendizaje pensado, guiado por eventos, y centrado en un motor de formularios que facilita el rápido desarrollo de aplicaciones graficas. No requiere de manejo de punteros y posee un manejo muy sencillo de cadenas de caracteres, permitiendo varias bibliotecas para maneo de bases de datos, es por tanto un término medio entre la programación tradicional, formada por una sucesión lineal de código estructurado, y la programación orientada a objetos, combinando ambas tendencias. Este lenguaje es utilizado principalmente para aplicaciones de gestión de Empresas, debido a la rapidez con la que puede hacerse un programa que utilice una base de datos sencilla. El Seguro social trabaja Visual Basic por ser una herramienta de fácil manejo a la hora de creación de programación que maneja formularios, lo cual Visual Basic permite: Creación de una interfaz de usuario. Definición de las propiedades de los controles – objetos. Generación del código asociado a los eventos que ocurran a los objetos, que se generan de acuerdo a las necesidades del programa. Generación del código del programa 2.6.2 Visual Basic .NET . “Cada vez más organizaciones de todos los tamaños, con programadores de Visual Basic de todos los niveles de conocimiento, están reconociendo el amplio conjunto de características y los nuevos niveles de
1 Wikipedia. Enciclopedia Libre [en línea].Florida: Microsoft Visual Basic, 2007. [Consultado 05 de noviembre, 2007]. Disponible en internet: http://es.wikipedia.org/wiki/Visual_Basic
24
productividad que ofrece Visual Basic .NET, y están implementando sus aplicaciones cruciales utilizando esta lenguaje de programación”2. Actualmente Visual Basic .NET, ofrece capacidades de diseño completamente orientado a objetos y acceso directo a Microsoft .NET, Framework, entorno que proporciona un amplio conjunto de interfaces de programación de aplicaciones para Windows e Internet. Visual Basic .NET proporciona una mejora en la seguridad, administración de la memoria, control de las versiones y compatibilidad con la implementación a desarrollar. Otras de sus características más importantes son:
• Diseño de controles de usuario para aplicaciones Windows y Web. • Programación de bibliotecas de clase. • Envió de datos vía documentos XML. • Generación de reportes basados en Crystal Reports a partir de información obtenida de orígenes de datos. Por razón de este lenguaje de programación nos enfocamos a realizar el presente proyecto para el Comité Técnico Científico (CTC) del Seguro social.
2.6.3 Sybase . “La toma intuitiva de decisiones requiere de un extra en el mundo competitivo de hoy. Responder a la demanda de la inteligencia de negocio, análisis avanzado de datos, modelamiento predictivo, regulaciones estrictas y extremadamente rápida generación de reportes, requiere más de lo que un sistema tradicional de gestión de datos puede manejar”3. Sybase es una compañía líder en el desarrollo y expansión de tecnología innovadora para la movilización de información, Sybase se ha ganado la confianza de muchas de las compañías más importantes del mundo por su habilidad en la gestión de información. Con una base global y leal de clientes y una fuerte presencia en mercados verticales clave, como servicios financieros, telecomunicaciones, salud y gobierno, Sybase ha permitido materializar, a clientes de todos los tamaños. Sus soluciones abiertas y multiplataforma entregan la información de manera segura, en cualquier momento y lugar, permitiendo que los clientes creen una ventaja de información, con las soluciones de software Sybase, los clientes pueden optimizar y mejorar
2 Ibíd.., Disponible en Internet: http://es.wikipedia.org/wiki/Visual_Basic 3 MTBase Sybase de Colombia [en línea]. Colombia: Sybase de Colombia. [Consultado 10 de noviembre, 2007]. Disponible en Internet http://www.mtbase.com/productos/gestionbasesdedatos
25
sus inversiones, relacionar sus recursos de información y extender el alcance de sus aplicaciones de negocio. Sybase es un motor de bases de datos altamente optimizado para inteligencia empresarial, utilizado por el instituto Seguro social. Diseñado específicamente para entregar resultados más rápidos en soluciones de inteligencia empresarial analítica de misión crítica, almacenamiento de datos y generación de reportes.
26
3. ANTECEDENTES Como quiera que la aplicación a desarrollar para el Comité Técnico Científico (CTC) se caracterice por ser un sistema que va dirigido, en particular a la persona que maneja el ingreso de las solicitudes de medicamentos de los afiliados al Seguro Social; no existe en el mercado un producto que, de manera genérica, pueda ser aplicado a este proceso. En la actualidad, el Seguro Social trabaja con un aplicativo generado por un contratista que implementó sin un previo análisis y diseño referente a las funciones del Comité Técnico Científico (CTC), que, a medida que crezcan las solicitudes de medicamentos y sus aplicaciones, no satisfará los requisitos concordantes, generando así, un nuevo levantamientos de la información que permita visualizar el proceso en curso. Del mismo modo, cabe apuntar, que el aplicativo en mención no es considerado, hoy, por el Seguro Social como “Crítico” para su funcionamiento, en tanto que existen actividades más importantes que requieren soluciones de mayor prioridad, presentando, también, inconvenientes cuando de generar los informes y llenar las solicitudes correspondientes a los medicamentos de los afiliados se trate, por esta razón se busca encontrar una solución optima al problema.
27
4. OBJETIVOS
4.1 OBJETIVOS GENERAL El presente documento tiene como objetivo analizar, diseñar y desarrollar un aplicativo software para el Comité Técnico Científico CTC, encargado de llevar a cabo el manejo de solicitudes de medicamentos no incluidos dentro del Plan Obligatorio de Salud (POS) para los afiliados al Seguro Social. 4.2 OBJETIVOS ESPECIFICOS • Estudiar y entender el proceso de solicitudes de medicamentos de acuerdo con criterios médicos. • Comprender el funcionamiento del sistema software que utiliza actualmente el Comité Técnico Científico (CTC). • Obtener información en tiempo real al servicio del Comité Técnico Científico (CTC). • Realizar el análisis y diseño del sistema que permita visualizar el proceso de una manera estandarizada. • Diseñar un aplicativo software integrado que dé soluciones eficaces y eficientes a los problemas actuales. • Desarrollar módulos dentro de la aplicación que generen informes estadísticos de gestión. • Evaluar el desempeño del sistema de información del Comité Técnico Científico • Implantar la solución en la órbita del Comité Técnico Científico (CTC) del Seguro Social.
28
5. JUSTIFICACIÓN El seguimiento de procesos bien definidos permite a toda organización tener un mejor control del capital humano como de las actividades y dispositivos que están involucrados en sus proyectos (personas, tiempos, documentación, responsabilidades, costos, entre otros) solucionando las disconformidades que se presentan. La realización de este proyecto es de vital importancia para la Empresa Instituto Seguro Social, por cuanto fortalece cualitativamente a la organización mediante la metodología planteada, un efectivo control y manejo de las solicitudes de medicamentos de sus afiliados con criterios médicos, mejorando la calidad y eficiencia en la prestación del servicio y una respuesta oportuna. Este proyecto apunta a unificar los formatos de solicitudes hechas por el Comité Técnico Científico (CTC), permitiendo mantener al día el registro de solicitudes de medicamentos del Plan Obligatorio de Salud (POS).
29
6. METODOLOGÍA
El proceso de desarrollo de software requiere de un conjunto de conceptos, una metodología y un lenguaje propio, denominado su “ciclo de vida”, y comprende cuatro grandes fases: concepción, elaboración, construcción y transición. La concepción define el alcance del proyecto y desarrolla un caso de negocio; la elaboración, el plan del proyecto y especifica las características y fundamenta la arquitectura; la construcción, crea el producto; y la transición, transfiere el producto a los usuarios. Para la realización del presente Proyecto, se seguirá la metodología estándar propia de la Ingeniería Informática, la cual es mundialmente reconocida como herramienta de la Ingeniería de Software. En su desarrollo utilizaremos el “Modelo en Cascada” que ordena, en forma secuencial, las etapas del ciclo de vida del proyecto, de tal modo que el inicio de cada una debe esperar la finalización inmediata de la anterior, como se anuncia a continuación: Paso uno: Análisis de requisitos Paso dos: Diseño del Sistema Paso tres: Diseño del Programa Paso cuatro: Implementación Paso quinto: Pruebas Paso sexto: Implantación
De suerte que cualquier error de diseño detectado en las etapas conduce, necesariamente, al rediseño de las anteriores y de las que siguen.
30
7. DESARROLLO DEL PROYECTO Para el presente proyecto se utilizó el Modelo Cascada, la cual esta está basada en el ciclo convencional de una ingeniería, abarcando las actividades para la realización y desarrollo del proyecto. Esta adaptación fue realizada en mutuo acuerdo entre los encargados del proyecto en el Comité Técnico científico CTC y dio origen a la metodología utilizada en el proyecto. Debido a la cantidad de procesos, al tamaño del sistema y su naturaleza Web se decidió utilizar el paradigma de desarrollo incremental, ya que este modelo es el que más se ajustó a las necesidades y es el más utilizado para el desarrollo Web. Para modelar los componentes y la iteración su utilizo el Lenguaje Unificado de Modelado (UML), y se modelaron los siguientes diagramas por cada modulo del sistema: • Diagramas de Casos de Uso. • Diagramas de Clases. • Diagramas de Secuencia. • Diagrama de Paquetes.
31
8. ESPECIFICACIÓN DE REQUERIMIENTOS DEL SOFTWARE 8.1 ANTECEDENTES
La Empresa Instituto Seguro Social sede administrativa Bellavista, tienen como actividad controlar el ingreso de solicitudes de medicamentos que no están incluidos dentro del Plan obligatorio de Salud (POS), la EPS cuenta con el Comité Técnico Científico (CTC), que surge como respuesta a las dificultades presentadas en el manejo de solicitudes de medicamentos, encargada de recepcionar, estudiar y evaluar de acuerdo a criterios médicos, la aprobación, aplazamiento y/o negación de la solicitud de medicamentos de los afiliados. Para este propósito se debe implementar un software que permita controlar las diferentes actividades que el Comité Técnico Científico (CTC) requiera para manejar las diferentes funciones más importantes y así tener un mayor control en el manejo de ingreso de solicitudes de medicamentos dando una solución optima para la Empresa.
8.2 ALCANCE La Empresa Instituto Seguro Social, entre sus servicios presta aseguramiento a los trabajadores, empresas y pensionados colombianos y sus familias en salud, pensiones, riesgos profesionales y otros seguros de protección social, orientados por los principios de universalidad, sostenibilidad, calidad y eficiencia. El Seguro Social maneja la oficina del Comité Técnico Científico (CTC), la cual es encargada de autorizar las solicitudes de medicamentos no incluidos en el Plan obligatorio de Salud (POS) de sus afiliados. El sistema permitirá manejar varios perfiles para el manejo de cada una de las actividades que se deseen realizar, esto se controlará dependiendo el nivel de seguridad que se asigne a cada perfil. El sistema se enfoca en el registro de las solicitudes de medicamentos no incluidos en el Plan Obligatorio de Salud (POS) diligenciadas de acuerdo a criterios médicos.
32
8.3 OBJETIVO DEL PROYECTO El objetivo del proyecto es desarrollar una aplicación software que permita ingresar, estudiar y evaluar de acuerdo a criterios médicos, la aprobación, prórroga y/o negación de la solicitud de medicamentos, asegurando el desarrollo y correcto desempeño de la aplicación. 8.3.1 Objetivos Específicos • Utilizar los procesos de ingeniería de software para lograr la correcta transformación de los requisitos del usuario en el sistema software. • Utilizar la disciplina de requisitos para delimitar la funcionalidad del sistema. • Asegurar la especificación y elaboración oportuna de los diferentes requisitos establecidos. • Determinar la importancia y complejidad de los diferentes procesos ejecutados en la empresa.
• Documentar y organizar la información para realizar la implementación
33
9. DEFINICIÓN DEL SISTEMA El usuario de este software debe, por lo menos, haber manejado programas básicos de office y tener conocimiento de cómo se debe diligenciar un formato de solicitud de medicamento que manejo el Comité Técnico Científico CTC. El sistema va dirigido básicamente a cinco usuarios finales: El Administrador: es el encargado de manejar el aplicativo en forma generar, es decir, puede realizar todas las funciones que realiza el software. El Digitador: es el encargado realizar el ingreso y modificación de las solicitudes antes de ser evaluadas bajo criterios médicos. El Médico: es el encargado de aprobar, aplazar y/o negar la solicitud ingresada por el digitador. El Consultor: es el encargado de consultar las solicitudes ingresadas al sistema e imprimirlas para enviarla a Fosyga o para entregar la solicitud al paciente. La impresora: es la encargada de imprimir las solicitudes y los reportes generados por el software. El software permitirá varias opciones, entre ellas se encuentran principalmente: Ingreso de solicitudes, Modificación de las solicitudes, la modificación de las solicitudes se realizara de acuerdo a criterios médicos, la solicitud ingresada solo pude ser modificada por el encargado con su respectivo perfil. Consultar solicitudes, La consulta de solicitudes se realiza cada vez que el usuario desee saber que solicitud es aprobada, aplazado y/o negada por el Médico del Comité Técnico Científico.
34
10. LISTA DE REQUISITOS FUNCIONALES A continuación en la tabla No.1 se presentan los requisitos funcionales que requiere el sistema: Tabla 1. Requerimientos Funcionales del Sistema
Requisitos Funcionales
RF1 El software debe permitir validar la fecha del sistema
RF2 El software debe permitir pedir login y password para ingresar al sistema
RF3 El software debe permitir crear usuario
RF4 El software debe permitir modificar usuario
RF5 El software debe permitir consultar usuario
RF6 El software debe permitir deshabilitar/habilitar usuario
RF7 El software debe permitir crear perfil
RF8 El software debe permitir modificar perfil
RF9 El software debe permitir deshabilitar/habilitar perfil de usuario
RF10 El software debe permitir ingresar solicitud
RF11 El software debe permitir consultar solicitudes para los perfiles asignados al aplicativo
RF12 El software debe permitir modificar solicitud para los perfiles asignados al aplicativo
RF13 El software debe permitir ingresar Medicamentos
RF14 El software debe permitir ingresar IPS
RF15 El software debe permitir ingresar Medico Tratante
35
Continuación Tabla 1. Requerimientos Funcionales del Sistema
RF16 El software debe permitir ingresar Paciente
RF17 El software debe permitir registro de usuario
RF18 El software debe permitir registro de formato de recobro enviado a Fosyga
RF19 El software debe permitir registro de formato de respuesta a solicitud de medicamentos entregado a paciente
RF20 El software debe permitir realizar informe de formato de recobro
RF21 El software debe permitir realizar informe de formato de solicitud de medicamentos
RF22 El software debe permitir ingresar datos de cotizante en caso que el cotizante del paciente no se encuentre en el sistema
RF23 El software debe permitir modificar la evaluación médica solo cuando el médico lo requiera antes de ser entregada o impresa al paciente
RF24 El software debe permitir imprimir reportes
RF25 El software debe permitir imprimir formato de recobro a Fosyga
RF26 El software debe permitir imprimir formato de solicitud de medicamento a paciente
RF27 El software debe permitir evaluar solicitudes, es decir, el médico tiene la opción de aprobar, negar y/o aplazar una solicitud de medicamento
RF28 El software debe permitir estudiar las solicitudes médicas, es decir el médico tiene la opción de mirar si la solicitud es correcta para luego ser evaluada.
RF29 El software debe permitir al médico modificar el estudio médico de una solicitud de medicamento
36
11. ESPECIFICACIONES SUPLEMENTARIOS (NO FUNCIONALES ) A continuación la tabla No.2 muestra los requerimientos no funcionales del sistema Tabla 2. Requerimientos No Funcionales del Sistema Requisitos No Funcionales.
RN1 El software no debe interferir en la ejecución de otros programas.
RN2 Validar que no haya duplicidad de usuarios.
RN3 Los colores de la aplicación deben ser acordes con el emblema de la empresa
RN4 El software debe validar la fecha del sistema
RN5 El software debe validar los campos correspondientes a cada formulario
RN6 Multiplataforma
RN7 Validar seguridad de perfiles
RN8 Los reportes deben tener la fecha correspondiente al día y el nombre del usuario que la realizo.
11.1 SEGURIDAD El sistema debe ser completamente seguro, es decir debe tener restricción de usuarios ya que no todas las personas que trabajen en la empresa tendrán acceso al aplicativo. El uso de los perfiles permitirá tener un control sobre las acciones realizadas por los usuarios sobre el sistema.
37
11.2 CONFIABILIDAD El sistema debe ser veraz y objetivo, es decir evitar adulteraciones a los datos del sistema y brindar la información precisa. El sistema debe de ser confiable ya que el software maneja una información muy importante. 11.3 USABLE
• Capacidad para ser entendido: cabe apuntar que el sistema se desempeñará con todos los requerimientos mediante un conjunto de herramientas que le permitirá al usuario un manejo simple y adecuado • Capacidad para ser aprendido: - El software brindara información relevante sobre su funcionamiento y operación de las actividades correspondientes. • Capacidad para ser operado: - El software debe permitir una buena interacción entre el usuario y la aplicación.
• Capacidad de atracción: - El software debe tener una apariencia visual llamativa al usuario.
11.4 ADAPTABILIDAD El sistema debe ser adaptable a todo tipo de cambio que ocurra en la empresa, desde cambio de clientes hasta el cambio de una maquina, en general a cualquier cambio que se presente. 11.5 PORTABILIDAD El software permita ser llevado a diferentes plataformas, de forma tal que su configuración en los diferentes entornos no genere cambios significativos en la aplicación.
38
11.6 UTILIDAD
Entendimiento básico en las solicitudes de medicamentos: el software será utilizado por personas con un entendimiento básico en el ingreso de solicitudes de medicamentos.
39
12. DEFINICIÓN DE ACTORES El sistema se enfocara principalmente en los siguientes actores: • Administrador. • Digitador. • Medico. • Consultor. • Impresora. 12.1 ACTORES Administrador: el administrador tiene todos los privilegios sobre el sistema, es decir, es el único que puede realizar operaciones de inserción, modificación o eliminación lógica sobre las actividades que realiza el software y la base de datos del sistema. Digitador: el digitador es el encargado de ingresar todas las solicitudes médicas, este podrá modificar las solicitudes antes de ser evaluadas por el médico. Médico: el médico es el encargado de estudiar las solicitudes médicas, es decir es el encargado de aprobar, negar y/o aplazar las solicitudes medicas con su respectiva descripción. Consultor: el consultor es el encargado de consultar que las solicitudes estén en correcto orden, éste también es el encargado de imprimir los formatos correspondientes. Impresora: la impresora es utilizada para la impresión de solicitudes y reportes generados por el sistema.
40
13. LISTADO DE CASOS DE USO A continuación se muestra el listado de casos de uso que maneja el sistema: Tabla 3. Lista de Casos de Uso
Casos de Uso Descripción CU CU_01 Ingresar al Sistema CU_02 Crear Usuario CU_03 Modificar Usuario CU_04 Consultar Usuario CU_05 Deshabilitar/Habilitar Usuario CU_06 Ingresar Solicitud CU_07 Modificar Solicitud CU_08 Consultar Solicitud CU_09 Estudio Medico CU_10 Evaluar Solicitud CU_11 Modificar Estudio Medico CU_12 Ingresar Medico Tratante CU_13 Ingresar IPS CU_14 Ingresar Paciente CU_15 Ingresar Medicamentos CU_16 Realizar Informe
(Ver Figura 1. Diagrama de Casos de uso en la página siguiente).
41
13.1 DIAGRAMA DE CASOS DE USO Figura 1. Diagrama de Casos de Uso
13.2 DESCRIPCIÓN DE CASOS DE USO 13.2.1 CU_01 Ingresar al Sistema Número: 001 Nombre de Caso de Uso: “Ingresar al Sistema” Actor(es): Administrador, Digitador, Médico, Consultor Descripción: Este caso de uso describe como el usuario ingresa al sistema
42
Tabla 4. CU_01 Ingresar al Sistema
FLUJO DE EVENTOS
CURSO NORMAL ALTERNATIVAS
1. El caso de uso inicia cuando el usuario administrador, digitador, médico o consultor selecciona el icono que activa la aplicación.
2. El sistema solicita al usuario ingresar los datos login y password.
3. El usuario ingresa login y password.
4. El usuario selecciona la opción Aceptar.
4.1. El usuario selecciona la opción Cancelar. 4.2. Flujo normal punto 10.
5. El sistema verifica la integridad de los datos. Verifica que los campos no estén vacíos.
5.1. Si el campo del login está vacío, el sistema muestra un mensaje indicando el error y le dice al usuario que lo vuelva a intentar. (Flujo normal 3). 5.2. Si el campo del password está vacío este muestra un mensaje indicando el error y le dice al usuario que lo vuelva a intentar. (Flujo normal 3).
6. El sistema verifica que los datos de login y password sean correctos.
6.1. Si el login no se encuentra registrado en el sistema o el password no coincide para el login registrado el sistema envía un mensaje indicando este hecho (Flujo normal 3).
7. El sistema guarda el registro del usuario ingresado
8. El sistema muestra un mensaje de Bienvenida al usuario.
9. El sistema muestra un menú con las opciones: Usuarios, Solicitudes, Informes.
10. Finaliza CU_01 Pre-Condiciones Debe haber usuarios registrados al sistema. Post-Condiciones Un usuario accede al sistema Puntos de Extensión N/A
43
13.2.2 CU_02 Crear Usuario Número: 002 Nombre de Caso de Uso: “Crear Usuario” Actor(es): Administrador Descripción: Este Caso de Uso permite al administrador del sistema ingresar la información (datos personales) asociadas a un usuario. Tabla 5. CU _ 02 Crear Usuario
FLUJO DE EVENTOS
CURSO NORMAL ALTERNATIVAS
1. El caso de uso inicia cuando el administrador selecciona la opción Ingresar Usuario, que se encuentra en la interfaz principal.
2. El sistema muestra una interfaz solicitando al administrador que ingrese los datos del Usuario.
Datos - Identificación - Nombre(es) - Apellido(s) - Dirección - Teléfono - Login - Password - E-mail
- Perfil de usuario
3. El administrador ingresa la información del usuario: identificación, nombre (es), apellido(s), dirección, teléfono, login, password, e-mail, y perfil de usuario
4. El administrador selecciona la opción Aceptar.
4.1. El Administrador Cancela la operación. 4.2. Flujo normal punto 8.
44
Continuación Tabla 5. CU_02 Crear Usuario
5. El sistema verifica la integridad de los datos. Verifica que los campos propios a la interfaz no estén vacíos, que el usuario no esté en la base de datos y que el número de identificación y teléfono sean positivos.
5.1. Si alguno de los campos se encuentra vacío, el sistema muestra un mensaje indicando el error y le dice al administrador que lo vuelva a intentar (Flujo normal punto 3).
5.2. Si el número de identificación del usuario ya está registrado en la base de datos, el sistema muestra un mensaje indicando el error y le dice al administrador que lo vuelva a intentar (Flujo normal punto 3).
5.3. Si el número de identificación es un número negativo, el sistema mostrará un mensaje indicando el error y le dice al administrador que lo vuelva a intentar. (Flujo normal punto 3).
6. Los datos son ingresados a la base de datos.
7. El sistema muestra un mensaje de confirmación al administrador que la operación ha sido exitosa.
8. Finaliza CU_02
Pre-Condiciones El usuario NO debe existir en la base de datos Post-Condiciones Los datos del usuario quedan almacenados en el sistema. Puntos de Extensión N/A
45
13.2.3 CU_03 Modificar Usuario Número: 003 Nombre de Caso de Uso: “Modificar Usuario” Actor(es): Administrador Descripción: Este Caso de Uso le permite al usuario modificar información (datos personales) asociada a un usuario inscrito en la base de datos. Tabla 6. CU_03 Modificar Usuario
FLUJO DE EVENTOS
CURSO NORMAL ALTERNATIVAS
1. El caso de uso inicia cuando el administrador selecciona la opción Modificar Usuario que se encuentra en la interfaz principal.
2. El sistema le solicita al administrador que ingrese el número de identificación del usuario.
3. El administrador ingresa el número de identificación del usuario.
4. El administrador selecciona la opción Aceptar
4.1. El administrador Cancela la operación
4.2. Flujo normal punto 12.
46
Continuación Tabla 6. CU_03 Modificar Usuario
5. El sistema valida la integridad de los datos. Verifica que la casilla no esté vacía, que el cliente este registrado en la base de datos y que el número de identificación sea positivo.
5.1. Si el campo de texto se encuentra vacío, el sistema muestra un mensaje indicando el error y le dice al administrador que lo vuelva a intentar. (Flujo normal punto 3)
5.2. Si el número de identificación es un número negativo, el sistema mostrará un mensaje indicando el error y le dice al administrador que lo vuelva a intentar. (Flujo normal punto 3)
5.3. Si el número de identificación no se encuentra en el sistema, el sistema mostrará un mensaje indicando que el usuario no existe (Flujo normal punto 3).
6. Se muestra en pantalla el formulario de los datos personales asociados al usuario a modificar. (La información del usuario se obtiene del caso de uso CU_02)
7. El administrador modifica la información asociada al usuario. El administrador solo podrá modificar: - Dirección - Teléfono - e-mail - Perfil de usuario
7.1. El Administrador no cambia los datos cancelando la operación de modificación.
7.2. Flujo normal punto 12
47
Continuación Tabla 6. CU_03 Modificar Usuario
8. El sistema valida la información modificada del usuario. Verifica que la casilla no esté vacía y que el número de identificación sea positivo.
8.1. Si el campo de texto se encuentra vacío, el sistema muestra un mensaje indicando el error y le dice al administrador que lo vuelva a intentar. (Flujo normal punto 7)
8.2. Si el número de identificación es un número negativo, el sistema mostrará un mensaje indicando el error y le dice al administrador que lo vuelva a intentar. (Flujo normal punto 7).
9. El administrador escoge la opción Aceptar.
9.1. El administrador escoge la opción Cancelar.
9.2. Flujo normal punto 12.
10. El sistema guarda los cambios en la base de datos.
11. El sistema muestra un mensaje indicando que los datos han sido modificados satisfactoriamente.
12. Finaliza el CU_03
Pre-Condiciones Debe existir un Usuario en la base de datos Post-Condiciones Las modificaciones realizadas a los datos del usuario deben quedar almacenadas en la base de datos Puntos de Extensión CU_02
48
13.2.4 CU_04 Consultar Usuario Número: 004 Nombre de Caso de Uso: “Consultar Usuario” Actor(es): Administrador Descripción: Este Caso de Uso le permite al administrador mirar la información (datos personales) de un usuario registrado en la base de datos. Tabla 7. CU_04 Consultar Usuario
FLUJO DE EVENTOS
CURSO NORMAL ALTERNATIVAS
1. El caso de uso inicia cuando el administrador seleccionan la opción Consultar Usuario que se encuentra en la interfaz principal.
2. El sistema pide el número de identificación del usuario.
3. El administrador ingresa el número de identificación del usuario.
4. El administrador selecciona la opción Aceptar.
4.1. El administrador Cancela la operación.
4.2. Flujo normal punto 7.
49
Continuación Tabla 7. CU_04 Consultar Usuario
5. El sistema verifica la integridad de los datos. Verifica que la casilla no esté vacía, que el número de identificación sea positivo y que el número de identificación se encuentre en la base de datos.
5.1. Si el campo de texto se encuentra vacío, el sistema muestra un mensaje indicando el error y le dice al administrador que lo vuelva a intentar. (Flujo normal 3).
5.2. Si el número de identificación es un número negativo, el sistema mostrará un mensaje indicando el error y le dice al administrador que lo vuelva a intentar. (Flujo normal punto 3).
5.3. Si el número de identificación ingresado no es válido este muestra un mensaje indicando el error. (Flujo normal punto 3).
6. El sistema muestra en pantalla la
información asociada al usuario (La información asociada al usuario se obtiene del CU_02)
7. Finaliza el CU_04
Pre-Condiciones Los datos del usuario deben estar almacenados en la base de datos Post-Condiciones N/A Puntos de Extensión CU_02
50
13.2.5 CU_05 Deshabilitar/Habilitar Usuario Número: 005 Nombre de Caso de Uso: “Deshabilitar/Habilitar Usua rio” Actor(es): Administrador. Descripción: Este Caso de Uso permite al administrador eliminar lógicamente a un usuario del sistema o habilitar usuarios que han sido deshabilitados por el administrador. Tabla 8. CU_05 Deshabilitar / Habilitar Usuario
FLUJO DE EVENTOS
CURSO NORMAL ALTERNATIVAS
1. El Caso de Uso inicia cuando el administrador selecciona la opción Deshabilitar/Habilitar Usuario que se encuentra en la interfaz principal
2. El sistema muestra en pantalla si desea deshabilitar/Habilitar Usuarios.
3. El administrador selecciona la opción Aceptar
3.1. El administrador Cancela la operación.
3.2. Flujo normal punto 8.
51
Pre-Condiciones Los datos del usuario deben estar almacenados en la base de datos Post-Condiciones Los datos del usuario deshabilitado no estarán disponibles nuevamente hasta que el administrador lo decida Los datos del usuario habilitado estarán disponibles nuevamente. Puntos de Extensión N/A
Continuación Tabla 8. CU_05 Deshabilitar / Habilitar Usuario
4. El sistema muestra los usuarios que se encuentran actualmente habilitados y deshabilitados
5. El administrador selecciona el usuario a cambiar de estado de la lista. Habilitado - Deshabilitado y Deshabilitado - Habilitado.
5.1. El administrador cancela la operación
5.2. Flujo normal punto 8
6. El administrador selecciona la opción Aceptar.
6.1. El administrador selecciona la opción cancelar.
6.2. Flujo normal punto 8
7. El Sistema deshabilita o habilita los clientes mostrados en pantalla.
8. Finaliza CU_05
52
13.2.6 CU_06 Ingresar Solicitud Número: 006 Nombre de Caso de Uso: “Ingresar Solicitud” Actor(es): Digitador Descripción: El Caso de Uso permite al usuario ingresar una nueva solicitud de medicamento al sistema Tabla 9. CU_06 Ingresar Solicitud
FLUJO DE EVENTOS
CURSO NORMAL ALTERNATIVAS
1. El caso de uso inicia cuando el administrador o el digitador selecciona la opción Ingresar Solicitud que se encuentra en la interfaz principal.
2. El sistema pide al usuario generar acta
3. El usuario selecciona la opción Aceptar
3.1. El usuario Cancela la operación (flujo normal punto 4, sigue con la secuencia anterior de actas)
4. El sistema muestra al usuario el
formato para el ingreso de solicitud.
53
Continuación Tabla 9. CU_06 Ingresar Solicitud
5. El Usuario digita los datos relacionados al formato de solicitud.
Datos: o Anexo No.1
5.1. Si el Médico tratante no se encuentra en el sistema, el usuario tiene la opción de Ingresar Médico Tratante (CU_12).
5.2. Si la IPS no se encuentra en el sistema, el usuario tiene la opción de Ingresar IPS (CU_13).
5.3. Si el Paciente no se encuentra en el sistema, el usuario tiene la opción de Ingresar Paciente (CU_14).
5.4. Si el Medicamento no se encuentra en el sistema, el usuario tiene la opción de Ingresar Medicamento (CU_15).
6. El usuario selecciona la opción Aceptar
6.1. El usuario Cancela la operación 6.2. Flujo normal punto 8.
7. El sistema valida la integridad de los datos. Verifica que las casillas no estén vacías, que el número de identificación del paciente sea un número positivo, que el número de teléfono sea un número positivo, que el formato de la fecha sea válido y que el formato de comprobación de derechos sea positivo.
7.1. Si el campo de texto se encuentra vacío, el sistema muestra un mensaje indicando el error y le dice al usuario que lo vuelva a intentar. (Flujo normal punto 3).
7.2. Si el número de identificación del usuario es un número invalido, el sistema muestra un mensaje indicando el error y le dice que lo vuelva a intentar. (Flujo normal punto 3).
7.3. Si el formato de la fecha es invalido, el sistema muestra un mensaje indicando el error y le dice al usuario que lo vuelva a intentar. (Flujo normal punto 3).
7.4. Si el teléfono es un número negativo, el sistema muestra un mensaje indicando el error y le dice al administrador que lo vuelva a intentar. (Flujo normal punto 3).
7.5. Si el número de comprobación es un número negativo, el sistema muestra un mensaje indicando el error y le dice al usuario que lo vuelva a intentar. (Flujo normal punto 3).
54
Continuación Tabla 9. CU_06 Ingresar Solicitud
8. El sistema guarda los datos de la solicitud en la base de datos.
9. El sistema muestra un mensaje de confirmación al usuario que la operación ha sido exitosa.
10. Finaliza el CU_06
Pre-Condiciones La solicitud NO debe existir en la base de datos Post-Condiciones El usuario ha ingresado una solicitud Puntos de Extensión CU_12, CU_13, CU_14, CU_15 13.2.7 CU_07 Modificar Solicitud Número: 007 Nombre de Caso de Uso: “Modificar Solicitud” Actor(es): Digitador Descripción: El Caso de Uso permite al usuario modificar una solicitud de medicamento que se encuentra en el sistema. La solicitud sólo puede ser modificada antes que el médico haga el estudio médico referente a la solicitud. (Ver Tabla 10. CU_07 Modificar Solicitud página siguiente).
55
Tabla 10. CU_07 Modificar Solicitud
FLUJO DE EVENTOS
CURSO NORMAL ALTERNATIVAS
1. El caso de uso inicia cuando el administrador o el digitador selecciona la opción Modificar Solicitud que se encuentra en la interfaz principal.
2. El sistema pide al usuario: Nombre del Paciente y Número de Identificación del paciente.
3. El usuario ingresa el nombre completo del paciente y Numero de Identificación del paciente.
4. El usuario selecciona la opción Aceptar
4.1. El usuario Cancela la operación 4.2. Flujo normal punto 13
5. El sistema valida la integridad de los datos. Verifica que la casilla no esté vacía y que el número de identificación sea un número positivo.
5.1. Si el campo de texto se encuentra vacío el sistema muestra un mensaje indicando el error y le pide al usuario que lo vuelva a intentar. (Flujo normal punto 3).
5.2. Si el número de identificación es un número negativo, el sistema muestra un mensaje indicando el error y le dice al usuario que lo vuelva a intentar. (Flujo normal punto 3).
56
Continuación Tabla 10. CU_07 Modificar Solicitud
6. El sistema verifica que el Nombre del paciente y el Número de Identificación sean correctos.
6.1. Si el nombre del paciente no se encuentra registrado en el sistema o el número de identificación no coincide para el número de identificación registrado en el sistema envía un mensaje indicando el error. (Flujo normal 3).
7. El sistema muestra la información
asociada al formato de solicitud. (Los datos se obtienen del caso de uso CU_06).
8. El usuario modifica los datos correspondientes a la solicitud.
8.1. El usuario Cancela la operación 8.2. Flujo normal punto 13
9. El usuario selecciona la opción Aceptar.
9.1. El usuario no cambia los datos de la solicitud Cancelando la operación
9.2. Flujo normal punto 13
10. El sistema valida la integridad de los datos. Verifica que las casillas no estén vacías, que el número de identificación del paciente y del cotizante sea un número positivo, que el número de teléfono sea un número positivo y que el formato de la fecha sea válido.
10.1. Si el campo de texto se encuentra vacío, el sistema muestra un mensaje indicando el error y le dice al administrador que lo vuelva a intentar. (Flujo normal punto 8).
10.2. Si el número de identificación del usuario o cotizante es un numero invalido, el sistema muestra un mensaje indicando el error y le dice que lo vuelva a intentar. (Flujo normal punto 8).
10.3. Si el formato de la fecha es invalido, el sistema muestra un mensaje indicando el error y le dice al administrador que lo vuelva a intentar. (Flujo normal punto 8).
10.4. Si el teléfono es un número negativo, el sistema muestra un mensaje indicando el error y le dice al administrador que lo vuelva a intentar. (Flujo normal punto 8).
57
Continuación Tabla 10. CU_07 Modificar Solicitud
11. El sistema guarda los cambios de la solicitud en la base de datos.
12. El sistema muestra un mensaje de confirmación al usuario que la operación ha sido exitosa.
13. Finaliza el CU_07
Pre-Condiciones La solicitud debe existir en la base de datos Post-Condiciones El usuario ha modificado una solicitud Puntos de Extensión CU_06 13.2.8 CU_08 Consultar Solicitud Número: 008 Nombre de Caso de Uso: “Consultar Solicitud” Actor(es): Administrador, Digitador, Médico, Consultor e Impresora. Descripción: El Caso de Uso permite al usuario consultar una solicitud de medicamento que se encuentra en el sistema. (Ver Tabla 11. CU_08 Consultar Solicitud página siguiente).
58
Tabla 11. CU_08 Consultar Solicitud
FLUJO DE EVENTOS
CURSO NORMAL ALTERNATIVAS
1. El caso de uso inicia cuando el administrador, digitador, médico o consultor seleccionan la opción Consultar Solicitud que se encuentra en la interfaz principal.
2. El sistema pide el Número de Identificación del paciente o el Nombre completo del paciente al cual se desea consultar la solicitud.
3. El usuario ingresa el Número de identificación del paciente o Nombre completo del paciente.
4. El usuario selecciona la opción Aceptar.
4.1. El usuario Cancela la operación. 4.2. Flujo normal punto 9
5. l sistema verifica la integridad de los datos. Verifica que la casilla no esté vacía o que el número de identificación sea positivo.
5.1. Si los campos de texto se encuentran vacíos, el sistema muestra un mensaje indicando el error y le dice al usuario que lo vuelva a intentar. (Flujo normal 3).
5.2. Si el número de identificación es un número negativo, el sistema mostrará un mensaje indicando el error y le dice al administrador que lo vuelva a intentar. (Flujo normal punto 3).
59
Continuación Tabla 11. CU_07 Consultar Solicitud
6. El sistema verifica que el Nombre del paciente o el Número de Identificación sean correctos.
6.1. Si el nombre del paciente no se encuentra registrado en el sistema o el número de identificación no coincide para el número de identificación registrado en el sistema envía un mensaje indicando el error. (Flujo normal 3).
7. El sistema muestra en pantalla la información asociada al paciente.
8. El usuario tiene la opción de imprimir la solicitud.
8.1. Si la solicitud es aprobada el sistema muestra la carta y el acta correspondiente a la aprobación de la solicitud
8.2. Si la solicitud es negada, el sistema muestra el acta correspondiente a la negación de la solicitud.
8.3. Si la solicitud es aplazada, el sistema muestra el acta correspondiente al aplazo de la solicitud
9. Finaliza el CU_08 Pre-Condiciones La solicitud debe existir en la base de datos Post-Condiciones El usuario consulta una solicitud Puntos de Extensión N/A
60
13.2.9 CU_09 Estudio Médico Número: 009 Nombre de Caso de Uso: “Estudio Medico” Actor(es): Médico. Descripción: El Caso de Uso permite al usuario realizar usuario la aprobación, aplazo y/o negación de la solicitud de medicamento. Tabla 12. CU_09 Estudio Médico
FLUJO DE EVENTOS
CURSO NORMAL ALTERNATIVAS
1. El caso de uso inicia cuando el Médico seleccionan la opción Estudio Medico que se encuentra en la interfaz principal.
2. El sistema pide el Número de Identificación o Nombre completo del paciente al cual se le va a evaluar la solicitud
3. El Médico Ingresa el Número de Identificación del paciente o Nombre completo del paciente al cual se le va a evaluar la solicitud
4. El Médico selecciona la opción Aceptar
4.1. El Médico Cancela la operación
4.2. Flujo normal punto 12
61
Continuación Tabla 12. CU_09 Estudio Médico
5. El sistema valida la integridad de los datos, verifica que los campos no estén vacíos y que el número de identificación sea un número positivo.
5.1. Si los campos de texto se encuentran vacíos, el sistema muestra un mensaje indicando el error y le dice al usuario que lo vuelva a intentar. (Flujo normal 3).
5.2. Si el número de identificación es un número negativo, el sistema muestra un mensaje indicando el error y le dice al usuario que lo vuelva a intentar. (Flujo normal 3).
6. El sistema verifica que el Nombre del paciente o el Número de Identificación sean correctos.
6.1. Si el nombre del paciente no se encuentra registrado en el sistema o el número de identificación no coincide para el número de identificación registrado en el sistema envía un mensaje indicando el error. (Flujo normal 3).
7. El sistema muestra los datos de
la solicitud. (Los datos se obtienen del caso de uso CU_06)
8. El Médico selecciona la opción Evaluar Solicitud. Se ejecuta caso de uso CU_10.
8.1. El Médico Cancela la operación
8.2. Flujo normal punto 13.
9. El sistema asocia la información de la solicitud con la evaluación medica
10. El Médico selecciona la opción Aceptar
10.1. El Médico Cancela la operación
10.2. Flujo normal punto 13
62
Continuación Tabla 12. CU_09 Estudio Médico
11. El sistema guarda los datos en la base de datos.
12. El sistema muestra un mensaje de confirmación al Medico que la operación ha sido exitosa.
13. Finaliza el CU_09
Pre-Condiciones La solicitud debe existir en la base de datos Post-Condiciones El usuario evalúa una solicitud Puntos de Extensión CU_06 y CU_10 13.2.10 CU_10 Evaluar Solicitud Número: 010 Nombre de Caso de Uso: “Evaluar Solicitud” Actor(es): Médico. Descripción: El Caso de Uso permite al usuario realizar la aprobación, aplazo y/o negación de la solicitud de medicamento. (Ver Tabla 13. CU_10 Evaluar Solicitud página siguiente)
63
Tabla 13. CU_10 Evaluar Solicitud
FLUJO DE EVENTOS
CURSO NORMAL ALTERNATIVAS
1. El caso de uso inicia cuando el Médico seleccionan la opción Evaluar Solicitud que se encuentra en la interfaz de Estudio Medico.
2. El sistema muestra en pantalla la interfaz con los datos a ingresar • Evalúo de Solicitud
o Solicitud Aprobada o Solicitud Negada o Solicitud Aplazada
• Descripción • Justificación • Criterios de autorización
3. El Médico ingresa los datos correspondientes a la interfaz. • Evaluó de Solicitud
o Solicitud Aprobada o Solicitud Negada o Solicitud Aplazada
• Descripción • Justificación • Criterios de autorización
3.1. Si el Médico selecciona la opción Solicitud Aprobada, el sistema habilitara los campos asociada a Solicitud Aprobada: Tiempo Autorizado, Cantidad Autorizada, Dosis Autorizada. (Flujo normal punto 3)
3.2. Si el Médico selecciona la opción Solicitud Negada, el sistema habilitara los campos asociados a Solicitud Negada: Causa Negación. (Flujo normal punto 3).
3.3. Si el Médico selecciona la opción Solicitud Aplazada, el sistema habilitara los campos asociados a Solicitud Aplazada: Motivo Aplazo. (Flujo normal punto 3).
3.4. Si el Médico no realiza la evaluación médica cancelando la operación. (Flujo normal punto 10.
64
Continuación Tabla 13. CU_10 Evaluar Solicitud
4. El Médico selecciona la opción Aceptar
4.1. El Médico Cancela la operación 4.2. Flujo normal punto 10
5. El sistema valida la integridad de los datos, verifica que los campos no estén vacíos
5.1. Si el campo de texto se encuentra vacío, el sistema muestra un mensaje indicando el error y le dice al Médico que lo vuelva a intentar. (Flujo normal 3).
6. El sistema asocia la información de la solicitud con la evaluación médica.
7. El Médico selecciona la opción Aceptar 7.1. El Médico Cancela la operación 7.2. Flujo normal punto 10
8. El sistema guarda los datos en la base de datos.
9. El sistema muestra un mensaje de confirmación al Medico que la operación ha sido exitosa.
10. Finaliza el CU_10 Pre-Condiciones La solicitud debe existir en la base de datos Post-Condiciones El usuario evalúa una solicitud Puntos de Extensión N/A
65
13.2.11 CU_11 Modificar Estudio Medico Número: 011 Nombre de Caso de Uso: “Modificar Estudio Medico” Actor(es): Médico. Descripción: El Caso de Uso permite al usuario modificar la aprobación, aplazo y/o negación de la solicitud de medicamento Tabla 14. CU_11 Modificar Estudio Medico
FLUJO DE EVENTOS
CURSO NORMAL ALTERNATIVAS
1. El caso de uso inicia cuando el Médico seleccionan la opción Modificar Estudio Medico que se encuentra en la interfaz principal.
2. El sistema pide el Número de Identificación o Nombre completo del paciente al cual se le va a Modificar la solicitud
3. El usuario ingresa el Número de Identificación o Nombre completo del paciente al cual se le va a Modificar la solicitud.
4. El usuario selecciona la opción Aceptar
4.1. El usuario Cancela la operación
4.2. Flujo normal punto 14
66
Continuación Tabla 14. CU_11 Modificar Estudio Medico
5. El sistema valida la integridad de los datos, verifica que los campos no estén vacíos y que el número de identificación sea un número positivo y que el número de identificación se encuentre en la base de datos.
5.1. Si los campos de texto se encuentran vacíos, el sistema muestra un mensaje indicando el error y le dice al médico que lo vuelva a intentar. (Flujo normal 3).
5.2. Si el número de identificación es un número negativo, el sistema muestra un mensaje indicando el error y le dice al administrador que lo vuelva a intentar. (Flujo normal 3).
6. El sistema verifica que el Nombre del paciente o el Número de Identificación sean correctos.
6.1. Si el nombre del paciente no se encuentra registrado en el sistema o el número de identificación no coincide para el número de identificación registrado en el sistema envía un mensaje indicando el error. (Flujo normal 3).
7. El sistema muestra los datos de la solicitud. (Los datos se obtienen del caso de uso CU_06)
8. El Médico modifica los campos de la solicitud. Sólo podrá modificar los siguientes campos:
• Entidad patológica o Diagnostico o Código CIE o Resumen de la Historia Clínica
• Descripción del Medicamento o Tipo de Medicamento (POS, No POS) o Nombre genérico o Concentración y forma farmacéutica o Dosis o Cantidad o Duración del tratamiento (en días) o Homologo en el POS (nombre
genérico) o Indicación Terapéutica o Tipo de solicitud (Primera vez,
renovación o Fallo de Tutela).
67
Continuación Tabla 14. CU_11 Modificar Estudio Medico
9. El Médico selecciona la opción Evaluar Solicitud. Se ejecuta caso de uso CU_10.
9.1. El Médico Cancela la operación
9.2. Flujo normal punto 14.
10. El sistema asocia la información de la solicitud con la evaluación medica
11. El Médico selecciona la opción Aceptar.
11.1. El Médico Cancela la operación
11.2. Flujo normal punto 14.
12. El sistema valida la integridad de los datos, verifica que los campos no estén vacíos
12.1. Si los campos de texto se encuentran vacíos, el sistema muestra un mensaje indicando el error y le dice al médico que lo vuelva a intentar. (Flujo normal 8).
13. El sistema guarda los cambios en la base de datos.
14. El sistema muestra un mensaje de confirmación al Medico que la operación ha sido exitosa.
15. Finaliza el CU_11
Pre-Condiciones La solicitud debe existir en la base de datos Post-Condiciones El usuario modifica una solicitud Puntos de Extensión CU_06, CU_10
68
13.2.12 CU_12 Ingresar Medico Tratante Número: 012 Nombre de Caso de Uso: “Ingresar Medico Tratante” Actor(es): Digitador. Descripción: El Caso de Uso permite al usuario un Médico Tratante que no se encuentre en el sistema. Tabla 15. CU_12 Ingresar Médico Tratante
FLUJO DE EVENTOS
CURSO NORMAL ALTERNATIVAS
1. El caso de uso inicia cuando el
digitador selecciona la opción Ingresar Medico Tratante, que se encuentra en la interfaz Ingresar Solicitud.
2. El sistema muestra una interfaz
solicitando al usuario que ingrese los datos del Médico Tratante.
Datos - Nombre(es) y Apellido (s) del
Médico Tratante - Especialidad
3. El usuario ingresa la información del usuario: Nombre(es) y Apellido (s) del Médico Tratante y Especialidad
69
Continuación Tabla 15. CU_12 Ingresar Medico Tratante
4. El usuario selecciona la opción Aceptar.
4.1. El usuario Cancela la operación. 4.2. Flujo normal punto 8
5. El sistema verifica la integridad de los datos. Verifica que los campos propios a la interfaz no estén vacíos.
5.1. Si alguno de los campos se
encuentra vacío, el sistema muestra un mensaje indicando el error y le dice al administrador que lo vuelva a intentar (Flujo normal punto 3).
6. Los datos son ingresados a la base
de datos.
7. El sistema muestra un mensaje de
confirmación al usuario que la operación ha sido exitosa.
8. Finaliza CU_12
Pre-Condiciones El Médico Tratante NO debe existir en la base de datos Post-Condiciones El usuario ingresa un medico tratante Puntos de Extensión N/A
70
13.2.13 CU_13 Ingresar IPS Número: 013 Nombre de Caso de Uso: “Ingresar IPS” Actor(es): Digitador. Descripción: El Caso de Uso permite al usuario Ingresar una IPS que no se encuentre en el sistema. Tabla 16. CU_13 Ingresar IPS
FLUJO DE EVENTOS
CURSO NORMAL ALTERNATIVAS
1. El caso de uso inicia cuando el administrador selecciona la opción Ingresar IPS, que se encuentra en la interfaz Ingresar Solicitud.
2. El sistema muestra una interfaz solicitando al usuario que ingrese los datos de la IPS
Datos - Nombre de la unidad
Asistencial - Empresa Social del Estado - Ciudad o Municipio
3. El usuario ingresa la información de la IPS: Nombre de la unidad Asistencial, Empresa Social del Estado y Ciudad o Municipio
71
Continuación Tabla 16. CU_13 Ingresar IPS
4. El usuario selecciona la opción Aceptar.
4.1. El usuario Cancela la operación. 4.2. Flujo normal punto 8.
5. El sistema verifica la integridad de los datos. Verifica que los campos propios a la interfaz no estén vacíos.
5.1. Si alguno de los campos se encuentra vacío, el sistema muestra un mensaje indicando el error y le dice al administrador que lo vuelva a intentar (Flujo normal punto 3).
6. Los datos son ingresados a la base de datos.
7. El sistema muestra un mensaje de confirmación al usuario que la operación ha sido exitosa.
8. Finaliza CU_13
Pre-Condiciones La IPS NO debe existir en la base de datos Post-Condiciones El usuario ingresa una IPS Puntos de Extensión N/A
72
13.2.14 CU_14 Ingresar Paciente Número: 014 Nombre de Caso de Uso: “Ingresar Paciente” Actor(es): Digitador. Descripción: El Caso de Uso permite al usuario ingresar un Paciente que no se encuentre en el sistema. Tabla 17. CU_14 Ingresar Paciente
FLUJO DE EVENTOS
CURSO NORMAL ALTERNATIVAS
1. El caso de uso inicia cuando el usuario selecciona la opción Ingresar Paciente, que se encuentra en la interfaz Ingresar Solicitud.
2. El sistema muestra una interfaz solicitando al usuario que ingrese los datos del Paciente.
Datos - Tipo de Identificación - Identificación - Nombre(es) - Apellido(s) - Edad - Tipo de Vinculación - Dirección - Teléfono - Nombre del Cotizante - Apellido del Cotizante - Tipo de identificación del Cotizante - Número de identificación del
Cotizante
73
Continuación Tabla 17. CU_ Ingresar Paciente
3. El usuario ingresa la información del usuario: Tipo de Identificación, Identificación, Nombre(es), Apellido(s), Edad, Tipo de Vinculación, Dirección, Teléfono, Nombre del Cotizante, Tipo de identificación del Cotizante y Numero de identificación del Cotizante
4. El usuario selecciona la opción Aceptar.
4.1. El usuario Cancela la operación. 4.2. Flujo normal punto 8.
5. El sistema verifica la integridad de los datos. Verifica que las campos propios a la interfaz no estén vacíos, que el usuario no esté en la base de datos y que el número de identificación del paciente y cotizante sean positivos y teléfono sean positivos.
5.1. Si alguno de los campos se encuentra vacío, el sistema muestra un mensaje indicando el error y le dice al usuario que lo vuelva a intentar (Flujo normal punto 3).
5.2. Si el número de identificación del usuario ya está registrado en la base de datos, el sistema muestra un mensaje indicando el error y le dice al usuario que lo vuelva a intentar (Flujo normal punto 3).
5.3. Si el número de identificación es un número negativo, el sistema mostrará un mensaje indicando el error y le dice al usuario que lo vuelva a intentar. (Flujo normal punto 3).
6. Los datos son ingresados a la base de
datos.
7. El sistema muestra un mensaje de confirmación al administrador que la operación ha sido exitosa.
8. Finaliza CU_14
Pre-Condiciones El Paciente NO debe figurar en la base de datos Post-Condiciones El usuario ingresa un paciente Puntos de Extensión N/A
74
13.2.15 CU_15 Ingresar Medicamento Número: 015 Nombre de Caso de Uso: “Ingresar Medicamento” Actor(es): Digitador. Descripción: El Caso de Uso permite al usuario ingresar un Medicamento e en el caso que el paciente que no se encuentre en el sistema. Tabla 18. CU_15 Ingresar Medicamentos
FLUJO DE EVENTOS
CURSO NORMAL ALTERNATIVAS
1. El caso de uso inicia cuando el usuario
selecciona la opción Ingresar Medicamento, que se encuentra en la interfaz Ingresar Solicitud.
2. El sistema muestra una interfaz
solicitando al usuario que ingrese los datos del Medicamento.
Datos - Tipo de Medicamento (POS
Prescrito, POS, No POS) - Nombre del medicamento - Concentración y Forma
Farmacéutica
75
3. El usuario ingresa la información del
medicamento: Tipo de Medicamento (POS Prescrito, POS, No POS), Nombre del medicamento, Concentración y Forma Farmacéutica
Continuación Tabla 18. CU_15 Ingresar Medicamento
4. El usuario selecciona la opción Aceptar.
4.1. El usuario Cancela la operación. 4.2. Flujo normal punto 8
5. El sistema verifica la integridad de los datos. Verifica que los campos propios a la interfaz no estén vacíos.
5.1. Si alguno de los campos se
encuentra vacío, el sistema muestra un mensaje indicando el error y le dice al usuario que lo vuelva a intentar (Flujo normal punto 3).
6. Los datos son ingresados a la base de datos.
7. El sistema muestra un mensaje de confirmación al administrador que la operación ha sido exitosa.
8. Finaliza CU_15
Pre-Condiciones El Paciente NO debe existir en la base de datos Post-Condiciones El usuario ingresa un medicamento Puntos de Extensión N/A
76
13.2.16 CU_16 Realizar Informe Número: 016 Nombre de Caso de Uso: “Realizar Informe” Actor(es): Administrador, Digitador, Medico e Impresora Descripción: El Caso de Uso permite al usuario generar un informe para la oficina de recobros e informe para respuesta de solicitud de medicamento. Tabla 19. CU_16 Realizar Informe
FLUJO DE EVENTOS
CURSO NORMAL ALTERNATIVAS
1. El caso de uso inicia cuando el usuario selecciona la opción Generar Informe que se encuentra en la interfaz principal
2. El sistema pide el tipo de informe que desea realizar: • Informe para Recobros • Informe para Respuesta Solicitud
Medicamento
3. El sistema pide al usuario elegir el rango de fecha que desea realizar el informe: Día, Mes y Año
77
Continuación Tabla 19. CU_16 Realizar Informe
4. El usuario selecciona los datos solicitados
5. El usuario selecciona la opción Aceptar.
5.1. El usuario selecciona la opción Cancelar.
5.2. Flujo normal punto 9
6. El sistema verifica la integridad de los datos. Verifica que los campos no estén vacíos.
6.1. Si el campo está vacío, el sistema muestra un mensaje indicando el error y le dice al usuario que lo vuelva a intentar. (Flujo normal 3).
7. El sistema busca en la base de datos
las solicitudes de medicamentos ingresadas al sistema.
8. El sistema muestra en pantalla el listado de las solicitudes
9. El usuario tiene la opción de imprimir el reporte
10. Finaliza CU_16
Pre-Condiciones Deben existir datos almacenados de solicitudes diarias Post-Condiciones N/A Puntos de Extensión N/A
78
14. MATRIZ CASOS DE USO – REQUISITOS A continuación la tabla No. 20 presenta la matriz de requisitos con sus respectivos casos de uso. Tabla 20. Matriz de Requisitos CU_01 CU_02 CU_03 CU_04 CU_05 CU_06 CU_07 CU_08 CU_09 CU_10 CU_11 CU_12 CU_13 CU_14 CU_15 CU_16
RF1 x x RF2 x RF3 x RF4 x RF5 x RF6 x RF7 x RF8 x RF9 x RF10 x RF11 x RF12 x RF13 x RF14 x RF15 x RF16 x RF17 x RF18 x RF19 x RF20 x
79
RF21 x RF22 x RF23 x RF24 x RF25 x RF26 x RF27 x RF28 x RF29 x
80
15. INTERFACES En la figura No. 2 se muestra el esquema de la interfaz del sistema: Figura 2. Interfaz del Sistema
Login: Administrador/Medico/ Digitador/Consultor Password: *****
Ventana Principal
Generar
Informes
Deshabilitar/Habilitar
Modificar
Consultar
Crear
Usuario
Estudio Medico
Modificar Solicitud
Consultar Solicitud
Ingresar IPS Ingresar Medicamento
Ingresar Medico Tratante
Ingresar Paciente
Ingresar Solicitud
Solicitudes
81
16. MODELO DE ARQUITECTURA DE CASO DE USO
16.1 CASOS DE USO SIGNIFICATIVOS En la figura 3 se representan los cosos de uso más significativos que maneja el sistema para el Comité Técnico Científico: Figura 3. Modelo de la Arquitectura
16.2 DESCRIPCIÓN TEXTUAL Después de realizar una reunión del grupo de trabajo en la cual se plantearon las primeras aproximaciones acerca de cuáles serian las funcionalidades primordiales con las cuales el sistema debía ser soportado, se tomo la decisión de centrar la arquitectura del sistema en cuatro casos de uso de interés colectivo para llevar a buen término la ejecución del proyecto.
82
A continuación se proporcionará una breve explicación del porque de esta determinación. CU_06 Ingresar Solicitud Mediante esta operación el caso de uso permitirá al usuario ingresar solicitudes la cual es de vital importancia debido a que si no se cuenta con un modulo para ingresar solicitudes no se tendría control alguno sobre los mismos para operaciones tan importantes para el Comité Técnico Científico como son el de Estudio Medico y Evaluar Solicitud. Este caso de uso ingresará la información perteneciente a la solicitud de medicamento. CU_08 Consultar Solicitud Este caso de uso permitirá al usuario hacer consultas de solicitudes medicamentos ya sean aprobadas, negadas y/o aplazadas por el Comité Técnico Científico, mediante esta operación el caso de uso es de mayor importancia debido a que este modulo permite el control para operaciones importantes para el Comité Técnico Científico como son el de Realizar Informe Recobro y Realizar Informe Respuesta Solicitud Medicamento. CU_09 Estudio Medico Mediante este caso de uso permitirá al usuario realizar el Estudio Medico Correspondiente a la solicitud de medicamento, esta operación es de vital importancia debido a que si no se cuenta con un modulo para realizar el Estudio Medico no se podría tener un mayor control sobre las solicitudes ingresadas al sistema y no se tendría control sobre operaciones importantes para el Comité Técnico Científico como son el de Evaluar Solicitud y Modificar Estudio Medico. CU_10 Evaluar Solicitud Tanto para el Comité Técnico Científico como para el sistema es muy importante contar con el modulo de Evaluar Solicitud debido a que mediante este modulo se realiza la aprobación, negación y/o aplazo de las solicitudes medicas ingresadas al sistema, este caso de uso permite el control de operaciones para el Comité Técnico Científico tales como el realizar informes.
83
17. MODELO DE ANÁLISIS DEL SISTEMA 17.1 REALIZACIÓN DE CASOS DE USO Una Realización de caso de uso – análisis es una colaboración dentro del Modelo de Análisis que describe cómo se lleva a cabo y se ejecuta un caso de uso determinado en términos de las clases de análisis. Por lo tanto hay una realización de caso de uso – análisis para cada caso de uso expresado en el Software Requirement Specification (SRS). Para cada caso de uso se desarrolla la realización de Caso de Uso-Análisis con el formato que se presenta a continuación: 17.1.1 CU_01 Ingresar al Sistema � Número: 001 � Nombre de Caso de Uso-Análisis: “Ingresar al Sistema” � Diagrama de Clase Figura 4. Diagrama de Clase CU_01
84
� Diagrama de Secuencia Figura 5. Diagrama de Secuencia CU_01
Descripción: El usuario inicia el caso de uso cuando da clic del evento Ingresar al Sistema, el cual solicitara los datos correspondientes al ingreso de la aplicación: login y Password, para el ingreso al sistema se hace una validación de los datos ingresados, si los datos son ingresados erróneamente el sistema enviará un mensaje de error haciendo la notificación de que ha ocurrido un error ingresando los datos, la interfaz se comunica con el control Usuario enviándole los datos para que realice la respectiva consulta, el control Usuario se comunica con el Ente Usuario haciendo el llamado a consultar para que se haga la respectiva consulta del Login y el Password, el ente Usuario valida la existencia del usuario enviando luego al control Usuario los datos correspondientes y se activa la interfaz Principal.
85
17.1.2 CU_02 Crear Usuario
� Número: 002 � Nombre de Caso de Uso-Análisis: “Crear Usuario” � Diagrama de Clase Figura 6. Diagrama de Clase CU_02
� Diagrama de Secuencia (Ver Figura 7 Diagrama de Secuencia CU_02 página siguiente).
86
Figura 7. Diagrama de Secuencia CU_02
Descripción: Este caso de uso permite al administrador y al encargado del sistema ingresar un nuevo usuario. El administrador inicia el caso de uso cuando selecciona la opción Crear Usuario que se encuentra en la interfaz Principal, al seleccionar se mostrará en pantalla un formulario en el cual se ingresaron los datos del nuevo usuario: cedula, nombre(s), apellido(s), dirección, teléfono, login, password y e-mail, para la creación del usuario se hace una validación de los datos ingresados, si los datos son ingresados erróneamente el sistema enviará un mensaje de error haciendo la notificación de que ha ocurrido un error ingresando los datos, la interfaz se comunica con el control Usuario enviándole los datos para que realice la respectiva consulta, este control activa el ente Usuario haciendo el llamado a consultar para que se haga la respectiva consulta de los datos ingresados, el ente valida la existencia del usuario, si el usuario ya existe en el sistema el sistema mostrará un mensaje indicando que el usuario ya existe, si no el control envía los datos correspondientes al ente y los datos son guardados, luego el sistema muestra un mansaje en pantalla de confirmación que el usuario ha sido creado.
87
17.1.3 CU_03 Modificar Usuario
� Número: 003 � Nombre de Caso de Uso-Análisis: “Modificar Usuario” � Diagrama de Clase Figura 8. Diagrama de Clase CU_03
88
� Diagrama de Secuencia Figura 9. Diagrama de Secuencia CU_03
:a Actor :UI Ingresar _ID :C Usuario
Selecciona opcion
ingresa id_usuario(id)
Aceptar()
x=valida_vacios()
x=false error
y=valida_negativos()
y=false error
y=true Activa
Activa
consultar(datos)
z=consultar()
Activa
Muestra Interfaz
:E Usuario :Ui Modificar
z=false
z=true datos()
muestra interfaz datos()
datos:
Cedula
Nombre
Apellido
Direccion
Telefono
Login
Password
modificar datos(direccion,telefono,email)
aceptar()
x=valida_vacios()
:UI Principal
z=false
z=false y=valida_negativos()
y=true
insertar()
msg "Usuario Modificado"
activa()
pasa datos()
msg "usuario no existe"
Descripción: El caso de uso inicia cuando el administrador selecciona la opción Modificar Usuario que se encuentra en la interfaz Principal, después de seleccionar la opción se muestra la interfaz Ingresar Id el cual el administrador digita el id del usuario a modificar, para realizar la modificación del usuario se hace una validación del dato ingresado, si el dato está mal ingresado el sistema muestra nuevamente la interfaz ingresar id hasta que el administrador ingrese correctamente el dato, si el id es digitado educadamente la interfaz se comunica con el control Usuario enviándole el dato correspondiente para que realice la consulta, el control se comunica con el ente Usuario haciendo el llamado a consultar para realizar la respectiva consulta del id ingresado, el ente consulta el id del usuario, si el id del usuario no se encuentra en la base de datos el sistema mostrará un mensaje indicando el error, si el usuario se encuentra registrado el control envía los datos correspondientes y muestra la interfaz Modificar Usuario
89
con los datos del usuario registrado, el administrador sólo podrá modificar los siguientes datos: dirección, teléfono y e-mail, el sistema realiza las respectivas validaciones de los datos modificados, si estos se encuentran erróneamente el sistema mostrará un mensaje de error haciendo la notificación de que ha ocurrido un error ingresando los datos, si los datos son digitados correctamente el control envía los datos al ente y estos son guardados, luego el sistema muestra un mensaje de confirmación notificando que el usuario ha sido modificado. 17.1.4 CU_04 Consultar Usuario � Número: 004 � Nombre de Caso de Uso-Análisis: “Consultar Usuario” � Diagrama de Clase Figura 10. Diagrama de Clase CU_04
90
� Diagrama de Secuencia Figura 11. Diagrama de Secuencia CU_04
Descripción Este caso de uso permite al administrador mirar la información (datos personales) de un usuario registrado en la base de datos. El caso de uso inicia cuando el administrador selecciona la opción Consultar Usuario que se encuentra en la interfaz principal, esta interfaz pide al usuario ingresar el id del usuario que desea consultar, el sistema realiza la verificación de los datos, si el dato es ingresado incorrectamente el sistema mostrara la interfaz hasta que el administrador digite bien los datos correspondientes, si el dato es ingresado correctamente la interfaz se comunica con el control Usuario enviándole el dato correspondiente para que realice la consulta, el control se comunica con el ente Usuario haciendo el llamado a consultar para realizar la respectiva consulta del id ingresado, el ente consulta el id del usuario, si el usuario se encuentra registrado el control envía los datos correspondientes y muestra la interfaz con los datos, si el usuario no se encuentra en el sistema mostrará un mensaje indicando que el usuario no existe, si el usuario se encuentra en la base de datos el ente pasa los datos al control para luego ser mostrados en la interfaz consultar, luego se muestran los datos al actor. Termina caso de uso.
91
17.1.5 CU_05 Deshabilitar/Habilitar Usuario � Número: 005 � Nombre de Caso de Uso-Análisis: “Deshabilitar/Habilitar Usuario” � Diagrama de Clase Figura 12. Diagrama de Clase CU_05
� Diagrama de Secuencia Figura 13. Diagrama de Secuencia CU_05
92
Descripción: El administrador inicia el caso de uso cuando selecciona la opción Deshabilitar/Habilitar Usuario, para deshabilitar y habilitar usuarios se muestra en pantalla si se desea realizar deshabilitar y habilitar, la interfaz se comunica con el control Usuario el cual envía al ente Usuario la sentencia a buscar los usuarios que se encuentran deshabilitados y habilitados del sistema, el ente pasa los datos correspondientes al control y luego son mostrados en pantalla, el administrador cambia el estado del usuario de Habilitado - Deshabilitado y Deshabilitado – Habilitado, luego los cambios son guardados en el ente Usuario. Termina la ejecución. 17.1.6 CU_06 Ingresar Solicitud � Número: 006 � Nombre de Caso de Uso-Análisis: “Ingresar Solicitud” � Diagrama de Clase Figura 14. Diagrama de Clase CU_06.
93
� Diagrama de Secuencia Figura 15. Diagrama de Secuencia CU_06
:A Actor :UI Principal :UI Acta :UI Solicitud :C Solicitud :E Solicitud
Selecciona
Activa
Aceptar()
Activa
Muestra Interfaz
Ingresa Datos (idpacie,nombrepaci,fecha,ciudad)
Aceptar()
x=valida_vacios()
y=valida_negativos()
x=false error
y=false error
y=true
Activa
consultar()
z=consultar()
z=false error
z=truePasa datos (paciente)
muestra interfaz
Ingresa Datos()
datos:
Medico tratante
Ips
Medicamento
Entidad_Patologica
Aceptar()
x=valida_vacios()
x=false error
x=true
buscar()
p=buscar
z=false error
z=true
mgs "ingrese datos"
pasa datos()
insertar()
msg Solicitud creada
msg "paciente no existe"
94
Descripción: El caso de uso se ejecuta cuando el digitador selecciona la opción ingresar solicitud que se encuentra en la interfaz principal, al realizar el ingreso de la solicitud, el sistema pide al usuario si desea generar acta, esta acta el sistema la genera con un consecutivo, si el usuario no desea generar acta se seguirá con el consecutivo que tenía anteriormente, el usuario ingresa los datos correspondientes al formato de la solicitud, estos datos son el id del paciente, nombre del paciente, la fecha y la ciudad, el sistema realiza la verificación de los datos, si los datos son ingresados incorrectamente el sistema mostrara la interfaz hasta que el administrador digite bien los datos correspondientes, si el dato es ingresado correctamente la interfaz se comunica con el control Solicitud enviándole el dato del id y el nombre del paciente correspondiente para que realice la consulta, el control se comunica con el ente Solicitud haciendo el llamado a consultar para realizar la respectiva consulta del id y nombre ingresado, el ente consulta el id y nombre del paciente, si el paciente no se encuentra en el sistema mostrará un mensaje indicando que el paciente no existe, si el paciente se encuentra registrado el control envía los datos correspondientes y muestra la interfaz con los datos, el usuario ingresa los demás datos del formato de solicitud, estos datos son: medico tratante, IPS, medicamento y entidad patológica, el sistema realiza la verificación de los datos, la interfaz se comunica con el control solicitud y luego con el ente solicitud haciendo el llamado de buscar, si los datos no se encuentran en la base de datos, el sistema indicara el error de ingresar los datos del médico tratante, la IPS y el medicamento, la interfaz se comunica con el control solicitud pasando los datos que se han ingresado en el formato del ingreso de solicitud de medicamento, el control se comunica con el ente solicitud para realizar la respectiva inserción de los datos en la base de datos, los datos son asociados y luego se muestra en pantalla indicando que la solicitud fue ingresada
95
17.1.7 CU_07 Modificar Solicitud � Número: 007 � Nombre de Caso de Uso-Análisis: “Modificar Solicitud”
� Diagrama de Clase Figura 16. Diagrama de Clase CU_07
+aceptar()
+cancelar()
+valida_fecha()
+valida_vacios()
+valida_negativos()
-fecha
-cuidad
-id_paciente
-tipo_id
-nombre_paciente
-edad_paciente
-direccion
-tipo_vinculacion
-nombre_mt
-especialidad
-tipo_unidad
-nombre_unidad
-nombre_medica
-tipo_medicamento
-aceptar
-cancelar
:UI Solicitud
+consultar()
+insertar()
:C Solitud
+Eventos()
+Salir()
-Menu
-Salir
:UI Principal
+getfecha()
+getCiudad()
+getId_paciente()
+gettipo_id()
+getNombre_paciente()
+getedad()
+getdireccion()
+gettipo_vinculacion()
+getnombre:mt()
+getespecialidad()
+gettipo_unidad()
+getnombre_unidad()
+getnombre_medica()
+gettipo_medicamento()
+consultar()
+insertar()
-fecha
-cuidad
-id_paciente
-tipo_id
-nombre_paciente
-edad_paciente
-direccion
-tipo_vinculacion
-nombre_mt
-especialidad
-tipo_unidad
-nombre_unidad
-nombre_medica
-tipo_medicamento
-aceptar
-cancelar
:E Solicitud
+valida_vacios()
+valida_negativos()
+aceptar()
+cancelar()
-id_pac
-nombre_pac
-aceptar
-cancelar
:UI Ingresar_ID+getid_paciente()
+getnombre_paciente()
+consultar()
-id_paciente
-nombre_paciente
:E Paciente
96
� Diagrama de Secuencia Figura 17. Diagrama de Secuencia CU_07
:A Actor :UI Principal :UI Ingresar_ID :C Solicitud :E Paciente :E Solicitud
selecciona
activa()
Muestra interfaz
ingresa (idpac,nombrepac)
Aceptar()
x=valida_vacios()x=false error
y=false error y=valida_negativos()
y=true activa()
consultar (idpac,nombrepac)
z=consultar()
z=false error
z=false error
y=true activa()
z=consultar()
z=true
msg "paciente no existe"
activa()
:UI Solicitud
pasa datos(solicitud)
Muestra interfaz
modifica datos()
Aceptar
x=valida_vacios()x=false error
y=false error y=valida_negativos()
y=true
insertar()
msg "solicitud modificada"
msg "el paciente no tiene solicitud asociada"
Descripción: El caso de uso se ejecuta cuando el usuario selecciona la opción Modificar Solicitud que se encuentra en la interfaz principal, el sistema pide al usuario ingresar el id o nombre del paciente al cual se le desea modificar la solicitud, el sistema realiza la verificación de los datos validando campos vacios y negativos, si los datos son ingresados incorrectamente el sistema mostrara la interfaz hasta que el administrador digite bien los datos correspondientes, si los datos son ingresados correctamente la interfaz se comunica con el control Solicitud el cual se comunica con el Ente Paciente haciendo el llamado consultar
97
para realizar la consulta del id o nombre ingresado, el ente paciente realiza la búsqueda de los datos ingresados, si el paciente no se encuentra en la base de datos, el sistema mostrará un mensaje indicando el error ,si el dato del paciente se encuentra en la base de datos, el ente paciente se comunica con el ente Solicitud haciendo el llamado consultar al ente solicitud, el ente realiza la respectiva consulta, si los datos se encuentran relacionados a una solicitud de medicamento, si el paciente no tiene ingresada una solicitud el sistema mostrara un mensaje indicando el erro, si el paciente tiene asociada la solicitud el control Solicitud activa la interfaz Solicitud relacionando los datos a la respectiva interfaz, el usuario modifica los datos correspondientes, el sistema realiza la verificación de los datos, si los datos son inválidos, el sistema mostrara un mensaje indicando el error, si los datos son validos, la interfaz se comunica con el control solicitud, éste se comunica con el ente solicitud con el llamado insertar, insertando los datos modificados. Luego se muestra en pantalla indicando que la solicitud fue modificada. Termina ejecución. 17.1.8. CU_08 Consultar Solicitud � Número: 008 � Nombre de Caso de Uso-Análisis: “Consultar Solicitud” � Diagrama de Clase Figura 18. Diagrama de Clase CU_08
98
� Diagrama de Secuencia Figura 19. Diagrama de Secuencia CU_08
Descripción: El usuario inicia el caso de uso cuando selecciona la opción consultar Solicitud que se encuentra en la interfaz principal, el sistema pide al usuario ingresar el id o nombre del paciente, el sistema realiza la verificación de los datos, si el dato es ingresado incorrectamente el sistema mostrara la interfaz hasta que el administrador digite bien los datos correspondientes, si el dato es ingresado correctamente la interfaz se comunica con el control Solicitud, el control solicitud se comunica con el ente paciente con el llamado consultar enviándole el dato correspondiente para que realice la consulta, el ente realiza la consulta, si el paciente no se encuentra el sistema el sistema mostrará un mensaje indicando que el usuario no existe, si el paciente se encuentra, el ente paciente se comunica con el ente solicitud haciendo el llamado buscar, si no se encuentra ninguna solicitud relacionada al paciente, se mostrara un mensaje indicando el error, si hay una solicitud relacionada al paciente el ente solicitud pasa los datos al control para luego ser asociados y mostrados en pantalla. El usuario tiene la opción de imprimir. Termina ejecución.
99
17.1.9 CU_09 Estudio Medico � Número: 009 � Nombre de Caso de Uso-Análisis: “Estudio Medico” � Diagrama de Clase Figura 20. Diagrama de Clase CU_09
100
� Diagrama de Secuencia Figura 21. Diagrama de Secuencia
:a Actor :UI Principal :Ui Ingresar-ID :C Paciente :E Paciente :E Solicitud :C Estudio :UI Estudio
Selecciona
activa
Muestra Interfaz
ingresa datos(idpac,nombre,pac)
x=valida_vacios()
y=valida_negativos()
x=false error
y=false error
y=true
Activa()
buscar(idpac,nombrpac)
z=buscar()
z=false error
z=true
msg "paciente no existe"
pasa datos()
z=Buscar()
z=false error
z=true
activa()
muestra interfaz
Evaluar solicitud
aceptar()
msg "estudio realizado"
pasa datos()
insertar()
aceptar()
Descripción: El usuario inicia el caso de uso cuando el usuario selecciona la opción Estudio Solicitud que se encuentra en la interfaz principal, la interfaz se comunica con la interfaz ingresar_id el cual el sistema pide al usuario ingresar el id o nombre del paciente, el sistema realiza la verificación de los datos, si el dato es ingresado incorrectamente el sistema mostrara la interfaz hasta que se digite bien los datos correspondientes, si el dato es ingresado correctamente la interfaz se comunica con el control Paciente para luego el control se comunica con el ente paciente con el llamado consultar enviándole el dato correspondiente para que realice la consulta, el ente realiza la consulta, si el paciente no se encuentra el sistema el sistema mostrará un mensaje indicando que el paciente no existe, si el paciente se encuentra en el sistema, el ente Paciente se comunica con el ente Solicitud haciendo el llamado a buscar, el ente busca la solicitud referente a los
101
datos ingresados, luego el ente Solicitud pasa los datos relacionados al control Estudio, el control estudio activa la interfaz Estudio la cual asocia los datos de la solicitud, el médico realiza el estudio médico correspondiente seleccionando la opción Evaluar Solicitud (se ejecuta el caso de uso CU-10), los datos se pasan al control para luego ser insertados en el ente solicitud. Se muestra un mensaje en pantalla indicando que el estudio fue realizado. Termina ejecución. 17.1.10 CU_010 Evaluar Solicitud � Número: 0010 � Nombre de Caso de Uso-Análisis: “Evaluar Solicitud” � Diagrama de Clase Figura 22. Diagrama de Clase CU_10
102
� Diagrama de Secuencia Figura 23. Diagrama de Secuencia CU_10
Descripción: El caso de uso se ejecuta cuando el médico selecciona la opción Evaluar Solicitud que se encuentra en la interfaz de estudio Médico, el usuario ingresa los datos relacionados a la interfaz, el sistema realiza la verificación de los datos si el dato es ingresado incorrectamente el sistema mostrara la interfaz hasta que se digite bien los datos correspondientes, si el dato es ingresado correctamente la interfaz se comunica con el control Evaluar Solicitud, el control se comunica con el ente Evaluar Solicitud mediante el llamado insertar, el cual inserta los datos ingresados, luego el control muestra los datos asociados en la interfaz Estudio Medico, termina caso de uso.
103
17.1.11 CU_011 Modificar Estudio Medico
� Número: 0011 � Nombre de Caso de Uso-Análisis: “Modificar Estudio Medico” � Diagrama de Clase Figura 24. Diagrama de Clase CU_11
104
� Diagrama de Secuencia Figura 25. Diagrama de Secuencia CU_11
Descripción: La ejecución del caso de uso inicial seleccionar la opción Modificar Estudio Medico, el sistema pide al usuario que ingrese el id o nombre del paciente al cual desea modificar, al ser ingresados los datos el sistema realiza la verificación de los datos si el dato es ingresado incorrectamente el sistema mostrara la interfaz hasta que se digite bien los datos correspondientes, si el dato es ingresado correctamente la interfaz se comunica con el control Paciente para luego el control se comunica con el ente paciente con el llamado consultar enviándole el dato correspondiente para que realice la consulta, el ente realiza la consulta, si el paciente no se encuentra el sistema el sistema mostrará un mensaje indicando que el paciente no existe, si el paciente se encuentra en el sistema, el ente Paciente se comunica con el ente Solicitud haciendo el llamado a buscar, el ente busca la solicitud referente a los datos ingresados, luego el ente Solicitud pasa los datos relacionados al control Estudio, el control estudio activa la interfaz
105
Estudio la cual asocia los datos de la solicitud, el médico realiza la modificación de los datos, si el médico desea modificar la evaluación de la solicitud selecciona la opción Evaluar Solicitud (se ejecuta caso de uso 10), el sistema realiza la verificación de los datos si el dato es ingresado incorrectamente el sistema mostrara la interfaz hasta que se digite bien los datos correspondientes, si los datos son ingresados correctamente la interfaz se comunica con el control Estudio para luego comunicarse con el ente Solicitud mediante el llamada Insertar, la cual inserta los datos modificados, luego el control muestra un mensaje indicando que la solicitud ha sido modificada. Termina ejecución del caso de uso. 17.1.12 CU_012 Ingresar Medico Tratante � Número: 0012 � Nombre de Caso de Uso-Análisis: “Ingresar Medico Tratante” � Diagrama de Clase Figura 26. Diagrama de Clase
106
� Diagrama de Secuencia Figura 27. Diagrama de Secuencia CU_12
Descripción: El caso de uso se ejecuta al seleccionar la opción Ingresar Medico Tratante, al seleccionar la opción se mostrara en pantalla la interfaz de Medico Tratante la cual se ingresaran los datos correspondientes al médico, el sistema realiza la verificación de los datos si el dato es ingresado incorrectamente el sistema mostrara la interfaz hasta que se digite bien los datos convenientes, si los datos son validos la interfaz se comunica con el control Medico_Tratante el cual se comunica con el ente Medico_Tratante mediante el llamado consultar, si el médico se encuentra en la base de datos el sistema mostrara en pantalla un mensaje indicando que el médico ya existe, si el médico tratante no se encuentra en la base de datos, la interfaz se comunica con el control pasándole los datos ingresados anteriormente, el control se comunica con el ente Medico_Tratante mediante el llamado insertar la cual se insertaran los datos ingresados, el sistema muestra un mensaje indicando que el médico ha sido ingresado.
107
17.1.13 CU_013 Ingresar IPS � Número: 0013 � Nombre de Caso de Uso-Análisis: “Ingresar IPS” � Diagrama se Clase Figura 28. Diagrama de Clase CU_13
� Diagrama de Secuencia Figura 29. Diagrama de Secuencia CU_13
108
Descripción: El caso de uso se ejecuta al seleccionar la opción Ingresar IPS, al seleccionar la opción se mostrara en pantalla la interfaz de IPS, la cual se ingresaran los datos correspondientes a la IPS, el sistema realiza la verificación de los datos, si los datos son ingresados incorrectamente el sistema mostrara un mensaje indicando el error hasta que se digite bien los datos convenientes, si los datos son validos la interfaz se comunica con el control IPS el cual se comunica con el ente IPS mediante el llamado consultar, si la IPS se encuentra en la base de datos el sistema mostrara en pantalla un mensaje indicando que la IPS ya existe, si la IPS no se encuentra en la base de datos, la interfaz se comunica con el control pasándole los datos ingresados anteriormente, el control se comunica con el ente IPS mediante el llamado insertar la cual se insertaran los datos ingresados, el sistema muestra un mensaje indicando que la IPS ha sido ingresada. 17.1.14 CU_014 Ingresar Paciente � Número: 0014 � Nombre de Caso de Uso-Análisis: “Ingresar Paciente” � Diagrama de Clase Figura 30. Diagrama de Clase CU_14
109
� Diagrama de Secuencia Figura 31. Diagrama de Secuencia CU_14
Descripción: El caso de uso se ejecuta al seleccionar la opción Ingresar Paciente, al seleccionar la opción se mostrara en pantalla la interfaz de Ingresar Paciente, la cual se ingresaran los datos correspondientes al paciente, el sistema realiza la verificación de los datos, si los datos son ingresados incorrectamente el sistema mostrara un mensaje indicando el error hasta que se digite bien los datos correctos, si los datos son validos la interfaz se comunica con el control Paciente el cual se comunica con el ente Paciente mediante el llamado consultar, si el Paciente se encuentra en la base de datos el sistema mostrara en pantalla un mensaje indicando que el paciente ya existe, si el paciente no se encuentra en la base de datos, la interfaz se comunica con el control pasándole los datos ingresados anteriormente, el control se comunica con el ente Paciente mediante el llamado insertar la cual se insertaran los datos ingresados, el sistema muestra un mensaje indicando que el paciente ha sido ingresado.
110
17.1.15 CU_015 Ingresar Medicamento � Número: 0015 � Nombre de Caso de Uso-Análisis: “Ingresar Medicamento” � Diagrama de Clase Figura 32. Diagrama de Clase CU_15
� Diagrama de Secuencia Figura 33. Diagrama de Secuencia CU_15
111
Descripción: El caso de uso se ejecuta al seleccionar la opción Ingresar Medicamento que se encuentra en la interfaz Solicitud, al seleccionar la opción se mostrara en pantalla la interfaz de Ingresar Medicamento, la cual se ingresaran los datos correspondientes al medicamento, el sistema realiza la verificación de los datos, si los datos son ingresados incorrectamente el sistema mostrara un mensaje indicando el error hasta que se digite bien los datos correctos, si los datos son validos la interfaz se comunica con el control Medicamento el cual se comunica con el ente Medicamento mediante el llamado consultar, si el medicamento se encuentra en la base de datos el sistema mostrara en pantalla un mensaje indicando que el medicamento ya existe, si el medicamento no se encuentra en la base de datos, la interfaz se comunica con el control pasándole los datos ingresados anteriormente, el control se comunica con el ente Medicamento mediante el llamado insertar la cual se insertaran los datos ingresados, el sistema muestra un mensaje indicando que el medicamento ha sido ingresado. Termina ejecución del caso de uso. 17.1.16 CU_016 Realizar Informe � Número: 0016 � Nombre de Caso de Uso-Análisis: “Realizar Informe” � Diagrama de Clase Figura 34. Diagrama de Clase CU_16
112
� Diagrama de Secuencia Figura 35. Diagrama de Secuencia CU_16
Descripción: El usuario inicia el caso de uso cuando da clic del evento Generar Informe que se encuentra en la interfaz principal, el sistema muestra la interfaz indicándole al usuario el tipo de informe que desea realizar, la interfaz se comunica con la interfaz Rango_Fecha la cual pide al usuario elegir la fecha del cual desea realizar el reporte, el sistema realiza la verificación de los datos, si el rango de la fecha no es válido el sistema vuelve a pedir al usuario que seleccione el tipo de informe, si el rango de la fecha es válido la interfaz se comunica en el control Solicitud, este se comunica con el ente solicitud mediante el llamado consultar para hacer las consultas respectivas, el ente solicitud retorna las solicitudes al control para luego ser mostradas en la interfaz reporte, el usuario tiene la opción de imprimir el reporte. Termina ejecución.
113
18. PAQUETES DE ANÁLISIS En la figura 36 se muestra el paquete UI Package el cual contiene todas las clases de interfaz del sistema:
Figura No. 36 UI_Package
En la figura No. 37 se muestra el paquete Control Package el cual contiene todas las clases de control del sistema:
114
Figura No. 37 Control_Package
En la figura No. 38 se muestra el paquete Entity Package el cual contiene todas las entidades del sistema: Figura No. 38 Entity_Package
En la figura No. 38 se muestra el paquete de análisis relacionado el cual contiene la unión de todos los paquetes del sistema:
115
Figura No. 39 Paquete de Análisis Relacionado
116
19. DESCRIPCIÓN DE PAQUETES DE ANÁLISIS A partir de la arquitectura de los casos de uso, siguiendo el modelo de casos de uso y requisitos suplementarios obtenemos los siguientes paquetes: 19.1 PAQUETE: “UI PACKAGE” Descripción: Contiene las clases de interfaz de ingresos, modificaciones, evaluaciones y reportes de la solicitud de medicamentos del Comité Técnico Científico CTC. Todas son interfaces de usuario adoptadas de los casos de uso identificados en el levantamiento de requerimientos. Objetivo: Las clases de interfaz de usuario son independientes y se agrupan todas en el paquete UI Package para seguir el patrón MVC (Model View Controller). 19.2 PAQUETE: “CONTROL PACKAGE” Descripción: Contiene las clases de control Usuario, control Solicitud, control Paciente, control Estudio, control Avaluar, control Medico_Tratante, control IPS, control Medicamento, encargadas de administrar los procesos del sistema. Objetivo: Agrupar todas las clases que hacen posible controlar y ejecutar los procesos que un usuario puede realizar en el sistema. Contiene la clase control Usuario la cual maneja los perfiles de todos los usuarios que puedan ingresar al sistema; Solicitud, que gestiona los datos de la solicitud respectiva de cada medicamento por paciente; Paciente, encargada de acceder a los datos principales del paciente; Estudio, llevará a cabo el proceso de realizar el estudio médico correspondiente a las solicitudes ingresadas; Evaluar, administrará la aceptación, negación o prorroga de las solicitudes de medicamento; Medico_Tratante, gestiona los datos de los médicos; IPS, gestiona los datos de las Ips ingresadas al sistema, Medicamento, gestiona los datos de los medicamentos de la solicitud.
117
19.3 PAQUETE: “ENTITY PACKAGE” Descripción: Contiene las clases necesarias para el almacenamiento y lectura de la información obtenida de la captura de los datos ingresados y comunicación al sistema hardware. Objetivo: Agrupar las entidades del sistema, en este caso las entidades: Usuario, Solicitud, Paciente, Evaluar, Medico_Tratante, IPS, Medicamento.
118
20. DESCRIPCIÓN DE ARQUITECTURA Para el desarrollo del producto software Comité Técnico Científico (CTC) se han tomado ciertas decisiones acerca de las herramientas de desarrollo que se van a utilizar en la implementación de dicho producto. Debido a la especificación del cliente y a cómo interactúan los actores con el sistema la arquitectura que mejor se acomoda a la aplicación es Cliente/Servidor de tres capas con clientes delgados, que consiste en una capa de Presentación, otra capa de la lógica de la aplicación y otra capa de la base de datos, donde: Presentación: son los formularios e inclusive código fuente que valida la entrada de datos en los formularios. Lógica: esta la parte más compleja e incluye todo lo que el programa debe hacer, aquí se arman las consultas SQL para acceder a datos que es enviada a la siguiente capa (Acceso a datos). Acceso a datos: esta parte es la encargada de acceder a los datos de la base de datos, realizando cualquier operación contra esta misma como ser Insertar, Modificar y Eliminar. La forma más correcta es agrupar cada capa en un directorio aparte. Es decir existirán 3 directorios principales, Presentación, Lógica, Acceso a datos. Se decidió una arquitectura de tres capas, donde la interfaz se encuentra situada en la primera capa, aparte de la lógica del negocio que se encuentra en la segunda capa y de los datos situados en la tercera capa, brindando la posibilidad de modificar cualquiera de las tres capas de manera independiente. Figura 36. Arquitectura Cliente/Servidor
119
Esta arquitectura se estableció debido a que durante la realización del presente proyecto se requiere de mucho procesamiento de datos en la aplicación, en las aplicaciones las funcionalidades están en constante cambio, aislar la tecnología de la base de datos para que sea fácil de cambiar, facilitar separar el código del cliente para que se facilite el mantenimiento y adecuada para utilizar programación orientada a objetos. Para el almacenamiento de datos se eligió el gestor de base de datos Sybase ya que es el que actualmente utiliza la Empresa Seguro Social y además poseen las licencias respectivas del uso de la misma. El gestor de bases de datos Sybase se opto como una solución para el análisis de la información y generación de informes en tiempo real, a partir de grandes volúmenes de datos, con menor costo de almacenamientos y administración. Su arquitectura permite procesar grandes volúmenes de datos con eficiencia, para facilitar a los usuarios la obtención de datos concretos en el momento preciso. Con respecto al lenguaje de programación se propuso realizar el proyecto en Visual Basic, en requerimientos con el Comité Técnico Científico CTC se planteó realizar el proyecto en Visual Studio .NET el cual permite a los programadores generar con rapidez aplicaciones para Internet de próxima generación orientadas a cualquier dispositivo y que se integran en cualquier plataforma. De esta forma el departamento podría continuar dando soporte al sistema después de que este sea construido y puesto en funcionamiento. A continuación se mostrara una imagen que ilustra el modelo de capas que componen los elementos que serán utilizados para llevar a cabo el desarrollo del sistema. Figura 37. Modelo de Capas
120
A continuación se presenta como se definió cada una de las partes de la arquitectura del sistema y especificando las razones para la elección de un método u otro: Componentes de interfaz de usuario (IU): la mayor parte de las soluciones necesitan ofrecer al usuario un modo de interactuar con la aplicación. Para el comité Técnico Científico CTC, un sitio Web permite al usuario realizar las operaciones correspondientes basadas en el entorno operativo Microsoft Windows, la cual permite hacer todo tipo de ingresos, modificación e inserción de datos. Las interfaces de usuario se implementan utilizando páginas Microsoft ASP.NET, controles u otro tipo de tecnología que permita procesar y dar formato a los datos de los usuarios, así como son los ingresos y validaciones de los datos entrantes procedentes de éstos. Interfaces de servicios : para exponer lógica empresarial como un servicio, es necesario crear interfaces de servicios que admitan las transacciones de comunicación; comunicación basada en mensajes, formatos, protocolos, seguridad y excepciones, entre otros que requieren los usuarios. En la interfaz de servicio se definen y coordinan los procesos de varios pasos de la ejecución del programa, los cuales se deben organizar y llevar a cabo en un orden determinado, se opera el manejo de sesiones, el manejo de errores y la ADOdb que maneja la lógica del sistema. Componentes lógicos de acceso a datos: la mayoría de las aplicaciones y servicios necesitan obtener acceso a un almacén de datos en un momento determinado del proceso. En los componentes lógicos de acceso se manejan las funcionalidades de acceso a datos es decir los SQL respectivos para obtener acceso a los datos en una capa independiente. Orígenes de datos: se encuentran todas las tablas donde se almacena la información donde están definidos procedimientos que se encargan de acceder a los datos cuando se necesita realizar algún tipo de operación intermedia de la lógica del negocio.
121
21. DISEÑO Y MODELO DE DATOS Descripción de entes del sistema. 21.1 MODELO ENTIDAD RELACIÓN MER
A continuación la figura No. 38 muestra el modelo entidad relación para el sistema: Figura 38. Modelo Entidad Relación.
122
21.2 MODELO RELACIONAL DE DATOS El modelo relacional de datos presenta en detalle cada una de las tablas del modelo entidad relación con sus tipos de datos, las restricciones, llaves primarias y foráneas dentro de las tablas. Tabla 21. MRD Paciente.
Campo Id Tipo_id Nombre Apellido Fecha
Nacimiento Dirección Teléfono
Tipo_Vinculación
Tipo y longitud bigin
t nchar(10) nvarchar(50) nvarchar(50) datetime nvarchar(MAX) numeric(18,0)
nvarchar(MAX)
Tipo clave PK Obligatoriedad NN NN NN NN NN NN Dominio y Restricción >0 >0
Tabla 22. MRD Médico Tratante. Campo Id Nombre Apellido Especialidad Tipo y Longitud int nvarchar(50) nvarchar(50) nvarchar(MAX) Tipo Clave PK Obligatoriedad NN NN NN NN Dominio y Restricción >0
123
Tabla 23. MRD Tabla Ciudad. campo Código Nombre Tipo y Longitud int nvarchar(50) Tipo Clave PK Obligatoriedad NN NN Dominio y Restricción >0
Tabla 24. MRD Departamento. Campo Código Nombre Tipo y Longitud int nvarchar(50) Tipo Clave PK Obligatoriedad NN NN Dominio y Restricción >0
Tabla 25. MRD Medicamento. Campo Código Nombre Tipo_Medicamento Detalle_Medicamento Tipo y longitud int nchar(50) nchar(10) nvarchar(MAX) Tipo clave PK Obligatoriedad NN NN NN NN Dominio y Restricción >0
124
Tabla 26. MRD Evaluación Solicitud.
Campo Código Tipo
_Evaluación Duración Cantidad_
Tratamiento Dosis_
Tratamiento Tipo y longitud int nvarchar(50) nchar(10) nchar(10) nchar(10) Tipo clave PK Obligatoriedad NN NN NN NN NN Dominio y restricción >0 >0 >0 >0
Tabla 27. MRD Solicitud. Campo Código Fecha Tipo_Unidad Historia_Clínica Tipo y longitud int datetime nvarchar(50) nvarchar(MAX) Tipo clave PK Obligatoriedad NN,U1 NN NN NN Dominio y Restricción >0
Tabla 28. MRD IPS. Campo Código Nombre Dirección Teléfono Tipo y Longitud int nvarchar(50) nvarchar(MAX) numeric (18,0) Tipo Clave PK Obligatoriedad NN NN NN NN Dominio y Restricción >0 >0
125
Tabla 29. MRD Entidad Patológica. Campo Código_CIE Diagnostico Tipo y Longitud nvarchar(50) nvarchar(MAX) Tipo Clave PK Obligatoriedad NN NN Dominio y Restricción
Tabla 30. MRD Actas. Campo Código Fecha_Inicial Fecha_Final Tipo y Longitud int datetime datetime Tipo Clave PK Obligatoriedad NN NN NN Dominio y Restricción >0
Tabla 31. MRD Presentación Medicamento. Campo Código Nombre Tipo_Dosis Detalle_Unidades Tipo y Longitud int nvarchar(MAX) nchar(10) nvarchar(50) Tipo Clave PK Obligatoriedad NN NN NN NN Dominio y Restricción >0 >0
Tabla 32. MRD Unidades de Concentración. Campo Código Nombre Tipo y Longitud int nvarchar(50) Tipo Clave PK Obligatoriedad NN NN Dominio y Restricción >0
126
Tabla 33. MRD Perfil de Usuario. Campo Código Cargo Descripción Tipo y Longitud int nvarchar(50) nvarchar(MAX) Tipo Clave PK Obligatoriedad NN NN NN Dominio y Restricción >0
Tabla 34. MRD Usuario
Tabla 35. MRD Bitácora. Campo Fecha Hora Tipo y Longitud datetime datetime Tipo Clave Obligatoriedad NN NN Dominio y Restricción >0
Campo Id Nombre Apellido Login Password Dirección Teléfono email
Tipo y longitud bigint nvarchar(50) nvarchar(50) nchar(10) nchar(10) nvarchar(MAX) nchar(10) nvarchar(MAX)
Tipo clave PK Obligatoriedad NN NN NN NN NN NN NN NN
Dominio y Restricción >0 >0
127
22. CONCLUSIONES
El desarrollo del proyecto Comité Técnico Científico CTC, es un avance importante para la EPS Seguro Social, sede Bellavista en Cali, ya que e s un sistema de información integrado para esta misma. Inicialmente con el proceso de desarrollo se abarcaron los procedimientos correspondientes a la ingeniería de software ya que la realización de este trabajo brindo la posibilidad de diseñar un sistema con funcionalidades que permiten la interacción del usuario con el proceso en particular permitiendo así una automatización para la oficina del Comité Técnico Científico CTC al momento de realizar los requisitos correspondientes por la aplicación. Además brinda un valor positivo de desarrollo ya que existen muy pocos antecedentes en este tipo de información. La realización de esta aplicación es una solución importante para el comité Técnico Científico CTC, ya que el sistema de información es indispensable para la empresa, es por eso que se llevo a cabo el desarrollo de este presente proyecto en modalidad de pasantía.
128
23. RECOMENDACIONES
Durante el desarrollo del proyecto para el Comité Técnico Científico CTC, se desarrollo hasta el documento de análisis y diseño para la EPS Seguro Social, sede en Bellavista en Cali, para esto al momento de implementar el sistema se recomienda realizar una equivalencia entre los diagramas de casos de uso, diagramas de clases, diagramas de secuencia y tablas donde se especifican los componentes de las interfaces que conforman los casos de uso y las respectivas tablas que se consulta en la base de dato, para lograr una coherente relación entre el diseño y la implementación de la aplicación. El trabajo futuro se debe diseñar la implementación acorde al Comité Técnico Científico CTC ya que este no se encuentra incluido en el documento de diseño.
129
BIBLIOGRAFIA
MTBase Sybase de Colombia [en línea]. Colombia: Sybase de Colombia. [Consultado 10 de noviembre, 2007]. Disponible en Internet: http://www.mtbase.com/productos/gestionbasesdedatos PRESSMAN, Roger S. Ingeniería del Software: Un enfoque práctico. 6 ed. México D.F.: McGraw-Hill, 1998. 581 p. Seguro Social [en línea]. Colombia: ISS, 2007. [Consultado en noviembre de 2007]. Disponible en Internet: http://www.iss.gov.co/ SOMERVILLE, Ian. Ingeniería del Software. 6 ed. México: Addison Wesley, 2001. 299 p. UML, Object Management Group, Unified Modeling Language UML [en línea]. Estados Unidos: UML, 2007. [Consultado 15 de agosto, 2007]. Disponible en internet: http://www.uml.org/ Wikipedia. Enciclopedia Libre [en línea]. Florida: Microsoft Visual Basic, 2007. [Consultado 05 de noviembre, 2007]. Disponible en Internet: http://es.wikipedia.org/wiki/Visual_Basic
130
ANEXOS
Anexo 1. Formato Ingreso de Solicitud