Tesis Referencia

UNIVERSIDAD MAYOR DE SAN ANDRÉS
FACULTAD DE CIENCIAS PURAS Y NATURALES

CARRERA DE INFORMÁTICA
PROYECTO DE GRADO
“SISTEMA DE GESTIÓN DE INFORMACIÓN

CLÍNICA”
CASO: CARRERA DE ENFERMERÍA
PARA OPTAR AL TÍTULO DE LICENCIATURA EN INFORMÁTICA
MENCIÓN INGENIERÍA DE SISTEMAS INFORMÁTICOS
POSTULANTE: JORGE ABIMAEL LARA TICONA

TUTOR METODOLÓGICO: M. SC. ROSA FLORES MORALES
ASESOR: LIC. CARMEN ROSA HUANCA QUISBERT
LA PAZ – BOLIVIA
Junio, 2018
FACULTAD DE CIENCIAS PURAS Y NATURALES
CARRERA DE INFORMÁTICA
LA CARRERA DE INFORMÁTICA DE LA FACULTAD DE CIENCIAS PURAS Y

NATURALES PERTENECIENTE A LA UNIVERSIDAD MAYOR DE SAN ANDRÉS
AUTORIZA EL USO DE LA INFORMACIÓN CONTENIDA EN ESTE
DOCUMENTO SI LOS PROPÓSITOS SON ESTRICTAMENTE ACADÉMICOS.
LICENCIA DE USO
El usuario está autorizado a:
a) visualizar el documento mediante el uso de un ordenador o dispositivo móvil.

b) copiar, almacenar o imprimir si ha de ser de uso exclusivamente personal y privado.
c) copiar textualmente parte(s) de su contenido mencionando la fuente y/o haciendo la
referencia correspondiente respetando normas de redacción e investigación.
El usuario no puede publicar, distribuir o realizar emisión o exhibición alguna de este

material, sin la autorización correspondiente.
TODOS LOS DERECHOS RESERVADOS. EL USO NO AUTORIZADO DE LOS

CONTENIDOS PUBLICADOS EN ESTE SITIO DERIVARA EN EL INICIO DE
ACCIONES LEGALES CONTEMPLADOS EN LA LEY DE DERECHOS DE AUTOR.
Dedicatoria
A mi querida familia por estar
siempre a mi lado brindándome
apoyo incondicional en todo
momento.
I
AGRADECIMIENTOS
Primero agradecer a Dios por haberme dado una familia, amigos y una vida
maravillosa.
A la Directora de la carrera de Enfermería M. Sc. María Eugenia Mendoza Fernández,

con su gran calidad como persona y profesionalismo me brindó la oportunidad de
trabajar en su entorno y motivar al desarrollo del presente trabajo.
A mi Tutora M. Sc. Rosa Flores Morales, quien, con su gran calidad como persona,
profesionalismo y experiencia, quien acompaño el desarrollo de este trabajo desde los
inicios apoyando y aportando siempre con sus conocimientos y consejos oportunos.
A mi asesora Lic. Carmen Rosa Huanca Quisbert, quien con gran calidad como
profesional realizó el seguimiento de este trabajo. Los consejos, observaciones,
correcciones, acompañados de su larga experiencia fueron un aporte invaluable para la
elaboración de este proyecto.
Al Lic. Florencio Antonio Mamani por haberme brindado la oportunidad de adquirir

nuevos conocimientos y también a supervisar el presente proyecto.
A la Lic. Ana Rosalía Choque Pacosillo por incentivar y apoyar el desarrollo del
presente proyecto.
Y por último a todos mis amigos de la universidad y compañeros de trabajo por

brindarme esa gran amistad el cual siempre me motivo a dar lo mejor por ellos.
II
RESUMEN
El presente proyecto de grado titulado “Sistema de Gestión de Información Clínica

Caso: Carrera de Enfermería” se clasifica dentro de los Sistemas de Información, los
mismos que son considerados como aplicaciones que ayudan el trabajo diario de
personas dependientes de empresas u organizaciones.
En la actualidad los sistemas de información en el área de la salud se convirtieron en

una pieza fundamental y precisa para el buen desempeño en la atención prestada por
los profesionales de salud, esto para que el desarrollo de sus procesos sustantivos y de
apoyo sean más óptimos y orientados a brindar una mejor atención con calidad y
calidez.
Por la necesidad de informatizar y automatizar las tareas del consultorio de enfermería

es que surge este proyecto de grado, colaborando así con las tareas llevadas a cabo en
el consultorio, obteniendo a la vez información actualizada y disponible para el
personal administrador del consultorio.
El sistema de Gestión de Información Clínica, posee los siguientes módulos: Atención

de pacientes, que realiza el registro de información personal y registro de atención del
paciente; Administración de insumos, que se realiza el registro de ingreso y uso de
insumos del consultorio; Personal enfermero, realiza el registro de la información y
habilitación del personal administrativo del consultorio; Servicios y materiales, realiza
el registro de nuevos servicios que se van a brindar en el consultorio, también facilita
el registro de nuevos materiales para poder hacer el ingreso de insumos al consultorio;
Reportes y estadísticas, genera la información requerida por parte del usuario para la
elaboración de informes mensuales de producción.
Este sistema, fue desarrollado con la metodología ágil Scrum el cual permite organizar
y priorizar aspectos esenciales del desarrollo del sistema, responde a una arquitectura
basada en el modelo cliente servidor, y se desarrolló con un gestor de base de datos
MySQL y lenguaje de programación PHP versión 7.
La calidad del producto está basada en la norma de calidad ISO 9126, mediante la cual
se probaron la funcionalidad y usabilidad del sistema. La seguridad está basada a través
de autenticación de usuarios y roles de función para el sistema, además de uso de
encriptación en base64 y md5 propias de PHP.
Palabras clave: sistema, desarrollo de software, metodología ágil, calidad de software,

consultorio de enfermería.
III
ABSTRACT
The present degree project entitled "Clinical Information Management System Case:
Nursing Career" is classified within the Information Systems, which are considered as
applications that help the daily work of dependents of companies or organizations.
Currently, information systems in the area of health have become a fundamental and
precise part of the good performance of the care provided by health professionals, so
that the development of their substantive and support processes is more optimal. and
oriented to provide better care with quality and warmth.
Due to the need to computerize and automate the tasks of the nursing office, this degree
project arises, thus collaborating with the tasks carried out in the office, obtaining at
the same time updated information available for the office administrator staff.
The Clinical Information Management system has the following modules: Patient care,
which records personal information and patient care record; Administration of supplies,
which records the entry and use of supplies of the office; Nursing personnel, performs
the registration of information and habilitation of the administrative staff of the office;
Services and materials, performs the registration of new services that will be provided
in the office, also facilitates the registration of new materials to be able to input inputs
to the office; Reports and statistics, generates the information required by the user for
the production of monthly production reports.
This system was developed with the agile Scrum methodology which allows to
organize and prioritize essential aspects of the development of the system, responds to
an architecture based on the client server model, and was developed with a MySQL
database manager and PHP programming language version 7.
The quality of the product is based on the quality standard ISO 9126, through which
the functionality and usability of the system were tested. Security is based on user
authentication and role roles for the system, as well as the use of PHP base64 and md5
encryption.
Keywords: system, software development, agile methodology, software quality,

nursing office.
IV
ÍNDICE
Capítulo 1................................................................................................................................. 1
Marco Introductorio ............................................................................................................... 1
1.1. Introducción ............................................................................................................ 1
1.2. Antecedentes ............................................................................................................ 2
1.2.1. Antecedentes institucionales................................................................................... 2
1.2.2. Antecedentes Consultorio de Enfermería ............................................................. 4
1.2.3. Proyectos Análogos ................................................................................................. 6
1.3. Descripción del problema ....................................................................................... 7
1.3.1. Problemática ............................................................................................................ 7
1.3.2. Planteamiento del problema .................................................................................. 9
1.4. Objetivos ................................................................................................................ 10
1.4.1. Objetivo General ................................................................................................... 10
1.4.2. Objetivos Específicos ............................................................................................ 10
1.5. Justificación ........................................................................................................... 11
1.5.1. Justificación Técnica ............................................................................................. 11
1.5.2. Justificación Económica ....................................................................................... 12
1.5.3. Justificación Social ................................................................................................ 12
1.6. Límites y/o Alcances ............................................................................................. 12
1.6.1. Limites.................................................................................................................... 12
1.6.2. Alcances ................................................................................................................. 13
1.7. Metodología SCRUM............................................................................................ 14
Capítulo 2............................................................................................................................... 15
Marco Teórico ....................................................................................................................... 15
2.1. Introducción .......................................................................................................... 15
2.2. Sistema de información ........................................................................................ 15
2.3. Arquitectura Cliente Servidor ............................................................................. 17
2.3.1. Cliente .................................................................................................................... 18
2.3.2. Servidor.................................................................................................................. 18
2.4. Arquitectura de software...................................................................................... 19
2.4.1. Modelo Vista Controlador.................................................................................... 20
V
2.4.1.1. Modelo.................................................................................................................... 21
2.4.1.2. Controlador ........................................................................................................... 21
2.4.1.3. Vista........................................................................................................................ 22
2.5. Proceso de desarrollo de software ....................................................................... 22
2.5.1. Ingeniería de requerimientos ............................................................................... 23
2.5.2. Recolección de datos ............................................................................................. 24
2.5.2.1. Entrevista ............................................................................................................... 25
2.5.2.2. Cuestionario........................................................................................................... 25
2.5.2.3. Cuestionario Abierto: ........................................................................................... 26
2.5.2.4. Cuestionario Cerrado: .......................................................................................... 26
2.5.2.5. Encuesta ................................................................................................................. 26
2.5.3. Diagramas UML.................................................................................................... 28
2.5.3.1. Diagrama de Secuencia......................................................................................... 28
2.5.3.2. Diagramas de caso de uso ..................................................................................... 28
2.6. Metodología SCRUM............................................................................................ 29
2.6.1. Las características de la metodología SCRUM son: .......................................... 30
2.6.2. Ciclo de vida de SCRUM ...................................................................................... 31
2.6.3. Fases de la metodología SCRUM ......................................................................... 31
2.6.3.1. Fase pregame ......................................................................................................... 32
2.6.3.2. Fase Game.............................................................................................................. 34
2.6.3.3. Fase de PostGame ................................................................................................. 37
2.6.4. Roles y responsabilidades ..................................................................................... 37
2.6.4.1. SCRUM Master ..................................................................................................... 37
2.6.4.2. Product Owner ...................................................................................................... 37
2.6.4.3. SCRUM Team ....................................................................................................... 37
2.6.4.4. Customer................................................................................................................ 38
2.6.4.5. Management .......................................................................................................... 38
2.7. Aplicaciones WEB ................................................................................................. 38
2.7.1. Características y Ventajas de las Aplicaciones Online ...................................... 39
2.7.2. Modelo de base de datos ....................................................................................... 40
2.7.2.1. Modelo entidad relación ....................................................................................... 40
2.7.2.2. Modelo físico .......................................................................................................... 41
VI
2.8. Pruebas de funcionalidad, Estándares de calidad y seguridad ......................... 42
2.8.1. Calidad del producto ISO 9126............................................................................ 42
2.8.2. Prueba de Humo ................................................................................................... 45
2.9. Seguridad ISO 27001 ............................................................................................ 46
2.9.1. Autenticación y autorización................................................................................ 46
2.9.2. Encriptación .......................................................................................................... 47
2.10. Estimación de costo ............................................................................................... 47
2.10.1. COCOMO II.......................................................................................................... 47
2.10.2. Beneficio ................................................................................................................. 48
2.10.3. VAN ........................................................................................................................ 49
2.10.4. TIR ......................................................................................................................... 50
2.10.5. Costo – Beneficio ................................................................................................... 50
Capítulo 3............................................................................................................................... 51
Marco Aplicativo................................................................................................................... 51
3.1. Introducción .......................................................................................................... 51
3.2. Pre - Game (Antes del desarrollo) ....................................................................... 51
3.2.1. Descripción de roles y función ............................................................................. 52
3.2.2. Indagación y elaboración de requerimientos ...................................................... 52
3.2.3. Descripción de la visión general del sistema ....................................................... 53
3.3. Modelo de casos de uso ......................................................................................... 54
3.4. Diagrama entidad relación ................................................................................... 55
3.5. Game (Durante el desarrollo) .............................................................................. 56
3.5.1. Modelo físico de base de datos ............................................................................. 56
3.5.2. Tareas identificadas s ........................................................................................... 56
3.5.2.1. Sprint N° 1 Desarrollo de interfaz de usuario de pacientes. ............................. 57
3.5.2.2. Sprint N° 2 Desarrollo de interfaz de usuario de administración de insumos. 60
3.5.2.3. Sprint N° 3 Desarrollo de módulo de reportes y estadísticas ............................ 62
3.5.2.4. Sprint N° 4. Desarrollo de interfaz de módulo de seguridad y registro de
personal 65
3.5.2.5. Sprint N° 5. Desarrollo de interfaz de módulo de registro de materiales y
servicios. 67
3.6. Plan de desarrollo de Sprints ............................................................................... 69
VII
3.7. Post – Game (Después del desarrollo) ................................................................. 69
Capítulo 4............................................................................................................................... 70
Control de Calidad y Seguridad .......................................................................................... 70
4.1. Introducción .......................................................................................................... 70
4.2. Pruebas Exhaustivas ............................................................................................. 70
4.2.1. Pruebas de Humo Sprint 1 ................................................................................... 70
4.2.4. Prueba de Humo Sprint 4..................................................................................... 79
4.2.5. Prueba de Humo Sprint 5..................................................................................... 81
4.3. Métricas de Calidad .............................................................................................. 84
4.3.1. Funcionalidad ........................................................................................................ 84
4.3.2. Usabilidad .............................................................................................................. 85
4.3.3. Mantenimiento ...................................................................................................... 86
4.3.4. Portabilidad ........................................................................................................... 88
4.4. Aplicación ISO 27001 ........................................................................................... 88
4.4.1. Encriptación .......................................................................................................... 88
4.4.2. Autenticación y autorización................................................................................ 88
Capítulo 5............................................................................................................................... 90
Conclusiones y Recomendaciones ........................................................................................ 90
5.1. Conclusiones .......................................................................................................... 90
5.2. Recomendaciones .................................................................................................. 91
REFERENCIAS BIBLIOGRAFICAS ................................................................................ 92
ANEXOS 96
ANEXO A. Cuestionario de indagación de información ....................................................... 97
ANEXO B. Estudio de costos................................................................................................. 99
ANEXO C. Cuestionario de evaluación de usabilidad......................................................... 103
ANEXO D. Manual de Usuario Supervisor. ........................................................................ 106
VIII
ÍNDICE DE FIGURAS
Figura 1.1 Estructura orgánica carrera de Enfermería .............................................................. 3

Figura 1.2 Formulario de registro de pacientes......................................................................... 8
Figura 1.3 Kardex de biológicos ............................................................................................... 9
Figura 1.4 Funcionamiento SCRUM ...................................................................................... 14
Figura 2.1 Arquitectura cliente servidor ................................................................................. 17
Figura 2.2 Modelo Vista Controlador MVC ........................................................................... 21
Figura 2.3 Estructura de la ingeniería de requerimientos ....................................................... 23
Figura 2.4 Proceso de la ingeniería de requerimientos ........................................................... 24
Figura 2.5 Técnica de observación para identificación de tareas............................................ 27
Figura 2.6 Estructura de diagrama de secuencia ..................................................................... 29
Figura 2.7 Componentes para realizar diagramas de casos de uso ......................................... 29
Figura 2.8 Proceso de la metodología SCRUM ...................................................................... 31
Figura 2.9 Ciclo de vida de la metodología SCRUM ............................................................. 32
Figura 2.10 Fases de la metodología SCRUM ........................................................................ 33
Figura 2.11 Estructura de una historia de usuario ................................................................... 35
Figura 2.12 Arquitectura de una aplicación web .................................................................... 39
Figura 2.13 Estructura de modelo entidad relación ................................................................ 41
Figura 2.14 Ejemplo de un modelo físico de una base de datos ............................................. 42
Figura 2.15 Características de la norma de calidad ISO 9126 ................................................ 43
Figura 2.16 Pruebas de humo ubicadas en el ciclo de pruebas ............................................... 46
Figura 3.1 Modelo de casos de uso general del funcionamiento del consultorio.................... 55
Figura 3.2 Diseño de la base de datos plasmado a través de un diagrama entidad relación ... 55
Figura 3.3 Modelo físico de la base de datos del consultorio de Enfermería ......................... 56
Figura 3.4 Diagrama de casos de uso del proceso de atención ............................................... 58
Figura 3.5 Diagrama de secuencia que refleja las tareas del proceso de atención .................. 58
Figura 3.6 Modelo de casos de uso del proceso de administración de insumos ..................... 60
Figura 3.7 Diagrama de secuencia que refleja las tareas que se realiza en el proceso de
ingreso y salida de insumos .................................................................................................... 61
Figura 3.8 Diagrama de casos de uso del proceso de elaboración de reportes de producción 63
Figura 3.9 Diagrama de componentes que refleja las tareas del proceso de reportes ............. 63
Figura 3.10 Modelo de casos de uso del proceso de administración de personal ................... 65
Figura 3.11 Diagrama de secuencia que refleja el proceso de administración de personal
enfermero ................................................................................................................................ 66
Figura 3.12 Modelo de casos de uso del proceso de administración de personal ................... 67
Figura 3.13 Diagrama de secuencia que refleja el proceso de administración de personal
enfermero ................................................................................................................................ 67
Figura 4.1 Resultado de módulo de registro de pacientes ....................................................... 71
IX
Figura 4.2 Resultado del módulo de atenciones ..................................................................... 72
Figura 4.3 Resultados del módulo de seguimiento de consulta de pacientes .......................... 73
Figura 4.4 Resultado del módulo de registro de jeringas ........................................................ 74
Figura 4.5 Resultado del módulo de registro de vacunas........................................................ 75
Figura 4.6 Resultado del módulo de registro de salida o uso de insumos............................... 76
Figura 4.7 Resultado de módulo de recopilación de datos sobre prestación de servicios ....... 77
Figura 4.8 Reporte generado por medio de filtros de búsqueda ............................................. 77
Figura 4.9 Resultado del módulo de seguimiento de uso de insumos .................................... 78
Figura 4.10 Resultado al módulo de estadísticas .................................................................... 79
Figura 4.11 Resultado del módulo de registro de personal enfermero.................................... 80
Figura 4.12 Resultado del módulo de autenticación ............................................................... 81
Figura 4.13Resultado del módulo de registro de datos de materiales ..................................... 82
Figura 4.14 Resultado de módulo de registro de nuevos servicios ......................................... 83
Figura 4.15 Algoritmo de encriptación utilizado .................................................................... 89
Figura 4.16 Creación de variables de sesión a partir de acceso al sistema mediante usuarios 89
X
ÍNDICE DE TABLAS
Tabla 1.1 Características de hardware y software de equipo de computación del consultorio 11

Tabla 2.1 Tareas de la fase Pre - Game................................................................................... 34
Tabla 2.2 Tareas de la fase Game ........................................................................................... 36
Tabla 3.1 Descripción de roles en la atención del servicio del consultorio ............................ 51
Tabla 3.2 Tareas del usuario Director(a) y Supervisor(a) ....................................................... 52
Tabla 3.3 Tareas del usuario Enfermero(a) ............................................................................. 52
Tabla 3.4 Requerimientos funcionales del sistema ................................................................. 53
Tabla 3.5 Requerimientos no funcionales del sistema ............................................................ 53
Tabla 3.6 Tareas realizadas en el consultorio ......................................................................... 54
Tabla 3.7 Conformación de Sprint (Iteraciones) de acuerdo a prioridades ............................. 57
Tabla 3.8 Lista de tereas (Sprint Backlog) del sprint 1 ........................................................... 59
Tabla 3.9 Historia de usuario módulo de registro de pacientes .............................................. 59
Tabla 3.10 Historia de usuario módulo de registro de atención .............................................. 59
Tabla 3.11 Historia de usuario del Módulo de seguimiento de consultas de pacientes .......... 60
Tabla 3.12 Lista de tareas (Sprint Backlog) del Sprint 2 ........................................................ 61
Tabla 3.13 Historia de usuario del módulo de registro de jeringas ......................................... 62
Tabla 3.14 Historia de usuario del módulo de registro de vacunas ........................................ 62
Tabla 3.15 Historia de usuario del Módulo de registro diario de salida o uso de insumos ..... 62
Tabla 3.16 Lista de tereas (Sprint Backlog) del sprint 3 ......................................................... 64
Tabla 3.17 Historia de usuario del Módulo de recopilación de datos sobre prestación de
servicios .................................................................................................................................. 64
Tabla 3.18 Historia de usuario del Módulo de seguimiento de uso de insumos ..................... 64
Tabla 3.19 Historia de usuario del Módulo de estadísticas de prestación de servicios ........... 65
Tabla 3.20 Lista de tareas (Sprint Backlog) del sprint 4 ......................................................... 66
Tabla 3.21 Historia de usuario módulo de registro de personal Enfermero ............................ 66
Tabla 3.22 Lista de tareas (Sprint Backlog) del sprint 4 ......................................................... 68
Tabla 3.23 Historia de usuario módulo de registro de materiales ........................................... 68
Tabla 3.24 Historia de usuario módulo de registro de servicios ............................................. 68
Tabla 3.25 Plan de entrega final de los Sprints a usuarios finales .......................................... 69
Tabla 4.1 Prueba de desarrollo Sprint Nro. 1 Módulo de registro de pacientes...................... 70
Tabla 4.2 Prueba de desarrollo Sprint Nro. 1 Módulo de registro de atenciones.................... 71
Tabla 4.3 Prueba de desarrollo Sprint Nro. 1 Módulo de seguimiento de consultas de
pacientes.................................................................................................................................. 72
Tabla 4.4 Prueba de desarrollo Sprint Nro. 2 Módulo de registro de jeringas ........................ 73
Tabla 4.5 Prueba de desarrollo Sprint Nro. 2 Módulo de registro de vacunas........................ 74
Tabla 4.6 Prueba de desarrollo Sprint Nro. 2 Módulo de registro de salida o uso de insumos
................................................................................................................................................ 75
XI
Tabla 4.7 Prueba de desarrollo Sprint Nro. 3 Módulo de recopilación de datos sobre
prestación de servicios ............................................................................................................ 76
Tabla 4.8 Prueba de desarrollo Sprint Nro. 3 Módulo de seguimiento del uso de insumos ... 78
Tabla 4.9 Prueba de desarrollo Sprint Nro. 3 Módulo de estadísticas de prestación de
servicios .................................................................................................................................. 78
Tabla 4.10 Prueba de desarrollo Sprint Nro. 4 Módulo de registro de personal ..................... 80
Tabla 4.11 Prueba de desarrollo Sprint Nro. 11 Módulo de seguridad por autenticación ...... 81
Tabla 4.12 Prueba de desarrollo Sprint Nro. 4 Módulo de registro de materiales .................. 82
Tabla 4.13 Prueba de desarrollo Sprint Nro. 11 Módulo de registro de servicios .................. 83
Tabla 4.14 Calculo de punto función ...................................................................................... 84
Tabla 4.15 Valores de ajuste de complejidad ......................................................................... 84
Tabla 4.16 Ajuste de complejidad punto función ................................................................... 85
Tabla 4.17 Escala de valores para la usabilidad...................................................................... 85
Tabla 4.18 Preguntas para hallar la usabilidad........................................................................ 86
Tabla 4.19 Valores para calcular mantenimiento .................................................................... 87
XII
ÍNDICE DE ECUACIONES
Ecuación 2.1 formula para el cálculo de la funcionalidad ...................................................... 43

Ecuación 2.2 Fórmula de funcionalidad ................................................................................. 43
Ecuación 2.3 Formula para el cálculo de usabilidad ............................................................... 44
Ecuación 2.4 Formula para el cálculo de mantenibilidad del sistema .................................... 44
Ecuación 2.5 Formula para el cálculo de VAN ...................................................................... 49
Ecuación 2.6 Formula para el cálculo de TIR ......................................................................... 50
Ecuación 2.7 Formula para el cálculo de costo – Beneficio ................................................... 50
XIII
Capítulo 1
Marco Introductorio
1.1. Introducción
Según la OMS (Organización Mundial de la Salud) define a la salud como un estado
anímico completo de bienestar físico, mental, social y no la mera ausencia de
enfermedad o discapacidad. Según ésta definición de 1948 el término “salud” no sólo
incluye la falta de enfermedad física mental, sino también los factores psicológicos y
sociales que disminuyen la probabilidad de que nuestro organismo desarrolle
problemas.
Por más de dos siglos la medicación ha formado parte de la lucha del ser humano contra
las enfermedades, en tal sentido el convertirse en humanos inmunes a éstas
enfermedades es un sueño al cual no es factible llegar en estas épocas, pero
científicamente está trabajándose día y noche en el tema. Ahora bien, las maneras de
combatir las enfermedades en el día de hoy son a través de exámenes rutinarios,
controles médicos y en mucho de los casos la aplicación de vacunas.
Las campañas de vacunación a nivel mundial han ido erradicando muchas de las
enfermedades, por ejemplo: virus de la viruela, fiebre amarilla, hepatitis tipo A,
hepatitis tipo B, etc. Por ello es que en el mundo se cuenta con varios de estos centros
de investigación. En Bolivia no contamos con la tecnología suficiente para poder
investigar y desarrollar nuevos tratamientos, ya que aún dependemos de organizaciones
tales como la OPS y OMS quienes dotan insumos a centros de salud de nuestro país.
Los centros de salud en Bolivia provisionan vacunas de manera gratuita, tal es el caso
del consultorio de la carrera de Enfermería, quien conjuntamente con el programa del
PAI (Programa Ampliado de Inmunización) hace posible las campañas de
vacunaciones. Asimismo, se realizan otros procedimientos de enfermería.
Por otro lado, la gran cantidad de pacientes que acuden a este centro generan cantidades
de información que son registrados de manera física, generando así demora al momento
1
de realizar la atención, por ello surge la necesidad de sistematizar estas actividades
cotidianas por medio de las TIC’s. Gracias a las herramientas de las Tecnologías de
Información y Comunicación es posible desarrollar un sistema, el cual ayude a
gestionar las tareas del consultorio.
1.2. Antecedentes
1.2.1. Antecedentes institucionales
La Carrera de Enfermería con 75 años de trayectoria y 47 de vida universitaria, es una
institución que ha sabido responder al imperativo categórico de formar profesionales
enfermeros(as) que a su vez respondan al encargo social, traducido en el "Cuidado de
la Salud Boliviana" (Carrera Enfermería, 2017).
Enfermería como profesión, interactúa con otras profesiones del área de la salud, sus
acciones van encaminadas a la promoción y fomento de la salud, prevención y
tratamiento de las enfermedades, y la rehabilitación de la persona enferma, en los tres
niveles de atención: Asistencial, Administrativa–Gerencial e investigación las mismas
que se encuentran vinculadas con el medio (Carrera Enfermería, 2017).
De acuerdo al Estatuto Orgánico de la Universidad Boliviana aprobado en el XII
Congreso, realizado el año 2014, se ratifica la inserción institucional de la Facultad de
Medicina Enfermería, Nutrición y Tecnología Médica como parte integrante de la
Universidad Mayor de San Andrés (Carrera Enfermería, 2017).
El Estado Boliviano forma enfermeras a partir del año 1942, en la Escuela Nacional de
Enfermeras y la Escuela de la Clínica Americana. Desde el año 1969 las Escuelas de
Enfermería existentes en la Ciudad de La Paz, (Escuela Nacional de Enfermería,
dependiente del Ministerio de Previsión Social y Salud Pública y la Escuela de
Enfermería de la Clínica Americana dependiente de la Iglesia Metodista, realizan
trámites a nivel de la Universidad Mayor de San Andrés, para integrarse al seno
universitario (Carrera Enfermería, 2017).
El 8 de junio de 1970, se constituye la ESCUELA UNIVERSITARIA DE
ENFERMERÍA de la Universidad Mayor de San Andrés, como integrante de la
Facultad de Medicina, a partir del cual se inician los cambios en la enseñanza de
2
Enfermería, debiendo ajustarse el programa a las normas establecidas en la Facultad,
así como a la política, filosofía y objetivos de la Universidad (Carrera Enfermería,
2017).
La infraestructura con la que cuenta la Facultad de Medicina, Enfermería, Nutrición y
Tecnología Médica, a la cual pertenece la Carrera de Enfermería, es la adecuada para
cumplir con los diferentes objetivos del programa académico de cada una de las
cátedras (Carrera Enfermería, 2017).
Figura 1.1 Estructura orgánica carrera de Enfermería

Fuente: (Carrera Enfermería, 2017)
La Carrera de Enfermería de manera exclusiva cuenta con los siguientes predios:

 Dentro del edificio de la Facultad, ocupa 2 pisos (10 y ¾ del piso 11) de manera
exclusiva
 Aulas de Simulación Clínica para las áreas de Enfermería: Pediatría, Médico
Quirúrgico, Obstetricia y Fundamentos de Enfermería ubicadas
específicamente en el piso de la Carrera de enfermería.
 Cuatro aulas apropiadas para la formación académica
3
 Escenarios Hospitalarios y Establecimientos de Salud para las Prácticas
Clínicas, refrendados por convenio
 Recibe servicios de los departamentos de Morfológica, Patológica y Salud
Publica de la Facultad
 Biblioteca especializada en el piso exclusivo de la Carrera de Enfermería
 Oficina de Kardex
 Sala de Computación
 Oficina Administrativa
 Consultorio de Enfermería
La estructura orgánica de la Carrera de Enfermería está constituida y reflejada por la
figura 1.1.
1.2.2. Antecedentes Consultorio de Enfermería
La Carrera de Enfermería desde hace aproximadamente más de 9 años ha venido
prestando servicios mediante su vacunatorio y que a partir de la gestión 2017 nombrado
como el Consultorio de la Carrera de Enfermería, beneficiando a la población
universitaria, plantel docente, administrativos y personal manual de la Facultad de
Medicina, así como a personas e instituciones exteriores que lo solicitaban. Las
intervenciones realizadas principalmente han estado dirigidas a la aplicación del
Programa Ampliado de Inmunización Familiar y Comunitario, con el esquema de
vacunas de DT (Difteria y Tétanos) Adulto, Vacuna contra la Hepatitis “B” y papiloma
virus de Influenza Estacional. Asimismo, se realizaba procedimientos como ser
inyectables y curaciones de forma ocasional (Carrera Enfermería, 2017).
El Vacunatorio nació como iniciativa docente – estudiantil en la Asignatura de Salud

Pública II, como parte de la formación profesional en el Segundo año de Carrera,
asimismo contó en algunos momentos con el apoyo de Auxiliares de Docencia y
estudiantes, bajo la supervisión docente, responsabilidad a cargo de la Lic. Gladys
Alcázar Vargas (Carrera Enfermería, 2017).
A través de la implementación del Vacunatorio se ha realizado el aporte al Programa

Ampliado de Inmunización Familiar y Comunitario (P. A. I.). El mismo es un programa
4
de prevención, vigilancia y control de las enfermedades prevenibles a través de las
vacunas. El P. A. I. desarrolla acciones conjuntas y comprometidas con las naciones
del mundo para lograr las coberturas universales de vacunación con el fin de erradicar,
eliminar y controlar dichas enfermedades (Carrera Enfermería, 2017).
El P. A. I. fue organizado oficialmente en Bolivia en octubre de 1979, a partir de

entonces se ha constituido en el programa preventivo más importante de las políticas
de salud. En su ejecución ha ido desarrollando diversas estrategias con el fin de cubrir
al 100% de la población objetivo, vale decir niñas y niños menores de cinco años
(Carrera Enfermería, 2017).
Al respecto es preciso destacar los objetivos del Programa Ampliado de Inmunización,

en el cual el objetivo es reducir el riesgo de la población de enfermar y morir por
enfermedades inmuno prevenibles, mediante la aplicación universal de vacunas y una
vigilancia epidemiológica oportuna y eficiente, desarrollada por personal de salud
capacitado para tal fin (Carrera Enfermería, 2017).
Entre los objetivos específicos están:
 Alcanzar y mantener coberturas de vacunación mayores a 95% por municipio

con cada una de las vacunas del Esquema Nacional de Vacunación.
 Asegurar la disponibilidad de todas las vacunas de este esquema para garantizar

la inmunización oportuna y sistemática en todo el territorio boliviano.
 Asegurar la correcta conservación, almacenamiento y transporte de las vacunas

desde el laboratorio hasta el establecimiento de salud o hasta el beneficiario
final, vale decir la comunidad.
 Asegurar la eficiencia de la vigilancia epidemiológica de las enfermedades

inmuno prevenibles como herramienta indispensable para la toma de
decisiones.
5
 Garantizar la vacunación segura a través del seguimiento al desempeño del
recurso humano en todo el proceso de vacunación.
 Asegurar un sistema de seguimiento, monitoreo, evaluación de los procesos de

vacunación y de vigilancia epidemiológica.
 Desarrollar, aplicar herramientas de trabajo comunitario y de negociación para

la gestión del PAI, sobre todo el nivel local.
Son objetivos que han de permitir el cumplimento de las metas, mismas son:
 Mantener la erradicación de la poliomielitis.
 Mantener la eliminación del sarampión, rubeola y síndrome de rubeola

congénita.
 Controlar el tétanos neonatal, difteria, tosferina, hepatitis B, fiebre amarilla,

neumonías y meningitis por Haemophilus tipo b y neumococo, así como las
diarreas graves generadas por Rotavirus.
Es por cuanto que en el transcurso de los nueve años de implementación del

Vacunatorio se han realizado actividades para el cumplimiento del Programa Ampliado
de Inmunización con la vacunación a la población universitaria de las vacunas Dt
(Difteria y Tétanos), Hepatitis B, Influenza. Entre los datos más significativos son los
registrados en los últimos 5 años (Carrera Enfermería, 2017).
1.2.3. Proyectos Análogos

Dentro los proyectos análogos realizados por estudiantes de la Carrera de Informática
de la Universidad Mayor de San Andrés tenemos:
 SISTEMA DE CONTROL Y GESTION DE HISTORIALES CLINICOS
APOYADO EN DISPOSITIVOS MOVILES” CASO: CENTRO
MEDICO LA PAZ, El proyecto muestra el proceso para el desarrollo del
Sistema de Control y Gestión de Historiales Clínicos Apoyado en Dispositivos
Móviles para el Centro Médico La Paz. El proceso de registro de historiales
6
clínicos es manual, razón por la cual se necesita una herramienta que automatice
estas tareas debido al crecimiento de pacientes que consultan al Centro Médico.
Por otra parte, la mayoría de los pacientes por diversos motivos no realizan un
seguimiento a tiempo de su tratamiento médico, razón por la cual se les brinda
una aplicación móvil que permita recordarle al paciente su tratamiento médico
(Centellas Coarite, 2015).
 SISTEMA DE ADMINISTRACION Y CONTROL DE HISTORIALES
CLINICOS PARA LOS CONSULTORIOS DE LA UMSA, Este sistema
permite almacenar los datos relevantes del paciente (universitario/a), ha sido
desarrollado para los Consultorios dependientes del Departamento de Bienestar
Social de la Universidad Mayor de San Andrés, cuya actividad principal es
brindar atención médica eficaz y eficiente. El propósito del proyecto, es la
realización de la transición de la gestión de la información de la Historia Clínica
tradicional del paciente, con la sustitución de un sistema informático, que
permita almacenar y procesar cantidades de datos. El proceso de investigación
que se utilizó para el desarrollo del proyecto es la investigación científica,
explicativa, experimental y metodológica (Rosmery, 2014).
También existen proyectos ya comercializados en el internet:
 OpenEMR (Sistema de Código abierto), Realiza la atención a clientes en

Argentina en forma personal, y en el resto del mundo a través de Internet, sin
necesidad de contacto personal. Los servidores proveen respuesta rápida y
segura a cualquier institución. En cualquier momento el cliente puede trasladar
sus datos a otro servidor de Internet o a su propia Intranet (OpenEMR, 2014).
1.3. Descripción del problema

1.3.1. Problemática
Los servicios que presta el consultorio de Carrera de Enfermería son ofrecidos a la
población en general a un costo diferenciado, pero para la comunidad universitaria
(estudiantes, docentes y administrativos) no tiene ningún costo. Uno de los principales
7
servicios que ofrece este consultorio es la aplicación de vacunas como vacuna Dt
(Difteria y tétanos), hepatitis B, influenza, fiebre amarilla, también se realizan
curaciones y servicios de primeros auxilios.
El personal encargado de la atención del consultorio es administrado por una persona

especializada en el área y anualmente se va cambiando, los personales auxiliares
(estudiantes) agilizan la atención a los pacientes.
El servicio cuenta con varias planillas, formularios y cuadernos de registro de pacientes

atendidos, entre estos están:
 Cuaderno de registro de pacientes, son formularios donde se registra la

información personal del paciente, además de registrar los datos de la atención
realizada (ver figura 1.2).
 Formularios de atención de pacientes, es un formulario de registro de las

cantidades totales de las atenciones realizadas en el mes.
 Kardex de biológicos, es un registro general de los materiales de trabajo usado,

sobrante y desperdiciado, además de registrar nuevos ingresos de los mismos
(ver figura 1.3).
 Informe Mensual de Producción de Servicios, es el registro mensual y general

que se obtiene a partir del total de cantidad de pacientes atendidos especificados
por tipo de servicio.
Figura 1.2 Formulario de registro de pacientes

Fuente: Formulario del consultorio de Enfermería
8
Figura 1.3 Kardex de biológicos
Fuente: Formulario del consultorio de Enfermería
1.3.2. Planteamiento del problema

Por medio de un cuestionario (ver anexo A) realizado al personal enfermero
responsable del consultorio, se pudo identificar diversos problemas el cual conlleva a
la deficiencia de la atención en el consultorio. En este cuestionario se identificó
principalmente la demora en tiempo en la búsqueda de información ya sea para emitir
un certificado de vacunación, realizar seguimiento a las vacunas aplicadas, como
también en la elaboración de informes que se realizan mensualmente por el personal.
Aproximadamente se atienden 15 pacientes por día, los cuales requieren ser registrados
o realizar la búsqueda de la información del paciente en los registros de atención esto
para hacer seguimiento a sus vacunas (aproximadamente una búsqueda tarda hasta 30
minutos). Los ingresos de insumos al consultorio son gestionados a través de Dirección
de Carrera. Al momento de adquirir este material se debe realizar su registro
9
correspondiente en cuaderno de inventarios (kardex). También el uso de materiales del
inventario debe ser registrado adecuadamente.
El consultorio es supervisado por el director(a) de carrera, es atendido y administrado

por personal especializado en el área. Cuando se realizan campañas de vacunación se
requiere apoyo auxiliar (estudiantes) para colaboración en las tareas de registro de
información.
1.4. Objetivos
1.4.1. Objetivo General
Desarrollar e implementar un Sistema de Gestión de Información Clínica, que permita
gestionar las tareas que se llevan a cabo en el consultorio de la Carrera de Enfermería.
1.4.2. Objetivos Específicos

Los objetivos específicos fueron planteados de la siguiente manera:
a) Recolectar información a través de la ingeniería de requerimientos, el cual

pueda aplicarse encuestas, cuestionarios de evaluación, etc. sobre el proceso de
atención y administración de los insumos del consultorio de la Carrera de
Enfermería.
b) Realizar un análisis con los formularios utilizados en el consultorio para poder
estructurar la base de datos que se utilizará en el sistema de gestión clínica.
c) Determinar el proceso realizado en la atención, para desarrollar un módulo de

registro y atención de los pacientes, para brindar información oportuna y al
alcance del operador del sistema.
d) Analizar el proceso de registros de ingreso y salida de insumos para desarrollar

un módulo de registro de ingreso, salida y desperdicio de materiales (insumos)
que ayude a gestionar de manera eficiente y efectiva del material de trabajo.
10
e) Implementar un módulo de reportes que generen información acerca de los
servicios brindados, además del estado y disponibilidad de insumos, para que
ayuden a administrar de manera eficiente.
f) Implementar un módulo estadístico gráfico, que genere datos acerca de los

servicios brindados en el consultorio.
g) Desarrollar el sistema bajo la norma de calidad ISO/IEC 9126 y la norma de

seguridad ISO 27001.
1.5. Justificación
1.5.1. Justificación Técnica
Desde el punto de vista técnico, es necesario mencionar que la Facultad de Medicina,
Enfermería, Nutrición y Tecnología Médica cuenta con sus propios servidores
administrados por la RED UMSALUD de la Facultad, el cual proporciona servicios de
internet, telefonía IP, correo institucional y hospedaje de sistemas informáticos. El
dominio proporcionado para el almacenamiento de sistemas Web es “200.7.173.101”,
de modo que cualquier carrera perteneciente a la Facultad puede solicitar el uso.
Tabla 1.1 Características de hardware y software de equipo de computación del consultorio
HARDWARE SOFTWARE
Procesador: Core i5-3470 Sistema Operativo: Windows 8.1 Pro
RAM: 4 GB Paquetes:
Disco Duro: 500 GB - Adobe Reader
Lector: Quemador DVD-RW - Navegador Web CHROME
Impresora: HP LaserJet P2055dn - Net Framework 4.6
Red: Realtek PCIe GBE Family - Java SE Development Kit 7
- Microsoft Visual C++ 2010
En el consultorio de Enfermería se cuenta con puntos de red instalados para el acceso

a la red de la facultad, también se cuenta con un equipo de cómputo con requerimientos
necesarios para el funcionamiento de diversos sistemas web. También se cuenta con
11
un laboratorio de computación con herramientas necesarias para el desarrollo del
sistema entre estos: acceso a internet, editor de código, administrador de base de datos,
etc. El equipo de computación del consultorio cuenta con características tanto en
software como en hardware reflejadas en la tabla 1.1.
1.5.2. Justificación Económica

El presente proyecto es económicamente justificable al proponer un software de
aplicación desarrollado con herramientas de software libre y código abierto,
permitiendo ejercer mayor control de las actividades que se llevan en el consultorio,
reduciendo de esta manera la pérdida de tiempo en procesos manuales. Lo que implica
un ahorro económico de tiempo y dinero en la recepción de datos, el desarrollo del
sistema empleara herramientas que sustituyan los procesos realizados en programas
ofimáticos como ser plantillas en Excel y manuales que generan un costo. También se
realizó un estudio de costos del desarrollo del sistema a través del sistema de estimación
COCOMO II (ver anexo B sobre el estudio de costos).
1.5.3. Justificación Social
Al contar con un sistema de información que gestione las tareas que se llevan a cabo
en el consultorio, mejora las condiciones de trabajo, brindando a la enfermera
información oportuna del paciente y facilitando la atención cuando así lo requiera.
1.6. Límites y/o Alcances

1.6.1. Limites
El presente sistema web se desarrollará bajo las siguientes limitaciones:
 La funcionalidad de sistema dependerá necesariamente de un hosting funcional

y acceso a internet.
 Podrá ser utilizado desde cualquier dispositivo ya sea computadora de escritorio

o un dispositivo móvil.
 El acceso al sistema estará restringido solo por un usuario administrador que

será asignado a el/la directora(a) de carrera, este usuario habilitará a otros
12
usuarios estándares (Docentes y estudiantes) que son parte de la administración
del consultorio.
 El sistema trabajará con los formularios utilizados en el consultorio de

Enfermería.
1.6.2. Alcances
Los alcances para cumplir con los objetivos de este proyecto, considerando los
requerimientos determinados en una primera instancia explicados en diagramas de
casos de uso son:
Módulo de administración personal enfermero: Este módulo realiza el registro de

información personal del personal que administra el consultorio, a la vez es asignado
un rol para el acceso a la información.
Módulo atención de pacientes: Realiza el registro de los datos del paciente, para
posteriormente registrar la consulta o atención que éste requiere. También tiene la
capacidad de realizar el seguimiento de consultas de los pacientes.
Módulo administración de insumos: Permite realizar una administración eficiente de

los materiales de trabajo (insumos) como ser el ingreso, salida o desperdicio de los
mismos.
Módulo de reportes y estadísticas: Se realizarán informes de producción de servicios

que el operador requiera a través de filtros de búsqueda, además tendrá la información
de los materiales que han sido usados, sobrantes y desperdiciados. También puede
realizarse cuadros estadísticos según los datos requeridos.
Módulo de servicios y materiales: Este módulo es encargado de registrar nuevos

servicios que se implantara en el consultorio, como también el registro a la base de
datos de nuevos materiales que se utilizaran posteriormente en el centro.
13
Para que el usuario pueda tener un mejor operación de los módulos es que se elaboró
un manual de usuario (ver anexo D), con el fin de ayudar al usuario a facilitar la
operatividad con el sistema.
Figura 1.4 Funcionamiento SCRUM

Fuente: (Pastrana, 2014)
1.7. Metodología SCRUM.

El presente proyecto de grado se realizó bajo la metodología de desarrollo SCRUM, ya
que SCRUM es un proceso ágil para desarrollar software que fue aplicado por primera
vez por Ken Schwaber y Jeff Sutherland., quienes lo documentaron en detalle en el
libro Agile Software Development with SCRUM. Esta metodología centra su atención
en las actividades de Gerencia y no especifica prácticas de Ingeniería. Fomenta el
surgimiento de equipos auto dirigidos cooperativos y aplica inspecciones frecuentes
como mecanismo de control. SCRUM parte de la base de que los procesos definidos
funcionan bien sólo si las entradas están perfectamente definidas y el ruido,
ambigüedad o cambio es muy pequeño, proceso SCRUM reflejado en la Figura 1.4.
Por lo tanto, resulta ideal para proyectos con requerimientos inestables, ya que fomenta
el surgimiento de los mismos. SCRUM consta de tres fases: Pregame, Development y
Postgame (Peralta, 2003).
14
Capítulo 2
Marco Teórico
2.1. Introducción
En el presente capitulo se da a conocer el marco teórico para poder aclarar todas las
dudas acerca de definiciones de dichos términos, como también especificar el proceso
que llevan dichas metodologías que sustenta el proyecto de grado. Estos elementos
teóricos están extraídos de diversas fuentes el cual son citadas en diversas partes del
documento, esto para un mejor entendimiento del proyecto.
2.2. Sistema de información

Nuestra sociedad se encuentra repleta de ejemplos de sistemas, tales como una máquina
expendedora de café, una fábrica de productos manufacturados, un vehículo, un
archivo para documentos, nuestra columna vertebral, etc. En el caso de las máquinas
de café o bebidas, podemos analizar su funcionamiento para comprender mejor el
concepto de sistema. Las monedas entran en el sistema, se compara su valor con el de
la bebida seleccionada (objetivo del sistema) y si ambos valores son iguales, se expide
la bebida (Pérez Porto & Gardey, 2008).
El objetivo primordial de un sistema de información es apoyar la toma de decisiones y

controlar todo lo que en ella ocurre. Es importante señalar que existen dos tipos de
sistema de información, los formales y los informales; los primeros utilizan como
medio para llevarse a cabo estructuras sólidas como ordenadores, los segundos son más
artesanales y usan medios más antiguos como el papel y el lápiz o el boca a boca (Pérez
Porto & Gardey, 2008).
Es un conjunto de componentes interrelacionados que recolectan (o recuperan),

procesan, almacenan y distribuyen información para apoyar los procesos de toma de
decisiones y de control en una organización. Además de apoyar la toma de decisiones,
la coordinación y el control, los sistemas de información también pueden ayudar a los
gerentes y trabajadores del conocimiento a analizar problemas, visualizar temas
complejos y crear nuevos productos (Laudon & Laudon, 2012).
15
En un sistema de información el aspecto electrónico no siempre debe ser necesario, sin
embargo, en la práctica se utiliza como sinónimo de sistema de información
computarizado. Estos elementos son de naturaleza diversa y normalmente incluye:
(Pérez Porto & Gardey, 2008)
 El equipo computacional: es decir el hardware necesario para que el sistema de
información pueda operar. Lo constituyen las computadoras y el equipo
periférico que se conectan a ellas.
 El recurso humano: que interactúa con el sistema de información, el cual está

formado por las personas que utilizan el sistema, alimentándolo con datos o
utilizando los resultados que genere.
 Los datos o información fuente: que son introducidos en el sistema, son todas
las entradas que este necesita para generar como resultados la información que
se desee.
 Los programas: que son ejecutados por las computadoras y producen diferentes
tipos de resultados. Los programas son parte del software del sistema de
información que hará que los datos de entrada introducidos sean procesados
correctamente y generen los resultados que se esperan.
 Las telecomunicaciones: que son básicamente hardware y software, facilitan la

transmisión de texto, datos, imágenes y voz en forma electrónica.
 Procedimientos: que incluyen las políticas y reglas de operación, tanto en la

parte funcional del proceso de negocio, como los mecanismos para hacer
trabajar una aplicación en la computadora.
Esto favorece los procesos de enseñanza de los programas basados en la Web, ya que
se parte de conceptos y herramientas ampliamente conocidos, como puede suceder con
los navegadores o los métodos de búsqueda y navegación (Pérez Porto & Gardey,
2008).
16
2.3. Arquitectura Cliente Servidor
En el mundo de TCP/IP las comunicaciones entre computadoras se rigen básicamente

por lo que se llama modelo Cliente-Servidor, éste es un modelo que intenta proveer
usabilidad, flexibilidad, interoperabilidad y escalabilidad en las comunicaciones. El
término Cliente/Servidor fue usado por primera vez en 1980 para referirse a PC’s en
red (Gralneg, 2004).
Este modelo Cliente/Servidor empezó a ser aceptado a finales de los 80’s. Su

funcionamiento es sencillo: se tiene una máquina cliente, que requiere un servicio de
una máquina servidor, y éste realiza la función para la que está programado (Gralneg,
2004).
En la Figura 2.1 podemos observar las peticiones realizadas a través de una

computadora que posteriormente llega a un servidor y a consecuencia de ello el
servidor lanza una respuesta específica a la petición realizada por la máquina.
Figura 2.1 Arquitectura cliente servidor

Fuente: (Culturacion, 2011)
17
2.3.1. Cliente
El cliente es el proceso que permite al usuario formular los requerimientos y pasarlos

al servidor, se le conoce con el término front-end (Gralneg, 2004).
El Cliente normalmente maneja todas las funciones relacionadas con la manipulación

y despliegue de datos, por lo que están desarrollados sobre plataformas que permiten
construir interfaces gráficas de usuario (GUI), además de acceder a los servicios
distribuidos en cualquier parte de una red (Gralneg, 2004).
Las funciones que lleva a cabo el proceso cliente se resumen en los siguientes puntos:
(Gralneg, 2004)
 Administrar la interfaz de usuario.

 Interactuar con el usuario.
 Procesar la lógica de la aplicación y hacer validaciones locales.
 Generar requerimientos de bases de datos.
 Recibir resultados del servidor.
 Formatear resultados.
2.3.2. Servidor
Es el proceso encargado de atender a múltiples clientes que hacen peticiones de algún

recurso administrado por él. Al proceso servidor se le conoce con el término back-end.
El servidor normalmente maneja todas las funciones relacionadas con la mayoría de las
reglas del negocio y los recursos de datos (Gralneg, 2004).
Las funciones que lleva a cabo el proceso servidor se resumen en los siguientes puntos:
(Gralneg, 2004)
• Aceptar los requerimientos de bases de datos que hacen los clientes.

• Procesar requerimientos de bases de datos.
18
• Formatear datos para trasmitirlos a los clientes.
• Procesar la lógica de la aplicación y realizar validaciones a nivel de bases de
datos.
2.3.2.1.WEB Hosting
Hosting significa Alojamiento u Hospedaje. La información alojada está contenida en

servidores que deben contar a su alrededor con una infraestructura tanto técnica como
humana, que permita que la información que contiene el servidor esté segura, y que
esté disponible para los usuarios que la necesitan en las condiciones que defina la
empresa propietaria de esa información (Espacio, 2004).
Por ejemplo, si el servidor contiene la página web corporativa de una empresa, éste ha
de estar conectado a la red Internet y debe contar con los medios que garanticen que
los servicios están disponibles 24x7 para los usuarios de Internet. Si se trata de una
aplicación de negocio a la que deben acceder los trabajadores de una empresa, este
servidor debe estar conectado a un punto común al que accedan los usuarios de la red
corporativa de que se trate, para garantizar que estos accedan a los recursos
corporativos cuando lo necesiten (Espacio, 2004).
2.4. Arquitectura de software
Existen muchas definiciones de Arquitectura del Software y no parece que ninguna de

ellas haya sido totalmente aceptada. En un sentido amplio podríamos estar de acuerdo
en que la Arquitectura del Software es el diseño de más alto nivel de la estructura de
un sistema, programa o aplicación y tiene la responsabilidad de: (Josep, 2004)
 Definir los módulos principales

 Definir las responsabilidades que tendrá cada uno de estos módulos
 Definir la interacción que existirá entre dichos módulos:
 Control y flujo de datos
 Secuenciación de la información
 Protocolos de interacción y comunicación
19
 Ubicación en el hardware
La Arquitectura del Software aporta una visión abstracta de alto nivel, posponiendo el
detalle de cada uno de los módulos definidos a pasos posteriores del diseño (Josep,
2004).
La definición oficial de Arquitectura del Software es la IEEE Std 1471-2000 que reza
así: La Arquitectura del Software es la organización fundamental de un sistema
formada por sus componentes, las relaciones entre ellos y el contexto en el que se
implantarán, y los principios que orientan su diseño y evolución (Josep, 2004).
El objetivo principal de la Arquitectura del Software es aportar elementos que ayuden

a la toma de decisiones y, al mismo tiempo, proporcionar conceptos y un lenguaje
común que permitan la comunicación entre los equipos que participen en un proyecto.
Para conseguirlo, la Arquitectura del Software construye abstracciones,
materializándolas en forma de diagramas (blueprints) comentados (Josep, 2004).
No hay estándares en cuanto a la forma y lenguaje a utilizar en estos blueprints. De

todas formas, existe consenso en cuanto a la necesidad de organizar dichas
abstracciones en vistas, tal y como se hace al diseñar un edificio. La cantidad y tipos
de vistas difiere en función de cada tendencia arquitectónica. Existen diversos modelos
de entre uno de ellos se podría decir el más utilizado por los desarrolladores de software
que es el Modelo Vista Controlador (Josep, 2004).
2.4.1. Modelo Vista Controlador
Modelo Vista Controlador (MVC) es un estilo de arquitectura de software que separa

los datos de una aplicación, la interfaz de usuario, y la lógica de control en tres
componentes distintos (vea figura 2.2) (Laudon & Laudon, 2012).
20
Se trata de un modelo muy maduro y que ha demostrado su validez a lo largo de los
años en todo tipo de aplicaciones, y sobre multitud de lenguajes y plataformas de
desarrollo (Drake, 2008).
Figura 2.2 Modelo Vista Controlador MVC

Fuente: (Alicante, 2017)
2.4.1.1.Modelo
El modelo cumple la tarea de: (Pérez Porto & Gardey, 2008)
• Acceder a la capa de almacenamiento de datos. Lo ideal es que el modelo sea

independiente del sistema de almacenamiento.
• Define las reglas de negocio (la funcionalidad del sistema). Un ejemplo de regla
puede ser: "Si la mercancía pedida no está en el almacén, consultar el tiempo
de entrega estándar del proveedor".
• Lleva un registro de las vistas y controladores del sistema.
• Si estamos ante un modelo activo, notificará a las vistas los cambios que en los
datos pueda producir un agente externo (por ejemplo, un fichero por lotes que
actualiza los datos, un temporizador que desencadena una inserción, etc.).
2.4.1.2.Controlador
El controlador se encarga de: (Pérez Porto & Gardey, 2008)
21
• Recibir los eventos de entrada (un clic, un cambio en un campo de texto, etc.).
• Contener reglas de gestión de eventos, del tipo "SI Evento Z, entonces Acción
W". Estas acciones pueden suponer peticiones al modelo o a las vistas. Una de
estas peticiones a las vistas puede ser una llamada al método "Actualizar ()".
Una petición al modelo puede ser " Obtener tiempo de entrega (nueva orden de
venta)".
2.4.1.3.Vista
Las vistas son encargadas de: (Pérez Porto & Gardey, 2008)
• Recibir datos del modelo y los muestra al usuario.

• Tienen un registro de su controlador asociado (normalmente porque además lo
instancia).
• Pueden dar el servicio de "Actualización ()", para que sea invocado por el
controlador o por el modelo (cuando es un modelo activo que informa de los
cambios en los datos producidos por otros agentes).
2.5. Proceso de desarrollo de software
Un proceso de desarrollo de software es la descripción de una secuencia de actividades

que deben ser seguida por un equipo de trabajadores para generar un conjunto
coherente de productos, uno de los cuales en el programa del sistema deseado (Drake,
2008).
El objetivo de un proceso de desarrollo de programas es la formalización de las

actividades relacionadas con el desarrollo del software de un sistema informático.
La mayoría de los proyectos que se desarrollan, finalizan tarde, cuesta mucho más de
lo estimado. ¿Por qué ocurre esto? El software se encuadra entre los artefactos más
complejos que es capaz de desarrollar el hombre, y además dado que no tiene límites
físicos por su carácter inmaterial, su dimensión se puede imaginar ilimitada (Drake,
2008).
22
2.5.1. Ingeniería de requerimientos
El marco conceptual sobre el cual se desarrolla este proyecto de grado está constituido
principalmente por el proceso de Ingeniería de Requerimientos. Este se rige bajo un
enfoque tradicionalista de la Ingeniería de Software; y tiene como objetivos el
identificar, analizar, documentar, validar y administrar los requerimientos que van a
ser desarrollados para un sistema o producto de software. Algunas de las definiciones
más generales del mismo son: (Camacho, 2005)
"Ingeniería de Requerimientos es la disciplina para desarrollar una especificación
completa, consistente y no ambigua, la cual servirá como base para acuerdos comunes
entre todas las partes involucradas y en dónde se describen las funciones que realizará
el sistema" (Boehm B. , 1981).
"Ingeniería de requerimientos es un enfoque sistémico para recolectar, organizar y
documentar los requerimientos del sistema; es también el proceso que establece y
mantiene acuerdos sobre los cambios de requerimientos, entre los clientes y el equipo
del proyecto" (Oberg, Probasco, & Ericsson, 2003).
“La Ingeniería de Requerimientos es la ciencia y disciplina a la cual le concierne el
establecer y documentar los requerimientos.” (Thayer & Dorfam, 2000).
Por esto, el proceso de Ingeniería de Requerimientos describe de manera detallada y
precisa cada uno de los aspectos del ciclo de vida de un conjunto de requerimientos.
Este proceso presenta dos grandes ramas: El Desarrollo de requerimientos, y la
Administración de requerimientos (Vea Figuras 2.3 y 2.4) (Camacho, 2005).
Figura 2.3 Estructura de la ingeniería de requerimientos

Fuente: (Camacho, 2005)
23
Cada una de estas actividades que conforman el Desarrollo de Requerimientos
consisten en: (Camacho, 2005)
- Recolección (Elicitation): Es el Proceso a través del cual los clientes
(compradores y/o usuarios) y el desarrollador (contratista) de un sistema de
software; descubren, revisan, articulan, y entienden las necesidades de los
usuarios del sistema y las restricciones que se dan sobre el software y el
desarrollo del mismo.
- Análisis (Analysis): Es el proceso de analizar las necesidades de los clientes y
los usuarios para llegar a una definición de los requerimientos de software.
- Especificación (Specification): Consiste en el desarrollo de un documento que
de manera clara y precisa contenga y especifique cada uno de los
requerimientos del sistema de software.
- Verificación (Verification): Es el proceso de asegurar que la especificación de
requerimientos de software sea acorde con los requerimientos del sistema,
conforme a los estándares de documentación de la fase de requerimientos, y
que a su vez este documento sea una base sólida para la arquitectura y el
diseño28.
Figura 2.4 Proceso de la ingeniería de requerimientos

Fuente: (Camacho, 2005)
2.5.2. Recolección de datos
La recolección de datos se refiere al uso de una gran diversidad de técnicas y herramientas

que pueden ser utilizadas por el analista para desarrollar los sistemas de información, los
24
cuales pueden ser la entrevistas, la encuesta, el cuestionario, la observación, el diagrama
de flujo y el diccionario de datos (Shirley, 2012).
Todos estos instrumentos se aplicarán en un momento en particular, con la finalidad de

buscar información que será útil a una investigación en común (Shirley, 2012).
2.5.2.1.Entrevista
Las entrevistas se utilizan para recabar información en forma verbal, a través de
preguntas que propone el analista. Quienes responden pueden ser gerentes o
empleados, los cuales son usuarios actuales del sistema existente, usuarios potenciales
del sistema propuesto o aquellos que proporcionarán datos o serán afectados por la
aplicación propuesta. El analista puede entrevistar al personal en forma individual o
en grupos algunos analistas prefieren este método a las otras técnicas que se estudiarán
más adelante. Sin embargo, las entrevistas no siempre son la mejor fuente de datos de
aplicación (Shirley, 2012).
Dentro de una organización, la entrevista es la técnica más significativa y productiva
de que dispone el analista para recabar datos. En otras palabras, las entrevistas es un
intercambio de información que se efectúa cara a cara. Es un canal
de comunicación entre el analista y la organización; sirve para obtener información
acerca de las necesidades y la manera de satisfacerlas, así como concejo y comprensión
por parte del usuario para toda idea o método nuevos. Por otra parte, la entrevista ofrece
al analista una excelente oportunidad para establecer una corriente de simpatía con el
personal usuario, lo cual es fundamental en transcurso del estudio (Shirley, 2012).
2.5.2.2.Cuestionario
Los cuestionarios proporcionan una alternativa muy útil para la entrevista; sin
embargo, existen ciertas características que pueden ser apropiada en algunas
situaciones e inapropiadas en otra. Al igual que la entrevistas, deben diseñarse
cuidadosamente para una máxima efectividad (Shirley, 2012).
25
2.5.2.3.Cuestionario Abierto:
Al igual que las entrevistas, los cuestionarios pueden ser abiertos y se aplican cuando
se quieren conocer los sentimientos, opiniones y experiencias generales; también son
útiles al explorar el problema básico, por ejemplo, un analista que utiliza cuestionarios
para estudiar los métodos de verificación de crédito, es un medio (Shirley, 2012).
El formato abierto proporciona una amplia oportunidad para quienes respondan escriba
las razones de sus ideas. Algunas personas, sin embargo, encuentran más fácil escoger
una de un conjunto de respuestas preparadas que pensar por sí mismas (Shirley, 2012).
2.5.2.4.Cuestionario Cerrado:
El cuestionario cerrado limita las respuestas posibles del interrogado. Por medio de un
cuidadoso estilo en la pregunta, el analista puede controlar el marco de referencia. Este
formato es el método para obtener información sobre los hechos (Shirley, 2012).
También fuerza a los individuos para que tomen una posición y forma su opinión sobre
los aspectos importantes (Shirley, 2012).
2.5.2.5.Encuesta
La encuesta es un instrumento de investigación para obtener información
representativa de un grupo de personas. Se trata de aplicar un cuestionario a
determinado número de individuos, con el objeto de obtener un resultado (Shirley,
2012).
El requisito es que debe aplicarse a un número representativo. Forma parte de una

investigación; es sólo un instrumento (Shirley, 2012).
2.5.2.6.La observación
Otra técnica útil para el analista en su progreso de investigación, consiste en observar

a las personas cuando efectúan su trabajo. Como técnica de investigación, la
observación tiene amplia aceptación científica (Shirley, 2012).
26
Los sociólogos, sicólogos e ingenieros industriales utilizan extensamente ésta técnica
con el fin de estudiar a las personas en sus actividades de grupo y como miembros de
la organización (Shirley, 2012).
El propósito de la organización es múltiple: permite al analista determinar que se está

haciendo, como se está haciendo, quien lo hace, cuando se lleva a cabo, cuanto tiempo
toma, dónde se hace y por qué se hace (vea figura 2.5) (Shirley, 2012).
Figura 2.5 Técnica de observación para identificación de tareas

Fuente: (Shirley, 2012)
2.5.2.7.Otros
Es una representación pictórica de los pasos en proceso. Útil para determinar cómo
funciona realmente el proceso para producir un resultado (Shirley, 2012).
El resultado puede ser un producto, un servicio, información o una combinación de los

tres. Al examinar cómo los diferentes pasos es un proceso se relacionan entre sí, se
puede descubrir con frecuencia las fuentes de problemas potenciales (Shirley, 2012).
Los diagramas de flujo se pueden aplicar a cualquier aspecto del proceso desde el flujo
de materiales hasta los pasos para hacer la venta u ofrecer un producto (Shirley, 2012).
27
2.5.3. Diagramas UML
La metodología UML (lenguaje Unificado de Modelado) fue creada por tres personajes
que desarrollaron notaciones de análisis muy diferentes pero que al unirlas se llegaría
al lenguaje de modelado, los nombre de estos personajes son Booch el desarrollo el
libro sobre análisis y diseño orientado hacia objetos, James Rumbaugh técnica de
modelación de objetos, Jacobson ingeniería de software orientada a objetos (Neira,
2010).
UML no lo podemos comparar con un lenguaje de programación ya que UML solo
diagrama la realidad de un requerimiento, la programación es un complemento de
UML, o mejor es la manera de planear de una forma sistémica el desarrollo de un
software con el fin de dar solución a un problema (Neira, 2010).
Los diagramas son 13 pero en realidad son 4 los que mayormente se utilizan se utilizan,
su uso va de acuerdo a las necesidades propias de cada sistema, lo ideal es lograr una
buena explicación del sistema gráficamente expresada (Neira, 2010).
2.5.3.1.Diagrama de Secuencia
Este nos muestra la interacción ordenada a través del tiempo de cada evento, muestra
los objetos participantes en cada interacción y los mensajes que intercambian según su
secuencia Vea la Figura 2.6 el cual muestra la estructura de un diagrama de secuencia.
En él se puede visualizar lo que pasa con el sistema a través del tiempo y se pueden dar
las pautas que se tienen cuando es necesario designar un tiempo límite para los
procesos, de igual forma se pueden ver los mensajes que viajan entre cada uno de los
procesos (Neira, 2010).
2.5.3.2.Diagramas de caso de uso
Muestra las relaciones entre actores y casos de uso del sistema, un caso de uso
representa la una funcionalidad del sistema, la cual puede interactuar con elementos
externos como actores u otros sistemas, nos da el paso a paso cada una de las funciones
que va a realizar el programa de una forma modular, de tal forma que se exprese de una
forma gráfica todo lo que va a hacer el sistema vea la figura 2.7 de la estructura de un
diagrama de clases. Se puede decir que es base de muchos de los otros diagramas que
28
se utilizan en UML, ya que muestra que se pretende hacer para suplir la necesidad que
se va a solucionar con el sistema (Neira, 2010).
Figura 2.6 Estructura de diagrama de secuencia

Fuente: (Neira, 2010)
Figura 2.7 Componentes para realizar diagramas de casos de uso

Fuente: (Neira, 2010)
2.6. Metodología SCRUM
SCRUM es un proceso en el que se aplican de manera regular un conjunto de buenas

prácticas para trabajar colaborativamente, en equipo, y obtener el mejor resultado
posible de un proyecto. Estas prácticas se apoyan unas a otras y su selección tiene
origen en un estudio de la manera de trabajar de equipos altamente productivos
(ProyectosAgiles, 2018).
29
En SCRUM se realizan entregas parciales y regulares del producto final, priorizadas
por el beneficio que aportan al receptor del proyecto. Por ello, SCRUM está
especialmente indicado para proyectos en entornos complejos, donde se necesita
obtener resultados pronto, donde los requisitos son cambiantes o poco definidos, donde
la innovación, la competitividad, la flexibilidad y la productividad son fundamentales
SCRUM también se utiliza para resolver situaciones en que no se está entregando al

cliente lo que necesita, cuando las entregas se alargan demasiado, los costes se disparan
o la calidad no es aceptable, cuando se necesita capacidad de reacción ante la
competencia, cuando la moral de los equipos es baja y la rotación alta, cuando es
necesario identificar y solucionar ineficiencias sistemáticamente o cuando se quiere
trabajar utilizando un proceso especializado en el desarrollo de producto
En SCRUM un proyecto se ejecuta en ciclos temporales cortos y de duración

fija (iteraciones que normalmente son de 2 semanas, aunque en algunos equipos son de
3 y hasta 4 semanas, límite máximo de feedback de producto real y reflexión) Figura
2.8. Cada iteración tiene que proporcionar un resultado completo, un incremento de
producto final que sea susceptible de ser entregado con el mínimo esfuerzo al cliente
cuando lo solicite (ProyectosAgiles, 2018).
2.6.1. Las características de la metodología SCRUM son:

 Equipos auto dirigidos
 Utiliza reglas para crear un entorno ágil de administración de proyectos
 No prescribe prácticas específicas de ingeniería
 Los requerimientos se capturan como ítems de la lista Product Backlog
 El producto se construye en una serie de Sprints de un mes de duración
30
Figura 2.8 Proceso de la metodología SCRUM
Fuente: (Peralta, 2003)
2.6.2. Ciclo de vida de SCRUM

El Ciclo de Vida del SCRUM está constituido por un grupo de iteraciones de longitud
fija llamadas Sprint. La estructuración contempla la planificación del SCRUM
(SCRUM Planning), las reuniones diarias de sincronización del equipo (Daily
SCRUM), la revisión del sprint (Sprint Review) y la retrospectiva del sprint (Sprint
Restrospective). Cada una de estas fases considera un conjunto de actividades que
permiten crear productos entregables según los requerimientos de los clientes (Digital,
2013).
A través del siguiente mapa conceptual presentado en la figura 2.9 se puede tener una
visión rápida del Ciclo de Vida del SCRUM.
2.6.3. Fases de la metodología SCRUM

El corazón de SCRUM es un Sprint, es un intervalo prefijado durante el cual se crea
un incremento de producto "Hecho o Terminado" utilizable, potencialmente
entregable. A lo largo del desarrollo hay Sprints consecutivos de duración constante.
31
En este post os quería detallar cinco etapas a considerar para que esta herramienta sea
efectiva y exitosa en vuestros proyectos SCRUM.
Figura 2.9 Ciclo de vida de la metodología SCRUM

Fuente: (Digital, 2013)
En realidad, cada Sprint se puede considerar un mini-proyecto de no más de un mes.

Al igual que los proyectos, los Sprint se utilizan para lograr algo. Cada Sprint cuenta
con una definición de lo que se va a construir, un diseño y un plan flexible que guiará
la construcción del plan, el trabajo, y el producto resultante (Bara, 2016).
SCRUM consta de tres fases (Vea Figura 2.10).
2.6.3.1.Fase pregame
La fase de Pregame incluye dos sub fases: Planning y Architecture (Peralta, 2003)
 Planning: Consiste en la definición del sistema que será construido. Para esto se
crea la lista Product Backlog a partir del conocimiento que actualmente se tiene del
32
sistema. En ella se expresan los requerimientos priorizados y a partir de ella se
estima el esfuerzo requerido1. La Product Backlog List es actualizada
constantemente con ítems nuevos y más detallados, con estimaciones más precisas
y cambios en la prioridad de los ítems.
Figura 2.10 Fases de la metodología SCRUM

Fuente: (Bara, 2016)
 Architecture / High level Design: El diseño de alto nivel del sistema se planifica a
partir de los elementos existentes en la Product Backlog List. En caso de que el
producto a construir sea una mejora a un sistema ya existente, se identifican los
cambios necesarios para implementar los elementos que aparecen en la lista
Product Backlog y el impacto que pueden tener estos cambios. Se sostiene una
Design Review Meeting para examinar los objetivos de la implementación y tomar
decisiones a partir de la revisión, además se construyen historias de usuario de
modo que el análisis para desarrollar el sistema pueda ser mostrado a través de
33
estas. Se preparan planes preliminares sobre el contenido de cada release (Peralta,
2003).
Entrada: La concepción inicial del producto que tienen los accionistas o interesados.
Tareas: Las tareas y asignación responsabilidades de la fase de pregame son descritas
en la Tabla 2.1.
Tabla 2.1 Tareas de la fase Pre - Game
Nombre de
Descripción Responsables
la tarea
Posibles elementos de esta lista son
Crear la
requerimientos técnicos y del negocio, funciones,
Product
errores a reparar, defectos, mejoras y Product Owner
Backlog List
actualizaciones tecnológicas
(Requerida)
requeridas.
Esta actividad se basa en considerar que
Priorizar la
elementos tienen más o menos influencia en el
Product
éxito del proyecto en un momento dado; Product Owner
Backlog List
considerando que los elementos con mayor
(Requerida)
prioridad se realizan primero.
Indagación Se realiza la indagación de información acerca del
de funcionamiento del consultorio, se aplica la
Producr Owner
información ingeniería de requerimientos para poder obtener
(Requerida) los requisitos funcionales y no funcionales.
Es un proceso el cual ayuda a plasmar de manera
Modeling general el funcionamiento que tiene la empresa o
Product Owner
UML negocio. A partir de los modelos se diseña las
SCRUM Team
(Requerida) base de datos, y se establecen la cantidad de Sprint
contara e sistema.
Es un proceso de diseño e implementación de la
Database información que cada módulo va a almacenar.
Modeling Este diseño se realiza a partir de toda la SCRUM Team
(Requerida) información que el SCRUM team haya recibido,
indagado o analizado.
Tareas Se deben identificar la cantidad de tareas que
Scrum Team
(Requerida) sellevan a cabo
Verificación: Deben estar realizadas todas las tareas requeridas
Salida: Product Backlog List, Arquitectura
2.6.3.2.Fase Game
La fase de Development también llamada Game Phase es la parte ágil de SCRUM.
(Peralta, 2003)
34
En esta fase se espera que ocurran cosas impredecibles. Para evitar el caos SCRUM
define prácticas para observar y controlar las variables técnicas y del entorno, así
también como la metodología de desarrollo que hayan sido identificadas y puedan
cambiar. Este control se realiza durante los Sprints. Dentro de variables de entorno
encontramos: tiempo, calidad, requerimientos, recursos, tecnologías y herramientas de
implementación. En lugar de tenerlas en consideración al comienzo del desarrollo,
SCRUM propone controlarlas constantemente para poder adaptarse a los cambios en
forma flexible (Peralta, 2003).
Las Historias de Usuario se componen de tres elementos: (Llopis, 2016)
 Una descripción escrita de la historia usada para la planificación y como un
recordatorio.
 Conversaciones sobre la necesidad de la historia que sirven para profundizar en
los detalles de la misma
 Elementos de prueba que permiten determinar cuándo las tareas que va a cubrir
la historia está completa.
Así una historia (Vea figura 2.11) debe permitir conocer la base de las necesidades del
usuario, así como los detalles que después permitan fijar la batería de pruebas para
poder determinar si un desarrollo es correcto o no (Llopis, 2016).
Figura 2.11 Estructura de una historia de usuario

Fuente: (Llopis, 2016)
35
Inicialmente se fijaba que esas historias de usuario se escribieran en unas tarjetas en
vez de en una libreta, lo que hizo que Ron Jeffries lo llamara CCC Card, Conversation,
Confirmation (Tarjeta, Conversación y Confirmación). Así la tarjeta almacenaba la
historia del usuario, y a través de la Conversación y la confirmación. Hay autores que
afirman que las tarjetas son la mejor forma de almacenar las Historias de Usuario.
(Llopis, 2016)
Entrada: Product Backlog List
Tareas: Las tareas y asignación responsabilidades de la fase de pregame son descritas
en la Tabla 2.2.
Tabla 2.2 Tareas de la fase Game
Nombre de
Descripción Responsables
la tarea
En la segunda fase se decide cómo se van a SCRUM
alcanzar los objetivos del Sprint. En esta fase se Team
Planeacion crea la Sprint Backlog, indicando qué tareas debe SCRUM
(Requerida) desempeñar el equipo para cumplir con dichos Master
objetivos. Product
Owner
Los participantes son clasificados según el
compromiso que tengan con las actividades del
proyecto en dos categorías: gallinas y chanchos1. SCRUM
Los chanchos son los que están más Team
comprometidos y por lo tanto son los que pueden
hablar y brindar opiniones.
Desarrollo Se realizan diseños de diagramas UML a partir de Customers
(Requerida) la información recopilada y se elaboran antes del Management
History User desarrollo y generalmente son presentadas Product
(Requerida) juntamente con historias de usuario. Owner
otros
interesados
Planificación de historias de usuario para
determinar prioridades de desarrollo además de SCRUM
estimar tiempos en que se va a desarrollar dichos Team
módulos
Revision Se realizan revisiones de avance de cada Spint SCRUM
(Requerida) Master
Verificación: Durante un sprint se puede acortar funcionalidad, pero la fecha de
entrega debe ser respetada.
Salida: Incremento del producto
36
2.6.3.3.Fase de PostGame
Contiene el cierre del release. Para ingresar a esta fase se debe llegar a un acuerdo
respecto a las variables del entorno por ejemplo que los requerimientos fueron
completados. El sistema está listo para ser liberado y es en esta etapa en la que se realiza
integración, pruebas del sistema y documentación (Peralta, 2003).
2.6.4. Roles y responsabilidades
2.6.4.1.SCRUM Master
Es un rol de administración que debe asegurar que el proyecto se está llevando a cabo
de acuerdo con las prácticas, valores y reglas de SCRUM y que todo funciona según lo
planeado. Su principal trabajo es remover impedimentos y reducir riesgos del producto.
Este rol suele ser desempeñado por un Gerente de Proyecto o Líder de equipo (Peralta,
2003).
2.6.4.2.Product Owner
Es el responsable del proyecto, administra, controla y comunica la Backlog List. Es el
responsable de encontrar la visión del producto y reflejarla en la Backlog List.
Generalmente esta persona puede ser el Product Manager, Marketing, Internal
Customer, etc. (Peralta, 2003).
2.6.4.3.SCRUM Team
Es el equipo del proyecto que tiene la autoridad para decidir cómo organizarse para
cumplir con los objetivos de un Sprint. Sus tareas son: Effort Estimation (Estimar
Esfuerzo), crear el Sprint Backlog, revisar la Product Backlog List y sugerir obstáculos
que deban ser removidos para cumplir con los ítems que aparecen. (Peralta, 2003)
Típicamente es un equipo de entre 5 y 10 personas cada una especializada en algún
elemento que conforma los objetivos a cumplir, por ejemplo: Programadores,
Diseñadores de Interfaz de usuario, etc. La dedicación de los miembros del equipo
debería ser full-time con algunas excepciones. La membresía solo puede cambiar entre
sprints (no durante) (Peralta, 2003).
37
2.6.4.4.Customer
El cliente participa en las tareas que involucran la lista Product Backlog (Peralta,
2003).
2.6.4.5.Management
Es el responsable de tomar las decisiones finales, acerca de estándares y convenciones
a seguir durante el proyecto. Participa en la selección de objetivos y requerimientos y
en la selección del Scrum Owner. Tiene la responsabilidad (Peralta, 2003).
2.7. Aplicaciones WEB
Las aplicaciones web reciben este nombre porque se ejecutan en la internet. Es decir
que los datos o los archivos en los que trabajas son procesados y almacenados dentro
de la web. Estas aplicaciones, por lo general, no necesitan ser instaladas en tu
computador (Gcfa, 2016).
El concepto de aplicaciones web está relacionado con el almacenamiento en la nube.

Toda la información se guarda de forma permanente en grandes servidores de internet
y nos envían a nuestros dispositivos o equipos los datos que requerimos en ese
momento, quedando una copia temporal dentro de nuestro equipo (Gcfa, 2016).
En la ingeniería de software se denomina aplicación web a aquellas herramientas que

los usuarios pueden utilizar accediendo a un servidor web a través de internet o de una
intranet mediante un navegador. En otras palabras, es un programa que se codifica en
un lenguaje interpretable por los navegadores web en la que se confía la ejecución al
navegador (Gcfa, 2016).
Las aplicaciones web son populares debido a lo práctico del navegador web como
cliente ligero, a la independencia del sistema operativo, así como a la facilidad para
actualizar y mantener aplicaciones web sin distribuir e instalar software a miles de
usuarios potenciales (Gcfa, 2016).
Es importante mencionar que una página web puede contener elementos que permiten
una comunicación activa entre el usuario y la información. Esto permite que el usuario
38
acceda a los datos de modo interactivo, gracias a que la página responderá a cada una
de sus acciones, como por ejemplo rellenar y enviar formularios, participar en juegos
diversos y acceder a gestores de base de datos de todo tipo (Wikipedia, 2017).
Las aplicaciones web requieren de muchos componentes, pero los más esenciales son
el servidor, la computadora y acceso a internet figura 2.12.
Figura 2.12 Arquitectura de una aplicación web

Fuente: (Informatica, 2009)
2.7.1. Características y Ventajas de las Aplicaciones Online
Una aplicación web es un sistema informático que los usuarios utilizan accediendo a
un servidor web, a través de Internet o de una intranet. Las aplicaciones web son
populares debido a la practicidad del navegador web, que actualmente, está disponible
tanto en equipos de escritorio, notebooks, celulares, Tablet, etc. La facilidad para
actualizar y mantener aplicaciones web sin distribuir e instalar software en miles de
potenciales clientes es otra razón de su popularidad (LoginDesarrollos, 2018).
39
Para el sistema de información del consultorio de enfermería se aplican las siguientes
características, ya que no requieren actualizaciones:
 Compatibilidad multiplataforma: Una misma versión de la aplicación puede

correr sin problemas en múltiples plataformas como Windows, Linux, Mac,
Android, etc.
 Acceso inmediato y desde cualquier lugar: Las aplicaciones basadas en
tecnologías web no necesitan ser descargadas, instaladas y configuradas.
Además, pueden ser accedidas desde cualquier computadora conectada a la red
en donde se accede a la aplicación.
 Menos requerimientos de hardware: Pueden funcionar en cualquier equipo
que disponga de un navegador web. Esto aplica tanto a celulares, Tablet y otros
dispositivos modernos.
 Seguridad en los datos: Los datos se alojan en servidores ubicados en
datacenters con toda la infraestructura necesaria para asegurar la protección de
datos y el funcionamiento constante de las aplicaciones.
2.7.2. Modelo de base de datos

Las bases de datos son un gran pilar de la programación actual, ya que nos permiten
almacenar y usar de forma rápida y eficiente cantidades ingentes de datos con cierta
facilidad. En la actualidad se usa de forma mayoritaria las bases de datos relacionales
(dominadas por distintos gestores a través del lenguaje SQL, en gran medida)
(Gutiérrez, 2013).
2.7.2.1.Modelo entidad relación
Este modelo se representa a través de diagramas y está formado por varios elementos.
Este modelo habitualmente, además de disponer de un diagrama que ayuda a entender
los datos y como se relacionan entre ellos, debe de ser completado con un pequeño
resumen con la lista de los atributos y las relaciones de cada elemento (Gutiérrez,
2013).
40
Este modelo comprende de los siguientes componentes y los mismos son reflejados en
un ejemplo en la Figura 2.13:
- Entidad: Las entidades representan cosas u objetos (ya sean reales o abstractos), que
se diferencian claramente entre sí.
- Atributos: Los atributos definen o identifican las características de entidad (es el
contenido de esta entidad). Cada entidad contiene distintos atributos, que dan
información sobre esta entidad. Estos atributos pueden ser de distintos tipos
(numéricos, texto, fecha, etc.).
- Relación: Es un vínculo que nos permite definir una dependencia entre varias
entidades, es decir, nos permite exigir que varias entidades compartan ciertos atributos
de forma indispensable.
Figura 2.13 Estructura de modelo entidad relación

Fuente: (Gutiérrez, 2013)
2.7.2.2.Modelo físico
Un modelo de datos físico es un modelo específico de bases de datos que representa
objetos de datos relacionales (por ejemplo, tablas, columnas, claves principales y
claves externas vea la figura 2.14) y sus relaciones. Un modelo de datos físico se puede
utilizar para generar sentencias DDL que, después, se pueden desplegar en un servidor
de base de datos (IBM, 2015).
41
Mediante el entorno de trabajo, puede crear un modelo de datos físico de diferentes
maneras: (IBM, 2015)
 Cree un modelo físico en blanco mediante un asistente

 Cree un modelo de datos físicos a partir de una plantilla mediante un asistente
 Revierta la ingeniería de un modelo físico de una base de datos o un archivo
DDL mediante un asistente o arrastrando objetos de datos del Explorador de
orígenes de datos
 Importe un archivo de modelo de datos físico del sistema de archivos
 Cree un modelo físico mediante la transformación de un modelo de datos lógico
Figura 2.14 Ejemplo de un modelo físico de una base de datos

Fuente: (IBM, 2015)
2.8. Pruebas de funcionalidad, Estándares de calidad y seguridad

2.8.1. Calidad del producto ISO 9126
El estándar ISO 9126 ha sido desarrollado en un intento de identificar los atributos
clave de calidad para el software evalúa los productos de software, esta norma nos
indica las características de la calidad y los lineamientos para su uso. El estándar
identifica 6 atributos clave de calidad (Vea Figura 2.15): (Lozano L. , 2013)
42
Figura 2.15 Características de la norma de calidad ISO 9126
Fuente: (Lozano L. A., 2013)
• Funcionalidad: el grado en que el software satisface las necesidades indicadas por

los siguientes sub atributos: idoneidad, corrección, interoperabilidad, conformidad
y seguridad. La funcionalidad es definida de la con la Ecuación 2.2.
PFA = PFSA * (0,65 + (0.01 * FC))

Ecuación 2.1 formula para el cálculo de la funcionalidad
𝑃𝐹𝐴
FUNCIONALIDAD = 𝑃𝐹𝐴
𝑚𝑎𝑥
Ecuación 2.2 Fórmula de funcionalidad
Dónde:
FPA = Análisis de Punto Función.
• Usabilidad: grado en que el software es fácil de usar. Viene reflejado por los
siguientes sub atributos: facilidad de comprensión, facilidad de aprendizaje y
operatividad.
La usabilidad de un sistema se calcula por medio de la Ecuación 2.2:
43
∑𝑉𝑎𝑙𝑜𝑟
( )𝑥100
𝑛
𝑈𝑠𝑎𝑏𝑖𝑙𝑖𝑑𝑎𝑑 = 5
Ecuación 2.3 Formula para el cálculo de usabilidad
• Eficiencia: grado en que el software hace óptimo el uso de los recursos del sistema.
Está indicado por los siguientes sub atributos: tiempo de uso y recursos utilizados.
• Facilidad de mantenimiento: la facilidad con que una modificación puede ser

realizada. Está indicada por los siguientes sub atributos: facilidad de análisis,
facilidad de cambio, estabilidad y facilidad de prueba, se debe aplicar la Ecuación
2.3:
IMS = ([MT-(FA+FC+FD)]) /MT

Ecuación 2.4 Formula para el cálculo de mantenibilidad del sistema
Dónde:
MT = es el número de módulos de la versión actual.
FC = número de módulos que han cambiado.
FA = número de módulos en la versión actual que se han añadido.
FD = número de módulos de la versión actual que se han borrado.
• Portabilidad: la facilidad con que el software puede ser llevado de un entorno a

otro. Está referido por los siguientes sub atributos: facilidad de instalación,
facilidad de ajuste, facilidad de adaptación al cambio.
Esta parte del estándar ISO/IEC 9126 es un reporte técnico que incluye las métricas
internas que se pueden aplicar a un producto de software; cabe destacar que al ser
métricas internas se aplican a productos de software no ejecutables; además, presenta
una serie de ejemplos sobre métricas que pueden ser aplicadas y un marco de trabajo
(framework) para realizar mediciones a un producto de software particular. En la Tabla
5 se ilustra la equivalencia entre las características del ISO/IEC 9126 y el ISO/IEC
25012, que actualmente se usa como base para adaptarlo al modelo de calidad de datos
del ISO 25012.
44
2.8.2. Prueba de Humo
Con las pruebas de humo se pueden verificar los flujos más significativos de una
aplicación o de una versión entregada al momento del despliegue a pruebas, de manera
que las funciones básicas del software operen de forma correcta mediante pruebas
rápidas y sencillas. Estas pruebas son muy comunes en realizar aunque muchas veces
no se tiene claro el concepto, por ejemplo cuando no se conoce la aplicación y es
necesario hacer pruebas más exhaustivas, las pruebas de humo van permitiendo que se
entiendan los flujos; en este caso, se dará un ejemplo de una aplicación que maneja
procesos financieros y se realizó la entrega a pruebas de una funcionalidad nueva
dentro del flujo de pagos de tarjeta de crédito, se hacen pruebas de humo donde se
valida que la funcionalidad cumpla con lo especificado en el requerimiento,
suponiendo que se entregó para que la aplicación permita enviar un correo de
confirmación después de hecho el pago, se debe validar dicha funcionalidad y a su vez
aquellas que sean las básicas para la realización del pago, como el pago mínimo y total
de la tarjeta de crédito (Administrador, 2016).
Los pasos a seguir para la ejecución de las pruebas de humo son (Véase la Figura 2.16
para observar donde entra esta prueba en el ciclo de pruebas): (Administrador, 2016)
o Integrar el sistema para iniciar las pruebas
o Ejecutar los casos de prueba definidos
o Encontrar errores
45
Figura 2.16 Pruebas de humo ubicadas en el ciclo de pruebas
Fuente: (Administrador, 2016)
Las pruebas de humo son un método de las pruebas de caja negra donde se mide que
las entradas y salidas son aceptadas correctamente, tomando como base que la
integridad de la información externa (datos de prueba) no varía. Se debe tener en cuenta
que este tipo de pruebas no valida que todo esté exento de errores, pero sí que la versión
no se desestabilice evitando que se pasen errores de alto impacto en la funcionalidad
(Administrador, 2016).
2.9. Seguridad ISO 27001

2.9.1. Autenticación y autorización
ISO 27001 es una herramienta perfecta para controlar la seguridad de la información y

aplicar medios que permitan conseguirla. Pero, en una empresa, ya sea pequeña,
mediana o grande existen diferentes empleados, encargados de distintos tipos de tareas,
y no todos tienen acceso a toda la información de la misma, entonces ¿Cómo se controla
el acceso a los sistemas de información? (Seguridad, 2014).
Lo primero de todo para controlar el acceso es identificar qué usuarios que tienen
derecho a acceder a cada tipo de información, los cuales accederán a ella mediante:
(Seguridad, 2014)
46
 Autenticación: proceso por el que el usuario de identifica en el equipo donde se
alojan los recursos a los que quiere acceder.
 Autorización: proceso mediante el que el usuario obtiene los privilegios
necesarios para poder tratar la información.
2.9.2. Encriptación
Las inspecciones criptográficas tienen que ser conforme a los requerimientos generales
de seguridad de la organización. La introducción de algún control tiene que
determinarse siempre conforme a la identificación de cualquier riesgo que la empresa
no asume, y cuya inversión no puede llegar a más que el valor del activo el cual se
protege, por lo que entonces no llegaría a ser rentable (ISO, 2014).
Con el fin de asegurar la correcta gestión de los distintos controles criptográficos que
se pueden introducir, se considera necesario establecer una política basada en el uso de
este prototipo de controles. Con la utilización de dichas inspecciones se obtiene
integridad, confidencialidad, y el no repudio de la información (ISO, 2014).
Por tanto, encontramos diferentes niveles de seguridad con algoritmos, más o menos
complejos, con los que puedes encriptar cualquier cosa: números de tarjetas de créditos,
correos electrónicos, nombre de usuarios, documento de textos, claves etc. y
protegerlos en caso de sufrir un hackeo (Econectia, 2017).
2.10. Estimación de costo

2.10.1. COCOMO II
Constructivo Cost Model II (COCOMO® II) es un modelo que permite estimar el
costo, el esfuerzo y el cronograma al planificar una nueva actividad de desarrollo de
software. COCOMO® II es la última extensión más importante del modelo original
COCOMO® ( COCOMO® 81 ), publicado en 1981. Consta de tres sub modelos, cada
uno de los cuales ofrece mayor fidelidad a medida que uno avanza en el proceso de
planificación y diseño del proyecto. Incluidos en una fidelidad cada vez mayor, estos
47
sub modelos reciben el nombre de Modelos de composición de aplicaciones, Diseño
inicial y Arquitectura posterior (Boehm B. W., 2017).
COCOMO® II se puede utilizar para las siguientes situaciones de decisión principales
 Tomar decisiones de inversión u otras decisiones financieras que impliquen un

esfuerzo de desarrollo de software
 Establecer los presupuestos y programas del proyecto como una base para la
planificación y el control
 Decidir o negociar compensaciones entre los costos de software, el cronograma,

la funcionalidad, el rendimiento o los factores de calidad
 Hacer que el software cueste y programar decisiones de gestión de riesgos
 Decidir qué partes de un sistema de software desarrollar, reutilizar, arrendar o

comprar
 Tomar decisiones de inventario de software heredado: qué partes modificar,

eliminar, subcontratar, etc.
 Establecer estrategias de inversión mixtas para mejorar la capacidad del

software de la organización, a través de la reutilización, las herramientas, la
madurez del proceso, la subcontratación, etc.
 Decidir cómo implementar una estrategia de mejora de procesos, como la

proporcionada en el SEI CMM
2.10.2. Beneficio
Una inversión es una operación financiera definida por una serie de desembolsos que
se estima que van a generar una corriente futura de ingresos (cash flows).
El VAN y el TIR son dos herramientas financieras procedentes de las matemáticas

financieras que nos permiten evaluar la rentabilidad de un proyecto de inversión
(conocidos los flujos de fondo- cash flows - y su valoración de coste), entendiéndose
48
por proyecto de inversión no sólo como la creación de un nuevo negocio, sino también,
como inversiones que podemos hacer en un negocio en marcha, tales como el desarrollo
de un nuevo producto, la adquisición de nueva maquinaria, el ingreso en un nuevo
rubro de negocio, etc. (Llorente, 2017).
2.10.3. VAN
El VAN es un método de valoración de inversiones en la que partimos de la rentabilidad
mínima que queremos obtener. Con esta rentabilidad mínima calcularemos el valor
actualizado de los flujos de caja (diferencia entre cobros y pagos) de la operación. Si
es mayor que el desembolso inicial la inversión es aceptable. Interpretación VAN:
𝑉𝐴𝑁 > 0: Se recomienda pasar a la siguiente etapa del proyecto
𝑉𝐴𝑁 = 0: Es indiferente realizar la inversión
𝑉𝐴𝑁 < 0: Se recomienda desecharlo o postergarlo
El VAN se calcula según la Ecuación 2.4.
𝑛
𝑄𝑖
0 = −𝐴 + ∑
(𝑖 + 𝑘)𝑖
𝑖=1
Ecuación 2.5 Formula para el cálculo de VAN
Donde:
𝑸1, 𝑸2, …, 𝑸n : Flujos de caja.
𝒌 : Tasa de descuento seleccionada
𝑨 : Desembolso inicial o inversión inicial.
𝒏 : Vida útil del proyecto.
𝒊 : Período.
49
2.10.4. TIR
Es una tasa porcentual que indica la rentabilidad promedio anual que genera el capital
que permanece invertido en el proyecto. También se define como la tasa de descuento
que hace que el 𝑉𝐴𝑁 = 0, su valor no depende del tiempo y representa el máximo costo
que el inversionista podría pagar por el capital prestado (Mariátegui, 2017).
𝑇𝐼𝑅 > 𝑘: se recomienda pasar a la siguiente etapa.
𝑇𝐼𝑅 = 𝑘: es indiferente invertir.
𝑇𝐼𝑅 < 𝑘: se recomienda su rechazo o postergación.
La TIR se calcula con la Ecuación 2.5.
𝒏
𝑸𝒊
𝟎 = −𝑨 + ∑
(𝟏 + 𝑻𝑰𝑹)𝒊
𝒊=𝟏
Ecuación 2.6 Formula para el cálculo de TIR
Donde:
𝑸1, 𝑸2, …, 𝑸n: Flujos de caja.

𝑨 : Desembolso inicial o inversión inicial.
𝒏 : Vida útil del proyecto.
𝒊 : Período.
2.10.5. Costo – Beneficio

Para calcular el costo beneficio usaremos una tabla anterior con la que se calculó el
“valor actual neto”, usamos la Ecuación 2.6 donde encontramos el total de gastos y
beneficios (ingresos) (Astros, 2017).
𝑻𝒐𝒕𝒂𝒍 𝑩𝒆𝒏𝒆𝒇𝒊𝒄𝒊𝒐𝒔
𝑪𝒐𝒔𝒕𝒐 𝑩𝒆𝒏𝒆𝒇𝒊𝒄𝒊𝒐 = 𝑻𝒐𝒕𝒂𝒍 𝑮𝒂𝒔𝒕𝒐𝒔
Ecuación 2.7 Formula para el cálculo de costo – Beneficio
50
Capítulo 3
Marco Aplicativo
3.1.Introducción
En este capítulo se presenta el proceso detallado de la aplicación de la metodología
SCRUM, además de plasmar diagramas que representen la estructura de la base de
datos como también diagramas UML que representen los procesos que comprende los
distintos módulos determinados en el capítulo 1. También se muestra los roles que
cumplen los agentes que están a cargo funcionamiento del consultorio.
3.2.Pre - Game (Antes del desarrollo)

A través de la ingeniería de software se presenta la descripción de roles asignados a los
distintos tipos de usuarios del consultorio, además se identifican los requerimientos
para posteriormente cumplir con ellos en la etapa de Game.
Tabla 3.1 Descripción de roles en la atención del servicio del consultorio
Usuario Descripción Rol

Es el encargado de supervisar Realizar el seguimiento a
las conclusión de tareas conclusión de tareas realizadas por
asignadas a la enfermera, el enfermero a cargo del
revisar informes, controlar la consultorio, registrar nuevos
Supervisor(a)
información, registrar al servicios y registrar nuevos
personal y asignar usuarios. materiales de trabajo. Registrar
datos personales del personal
enfermero.
Es responsable de la atención Su tarea es registrar al paciente,
del consultorio, quien registrar el servicio prestado,
Enfermero(a) supervisa la evolución de los realizar informes mensuales al
pacientes supervisor, solicitar dotación de
insumos para los servicios.
Son encargados de colaborar Realizar los registros de atención
Auxiliares en la atención del consultorio de pacientes, apoyo en
vacunaciones.
Paciente del consultorio Debe brindar datos claros y
Paciente específicos, además de realizar los
pagos si es que se requiere.
51
3.2.1. Descripción de roles y función
En el consultorio se identifica 4 actores (Director(a), Supervisor(a), Enfermero(a) y
Paciente) que cumplen tareas de forma permanente y temporal. Estos actores tienen
un rol asignado reflejado en la tabla 3.1.
3.2.2. Indagación y elaboración de requerimientos

Las tareas rutinarias que se realizan por los usuarios mencionados del consultorio son
reflejadas de forma detallada en las Tablas 3.2 y 3.3.
Tabla 3.2 Tareas del usuario Director(a) y Supervisor(a)
Nro. Tarea
1 Registrar al personal enfermero a cargo del consultorio.
2 Otorgar privilegios a personal enfermero.
3 Registrar Materiales nuevos de trabajo
4 Registrar nuevos servicios
Tabla 3.3 Tareas del usuario Enfermero(a)
Nro. Tarea
1 Registrar los datos personales del paciente.
2 Registrar los insumos dotados por el PAI
3 Realizar la búsqueda de información clínica del paciente en los registros.
Registrar los datos de la consulta del paciente, verificar en los registros la
4
posible duplicidad del servicio a brindar
5 Registrar diariamente la salida o uso de insumos utilizados
Registrar los insumos desperdiciados por motivos de fecha de
6
vencimiento, contaminación, etc.
Elaborar un informe mensual de la producción de servicios de
7
procedimientos enfermeros dentro el consultorio.
Elaborar un informe mensual detallado de las cantidades de vacunación
8
realizadas.
A partir de la interacción de los usuarios descritos en la Tabla 3.1 con sus respectivos
roles en el funcionamiento del consultorio, se pueden determinar los requerimientos
funcionales del sistema mostrados en la Tabla 3.4 y los requisitos no funcionales
mostrados en la Tabla 3.5.
52
Tabla 3.4 Requerimientos funcionales del sistema
Ref. Requisito funcional
R01 Realizar el registro de personal que administra el consultorio
R02 Habilitación y control de usuarios para acceso al sistema
R03 Registrar o actualizar datos del paciente
R04 Seguimiento de curaciones, vacunas, inyectables, etc. Aplicadas a los
pacientes
R05 Registrar ingreso de insumos al consultorio
R06 Registrar la salida o uso de insumos
R07 Verificar la existencia y caducidad de insumos
R08 Generar reportes de servicios brindados en el consultorio
R09 Generar reportes de seguimiento de uso de los insumos
R10 Contar con un mecanismo de control de registro de datos correctos de
pacientes
R11 Contar con un mecanismo de control de alteración de datos de pacientes
R12 Añadir un mecanismo de seguridad para los datos registrados
R13 Guardar y actualizar nuevos servicios para la atención en el consultorio
R14 Guardar y actualizar los datos específicos de materiales de trabajo para
registro de insumos
Tabla 3.5 Requerimientos no funcionales del sistema
Ref. Requisito no funcional

Interfaz El sistema debe funcionar con navegador web
grafica
Respuestas de El tiempo de respuesta del sistema debe ser de inmediato
registro
El acceso es restringido por usuario y contraseña designado por el
Acceso
supervisor
Red Debe contar con acceso a internet para su funcionamiento
Debe contar con recursos computacionales actuales de acuerdo a
Software
requerimientos de hardware de la pagina
Los datos deben guardarse de manera restringida sin que otro
Fiabilidad
usuario pueda acceder a dicha información
3.2.3. Descripción de la visión general del sistema

Según la metodología SCRUM en la fase de pregame es necesario analizar las
prioridades con el cual el sistema debe ser desarrollado, de modo que se pueda partir
53
desarrollando por la tarea con mayor prioridad, además de definir la cantidad de
sprints, es así que se presenta en la Tabla 3.6 las tareas y su prioridad.
Tabla 3.6 Tareas realizadas en el consultorio

Necesidad Prioridad Característica Solución
Registro de Alta La duplicidad del registro de Registro único en la
pacientes un paciente, conduce a una base de datos de la
mala elaboración de informes información personal
del paciente
Registro de Media Mantener al día el stock del Registrar el insumo y
insumos insumo lleva a ocasionar que automáticamente al
demoras realizar la atención a un
paciente este vaya
descontando el stock
Control de Alta En las atenciones puede Desarrollar un módulo
duplicidad presentarse el caso de que un de control dentro del
de paciente ya haya recibido una software para la
atenciones vacuna y el paciente haya supervisión de
olvidado duplicidad de los datos
Registro de Baja No se tiene un código de Crear usuarios con roles
personal acceso asignados para el
manejo del sistema
Elaboración Media Realizar un informe con datos Elaboración con conteo
de informes estadísticos, el cual se realiza automatizado por el
un conteo manual en la sistema
cantidad de servicios
Registro de Baja Los servicios y materiales Desarrollar un módulo
materiales nuevos con que se trabajan en de registros de nuevos
y servicios el consultorio deben ser servicios y materiales,
añadidas a los cuadernos de el cual pueda trabajar
registros y formularios con el módulo de
respectivos atenciones.
3.3.Modelo de casos de uso
En la Figura 3.1 se puede reflejar de forma general el proceso que se lleva a cabo en el
consultorio de Enfermería, involucrando a los actores(Supervisor(a), enfermero(a) y
paciente).
54
Figura 3.1 Modelo de casos de uso general del funcionamiento del consultorio
3.4.Diagrama entidad relación

En base a los requerimientos proporcionados por los usuarios finales y con la ayuda del diseño
del diagrama de casos de uso de la Figuran 3.1 que muestra de manera general el
funcionamiento y las tareas que se llevan a cabo en el consultorio, es así que se realiza el diseño
de la estructura de base de datos (Ver Figura 3.2) que se va a implementar para el sistema.
Figura 3.2 Diseño de la base de datos plasmado a través de un diagrama entidad relación
55
3.5.Game (Durante el desarrollo)
A partir de la obtención de información y el análisis de requerimientos obtenidos en la
fase de Pre – Game es que se continua y elabora de manera más detallada los procesos
por el cual atravesara el desarrollo del sistema, empezando primeramente por la
implementación de la base de datos y luego al desarrollo de los módulos propuestos.
3.5.1. Modelo físico de base de datos

Acorde al diseño elaborado a través de diagrama entidad relación plasmado en la Figura
3.2 se implementa con el lenguaje SQL la creación de las tablas, y obteniendo como
resultado una estructura no entendible, es así que a través de una herramienta propia de
MYSQL se puede reflejar la estructura física reflejada en la Figura 3.3.
Figura 3.3 Modelo físico de la base de datos del consultorio de Enfermería
3.5.2. Tareas identificadas s

De acuerdo a los requerimientos obtenidos se puede establecer la cantidad de
iteraciones (Sprint) que va a constar el sistema dando así prioridades de desarrollo esto
para poder solventar los módulos propuestos. Se refleja en la Tabla 3.7 las 5 tareas
definieron para la atención del consultorio.
56
Tabla 3.7 Conformación de Sprint (Iteraciones) de acuerdo a prioridades
N° Programador
Tarea Tipo Prioridad
Sprint Responsable
1 Desarrollo de interfaz de Diseño y Alta Jorge Lara
usuario de administración de desarrollo Ticona
información del paciente y
registro de atención.
2 Desarrollo de interfaz de Diseño y Alta Jorge Lara
usuario de administración de desarrollo Ticona
inventario de insumos
3 Desarrollo de módulo de Diseño y Alta Jorge Lara
reportes y estadísticas desarrollo Ticona
4 Desarrollo de módulo de Diseño y Media Jorge Lara
seguridad y registro de desarrollo Ticona
personal
5 Desarrollo de módulo de Diseño y Alta Jorge Lara
registro de materiales y desarrollo Ticona
servicios
Para la fase game, a partir de los Sprints definidos de manera general, se determinan
de manera más detallada los subprocesos que cuenta cada uno de estos Sprints, además
se toma en cuenta los diagramas realizados para poder poner énfasis a cada subproceso
conforme a los requerimientos que son reflejados en la Tabla 3.4.
3.5.2.1.Sprint N° 1 Desarrollo de interfaz de usuario de pacientes.
- Planificación: A través de un diagrama de casos de uso se muestra la función
del proceso de administración del paciente, el cual se lleva a cabo las tareas de
registro, modificación de información, y listados de pacientes reflejado en la
Figura 3.4, también se refleja las funciones que realiza este proceso en la Figura
3.5.
57
Figura 3.4 Diagrama de casos de uso del proceso de atención
Figura 3.5 Diagrama de secuencia que refleja las tareas del proceso de atención
- Desarrollo: Conforme al diseño del modelo de caso de uso de la Figura 3.4 y

efectuando los requerimientos R01, R03 y R04 de la Tabla 3.4 se detalla en la
Tabla 3.8 los procesos el cual consta este sprint.
58
Tabla 3.8 Lista de tereas (Sprint Backlog) del sprint 1
SPRINT N° 1
ID PROCESO SUBPROCESO TIPO ESTADO
1 Módulo de registro de Altas, Desarrollado Terminado
pacientes modificaciones
2 Módulo de registro de Registro datos Desarrollado Terminado
atención
3 Módulo de seguimiento de Consultas de la Desarrollado Terminado
consultas de pacientes base de datos y
listados
Conforme a la asignación de tareas en el sprint 1, se determinan 3 historias de usuario

reflejadas en las Tablas 3.9, 3.10 y 3.11.
Tabla 3.9 Historia de usuario módulo de registro de pacientes

Nombre de la historia de usuario: Módulo de registro de pacientes
Usuario: Enfermero(a) Iteración asignada: 1
Prioridad: alta Riesgo en desarrollo: alta
Descripción
Registrar los datos personales del paciente y la fecha de registro.
Observaciones
Ninguna
Tabla 3.10 Historia de usuario módulo de registro de atención

Nombre de la historia de usuario: Módulo de registro de atención
Descripción
Registrar datos del servicio de proceso enfermero.
Registrar datos del servicio de vacunación al paciente
Observaciones
Solo se permite un registro por paciente
59
Tabla 3.11 Historia de usuario del Módulo de seguimiento de consultas de pacientes
Nombre de la historia de usuario: Módulo de seguimiento de consultas de
pacientes
Prioridad: media Riesgo en desarrollo: baja
Descripción
Registrar la búsqueda de información acerca de las consultas realizadas por los
pacientes.
Observaciones
El personal que administra el consultorio puede realizar la búsqueda del paciente y
visualizar su registro de atenciones.
3.5.2.2.Sprint N° 2 Desarrollo de interfaz de usuario de administración de

insumos
- Planeación: En la Figura 3.6 se observa el proceso que realiza el personal
enfermero para la administración y gestión del inventario de insumos, además
en la Figura 3.7 se muestra a través de un diagrama de componentes el
funcionamiento ejemplificado de los registros de insumos y salida de los
mismos.
Figura 3.6 Modelo de casos de uso del proceso de administración de insumos
60
Figura 3.7 Diagrama de secuencia que refleja las tareas que se realiza en el proceso de ingreso y salida
de insumos
- Desarrollo: En base al modelo de casos de uso de la Figura 3.6 y efectuando

los requerimientos R04, R05, R06 y R07 de la Tabla 3.4, se puntualiza los
procesos de manera detallada en la Tabla 3.12.
Tabla 3.12 Lista de tareas (Sprint Backlog) del Sprint 2
SPRINT N° 2
1 Módulo de registro de Altas y listado Desarrollado Terminado
jeringas
2 Módulo de registro de Altas y listado Desarrollado Terminado
vacunas
3 Módulo de registro de altas Desarrollado Terminado
salida o uso de insumos

61
Tabla 3.13 Historia de usuario del módulo de registro de jeringas
Nombre de la historia de usuario: Módulo de registro de jeringas
Descripción
Registrar los datos de ingreso de insumos de tipo vacuna, nro. de comprobantes,
origen de jeringas, stock y fecha de caducidad.
Observaciones
Ninguna
Tabla 3.14 Historia de usuario del módulo de registro de vacunas

Nombre de la historia de usuario: Módulo de registro de vacunas
Descripción
Registrar los datos de ingreso de insumos de tipo jeringas, nro. de comprobantes,
origen de jeringas, stock, medida y fecha de caducidad.
Observaciones
Ninguna
Tabla 3.15 Historia de usuario del Módulo de registro diario de salida o uso de insumos
Nombre de la historia de usuario: Módulo de registro diario de salida o uso de
insumos
Descripción
Registrar los insumos utilizados en el proceso de atención del paciente
Observaciones
Este registro es realizado por el sistema en segundo plano, se puede realizar
seguimiento al mismo en el Módulo de reportes de insumos
3.5.2.3.Sprint N° 3 Desarrollo de módulo de reportes y estadísticas

- Planeación: Realizando un diagrama de casos de uso reflejado en la Figura 3.8
se observa el proceso el cual realiza el personal enfermero obtener los informes
o reportes acerca del servicio y estado de inventario de insumos, además en la
62
Figura 3.9 se muestra a través de un diagrama de componentes el
funcionamiento.
Figura 3.8 Diagrama de casos de uso del proceso de elaboración de reportes de producción
Figura 3.9 Diagrama de componentes que refleja las tareas del proceso de reportes
63
- Desarrollo: En base al modelo de casos de uso de la Figura 3.9 y efectuando
los requerimientos R08 y R09 de la Tabla 3.4, se puntualizan los procesos
detallados para este sprint en la Tabla 3.16.
Tabla 3.16 Lista de tereas (Sprint Backlog) del sprint 3
SPRINT N° 3
1 Módulo de recopilación de listados Desarrollado Terminado
datos sobre prestación de
servicios
2 Módulo de uso de seguimiento listados Desarrollado Terminado
de insumos
3 Módulo de estadísticas de listados Desarrollado Terminado
prestación de servicios

Tabla 3.17 Historia de usuario del Módulo de recopilación de datos sobre prestación de servicios
Nombre de la historia de usuario: Módulo de recopilación de datos sobre
prestación de servicios
Prioridad: media Riesgo en desarrollo: media
Descripción
Consultas y conteos de los registros de producción de servicios.
Observaciones
Esta operación se obtiene por medio de opciones de búsqueda de información, el
cual el usuario administrador selecciona la información requerida mediante un
formulario.
Tabla 3.18 Historia de usuario del Módulo de seguimiento de uso de insumos

Nombre de la historia de usuario: Módulo de seguimiento de uso de insumos
Descripción
Consultar los registros diarios de uso de materiales para generar un reporte de usos.
Observaciones
Esta operación es concretada a través de filtros de búsqueda proporcionados por el
usuario.
64
Tabla 3.19 Historia de usuario del Módulo de estadísticas de prestación de servicios
Nombre de la historia de usuario: Módulo de estadísticas de prestación de
servicios
Descripción
Recopilar información de las atenciones realizadas en el consultorio (Vacunas,
curaciones, etc.), generar gráficas y datos estadísticos por servicio.
Observaciones
El operador debe proporcionar filtros de búsqueda para poder generar la
información deseada.
3.5.2.4.Sprint N° 4. Desarrollo de interfaz de módulo de seguridad y registro de
personal
- Planificación: A través de un diagrama de casos de uso del proceso de

administración de personal enfermero reflejado en la Figura 3.10 se puede
identificar dos tareas, además en la Figura 3.11 se muestra a través de un
diagrama de componentes el funcionamiento.
Figura 3.10 Modelo de casos de uso del proceso de administración de personal
65
Figura 3.11 Diagrama de secuencia que refleja el proceso de administración de personal enfermero
- Desarrollo: Conforme al diseño del modelo de caso de uso de la Figura 3.10

y puntualizando los requerimientos R01 y R02 de la Tabla 3.4, se puntualizan
los procesos de manera detallada en la Tabla 3.20.
Tabla 3.20 Lista de tareas (Sprint Backlog) del sprint 4
SPRINT N° 4
1 Módulo de registro de Registro de datos Desarrollado Terminado
personal Enfermero
2 Módulo de seguridad por Registro datos Desarrollado Terminado
autenticación

Tabla 3.21 Historia de usuario módulo de registro de personal Enfermero
Nombre de la historia de usuario: Módulo de registro de personal Enfermero
Usuario: Director(a) Iteración asignada: 4
Prioridad: alta Riesgo en desarrollo: media
Descripción
Registrar la información personal de los administradores del consultorio.
Observaciones
Al momento de realizar el registro de personal, se debe asignar un rol para otorgar
limitaciones en el uso del sistema
66
3.5.2.5.Sprint N° 5. Desarrollo de interfaz de módulo de registro de materiales y
servicios.
- Planificación: A través de un diagrama de casos de uso del proceso de
administración de personal enfermero reflejado en la Figura 3.12 se puede
identificar dos tareas, además en la Figura 3.13 se muestra a través de un
diagrama de componentes el funcionamiento.
Figura 3.12 Modelo de casos de uso del proceso de administración de personal
Figura 3.13 Diagrama de secuencia que refleja el proceso de administración de personal enfermero
67
- Desarrollo: Conforme al diseño del modelo de caso de uso de la Figura 3.12
y puntualizando los requerimientos R13 y R14 de la Tabla 3.4, se puntualizan
los procesos de manera detallada en la Tabla 3.22.
Tabla 3.22 Lista de tareas (Sprint Backlog) del sprint 4
SPRINT N° 4
1 Módulo de registro de Registro datos Desarrollado Terminado
materiales
2 Módulo registro de Registro datos Desarrollado Terminado
servicios

reflejadas en las Tablas 3.23 y 3.24.
Tabla 3.23 Historia de usuario módulo de registro de materiales
Nombre de la historia de usuario: Módulo de registro de materiales
Descripción
Realizar el registro de nuevos materiales que vayan a ser utilizados en el
consultorio de Enfermería, con el propósito que al momento de ingresar insumos al
sistema estos ya tengas una clave y detalles asignados.
Observaciones
Solo se puede registrar una sola vez un material y este no puede ser borrado solo
modificado
Tabla 3.24 Historia de usuario módulo de registro de servicios

Nombre de la historia de usuario: Módulo de registro de servicios
Prioridad: baja Riesgo en desarrollo: media
Descripción
Este módulo permite registrar nuevos servicios que vaya a brindar el consultorio.
Observaciones
Las claves asignadas al servicio por el usuario necesariamente deben ser fáciles de
identificar.
68
3.6.Plan de desarrollo de Sprints
Posteriormente definidas los sprint con sus respectivas historias de usuario se traza los
tiempos el cual abarcara cada historia de usuario reflejados en la Tabla 3.24. Cada
subproceso de los Sprints cuentas con un nombre, usuario designado y prioridad de
desarrollo, por ello es que se toma principalmente a aquellos módulos tienen una
prioridad alta.
Tabla 3.25 Plan de entrega final de los Sprints a usuarios finales
3.7.Post – Game (Después del desarrollo)

Luego de haber concluido con la fase Game, se procede a realizar las pruebas de
desarrollo que se exponen en el Capítulo IV a través de la prueba de humo, para
verificar si existen posibles errores o bugs en el sistema.
69
Capítulo 4
Control de Calidad y Seguridad
4.1.Introducción
Para poder establecer la calidad del sistema se trabaja con pruebas exhaustivas de cada
Sprint definidos en el anterior capítulo. En este capítulo se realiza una serie de tareas
para evaluar distintos aspectos que cuenta la Norma de calidad ISO 9126 para sistemas
de información, se realizan inspecciones, revisiones y pruebas utilizadas a lo largo del
ciclo de desarrollo, esto asegura que cada producto cumpla con los requisitos que se
designan.
4.2.Pruebas Exhaustivas
Durante el proceso de desarrollo del sistema se aplicaron pruebas unitarias a cada
módulo definidos para el sistema en base a los Sprint, seguidamente de sus resultados.
4.2.1. Pruebas de Humo Sprint 1

La evaluación del Sprint 1 se da dentro de la revisión con los requerimientos del sistema
también se evaluó antes, durante y después del desarrollo de este Sprint, para poder
tener una retro alimentación constante y así tener una base sólida para afrontar los
siguientes Sprint que se desarrollan. En las tablas 4.1, 4.2 y 4.3 se muestran las
evaluaciones realizadas seguidamente el resultado de los módulos reflejados en las
figuras 4.1, 4.2 y 4.3.
Tabla 4.1 Prueba de desarrollo Sprint Nro. 1 Módulo de registro de pacientes
Prueba de desarrollo
Cód. Prueba: 1 Tipo de Prueba: Humo
Descripción de la prueba
Prueba aplicada a la Historia de Usuario 1 del Sprint 1 correspondiente al llamado
registro y modificación de información de pacientes
Evaluación
- Registro y actualizacion de datos del paciente.
- Validaciones de ingreso de datos.
- Mensajes de error en él envió de datos.
El sistema no presenta falla, los datos son registrados y modificados correctamente
70
Figura 4.1 Resultado de módulo de registro de pacientes
Tabla 4.2 Prueba de desarrollo Sprint Nro. 1 Módulo de registro de atenciones
proceso de atenciones
Evaluación
- Búsqueda del paciente por C.I.
- Búsqueda del paciente por nombre
- Verificaciones de vacunas aplicadas
- Mostrar registros de atención
- Realizar procedimiento enfermero
- Existencia de insumos para proceder a la atención
Conforme se realizaron varios casos de prueba no se encontraron errores
71
Figura 4.2 Resultado del módulo de atenciones
Tabla 4.3 Prueba de desarrollo Sprint Nro. 1 Módulo de seguimiento de consultas de pacientes
seguimiento de consultas de pacientes
Evaluación
- Búsqueda de pacientes mediante carnet
Conforme se realizaron varios casos de prueba no se encontraron errores
72
Figura 4.3 Resultados del módulo de seguimiento de consulta de pacientes

Conforme a las pruebas realizadas en el Sprint 1, de la misma manera se aplican dichas
pruebas a los módulos que contiene el Sprint 2. En las tablas 4.4, 4.5 y 4.6 se muestran
las evaluaciones realizadas seguidamente el resultado de los módulos reflejados en las
figuras 4.4, 4.5 y 4.6.
Tabla 4.4 Prueba de desarrollo Sprint Nro. 2 Módulo de registro de jeringas

Prueba aplicada a la Historia de Usuario 1 de Sprint 2 correspondiente al llamado
registro y modificación de ingreso de jeringas
Evaluación
- Validaciones de fechas.
- Alertas de envió correcto de datos.
- Registro de jeringas en el registro diario.
El sistema no presenta falla, los datos son registrados y modificados correctamente
73
Figura 4.4 Resultado del módulo de registro de jeringas
Tabla 4.5 Prueba de desarrollo Sprint Nro. 2 Módulo de registro de vacunas
registro y modificación de jeringas
Evaluación
- Ingreso de datos.
- Validaciones de fechas.
- Alertas de envió correcto de datos.
- Registro de vacunas en el registro diario.
Conforme a estos puntos el sistema no presenta falla alguna, los datos son
registrados y modificados correctamente
74
Figura 4.5 Resultado del módulo de registro de vacunas
Tabla 4.6 Prueba de desarrollo Sprint Nro. 2 Módulo de registro de salida o uso de insumos
Prueba aplicada a la Historia de Usuario 2 correspondiente al llamado proceso
registro de salida o uso de insumos
Evaluación
- Registro de la salida de jeringas
- Registro de la salida de vacunas
- Registro de insumos desperdiciados o derrochados
Los registros de los materiales salientes se realizan de forma efectiva
75
Figura 4.6 Resultado del módulo de registro de salida o uso de insumos

pruebas a los módulos que contiene el Sprint 3. En las tablas 4.7, 4.8 y 4.9 se muestran
figuras 4.7, 4.8, 4.9 y 4.10.
Tabla 4.7 Prueba de desarrollo Sprint Nro. 3 Módulo de recopilación de datos sobre prestación de
servicios
módulo de recopilación de datos sobre la producción de servicios
Evaluación
- Validación de fecha inicial y fecha final.
- Filtros aceptables a partir de la base de datos.
- Obtención de reportes PDF.
Conforme a estos puntos el sistema no presenta falla alguna, los reportes son
obtenidos satisfactoriamente según los filtros ingresados.
76
Figura 4.7 Resultado de módulo de recopilación de datos sobre prestación de servicios
Figura 4.8 Reporte generado por medio de filtros de búsqueda
77
Tabla 4.8 Prueba de desarrollo Sprint Nro. 3 Módulo de seguimiento del uso de insumos
módulo de seguimiento de uso de insumos
Evaluación
- Filtros de búsqueda por insumos
- Validaciones de fecha inicial y fecha final
- Obtención de reporte PDF.
Figura 4.9 Resultado del módulo de seguimiento de uso de insumos
Tabla 4.9 Prueba de desarrollo Sprint Nro. 3 Módulo de estadísticas de prestación de servicios
Prueba aplicada a la Historia de Usuario 2 de Sprint 4 correspondiente al módulo
de estadísticas de prestación de servicios
Evaluación
- Verificación de existencia de información
- Mensaje de información no encontrada
No se presentan fallos algunos para ingreso al sistema
78
Figura 4.10 Resultado al módulo de estadísticas
4.2.4. Prueba de Humo Sprint 4

pruebas a los módulos que contiene el Sprint 4. En las tablas 4.10 y 4.11 se muestran
figuras 4.11 y 4.12.
79
Tabla 4.10 Prueba de desarrollo Sprint Nro. 4 Módulo de registro de personal
módulo de registro de personal enfermero
Evaluación
- Registro de datos de enfermero
- Modificación de datos de enfermero
- Otorgar acceso y bloquear acceso al sistema
- Asignación de roles para restringir la operatividad del sistema
Conforme a estos puntos el sistema no presenta falla alguna los datos son
registrados y modificados correctamente.
Figura 4.11 Resultado del módulo de registro de personal enfermero
80
Tabla 4.11 Prueba de desarrollo Sprint Nro. 11 Módulo de seguridad por autenticación
Prueba aplicada a la Historia de Usuario 2 correspondiente al llamado módulo de
seguridad por autenticación
Evaluación
- Ingreso mediante Logueo por usuario y contraseña
- Mensajes de usuarios inexistentes o inactivos
Figura 4.12 Resultado del módulo de autenticación
4.2.5. Prueba de Humo Sprint 5

pruebas a los módulos que contiene el Sprint 4. En las tablas 4.12 y 4.13 se muestran
figuras 4.13 y 4.14.
81
Tabla 4.12 Prueba de desarrollo Sprint Nro. 4 Módulo de registro de materiales
módulo de registro de materiales.
Evaluación
- Registro de nuevos materiales
- Asignación de claves del material
Conforme a estos puntos el sistema no presenta falla alguna los datos son
registrados correctamente.
Figura 4.13Resultado del módulo de registro de datos de materiales
82
Tabla 4.13 Prueba de desarrollo Sprint Nro. 11 Módulo de registro de servicios
Prueba aplicada a la Historia de Usuario 2 correspondiente al llamado módulo de
registro de servicios.
Evaluación
- Registro de nuevos servicios
- Asignación de claves a los servicios
obtenidos satisfactoriamente.
Figura 4.14 Resultado de módulo de registro de nuevos servicios
83
4.3.Métricas de Calidad
El sistema final se evalúa con las siguientes métricas de calidad de la ISO 9126 que
se detalla en el capítulo II.
4.3.1. Funcionalidad
La funcionalidad del Sistema se mide a través de su complejidad, la funcionalidad no
puede ser medida directamente, entonces corresponde derivar, mediante otras medidas
directas como Punto Función, que permite un resultado medible y cuantificable a partir
de la Ecuación 2.1 se calculó la funcionalidad del sistema. Para la medición de la
funcionalidad, se toman en cuenta las siguientes características:
Tabla 4.14 Calculo de punto función
Factor de peso
Parámetros de medida Cuenta Total
Simple Medio Complejo
Número de entradas de Usuario
7 3 4 6 28
(EU)
Número de Salidas de Usuario
3 4 5 7 15
(SU)
Número de Peticiones de Usuario
3 3 4 6 12
(PU)
Número de Archivos (NA) 10 7 10 15 100
Número de Interfaces (NI) 0 5 7 10 0
Total 155
Los valores de la variable Fi, se obtiene de los resultados que se aprecian en la Tabla
4.15, bajo la siguiente ponderación:
Tabla 4.15 Valores de ajuste de complejidad

Complejidad influencia incidencial Moderado Medio Significativo Escencial
Escala 0 1 2 3 4 5
Preguntas para la variable Fi se muestra en la tabla 4.16.
84
Tabla 4.16 Ajuste de complejidad punto función
Pregunta Ponderación
¿Requiere el Software copias de seguridad y de recuperación fiables? 5
¿Se requiere comunicación de datos? 5
¿Es crítico el rendimiento? 3
¿Se ejecuta el Software en un entorno operativo existente y fuertemente
5
utilizado?
¿Requiere el Software entrada de datos interactiva? 3
¿Son complejos las entradas, las salidas, los archivos o las peticiones? 3
¿Es complejo el procesamiento interno? 3
¿Se ha diseñado el código para que sea reutilizable? 5
¿Se ha diseñado el Software para soportar múltiples instalaciones en
5
diferentes organizaciones?
¿Se a diseñado la Aplicación Web para facilitar los cambios y para ser
5
fácilmente utilizada por el usuario?
P(Fi) Total 42
Empleando la fórmula para hallar el PF y PF(Máximo):
PF = 155 ∗ [0,65 + 0,01 ∗ 42]

PF = 165,85
PF(Máximo) = 155 ∗ [0,65 + 0,01 ∗ 50]
PF(Máximo) = 178,25
Con los valores máximos de ajuste de complejidad de Punto Función, se tiene el

siguiente resultado de Funcionalidad Real:
𝑃𝐹𝐴 165,85
FUNCIONALIDAD = 𝑃𝐹𝐴 ∗ 100 = 178,25 ∗ 100
𝑚𝑎𝑥
FUNCIONALIDAD = 93,04 %
4.3.2. Usabilidad
Para calcular la usabilidad del sistema se realizó una encuesta a los involucrados (ver
anexo C) para verificar el grado de dificultad en su uso que son reflejadas en las tablas
4.13, 4.14, posteriormente se utilizó la Ecuación 2.2 para el cálculo.
Tabla 4.17 Escala de valores para la usabilidad
85
Escala Valor
Excelente 5
Bueno 4
Aceptable 3
Deficiente 2
Pésimo 1
Tabla 4.18 Preguntas para hallar la usabilidad

Nro. Pregunta Usr1 Usr2 Usr3 Prom
1 ¿El sistema es de fácil uso? 5 5 4 4,67
2 ¿Considera que los mensajes del sistema son 5 5 4 4,67
entendibles?
3 ¿Considera usted que el sistema es útil? 5 5 5 5
4 ¿Los reportes generados por el sistema son útiles para 5 4 5 4,67
usted?
5 ¿Usted encuentra funciones bastante interactivas en el 4 5 4 4,33
sistema?
6 ¿Recomendaría el uso del sistema a otras instituciones 5 4 5 4,67
similares?
7 ¿Los registros(pacientes, insumos y personal) son 5 5 4 4,67
eficientes y seguros?
8 ¿Las estadísticas mostradas son de ayuda para su 4 5 4 4,33
trabajo?
9 ¿La generación de resultados ayuda al proceso de toma 4 5 4 4,33
de decisiones?
10 ¿El sistema llego a cumplir todas sus expectativas? 5 5 5 5
Total 46,34
Calculamos la facilidad de uso, tomando en cuenta que el Nro. de preguntas son 10 y

los involucrados 3.
FU = [(∑ xi/n) *100]/N = [(46,34/10) *100]/5 = 92,68
La Usabilidad de Uso del sistema es de 92,68%.
4.3.3. Mantenimiento
Utilizando la Ecuación 2.3 podemos calcular la mantenibilidad del sistema.
IMS = [Mt – (Fa + Fc + Fd)]/Mt
86
Dónde:
 Mt: es el número de módulos de la versión actual.
 Fc: es el número de módulos que se han cambiado.
 Fa: es el número de módulos en la versión actual que se han añadido.
 Fd: es el número de módulos que se han borrado en la versión actual.
Donde los valores del sistema son reflejados en la Tabla 4.16.
Tabla 4.19 Valores para calcular mantenimiento
Nro. Módulos Fc Fa Fd
1 Módulo de registro de pacientes 0 0 0
2 Módulo de registro de atención 0 0 0
3 Módulo de seguimiento de consultas de pacientes 1 0 0
4 Módulo de registro de jeringas 0 0 0
5 Módulo de registro de vacunas 0 0 0
6 Módulo de registro de salida o uso de insumos 1 0 0
7 Módulo de recopilación de datos sobre prestación de 0 0 0
servicios
8 Módulo de uso de seguimiento de insumos 1 0 0
9 Módulo de estadísticas de prestación de servicios 0 1 0
10 Módulo de registro de personal Enfermero 0 0 0
11 Módulo de seguridad por autenticación 0 0 0
12 Módulo de registro de materiales 0 0 0
13 Módulo registro de servicios 0 0 0
3 0 0
Mt = 13, Fc = 3, Fa = 1, Fd = 0
Por lo tanto, el resultado IMS es:
IMS = [13-(3+0+1)]/13= 9/13 = 0.69
Por lo tanto, el mantenimiento del sistema es de un 69 %.
87
4.3.4. Portabilidad
El sistema de fue desarrollado en un entorno multiplataforma, de manera que el sistema
funciona en cualquier tipo de plataforma (Windows, Linux, MacOS, Android, etc.),
además que su adaptabilidad a cualquier resolución de pantalla es que hace al sistema
portable y accesible desde cualquier dispositivo o equipo de cómputo.
Además, el sistema cuenta con una aplicación móvil diseñada para un entorno en donde
no se tenga acceso a internet y dicha aplicación puede ser instalada en versiones
Android actuales.
4.4.Aplicación ISO 27001

Las medidas de seguridad necesarias que debe contar el sistema son la encriptación y
uso de variables de sesión. La encriptación de datos nos ayuda a encriptar datos como
ser contraseñas, parámetros enviados por método GET en PHP, así también las
variables de sesión colaboran en el acceso restringido a un sistema, es decir el usuario
debe contar con un usuario y contraseña y a partir de ello es que a través de una
verificación existente del usuario se crea una variable de sesión y finalizada las tareas
correspondientes al final se destruye las variables de sesión creadas por el sistema.
4.4.1. Encriptación
Varios módulos del sistema cuentan con envío de datos a otra página a través del
parámetro GET, propio de PHP, es así que la necesidad de reservar la información que
viaja a través del link de la página, para ello se utilizó la función “base64_encode” para
ocultar la información y “base64_decode” para des encriptar la información en el
momento en que llega a la página destino. (vea figura 4.1 donde se muestra el algoritmo
utilizado para encriptación y des encriptación)
4.4.2. Autenticación y autorización

A través de la autenticación mediante un usuario y contraseña para acceder al sistema
es que se utilizan las variables de sesión, estas son creadas e iniciadas en cuanto el
sistema verifique que el usuario y contraseña coincidan, además este usuario no este
88
dado de baja. (Vea la Figura 4.2 para ver la estructura con el cual se verifica que el
usuario existe y está habilitado para acceder al sistema)
Figura 4.15 Algoritmo de encriptación utilizado
Figura 4.16 Creación de variables de sesión a partir de acceso al sistema mediante usuarios
89
Capítulo 5
Conclusiones y Recomendaciones
5.1. Conclusiones
El desarrollo del Sistema de Gestión de Información Clínica para el consultorio de la
carrera de Enfermería de la Facultad de Medicina, Enfermería, Nutrición y Tecnología
Médica fue exitoso, lográndose alcanzar los objetivos.
 El desarrollo y la implementación del sistema de gestión de información clínica

para el consultorio de enfermería aporto de gran manera en las diversas
actividades que se llevan a cabo en el consultorio, logrando así una atención
más eficiente.
 La información deseada para poder diseñar, estructurar y desarrollar el Sistema
de Información Clínica fue obtenida por medio de cuestionarios y
observaciones en el funcionamiento.
 El tiempo de búsqueda de la información anterior para aplicación de las

siguientes dosis correspondientes tenía una demora entre 20 a 40 minutos, pero
con el módulo de seguimiento del paciente pudo optimizar el tiempo de la
búsqueda a menos de 10 segundos, logrando así una mejor y rápida atención,
 En la elaboración de informes o reportes de prestación de servicios existía

mucha pérdida de tiempo, ya que al realizar el conteo manual de cada servicio
ofrecido para la elaboración de dicho informe tenía una tardanza hasta 2 días,
así pues, con el sistema de gestión de información clínica el tiempo se redujo a
menos de 5 segundos, esto gracias a que el sistema puede generar reportes.
 Los registros de atención de pacientes contenían información duplicada ya que

cada vez que el paciente acudía al servicio se lo registraba nuevamente
generando así duplicidad de información, pero con el sistema solo se requiere
registrar una sola vez al paciente y para posteriores visitas al consultorio solo
se realiza la búsqueda de la información del paciente y se procede a la atención.
90
 Los módulos propuestos fueron desarrollados, aplicando pruebas de desarrollo
y pruebas finales con el usuario final.
 La norma de calidad ISO 9126 fue aplicada dando como resultados favorables
en la parte de funcionalidad, usabilidad y mantenimiento. Para la parte de
funcionalidad a través del cálculo de punto función se obtuvo como resultado
93,04% que el sistema es de funcional, la usabilidad obtuvo como resultado un
92,68% que refiere a que el sistema es amigable y finalmente la mantenibilidad
obtuvo un 69% ya que futuros cambios o inclusiones de nuevos módulos
pueden ser agregados o modificados.
De esta manera, se ha logrado alcanzar el objetivo general de desarrollar e implementar

un sistema de gestión de información clínica, como también se abarcaron los objetivos
específicos gracias a los módulos propuestos y desarrollados, el cual permite gestionar
las tareas que se llevan a cabo en el consultorio de Enfermería. Esto se pudo lograr
mediante la ejecución de las fases propuestas por la metodología SCRUM.
5.2. Recomendaciones
Realizar evaluaciones periódicas de la información generada por el sistema, esto con
el fin de identificar nuevas necesidades para futuros cambios.
Una vez que el personal concluya sus labores en el consultorio de Enfermería se

recomienda deshabilitar al usuario para que ya no pueda realizar modificación alguna
en la información registrada.
Realizar un backup anual de los datos almacenados en la gestión de trabajo, para poder
respaldar la información o poder migrar a otra base de datos.
La mantenibilidad del sistema puede realizarse solo en algunos componentes como ser:
reportes, estadísticas, servicios y materiales, ya que los demás componentes son
inalterables ya que la información que maneja es relacionada una con la otra.
91
REFERENCIAS BIBLIOGRAFICAS
Administrador. (30 de enero de 2016). Testing Colombia. Obtenido de
http://www.testingcolombia.com/pruebas-de-humo-su-aplicacion-al-flujo-de-un-
producto-financiero/
Alicante. (2017). Servicio de Informatica. Obtenido de Servicio de Informatica:

https://si.ua.es/es/documentacion/asp-net-mvc-3/1-dia/modelo-vista-controlador-
mvc.html
Astros, I. J. (1 de Diciembre de 2017). Evaluación de proyectos por medio del analisis costo -
beneficio. Obtenido de Evaluación de proyectos por medio del analisis costo -
beneficio: http://www.monografias.com/trabajos99/evaluacion-proyectos-analisis-
costo-beneficio/evaluacion-proyectos-analisis-costo-beneficio.shtml
Bara, M. (2016). BusinessSchool. Obtenido de BusinessSchool: https://www.obs-

edu.com/int/blog-investigacion/project-management/las-5-etapas-en-los-sprints-
de-un-desarrollo-scrum
Boehm, B. (1981). Software Engineering Economics. New Jersey: Prentice Hall.
Boehm, B. W. (2017). Center for Systems and Software Engineering. Obtenido de Center for
Systems and Software Engineering:
http://csse.usc.edu/csse/research/COCOMOII/cocomo_main.html#downloads
Camacho, A. (2005). HERRAMIENTA PARA EL ANÁLISIS DE REQUERIMIENTOS. Bogota D.C.:

CARRERA DE INGENIERÍA DE SISTEMAS.
Carrera Enfermería, U. (2017). Dimensioin 1 Contxeto Institucional. En C. E. UMSA. La Paz.
Centellas Coarite, M. (2015). Sistema de control y gestión de historiales clínicos apoyado en

dispositivos móviles Caso: Centro Medico La Paz. la paz: Carrera de Informática.
Culturacion, W. (2011). culturacion. Obtenido de culturacion: http://culturacion.com/cual-

es-la-utilidad-de-las-aplicaciones-clienteservidor/
Diaz, I. (12 de abril de 2014). Ser Programador. Obtenido de Ser Programador:

https://serprogramador.es/que-es-frontend-y-backend-en-la-programacion-web/
Digital, R. (agosto de 2013). En red digital. Obtenido de En red digital:

http://www.serviciosenreddigital.com/ciclo-de-vida-del-scrum/
Drake, J. (2008). Proceso de desarrollo de. Santander: Computadores y Tiempo Real.
92
Econectia, W. (17 de agosto de 2017). Econectia.com. Obtenido de
https://www.imaginanet.com/blog/seguridad-en-php-basica-escribiendo-
aplicaciones-web-seguras.html
Espacio, P. (Julio de 2004). Hosting. EspacioPyme, 6.
Gcfa, A. (2016). GCFApredelibre. Obtenido de GCFApredelibre:

https://www.gcfaprendelibre.org/tecnologia/curso/informatica_basica/todo_acerc
a_de_las_aplicaciones_o_programas/3.do
Gralneg, U. (2004). Arquitectura cliente servidor. En gralneg64.
Gutiérrez, P. (05 de 11 de 2013). Fundamentos de base de datos. Obtenido de

GENBETA:Dev: https://www.genbetadev.com/bases-de-datos/fundamento-de-las-
bases-de-datos-modelo-entidad-relacion
Huanca Cantuta, S. P. (2015). Sistema web de control de pagos, citas e historiales clínicos. la
paz: Carrera de Informática.
IBM, C. (2015). IBM. Obtenido de IBM:

https://www.ibm.com/support/knowledgecenter/es/SS9UM9_9.1.0/com.ibm.datat
ools.core.ui.doc/topics/cphysmod.html
IdeasWow, W. (2017). SIMEDIC- SISTEMA INTEGRAL MÉDICO. Obtenido de SIMEDIC-

SISTEMA INTEGRAL MÉDICO: https://simedic.clinic/
Imaginanet, W. (31 de marzo de 2010). imaginanet.com. Obtenido de

https://www.imaginanet.com/blog/seguridad-en-php-basica-escribiendo-
aplicaciones-web-seguras.html
Informatica, D. (2009). Estándares para el Uso de Herramientas de Desarrollo y Plataformas

de Aplicaciones Web. Peru: Secretaría de Planificación Estratégica.
ISO, 2. (5 de noviembre de 2014). ISOTools. Obtenido de

https://www.isotools.org/2014/11/05/iso-27001-medios-aplicados-seguridad-
informacion/
Israel. (27 de marzo de 2017). CCM. Obtenido de CCM: https://es.ccm.net/contents/304-

lenguajes-de-programacion
Josep, C. (09 de 09 de 2004). Acerca de nosotros: Desarrollo web. Obtenido de Desarrollo

web : https://desarrolloweb.com/articulos/1622.php
Laudon, & Laudon. (2012). management information systems. E.E.U.U: Pearson.
93
Llopis, F. (06 de 10 de 2016). Scrum. Historias de Usuario. Obtenido de Scrum. Historias de
Usuario: http://fernandollopis.dlsi.ua.es/?p=39
Llorente, M. (2017). Matemáticas financieras. Madrid: Dpto. de analisis económico:

Econimía cuantitativa.
LoginDesarrollos, W. (2018). Login desarrollos. Obtenido de Login desarrollos:

https://logindesarrollos.com/es/Servicios-aplicaciones-web-21
Lozano, L. (2013). Estandares calidad software. Obtenido de Estandares calidad software:

http://estandarescalidadsoftware.blogspot.com/
Lozano, L. A. (13 de septiembre de 2013). ESTÁNDARES DE CALIDAD DEL SOFTWARE.

Obtenido de ESTÁNDARES DE CALIDAD DEL SOFTWARE:
http://estandarescalidadsoftware.blogspot.com/
Madachy, R. (2017). COCOMO II - Constructive Cost Model. Obtenido de COCOMO II -

Constructive Cost Model: http://csse.usc.edu/tools/COCOMOII.php
Mariátegui. (1 de Diciembre de 2017). Biblioteca Virtual Universidad José Carlos. Obtenido

de Indicadores de Rentabilidad.: bv.ujcm.edu.pe/links/cur_general/IngEconomica-
5.pdf
Martinez, K., & Marielos, A. (1 de Diciembre de 2017). Contabilidad Financiera II. Obtenido
de Contabilidad Financiera II:
https://portafoliovirtual2.wikispaces.com/Krissia+Marielos+Acosta+Martinez
Neira, A. (2010). Tecnicas de Modelado de Software . Obtenido de Tecnicas de Modelado de

Software : http://modeladouniminuto.blogspot.com/p/diagramas-uml.html
Oberg, R., Probasco, L., & Ericsson, M. (2003). Applying requirements management with use
cases. Rational Software.
OpenEMR, W. (2014). OpenEMR. Obtenido de OpenEMR: http://www.open-emr.org/
Pastrana, O. (2014). i2btech. Obtenido de i2btech: http://www.i2btech.com/blog-i2b/tech-

deployment/5-beneficios-de-aplicar-metodologias-agiles-en-el-desarrollo-de-
software/
Peralta, A. (2003). Metodología SCRUM. Uruguay: Universidad ORT.
Pérez Porto, J., & Gardey, A. (2008). Definicion.de. Obtenido de Definicion.de:

https://definicion.de/sistema-de-informacion/
94
Perez, J. (5 de junio de 2007). Maestros del web. Obtenido de Maestros del web:
http://www.maestrosdelweb.com/herramientas-adecuadas-para-el-diseno-y-
desarrollo-de-un-sitio-web/
ProyectosAgiles, W. (2018). proyectosagiles.org. Obtenido de proyectosagiles.org:

https://proyectosagiles.org/que-es-scrum/
Repositorios, U. (09 de noviembre de 2017). Repositorio Institucional UMSA. Obtenido de

Repositorio Institucional UMSA: http://repositorio.umsa.bo
Rodriguez, M. L. (7 de marzo de 2012). INTRODUCCIÓN GENERAL A LA METODOLOGÍA DE LA

INVESTIGACIÓN. Obtenido de
https://metodologiasdelainvestigacion.wordpress.com/2012/03/07/introduccion-
general-a-la-metodologia-de-la-investigacion/
Rosmery, L. F. (2014). Sistema de Administración y Control de Historiales Clínicos para los

Consultorios Clínicos de la UMSA. la paz: Carrera de Informática.
Seguridad, G. d. (6 de 10 de 2014). SGSI. Obtenido de https://www.pmg-

ssi.com/2014/10/iso-27001-acceso-sistemas-informacion/
Shirley. (4 de mayo de 2012). INGENIERIA DE SISTEMAS. Obtenido de INGENIERIA DE

SISTEMAS: http://ingenieriadesistemas-shirley.blogspot.com/2012/05/tecnicas-de-
recoleccion-de-datos.html
Thayer, R., & Dorfam, M. (2000). Software Requirements Engineering. Los alamitos,
california: IEEE Computer Science Press.
Valdéz, J. L. (s.f.). EUMED. Obtenido de EUMED: http://www.eumed.net/tesis-

doctorales/2014/jlcv/software.htm
Wikipedia, W. (2017). Wikipedia. Obtenido de Wikipedia:

https://es.wikipedia.org/wiki/Aplicaci%C3%B3n_web
95
ANEXOS
96
ANEXO A. Cuestionario de indagación de información
97
98
ANEXO B. Estudio de costos.
Calculo de costos
Para el cálculo del costo estimado del software desarrollado, se utilizó la herramienta
“COCOMO II - Constructive Cost Model” que pertenece al Centro de Sistemas e
Ingeniería de software de la Universidad de California del Sur. Por ello se eligió la
opción de estimar el precio total por líneas de código, y se llenó los datos que requiere
el servicio con información obtenida del código fuente de la aplicación móvil.
Además de la información de líneas de código el modelo requiere varias características

como la flexibilidad de desarrollo, la arquitectura, el trabajo de equipo, tamaño de la
base de datos, complejidad del producto, capacidad del personal, la limitación de
tiempo, la restricción de almacenamiento, el uso de herramientas de software, etc.
Figura 1.4 Ingreso de datos en el sistema COCOMO II
99
Fuente: (Madachy, 2017)
Luego de llenar la información requerida por el sistema de estimación de costos

COCOMO II se procedió a calcular y ver los resultados que proporciona la herramienta,
ver Figura 1.5.
Figura 1.5 Resultados estimación de costos COCOMO II

Fuente: (Madachy, 2017)
Los resultados que nos proporciona la herramienta son datos importantes, como el
esfuerzo que es 19.2 personas-mes, el tiempo estimado de desarrollo es 12.7 meses, la
100
cantidad de personas promedio para desarrollar el proyecto es 2 y el costo final fue de
$us. 960,00
Además del costo total del desarrollo que proporciona el modelo COCOMO II, se
debería tomar en cuenta más factores como ser el material de escritorio, internet,
mantenimiento, etc. Dichos factores fueron proporcionados por la institución así que
no fue necesario hacer cálculos adicionales.
Por lo tanto, se concluye que el costo total para desarrollar el sistema de información
clínica del consultorio de la Carrera de Enfermería, alcanza aproximadamente a $us.
960,00, que convertidos en moneda nacional son: Bs. 6,605.42
Beneficio
VAN
Se calculó el VAN con los siguientes datos:
𝐴 = 6,605.42, 𝑘 = 5%, 𝑛 = 7, flujo inicial de caja de Bs. 1.000 y los flujos que se
muestran en la siguiente Tabla 1.2:
Periodo Año Gastos (Bs.) Beneficios (Bs.) Flujo de caja

(Bs.)
1 2018 3.500 10.000 6.500
2 2019 2.500 9.500 7.000
3 2020 3.700 8.700 5.000
4 2021 3.100 9.800 6.700
5 2022 4.800 10.500 5.700
6 2023 3.200 8.300 5.100
7 2024 4.400 11.000 6.600
Total 25.200 67.800 42.600
Tabla 1.2: Flujo de caja por años
Fuente: Elaboración propia
101
6500 7000 5000 6700
𝑉𝐴𝑁 = −30854.01 + + + +
(1 + 0.1)1 (1 + 0.1)2 (1 + 0.1)3 (1 + 0.1)4
5700 5100 6600
+ 5
+ 6
+
(1 + 0.1) (1 + 0.1) (1 + 0.1)7
VAN = 28.727,85
Como resultado de los datos se tiene que el VAN es 28.727,85, notemos que el
resultado es mayor a cero, por lo tanto, el proyecto es aceptable.
TIR
Aplicando los datos: 𝐴 = 6,605.42, 𝑛 = 7 y los flujos de caja que se muestran en la tabla
anterior se aplican en la fórmula de la 𝑇𝐼𝑅, de la cual se obtiene el siguiente resultado:
87%.
Analizando el resultado que es mayor a 0, concluimos que el proyecto es factible para

su desarrollo.
Costo – Beneficio
𝑇𝑜𝑡𝑎𝑙 𝐵𝑒𝑛𝑒𝑓𝑖𝑐𝑖𝑜𝑠 67.800

𝐶𝑜𝑠𝑡𝑜 𝐵𝑒𝑛𝑒𝑓𝑖𝑐𝑖𝑜 = =
𝑇𝑜𝑡𝑎𝑙 𝐺𝑎𝑠𝑡𝑜𝑠 25.200
Coso Beneficio = 2,69
Del resultado obtenido se concluye que la ganancia por cada boliviano invertido es Bs.
2,69 lo cual indica que el proyecto es viable.
102
ANEXO C. Cuestionario de evaluación de usabilidad.
103
104
105
ANEXO D. Manual de Usuario Supervisor.

FACULTAD DE MEDICINA, ENFERMERÍA,
NUTRICIÓN Y TECNOLOGÍA MÉDICA
CARRERA DE ENFERMERÍA
MANUAL DE USUARIO
DEL SISTEMA DE GESTIÓN
DE INFORMACIÓN
CLÍNICA
Elaborado por : Jorge Abimael Lara Ticona
Fecha de Elaboración : 8 de junio de 2018
Versión : 1.0
Propiedad : Consultorio de carrera de Enfermería
Usuarios : Supervisor, Administrador, auxiliar
106
1. BIENVENIDA
Para la Carrera de Enfermería es muy importante darle la bienvenida, ya que usted

encontrara el apoyo y colaboración conocer acerca de las funciones que usted va a
desempeñar dentro el entorno.
Este manual busca proporcionar información general acerca de todas la funciones,

propósitos y alcances que cuenta el Sistema de Gestión de Información Clínica,
también podrá reflejar las principales características que cuenta el sistema de
información.
La operatividad que vaya a tener con el sistema le brindará un mayor desarrollo

personal y profesional. Sabemos que contamos con su dinamismo, interés y
colaboración, para hacer del Consultorio de Enfermería un ejemplo de eficiencia y
calidad.
1.1.¿QUÉ ES EL SISTEMA DE GESTÓN DE INFORMACIÓN CLÍNICA?
El consultorio de la Carrera de Enfermería es propio de la Universidad Mayor de San

Andrés perteneciente a la Carrera de Enfermería de la facultad de Medicina,
Enfermería, Nutrición y Tecnología Médica, cumple funciones de atención médica a la
población en general desde aproximadamente la gestión 2010.
El Sistema de Gestión de Información Clínica de la carrera de Enfermería fue

desarrollado con el propósito de poder agilizar el proceso de atención, además de
brindar al operador la facilidad de tener información al alcance.
1.2.PROPÓSITO
El propósito de este manual es mostrar a los usuarios operadores del sistema mostrar
las funciones con el que cuenta el software, además de explicar con detalle sobre cómo
debe utilizarse registrarse los datos de personal, pacientes, material de trabajo(insumos)
y algunos datos adicionales.
107
1.3.ALCANCE
El alcance de este manual de usuario se extiende a todas las páginas que contienen
dicho sistema, así mismo se abarcara la funcionalidad, validaciones y registros de las
mismas
1.4.REQUERIMIENTOS PARA EL SISTEMA
El desarrollo de esta aplicación está basado en un entorno Web ya que para la

implementación de dicho sistema no se requieren de muchos componentes para su
uso, para lo cual el equipo de computación donde vaya a ser utilizado debe contar con
los siguientes requerimientos mínimos tanto en software como en hardware.
1.4.1. CARACTERISTICAS DE SOFTWARE
El sistema de información necesariamente debe contar con los siguientes programas

instalados:
- Sistema Operativo Windows 7, Windows 8 o Windows 10

- Navegador Web (Google Chrome, Firefox, Safari, etc.) preferentemente
Firefox
- Lector de archivos PDF (Adobe Reader, Nitro PDF, Solid PDF)
- Además, necesariamente debe contar con un acceso a la red de la facultad o
acceso a internet.
1.4.2. CARACTERISTICAS DE HARDWARE
El sistema de información debe contar con un equipo de computación con las

siguientes características:
- Procesador Dual Core, Core i3, Core i5, Core i7

- RAM 4GB para buen funcionamiento de otros procesos del computador
- Impresora (cualquiera con conexión USB)
- Tarjeta de red para acceso a internet
- Punto de red instalado en el ambiente
108
USUARIO
SUPERVISOR
109
2. MANUAL DE USUARIO PARA SUPERVISOR PARA LA
ADMINISTRACIÓN DEL PERSONAL
El personal administrador del Consultorio de Enfermería es designado según el

administrador del sitio Web, el mismo debe ocuparse de gestionar los servicios que
brinda el consultorio. Para la administración del Sistema de Gestión de Información
Clínica, el director(a) debe realizar los siguientes pasos descritos a continuación:
2.1.INGRESO A LA PLATAFORMA WEB
Usted con un usuario asignado como director(a) debe ingresar al sitio:
http://200.7.173.101/consultorio
2.2.INICIAR SESIÓN COMO ADMINISTRADOR
Usted debe tener asignado un usuario y contraseña por el administrador del sitio,
seguidamente debe ingresar su usuario y contraseña en la ventana LOGIN e iniciar
sesión figura 1.
Figura 1. Ventana LOGIN para acceso al sistema
2.3.NAVEGAR POR EL MENÚ PRINCIPAL
Luego que usted ingrese al sistema puede visualizar los módulos y operar con cada uno
de ellos para sus fines laborales (ver figura 2).
110
Figura 2. Página principal contenedora de los módulos del sistema
2.3.1. MÓDULO DE PERSONAL ENFERMERO
Este módulo ofrece la posibilidad de agregar nuevos usuarios o también habilitar o

deshabilitar el acceso al sistema a usuarios en específico (ver figura 3).
111
Figura 3. Lista de personal registrado
2.3.2. MÓDULO DE REGISTRO DE NUEVO MATERIAL DE TRABAJO
Este módulo es muy importante porque para poder registrar nuevos ingresos de
insumos, el nombre del insumo debe estar registrado en el banco de insumos de la base
de datos, para así poder desplegar estos materiales al momento de registrar nuevos
ingresos de insumos (ver figuras 4 y 5 ejemplo para registrar nuevos servicios).
Figura 4. Registro de nuevos servicios
112
Figura 5. Registro de servicios
2.3.3. MÓDULO DE REGISTRO NUEVO DE SERVICIOS
Esta modulo necesariamente se deben registrarse nuevos servicios para poder

aplicarlos en el proceso de atención, es muy importante colocar una palabra clave al
servicio, esto para que el sistema pueda identificar y diferenciar de los demás
servicios (ver figuras 6 y 7 para ver ejemplo de agregar materiales).
Figura 6. Agregar nuevos materiales
113
Figura 7. Lista de materiales
114
USUARIO
ADMINISTRADOR
O AUXILIAR
115
3. ADMINISTRACIÓN DE PACIENTES
El personal administrador del Consultorio de Enfermería es designado según el

Director(a) de carrera, el mismo debe ocuparse de gestionar los servicios que brinda
el consultorio. Para la administración del Sistema de Gestión de Información Clínica,
el director(a) debe realizar los siguientes pasos descritos a continuación:
3.1.INGRESO A LA PLATAFORMA WEB
Usted con un usuario asignado como director(a) debe ingresar al sitio:
http://200.7.173.101/consultorio
3.2.INICIAR SESIÓN COMO ADMINISTRADOR
Usted debe tener asignado un usuario y contraseña por el director(a) o supervisor(a),

seguidamente debe ingresar su usuario y contraseña en la ventana LOGIN como se
muestra la figura 8, luego iniciar sesión.
Figura 8. Ventana LOGIN para acceso al sistema
3.3.NAVEGAR POR EL MENÚ PRINCIPAL
Luego que usted ingrese al sistema puede visualizar los módulos y operar con cada uno
de ellos para sus fines laborales (ver figura 9).
116
Figura 9. Página principal contenedora de los módulos del sistema
3.3.1. MÓDULO DE PACIENTE REGISTRADOS
Este módulo permite realizar el registro, modificación, búsqueda y descripción de

información del paciente, también se puede realizar el proceso de atención una vez que
el paciente haya sido registrado. Para ello las funciones con las que cuenta dicho
modulo son descritas a continuación.
117
3.3.1.1.BÚSQUEDA DE PACIENTE
Usted puede realizar la búsqueda ingresando el número de carnet o el nombre del

paciente en el campo búsqueda y automáticamente le devolverá la información
deseada (ver Figura 10) o simplemente en la lista general buscar al paciente
Figura 10. Informacion de pacientes
3.3.1.2.REGISTRO O MODIFICACION DE DATOS DE PACIENTE
Para poder registrar o modificar la informacion del paciente usted debe considerar las
siguientes validaciones de informacion por parte del sistema.
- Debe ingresar en los campos nombres, apellido paterno, apellido materno solo
texto sin tildes ni numero
- La fechas de nacimiento no puede ser posteriores a la fecha actual
- El numero de carnet debe ser mayor a 5 digitos necesariamente
Caso contrario el sistema le hara notar lo errores que esta cometiendo al

registrar.(Vease forma correcta de ingresar informacion figura 11)
118
Figura 11. Registro o modificacion de datos de paciente
3.3.3.3.ATENCION DEL PACIENTE
Una vez registrado o encontrado la informacion del paciente usted debe proceder a la
atencino del mismo ya sea Proceso enfermero o aplicar una vacunacion como se
muestra en la figura 10.
Luego debe llenar el formulario seleccionando las opciones como se muestra en la

figura 12, luego puede guardar la informacion que se almacenara en los registros de la
base de datos.
Figura 12. Proceso de atencion
119
3.3.3.4.HISTORIAL DE ATENCIONES POR PACIENTE
Usted puede ver los registros de conulta del paciente como se muestra en la figura 13
usted puede visualizar las atenciones que el paciente tuvo en el consultorio.
Figura 13. Historial de paciente
3.3.4. MÓDULO DE ESTADO DE INSUMOS
Este módulo nos permite tener información acerca del ingreso de insumos (ver figura
14), también pueden registrarse nuevos ingresos dependiendo del tipo de insumo que
sea para lo cual el modulo cuenta con dos botones específicos para agregar vacunas o
agregar jeringas (ver figura 15).
Para poder realizar el registro de un nuevo ingreso de insumo debe tomar en cuanta la
siguiente validaciones que tiene el sistema:
- Fecha de ingreso no debe ser posterior a la fecha actual
- Fecha de expiracion debe ser posterior a la fecha actual
120
Figura 14. Estado de insumos
Figura 15. Registro nuevo en ingreso de vacunas
3.3.5. MÓDULO DE REPORTES DE SERVICIOS E INSUMOS
Usted debe seleccionar los filtros para poder generar el reporte ya sea producción de
servicios y estado de insumos como se muestra en la figura 16. A partir de los filtros
seleccionados el sistema generara los reportes correspondientes como se muestra en la
figura 17.
121
Figura 16. Filtros para generar reporte
Figura 17. Ejemplo de reporte de produccion de servicios
3.3.6. MÓDULO DE ESTADÍSTICAS DE ATENCIONES
Este módulo nos permite visualizar de manera gráfica las cantidades de atenciones
registradas ya sea por meses o por gestiones (ver figura 18 para un ejemplo).
122
Figura 18. Estadísticas del servicio
123

Tesis Referencia

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Tesis Referencia

Încărcat de

Drepturi de autor:

Formate disponibile

UNIVERSIDAD MAYOR DE SAN ANDRÉS

FACULTAD DE CIENCIAS PURAS Y NATURALES

“SISTEMA DE GESTIÓN DE INFORMACIÓN

POSTULANTE: JORGE ABIMAEL LARA TICONA

LA CARRERA DE INFORMÁTICA DE LA FACULTAD DE CIENCIAS PURAS Y

El usuario está autorizado a:

a) visualizar el documento mediante el uso de un ordenador o dispositivo móvil.

El usuario no puede publicar, distribuir o realizar emisión o exhibición alguna de este

TODOS LOS DERECHOS RESERVADOS. EL USO NO AUTORIZADO DE LOS

A la Directora de la carrera de Enfermería M. Sc. María Eugenia Mendoza Fernández,

Al Lic. Florencio Antonio Mamani por haberme brindado la oportunidad de adquirir

Y por último a todos mis amigos de la universidad y compañeros de trabajo por

El presente proyecto de grado titulado “Sistema de Gestión de Información Clínica

En la actualidad los sistemas de información en el área de la salud se convirtieron en

Por la necesidad de informatizar y automatizar las tareas del consultorio de enfermería

El sistema de Gestión de Información Clínica, posee los siguientes módulos: Atención

Palabras clave: sistema, desarrollo de software, metodología ágil, calidad de software,

Keywords: system, software development, agile methodology, software quality,

Figura 1.1 Estructura orgánica carrera de Enfermería .............................................................. 3

Tabla 1.1 Características de hardware y software de equipo de computación del consultorio 11

Ecuación 2.1 formula para el cálculo de la funcionalidad ...................................................... 43

Figura 1.1 Estructura orgánica carrera de Enfermería

La Carrera de Enfermería de manera exclusiva cuenta con los siguientes predios:

El Vacunatorio nació como iniciativa docente – estudiantil en la Asignatura de Salud

A través de la implementación del Vacunatorio se ha realizado el aporte al Programa

El P. A. I. fue organizado oficialmente en Bolivia en octubre de 1979, a partir de

Al respecto es preciso destacar los objetivos del Programa Ampliado de Inmunización,

Entre los objetivos específicos están:

 Alcanzar y mantener coberturas de vacunación mayores a 95% por municipio

 Asegurar la disponibilidad de todas las vacunas de este esquema para garantizar

 Asegurar la correcta conservación, almacenamiento y transporte de las vacunas

 Asegurar la eficiencia de la vigilancia epidemiológica de las enfermedades

 Asegurar un sistema de seguimiento, monitoreo, evaluación de los procesos de

 Desarrollar, aplicar herramientas de trabajo comunitario y de negociación para

 Mantener la erradicación de la poliomielitis.

 Mantener la eliminación del sarampión, rubeola y síndrome de rubeola

 Controlar el tétanos neonatal, difteria, tosferina, hepatitis B, fiebre amarilla,

Es por cuanto que en el transcurso de los nueve años de implementación del

1.2.3. Proyectos Análogos

 OpenEMR (Sistema de Código abierto), Realiza la atención a clientes en

1.3. Descripción del problema

El personal encargado de la atención del consultorio es administrado por una persona

El servicio cuenta con varias planillas, formularios y cuadernos de registro de pacientes

 Cuaderno de registro de pacientes, son formularios donde se registra la

 Formularios de atención de pacientes, es un formulario de registro de las

 Kardex de biológicos, es un registro general de los materiales de trabajo usado,

 Informe Mensual de Producción de Servicios, es el registro mensual y general

Figura 1.2 Formulario de registro de pacientes

1.3.2. Planteamiento del problema

El consultorio es supervisado por el director(a) de carrera, es atendido y administrado

1.4.2. Objetivos Específicos

a) Recolectar información a través de la ingeniería de requerimientos, el cual

c) Determinar el proceso realizado en la atención, para desarrollar un módulo de

d) Analizar el proceso de registros de ingreso y salida de insumos para desarrollar

f) Implementar un módulo estadístico gráfico, que genere datos acerca de los

g) Desarrollar el sistema bajo la norma de calidad ISO/IEC 9126 y la norma de

Tabla 1.1 Características de hardware y software de equipo de computación del consultorio

En el consultorio de Enfermería se cuenta con puntos de red instalados para el acceso

1.5.2. Justificación Económica

1.6. Límites y/o Alcances

 La funcionalidad de sistema dependerá necesariamente de un hosting funcional

 Podrá ser utilizado desde cualquier dispositivo ya sea computadora de escritorio

 El acceso al sistema estará restringido solo por un usuario administrador que