, junio de 2019
TRANSCRIPT
, junio de 2019
Tecnologías de Programación y Sistemas de Información
Título:
Sistema informático para la gestión de la información clínica de la sala de
Cardiología del Hospital Universitario Clínico-Quirúrgico “Arnaldo Milián Castro”.
Tutores:
Dra. Martha Beatriz Boggiano Castillo
Lic. Alexander Rodríguez Fabelo
Consultante:
Dr. José Ignacio Ramírez Gómez
Autor:
Gustavo del Sol Hernández
, June of 2019
Programming Technologies and Information System
Title:
Computer System for the management of clinical information
of the Cardiology room of the Clinical- Surgical University
Hospital “Arnaldo Milián Castro”
Author:
Gustavo del Sol Hernández
Thesis Director:
Dra. Martha Beatriz Boggiano Castillo
Lic. Alexander A. Rodríguez Fabelo
Consultant:
Dr. José Ignacio Ramírez Gómez
Este documento es Propiedad Patrimonial de la Universidad Central “Marta Abreu”
de Las Villas, y se encuentra depositado en los fondos de la Biblioteca Universitaria
“Chiqui Gómez Lubian” subordinada a la Dirección de Información Científico Técnica
de la mencionada casa de altos estudios.
Se autoriza su utilización bajo la licencia siguiente:
Atribución- No Comercial- Compartir Igual
Para cualquier información contacte con:
Dirección de Información Científico Técnica. Universidad Central “Marta Abreu” de
Las Villas. Carretera a Camajuaní. Km 5½. Santa Clara. Villa Clara. Cuba. CP. 54 830
Teléfonos.: +53 01 42281503-1419
I
Pensamiento
“Todos tenemos sueños. Pero para convertir los sueños en
realidad, se necesita una gran cantidad de determinación,
dedicación, autodisciplina y esfuerzo”
Jesse Owens
II
Dedicatoria
A mi familia por su apoyo en todo este tiempo,
especialmente a mis padres, tíos y abuelos.
III
Agradecimientos
A mis padres Tania y Gustavo, mi tía Talena, mi abuela Diley, y
familia en general, por su preocupación y por estar a mi lado
cada vez que lo he necesitado.
A mi tío Alex, por su incondicionalidad.
A mi tutora, la Dra. Martha Beatriz Boggiano Castillo, por su
preciado tiempo.
A mi novia Anailis, por comprenderme y apoyarme en todo este
tiempo.
A mis compañeros de carrera, especialmente a Ana Elisa y César,
por estar siempre juntos.
A todos los amigos y compañeros que, de una forma u otra,
posibilitaron el desarrollo de este trabajo.
IV
Resumen
La atención a pacientes hospitalizados con diagnósticos de enfermedades
cardiovasculares es el propósito fundamental de la sala de Cardiología del
Hospital Universitario Clínico – Quirúrgico “Arnaldo Milián Castro” de Santa
Clara. La información de los pacientes se ha gestionado a través de una hoja
clínica específica de la sala con apoyo de una base de datos Access; sin
embargo, esto no ha satisfecho las expectativas del personal cardiólogo;
además, el diseño de la misma es deficiente; estas son las causas que motivan
a este trabajo, que tiene como objetivo desarrollar un Sistema Informático para
la gestión de los datos clínicos de los pacientes ingresados en esta sala de
hospitalización. Se estudian sistemas existentes de gestión clínica a nivel
nacional e internacional, y se observa que estos por una razón u otra no son
viables de usar. Se diseña una aplicación de tipo escritorio, siguiendo los
principios del modelo RUP, utilizando el patrón Modelo – Vista – Controlador con
una base de datos relacional que supera las debilidades de la existente. El
sistema se implementa en el lenguaje de programación Java, sobre la plataforma
NetBeans, implementando la base de datos en el gestor PostgreSQL.
El producto se valida utilizando técnicas de pruebas de caja negra y pruebas de
caja blanca para depurar defectos. Se realizan, además, pruebas de aceptación
a los usuarios, utilizando encuestas, con resultados satisfactorios.
El sistema se encuentra actualmente en fase de implementación en la sala de
Cardiología del Hospital.
V
Abstract
The attention to hospitalized patients with diagnoses of cardiovascular diseases
is the fundamental purpose of the Cardiology room of the Clinical – Surgical
University Hospital “Arnaldo Milián Castro” of Santa Clara. The information of the
patients has been managed through a specific clinical sheet of the room with the
support of an Access database; however, this has not met the expectations of
the cardiology staff. In addition, the design of it is deficient; these are the causes
that motivate this work, which aims to develop a computer system for the
management of clinical data of patients admitted to this hospital ward. Existing
clinical management systems are studied at national and international level, and
it is observed that these for one reason or another, are not viable to use. A
desktop application is designed, following the principles of the RUP model, using
the Model – View – Controller model with a relational database that overcomes
the weaknesses of the existing one. The system is implemented in the Java
programming language, on the NetBeans platform, implementing the database in
the PostgreSQL manager.
The product is validated using black box testing techniques and white box tests
to debug defects. In addition, acceptance tests are made to users, using surveys,
with satisfactory results.
The system is currently in the implementation phase in the Cardiology room of
the Hospital.
VI
Tabla de contenidos
Introducción .....................................................................................................................1
Capítulo I. Gestión de información clínica hospitalaria. Fundamentos teóricos. ...6
1.1 Gestión de la información clínica cardiológica.............................................6
1.2 Sistemas informáticos de gestión hospitalaria.............................................7
1.2.1 Sistema Informático de Gestión Hospitalaria ICCCVMed.....................7
1.2.2 Sistema de Información Hospitalaria Galen Clínicas............................8
1.2.3 Sistema de Gestión Clínica Klinico .........................................................9
1.2.4 Sistema de Información Hospitalaria XAVIA HIS 2.1 .......................... 10
1.2.5 Sistema informático para la gestión de la información hospitalaria
del infarto agudo de miocardio (RHIMA) ............................................................. 10
1.3 Herramientas para la creación de aplicaciones de escritorio ................... 11
1.3.1 NetBeans IDE ................................................................................................. 11
1.3.2 BlueJ IDE ........................................................................................................ 12
1.3.3 Eclipse IDE ..................................................................................................... 13
1.3.4 IntelliJ IDEA.................................................................................................... 13
1.3.5 JCreator .......................................................................................................... 14
Conclusiones del capítulo ........................................................................................ 15
Capítulo II. Modelo del negocio y requisitos del sistema ......................................... 16
2.1 Modelado de negocio .......................................................................................... 16
2.2 Requisitos del sistema ........................................................................................ 21
2.3 Análisis de factibilidad........................................................................................ 27
2.3.1 Estimación basada en Casos de Uso ......................................................... 27
2.3.1 Costos del desarrollo ................................................................................... 28
Conclusiones del capítulo ........................................................................................ 37
Capítulo III. Descripción de la propuesta de solución. ............................................. 38
3.1 Arquitectura del sistema ................................................................................ 38
3.1.1 Vista de análisis ............................................................................................ 38
3.1.2 Vista de diseño .............................................................................................. 45
3.1.3 Vista de componentes .................................................................................. 48
3.1.4 Vista de despliegue....................................................................................... 51
3.1.5 Vista de implementación .............................................................................. 52
3.2 Modelado propuesto de la base de datos.................................................... 58
3.2.1 Bases de datos relacionales ........................................................................ 58
3.2.2 Proceso de obtención de la base de datos propuesta ............................. 59
Conclusiones del capítulo ........................................................................................ 63
VII
Capítulo IV. Validación de la solución propuesta...................................................... 65
4.1 Pruebas y estrategias de prueba. ...................................................................... 65
4.2 Casos de pruebas. ............................................................................................... 66
4.2.1 Pruebas unitarias. Pruebas de caja blanca................................................ 66
4.2.2 Pruebas funcionales. Pruebas de caja negra. ........................................... 72
4.2.3 Aplicación de encuestas de satisfacción................................................... 78
Conclusiones del capítulo ........................................................................................ 84
Conclusiones generales ............................................................................................... 85
Recomendaciones ......................................................................................................... 86
Referencias bibliográficas............................................................................................ 87
Glosario .......................................................................................................................... 89
Anexos ............................................................................................................................ 90
Anexo 1 Especificación del caso de uso del negocio Indicar tratamiento......... 90
Anexo 2 Especificación del caso de uso del negocio Realizar egreso de
paciente....................................................................................................................... 91
Anexo 3. Especificación del caso de uso del negocio Depurar historia clínica.
...................................................................................................................................... 92
Anexo 4. Manual de usuario del Sistema Informático AMCardio – 2019. ........... 93
1
Introducción
En las últimas décadas, la sociedad cubana ha apostado por el desarrollo de las
nuevas tecnologías de la Informática y las Comunicaciones, las cuales han
impactado con fuerza en varios sectores de la sociedad: economía, población,
los servicios, entre otras; se ha producido un impulso importante en el proceso
de informatización de la sociedad.
La Informatización del Sistema Nacional de Salud (SNS), se enmarca en dicho
proceso, iniciado en 1996; retomado en la actualidad dado los cambios y
transformaciones que se están produciendo en el contexto nacional e
internacional. Responde a la política y estrategias definidas como un proceso
prioritario del sector,(Díaz, 2017).
Este proceso constituye de interés marcado del estado cubano y su órgano rector
el Partido Comunista de Cuba (PCC). Así quedó reflejado en los Lineamientos
de la Política Económica y Social para el período desde el año 2016 a 2021, y
que fueron aprobados en su Séptimo Congreso con gran respaldo popular.
Referido a la política tecnológica trazada para esta etapa, según el Capítulo V:
“Política de ciencia, tecnología, innovación y medio ambiente”, fueron tratados
en el documento varios artículos, tal es el caso del número 98, el cual refiere
situar en el primer plano, el papel de la ciencia y la tecnología, así como la
innovación en todas las instancias. De igual manera, lo hace el 104, el cual
enuncia la prestación de mayor atención a la formación y capacitación continua
del personal técnico y en general a la población que se anticipen con
responsabilidad social al desarrollo científico y tecnológico en las principales
áreas de la producción y los servicios,(PCC, 2017).
En el artículo 108 se refleja claramente el interés del gobierno cubano hacia el
desarrollo tecnológico, al expresar el avance gradual, según las posibilidades
económicas, en el proceso de informatización de la sociedad, el desarrollo de la
infraestructura de telecomunicaciones y la industria de aplicaciones y servicios
informáticos, (PCC, 2017).
En el año 2003 el Ministerio de Salud Pública (MINSAP) como organismo rector
del Sistema Nacional de Salud define como una prioridad su informatización, con
el propósito de elevar la eficiencia, seguridad, calidad y estética en todas las
2
direcciones. Para ello se convoca a un grupo de instituciones propias del sector,
del Ministerio de Informática y Comunicaciones y de otros organismos de la
administración central del estado, para definir de conjunto la estrategia a llevar a
cabo. En algunos casos se ha tomado como punto de partida sistemas ya
elaborados en el país en el marco de aquella primera estrategia de
desarrollo,(Ramos, 2014).
Para el MINSAP, el eje fundamental y centro del proceso de informatización del
sector lo constituye la atención el paciente, quién se reconoce como el principal
beneficiado al garantizar los sistemas, la calidad, oportunidad y consistencia de
la información, lo que incrementará la efectividad y eficiencia de los procesos
relacionados con la salud, que en última instancia gravitarán en un incremento
continuo y sostenido de la calidad en la atención médica. (García, 2018)
Uno de los logros más significativos en el avance de la informatización del SNS
lo constituye el Portal de Salud Cubano Infomed, que desde 1992, surge como
una necesidad de desarrollar el acceso a la información relacionada con las
ciencias médicas, y al conocimiento de los trabajadores de la salud en Cuba,
(García, 2018).
Como iniciativa del Comandante en Jefe de la Revolución Fidel Castro Ruz, y
con el apoyo del Ministerio de Salud Pública, se realizó un programa para la
conexión de todos los policlínicos del SNS. Actualmente se cuenta con los
hospitales provinciales y municipales conectados a la red Infomed. Ha mejorado
la conectividad en las instituciones y se ha trabajado actualmente de conjunto
con las empresas de desarrollo de software para que muchos de los proyectos
realizados se integren a la información con que cuentan los hospitales.
Son muchas las instituciones dedicadas a la producción de software las que se
han sumado al proceso de informatización de la salud en Cuba. Se destaca la
Empresa Cubana de Soluciones Informáticas (Softel), quien ha trabajado en la
informatización de Centros de Atención de Salud, donde se brindan servicios de
consulta externa, medios de diagnóstico y hospitalización. (García, 2018)
El Hospital Universitario Clínico-Quirúrgico Arnaldo Milián Castro, está inmerso
en una serie de proyectos, que, en alguna medida, cumplen con el propósito de
la informatización de la sociedad cubana, a pesar de que los recursos con los
que cuenta el mismo no son óptimos.
3
La sala de Cardiología del hospital registra la información clínica de los pacientes
que ingresan, en las historias clínicas intrahospitalarias que se almacenan en los
archivos correspondientes, estos registros se convierten en grandes volúmenes
de datos, que deben ser posteriormente analizados. Desde hace tres años se
utiliza una base de datos Access para registrar los datos básicos de los pacientes
ingresados, pero este nivel de automatización no cubre las expectativas del
personal médico de la sala, ni las necesidades informativas de instancias
superiores. De esta manera, resulta engorroso realizar el análisis de los datos
clínicos de los pacientes, continúa siendo un proceso al que se le debe destinar
gran cantidad de tiempo, y esfuerzo del personal involucrado. No se logran emitir
datos específicos en cuanto a criterios médicos que son importantes para el
trabajo en la sala.
Los médicos cardiólogos involucrados en el proceso de atención al paciente,
reconocen que el procedimiento actual de recopilación de información clínica es
deficiente, y no se cumple la meta de obtener datos totalmente confiables para
el control interno de los mismos dentro del hospital.
A partir de las carencias informáticas que presenta la sala de Cardiología por las
limitaciones en el manejo de la información de los pacientes y las expectativas
de los cardiólogos de la sala de elevar la calidad de atención a partir de la
exactitud en el manejo de los datos, su organización adecuada y el análisis fiable
de la misma, se formula el problema de investigación con la siguiente pregunta:
¿Cómo obtener un sistema de información hospitalaria que almacene los datos
de los pacientes ingresados en la sala de Cardiología del Hospital Universitario
Clínico - Quirúrgico “Arnaldo Milián Castro” con mayor exactitud y organización
respecto al sistema anterior, de manera que se emitan informaciones útiles
basadas en proceso de selección por criterios establecidos por los especialistas
médicos?
A partir de lo anterior se propone el siguiente objetivo general:
Desarrollar un sistema informático para la gestión de la información clínica de los
pacientes ingresados en la sala de Cardiología del Hospital Universitario Clínico -
Quirúrgico Arnaldo Milián Castro.
Estableciendo como objetivos específicos:
4
1. Diseñar una base de datos relacional a partir de las necesidades de
los cardiólogos de la sala que supere las debilidades que presenta la
base de datos Access existente.
2. Diseñar un software sobre las bases de un modelo de proceso de
desarrollo de software que soporte la implementación del mismo.
3. Implementar las funcionalidades requeridas del sistema de
información que permitan lograr la gestión de los datos clínicos de los
pacientes ingresados y la emisión de información necesitada por el
personal de la sala en este nivel de atención.
4. Validar el sistema desde la perspectiva técnica, a partir del diseño de
pruebas, y desde la perspectiva del usuario teniendo en cuenta el
cumplimiento de sus expectativas.
El valor práctico está dado por la solución del problema planteado, donde dotar
al personal médico de la sala de Cardiología de un sistema informático para
realizar la gestión de la información de los pacientes que ingresan a la misma de
una manera más ágil, evitando errores humanos tales como la repetición de
datos y la pérdida de la información. Además de contar con posibilidades
diversas de obtener los datos de pacientes agrupados por diversas
combinaciones de criterios médicos.
El valor metodológico se refleja en que sistematiza un modo de trabajo en la sala
de cardiología que coadyuva a un manejo organizado de los datos de los
pacientes ingresados a través del tiempo, además servirá de base para trabajos
de investigación médica acerca de los pacientes atendidos en la sala.
El informe se ha estructurado en cuatro capítulos de la siguiente forma:
En el Capítulo I se describe el procedimiento actual de atención al paciente en la
sala de Cardiología del Hospital Universitario Clínico-Quirúrgico Arnaldo Milián
Castro (antes de desarrollar el sistema informático que se propone). Se exponen
las características fundamentales de un conjunto de sistemas de información de
gestión hospitalaria existentes dentro y fuera del ámbito nacional, analizando las
causas de su inadecuación para el problema planteado.
También se tratan aspectos esenciales de entornos de desarrollo de software
para la creación de aplicaciones de tipo escritorio que sirve de base para decidir
el entorno a utilizar.
5
En el Capítulo II se modela el negocio, exponiendo el procedimiento del de la
atención al paciente en la sala de Cardiología, se representa con un diagrama
de casos de uso del negocio, que permite identificar los requisitos del sistema.
Por otra parte, se identifican una serie de reglas del trabajo en la sala de
cardiología, enfocadas como reglas de negocio.
También se realiza una estimación del esfuerzo del proyecto siguiendo la
filosofía de la estimación basada en casos de uso.
En el Capítulo III se describe la solución propuesta. Para ello, se presentan un
grupo de artefactos correspondientes al flujo de trabajo del diseño. Se presenta
el diagrama de la base de datos propuesta atendiendo al procedimiento seguido
para su diseño. Además, se explican funcionalidades desarrolladas en la etapa
de codificación.
En el Capítulo IV se exponen las distintas pruebas técnicas realizadas al sistema,
y los resultados arrojados por las mismas, por otra parte, se exponen resultados
de las pruebas de aceptación realizadas a los usuarios del mismo.
6
Capítulo I. Gestión de información clínica
hospitalaria. Fundamentos teóricos.
Este capítulo trata sobre la forma en que se realiza la gestión de la información
clínica en el Hospital Universitario Clínico-Quirúrgico Arnaldo Milián Castro,
específicamente en la sala de Cardiología de esta institución médica, se exponen
detalles de algunos sistemas de información similares que actúan dentro y fuera
del marco nacional. Además, se describen características esenciales de algunas
herramientas actuales para el desarrollo de aplicaciones de escritorio y sus
características.
1.1 Gestión de la información clínica cardiológica
La sala de Cardiología del Hospital Universitario Clínico-Quirúrgico Arnaldo
Milián Castro se desempeña principalmente en la atención de los pacientes que
requieren estudios diagnósticos de enfermedades cardiovasculares: la
realización de trombólisis, estudios por coronariografía, etc., cuyos resultados
pueden diagnosticar enfermedades cardiovasculares para establecer
tratamientos adecuados, que pueden incluso llegar a ser operaciones del
corazón.
Actualmente, para gestionar los datos de estos pacientes en la sala se cuenta
con un modelo de historia clínica donde se registra al ingreso del paciente de
forma manual su número de historia, nombre y apellidos. En caso de que el
paciente no recuerde su número de historia clínica, se solicita al archivo del
hospital. En caso contrario, se le asigna un número temporal al momento de su
ingreso.
Se recogen además otros datos de gran interés para los cardiólogos, como la
edad, antecedentes patológicos, sexo del paciente, la raza y demás, estos datos
también se registran en una base de datos Access implementada a estos
efectos. Se adicionan datos de interés como la fecha de egreso o fecha de
fallecimiento. Se registran además datos específicos de los resultados de las
pruebas diagnósticas realizadas a los pacientes. Varios de los datos que se
solicitan han sido reportados en la literatura médica como decisivos en el
7
condicionamiento de enfermedades cardiovasculares, por lo que es importante
registrarlos y que el almacenamiento de los mismos constituya una base
fundamental para el estudio de enfermedades cardiovasculares en el ámbito
nacional y regional.
1.2 Sistemas informáticos de gestión hospitalaria
En este epígrafe se exponen las características de algunos sistemas de
información dedicados a la gestión de información clínica de pacientes que
actúan en el marco nacional e internacional.
1.2.1 Sistema Informático de Gestión Hospitalaria ICCCVMed
ICCCVMed es un sistema de gestión que implementa el Instituto de Cardiología
y Cirugía Cardiovascular (ICCCV) de La Habana, destinado al registro de las
historias clínicas de los pacientes. Este sistema cuenta con una serie de módulos
que realizan la gestión, centralización y aseguramiento de la información clínica
de distintas áreas, tal es el caso de Anestesiología, Cirugía, entre otros,(Motroni,
2018).
Este sistema cuenta con una base de datos relacional, y los módulos fueron
creados con el lenguaje Pascal (Delphi) orientado a objetos, (Motroni, 2018).
Para desarrollar la página web, la cual permite consultar la información desde
cualquiera de las estaciones de trabajo, se empleó el lenguaje PHP soportado
en un servidor Apache, (Motroni, 2018).
El sistema de gestión ICCCVMed garantiza que la información almacenada en
la base de datos sea confiable, pues en los documentos que exporta se incluyen
la fecha y hora de cuándo fueron modificados, así como el especialista que
realizó la modificación. Se realizan salvas de la información de manera diaria,
las cuales garantizan cualquier alteración de la base de datos producto de fallos
eléctricos. Permite la recuperación de información histórica mediante consultas
fáciles de preparar, que permiten exportar el resultado para su uso en paquetes
estadísticos, (Motroni, 2018).
Las funcionalidades de ICCCVMed, son específicas para un centro hospitalario
de cirugía cardiovascular y utilizarlo en la solución del problema planteado suma
8
riesgos de adaptación de configuración del sistema, de limitaciones de compra
o de autorización de uso.
1.2.2 Sistema de Información Hospitalaria Galen Clínicas
El sistema de Información Hospitalaria Galen Clínicas es una aplicación
informática desarrollada Softel. Es una suite que trabaja en el entorno web y
contiene los resultados de varios componentes médicos y que a partir de las
configuraciones que posee el sistema, permite su instalación tanto en los
grandes institutos médicos como en policlínicos.
Los módulos más importantes del programa informático son: Módulo de
administración, que permite la gestión de usuarios y los permisos de los mismos
a las funcionalidades del sistema. El módulo de configuración: configura y
parametriza el sistema de forma tal que se adecúa a las características de cada
institución. El módulo de registro de personas, que actualiza los datos de las
personas, ya sean pacientes o funcionarios de la institución. El módulo de
inscripción, que permite la inserción y actualización del registro de inscripciones
de la institución, otorgándole una historia clínica a cada paciente. (Softel, 2018)
Está desarrollada utilizando tecnologías libres pertenecientes a la plataforma
JEE (Java Enterprise Edition). Como framework para el desarrollo se utilizó
Gralis en su versión 1.3.7. Como servidor web se utiliza Apache Tomcat 6.0. para
la gestión de la base de datos se utilizó Mysql, aunque es posible cambiar el
gestor de base de datos sin necesidad de hacer cambios en el sistema, (Softel,
2018).
Actualmente esta herramienta está funcionando en setenta entidades
hospitalarias del país, de acuerdo con los niveles de informatización que posee
cada uno de los centros de salud. También se usa en los Centros de Diagnóstico
Integral (CDI) de Venezuela. En algunos hospitales, por la infraestructura de
comunicación y equipamientos de que disponen, solo se ha podido establecer el
componente de registros médicos, que es el básico, y contiene toda la inscripción
del paciente, la admisión e ingreso, el informe de cirugía, y el egreso, (Softel,
2018).
Galen Clínica registra todas las solicitudes de exámenes, ultrasonidos y rayos X
que se realizan en las instituciones médicas donde actúa. A partir de que se
9
archivan las solicitudes de los turnos, los resultados se imprimen o se envían
directamente al sistema, estos pueden ser consultados desde cualquier lugar del
hospital con acceso a la red, (Softel, 2018).
Este sistema no puede ser utilizado para dar solución al problema, puesto que el
mismo no gestiona los datos específicos necesarios en la sala de Cardiología
del Hospital, como los datos específicos de diagnósticos. Este gestiona varias
áreas del hospital, pero no especifica un módulo para la gestión cardiovascular.
1.2.3 Sistema de Gestión Clínica Klinico
Klinico es un sistema de administración clínica diseñado e implementado por la
compañía paraguaya Green Light S.A. Este sistema de información está
diseñado principalmente para profesionales médicos. El servicio que presta es
totalmente online, está montado en la nube y no necesita instalación. Cuenta con
un soporte permanente, (Light, 2018).
Esta herramienta clínica tiene varias funcionalidades: posee un calendario
flexible para crear citas de manera rápida. Cuenta con un sistema de
notificaciones a emails y mensajes SMS a clientes que ahorran tiempo. Cada
cita, cambio o cancelación cuenta con un recordatorio generado
automáticamente, (Light, 2018).
En cuanto a las recetas médicas el producto las guarda e imprime desde el
sistema, así resulta fácil por parte del personal médico conocer qué
medicamentos fueron proporcionados al paciente con exactitud de fecha, (Light,
2018).
Asimismo, Klinico administra las finanzas del consultorio, crea una factura desde
el calendario, agrega productos, cobra y edita precios de manera digital, (Light,
2018).
La implementación de este sistema de gestión clínica en nuestro país se ve
afectada principalmente porque Klinico es privativo, el usuario debe contar con
una licencia de uso. Existe la posibilidad del uso del software de manera gratuita
en una etapa de prueba de treinta días, donde no es posible acceder a todas las
funcionalidades del mismo, solamente a las básicas, (Light, 2018).
10
1.2.4 Sistema de Información Hospitalaria XAVIA HIS 2.1
XAVIA HIS 2.1 es un sistema integral para la gestión hospitalaria. Tiene como
atributo fundamental una historia clínica electrónica (HCE) única por paciente.
Permite la recolección, almacenamiento, procesamiento y comunicación de la
información relacionada con la atención al paciente, así como la información
administrativa del hospital. Comprende una estructura modular para la gestión
completa de pacientes y sistemas departamentales: Configuración, Admisión,
Historia Clínica, Citas, Consulta externa, Laboratorios, Hospitalización,
Enfermería, entre muchos más. Cuenta, además, con especializaciones para
áreas como Estomatología, (Batista, 2017).
Dentro de los principales beneficios para el paciente sobresale la gestión de la
información de los procesos por los que transita dentro del hospital. Se hace la
integración con el resto de las áreas intrahospitalarias, (Batista, 2017)
Tiene en consideración elementos como la seguridad, la homogeneidad y
estandarización de la información, para lograr un mayor control y una gestión
estadística más ágil y eficiente en la obtención de casos de estudios médicos.
Brinda, además, la posibilidad de realizar estudios estadísticos sobre casos o
padecimientos específicos,(Batista, 2017).
El uso de este Sistema Informático no es viable en la sala de Cardiología; este
sistema de información es utilizado para gestionar una serie de áreas
hospitalarias, lo que supone gran cantidad de información no aplicable a la sala
de Cardiología. Además, este es un sistema de pago, siendo una decisión de los
directivos del Hospital su uso por el personal del mismo.
1.2.5 Sistema informático para la gestión de la información
hospitalaria del infarto agudo de miocardio (RHIMA)
RHIMA es un sistema informático que permite la obtención de datos estadísticos
inmediatos, que permiten realizar un análisis de la atención a los pacientes con
infarto agudo de miocardio, (Curbelo, 2018).
11
Para la implementación de RHIMA se identificaron las variables necesarias para
la confección del registro, divididas por bloques relacionados con la atención
prehospitalaria, el síndrome coronario agudo, la atención en Unidades de
Cuidados Coronarios y el egreso. Se utilizó como IDE de programación
NetBeans, Apache como servidor web y la base de datos en MySql. Como
lenguaje de programación se utilizó PHP con la infraestructura digital
(framework) Yii del lado del servidor y Java Script con el framework ExtJs 4.1.1
del lado del cliente. Como modelador de base de datos se utilizó ER/Studio,
(Curbelo, 2018). La utilización de estas funcionalidades en la sala de Cardiología
no está de acuerdo con las expectativas del personal médico, pues este sistema
es específico para el estudio del infarto agudo de miocardio.
1.3 Herramientas para la creación de aplicaciones de
escritorio
Las aplicaciones de escritorio son programas encargados de realizar la
funcionalidad del software implementado que se instala en cada puesto de
trabajo o cada equipo de cómputo. La principal ventaja de este sistema es que
pueden hacer uso completo de los recursos de la computadora (procesador,
memoria RAM, espacio en disco, etc.). También pueden generar resultados con
cientos de miles de registros en pocos segundos. Actualmente existen varias
tecnologías para el desarrollo de este tipo de aplicaciones, (Ibáñez, 2018).
1.3.1 NetBeans IDE
NetBeans es un entorno de desarrollo gratuito y de código abierto. Permite el
uso de un amplio rango de tecnologías de desarrollo, tanto para escritorio, como
aplicaciones Web, o para dispositivos móviles. Da soporte a tecnologías como
Java, PHP, Groovy, C/C++, HTML5, entre otras. Puede instalarse en varios
sistemas operativos como Windows, Linux y Mac OS, (Hernández, 2018).
Este entorno de desarrollo suele dar soporte a casi todas las novedades en el
lenguaje Java. Cuenta con asistentes para la creación y configuración de
distintos proyectos, incluida la elección de algunos frameworks, (Hernández,
2018).
12
Tiene la característica de ser un buen editor de código, multilenguaje, con el
habitual coloreado y sugerencias de códigos. Además, cuenta con el acceso a
las clases a partir del código, control de versiones, localización de ubicación de
la clase actual, comprobaciones sintácticas y semánticas, plantillas de código,
entre muchas más, (Hernández, 2018).
Simplifica la gestión de grandes proyectos con el uso de diferentes vistas,
asistentes de ayuda, y estructurando la visualización de manera ordenada, lo
que ayuda al trabajo diario, (Hernández, 2018).
La optimización de códigos también está presente en este IDE, de ello se
encarga el Profiler, el cual optimiza las aplicaciones e intenta hacer que se
ejecuten más rápido y con el mínimo uso de memoria. Da la posibilidad de
observar el comportamiento del proyecto y obtener indicadores e información de
cómo y cuántos recursos consume, cuántos objetos se crean, etc., (Hernández,
2018).
Desde el propio Netbeans se puede acceder a distintos sistemas gestores de
bases de datos, como Oracle, MySql, PostgreSQL, ver las tablas, realizar
consultas y modificaciones. Se integra con diversos servidores de aplicaciones,
de tal manera que se puede gestionar desde el propio IDE: inicio, parada,
arranque en modo debug, (Hernández, 2018).
1.3.2 BlueJ IDE
BlueJ es un entorno integrado de desarrollo para el lenguaje de programación
Java, desarrollado principalmente con propósitos educacionales, pero también
es adecuado para el desarrollo de softwares a pequeña escala, (Ecured, 2018a).
BlueJ está desarrollado completamente sobre Java, por lo que es
multiplataforma. Una de sus características más llamativas es que utiliza muy
pocos recursos de la máquina. Además, cuenta con un sistema muy parecido al
Lenguaje Unificado de Modelado (UML) que representa de manera gráfica el
comportamiento y las relaciones que existen entre clases,(Ecured, 2018a).
La representación de los objetos se realiza de dos formas: los conceptos de
clases y objetos; ambos representados de forma visual, aunque de distintas
maneras. La interfaz gráfica es simple, más que en ambientes de alta escala
13
profesional, y por ello es fácil de aprender. El objetivo es que el entorno de
desarrollo desaparezca, los usuarios con poca experiencia desarrollen más
fácilmente un modelo mental consistente de sistemas orientados a objetos, sus
propiedades y su ejecución. La última versión estable de este IDE trae mejoras
como el completado de código, (Ecured, 2018a).
1.3.3 Eclipse IDE
Eclipse es una plataforma de desarrollo, diseñada para ser extendida de forma
indefinida a través de plugins. No tiene definido un lenguaje de programación
específico, sino que es un IDE genérico, aunque goza de mucha popularidad
entre la comunidad de desarrolladores de lenguaje Java usando el plugin JDT,
que está incluido en la distribución estándar del IDE. Proporciona herramientas
para la gestión de espacios de trabajo, escribir, desplegar, ejecutar y depurar
aplicaciones,(Acosta, 2018).
En Eclipse, el contexto de trabajo está basado en las perspectivas, una
preconfiguración de ventanas y editores, relacionadas entre sí, y que permiten
trabajar en un determinado entorno de trabajo de forma óptima,(Acosta, 2018).
El desarrollo sobre este IDE se basa en los proyectos, que son el conjunto de
recursos relacionados entre sí, como puede ser el código fuente, documentación,
ficheros de configuración. Árbol de directorios. Eclipse proporciona asistentes y
ayudas para la creación de nuevos proyectos, (Acosta, 2018).
Cuenta con una extensa colección de plugins, algunos de pago y otros bajo
distintas licencias. Uno de ellos, el JDT, es el encargado del soporte del lenguaje
Java en el IDE. Permite el completamiento de código automáticamente, con
sugerencias dependientes del contexto. Admite la generación de esqueletos de
clases, de métodos getters y setters, (Acosta, 2018).
1.3.4 IntelliJ IDEA
IntelliJ IDEA es un ambiente de desarrollo de programas informáticos, un IDE
multiplataforma para Java, desarrollado por JetBrains. Está disponible en dos
ediciones: community edition y edición comercial, esta última una edición de
14
pago, mientras que la primera está disponible bajo una licencia de código abierto,
(Hildalgo, 2017).
El IDE puede extenderse mediante numerosos complementos. Cada uno de sus
aspectos está diseñado para maximizar la productividad del
desarrollador,(Hildalgo, 2017).
Cuenta con un completado de código inteligente, además de sugerir nombres de
clases, métodos, campos y palabras claves, la finalización de código inteligente
depende del contexto, (Hildalgo, 2017).
Igualmente entiende y proporciona ayuda de codificación inteligente para una
gran variedad de otros lenguajes como SQL, HTML, JavaScript, etc., (Hildalgo,
2017).
Para optimizar el flujo de trabajo, el IDE permite a los usuarios organizar un
diseño para tener más espacio en la pantalla, porque los controles auxiliares
como las barras de herramientas y las ventanas están ocultos. Analiza el código
y busca conexiones entre símbolos de entre todos los archivos del proyecto e
idiomas, (Hildalgo, 2017).
1.3.5 JCreator
JCreator es un entorno de desarrollo integrado con lenguaje java en entorno
Windows. Es un producto comercial de la compañía Xinox Software. Existen dos
ediciones de este software, una gratuita, llamada LE y otra de pago llamada Pro,
que añade complementos de comandos, plantillas, depuración y soporte al
control de versiones con CVS,(Álvarez, 2018).
Ofrece una variedad de funcionalidades como la administración de proyectos,
modelos de proyecto, conclusión automática de código, interfaz de depuración,
editor con resaltado de sintaxis, asistentes y una interfaz de usuario totalmente
personalizable,(Álvarez, 2018).
Con JCreator es posible compilar directamente o ejecutar el programa Java sin
necesidad de activar el documento principal en primer plano. Este encuentra
automáticamente el archivo con el método principal e inicia la herramienta. Está
escrito completamente en C++, lo que hace que sea rápido y eficiente,(Álvarez,
2018).
15
Conclusiones del capítulo
En el Hospital Universitario Clínico-Quirúrgico Arnaldo Milián Castro la gestión
de la información clínica de los pacientes que ingresan a la sala de Cardiología,
a pesar de contar con el apoyo de una base de datos Access, tiene limitaciones,
y el personal médico necesita mayores posibilidades de gestión de la información
clínica. Existen varios softwares utilizados para gestionar la información clínica,
pero algunos de estos son privativos, otros necesitan erogación de fondos por
parte del hospital, y ninguno de estos recoge los datos cardiológicos específicos
para ser procesados como se necesita en la sala de Cardiología. Para la
elaboración de este sistema se han valorado algunas tecnologías de desarrollo
de aplicaciones de escritorio, debido a que los especialistas solicitan un sistema
con acceso desde la sala. Para su desarrollo se selecciona la herramienta
NetBeans a causa de ser libre y por la experiencia de trabajo con esta del
personal de desarrollo.
16
Capítulo II. Modelo del negocio y requisitos del
sistema
En este capítulo se caracteriza el negocio, la gestión de los datos clínicos del
paciente en la sala de Cardiología, exponiendo las actividades fundamentales
que se desarrollan. Asimismo, se exponen las reglas que surgen del análisis del
negocio. Se da a conocer el modelo de casos de uso del negocio y los requisitos
que debe cumplir el sistema. Se realiza una estimación del esfuerzo para el
desarrollo del software a través del método de estimación basado en caso de
uso.
2.1 Modelado de negocio
En la sala de Cardiología del Hospital Universitario Clínico-Quirúrgico “Arnaldo
Milián Castro” se identifican seis procesos del negocio:
La entrada del paciente a la sala: El personal médico verifica sus datos clínicos:
número de historia clínica, edad, sexo, raza, nacionalidad, provincia y municipio
en caso de ser cubano.
Verificación del diagnóstico: A partir de ese momento se comienzan a realizar
las acciones e investigaciones de su caso apoyados en los antecedentes
patológicos personales presentados y tratamientos anteriores, si existen, para
verificar si el diagnóstico actual coincide con el diagnóstico indicado en admisión.
Indicar el tratamiento: El médico indica el tratamiento que debe cumplir paciente
para recuperarse de la afección cardiológica.
Confeccionar modelo de historia clínica general: Una vez verificados los datos
generales del paciente, el diagnóstico, e indicado el tratamiento, se confecciona
el modelo de historia clínica del paciente.
Egreso del paciente: Cuando el paciente esté recuperado y no sea necesario su
permanencia en el hospital se le realiza el egreso al mismo.
17
Depurar modelo de historia clínica: Se tiene en cuenta que, si un paciente no
ingresa a los servicios cardiológicos en un período de cinco años, se depura la
historia clínica.
Actualmente, los datos generales y clínicos de los pacientes que transitan por la
sala son almacenados en una base de datos de formato Access. Dicha base de
datos presenta una serie de características que dificulta el trabajo del personal
médico, ellas son:
La interfaz gráfica no es óptima para la gestión de los datos del paciente,
puesto que el personal médico trabaja en la vista de edición de la
herramienta Access de Office, y no en un ambiente acondicionado para
ello.
Existe diversidad de terminologías para referirse a un mismo elemento.
Existen caracteres extraños en los datos almacenados en la base de
datos.
Las tablas almacenadas no cuentan con una integridad referencial, se
encuentran aisladas.
La seguridad de la base de datos es nula. Los datos se encuentran
expuestos a cualquier cambio que puede ser realizado por cualquier
persona.
Es necesario considerar una serie de reglas del negocio. Estas son aquellas
que se usan para operar un negocio, son las guías que determinan cómo se lleva
el día a día de las operaciones. Atendiendo al proceso de negocio, significan un
conjunto de requerimientos asociados con los procesos, que están o no
formalizados en una gramática por algún tipo de mecanismo. Asimismo,
orientadas a las bases de datos, pueden ser un requerimiento específico que se
satisface mediante la definición de alguna característica de los datos, que
expresará en los valores posibles de un determinado campo, (Msaffirio, 2017).
Según (Castillo, 2014) se proponen varias sintaxis que responden a una serie de
clasificaciones para representar las reglas del negocio, un conjunto de
categorías de reglas según el modelo de los datos. Ellas son: reglas de
restricción, reglas de cómputo, reglas de notificación, y reglas de clasificación.
Atendiendo a lo anterior se recogen cuatro reglas del negocio de tipo restricción:
18
1. Un paciente puede ingresar a los servicios cardiológicos del Hospital
Universitario Clínico-Quirúrgico “Arnaldo Milián Castro” solo si tiene los 18
años cumplidos.
2. Un paciente puede ingresar a la sala de Cardiología del Hospital
Universitario Clínico-Quirúrgico “Arnaldo Milián Castro” solo si la patología
presentada está relacionada con una afección cardiológica.
3. Un paciente puede presentar un tratamiento solo si presenta al menos un
diagnóstico.
4. Un paciente no puede presentar un número de diagnósticos nulo.
Como actor del negocio se reconoce al paciente, eje fundamental y principal
beneficiado con los procesos de negocio que se realizan en la sala.
Teniendo en cuenta la descripción del negocio y las actividades que se realizan
en el mismo, se obtiene el siguiente diagrama de casos de uso del negocio el
cual se muestra en la figura 1, este, muestra el entorno de la sala de Cardiología
del Hospital:
Fig. 1. Diagrama de casos de uso del negocio obtenido.
La realización de cada caso de uso está acompañada por varios elementos que
están involucrados en la ejecución del mismo y las relaciones entre ellos que son
19
requeridas para hacer el trabajo. Ellos son los trabajadores y las entidades del
negocio, (Lorenzo, 2016a).
Un trabajador del negocio es una abstracción de un humano o software que
representa un rol dentro del desarrollo de una realización de un caso de uso del
negocio, (Lorenzo, 2016b). Se reconocen varios trabajadores del negocio:
Personal médico: Se encarga de verificar la validez de los datos generales y
clínicos de los pacientes ingresados en la sala, verifica el diagnóstico realizado
en admisión e indica el tratamiento.
Jefe de servicios: Persona que está al frente de la actividad cardiológica en el
hospital.
Por su parte, una entidad del negocio representa una pieza significativa de
información que es manipulada por los trabajadores y/o los actores del negocio.
Se reconoce como una entidad del negocio el modelo de historia clínica que es
usado por el personal médico para recoger los datos clínicos de los pacientes
que ingresan a la sala.
Los casos de uso del negocio definen qué es lo que debe suceder en el negocio
cuando este se realiza, describe la ejecución de una secuencia de acciones que
produce un resultado de valor para un actor del negocio en particular, en este
caso el paciente, (Lorenzo, 2016a). Los casos de uso del negocio más
importantes son:
Se muestra la especificación del caso de uso del negocio Verificar datos de
paciente en la tabla 1:
Actor del negocio Paciente
Trabajador del negocio Personal médico
Flujo de eventos
Acción del actor Respuesta del proceso de negocio
1. El paciente llega a la sala de
Cardiología procedente de
admisión.
2. El personal médico verifica los
datos generales llegados de
admisión.
20
Tabla 1. Especificación del caso de uso del negocio Verificar datos de paciente.
Observaciones: Cuando el paciente llega a la sala de Cardiología procedente
de admisión, ya ingresa con los datos generales completos y con un diagnóstico
inicial prematuro en el modelo de historia clínica.
Se muestra la especificación el caso de uso del negocio Verificar diagnóstico en
la tabla 2:
Actor del negocio Paciente
Trabajador del negocio Personal médico
Flujo de eventos
Acción del actor Respuesta del proceso de negocio
1. El personal médico realiza
pruebas e investigaciones al
paciente para determinar si el
diagnóstico indicado en
admisión fue correcto.
2. El paciente responde a las
preguntas que le hace el
personal médico.
3. El personal médico incorpora
al modelo de historia clínica el
diagnóstico realizado.
Tabla 2. Especificación del caso de uso del negocio Verificar diagnóstico.
Se muestra la especificación del caso de uso del negocio Confeccionar historia
clínica general en la tabla 3:
Actor del negocio Paciente
Trabajador del negocio Personal médico
Flujo de eventos
Acción del actor Respuesta del proceso de negocio
1. El personal médico
confecciona una historia
clínica general una vez que se
haya hecho el diagnóstico y se
21
haya indicado el tratamiento al
paciente.
2. Se notifica al paciente la
elaboración del nuevo modelo
de historia clínica.
Tabla 3. Especificación del caso de uso del negocio Confeccionar historia clínica
general.
Se obtienen las especificaciones de los casos de uso del negocio Indicar
tratamiento en el Anexo 1, Realizar egreso de paciente en el Anexo 2 y Depurar
historia clínica en el Anexo 3.
2.2 Requisitos del sistema
El sistema a desarrollar lleva consigo la satisfacción de una serie de requisitos
funcionales. Ellos son una condición y/o exigencia que debe cumplir el sistema
a implementar a petición del usuario o cliente, (Lorenzo, 2016c). Se recogen los
siguientes requisitos que debe cumplir el software:
Requisito funcional 1: Gestionar los datos generales y clínicos de pacientes
almacenados en el sistema. Este requisito incluye agregar, modificar, consultar
y eliminar los datos generales y clínicos de pacientes.
Requisito funcional 2: Desactivar pacientes. Este requisito no significa eliminar
los datos generales y clínicos de un paciente, los mismos deben estar
almacenados en el sistema para un futuro trabajo estadístico. El paciente está
en el sistema, pero su historia clínica no está vigente.
Requisito funcional 3: Gestionar la información de los usuarios que pueden
operar con el sistema. Este requisito incluye agregar, modificar, consultar y
eliminar la información de los usuarios.
Requisito funcional 4: Gestionar la información del catálogo de antecedentes
patológicos personales(APP).
Requisito funcional 5: Gestionar la información del catálogo de tratamientos
Requisito funcional 6: Buscar pacientes por proceso de selección de criterios
establecidos por los especialistas médicos.
22
Requisito funcional 7: Exportar los resultados de la búsqueda de pacientes a
diferentes formatos (PDF y xls).
De igual manera se pueden identificar requisitos no funcionales. Estos son
una restricción sobre la operación del sistema. Se identifican los siguientes:
Requisito no funcional 1: El sistema debe estar disponible todo el tiempo.
Requisito no funcional 2: Se debe contar como mínimo 500MB de espacio en
disco para la instalación de los programas necesarios.
Los actores del sistema son toda entidad externa al mismo que guarda una
relación con este, y que le demanda una funcionalidad. Esto incluye a los
operadores humanos, pero también incluye a todos los sistemas externos. En el
caso de los seres humanos, estos se pueden ver como definiciones de rol, por
lo que un mismo individuo puede corresponder como uno o más actores,
(Gutiérrez, 2018).
Como actores del sistema se encuentran:
Personal Médico: Es la persona encargada de realizar la gestión de la
información general y clínica del paciente que ingresa en la sala. Agrega,
modifica y consulta los datos, así como es el encargado de desactivar a un
paciente. Cuenta con la posibilidad de realizar listados de datos generales y
clínicos de pacientes e imprimir la información para posteriores informes.
Personal médico espectador: Se encarga de observar la información que existe
en el sistema de los pacientes. Cuenta con la posibilidad de realizar búsquedas
por distintos aspectos, ya sean datos clínicos como generales, así como la
impresión de los mismos. Su principal misión es la búsqueda de errores en los
datos.
Jefe de servicios: Realiza operaciones similares al personal médico. Es el
encargado de gestionar la información de los usuarios que pueden operar con el
sistema. De igual manera, gestiona los catálogos de antecedentes patológicos
personales, diagnósticos y/o tratamientos.
23
Teniendo en cuenta los requisitos anteriores se puede obtener el diagrama de
casos de uso del sistema que se representa en la figura 2:
Fig. 2. Diagrama de casos de uso del sistema obtenido.
Los casos de uso del sistema responden a qué se quiere que haga el producto.
Los más significativos son:
Se muestra la especificación del caso de uso del sistema Añadir información del
paciente en la tabla 4:
Actores Personal médico
Propósito Agregar la información general y
clínica de un paciente al sistema.
Casos de uso del negocio asociado Caso de uso del negocio Registrar
datos generales de paciente
24
Caso de uso del negocio Registrar
datos clínicos de paciente
Caso de uso del sistema
precondición
Listar paciente
Flujo de eventos
Acción del actor Respuesta del sistema
1. El personal médico selecciona
la opción Gestión de
pacientes.
2. El sistema muestra la pantalla
de gestionar los pacientes.
3. El personal médico selecciona
la opción Agregar
4. El sistema muestra el
formulario para agregar la
información general y clínica
del paciente.
5. El personal médico llena los
campos necesarios en el
formulario.
6. El sistema comprueba la
información insertada por el
personal médico. Si está
correcta se guarda en la base
de datos y se notifica el fin del
proceso.
Flujo alterno
6. El sistema comprueba la
información insertada por el
personal médico. Si no está
correcta, se le notifica del
error.
7. Se repiten los pasos 5 y 6.
Tabla 4. Especificación del caso de uso del sistema Añadir información de
paciente.
25
Se muestra la especificación del caso de uso del sistema Modificar información
de paciente en la tabla 5:
Actores Personal médico
Propósito Modificar la información general y
clínica de un paciente existente en el
sistema.
Casos de uso del negocio asociado -
Caso de uso del sistema
precondición
Listar pacientes
Flujo de eventos
Acción del actor Respuesta del sistema
7. El personal médico selecciona
la opción Gestión de
pacientes.
8. El sistema muestra la pantalla
de gestionar los pacientes.
9. El personal médico selecciona
la opción Modificar
10. El sistema busca el paciente
en la base de datos por su
llave principal. Muestra un
formulario con los datos del
mismo ya insertados.
11. El personal médico actualiza
los campos deseados en el
formulario.
12. El sistema comprueba la
información insertada por el
personal médico. Si está
correcta se guarda en la base
de datos y se notifica el fin del
proceso.
Flujo alterno
26
12. El sistema comprueba la
información insertada por el
personal médico. Si no está
correcta, se notifica del error.
13. Se repiten los pasos 11 y 12.
Tabla 5. Especificación del caso de uso del sistema Modificar información de
paciente.
Se muestra la especificación del caso de uso del sistema Desactivar paciente en
la figura 6:
Actores Personal médico
Propósito Desactivar a un paciente. Esto es
retirarle el número de historia clínica,
pero mantener sus datos generales y
clínicos en el sistema para posteriores
investigaciones.
Casos de uso del negocio asociado Caso de uso del negocio Depurar
historia clínica
Caso de uso del sistema
precondición
Listar pacientes
Flujo de eventos
Acción del actor Respuesta del sistema
13. El personal médico selecciona
la opción Gestión de
pacientes.
14. El sistema muestra la pantalla
de gestionar los pacientes.
15. El personal médico selecciona
la opción Eliminar
16. El sistema busca el paciente
en la base de datos por su
llave principal y lo elimina. Se
le notifica al personal médico
el fin del proceso
Tabla 6. Especificación del caso de uso del sistema Desactivar paciente.
27
2.3 Análisis de factibilidad.
La estimación es una actividad importante que no debe llevarse a cabo de forma
descuidada. Existen técnicas útiles para la estimación de costes y tiempos. Es la
base de todas las demás actividades de planificación del proyecto y sirve como
guía para una buena ingeniería del software,(Fernández, 2018).
El objetivo de la estimación es predecir las variables involucradas en el proyecto
con cierto grado de certeza. Aporta una predicción de algún indicador importante
para la gestión de proyectos de software: tiempo, esfuerzo, cantidad de defectos
esperados, entre otros, sin dejar de tener en cuenta que la incertidumbre y el
riesgo son elementos inherentes,(Fernández, 2018).
Son muchos los métodos de estimación del esfuerzo que existen en la
actualidad: SLIM, COCOMO II, Juicio Experto, Analogía, algunos basados en
técnicas estadísticas e Inteligencia Artificial, (Fernández, 2018).
En este epígrafe se explican las características fundamentales del método de
estimación basado en casos de uso. También se realiza la estimación del
producto basado en este método.
2.3.1 Estimación basada en Casos de Uso
La estimación basada en casos de uso tiene como objetivo fundamental estimar
las horas necesarias para ejecutar un conjunto de casos de uso. Se necesita
predecir cuánto tiempo llevará el desarrollo del software y cuántas personas se
requieren para realizarlo. Para ello, es necesario cuantificar la complejidad del
sistema y el tiempo necesario para producir una unidad de complejidad,
(Fernández, 2018).
Esta estimación es bastante imprecisa debido principalmente a la escasa
información que se tiene sobre el software al principio de un proyecto, pero
permite obtener una idea del esfuerzo necesario para llevar adelante el mismo,
y puede ser refinada a medida que se obtenga más, (Fernández, 2018).
Un caso de uso por sí solo no permite efectuar una estimación de esfuerzos ni
de tiempos, los casos de uso son solamente herramientas para el análisis. La
28
idea fundamental es predecir el tamaño del software a partir de los
requerimientos de los casos de uso, (Fernández, 2018).
2.3.1 Costos del desarrollo
El primer paso para calcular el costo del proyecto es el cálculo de Puntos de
Casos de Uso sin Ajustar (UUCP) a partir de la siguiente fórmula:
UUCP = UAW + UUCW
Donde:
UAW: Factor de Peso de los actores sin ajustar,
UUCW: Factor de Peso de los Casos de uso sin ajustar.
Para determinar el UAW se tiene en cuenta un análisis de actores presentes en
el sistema y la complejidad de cada uno de ellos. La complejidad de los actores
se establece, teniendo en cuenta en primer lugar, si se trata de una persona o
de otro sistema, y, en segundo lugar, la forma en que el actor interactúa con el
sistema, (Fernández, 2018). La determinación del UAW se muestra en la tabla
7.
Tipo de
actor
Descripción Factor
de peso
Número
de
actores
Resultado
Simple Otro sistema que interactúa
con el sistema a desarrollar
mediante una interfaz de
programación (API,
Aplication Programming
Interface).
1 0 0
Promedio Otro sistema que interactúa
con el sistema a desarrollar
mediante un protocolo o una
interfaz basada en texto.
2 0 0
29
Complejo Una persona que interactúa
con el sistema mediante una
interfaz gráfica.
3 3 9
Total 9
Tabla 7. Determinación del UAW.
Por tanto, el resultado obtenido es UAW = 9.
Para la determinación del UUCW, se calcula mediante un análisis de la cantidad
de casos de uso presentes en el sistema y la complejidad de cada uno de ellos.
La complejidad de los casos de uso se establece teniendo en cuenta la cantidad
de transacciones efectuadas en el mismo, donde una transacción se entiende
como una secuencia de actividades atómicas, (Fernández, 2018). La
determinación del UUCW se muestra en la tabla 8.
Tipo de caso
de uso
Descripción Factor
de peso
Número de
casos de uso
Resultado
Simple 1-3 Transacciones 5 17 85
Promedio 4-7 Transacciones 10 3 30
Complejo Mayor de 8
Transacciones
15 0 0
Total 115
Tabla 8. Determinación del UUCW.
Como resultado se obtiene que UUCW = 115.
Calculando:
UUCP = 9 + 115
UUCP = 124
Seguidamente se deben calcular los Puntos de casos de uso ajustados (UCP),
para ello se utiliza la siguiente ecuación:
UCP = UUCP*TCF*EF, donde:
TCF: Factor de complejidad técnica,
EF: Factor de ambiente.
30
El factor de complejidad técnica se calcula mediante la cuantificación de un
conjunto de factores que determinan la complejidad técnica del sistema. Cada
uno de los factores se cuantifica con un valor de 0 a 5, donde 0 significa un aporte
irrelevante y 5 un aporte muy importante, (Fernández, 2018). El resultado de la
determinación del factor de complejidad técnica se muestra en la tabla 9.
Número
de
factores
Descripción Peso Valor Resultado Comentario
T1 Sistema
Distribuido
2 1 2 El sistema cuenta
con una conexión
remota a pesar de
que es una
aplicación de tipo
escritorio, por lo
que posee cierto
nivel de
distribución.
T2 Tiempo de
respuesta
1 1 1 El tiempo de
respuesta
respalda los
objetivos que se
persiguen con el
proyecto, por lo
que es el
adecuado.
T3 Eficiencia por
el usuario
1 3 3 Algunos roles
necesitan estar
relacionados con
el sistema para su
mejor
funcionamiento.
T4 Proceso
interno
complejo
1 3 3 El sistema no
posee cálculos
complejos,
31
aunque
proporciona una
serie de datos
lógicos que
necesitan un nivel
medio de
conocimiento
para lograr su
correcta
comprensión.
T5 Reusabilidad 1 5 5 Sí es un objetivo
esencial reutilizar
el código.
T6 Facilidad de
instalación
0.5 3 1.5 La complejidad de
instalación en
promedio debido
a que es
necesario la
instalación de
varios programas
como gestor de
bases de datos.
T7 Facilidad de
uso
0.5 5 2.5 El sistema debe
ser fácil de usar.
T8 Portabilidad 2 5 10 El sistema está
diseñado para
que sea usado en
situaciones
similares en salas
de Cardiología de
otros centros
hospitalarios.
T9 Facilidad de
cambio
1 5 5 El sistema está
estructurado para
que los cambios
32
realizados afecten
lo menos posible
las
funcionalidades
del sistema.
T10 Concurrencia 1 1 1 La concurrencia
no tiene gran
importancia
T11 Objetivos
especiales de
seguridad
1 5 5 La seguridad del
sistema es un
tema bastante
controlado, ya
que el sistema
permite que un
usuario realice las
funcionalidades
correspondientes
a su rol.
T12 Acceso directo
a terceras
partes
1 0 0 La aplicación no
es accesible a
cualquier usuario
T13 Facilidades
especiales de
entrenamiento
a usuarios
finales
1 1 1 No se hace
necesario el
entrenamiento de
los usuarios
finales, debido a
la facilidad de uso
que presenta el
sistema, pero se
debe incluir un
manual de
usuario para
garantizar la
correcta
33
usabilidad de
dicho sistema.
Total
factor
40
Tabla 9. Determinación del TCF.
El factor de complejidad técnica se calcula mediante la siguiente ecuación:
TCF = 0.6 + 0.01 * ∑ (Pesoi * valor asignado)
TCF = 0.6 + 0.01 * 40
TCF = 1
Para determinar el Factor Ambiente son determinantes las habilidades y en
entrenamiento del grupo involucrado en el desarrollo. El procedimiento de la
determinación del Factor Ambiente se muestra en la tabla 10.
Número
del
factor
Descripción Peso Valor Fact
or
Comentario
E1 Familiaridad
con el modelo
del proyecto
usado.
1.5 3 4.5 Se está
familiarizand
o con el
modelo del
proyecto.
E2 Experiencia en
la aplicación.
0.5 4 2 No es una
aplicación
que requiera
mucha
experiencia
E3 Experiencia en
la
programación.
1 4 4 Se considera
cierto grado
de
experiencia
en la
programación
, debido que
34
esta es la que
se ha
estudiado.
E4 Capacidad del
analista líder.
0.5 4 2 El analista
líder a pesar
de ser una
única
persona tiene
una
capacidad
promedio.
E5 Motivación 1 5 5 Alta
E6 Estabilidad de
los
requerimientos.
2 4 8 Aunque el
sistema se
encuentra
sujeto a
cambios, el
mismo brinda
las
funcionalidad
es esenciales
que dan
cumplimiento
a los
objetivos que
iniciaron su
realización.
E7 Personal media
jornada.
-1 0 0 Se trabaja a
tiempo
completo.
35
E8 Dificultad del
lenguaje de
programación.
-1 3 -3 Como el
lenguaje
empleado es
Java y este
ofrece
grandes
facilidades y
ventajas, se
considera
una dificultad
media su
empleo.
Total 22.5
Tabla 10. Determinación del factor ambiente.
El factor ambiente se calcula mediante la siguiente ecuación:
EF = 1.4 - 0.03 * ∑ (Pesoi * Valor asignado)
EF = 1.4 - 0.03 * 22.5
EF = 0.725
Sustituyendo en la ecuación de cálculo de casos de uso ajustado:
UCP = 124 * 1 * 0.725
UCP = 89.9
Igualmente, es necesario calcular el esfuerzo en horas – hombre (E), el cual
viene dado por:
E = UCP * CF, donde:
CF: Factor de conversión (20 Horas – hombre por defecto)
E = 89.9 * 20
E = 1798 Horas - hombre
Para una estimación más exacta de la duración del proyecto, se hace necesario
agregar a la estimación del esfuerzo obtenida por los puntos de casos de uso,
las estimaciones de esfuerzo de las restantes actividades que se llevan a cabo
36
durante el desarrollo del software,(Fernández, 2018). Los porcentajes de la
estimación del esfuerzo se muestran en la tabla 11.
Actividad Porcentaje
Análisis 10.00%
Diseño 20.00%
Programación 40.00%
Pruebas 15.00%
Sobrecarga (otras actividades) 15.00%
Tabla 11. Estimación del esfuerzo realizado en porciento.
Con este criterio y tomando como entrada la estimación de tiempo calculada a
partir de los puntos de casos de uso, se pueden calcular las demás estimaciones
para obtener la duración total del proyecto. El desglose de horas – hombre que
representan el esfuerzo realizado se muestra en la tabla 12.
Actividad Horas - hombre
Análisis 179.8
Diseño 359.6
Programación 719.2
Pruebas 269.7
Sobrecarga (otras actividades) 269.7
Total 1798
Tabla 12. Estimación del esfuerzo realizado en Horas – hombre.
Cálculo del esfuerzo total:
ETotal = 1798 Horas – hombre
Cálculo del tiempo de desarrollo:
TDesarrollo = ETotal/CHTotal donde:
CHTotal: Cantidad de hombres.
TDesarrollo = 1798/1
TDesarrollo = 1798 horas
Considerando que se trabajan 8 horas diarias:
TDesarrollo = 1798/8
37
TDesarrollo = 225 días aproximadamente.
Cálculo de costo:
Costo Total = ETotal * 2 * TH, donde:
TH: Tarifa horaria ($2.40)
Costo Total 1798 * 2 * 2.40
Costo Total = $8630.4
A partir del resultado obtenido se puede llegar a la conclusión de que es factible
y económico la realización del producto. El mismo implicará un esfuerzo total de
1798 Horas – hombre, para un tiempo de desarrollo de 225 días
aproximadamente, se contará con un hombre para su realización, lo que implica
un costo de $8630.4, para una tarifa horaria de $2.40. El trabajo no tendrá
inversión alguna para el Hospital, por lo que representa un ahorro en esa
cantidad.
Conclusiones del capítulo
El diagrama de casos de uso del negocio que se obtiene influye en la decisión
de elegir cuáles de los procesos que se realizan en la sala de Cardiología deben
ser automatizados. Los requisitos del sistema identificados sirven como guía
para la realización del mismo. Asimismo, la estimación del esfuerzo arroja que sí
es factible la realización del sistema, puesto que el tiempo de realización
estimado y el costo así lo confirman.
38
Capítulo III. Descripción de la propuesta de
solución.
En este capítulo se expone la arquitectura del sistema desde sus diferentes
visiones: la vista del análisis, vista de diseño, vista de implementación y vista de
despliegue. Asimismo, se dan a conocer las características fundamentales en la
etapa de desarrollo del producto basado apoyando en el patrón de diseño
Modelo – Vista – Controlador. Se exponen características medulares del
diagrama entidad relación obtenido para el desarrollo del producto.
3.1 Arquitectura del sistema
La arquitectura de software se refiere a la estructuración del sistema que,
idealmente, se crea en etapas tempranas del desarrollo. Esta estructuración
representa un diseño de alto nivel del sistema que tiene dos propósitos primarios:
satisfacer los atributos de calidad: desempeño, seguridad, etc., y servir como
guía en el desarrollo. No crear diseños desde una etapa temprana del desarrollo
puede influir negativamente en que el producto final satisfaga las necesidades
de los clientes, (Cervantes, 2017).
La arquitectura de software se representa en cuatro fases, ellas son: Vista de
análisis, donde se captura el análisis de los requerimientos del sistema, vista del
diseño, donde se encuentra el diseño del sistema a implementar y la vista de
implementación, mostrando la implementación del sistema, (Eeles, 2017).
En este epígrafe se hace énfasis en cada una de sus etapas, exponiendo los
elementos esenciales de cada una de ellas que conllevan a la realización de
distintos tipos de diagramas y herramientas a obtener. Para esto, se sigue una
filosofía de proceso de desarrollo de software RUP, pero se personaliza el
proceso, pues se reduce en cantidad y especificaciones de los artefactos a
desarrollar.
3.1.1 Vista de análisis
La realización del análisis da como resultado un modelo del sistema que
pretende ser correcto, completo, consistente y verificable. El objetivo del mismo
39
es conseguir una comprensión más precisa de los requisitos y una descripción
de los mismos que sea fácil de mantener y que ayude a estructurar el sistema
entero, incluyendo su arquitectura, (Lorenzo, 2017).
Para el análisis es necesario la confección de las clases del análisis. Esta
representa una abstracción de una o varias clases y/o subsistemas del diseño
del sistema. Se centra en el tratamiento de los requisitos funcionales y pospone
los no funcionales, denominándolos requisitos especiales, hasta llegar a las
actividades de diseño e implementación siguientes. Contiene y define atributos
reconocidos por el dominio del sistema. Siempre encajan en uno de los tres
estereotipos básicos: de interfaz o frontera, de control y de entidad, (Lorenzo,
2017).
Las clases de interfaz son los puntos por los cuales algún actor externo puede
interactuar con el sistema. Representan abstracciones de ventanas, formularios,
paneles, distintos tipos de interfaces, sensores, API, etc. No es necesario que
estas clases describan cómo se ejecuta físicamente la interacción, (Lorenzo,
2017).
La clase entidad se emplean para modelar los conceptos, cuyo estado debe ser
conservado más allá de la ejecución del sistema. Los objetos que son instancias
de esta clase se pueden almacenar y recuperar con posterioridad. Tienen como
principal característica ser contenedoras de datos, (Lorenzo, 2017).
Las clases de control se crean con el objetivo de coordinar y llevar el control de
la secuencia de eventos necesarios para completar cada interacción de un actor
con el sistema. Se estila emplear una clase controladora para cada caso de uso.
Estas determinan y garantizan el cumplimiento de las reglas del negocio
Teniendo en cuenta lo anterior se puede conformar el diagrama de clases del
análisis que aparece en la figura 3 para los casos de uso relacionados con la
gestión de pacientes.
40
Fig. 3. Diagrama de clases del análisis obtenido para casos de uso del sistema
asociados a la gestión de pacientes.
En el mismo se observa una clase de tipo interfaz Inicio, la cual interactúa en un
primer momento con el personal médico, desde donde se puede acceder a la
clase de interfaz GestionPaciente. Desde este lugar el personal médico tiene la
posibilidad de realizar acciones como agregar los datos clínicos de un paciente,
modificarlos, eliminarlos y/o desactivar un paciente. En caso de que la opción
elegida sea agregar o modificar un paciente, el usuario interactúa con las
interfaces de Agregar paciente o Modificar paciente correspondiente. Toda la
actividad es manejada por la clase controladora ControladorPaciente, la cual
interactúa con la clase de tipo entidad Paciente, encargada del manejo de datos.
De manera similar sucede con la gestión de los usuarios, la gestión de los
antecedentes patológicos personales y la gestión de los tratamientos.
También es preciso obtener en el análisis el diagrama de colaboración o
comunicación. Estos contienen instancias de objetos y actores, junto con los
enlaces y mensajes que describen cómo ellos se relacionan e interactúan.
Describe qué es lo que tiene lugar en los objetos participantes en términos de
cómo los objetos se comunican enviándose mensajes unos a otros. Para cada
variante de flujo de eventos de caso de uso se puede obtener un diagrama de
comunicación, (Lorenzo, 2017).
Se obtienen los diagramas de colaboración para los casos de uso del sistema
más significativos: Añadir información de paciente en la figura 4, Modificar
información de paciente en la figura 5, y Desactivar paciente en la figura 6.
41
Fig. 4 Diagrama de colaboración para el caso de uso del sistema Añadir
información de paciente obtenido.
El Personal Médico interactúa con la clase de tipo frontera Inicio, la cual activa
la interfaz de usuario GestionPaciente. El Personal Médico selecciona la opción
Agregar. La Interfaz de usuario GestionPaciente activa la interfaz de usuario
AgregarPaciente, donde el usuario llena la información del nuevo paciente.
Hecho esto y seleccionada la opción Agregar, el sistema realiza un llamado al
método agregarPaciente en la clase controladora ControladoraPaciente, la cual,
a su vez, guarda la información en la base de datos.
42
Fig. 5 Diagrama de colaboración obtenido para el caso de uso del sistema
Modificar información de paciente.
Para este caso de uso del sistema, el personal médico, desde la clase de tipo
frontera Inicio selecciona la opción Gestión de paciente, la cual activa la interfaz
GestionPaciente, una vez aquí el usuario selecciona la opción Modificar. Esto
activa los métodos correspondientes para buscar al paciente seleccionado en la
base de datos, activando la interfaz de usuario Modificar paciente, donde se
completa cada campo de datos con la información relacionada con el paciente.
El usuario modifica los datos deseados y selecciona la opción Confirmar. Esta
acción activa el método actualizarPaciente, el cual, modifica la información
existente relacionada con el paciente.
43
Fig. 6 Diagrama de colaboración obtenido para el caso de uso del sistema
Desactivar paciente.
El personal médico interactúa con la clase de tipo frontera Inicio, desde donde
selecciona la opción Gestionar paciente, se activa la interfaz GestionPaciente.
Desde aquí selecciona el paciente a desactivar, realizando un llamado al método
desactivarPaciente en la clase controladora ControladorPaciente, guardando los
cambios en la base de datos.
Es necesario señalar que los diagramas obtenidos que se presentan responden
al flujo principal de la realización de los casos de uso más significativos.
Otros elementos a obtener son los diagramas de secuencia. Estos son
necesarios para obtener una ilustración de las realizaciones de los casos de uso.
Ellos aclaran los roles de los objetos en el flujo, y, por consiguiente, brindan la
entrada básica para la determinación de las responsabilidades y las interfaces
de las clases. Incluye las secuencias cronológicas, pero no prioriza gráficamente
las relaciones entre los objetos. Muestran la secuencia explícita de los mensajes,
y resultan de gran utilidad cuando es preciso visualizar el orden de los mensajes
en el tiempo, (Lorenzo, 2017).
Se obtienen los diagramas de secuencia para los casos de uso del sistema
más significativos: Añadir información de paciente en la figura 7, Modificar
información de paciente en la figura 8, y Desactivar paciente en la figura 9.
44
Fig. 7 Diagrama de secuencia obtenido para el caso de uso del sistema Añadir
información de paciente.
Fig. 8 Diagrama de secuencia obtenido para el caso de uso del sistema
45
Modificar información de paciente.
Fig. 9 Diagrama de secuencia obtenido para el caso de uso del sistema
Desactivar paciente.
En todos los diagramas expuestos se puede apreciar la interacción del personal
médico, actor principal de los casos de uso del sistema más significativos, con
las clases de tipo interfaz Inicio y GestionPaciente. De igual manera de estas con
la clase de tipo controladora ControladorPaciente y manejar el flujo de
actividades hacia los datos de la clase entidad Paciente. En ello se puede
destacar el orden secuencial que presentan las actividades en la realización de
los casos de uso del sistema.
Con el objetivo de gestionar los datos de los pacientes que ingresan a la sala de
Cardiología, se diseña una base de datos relacional, a partir del diagrama
entidad – relación.
3.1.2 Vista de diseño.
Para reducir la complejidad del dominio de la aplicación se identifican partes más
pequeñas llamadas clases. Las clases del análisis pueden trasladarse a la
actividad de diseño y pueden agruparse en paquetes. Los paquetes del análisis
pueden representar una separación de intereses del análisis. Estos se crean
basándose en los requisitos funcionales y en el dominio de la aplicación o del
negocio. Los paquetes del análisis no deben basarse en requisitos no
funcionales o en el dominio de la solución, (Lorenzo, 2018).
46
Un subsistema del diseño lo constituye una forma de organizar los artefactos del
modelo de diseño en piezas más manejables. Puede contener clases del diseño,
realizaciones de casos de uso, interfaces y otros subsistemas. Puede
proporcionar interfaces que representan la funcionalidad que exportan en
términos de operaciones, (Lorenzo, 2018).
Los subsistemas pueden representar productos de softwares reutilizados que
han sido encapsulados en ellos. Pueden utilizarse los subsistemas en el modelo
de diseño para representar la integración de productos de softwares reutilizados,
(Lorenzo, 2018).
Para los casos de uso del sistema asociados a la gestión de pacientes se obtiene
el subsistema del diseño representado en la figura 10:
Fig. 10 Subsistema del diseño obtenido para casos de uso del sistema asociados
a la gestión de pacientes.
Se reduce el desarrollo del producto a varios subsistemas del diseño, uno de
ellos es el subsistema del diseño Gestión de pacientes, donde a su vez, se
encuentran los subsistemas del diseño Modelo, Vista y Controlador. Los
subsistemas del diseño restantes cumplen con el mismo tipo de modelado que
del subsistema del diseño Gestión de pacientes.
47
Los paquetes del diseño también juegan un papel importante para el desarrollo
del software. Estos son una colección de clases, relaciones, realizaciones de
casos de uso, diagramas y otros paquetes que estén de alguna forma
relacionados. A diferencia de los subsistemas del diseño, los paquetes no
ofrecen una interfaz formal, (Lorenzo, 2018).
Para casos de uso del sistema asociados con la gestión de pacientes se obtiene
el diagrama de paquetes del diseño representado en la figura 11:
Fig. 11 Diagrama de paquetes del diseño obtenido para casos de uso del sistema
asociados a la gestión de pacientes.
A partir del diagrama de paquetes obtenido en la figura 11, se obtiene el
diagrama de clases representado en la figura 12 que representa las relaciones
entre algunas clases del producto:
48
Fig. 12 Diagrama de clases para los casos de uso del sistema asociados a la
gestión de pacientes.
Una instancia de la clase Vista tiene relación con una instancia de la clase
controladora, esta a su vez con una de la clase UtilPaciente, donde se agregan
en una lista varias instancias de la clase Paciente.
3.1.3 Vista de componentes
Para desarrollar la vista de componentes es necesario obtener el diagrama de
componentes. Este proporciona una visión física de la construcción del sistema
informático, muestra la organización de los componentes de software, sus
interfaces y las dependencias entre ellos, (Cillero, 2018a).
Un componente es un módulo de software que puede ser código fuente, código
binario, un ejecutable, o una librería con una interfaz definida. Una interfaz
establece las operaciones externas de un componente, las cuales determinan
una parte del comportamiento del mismo. Además, se representan las
dependencias entre componentes o entre un componente y la interfaz de otro, o
sea, uno de ellos usa los servicios o facilidades del otro, (Cillero, 2018a).
Estos diagramas pueden incluir paquetes que permiten organizar la construcción
del sistema informático en subsistemas y que recogen aspectos prácticos
relacionados con la secuencia de compilación entre componentes, la agrupación
de elementos en librerías, (Cillero, 2018a).
49
Se obtienen los diagramas de componentes para los casos de uso del sistema
más importantes: Añadir información de paciente, Modificar información de
paciente y Desactivar paciente, en las figuras 13, 14 y 15 respectivamente.
Fig. 13 Diagrama de componentes obtenido para el caso de uso del sistema
Agregar información del paciente.
En el diagrama de componentes obtenido para el caso de uso del sistema
Agregar información del paciente, se puede apreciar que actúa un subsistema
de implementación, donde se encuentra el componente Inicio.java, del cual
depende el componente GestionPaciente.java, este a su vez, necesita
ControladorPaciente.java, al cual le da soporte UtilPaciente.java. Este
componente depende de Paciente.java, el cual es el contenedor de datos, y
ConnectionDB.java, quien se encarga de la conexión con la base de datos para
la ejecución de las consultas.
50
A su vez, el subsistema de implementación anterior, ejerce una dependencia del
subsistema de implementación Servicios, donde se encuentran las librerías
necesarias para ejecutar acciones como la conexión con la base de datos. En
otros subsistemas de implementación están presentes las librerías para exportar
datos hacia formatos como PDF y xls, de documentos Excel.
Para los casos de uso del sistema Modificar información de paciente y Desactivar
paciente se siguen modelados similares al anterior.
Fig. 14 Diagrama de componentes obtenido para el caso de uso del sistema
Modificar información de paciente.
51
Fig. 15 Diagrama de componentes obtenido para el caso de uso del sistema
Desactivar paciente.
3.1.4 Vista de despliegue
El modelo del despliegue describe la distribución física del sistema en términos
de cómo se distribuye la funcionalidad entre otros nodos de cómputo. Muestra la
configuración de los nodos de proceso en el tiempo de ejecución, los enlaces de
comunicación entre ellos y las instancias de componente, (Terrera, 2017).
El objetivo de estos diagramas es mostrar la disposición de las particiones físicas
del sistema informático y la asignación de los componentes de software a estas
particiones. Es decir, las relaciones entre los componentes de software y
hardware en el sistema a desarrollar, (Cillero, 2018b).
El modelo de despliegue consta de uno o más nodos. Los nodos son elementos
de proceso con, como mínimo, un procesador, memoria y otros dispositivos.
También puede contar con dispositivos, que son nodos estereotipados sin
capacidad de proceso. Al igual deben existir conectores entre nodos, y entre
nodos y dispositivos, (Terrera, 2017).
52
Las conexiones representan las formas de comunicación entre nodos. Cada
nodo se le asocia un subsistema de construcción que agrupa componentes de
software, permitiendo determinar la distribución de estos componentes, (Cillero,
2018b).
Este tipo de modelo también correlaciona procesos con los elementos de
proceso, permitiendo la distribución de comportamiento entre los nodos que se
deben representar, (Terrera, 2017).
Para los casos de uso del sistema asociados a la gestión de pacientes se obtiene
el modelo de despliegue de la figura 16:
Fig. 16. Modelo de despliegue para casos de uso del sistema asociados a la
gestión de pacientes.
En el modelo de despliegue que se muestra en la figura 16, se observa que se
cuenta con un cliente, donde se ejecutan los subsistemas de implementación
GestionPaciente y Servicios. El subsistema de implementación GestionPaciente
utiliza el componente ejecutable PostgreSQL.exe.
3.1.5 Vista de implementación
53
En la implementación del sistema se utiliza en lenguaje de programación Java.
Se estructura en paquetes siguiendo el patrón de diseño Modelo – Vista –
Controlador.
En la figura 17 se muestra de manera general la estructura que presenta el
producto.
Fig. 17. Estructura del software
En el paquete Modelo se encuentran las clases que apoyan al desarrollo del
sistema, las mismas son destinadas a ser contenedoras de datos. Las clases
más importantes son Paciente e Historia_Clinica, de las cuales se muestra sus
componentes:
Clase Paciente:
package Modelo.Paciente;
public class Paciente{
private String ci;
private String nombreApellidos;
private int edad;
54
private String sexo;
private String raza;
private String nacionalidad;
private String provincia;
private String municipio;
private String desactivado;
private String fechaIngreso;
private String fechaEgreso;
private String estado;
//Constructor.
//Métodos get y set.
//Método toString().
} //Fin de la clase Paciente.
Clase Historia_Clinica:
package Modelo.Historia_Clinica;
public class Historia_Clinica{
private int numero;
//Diagnósticos que solo es necesario conocer si o no.
private String Cardiopatia_Izquemica;
private String Imacest;
private String Sepsis_bolson;
private Bradicardia_Sinusal;
private String Alteraciones_Ritmo;
private String Miocarditis;
private String Endocarditis;
55
//Constructor.
//Métodos get y set.
} //Fin de la clase Historia_Clinica
Además, en este paquete se encuentran las clases necesarias para realizar las
distintas operaciones sobre la base de datos, ya sea inserción, actualización,
borrado y consulta de todos los componentes del sistema (pacientes, usuarios,
APP, tratamientos, diagnósticos, entre otros). Algunas de ellas son UtilPaciente,
UtilUsuario, UtilApp y UtilTratamiento.
En el paquete Controlador se encuentran las clases que son puentes entre los
paquetes Vista y Modelo, dentro de ellas se encuentran ControladorPaciente,
que administra todos los métodos relacionados con el caso de uso del sistema
relacionados con la gestión de pacientes, ControladorUsuario, encargada de los
casos de uso relacionados con la gestión de usuarios, y las clases
ControladorTratamiento y ControladorApp, las cuales controlan los casos de uso
relacionados con la gestión de tratamientos y APP respectivamente.
En el paquete Vista se encuentra todas las clases relacionadas con la interfaz
de usuario. Entre ellas están Inicio, Login, AgregarPaciente y Listar paciente, por
solo mencionar algunas.
El paquete DBConnection es el encargado de realizar la conexión con la base
de datos.
En otros paquetes se encuentran las clases necesarias para exportar datos a
distintos formatos. Tal es el caso de los paquetes Excel y PDF. Para dar la
posibilidad al usuario del sistema que exporte a formatos como xls (documento
MS Excel) los datos resultados de la búsqueda por criterios médicos, se utiliza
la librería jxl- 2.6.jar, donde se logra este propósito a partir de la siguiente clase:
package Excel;
import Modelo.Paciente.PacienteListar;
import java.io.DataOutputStream;
56
import java.io.File;
import java.io.FileOutputStream;
import java.util.LinkedList;
import jxl.Workbook;
import jxl.write.Label;
import jxl.write.WritableSheet;
import jxl.write.WritableWorkbook;
public class GenerateExcelFile{
public void CreateXls(File file, LinkedList<Paciente>
lista, String consulta){
try{
DataOutputStream out = new
DataOutputStream(new
FileOutputStream(file));
// Se crea un nuevo libro de MS Excel.
WritableWorkbook w =
Workbook.createWorkBook(out);
// Se crea una nueva hoja de cálculo.
WritableSheet s = w.createSheet(“Consulta”);
//Se escribe la consulta realizada.
s.addCell(new Label(0,0, consulta));
//Se pone el encabezado de los datos.
for (int i = 0; i < 12; i++){
String encabezado = llenarEncabezado(i);
s.addCell(new Label(i, 1, encabezado));
57
// El método llenarEncabezado(int indice
//devuelve el encabezado de la tabla. Ej:
//Nombre y Apellidos).
}
// Se llena la tabla.
for (int i = 0; i < lista.size(); i++){
Paciente p = lista.get(i);
for(int j = 0; j < 12; j++){
s.addCell(new Label(j, i+2,
devolverValor(j, p)));
}
}
//(j<12): 12 columnas a llenar;
//devolverValor(j, p): el método devuelve el
//atributo de p correspondiente a la columna j.
//Escribir en el libro
w.write();
//Cerrar el libro
w.close;
}catch(Exception ex){
}
} // Fin del método CreateXls().
// Método llenarEncabezado.
// Método devolverValor.
} // Fin de la clase GenerateExcelFile.
58
3.2 Modelado propuesto de la base de datos
Para lograr los datos persistentes se diseña una base de datos de tipo relacional,
a partir de un diagrama entidad – relación. En esta sección se exponen las
características fundamentales que presenta la base de datos obtenida para el
desarrollo del producto.
3.2.1 Bases de datos relacionales
Una base de datos relacional es una colección de elementos de datos
organizados en un conjunto de tablas formalmente descritas desde la que se
puede acceder a los datos,(Rouse, 2018a).
Además de ser relativamente fáciles de crear y acceder, una base de datos
relacional tiene la gran ventaja de ser fácil de extender. Después de su creación
original, una nueva categoría de datos se puede añadir sin necesidad de que
todas las aplicaciones existentes sean modificadas, (Rouse, 2018a).
Una base de datos relacional es un conjunto de tablas que contienen datos
provistos en categorías predefinidas. Cada tabla, que en ocasiones se llaman
relación, contiene una o varias categorías de datos en columnas. Cada fila
contiene una instancia única de datos para las categorías definidas por las
columnas, (Rouse, 2018a).
Al crear una base de datos relacional, se puede definir el dominio de posibles
valores de una columna de datos y restricciones adicionales que pueden
aplicarse a ese valor de dato. La definición de la misma resulta en una tabla de
metadatos o descripciones formales de las tablas, columnas, dominios y
restricciones, (Rouse, 2018a).
Según (Marín, 2018) las bases de datos relacionales cuentan con una serie de
conceptos que son fundamentales:
Atributo: Es el elemento susceptible de tomar valores, son cada una de
las columnas de la tabla.
Dominio: Es el conjunto de valores que puede tomar un atributo; este se
considera finito.
59
Tupla: Es cada uno de los elementos que contiene una instancia de la
relación; se representan por las filas.
Clave primaria: Se representa por el conjunto de atributos seleccionados
para identificar unívocamente a las tuplas de una relación.
Clave externa: Es el conjunto de atributos de una relación cuyos valores
en las tuplas deben coincidir con valores de la clave primaria de las tuplas
de otra relación.
Integridad referencial: Es que todos los valores no nulos de una clave
externa referencien valores reales de la clave referenciada.
Atendiendo a lo planteado por (Marín, 2018), el diseño de una base de datos
relacional conlleva un conjunto de fases que, para su correcta elaboración, se
deben cumplir:
1. Análisis de requisitos, donde se recaba información sobre el uso que se
desea dar a la base de datos.
2. Diseño conceptual, o creación del diagrama Entidad-Relación, aquí se
crea un esquema conceptual de la base de datos, independientemente
del gestor de bases de datos a utilizar.
3. Elección del sistema gestor de bases de datos, donde se tienen en cuenta
varios aspectos como: si es un gestor de bases de datos relacionales,
multidimensional, etc.
4. Diseño lógico, donde se crea el esquema conceptual para el modelo de
datos del gestor de bases de datos elegido.
5. Diseño físico, para crear la base de datos utilizando el lenguaje de
definición de datos del gestor seleccionado.
6. Uso y mantenimiento, para la perdurabilidad del modelado de base de
datos realizado.
3.2.2 Proceso de obtención de la base de datos propuesta
Para obtener la base de datos propuesta se siguen los pasos descritos por
(Marín, 2018). En este apartado se describen los pasos que se siguen para
obtener la base de datos propuesta para el sistema.
Análisis de requisitos
60
La base de datos relacional se desea utilizar para la gestión de la información de
los pacientes que ingresan a la sala de Cardiología del Hospital Universitario
Clínico – Quirúrgico “Arnaldo Milián Castro”. En la figura 18 se muestra el
diagrama entidad – relación obtenido.
Diseño conceptual
Fig. 18 Modelo Entidad – Relación obtenido.
En el modelo Entidad – Relación se representan las entidades con sus
relaciones. En la figura 19 se muestran las entidades que presentan relaciones
1-1:
Fig. 19 Entidades con relación 1-1.
La entidad fuerte Paciente representa al paciente que ingresa a la sala. Algunos
de sus atributos son: número de carnet de identidad, nombre y apellidos, sexo,
raza, nacionalidad, provincia, municipio, fecha de ingreso, fecha de egreso y si
está desactivado o no.
61
La entidad fuerte Historia_clinica describe el modelo de historia clínica que se
utiliza en la sala. Contiene atributos como: número de historia clínica, y algunos
diagnósticos como cardiopatía isquémica, IMASEST, sepsis del bolsón del
marcapaso, entre otros, representando la existencia de estos o no.
La relación entre estas dos entidades es de 1-1, representa que un paciente tiene
una y solo una historia clínica. A su vez, la historia clínica pertenece a un solo
paciente.
En la figura 20 se muestra un ejemplo de las entidades que presentan relaciones
m-m:
Fig. 20 Entidades con relación m-m.
La entidad fuerte App representa a los antecedentes patológicos personales
(APP), sus atributos son: identificador del tipo de APP, y tipo de APP.
La relación que une a estas dos entidades se clasifica en m-m (muchos-muchos).
Esto se evidencia en que en un modelo de historia clínica pueden estar presentes
varios APP. A su vez, una historia varios APP pueden estar en un modelo de
historia clínica. Las demás entidades siguen filosofía similar a la anterior.
Elección del sistema de bases de datos a utilizar
Un sistema de gestión de bases de datos relacionales es un programa que
permite crear, actualizar y administrar una base de datos relacional. La mayoría
de estos sistemas utilizan el lenguaje de consultas estructuradas (SQL) para
acceder a la base de datos, (Rouse, 2018b).
Existen varios productos de este tipo como lo son Oracle, DB2, Microsoft SQL
Server, PostgreSQL, entre otros. Para la elaborar la base de datos se escoge
PostgreSQL, debido a que es un producto orientado a objetos y libre,
desarrollado por una comunidad de desarrolladores que trabajan de forma
62
desinteresada, altruista, libre o apoyados por organizaciones comerciales,
(Rouse, 2018b).
Diseño lógico
El diseño lógico es el proceso de construir un esquema de la información que
usa una determinada entidad, basándose en un modelo conceptual de bases de
datos específico, independiente del gestor de bases de datos concreto. En esta
etapa se transforma el esquema conceptual en un esquema lógico que usará
estructuras de datos del modelo de base de datos que usa el gestor a usar:
modelo de red, modelo jerárquico o modelo orientado a objetos. El esquema
lógico es una fuente de información para el diseño físico, (Marín, 2018).
Se obtiene el modelo lógico de la base de datos propuesta y se muestra en la
figura 21:
Fig. 21 Diseño lógico de los datos obtenido.
Diseño físico
El diseño físico es el proceso de producir la descripción de la implementación de
la base de datos en memoria secundaria: estructuras de almacenamiento y
63
métodos de acceso que garanticen un acceso eficiente a los datos. El propósito
del diseño físico es describir cómo se va a implementar físicamente el esquema
lógico obtenido en la fase anterior.
Se obtiene el modelo físico de datos y se representa en la figura 22:
Fig. 22 Diseño físico de los datos obtenido.
Conclusiones del capítulo
En este capítulo se diseña la arquitectura del sistema teniendo en cuenta las
necesidades de los cardiólogos de la sala. Se hace la propuesta la base de
datos a utilizar, construida a través de las etapas descritas para su diseño, así
como el sistema gestor de bases de datos a emplear. Se presentan los
artefactos fundamentales de las vistas del análisis, diseño e implementación
teniendo en cuenta el proceso de desarrollo de software RUP. Los diagramas
de despliegue describen la forma en que quedará el sistema con respecto a los
64
nodos físicos. Se describen los paquetes Vista, Controlador y Modelo, que
muestran la utilización de la arquitectura Modelo – Vista – Controlador.
65
Capítulo IV. Validación de la solución propuesta
Este capítulo resume las características fundamentales de las pruebas de
software que resaltan la importancia de las mismas. Se explican las estrategias
de pruebas que se utilizan para el sistema: pruebas funcionales, de caja negra y
pruebas de caja blanca unitarias.
4.1 Pruebas y estrategias de prueba.
Las pruebas de software comprenden el conjunto de actividades que se realizan
para identificar posibles fallos de funcionamiento, configuración o usabilidad de
un programa o aplicación, por medio de pruebas sobre el comportamiento del
mismo, (Ecured, 2018b).
Los sistemas informáticos, programas y aplicaciones han crecido a grandes
niveles en cuanto a complejidad e interoperabilidad, con lo cual también se han
incrementado las posibilidades de defectos, a simple vista insignificantes, pero
que pudieran adquirir proporciones catastróficas, (Ecured, 2018b).
Dentro de los objetivos de las pruebas de software se encuentran la detección
de defectos en el software, la verificación de la integración adecuada de los
componentes, verificar que todos los requisitos se han implementado
correctamente, identificar y asegurar que los defectos encontrados se han
corregido antes de entregar el software al cliente, y diseñar casos de prueba que
sistemáticamente saquen a la luz diferentes clases de errores, haciéndolo con la
menor cantidad de tiempo y esfuerzo, (Ecured, 2018b).
Existen diversas clasificaciones de los tipos de pruebas de software, ellas son:
las pruebas funcionales, pruebas de sistemas, pruebas no funcionales, pruebas
de caja negra, pruebas de caja blanca, entre otras, (Ecured, 2018b).
Las pruebas unitarias son de muy bajo nivel, como la fuente de la aplicación.
Están compuestas de métodos y funciones individuales de las clases,
componentes o módulos que usa el software, (Pittet, 2019).
Las pruebas de integración verifican que los distintos módulos o servicios
utilizados por la aplicación funcionan bien en conjunto. Estos tipos de pruebas
son más costosos de ejecutar, ya que requieren que varias partes de la
aplicación estén en marcha, (Pittet, 2019).
66
Las pruebas funcionales se centran en los requerimientos del funcionamiento de
la aplicación. Ellas solo verifican la salida de una acción y no verifican los estados
intermedios del sistema al realizar esa acción, (Pittet, 2019).
Las pruebas de aceptación son pruebas formales ejecutadas para verificar si un
sistema satisface los requisitos empresariales. Requieren que toda la aplicación
esté en marcha y que se centre en replicar las conductas de los usuarios. Sin
embargo, también pueden ir más allá y medir el rendimiento del sistema y
rechazar cambios si no se han cumplido determinados objetivos, (Pittet, 2019).
Para comprobar el funcionamiento del sistema se ejecutan una serie de pruebas
al mismo. Resulta necesario conocer cómo funciona el mismo a un nivel bajo,
probar la veracidad de que los datos obtenidos son los certeros. Se realizan
pruebas de caja blanca para darle solución a lo anterior.
Asimismo, es necesario realizar pruebas funcionales al sistema y centrarse en la
salida que ofrece al mismo atendiendo a una serie de parámetros de entrada.
Para darle respuesta a esto se emplean las pruebas de caja negra.
Finalmente, se realizan pruebas de aceptación por los usuarios que interactúan
con el sistema, se persigue conocer si el producto cumple con las expectativas
del personal médico de la sala de Cardiología, así como saber si resulta de fácil
uso y de interfaz amigable.
4.2 Casos de pruebas.
El sistema se valida mediante la aplicación de una serie de pruebas para
determinar si el mismo tiene calidad y supera las deficiencias del sistema
existente en la sala de Cardiología. En este apartado se exponen los detalles de
cada una de las pruebas realizadas.
4.2.1 Pruebas unitarias. Pruebas de caja blanca
Las pruebas de caja blanca se realizan sobre el código fuente de la aplicación,
y, en consecuencia, en los diferentes algoritmos y estructuras de datos utilizados.
Se seleccionan distintos valores de entrada para examinar cada uno de los
posibles flujos de ejecución del programa y cerciorarse de que se devuelven los
valores de salida adecuados. Al estar basadas en una implementación concreta,
67
si esta se modifica, por regla general las pruebas también deben rediseñarse,
(Pittet, 2019).
Para la realización de este tipo de pruebas, se utiliza el framework JUnit, que
permite la realización de la ejecución de clases de manera controlada, para
poder comprobar que los métodos realizan su cometido de forma correcta,
(Pittet, 2019).
También sirve como herramienta para realizar las pruebas de regresión, que se
realizan cuando una parte del código ha sido modificada y sea necesario
comprobar que se sigue cumpliendo con todos los requisitos, (Pittet, 2019).
Para la ejecución de las pruebas al producto se utiliza la versión 4.12 del
framework JUnit, versión integrada al entorno de desarrollo NetBeans. Las
mismas se encuentran en el paquete Tests Packages.
Entre las pruebas realizadas a diferentes métodos están los siguientes:
recuperarDatosGenerales: este método hace referencia a la recuperación
de los datos generales de un paciente. La entrada del método es un
número de carnet de identidad. La salida del mismo es un objeto de tipo
Paciente, del cual se verifica si su número de carnet de identidad
corresponde con el parámetro de entrada.
public void testRecuperarDatosGenerales() throws Exception
{
System.out.println("recuperarDatosGenerales");
String ci = "17030610142";
UtilPaciente instance = new UtilPaciente();
String expResult = "17030610142";
Paciente result = instance.recuperarDatosGenerales(ci);
assertEquals(expResult, result.getCi());
}
buscarPorEdad: este método refiere la búsqueda de pacientes por una
edad específica. El método devuelve una lista de tipo String, donde están
almacenados los números de carnet de identidad de los pacientes cuya
68
edad sea la entrada por parámetros. Se comprueba que cada uno de los
números de carnet de identidad pertenecen a pacientes con la edad
especificada.
public void testBuscarPorEdad() throws Exception {
System.out.println("buscarPorEdad");
int edad = 70;
UtilPaciente instance = new UtilPaciente();
boolean expResult = true;
boolean result = true;
LinkedList<String> list =
instance.buscarPorEdad(edad);
for (int i = 0; i < list.size(); i++) {
String query = "SELECT edad FROM paciente WHERE
ci='" + list.get(i) + "'";
r = con.select(query);
while (r.next()) {
if (r.getInt("edad") != edad) {
result = false;
}// Fin if.
}// Fin while.
}// Fin for.
assertEquals(expResult, result);
} // Fin de la clase.
buscarPorEstado: el método realiza una búsqueda de pacientes por un
estado definido, ya sea vivo o fallecido, devolviendo una lista de tipo String
donde almacena los números de carnet de identidad de las personas que
cumplan con ese estado. La prueba que se le realizó al método consiste
69
en que el estado de los pacientes cuyo número de carnet de identidad se
almacena, coincida con el estado especificado previamente.
public void testBuscarPorEstado() throws Exception {
System.out.println("buscarPorEstado");
String estado = "Vivo";
UtilPaciente instance = new UtilPaciente();
boolean expResult = true;
boolean result = true;
LinkedList<String> lista =
instance.buscarPorEstado(estado);
for (int i = 0; i < lista.size(); i++) {
String query = "SELECT estado FROM paciente WHERE
ci='" + lista.get(i) + "'";
r = con.select(query);
while (r.next()) {
if (!r.getString("estado").equals(estado)) {
result = false;
}// Fin del if.
}// Fin del while
}// Fin del for.
assertEquals(expResult, result);
} // Fin de la clase
buscarPorApp: el método realiza una búsqueda por un antecedente
patológico personal específico. Devuelve una lista de tipo String, donde
se almacenan los números de carnet de identidad de los pacientes que
posean el antecedente patológico personal especificado. La prueba
realizada consiste en verificar si dentro de los antecedentes del paciente
70
al que pertenece el número de carnet de identidad se encuentra el
especificado, esto se realiza a través del identificador.
public void testBuscarPorAPP() throws Exception {
System.out.println("buscarPorAPP");
String app = "HTA-Dislipidemia";
UtilPaciente instance = new UtilPaciente();
int expResult = 2;
int result = 0;
LinkedList<String> lista = instance.buscarPorAPP(app);
LinkedList<Integer> listaNumerosHC = new
LinkedList<>();
for (int i = 0; i < lista.size(); i++) {
String query = "SELECT numero FROM
historia_clinica WHERE paciente__ci='" +
lista.get(i) + "'";
r = con.select(query);
while (r.next()) {
listaNumerosHC.add(r.getInt("numero"));
}
}
for (int i = 0; i < listaNumerosHC.size(); i++) {
String query2 = "SELECT app__idapp FROM
historia_app WHERE historia_clinica__numero='" +
listaNumerosHC.get(i) + "'";
r = con.select(query2);
while (r.next()) {
result = r.getInt("app__idapp");
71
}
}
assertEquals(expResult, result);
}// Fin de la clase.
recuperarHistoriaClinica: el método recupera la información de una
historia clínica perteneciente a un paciente, especificando su número de
carnet de identidad. La prueba realizada al método consiste en comprobar
si coinciden tanto los números de historia clínica recuperado como el
esperado.
public void testRecuperarDatosHistoriaClinica() throws
Exception {
System.out.println("recuperarHistoriaClinica");
String ci = "17030610142";
UtilPaciente instance = new UtilPaciente();
int expResult = 283108;
Historia_Clinica result =
instance.recuperarDatosHistoriaClinica(ci);
assertEquals(expResult, result.getNumero());
} // Fin de la clase.
Luego de la realización de las pruebas unitarias, los resultados fueron todo
satisfactorios, con un tiempo adecuado de ejecución, como se muestra en la
figura 23.
Fig. 23 Resultados de las pruebas unitarias realizadas.
72
4.2.2 Pruebas funcionales. Pruebas de caja negra.
Las pruebas de caja negra se centran principalmente en lo que se quiere de un
módulo o sección específica de un software, o sea, es una manera de encontrar
casos específicos den ese módulo que atiendan a su especificación. Son
dedicadas a mirar en el exterior de lo que se prueba. Se enfoca solamente en la
entrada y salida del sistema, sin preocuparse en tener conocimiento de la
estructura interna del programa, (Milián, 2018).
Se realizaron las pruebas de caja negra al sistema:
Interfaz de usuario Login:
Entrada de datos Salida del
sistema
Mensaje de la interfaz
Usuario:
gdelsol
Contraseña:
2356
(incorrecto)
Error. El
nombre de
usuario y la
contraseña
especificada
no son
correctos.
73
Usuario: gdelsol
Contraseña: 2306
Dirección IP:
192.168.24.150(dirección
IP incorrecta)
Nombre de la base de
datos: AMCardio
Error. Error en
la conexión de
red. Los datos
especificados
no son los
correctos.
Tabla 13. Casos de prueba en la interfaz de usuario Login.
Interfaz de usuario Gestión de pacientes:
Entrada de
datos
Salida del
sistema
Mensaje de la interfaz
No se
introducen
datos en el
campo
Buscar por
historia
clínica.
Error. Se
debe
insertar un
número de
historia
clínica para
realizar la
búsqueda.
74
Se
introducen
los siguientes
datos en el
campo
Buscar por
historia
clínica:
querty
Error. El
campo de
búsqueda
Buscar por
historia
clínica solo
acepta
números.
Tabla 14. Casos de prueba en la interfaz de usuario gestión de pacientes.
Interfaz de usuario Agregar paciente:
Entrada de
datos
Salida del
sistema
Mensaje de la interfaz
No se
introducen
datos.
Error. Se deben
llenar todos los
campos en
blanco, excepto
el campo Fecha
de egreso.
75
En el campo de
entrada
Nombre y
apellidos se
introduce el
siguiente dato:
Gustav0
del Sol
(Error. Cambio
de la vocal o
por el número
cero).
Error. El campo
de entrada
Nombre y
apellidos solo
acepta letras.
En el campo de
entrada Carnet
de identidad se
introduce el
siguiente dato:
qwerty
Error. El campo
de entrada
Carnet de
identidad solo
acepta
números.
En el campo de
entrada Fecha
de ingreso se
introduce el
siguiente dato:
20/09/2
01998
Error. El sistema
solo acepta el
formato de fecha
DD/MM/AAAA
76
En el campo de
entrada
Número de HC
se introduce el
siguiente dato:
123456
789
Error. El sistema
solo acepta un
número de
historia clínica
que sea menor
de seis dígitos.
En el campo de
entrada
Número de HC
se introduce el
siguiente dato:
querty
Error. El sistema
sola acepta
números en el
campo Número
de HC.
No se
seleccionan
datos en los
campos
desplegables.
Error. Para
continuar en la
inserción de un
paciente es
necesario
seleccionar la
información
requerida en los
campos
desplegables.
Tabla 15. Casos de prueba en la interfaz de usuario Agregar paciente.
Para la interfaz de usuario Modificar paciente se utilizan casos de pruebas
similares a la interfaz de usuario Agregar paciente, las pruebas realizadas arrojan
resultados parecidos, debido a la similitud entre ambas.
Interfaz de usuario Gestión de APP:
77
Entrada de
datos
Salida del
sistema
Mensaje de la interfaz
No se
introducen
datos en el
campo de
entrada APP.
Se presiona el
botón Agregar
Error. Se debe
llenar el campo
de entrada
APP para
añadir un
nuevo APP.
Tabla 16. Caso de prueba en la interfaz de usuario Gestión de APP.
Para la interfaz de usuario Gestión de tratamientos se sigue la misma filosofía
de la interfaz de usuario Gestión de APP, las pruebas realizadas arrojan
resultados idénticos, debido a la similitud entre ambas.
Interfaz de usuario Gestión de usuarios:
Entrada
de datos
Salida del
sistema
Mensaje de la interfaz
No se
introduce
n datos
en los
campos
de
entradas.
Error. Para
agregar un
usuario es
necesario
llenar la
informació
n que se
necesita
para
agregar un
nuevo
usuario.
Tabla 17. Caso de prueba en la interfaz Gestión de usuarios.
78
Interfaz de usuario Listar pacientes:
Entrada
de datos
Salida del
sistema
Mensaje de la interfaz
No se
selecciona
ninguna
casilla de
búsqueda
(casillas
Datos
generales,
Datos
clínicos)
Error. Se
debe
seleccionar
el aspecto
por donde
se desea
realizar la
búsqueda
de
pacientes.
Tabla 18. Caso de prueba en la interfaz Listar pacientes.
El sistema en la entrada de datos, de todas las ventanas de adición o
modificación de verifica la ocurrencia de errores en cada. Se garantiza un mínimo
de errores en la inserción o modificación de los datos.
4.2.3 Aplicación de encuestas de satisfacción
La encuesta de satisfacción es un estudio empírico basado en la observación
para determinar el grado de aceptación del encuestado. La encuesta suele
obtener la información a partir de un cuestionario que puede ser respondido de
manera presencial, por papel, teléfono, vía web o por correo electrónico,
(Carvajal, 2018).
Las encuestas de satisfacción suelen tener por finalidad conocer el grado de
satisfacción de un público objetivo ante un servicio ofrecido o la valoración de un
conjunto de circunstancias. Es común realizar encuestas de satisfacción de los
sistemas informáticos, de los procedimientos de una determinada organización,
entre otras, (Carvajal, 2018).
Para conocer el grado de satisfacción del personal médico que interactúan con
el sistema se aplica un cuestionario a los mismos, para ello se tienen en cuenta
79
los tres roles con los que cuenta el sistema, se eligen tres usuarios que
corresponden con estos:
Encuesta de satisfacción
Estimado usuario de AMCardio – 2019:
Para conocer el grado de satisfacción que usted le atribuye a su experiencia
de uso del sistema informático AMCardio – 2019, le pedimos que conteste el
siguiente cuestionario:
1. Usted considera que la interfaz de AMCardio - 2019 es:
__ Agradable __ No tan agradable __ Es necesario cambiarla
2. Usted considera que el Sistema Informático AMCardio – 2019 en cuanto
a la facilidad de su uso es:
__ Fácil de usar __ Cierta complejidad __ Difícil de usar
3. Para el uso del Sistema Informático AMCardio – 2019, el manual de
usuario aporta:
__ Todo el conocimiento __ Deficiente
conocimiento
__ No aporta nada
4. ¿Considera usted que sea necesario impartir clases de familiarización
para principiantes con el Sistema Informático AMCardio – 2019?
__ Si __ No
5. ¿Considera usted que la automatización del trabajo que se realiza en la
sala de Cardiología con este sistema ayuda a la agilización del mismo?
__ Si __ No __ En algunos aspectos
(¿En cuáles si y en
cuáles no?¿Por qué?)
6. ¿Considera usted que los datos que aporta el Sistema son correctos y
confiables?
__ Si __ No
80
7. ¿Afirma usted que el Sistema Informático AMCardio – 2019 cumple con
las expectativas del trabajo que se realiza en la sala de Cardiología?
__ Si __ No __ En algunos aspectos
(¿En cuáles si y en
Cuáles no?¿Por qué?)
8. Recomendaciones que desee agregar:
Tabla 19. Encuesta de satisfacción realizada a los usuarios del Sistema
Informático AMCardio -2019.
Se aplicó la encuesta a tres usuarios del sistema que responden a los tres roles,
aunque la muestra es pequeña responde a la situación real de la sala con el
sistema ya instalado:
Resultados de la pregunta 1:
Todos los usuarios contestaron que la interfaz del sistema es agradable.
Resultados de la pregunta 2:
Agradable100%
No tan agradable0%
Es necesario cambiarla
0%
Resultados de la pregunta 1
Agradable No tan agradable Es necesario cambiarla
81
Solamente un usuario, con rol de Personal Médico, contestó que el sistema tiene
cierta complejidad, para un 33% de encuestados.
Resultados de la pregunta 3:
Todos los usuarios señalaron que el manual de usuario es importante, y aporta
gran conocimiento para el uso del sistema.
Fácil de usar67%
Cierta complejidad33%
Difícil de usar0%
Resultados de la pregunta 2
Fácil de usar Cierta complejidad Difícil de usar
Todo el conocimiento
100%
Deficiente conocimiento
0%
No aporta nada0%
Resultados de la pregunta 3
Todo el conocimiento Deficiente conocimiento No aporta nada
82
Resultados de la pregunta 4:
Todos los usuarios señalaron que no es necesario impartir clases de
familiarización para el uso del sistema. Esto responde a que el manual de usuario
proporciona gran información en cuanto al uso del mismo.
Resultados de la pregunta 5:
Todos los usuarios coinciden que con la automatización del trabajo que logra
este sistema en la sala de Cardiología, el mismo se realiza de manera más
rápida.
Si0%
No
100%
Resultados de la pregunta 4
Si No
Si100%
No0%
En algunos aspectos0%
Resultados de la pregunta 5
Si No En algunos aspectos
83
Resultados de la pregunta 6:
Todos los usuarios coinciden en que los datos que arroja el sistema son
confiables y exactos.
Resultados de la pregunta 7:
Todos los usuarios responden que el Sistema Informático AMCardio – 2019
cumplen con las expectativas del trabajo que se realiza en la sala de Cardiología.
Si100%
No0%
Resultados de la pregunta 6
Si No
Si100%
No0%
En algunos aspectos0%
Resultados de la pregunta 7
Si No En algunos aspectos
84
Resultados de la pregunta 8:
No se realizaron recomendaciones.
Luego de la aplicación de la encuesta de satisfacción se pudo comprobar que el
nivel de satisfacción de los usuarios con respecto al Sistema Informático
AMCardio – 2019 es alta. Los usuarios alegan que los datos son confiables, su
interfaz de usuario es amigable, y que su manual de usuario aporta gran
conocimiento para el uso del mismo.
Conclusiones del capítulo
La validación del sistema se realizó a través del diseño de casos de pruebas de
caja negra, para probar la funcionalidad del sistema, y pruebas de caja blanca,
para realizar pruebas unitarias. Además, se realizan pruebas de aceptación a los
usuarios.
Las pruebas realizadas dieron como resultado que el software resultante esté
libre de defectos en las entradas de datos, procesamiento e información de
salida. Los usuarios del mismo aceptan el producto con altos valores de
satisfacción.
85
Conclusiones generales
Se desarrolla un sistema informático para la gestión clínica de los pacientes
ingresados en la Sala de Cardiología del Hospital Universitario Clínico –
Quirúrgico “Arnaldo Milián Castro” de Santa Clara:
1. La base de datos relacional obtenida a partir de las necesidades de los
cardiólogos, supera las debilidades de la base de datos Access utilizada
actualmente, permitiendo mejor organización y consistencia de los datos.
2. El diseño del sistema se realiza utilizando las bases y los artefactos
fundamentales que propone el modelo de proceso de desarrollo de
software RUP, para modelar, visualizar y documentar el software.
3. Con la implementación de las funcionalidades requeridas para este
sistema informático, se logra la gestión de los datos clínicos de los
pacientes ingresados en la sala, y la emisión de información necesaria
para el personal médico a este nivel de atención.
4. La validación del sistema desde la perspectiva técnica de los
desarrolladores con pruebas de caja negra y pruebas de caja blanca, así
como desde la perspectiva del usuario, da como resultado un sistema
informático que cumple los criterios de calidad requeridos para su
implementación.
86
Recomendaciones
Como parte de posibles extensiones del Sistema Informático AMCardio – 2019
se recomienda añadir las siguientes funcionalidades:
1. Permitir la gestión de los diagnósticos.
2. Integrar este sistema con cualquier sistema de gestión hospitalaria que se
adquiera en el hospital.
3. Exportar las informaciones que se emiten a un formato estándar como
XML para que puedan ser visualizados sobre la Web.
87
Referencias bibliográficas
Acosta, L. F. (2018) ‘Eclipse IDE’.
Álvarez, D. (2018) ‘JCreator’.
Batista, Y. O. (2017) ‘4-Comunicacion corta’.
Carvajal, F. V. (2018) ‘Crear pruebas y encuestas _ Ayuda de Blackboard’.
Castillo, D. M. B. B. (2014) ‘REGLAS DE NEGOCIO DESDE LA
PERSPECTIVA DE LOS DATOS EN BASES DE DATOS RELACIONALE’.
Cervantes, H. (2017) ‘Arquitectura de Software _ SG Buzz’.
Cillero, M. (2018a) ‘Diagrama de Componentes - manuel’.
Cillero, M. (2018b) ‘Diagrama de Despliegue - manuel’.
Curbelo, L. E. F. (2018) ‘Sistema informático para la gestión de la información
hospitalaria del infarto agudo de miocardio (RHIMA) _ Coll Muñoz _ CorSalud’.
Díaz, A. R. (2017) ‘Desarrollo de la informatización en Hospitales.’, pp. 3–15.
Eeles, P. (2017) ‘L a y e r i n g S t r a t e g i e s P e t e r E e l e s Rational
Software White Paper’.
Fernández, L. O. (2018) ‘Estimación de software basada en puntos de casos de
uso’.
García, A. C. (2018) ‘Infomed,_Portal_de_Salud_de_Cuba’.
Gutiérrez, N. (2018) ‘nataliagutierrez9835ita_ DEFINICION CASO DE USO,
ACTORES Y ROLES’.
Hernández, L. del V. (2018) NetBeans IDE entorno de desarrollo para
lenguajes como Java PHP C/C++ Groovy. Available at:
https://www.genbeta.com/desarrollo/netbeans-1 (Accessed: 17 December
2018).
Hildalgo, H. (2017) ‘Intellij ¿El mejor IDE para programar en Java – hugo
hidalgo – Medium’.
Ibáñez, C. (2018) ‘Aplicaciones de Escritorio » Desarrollo de Software a la
88
medida’.
Light, G. (2018) ‘Klinico - Sistema de Gestión Clínica’.
Lorenzo, G. F. (2016a) ‘Conf 3 - Detallando CU del negocio’.
Lorenzo, G. F. (2016b) ‘Conf 4 - Modelo de objetos del negocio y modelo del
dominio’.
Lorenzo, G. F. (2016c) ‘Conf 5 - Captura de requisitos’.
Lorenzo, G. F. (2017) ‘Conf 7- Análisis’.
Lorenzo, G. F. (2018) ‘Conferencia 3 Paquetes, Subsistemas, Interfaces’.
Marín, N. (2018) ‘Bases de datos relacionales’.
Milián, Y. R. (2018) ‘Pruebas de caja negra - Globe Testing’.
Motroni, O. M. T. (2018) ‘Sistema Informático de Gestión Hospitalaria del
Instituto de Cardiología y Cirugía Cardiovascular’.
Msaffirio (2017) ‘Reglas de Negocio – Business Rules – Tecnologías de la
Información y Procesos de Negocios (BPM)’.
PCC (2017) ‘LINEAMIENTOS DE LA POLÍTICA ECONÓMICA Y SOCIAL DEL
PARTIDO Y LA REVOLUCIÓN PARA EL PERÍODO 2016-2021 Julio de 2017
1’.
Pittet, S. (2019) ‘Los distintos tipos de pruebas en software _ Atlassian’.
Ramos, A. D. (2014) ‘Bases de datos distribuidas para aplicaciones médicas en
el Sistema Nacional de Salud Distributed database for medical applications in
the National’, 6(2), pp. 227–235.
Rouse, M. (2018a) ‘¿Qué es Base de datos relacional_ - Definición en WhatIs’.
Rouse, M. (2018b) ‘¿Qué es Sistema de gestión de bases de datos
relacionales (RDBMS)_ - Definición en WhatIs’.
Terrera, G. (2017) ‘Artefacto Modelo de despliegue’.
89
Glosario
ACTP: angioplastia coronaria transluminal percutánea.
Anticálcicos: antagonistas del calcio.
Antiarrítmicos: antagonistas de las arritmias.
APP: antecedentes patológicos personales.
ASA: ácido acetilsalicílico.
BBloqueo: beta bloqueadores.
Bloqueo A-V: bloqueo auriculoventricular.
CX: arteria circunferencia.
DA: Arteria descendente anterior.
Dicumarínicos: grupo farmacológico de acción anticoagulante.
DM: Diabetes mellitus de tipo I y II.
Estenosis: estrechamiento o constricción de un orificio o conducto
corporal.
FA: Fibrilación Auricular.
HTA: Hipertensión arterial.
HBPM: heparina de bajo peso molecular.
IECA: inhibidores de la enzima conversata.
ICP: intervención coronaria percutánea.
Insuficiencia: deterioro de la válvula en su funcionamiento.
IMACEST: infarto agudo de miocardio con elevación del segmento ST.
IMASEST: infarto agudo de miocardio sin elevación del segmento ST.
90
Anexos
Anexo 1 Especificación del caso de uso del negocio
Indicar tratamiento.
Actor del negocio Paciente
Trabajador del negocio Personal médico
Flujo de eventos
Acción del actor Respuesta del proceso de negocio
1. El personal médico indica un
tratamiento basado en el
diagnóstico realizado con
anterioridad.
2. El paciente recibe las
indicaciones del tratamiento a
seguir.
Tabla 20. Especificación del caso de uso del negocio Indicar tratamiento.
91
Anexo 2 Especificación del caso de uso del negocio
Realizar egreso de paciente.
Actor del negocio Paciente
Trabajador del negocio Personal médico
Flujo de eventos
Acción del actor Respuesta del proceso de negocio
1. El personal médico decide que
el paciente está apto para
efectuar el egreso del mismo.
2. Se notifica al paciente que
está apto para egreso y
abandona el hospital.
Tabla 21. Especificación del caso de uso del negocio Realizar egreso del
paciente
92
Anexo 3. Especificación del caso de uso del negocio
Depurar historia clínica.
Actor del negocio Paciente
Trabajador del negocio Personal médico
Flujo de eventos
Acción del actor Respuesta del proceso de negocio
1. El paciente no acude a los
servicios de la sala de
Cardiología en un periodo de 5
años.
2. El personal médico desactiva
la historia clínica
correspondiente al paciente.
Tabla 22. Especificación del caso de uso del negocio Depurar historia clínica.
93
Anexo 4. Manual de usuario del Sistema Informático
AMCardio – 2019.
AMCardio - 2019 es un Sistema Informático desarrollado en conjunto por la
Universidad Central "Marta Abreu" de Las Villas y el Hospital Universitario
Clínico-Quirúrgico "Arnaldo Milián Castro", para su aplicación en la sala de
Cardiología del mismo. Va dirigido al personal médico de dicha sala.
Surge a partir de la necesidad de la sala de Cardiología de gestionar de forma
organizada y exacta los datos clínicos de los pacientes que ingresan a sus
servicios, dando la posibilidad de emitir reportes y exportar información hacia
documentos externos.
Características y beneficios:
El sistema cuenta con dos roles de usuarios:
- un Jefe de servicios (administrador del sistema) que controla y
gestiona los usuarios, así como los tratamientos y los Antecedentes
Patológicos Personales (APP). De igual manera tiene la posibilidad de
gestionar los usuarios y de exportar la información de una búsqueda
de pacientes.
- un personal médico (usuario), que gestiona la información de
pacientes y puede realizar búsquedas a partir de información
específica, así como exportarla a documentos externos.
- un personal médico espectador (usuario espectador), que tiene la
posibilidad solamente de observar los datos que se encuentran en el
sistema, además de realizar la búsqueda por criterios.
Gestión de pacientes: Permite la gestión de la información clínica de los
pacientes que ingresan a la sala. Facilita agregar la información de un
paciente, modificarla y/o eliminarla.
Gestión de usuarios: El Sistema Informático permite la gestión de los
usuarios que pueden intervenir con el mismo.
Gestión de catálogos: El administrador del Sistema Informático puede
gestionar los catálogos de los APP y los tratamientos que serán
mostrados en las listas de selección.
94
Realizar búsquedas de pacientes: A partir de información específica
(Nombre y apellidos de un paciente, número de historia clínica, carnet de
identidad, etc.) se puede realizar búsquedas de pacientes. Las consultas
pueden arrojar uno o varios resultados.
Exportar resultados de la búsqueda: Con el objetivo de emitir reportes
médicos a distintos niveles hospitalarios, el Sistema Informático da la
posibilidad al usuario de exportar la información resultado de las
búsquedas de pacientes a distintos tipos de documentos.
Requisitos del sistema
Para un funcionamiento óptimo de AMCardio - 2019, el sistema debe cumplir con
los siguientes requisitos de software y hardware:
Procesadores compatibles: Intel (R) o AMD x86 - x64.
Sistemas Operativos: Windows (R) 7/8/8.1/10
Softwares necesarios para la instalación de AMCardio - 2019:
Máquina virtual de Java (JDK) versión superior a la 1.8.0.
Gestor de bases de datos PostgreSQL, preferiblemente versión 9.4.
Contactos
Desarrollador: Gustavo del Sol Hernández [email protected]
Tutores: Dra. Marta Beatriz Boggiano Castillo [email protected]
Licenciado Alexander A. Rodríguez Fabelo
Dr. José Ignacio Ramírez Gómez [email protected]
Instalación
En este capítulo se explicarán los pasos necesarios para realizar la instalación
del software AMCardio - 2019 y su puesta a punto.
JDK
Gestor de bases de datos PostgreSQL
Instalación de la Máquina virtual de Java (JDK)
95
Uno de los primeros pasos que se debe seguir para la puesta a punto de
AMCardio - 2019 es la instalación de un JDK válido. Se recomienda usar la
versión superior a la 1.8.0. Se puede realizar a partir de su instalador activo como
se ejemplifica en la figura 24.
Fig. 24 Instalación del JDK.
Instalación del gestor de bases de datos PostgreSQL
Lo próximo en instalar es el gestor de bases de datos PostgreSQL, es
recomendable usar la versión 9.4. Es posible que en alguna versión del Sistema
Operativo Windows 10 el gestor no pueda iniciar el servicio de la base de datos.
1. Instalar PostgreSQL en el equipo mediante su instalador activo, teniendo en
cuenta la arquitectura del sistema (x86 o x64), como se muestra en la figura
25.
96
Fig. 25 Instalación del gestor de bases de datos PostgreSQL.
Importante:
En el momento en que el instalador requiera especificar un puerto por el cual
el servicio de la base de datos debe funcionar, usted debe especificar el
siguiente: 5432.
En el momento en que el instalador requiera especificar una contraseña por la
cual usted debe acceder a la base de datos, usted debe especificar la
siguiente: 2306.
El Sistema está configurado para trabajar con estas especificidades, alterarlas
se traduce en el funcionamiento incorrecto de AMCardio - 2019.
2. Una vez finalizada la instalación del gestor de bases de datos PostgreSQL, el
directorio de instalación es el siguiente:
C:\ Archivos de programas \ PostgreSQL \ 9.4
El ejecutable del gestor de bases de datos se encuentra en la dirección siguiente:
C:\ Archivos de programas \ PostgreSQL \ 9.4 \ bin \ pgadminIII.exe
3. Al acceder al ejecutable del gestor de bases de datos PostgreSQL, debemos
crear nuestra nueva base de datos de la siguiente forma:
97
- Acceder al servidor PostgreSQL 9.4(localhost:5432) y acceder por la
contraseña antes establecida (2306).
- Crear la nueva base de datos. Encima de Databases clic derecho / New
Database. (Fig. 26)
- Especificar nombre de la nueva base de datos: AMCardio. (Fig. 27)
Fig. 26 Creación de una nueva base de datos.
Fig. 27 Creación de una nueva base de datos.
4. Debemos restaurar la base de datos con los datos clínicos históricos:
98
- Encima de la base de datos AMCardio, clic derecho / Restore.(Fig. 28, 29)
Fig. 28 Restauración de la base de datos.
99
Fig. 29 Restauración de la base de datos.
5. Verificar que el servicio de la base de datos esté en ejecución.
Se puede verificar que el servicio de la base de datos esté en ejecución a través
del Administrador de Tareas, como se muestra en la figura 30.
100
Fig. 30 Servicio de la base de datos funcionando en el Administrador de tareas.
Interactuando con AMCardio – 2019
En esta apartado se explicará al usuario cómo interactuar con el sistema.
Algunos puntos a tratar serán:
Credenciales
Inicio
Gestión de pacientes
Gestión de catálogos
Gestión de usuarios
Problemas frecuentes
Glosario de palabras
101
Credenciales
Fig. 31 Interfaz de usuario Login.
Para ingresar al Sistema usted debe proporcionarle las credenciales correctas
como se muestra en la figura 31. Si usted no cuenta con las credenciales para
acceder al mismo, contacte al administrador.
Conexión remota
La conexión remota se refiere al uso de la base de datos en un terminal de
cómputo distinto al que se está usando. Para ello se debe especificar la dirección
IP donde se encuentra la base de datos.
102
Inicio
Fig. 32 Interfaz de usuario Inicio.
En la figura 32 se muestra la pantalla principal del Sistema AMCardio - 2019.
Desde este sitio usted puede:
Consultar la Misión y Visión de la sala de Cardiología del Hospital.
Acceder a las opciones:
Paciente: desde esta opción el usuario del sistema puede gestionar la
información de los pacientes y listar pacientes por determinada
información.
Catálogos: el usuario puede gestionar la información de los catálogos de
APP y tratamientos.
Usuarios: se da la posibilidad de gestionar la información de los usuarios
que pueden ingresar al sistema.
Ayuda: se consulta la información del sistema.
Salir: el usuario puede salir del sistema o bien cerrar la sesión.
103
Gestionar pacientes
Fig. 33 Interfaz de usuario Gestión de pacientes
En la figura 33 se representa la interfaz de usuario que permite la gestión de los
pacientes.
Agregar paciente
Permite al usuario agregar un nuevo paciente. Lo dirige directamente hacia la
interfaz de adición del mismo.
Modificar paciente
Permite al usuario modificar la información de un paciente. Se debe seleccionar
primeramente el paciente deseado a modificar, luego de esto, se habilita la
acción de modificar. Esa opción dirige al usuario directamente a la interfaz de
modificación del paciente.
Eliminar paciente
Permite al usuario eliminar la información de un paciente. Se debe seleccionar
primeramente el paciente deseado a eliminar, luego de esto se habilita la acción
104
de eliminar. Esta acción es irreversible, se elimina la información del paciente de
la base de datos.
Activar / Desactivar paciente
El usuario tiene la posibilidad de activar o desactivar la información de un
paciente. Es conveniente que la información permanezca en la base de datos
para posteriores búsquedas.
Búsquedas rápidas por número de historia clínica
El usuario cuenta con la posibilidad de buscar a un paciente directamente por su
número de historia clínica. Lógicamente, el resultado de esta búsqueda rápida
es un paciente, puesto que el número de historia clínica es único.
Agregar un paciente
Fig. 34 Interfaz de usuario Agregar paciente.
En la figura 34 se muestra la interfaz que permite al usuario agregar la
información de un nuevo paciente. Se divide en dos secciones: los datos
generales, donde se ingresan el nombre y los apellidos del paciente, su número
de carnet de identidad, edad, etc., y los datos clínicos específicos para la sala de
Cardiología del Hospital, donde el usuario puede ingresar su número de historia
clínica, los APP, tratamientos, etc.
105
Importante:
Al llenar los campos de entrada escrita de datos, el usuario debe tener en
cuenta que:
El campo Nombre y Apellidos solamente acepta letras.
Los campos Carnet de Identidad y Edad, solamente aceptan datos
numéricos. En el caso de la edad, los datos no deben exceder los tres
números, en caso contrario, el sistema notificará el error.
Los campos Fecha de Ingreso y Fecha de Egreso deben tener el
formato DD/MM/AAAA, en caso contrario el sistema notificará el error. En
el caso del campo Fecha de Egreso, este puede permanecer en blanco,
puesto que el paciente pudo ingresar y permanecer todavía en ese
estado.
El campo Número de HC hace referencia al número de historia clínica
del paciente. Este debe ser de tipo numérico y no exceder de 6 dígitos.
En caso contrario el sistema notificará el error.
Para los APP, el usuario debe seleccionar la deseada en la lista
desplegable y luego añadirla a la lista de APP mediante el botón (+), si
desea eliminar alguna de la lista de APP, puede hacerlo mediante el botón
(-).
Para los Tratamientos, el usuario debe seleccionar el deseado en la lista
desplegable y luego añadirlo a la lista de Tratamientos mediante el botón
(+), si desea eliminar alguno de la lista de Tratamientos, puede hacerlo
mediante el botón (-).
106
Modificar un paciente
Fig. 35 Interfaz de usuario Modificar paciente.
En la figura 35 se muestra la interfaz de usuario que permite modificar la
información de un paciente. Los datos del paciente seleccionado son cargados
en los campos de datos, dando la posibilidad de modificar la información
deseada, una vez hecho esto, el usuario confirma los cambios.
Los requisitos que deben cumplir los campos de entrada de datos en esta
interfaz siguen la misma filosofía que los campos de entrada de la interfaz de
usuario Agregar paciente.
107
Eliminar un paciente
Fig. 36 Mensaje de la Interfaz de usuario Gestión de pacientes al eliminar un
paciente.
Para eliminar la información de un paciente, el usuario debe acceder a esta
funcionalidad a través de la interfaz Gestión de pacientes. El paciente objeto
debe ser previamente seleccionado en la tabla, una vez hecho esto, se habilita
la opción de eliminar. El usuario debe confirmar la acción, ya que es permanente:
la información del paciente se elimina de la base de datos tal y como se observa
en la figura 36.
Gestionar catálogos
En esta sección se explicarán los aspectos fundamentales de la gestión de los
catálogos.
Gestión de APP.
Gestión de Tratamientos.
Estos catálogos serán mostrados a la hora de adicionar o modificar la
información de un paciente.
108
Gestionar tratamientos
Fig. 37 Interfaz de usuario Gestión de tratamientos.
En la figura 37 se representa la interfaz de usuario que permite la gestión de los
tratamientos.
Agregar tratamiento
El usuario debe completar la información del nuevo tratamiento, una vez
realizado, pulsa el botón Agregar. No es posible agregar un nuevo tratamiento si
el campo de datos está vacío.
Modificar tratamiento
Para modificar un tratamiento el usuario debe seleccionar el deseado en la lista,
la opción Modificar se activa, y aparecen dos botones: uno, confirmar el cambio,
otro: cancelar cambios. A su vez, la información del tratamiento seleccionado
aparece en el campo de datos para su modificación.
109
Fig. 38 Acción del botón Modificar en la interfaz de usuario Gestión de
tratamientos.
El sistema no permite realizar otra acción hasta que el usuario confirme el cambio
o lo descarte tal y como es mostrado en la figura 38.
Eliminar tratamiento
Para eliminar un tratamiento, el usuario debe seleccionarlo en la lista, luego de
esto se activa la opción de eliminar. Se debe confirmar la eliminación del
tratamiento. Esta acción es representada en la figura 39.
110
Fig. 39 Mensaje de la interfaz de usuario Gestión de tratamientos al eliminar un
tratamiento.
Gestionar APP
Fig. 40 Interfaz de usuario Gestión de APP.
En la figura 40 se muestra la interfaz de usuario que permite la gestión de APP.
111
Agregar APP
El usuario debe completar la información del nuevo APP, una vez realizado,
pulsa el botón Agregar. No es posible agregar un nuevo APP si el campo de
datos está vacío.
Modificar APP
Para modificar un APP el usuario debe seleccionar el deseado en la lista, la
opción Modificar se activa, y aparecen dos botones: uno, confirmar el cambio,
otro: cancelar cambios. A su vez, la información del APP seleccionado aparece
en el campo de datos para su modificación.
Fig. 41 Acción del botón Modificar en la interfaz de usuario Gestión de APP.
El sistema no permite realizar otra acción hasta que el usuario confirme el cambio
o lo descarte, tal y como es mostrado en la figura 41.
112
Eliminar APP
Para eliminar un APP, el usuario debe seleccionar un APP en la lista, luego de
esto se activa la opción de eliminar. Se debe confirmar la eliminación del APP
como se representa en la figura 42.
Fig. 42 Mensaje de la interfaz de usuario Gestión de APP al eliminar un usuario.
113
Gestión de usuarios
Fig. 43 Interfaz de usuario Gestión de usuarios.
En la figura 43 se representa la interfaz de usuario que permite gestionar la
información de los usuarios que pueden acceder al Sistema.
114
Agregar un usuario
Fig. 44 Interfaz de usuario Gestión de usuarios al agregar un nuevo usuario.
El usuario completa el nombre y los apellidos del usuario, su nombre de usuario
y le asigna una contraseña. Luego confirma la adición como se representa en la
figura 44.
115
Modificar un usuario
Fig. 45 Interfaz de usuario Gestión de usuarios al modificar un usuario.
Para modificar un usuario, se debe seleccionar en la lista el objeto a modificar.
Los campos de datos se llenan con la información del usuario seleccionado. El
sistema no permite otra acción hasta que el usuario confirme el cambio realizado
o lo descarte, así es mostrado en la figura 45.
116
Eliminar usuario
Fig. 46 Mensaje de la interfaz de usuario al eliminar un usuario.
Para eliminar la información de un usuario, tal y como es mostrado en la figura
46, se debe seleccionar en la lista el objeto a eliminar. El usuario debe confirmar
la acción, puesto que la información se elimina de la base de datos, eliminando
el acceso del usuario al Sistema.
Importante:
El usuario cuyo rol es Administrador no puede ser eliminado del sistema. Solo
es permitido la modificación de sus credenciales. El Sistema notificará el error al
intentar eliminar este tipo de usuario.
117
Listar pacientes
Fig. 47 Interfaz de usuario Listar pacientes.
En la figura 47 se muestra la interfaz que permite al usuario realizar una
búsqueda de pacientes a partir de información específica. Primeramente, el
usuario debe seleccionar cómo desea realizar la búsqueda, cuenta con varias
posibilidades: buscar por datos generales, buscar por datos clínicos, o por
ambos.
Buscar por datos generales
Si el usuario desea realizar la búsqueda por datos generales, debe seleccionar
la opción. Una vez realizado esto, si la búsqueda es por nombre y apellidos,
número de carnet de identidad o edad, debe especificar los datos en el campo
de texto; en caso contrario, especifica los datos por la lista de selección.
Buscar por datos clínicos
Si el usuario desea realizar la búsqueda por los datos clínicos, debe seleccionar
la opción. Una vez realizado esto, si la búsqueda es por número de historia
clínica, debe especificar el dato en el campo de texto, en caso contrario, debe
especificar los datos por la lista de selección.
118
Ver detalles de paciente
Una vez que el usuario realiza una búsqueda con resultados, tiene la posibilidad
de consultar los detalles de un paciente previamente seleccionado en la tabla de
resultados, como se muestra en la figura 48.
Fig. 48 Interfaz de usuario Detalles de paciente.
Exportar resultados de la búsqueda
El usuario tiene la posibilidad de exportar al formato que desee los resultados de
la búsqueda realizada, facilitando los reportes que se deben emitir.
Importante:
A la hora de especificar la dirección del archivo a guardar, el usuario debe
especificar la extensión del archivo. Solo se permiten las extensiones .pdf y .xls,
en sus respectivas funcionalidades.
Ejemplo:
Exportar archivo a PDF: Consulta1.pdf
Exportar archivo a Excel: Consulta2.xls
Problemas frecuentes
El servicio de la base de datos no está en ejecución.
119
Fig. 49 Mensaje de la interfaz de usuario Login al notificar error en el servicio de
la base de datos.
Para resolver el problema representado en la figura 49, usted puede contactar
con el informático encargado, o bien seguir estos pasos:
1- Acceder al Administrador de Tareas. La manera más frecuente de acceder es
a través de la combinación de teclas Ctrl + Shift + Esc.
2- Una vez en el Administrador de Tareas, acceder a la pestaña Servicios.
3- Buscar el servicio postgresql-x64-9.4/ clic derecho sobre él / Iniciar.
120
Fig. 50 Servicio de la base de datos en el Administrador de tareas.
En la figura 50 se muestra el servicio de la base de datos en funcionamiento. Si
el servicio no se encuentra, es posible que el gestor de bases de datos
PostgreSQL no esté instalado.
Errores en la adición de pacientes
Es posible que el usuario se enfrente a errores en la adición de la información de
los pacientes tales como los representados en las figuras 51, 52 y 53:
Fig. 51 Error en la interfaz de usuario Agregar paciente / Modificar paciente.
121
Para solucionar este problema el usuario debe llenar la información necesaria:
los campos de datos no deben estar en blanco.
Fig. 52 Error en la interfaz de usuario Agregar paciente / Modificar paciente.
Para solucionar este problema el usuario debe comprobar la información
proporcionada. Debe tener en cuenta que:
El campo Nombre y Apellidos solamente acepta letras.
Los campos Carnet de Identidad y Edad, solamente aceptan datos
numéricos. En el caso de la edad, los datos no deben exceder los tres números,
en caso contrario, el sistema notificará el error.
Los campos Fecha de Ingreso y Fecha de Egreso deben tener el formato
DD/MM/AAAA, en caso contrario el sistema notificará el error. En el caso del
campo Fecha de Egreso, este puede permanecer en blanco, puesto que el
paciente pudo ingresar y permanecer todavía en ese estado.
El campo Número de HC hace referencia al número de historia clínica del
paciente. Este debe ser de tipo numérico y no exceder de 6 dígitos. En caso
contrario el sistema notificará el error.
122
Fig. 53 Error en la interfaz de usuario Agregar paciente / Modificar paciente.
Este error surge cuando el usuario intenta insertar un número de historia clínica
que ya se encuentra en la base de datos. Para solucionar este problema debe
comprobar el dato proporcionado.
Errores en la conexión remota
Fig. 54 Error en la interfaz de usuario Login.
123
El error mostrado en la figura 54 advierte que el servicio de red no está
funcionando.