Proyecto Trabajo Grupal Final

UNIVERSIDAD TÉCNICA DE COTOPAXI
FACULTAD DE CIENCIAS DE LA INGENIERIA Y

APLICADAS
CARRERA: SISTEMAS DE INFORMACIÓN
ESTUDIANTES:
JACOME TACO VALERIA ELIZABETH
LOGACHO MASABANDA ANGELICA ANABEL
 SIMBA SIMBA DANNY EDUARDO
 TORRES OJEDA ROBERTH DAVID
MATERIA: ANÁLISIS Y DISEÑO DE SISTEMAS DE

INFORMACIÓN
TEMA: AUTOMATIZACIÓN DE REGISTROS DE KARDEX

PARA EL PERSONAL DE ENFERMERÍA EN EL HOSPITAL
BÁSICO DE SANGOLQUÍ
DOCENTE: ING. EDWIN QUINATOA
i
Contenido
1. Árbol de Problema:........................................................................................................................1
2. Problema.......................................................................................................................................3
3. Alcance..........................................................................................................................................4
4. Objetivos........................................................................................................................................5
5. Encuestas.......................................................................................................................................6
6. Reglas de negocio........................................................................................................................13
7. Grupo de Trabajo.........................................................................................................................14
8. Marco Teórico.............................................................................................................................14
7.1 Requisitos..................................................................................................................................14
7.2 Requisitos funcionales...............................................................................................................15
7.3 Requisitos no funcionales..........................................................................................................15
7.4 Modelo Estructurado.................................................................................................................15
7.5 Modelo orientado a objetos......................................................................................................15
7.6 Lenguaje de modelado unificado (UML)....................................................................................16
7.7 Herramientas CASE....................................................................................................................16
7.8 Power Designer..........................................................................................................................16
7.9 Visual Parading..........................................................................................................................16
7.10 Diagrama de clases..................................................................................................................17
7.11 Prototipo de software..............................................................................................................17
9. Requisitos Funcionales................................................................................................................17
10. Requisitos no funcionales........................................................................................................18
11. Especificación de módulos.......................................................................................................18
12. Diagrama de flujo de datos......................................................................................................19
12.1 Nivel 0..................................................................................................................................19
12.2 Nivel 1..................................................................................................................................20
12.3 Nivel 2......................................................................................................................................21
12.4 Nivel 3......................................................................................................................................24
13. Casos de Usos UML..................................................................................................................28
13.1 Nivel 0......................................................................................................................................28
13.2 Nivel 1......................................................................................................................................28
13.3 Nivel 2......................................................................................................................................30
14. Prototipo..................................................................................................................................49
ii
15. Diagrama de clases..................................................................................................................54
16. Diagrama Lógico......................................................................................................................55
17. Diagrama Físico........................................................................................................................55
15. Script BBDD..............................................................................................................................56
16. Diagrama de Actividades.........................................................................................................59
17. Conclusiones............................................................................................................................61
18. Recomendaciones....................................................................................................................61
19. Bibliografía...............................................................................................................................61
iii
1. Árbol de Problema:
1.1 Análisis de la situación:
En los hospitales públicos el personal de enfermería es el encargado de administrar la
medicación prescrita por el médico, en la actualidad se manejan hojas llamadas
Kardex que son llenadas a mano y son considerados documento con validez legal, lo
cual no garantiza seguridad al paciente debido a la cantidad de errores que se pueden
cometer, tales como confusión por mala caligrafía, uso de tinta correctora,
medicamentos LASA, entre otros.
1.2 Identificar los principales problemas de la situación (lluvia de ideas)
● Los datos de afiliación de los pacientes a nivel público son ineficientes, sobre
su ingreso, proceso y alta, debido a la falta de automatización de información
ya que los registros históricos se han llevado mediante papel y con el paso del
tiempo la documentación se ha ido deteriorando.
● Los procesos manuales están dados de una manera inadecuada lo que ocasiona
errores en el registro, tanto en el sentido de llevar una secuencia de los Kardex
como en la incomodidad y pérdida de tiempo reflejada en el paciente y el
personal médico.
● Es difícil rastrear los papeles necesarios y caro de manejarlos. Y en la
industria hospitalaria de la salud, mantener estos archivos seguros y protegidos
es obligatorio para el cumplimiento de un hospital.
● En caso de conflictos legales la información detallada y precisa es
fundamental para definir culpabilidades, actualmente se dispone de registros
manuales que pueden ser alterados a conveniencia de una de las partes y no se
consideraría una prueba legal admisible.
● Los medicamentos LASA son aquellos que se parecen físicamente o que sus
nombres suenan parecidos, esto conllevo una problemática en la
administración debido a la caligrafía.
1.3 Determinar los efectos y causas del problema principal
Causas Efectos
Los datos de afiliación de los pacientes a Perdida de datos de afiliación de cada

nivel público son ineficientes, debido a la paciente. Impidiendo llevar un buen
falta de automatización de información, y
1
deterioro de documentación llevada en papel. seguimiento para su respectiva recuperación.
Los procesos manuales son llevados de Incomodidad y pérdida de tiempo reflejada en

manera inadecuada lo que ocasiona errores, el paciente y personal médico.
tanto en los registros como llevar una
secuencia de los Kardex.
Es difícil rastrear los papeles necesarios y Sanción al hospital por no llevar un papeleo
caro de manejarlos, y en la industria seguro y organizado.
hospitalaria es obligatorio mantenerlos
seguros y protegidos.
En caso de conflictos legales la información Manipulación de evidencia y como efecto la

detallada y precisa es fundamental, pero en la cárcel de la persona que pueda o no ser
actualidad se dispone de papeles llenados a responsable.
mano, que pueden contener errores.
Los medicamentos LASA conlleva una Errores en la administración de

problemática en la administración debido a medicamentos, shock anafiláctico y muerte
que sus nombres son parecidos y puede del paciente.
causar problemas debido a la caligrafía.
2. Problema
En los hospitales públicos, especialmente los registros Kardex que constituyen una parte
importante de las asistencias sanitarias, son integrados en la historia clínica del paciente
hospitalizado, lo que conlleva las repercusiones y responsabilidades de índole profesional
y legal, que precisa llevarlos a la práctica con el necesario rigor, que garantice la calidad
de los mismos. Al llevarlos manualmente ha ocasionado varios problemas para el
personal de enfermería tales como la ineficiencia al momento de ingresar, procesar y dar
el alta, debido a la falta de rapidez de la información, ya que los registros se han llevado
mediante papel y con el paso del tiempo la documentación se ha ido deteriorando,
ocasionando la perdida de datos de afiliación del paciente, impidiendo un seguimiento
optimo.
En caso de conflictos legales llevados por parte del personal de salud, la información
detallada y precisa es fundamental para definir culpabilidades, lo que actualmente se
2
dispone de registros manuales, que pueden contener errores de caligrafía u ortografía que
pueden ser alterados a conveniencia de una de las partes y no se consideraría una prueba
legal admisible. Y como uno de los mayores problemas, que podría llevar a la muerte del
paciente, es la confusión de la administración de medicamentos LASA que se parecen
físicamente o que sus nombres suenan parecidos, debido a la confusión al momento de
escribir todo manualmente, llevando a la falta de credibilidad del personal médico y como
consecuencia la garantía de atención por parte del hospital.
3. Alcance
En la creación de este prototipo de aplicativo web, para un mejor desarrollo se
implementarán varios puntos tales como la generación de un cronograma de los procesos
que se realizará a lo largo. En el cronograma se establecerá la fecha inicial y fecha límite
que tendrá cada uno de los procedimientos que se llevaran a cabo. Al mismo tiempo se
realizará una encuesta al personal de enfermería sobre las problemáticas y falencias que
tienen con el manejo manual de los registros Kardex, y basándonos en esa información
generaremos un árbol de problemas donde contendrá los efectos, problemas y causas. En
el informe que se realizará contendrá información tal como: Análisis, objetivos,
observaciones, árbol de problemas alcance, etc., e incluirá los requisitos funcionales y no
funcionales, además para obtener un mejor visualización del procesamiento de datos de
nuestro prototipo implementaremos diagramas de flujo de datos, diagrama de casos de
usos con sus respectivos formularios de flujos normales y alternos y la realización del
diagrama de actividades que nos ayudara a comprender el orden de las actividades de los
procesos que llevaremos a cabo en nuestro prototipo. Con los objetivos e ideas claras el
equipo de trabajo se dividirá el proyecto para comenzar con el desarrollo del prototipo del
aplicativo web. Una parte del grupo se encargará de la creación del MER, tablas de
usuarios, relaciones y los demás elementos que estructurarán la base de datos. Esta base
de datos contendrá (datos afiliación, registro Kardex e información general de médicos y
enfermeras) y se desarrollará con la herramienta digital MYSQL. La otra parte del grupo
trabajará en el desarrollo del software donde se encargarán de desarrollar el login, perfil
de usuario, lista de pacientes, automatización de Kardex, menú de opciones, conexiones,
funciones, etc. Para el desarrollo de toda esta interfaz gráfica se usará el lenguaje PHP,
HTML, CSS junto con la herramienta Visual Code. Para mostrar los registros y datos
personales (personal y paciente), se deberá realizar la conexión de la base de datos con el
prototipo aplicativo web. El equipo procederá a realizar la conexión mediante PHP y para
3
confirmar que la base de datos fue conectada exitosamente, se realizara inserciones como
parte de un test. Como procedimientos finales nos enfocaremos en realizar cambios en la
interfaz tales como: cambio de diseño, mejoras visuales, etc. Ya comprobado la conexión,
las secciones del menú y registro se podrán usar. Finalmente se comprobará que el
desarrollo del software cumplió con el cronograma establecido y se verificara la eficacia
con la implementación de pruebas del prototipo para la presentación del proyecto.
4. Objetivos
4.1 Objetivo General
Desarrollar el prototipo de una aplicación web, mediante el uso de lenguajes de
programación HTML, CSS, PHP y MySQL, para la automatización de los registros
Kardex en el hospital básico de Sangolquí.
4.2 Objetivos Específicos
 Aplicar cada uno de las actividades realizadas en clases para el mejoramiento del
desarrollo de los procesos del prototipo.
 Reducir la cantidad de carpetas y hojas que se usan para los registros de cada
paciente.
 Obtener un respaldo de la información para evitar desafortunadas perdidas de
registros.
4
5. Encuestas
5
6
7
Nombre Ana Jorge Luis Gabriela Adelina Francisc Tatiana Carmen Carlos Fernand
Castro Estrad Díaz Zambran Fernánde o Baños Vera Quishpe a Silva
a o z Paredes
Edad 33 40 26 28 33 45 34 38 29 30
¿Por cuánto tiempo ha trabajado 1-3 años 4 años 1-5 5-11 1-3 años 4 años y 4 años y 4 años y 1-3 años 4 años y
como personal de enfermería? y más meses meses más más más más
¿Cuánto se demora en registrar 15-30 30-60 15-30 10-15 15-30 15-30 10-15 15-30 10-15 10-15
los datos manualmente de cada minutos minutos minutos minutos minutos minutos minutos minutos minutos minutos
paciente en hospitalización?
¿Con cuanta frecuencia usted 3-4 veces 1-2 2-3 2-4 veces 2-3 veces 3-4 veces 3-4 veces 2-3 veces 3-4 3-4 veces
repite un registro Kardex por una veces veces veces
equivocación?
¿Existen con funciones de Si Si Si Si Si Si Si Si Si Si
tipografía al momento de leer un
diagnóstico?
¿Usted se considerada apto para Si Si Si Si Si No Si Si Si Si
manejar un software nuevo?
¿Estaría dispuesto a utilizar un Si Si Si Si Si Si Si Si Si Si
software donde ayude a la
automatización de los procesos del
Kardex?
Tabulación de resultados
8
¿Por cuánto tiempo ha trabajado como 1-5 meses 1 En
personal de enfermería? 5-11 meses 1 ¿Por cuanto tiempo a trabajado
1-3 años 3 como personal de enfermería?
4 años y 5
más 1-5 meses
Total 10 5-11 meses
10%
1-3 años
esta grafica se puede observar que la mayoría del personal de enfermería ha 10%
4 años y más
trabajado por mas de 4 años en el hospital básico de Sangolquí, con lo que 50%
podemos concluir que la mayoría de personas son conocedoras de los 30%
procedimientos del hospital.
¿Cuánto se demora en registrar los 5-10 minutos 0

datos manualmente de cada paciente 10-15 minutos 4 ¿Cuánto se demora en registrar los
en hospitalización? 15-30 minutos 5 datos manualmente de cada pa-

30-60 minutos 1 ciente en hospitalización?
Total 10
5-10 minutos
10-15 minutos
15-30 minutos
Aquí podemos observar que el personal de enfermería se demora en hacer un registro Kardex de 10 a 30 minutos,
20% eso sin contar al momento
30-60 que
minutos
tienen que repetir o corregir, tomándoles más tiempo. Total
50%
25%
5%
¿Con cuanta frecuencia usted repite un 1-2 veces 1
9
registro Kardex por una equivocación? 2-3 veces 4 ¿Con cuanta frecuencia usted repite
3-4 veces 5
4-5 veces 0
un registro Kardex por una equivo-
Total 10 cación?
1-2 veces
Aquí observamos que el personal de enfermería repite un registro Kardex de 2 2-3 veces
3-4 veces
a 4 veces tomándoles mucho más tiempo y no privilegiando la atención al 5% 4-5 veces
cliente. 20% Total
50%
25%
¿Usted se considerada apto para Si 10 ¿Usted se considerada apto para

manejar un software nuevo? No 0
Total 10
manejar un software nuevo?

En esta grafica observamos que el personal de enfermería está dispuesto a
usar un software nuevo, para poder facilitar su trabajo en el hospital y Si
No
mejorar la atención al paciente.
¿Existen con funciones de tipogra-

fía al momento
100% de leer un diag-
¿Existen con funciones de tipografía al Si 9
momento de leer un diagnóstico? No 1
nóstico?
Total 10
Si
10% No
10
90%
Aquí podemos observar en esta pregunta que al momento de escribir los registros Kardex existen equivocaciones de tipografía por lo que puede
llevar a malentendidos entre el personal de salud.
¿Estaría dispuesto a utilizar un Si 10

software donde ayude a la ¿Estaría dispuesto a utilizar un so-
automatización de los procesos del
No 0 ftware donde ayude a la automati-
Total 10
Kardex? zación de los procesos del Kardex?

Si
No
En esta pregunta se observo que el personal de enfermería estaría dispuesto a
adquirir un software nuevo donde los ayude en la automatización de los
registros Kardex.
100%
11
6. Reglas de negocio
# Descripción
RN1 Los usuarios autorizados (enfermeras), podrán ingresar al sistema, con un usuario
y contraseña entregados con anterioridad.
RN2 El personal de enfermería podrá observar su perfil donde se visualizará toda su
información personal: C.I., nombres y apellidos completos, edad, fecha de
nacimiento y departamento, título de tercer y cuarto nivel.
RN3 El personal de enfermería atenderá a varios pacientes, donde el paciente tendrá su
perfil con su información personal: nombres y apellidos, cedula de ciudadanía,
dirección, edad, teléfono y fecha de ingreso.
RN4 El personal de enfermería podrá observar un listado de los diagnósticos hechos por
el personal médico que contendrá el código, fecha del diagnóstico, nombre del
diagnóstico, nombre del médico.
RN5 El personal de enfermería podrá suministrar a varios pacientes sus medicamentos,
en donde la información por grupo farmacológico contendrá la siguiente
información: código, fecha, hora de suministración de medicamento, nombre del
responsable y su especialidad.
RN6 El diagnostico escrito por el medico tendrá varias suministraciones de
medicamento por parte del personal de enfermería.
12
7. Grupo de Trabajo
Rol Nombre Descripción
Jefe de Proyecto Jácome Valeria Organización y planificación de

actividades, designación y supervisión del
informe final.
Analista Torres Roberth Elaboración y aplicación de encuestas y

descripción de reglas de trabajo.
Analista Jácome Valeria Definir los requisitos funcionales y no

funciones, elaboración del diagrama de
flujo de datos nivel 3 y diagrama de
clases, lógico, físico.
Analista Simba Danny Realización del diagrama de flujo de datos

nivel 2 y diagrama de actividades.
Analista Logacho Angelica Elaboración del diagrama de flujo de datos

nivel 0 y 1 y diagrama de casos de uso
nivel 0 y 1.
Programador Jácome Valeria Desarrollo del código para el login, perfil

de usuario y listado de pacientes.
Programador Torres Roberth Desarrollo del código para el perfil del

paciente, listado de diagnósticos y CRUD
del Kardex.
Tester Simba Danny Generar un plan de pruebas, ejecución de

las pruebas de software.
Tester Logacho Angelica Generación de informe de las pruebas

realizadas en el prototipo del aplicativo.
8. Marco Teórico
7.1 Requisitos
Un requisito es una condición necesaria para tener acceso a algo, o para que una cosa
suceda. La palabra requisito significa pretender o requerir alguna cosa. Los requisitos
pueden ser tangibles (tener un auto, entregar cierta documentación, firmar un contrato,
etc.) o intangibles (buena presencia, responsabilidad, puntualidad). Por otra parte, los
requisitos pueden ser de orden natural (por ejemplo, es una condición imprescindible
13
que la mayoría de las plantas reciban luz solar para poder hacer la fotosíntesis) o
culturales. (Significados, 2022)
7.2 Requisitos funcionales

Los requerimientos funcionales son las descripciones explicitas del comportamiento
que debe tener una solución de software y que información debe manejar. Expresan
las capacidades o cualidades que debe tener la solución para satisfacer los
requerimientos de los interesados de proyecto. Se expresan en términos de cuál debe
ser el comportamiento de la solución y que información debe manejar. Deben
proporcionar una descripción lo suficientemente detallada para permitir el desarrollo e
implementación de la solución. Son los que más influyen en si la solución será
aceptada o no por los usuarios. (PMOinformatica.com, 2018)
7.3 Requisitos no funcionales

Requisitos No Funcionales, son requisitos que imponen restricciones en el diseño o la
implementación como restricciones en el diseño o Estándares de Calidad.
un requisito que especifica criterios que pueden usarse para juzgar la operación de un
sistema en lugar de sus comportamientos específicos, ya que estos corresponden a
los funcionales. Son propiedades o cualidades que el producto debe tener. Se conocen
como un conjunto de características de calidad, que es necesario tener en cuenta al
diseñar e implementar el Software. (EcuRed, 2015)
7.4 Modelo Estructurado

El enfoque Estructurado, fue seleccionado como técnica de investigación de
requerimientos, ya que permite al analista conocer el sistema o proceso en una forma
lógica y manejable, al mismo tiempo que proporciona la base para asegurar que no se
omite ningún detalle. Este es un método para el análisis de sistemas manuales o
automatizados, que conduce al desarrollo de especificaciones para sistemas nuevos o
para efectuar modificaciones a los ya existentes. Aunado a ello y por ser considerados
como una herramienta capaz de describir y analizar el movimiento de los datos a
través de un sistema, la representación gráfica de los procesos del sistema estará a
cargo de los Diagramas de Flujos de Datos (DFD). (Software, 2012)
7.5 Modelo orientado a objetos

El modelado orientado a objetos es la construcción de objetos utilizando una
colección de objetos que contienen valores almacenados de las variables de instancia
14
encontradas dentro de un objeto. A diferencia de los modelos que están orientados a
registros, los valores orientados a objetos son únicamente objetos. (theastrologypage,
2019)
7.6 Lenguaje de modelado unificado (UML)

El lenguaje de modelado unificado fue creado para forjar un lenguaje de modelado
visual común y semántica y sintácticamente rico para la arquitectura, el diseño y la
implementación de sistemas de software complejos, tanto en estructura como en
comportamiento. UML tiene aplicaciones más allá del desarrollo de software, p. ej.,
en el flujo de procesos en la fabricación. (Krall, s.f.)
7.7 Herramientas CASE

Son diversas Aplicaciones informáticas destinadas a aumentar la productividad en el
Desarrollo de software reduciendo el coste de las mismas en términos de tiempo y de
dinero. Estas herramientas nos pueden ayudar en todos los aspectos del ciclo de vida
de desarrollo del software en tareas como el diseño de proyectos, cálculo de costes,
implementación de parte del código automáticamente con el diseño dado,
Compilación automática, documentación o detección de errores entre otras. (Gómez,
s.f.)
7.8 Power Designer

PowerDesigner es una familia de productos que ofrece una solución de modelaje
comprensivo para los analistas y diseñadores de sistemas de información y de bases
de datos. PowerDesigner permite, entre otras cosas, crear una base de datos
eficazmente y de manera estructurada, sin necesidad de adoptar una metodología
especifica. PowerDesigner incluye seis herramientas altamente integradas que facilita
a individuos y/o a miembros de un equipo de trabajo, desarrollar proyectos que
satisfagan sus necesidades de manera efectiva; estos módulos son: (Tipantuña, s.f.)
7.9 Visual Parading

Visual Paradigm ayuda a los equipos de desarrollo de softwares a capturar los
requisitos correctos y transformarlos en diseños precisos, lo que ayuda a los
desarrolladores a crear el software adecuado según los requisitos. La misma propicia
un conjunto de ayudas para el desarrollo de programas informáticos, desde la
planificación, pasando por el análisis y el diseño, hasta la generación del código
fuente de los programas y la documentación.
15
7.10 Diagrama de clases
Los diagramas de clases son uno de los tipos de diagramas más útiles en UML, ya que
trazan claramente la estructura de un sistema concreto al modelar sus clases, atributos,
operaciones y relaciones entre objetos. Popular entre los ingenieros de software para
documentar arquitectura de software, los diagramas de clases son un tipo de diagrama
de estructura porque describen lo que debe estar presente en el sistema que se está
modelando. Sin importar tu nivel de familiaridad con diagramas UML o diagramas de
clases, nuestro software UML está diseñado para ser simple y fácil de usar.
7.11 Prototipo de software

Los prototipos de software son implementaciones realizadas con técnicas de
programación del sistema interactivo propuesto que reproducen el funcionamiento de
una parte importante de las funcionalidades con el objetivo de probar determinados
aspectos del sistema final. Habitualmente se realizan con el lenguaje o la técnica de
programación escogida para desarrollar la aplicación, aunque pueden utilizarse otras
alternativas.
9. Requisitos Funcionales
8.1 Sistema
RF001: El sistema enviará o mostrará una alerta cuando se registre un nuevo registro de
Kardex.
RF002: El sistema eliminará los registros ya pasados de fecha.
RF003: El sistema debe contabilizar de forma automatizada el número de registros
semanales.
RF004: El sistema debe asignar a cada registro un identificador único, que será
utilizado para distinguirlos en todos los procesos subsecuentes que se realicen sobre
esta.
RF005: El sistema permitirá al usuario observar un historial de uso, con la fecha
respectiva.
8.2 Usuario
RF006.-El sistema permitirá al usuario ingresar a su perfil, con un usuario y contraseña

ya establecida.
RF007: El sistema permitirá al usuario visualizar sus datos personales registrados en el
sistema.
16
RF008: El sistema permitirá al usuario visualizar el registro del paciente, solamente si
ya tiene uno existente.
RF009: El sistema permitirá al usuario visualizar los datos de afiliación del paciente.
RF010: El sistema permitirá al usuario gestionar los datos del diagnóstico realizado por
el personal médico.
RF011: El sistema permitirá al usuario la gestión de los registros Kardex.
10. Requisitos no funcionales

RNF001: El sistema estará activo únicamente en el horario laboral y fuera de este se
tendrá que identificarse con el usuario y contraseña de la persona a cargo.
RNF002: El Sistema deberá permitir abrir archivos almacenados con anterioridad.
RNF003: El sistema deber permitir crear archivos nuevos.
RNF004: El sistema permitirá restaurar los archivos ante emergencias eléctricas en un
máximo de 60 minutos.
RNF005: El tiempo de aprendizaje para la utilización del software debe ser máximo de 4
horas.
RNF006: La velocidad el software dependerá del tamaño del archivo que se está creando
o leyendo.
RNF007: El sistema permitirá que se auto guarde los avances en un documento cada 2
minutos en caso de una falla interna o externa y no se pierda el avance del trabajo
realizado.
RNF008: El sistema permitirá que al momento de guardar un registro y si ya existe un
archivo con el mismo nombre, mostrara un mensaje para que el usuario decida si quiere
cambiar el nombre o remplazarlo.
RNF009: El sistema tendrá un backup en línea de cada 7 días.
RNF010: El sistema permitirá eliminar el backup anterior para almacenar lo más reciente.
RNF011: El sistema permitirá restaurar el sistema en otro dispositivo tras utilizar el
usuario y contraseña del admin.
RNF010: El sistema solo funcionara en n cantidades de dispositivos dispuestos por la
empresa.
11. Especificación de módulos

Inicio de sesión Registro de Kardex
RF006.-El sistema permitirá al usuario RF001: El sistema enviará o mostrará una
17
ingresar a su perfil, con un usuario y alerta cuando se registre un nuevo registro
contraseña ya establecida. de Kardex.
Visualización de datos personales RF002: El sistema eliminará los registros ya
pasados de fecha.
RF007: El sistema permitirá al usuario
RF003: El sistema debe contabilizar de
visualizar sus datos personales registrados
forma automatizada el número de registros
en el sistema.
semanales.
RF004: El sistema debe asignar a cada
visualizar el registro del paciente, solamente
registro un identificador único, que será
si ya tiene uno existente.
utilizado para distinguirlos en todos los
procesos subsecuentes que se realicen sobre
visualizar los datos de afiliación del
esta.
paciente.
gestionar los datos del diagnóstico realizado
Uso del sistema en general
por el personal médico.
RF011: El sistema permitirá al usuario la
observar un historial de uso, con la fecha
gestión de los registros Kardex.
respectiva.
12. Diagrama de flujo de datos

12.1 Nivel 0
Descripción: Diagrama de flujos de datos donde se especifica el nombre del proyecto junto
con sus módulos correspondientes.
18
12.2 Nivel 1
Escenario: Inicio de sesión
Descripción: El sistema permitirá al usuario ingresar a su perfil, con un usuario y
contraseña ya establecida.
19
12.3 Nivel 2
Escenario: Eliminar los registros ya pasados de fecha.
Descripción: Debe permitir al usuario eliminar todos los registros que estén pasados
de fecha para fomentar el orden de la base de datos
Escenario: Visualización de los informes de registros semanales.

Descripción: El sistema debe permitir visualizar los informes de los registros
semanales y notificar los registros semanales de cada fecha en indicada,
Escenario: Observación del historial de uso.

Descripción: El sistema de permitir generar una observación de todo el historial de
uso que se va generando en la base de datos
20
Escenario: Ingreso del usuario a su perfil.
Descripción: El sistema debe permitir el ingreso solo a usuarios autorizados
dependiendo al perfil que pertenece el usuario
Escenario: Visualización de los datos personales del usuario.

Descripción: El sistema debe permitir al usuario visualizar los datos personales de
cada uno de los usuarios que están registrados en la base de datos
21
Escenario: Visualización del registro de los pacientes.
Descripción: El sistema debe permitir visualizar los registros de cada uno de los
pacientes que se ban integrando al plantel con la ayuda de la base de datos.
Escenario: Visualización de los datos de afiliación del paciente.

Descripción: El sistema debe permitir a los usuarios visualizar a los pacientes que son
afiliados, todo está ya guardados en nuestra base de datos.
Escenario: Gestión de los registros Kardex.
22
Descripción: El sistema debe permitir gestionar cada uno de los registros en Kardex
que se va implementado al sistema, donde puedan generar reportes si es necesario
12.4 Nivel 3
Descripción: El sistema eliminara los registros ya pasados de fecha en un rango de dos

años.
23
Descripción: El sistema debe contabilizar de forma automatizada el número de
registros semanales, a lo que se creara un informe con los detalles de los registros.

Descripción: El sistema permitirá al usuario observar un historial de uso, con la fecha
respectiva, a lo cual también podrá ser eliminado.

24
Descripción: El sistema permitirá al usuario visualizar sus datos personales
registrados en el sistema tales como sus nombres, apellidos, número de cédula, títulos,
fecha de nacimientos, etc.

Descripción: El sistema permitirá al usuario visualizar el registro del paciente,
solamente si ya tiene uno existente, donde se detallará cada uno de sus datos de
afiliación.
25
Descripción: El sistema permitirá al usuario visualizar los datos de afiliación del
paciente tales como los nombres, apellidos, numero de cedula, fecha de ingreso, etc.

Descripción: El sistema permitirá al usuario la gestión de los registros Kardex es decir
podrá insertar datos, eliminar, buscar, modificar y eliminar.
26
13. Casos de Usos UML
13.1 Nivel 0
Escenario: Automatización de registros de Kardex para el personal de enfermería en
el hospital básico de Sangolquí
13.2 Nivel 1
Escenario: Iniciar Sesión
27
Escenario: Visualizar Perfiles

Descripción: El usuario podrá observar tanto su perfil como el del paciente con su
diagnóstico.
Escenario: Gestionar Kardex

Descripción: El usuario podrá insertar, modificar y eliminar los registros Kardex
después de seleccionar el diagnóstico del paciente.
Escenario: Utilizar el sistema general

Descripción: En este módulo el usuario podrá revisar y eliminar el historial de uso,
verificar si los registros ya pasados de fecha fueron eliminados y revisar además de
eliminar el informe semanal de Kardex.
28
13.3 Nivel 2
Descripción: El sistema eliminara los registros ya pasados de fecha en un rango de dos

años.
Caso de Uso: Visualizar los registros ya Identificador: CU01

pasados de fecha.
Autor: Torres Roberth
Fecha: 2023-01-28
Actores: Enfermera/o
Tipo: Secundario
Referencias: El sistema eliminara los registros ya pasados de fecha
Precondición: El usuario debe iniciar sesión e ingresar a la opción Kardex.
Postcondición: La interfaz nos mostrara los registros Kardex enlistados.
Descripción: El sistema elimina los registros Kardex que tengan dos años en la base de
datos.
Resumen: Eliminación de registros con dos años de permanencia.
29
Flujo normal
N° Ejecutar Paso o Actividad

1 El actor selecciona la opción Kardex. Seleccionar opción del menú.
2 El sistema muestra una opción para buscar Búsqueda de registros Kardex.
cualquier registro.
3 El actor ingresa los parámetros de Ingreso de parámetros de búsqueda,
búsqueda.
Flujo Alterno
N° Descripción de las opciones alternas

3.1 El sistema valida el parámetro de búsqueda establecido.
3.1. A El usuario ingresa la fecha de la creación del registro Kardex.
3.1. A.1 El sistema muestra una notificación de documento no encontrado.

Descripción: El sistema debe contabilizar de forma automatizada el número de
registros semanales, a lo que se creara un informe con los detalles de los registros.
Caso de Uso: Visualizar los informes de Identificador: CU02
30
registros semanales.
Fecha: 2023-01-28
Tipo: Secundario
Referencias: El sistema debe contabilizar de forma automatizada el número de registros
semanales.
Precondición: El usuario debe iniciar sesión e ingresar a la opción Kardex, escoger opción
informe semanal.
Postcondición: La interfaz nos mostrara el menú de la opción Kardex.
Descripción: Permite visualizar al usuario los informes de registros semanales.
Resumen: Visualizar los registros Kardex semanales.
Flujo normal

1 El actor selecciona la opción llamado Selección de la opción Kardex.
Kardex.
2 El sistema muestra un menú de opciones. Visualización de menú de opciones.
3 El actor selecciona la opción informe Selección de informe semanal.
semanal.
4 El actor ingresa el parámetro de búsqueda. Ingreso del parámetro de búsqueda.
Flujo Alterno

4.1. A El usuario ingresa el rango de fechas para el informe semanal.
4.1. A.1 El sistema muestra una notificación de fecha no encontrada.
4.1. A.2 El sistema muestra una lista de los Kardex creados en esa fecha.

Caso de Uso: Modificar los informes de Identificador: CU03
31
Fecha: 2023-01-28
Tipo: Secundario
semanales.
informe semanal y debe estar en el formulario buscar informe.
Postcondición: La interfaz nos mostrara el formulario buscar informe.
Descripción: Permite modificar al usuario los informes de registros semanales.
Resumen: Modificar los registros Kardex semanales.
Flujo normal

1 El actor ingresa el parámetro de búsqueda. Ingreso de parámetro de búsqueda.
2 El sistema refleja el registro de búsqueda Registro encontrado.
encontrado.
3 El usuario selecciona la opción modificar Selección del registro a eliminar.
acorde al registro a actualizar.
4 El sistema nos refleja el formulario a Visualización del formulario a
modificar. modificar.
5 El usuario ingresa los datos a modificar Ingreso de datos.
6 El usuario selecciona la opción guardar. Selección de la opción guardar.
Flujo Alterno

1.1. A El usuario ingresa el rango de fechas para el informe semanal.
1.1. A.1 El sistema muestra una notificación de fecha no encontrada.
1.1. A.2 El sistema muestra una lista de los Kardex creados en esa fecha.
32
1.2 El usuario ingresa un nuevo parámetro de búsqueda.
3.1 El sistema muestra un mensaje de notificación.
3.1.A El usuario selecciona la opción SI
3.1.B El usuario selecciona la opción SI
5.1 El sistema valida que los campos no estén vacíos.
5.2 El sistema valida que la fecha debe estar en el rango del año actual.
5.3 El sistema valida que el nombre del responsable debe ser solamente texto.
6.1 El sistema refleja una notificación de guardar datos
6.1.A El usuario selecciona la opción de que si desea guardar.
6.1.A.1 El sistema refleja una notificación de que se guardaron los datos.
6.1.B El usuario selecciona la opción de que no desea guardar.
6.1.B.1 El sistema refleja una notificación de que se mantuvieron los datos que estaban.

Caso de Uso: Eliminar los informes de registros Identificador: CU4
semanales.
Autor: Jácome Valeria
Fecha: 2023-01-30
Tipo: Secundario
semanales.
informe semanal y debe estar en el formulario buscar informe.
Postcondición: La interfaz nos mostrara el formulario buscar informe.
Descripción: El sistema permitirá al actor eliminar una o varios informes guardados con
anterioridad.
Resumen: Eliminación de informes creados.
Flujo normal
No Ejecutar Paso o Actividad

1 El usuario ingresa el parámetro de búsqueda. Ingreso de parámetro de búsqueda
33
2 El sistema visualiza los informes a eliminar. Visualización de informes
3 El usuario selecciona la opción eliminar. Selección de opción eliminar
Flujo Alterno
No Descripción de las opciones alternas

1.1 El sistema valida los parámetros de búsqueda.
1.1.a El usuario ingresa el rango de fecha.
1.1.a.1 El sistema devuelve el informe.
1.1.a.2 El sistema genera una notificación de informe no encontrado.
1.1.b El actor no ingresa parámetros de búsqueda.
1.1.b.1 El sistema notifica que debe ingresar un parámetro de búsqueda.
1.2 El usuario ingresa nuevos parámetros de búsqueda.
3.1 El sistema genera una notificación de eliminación de documento.
3.1.a El usuario selecciona la opción que si desea eliminar el informe.
3.1.a.1 El sistema genera una notificación de eliminación de registro.
3.1.b El usuario selecciona la opción que no desea eliminar el informe.
3.1.b.1 El sistema devuelve una notificación de cancelación.

Descripción: El sistema permitirá al usuario observar un historial de uso, con la fecha
respectiva, a lo cual también podrá ser eliminado.
34
Caso de Uso: Visualizar los informes de Identificador: CU05
Fecha: 2023-01-28
Tipo: Secundario
Referencias: El sistema permitirá al usuario observar un historial de uso.
historial de uso.
Descripción: Permite visualizar al usuario el historial de uso.
Resumen: Visualizar el historial de uso.
Flujo normal

1 El actor selecciona la opción llamado Selección de la opción Kardex.
Kardex.
3 El actor selecciona la opción historial de Selección de informe semanal.
uso.
4 El actor ingresa el parámetro de búsqueda. Ingreso del parámetro de búsqueda.
Flujo Alterno

4.1. A El usuario ingresa el rango de fechas para el observar el historial de uso.
4.1. A.1 El sistema muestra una notificación de fechas no encontradas.
4.1. A.2 El sistema muestra una lista del historial de uso.
35
Caso de Uso: Eliminar el historial de uso. Identificador: CU6
Fecha: 2023-01-30
Tipo: Secundario
Referencias: El sistema permitirá al usuario observar un historial de uso.
historial de uso e ingresar el parámetro de búsqueda.
Descripción: El sistema permitirá al actor eliminar una o varias fechas de historial de uso.
Resumen: Eliminación de historial de uso.
Flujo normal

1 El usuario ingresa el parámetro de búsqueda. Ingreso de parámetro de búsqueda
2 El sistema visualiza las fechas a eliminar. Visualización de fechas
3 El usuario selecciona la opción eliminar. Selección de opción eliminar
Flujo Alterno

1.1.a El usuario ingresa el rango de fecha.
1.1.a.1 El sistema devuelve el historial.
1.1.a.2 El sistema genera una notificación de fechas no encontradas.
1.1.b El usuario no ingresa parámetros de búsqueda.
3.1 El sistema genera una notificación de eliminación de historial.
3.1.a El usuario selecciona la opción que si desea eliminar el documento.
3.1.a.1 El sistema genera una notificación de eliminación de historial.
36
3.1.b El usuario selecciona la opción que no desea eliminar el historial.

CU: Ingresar a la aplicación Identificador: CU07

AUTOR: Valeria Jácome
FECHA: 19/1/2023
ACTOR/ES: Enfermera/o
REFERENCIA: El sistema debe permitir al gerente y al administrador de la empresa
ingresar a la aplicación con su correo y contraseña.
PRECONDICION: Los actores debe iniciar sección, deben seleccionar a que tipo de
usuario pertenece, debe ingresar su correo y contraseña.
POSCONDICION: Ingresar los parámetros que solicita la aplicación para los
actores
DESCRIPCION: Los actores podrán iniciar sección al tipo de usuario que pertenece
en la aplicación.
RESUMEN: Iniciar sesión
Flujos normales
N- EJECUTAR PASO O ACTIVIAD

1 El actor selecciona a que tipo de Seleccionan al tipo de usuario que
usuario pertenece pertenecen
2 El sistema muestra los campos de Visualizan los campos que deben
iniciar sesión ingresar
37
3 El actor ingresa su correo y Ingreso de parámetros de ingreso
contraseña correspondiente
4 El sistema verifica si son correctos Verifica los campos
los campos
5 El actor ingresa a la aplicación Inician sección a la aplicación
Flujos alternos
N- DESCRIPCIÓN DE ACCIONES ALTERNAS

1.1 El actor selecciona a que tipo de usuario pertenece
1.1. A El sistema da dos opciones de selección de gerente y usuario
1.1. B El actor selecciona la opción de actor
1.1. C El actor selecciona la opción del gerente
3.1 El actor ingresa el correo y contraseña
3.A El sistema debe llenar los campos obligatoriamente
4.1.A El sistema notificara si son correctos los campos.
4.4.B El sistema notificara si son erróneos los datos.
5.1 Es sistema debe notificar que iniciaron sesión

Descripción: El sistema permitirá al usuario visualizar sus datos personales
registrados en el sistema tales como sus nombres, apellidos, número de cédula, títulos,
fecha de nacimientos, etc.
Caso de Uso: Visualizar los datos Identificador: CU08

personales.
38
Fecha: 2023-01-28
Tipo: Primario
Referencias: El sistema permitirá al usuario visualizar sus datos personales registrados en
el sistema.
Precondición: El usuario debe iniciar sesión.
Postcondición: La interfaz nos mostrara los datos personales del usuario.
Descripción: Permite visualizar al usuario sus datos personales.
Resumen: Visualizar perfil de usuario.
Flujo normal

1 El actor debe iniciar sesión Iniciar sesión.
3 El actor selecciona la opción perfil. Selección de perfil de usuario.
Flujo Alterno

1.1 El actor ingresa su usuario y contraseña.
1.1.A El sistema visualiza una notificación de datos ingresados erróneamente.
1.1.B El sistema visualiza una notificación de datos ingresados correctamente.
1.1.C El sistema visualiza una notificación de que ingrese datos a los campos.

Descripción: El sistema permitirá al usuario visualizar el registro del paciente,
solamente si ya tiene uno existente, donde se detallará cada uno de sus datos de
afiliación.
39
Caso de Uso: Visualizar los registros de los Identificador: CU08
pacientes.
Fecha: 2023-01-28
Tipo: Primario
Referencias: El sistema permitirá al usuario visualizar el registro del paciente, solamente
si ya tiene uno existente.
Precondición: El usuario debe iniciar sesión y escoger la opción paciente.
Postcondición: La interfaz nos mostrara los datos del paciente escogido.
Descripción: Permite visualizar el registro de los pacientes.
Resumen: Visualizar registro de pacientes.
Flujo normal

1 El actor selecciona la opción paciente. Selección de la opción paciente.
2 El sistema visualiza el listado de los Visualización de pacientes.
pacientes
3 El actor selecciona al paciente. Selección del paciente.
Flujo Alterno

3.1 El sistema genera una notificación de selección.
3.1.a Los usuarios seleccionan la opción que si desea seleccionar al paciente.
40
3.1.a.1 El sistema genera una notificación de paciente seleccionado.
3.1.b El usuario selecciona la opción que no desea seleccionar al paciente.

Descripción: El sistema permitirá al usuario visualizar los datos de afiliación del
paciente tales como los nombres, apellidos, numero de cedula, fecha de ingreso, etc.
Caso de Uso: Visualizar los datos de Identificador: CU09

afiliación del paciente
Fecha: 2023-01-28
Tipo: Primario
Referencias: El sistema permitirá al usuario visualizar los datos de afiliación del paciente.
Precondición: El usuario debe iniciar sesión, escoger la opción paciente y escoger el
paciente deseado.
Postcondición: La interfaz nos mostrara el registro de Kardex.
Descripción: Permite visualizar los datos de afiliación del paciente junto con sus
diagnósticos.
Resumen: Visualizar datos de los pacientes.
Flujo normal
41
1 El actor selecciona la opción paciente. Selección de la opción paciente.
2 El sistema visualiza el listado de los Visualización de pacientes.
pacientes
3 El actor selecciona al paciente. Selección del paciente.
4 El actor selecciona el diagnóstico del Selección del diagnóstico.
paciente.
Flujo Alterno

3.1.a El usuario selecciona la opción que si desea seleccionar al paciente.
3.1.a.1 El sistema genera una notificación de paciente seleccionado.
3.1.b El usuario selecciona la opción que no desea seleccionar al paciente.
4.1.a El usuario selecciona la opción que si desea seleccionar ese diagnóstico.
4.1.a.1 El sistema genera una notificación de diagnóstico seleccionado.
4.1.b El usuario selecciona la opción que no desea seleccionar el diagnóstico.

Descripción: El sistema permitirá al usuario la gestión de los registros Kardex es decir
podrá insertar datos, eliminar, buscar, modificar y eliminar.
42
Caso de Uso: Insertar registros Kardex Identificador: CU010
Fecha: 2023-01-30
Tipo: Primario
Referencias: El sistema permitirá al usuario la gestión de los registros Kardex.
paciente y escoger el diagnóstico.
Postcondición: Formulario ingresar registros Kardex.
Descripción: El personal de enfermería podrán insertar datos en los registros Kardex.
Resumen: Insertar datos en los registros Kardex.
Flujo normal

1 El actor ingresa los datos en los campos Ingreso los datos en los campos.
43
correspondientes al formulario ingresar
registros Kardex.
2 Los actores seleccionan la opción guardar Selección opción guardar.
Flujo Alterno

3.1 El actor ingresa los datos incorrectos en cada uno de los campos del formulario.
3.1.A El sistema debe generar una notificación de datos incorrectos.
3.1.B El actor ingresa nuevamente los datos de forma correcta.
2.1 El sistema genera una notificación de confirmación de guardar datos.
2.1.A El actor selecciona la opción de SI para guardar los datos del formulario.
2.1.A. El sistema almacena los datos ingresados en la base de datos.
1
2.1.B El actor selecciona la opción de NO.
2.1.B.1 El sistema genera una notificación de no almacenamiento de datos.
2.1.B.2 El sistema permanece en el formulario y conserva los datos ingresados
previamente.
2.2 El actor selecciona la opción cancelar.
Caso de Uso: Modificar registros Kardex Identificador: CU012

Fecha: 2023-01-30
Tipo: Primario
Postcondición: Formulario listar registros Kardex.
Descripción: Permite al actor modificar los registros Kardex.
Resumen: Modificar registros Kardex.
Flujo normal
44
1 El actor ingresa el parámetro de búsqueda. Ingresar el parámetro de búsqueda.
2 El sistema muestra el / los registros de la Registro o registros encontrados.
búsqueda previa.
3 El actor selecciona la opción de modificar Seleccionar la opción modificar.
del registro a actualizar.
4 El sistema visualiza el formulario con los Visualización del formulario a
datos a modificar. modificar.
5 El usuario ingresa los nuevos datos a Ingreso de los nuevos datos.
modificar.
6 El usuario selecciona la opción guardar. Seleccionar la opción guardar.
Flujo Alterno

1.1. A El usuario ingresa el nombre del responsable del registro.
1.1. A.1 El sistema devuelve uno o varios registros.
1.1. A.2 El sistema muestra una notificación de registro no encontrado.
1.1. B El usuario ingresa la fecha de documento.
1.1. B.1 El sistema devuelve uno o varios registros.
1.1. B.2 El sistema muestra una notificación de registro no encontrado.
1.2 El sistema muestra una notificación de que no hay registros existentes.
5.1 El sistema valida los campos del formulario
5.1.A El sistema muestra una notificación de que existen datos erróneos.
5.1.A.1 El sistema valida que los campos estén llenos.
5.1.A.1.1 El sistema muestra una notificación de que existen campos vacíos
6.1 El usuario selecciona la opción guardar
6.1.A El sistema genera una confirmación para guardar datos
6.1.A.1 El usuario selecciona la opción “si”
6.1.A.1.1 El sistema genera una notificación de los datos se han guardado correctamente.
6.1.A.1.2 El sistema nos direcciona a listar documentos.
6.1.A.2 El usuario selecciona la opción “no”
45
6.1.A.2.1 El formulario se modificar datos se mantiene con los datos previamente
ingresados
6.2 El usuario selecciona la opción cancelar
6.2.A El sistema genera una notificación de confirmación
6.2.A.1 El usuario selecciona la opción “cancelar”
6.2.A.1.1 El sistema nos direcciona a listar documentos
6.2.A.2.1 El usuario selecciona la opción “no”
6.2.A.2.2 El formulario de modificar datos se mantiene.

Caso de Uso: Visualizar registros Kardex Identificador: CU12
Fecha: 2023-01-30
Tipo: Primario
Postcondición: Formulario listar registros Kardex.
Descripción: El actor podrá visualizar los registros Kardex generados anteriormente.
Resumen: Visualizar los registros Kardex.
Flujo normal

1 Los actores deben seleccionar la opción Selección de la opción Kardex.
Kardex.
2 El sistema muestra el listado de todos los Visualización de los documentos
documentos generados con anterioridad.
3 El actor ingresa los parámetros de búsqueda Ingreso de parámetro de búsqueda
Flujo Alterno
46
3.1 El sistema validara el parámetro de búsqueda ingresado.
3.1. a El sistema visualiza los registros de acuerdo a los parámetros establecidos
previamente.
3.1. b El sistema notificara el documento no encontrado.

Caso de Uso: Eliminar registros Kardex Identificador: CU13
Fecha: 2023-01-19
Tipo: Primario
Postcondición: Historial de documentación.
Descripción: Formulario listar registros Kardex.
Resumen: Eliminación de registro de Kardex.
Flujo normal

1 Los actores ingresan el parámetro de Ingreso de parámetro de búsqueda
búsqueda.
2 El sistema visualiza los registros a eliminar. Visualización de documentación
3 Los usuarios seleccionan la opción eliminar. Selección de opción eliminar
Flujo Alterno

1.1.a El usuario ingresa la fecha del registro.
47
1.1.a.1 El sistema devuelve el registro.
1.1.a.2 El sistema genera una notificación de registro no encontrado.
1.1.b El actor no ingresa parámetros de búsqueda.
3.1 El sistema genera una notificación de eliminación de registro.
3.1.a Los usuarios seleccionan la opción que si desea eliminar el registro.
3.1.a.1 El sistema genera una notificación de eliminación de registro.
3.1.b El usuario selecciona la opción que no desea eliminar el registro.
14. Prototipo
Tema: Automatización de Registros De Kardex para el Personal de Enfermería en el
Hospital Básico De Sangolquí
Evidencia
Interfaz del prototipo del aplicativo
Inicio de Sesión: En esta pantalla se muestra el login que tendrá nuestro aplicativo,
donde se ingresará el usuario y la contraseña.
Perfil de usuario: Aquí se observa como se refleja los datos del usuario, dependiendo de
quien ingrese los datos se reflegara su informacion.
48
Listado de pacientes: Aquí se reflejará todos los pacientes que fueron registrados en
hospitalización con cedula, nombre y fecha de ingreso respectiva.
Perfil de paciente: En esta parte se refleja los datos de afiliacion del paciente que se escogio,
junto con los diagnosticos dados, donde se reflejara tanto el nombre del medicamento como
el medico que lo trato.
49
Kardex: En esta parte se podra ingresar los registros de Kardex, donde se podra registrar,
eliminar y modificar.
Modificacion del Kardex: Aquí se puede observar que se podra modificar cualquier kardex
seleccionado.
50
Codigo en HTML y CSS
Index: Inicio del aplicativo web.
PHP: Conexión con la base de datos
51
CSS: Estilos del aplicativo
PHP y HTML: Código para el registro de Kardex
52
15. Diagrama de clases
53
16. Diagrama Lógico
17. Diagrama Físico
54
15. Script BBDD
CREATE TABLE diagnostico (
codigo_dia VARCHAR2(15) NOT NULL,
nombre_dia unknown
-- ERROR: Datatype UNKNOWN is not allowed
NOT NULL,
fecha_dia DATE NOT NULL,
nombredoc_dia VARCHAR2(50) NOT NULL,
observacion_dia VARCHAR2(100) NOT NULL,
medicamento_dia VARCHAR2(100) NOT NULL,
cantidad_dia INTEGER NOT NULL,
viadmis_dia VARCHAR2(50) NOT NULL,
horario_dia INTEGER NOT NULL,
paciente_id_pac unknown
NOT NULL
);
ALTER TABLE diagnostico ADD CONSTRAINT diagnostico_pk PRIMARY KEY ( codigo_dia );
CREATE TABLE enfermeria (
id_enf VARCHAR2(15) NOT NULL,
nombres_enf VARCHAR2(50) NOT NULL,
apellidos_enf VARCHAR2(50) NOT NULL,
senecyt_enf VARCHAR2(50) NOT NULL,
acces_enf VARCHAR2(50) NOT NULL,
fechan_enf DATE NOT NULL,
edad_enf INTEGER NOT NULL,
titulo3_enf VARCHAR2(50) NOT NULL,
titulo4_enf VARCHAR2(50) NOT NULL,
pass_enf VARCHAR2(50) NOT NULL,
correo_enf VARCHAR2(50) NOT NULL
);
55
ALTER TABLE enfermeria ADD CONSTRAINT enfermeria_pk PRIMARY KEY ( id_enf );
CREATE TABLE kardex (
codigo_kar VARCHAR2(15) NOT NULL,
fecha_kar DATE NOT NULL,
hora_kar DATE NOT NULL,
responsable_kar VARCHAR2(50) NOT NULL,
funcion_kar VARCHAR2(50) NOT NULL,
observacion_kar VARCHAR2(100) NOT NULL,
diagnostico_codigo_dia VARCHAR2(15) NOT NULL
);
CREATE UNIQUE INDEX kardex__idx ON
kardex (
diagnostico_codigo_dia
ASC );
ALTER TABLE kardex ADD CONSTRAINT kardex_pk PRIMARY KEY ( codigo_kar );
CREATE TABLE paciente (
id_pac unknown
NOT NULL,
nombres_pac unknown
NOT NULL,
apellidos_pac unknown
NOT NULL,
fechan_pac DATE NOT NULL,
edad_pac INTEGER NOT NULL,
numcama_pac VARCHAR2(10) NOT NULL,
fechaingre DATE NOT NULL,
enfermeria_id_enf VARCHAR2(15) NOT NULL
);
56
ALTER TABLE paciente ADD CONSTRAINT paciente_pk PRIMARY KEY ( id_pac );
ALTER TABLE diagnostico
ADD CONSTRAINT diagnostico_paciente_fk FOREIGN KEY ( paciente_id_pac )
REFERENCES paciente ( id_pac );
ALTER TABLE kardex
ADD CONSTRAINT kardex_diagnostico_fk FOREIGN KEY ( diagnostico_codigo_dia )
REFERENCES diagnostico ( codigo_dia );
ALTER TABLE paciente
ADD CONSTRAINT paciente_enfermeria_fk FOREIGN KEY ( enfermeria_id_enf )
REFERENCES enfermeria ( id_enf );
57
16. Diagrama de Actividades
Vamos a generar nuestro diagrama de actividades la parte en que el usuario ingresa los
registros
Vamos a generar nuestro diagrama de actividades la parte en que el usuario busque los
registros
58
Vamos a generar nuestro diagrama de actividades la parte en que el usuario puede
eliminar los registros
17.
59
Vamos a generar nuestro diagrama de actividades la parte en que el usuario pueda
modificar los registros
60
Descripción: Vamos a generar un diagrama sobre las actividades que debe cumplir para
visualizar los informes de registró semanal
61
18. Conclusiones
 Se logro desarrollar un prototipo funcional del aplicativo web que se planteó desde el
inicio con los requisitos e ideas que se propusieron, el desarrollo del prototipo sirvió
en gran parte para mejorar el rendimiento grupal al igual que el individual,
proporcionándonos experiencia y una mayor resolución de problemas para futuros
proyectos.
 La realización de pruebas, cronogramas, reglas de negocio, requisitos funcionales,
diagrama de flujo de datos, diagrama de caso de usos, etc. Fue de gran ayuda para el
desarrollo del prototipo, ya que ayudo a tener un orden optimo en los pasos
realizados, además permitió reducir en gran parte los márgenes de errores y tiempo
que podían provocarse, si no existía un plan claro a realizar desde el inicio.
 El prototipo desarrollado se podrá seguir mejorando para que en un futuro puede ser
utilizado en áreas donde se necesite este sistema, permitiéndonos tener una
vinculación con la sociedad.
19. Recomendaciones
 Es recomendable tener buena comunicación con el equipo de trabajo, porque en caso
contrario podría perjudicar potencialmente el desarrollo del programa, es necesario
establecer un buen ambiente de trabajo para evitar conflictos y mala sinergia en los
desarrolladores e incluso al sabotaje intencional y no intencional.
 Es importante que se controle el tema económico en el desarrollo del programa, por
lo tanto, es útil utilizar mitigaciones en los posibles riesgos que nos podemos
enfrentar, así reduciremos en gran medida los costos.
 Tener las mejores herramientas para generar los diagramas son lo más primordial una
de las plataformas que más recomiendo el visual paradigma, es una herramienta
cómoda y clara a la hora de utilizarla, nos ayuda a generar tiempo y crear mejores
decisiones de trabajo al elaborar nuestros proyectos, también es tener en claro de que
se trata el proyecto cuales son son funcionalidades.
20. Bibliografía
EcuRed. (16 de 10 de 2015). EcuRed. Obtenido de EcuRed:
https://www.ecured.cu/Requisitos_no_funcionales
Gómez, R. P. (s.f.). ecured. Obtenido de ecured.
Krall, C. (s.f.). aprenderaprogramar. Obtenido de aprenderaprogramar.
62
PMOinformatica.com. (30 de MAYO de 2018). La oficina de proyectos de informática.
Obtenido de La oficina de proyectos de informática:
http://www.pmoinformatica.com/2018/05/que-es-requerimiento-funcional.html
Significados. (30 de Octubre de 2022). Significados. Obtenido de Significados:
https://webcache.googleusercontent.com/
Software, P. d. (3 de Noviembre de 2012). Paradigmas de la Ingeniería de Software.
Obtenido de Paradigmas de la Ingeniería de Software:
https://sites.google.com/site/paradigmasdelais/
theastrologypage. (2019). strologypage. Obtenido de strologypage.
Tipantuña, K. (s.f.). Ciencias Datos. Obtenido de Ciencias Datos.
Andrade, L. (25 de Agosto de 2020). LUCIDCHART . Obtenido de
https://www.lucidchart.com/pages/es/tutorial-de-diagrama-de-clases-uml
Granollers, T. (30 de Julio de 2014). mpiua . Obtenido de
https://mpiua.invid.udl.cat/prototipos-software/
Lopez, F. (15 de Marzo de 2019). MLCONSULTORES . Obtenido de
https://www.mlconsultores.com/visual-paradigm/
63

Proyecto Trabajo Grupal Final

Cargado por

Información del documento

Descripción original:

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Proyecto Trabajo Grupal Final

Cargado por

Copyright:

Formatos disponibles

UNIVERSIDAD TÉCNICA DE COTOPAXI

FACULTAD DE CIENCIAS DE LA INGENIERIA Y

MATERIA: ANÁLISIS Y DISEÑO DE SISTEMAS DE

TEMA: AUTOMATIZACIÓN DE REGISTROS DE KARDEX

DOCENTE: ING. EDWIN QUINATOA

Los datos de afiliación de los pacientes a Perdida de datos de afiliación de cada

Los procesos manuales son llevados de Incomodidad y pérdida de tiempo reflejada en

En caso de conflictos legales la información Manipulación de evidencia y como efecto la

Los medicamentos LASA conlleva una Errores en la administración de

¿Cuánto se demora en registrar los 5-10 minutos 0

¿Con cuanta frecuencia usted repite un 1-2 veces 1

¿Usted se considerada apto para Si 10 ¿Usted se considerada apto para

¿Existen con funciones de tipogra-

¿Estaría dispuesto a utilizar un Si 10

Rol Nombre Descripción

Jefe de Proyecto Jácome Valeria Organización y planificación de

Analista Torres Roberth Elaboración y aplicación de encuestas y

Analista Jácome Valeria Definir los requisitos funcionales y no

Analista Simba Danny Realización del diagrama de flujo de datos

Analista Logacho Angelica Elaboración del diagrama de flujo de datos

Programador Jácome Valeria Desarrollo del código para el login, perfil

Programador Torres Roberth Desarrollo del código para el perfil del

Tester Simba Danny Generar un plan de pruebas, ejecución de

Tester Logacho Angelica Generación de informe de las pruebas

7.2 Requisitos funcionales

7.3 Requisitos no funcionales

7.4 Modelo Estructurado

7.5 Modelo orientado a objetos

7.6 Lenguaje de modelado unificado (UML)

7.7 Herramientas CASE

7.8 Power Designer

7.9 Visual Parading

7.11 Prototipo de software

RF006.-El sistema permitirá al usuario ingresar a su perfil, con un usuario y contraseña

10. Requisitos no funcionales

11. Especificación de módulos

RF006.-El sistema permitirá al usuario RF001: El sistema enviará o mostrará una

12. Diagrama de flujo de datos

Escenario: Visualización de los informes de registros semanales.

Escenario: Observación del historial de uso.

Escenario: Visualización de los datos personales del usuario.

Escenario: Visualización de los datos de afiliación del paciente.

Escenario: Gestión de los registros Kardex.

Descripción: El sistema eliminara los registros ya pasados de fecha en un rango de dos

Escenario: Visualización de los informes de registros semanales.

Escenario: Observación del historial de uso.

Escenario: Ingreso del usuario a su perfil.

Escenario: Visualización del registro de los pacientes.

Escenario: Gestión de los registros Kardex.

Escenario: Visualizar Perfiles

Escenario: Gestionar Kardex

Escenario: Utilizar el sistema general

Descripción: El sistema eliminara los registros ya pasados de fecha en un rango de dos

Caso de Uso: Visualizar los registros ya Identificador: CU01

N° Ejecutar Paso o Actividad

N° Descripción de las opciones alternas

Escenario: Visualización de los informes de registros semanales.

Caso de Uso: Visualizar los informes de Identificador: CU02

N° Ejecutar Paso o Actividad

N° Descripción de las opciones alternas

Escenario: Visualización de los informes de registros semanales.

N° Ejecutar Paso o Actividad