Universidad Peruana de Integración Global: Facultad de Ingeniería de Sistemas E Informática

UNIVERSIDAD PERUANA DE INTEGRACIÓN GLOBAL
FACULTAD DE INGENIERÍA DE SISTEMAS E INFORMÁTICA
PROYECTO DE TESIS
Desarrollo de un Sistema de control de Historia Clínicas y su

mejoramiento en la ubicación y minimización de duplicidad
documentaria en el área de admisión del Centro Médico Municipal
de Mala – 2015.
PARA OPTAR EL TÍTULO PROFESIONAL DE INGENIERO DE

SISTEMAS E INFORMÁTICA
AUTOR: CHUMPITAZ AVALOS, Victor Manuel
ASESOR: MBA ING. CARLOS ZORRILLA VARGAS
LIMA - PERU
2015
Santiago de Surco
DEDICATORIA
Al Divino hacedor por darnos la vida, a mis padres,

por ser la motivación de seguir adelante, a mi
esposa e hijo por comprenderme en el logro de mis
objetivos.
AGRADECIMIENTO
A Dios: Por darnos la luz de la vida y la salud. A la Universidad Peruana de Integración

Global: Por permitirnos mejorar y profundizar la luz de nuestro conocimiento. Al Asesor
MBA Ing. Carlos Zorrilla Vargas: por su dedicación y apoyo incondicional para mejorar la
investigación.
RESUMEN
La investigación se realizó planteando como problema general la Ineficiencia del control de

Historias Clínicas del Centro Médico Municipal de Mala, con lo investigado se pretende crear e
implantar un sistema automatizado que permita controlar y administrar las Historias clínicas de
los pacientes, logrando optimizar el proceso de Búsqueda, minimización de Duplicidad de
Historias clínicas, atención de Pacientes y así mejorar la calidad del servicio.
Esta automatización permite tener información más precisa a la hora de generar reportes; estos
retos se alinean estratégicamente al logro de esta misión, si bien es cierto no se implementan
todos los módulos pertenecientes al Centro Médico Municipal.
Este proyecto abarca la etapa de Análisis Diseño e implementación del sistema, y se utiliza la
metodología RUP en combinación con la Notación UML, se diagraman los casos de uso del
negocio, los Casos de Uso de Sistema, Secuencia, Diagrama de Clase, y los prototipos de la
aplicación la cual va a contener las pantallas.
El sistema que se implementa se desarrolla en el Lenguaje de Programación Visual Basic 6.0 y

la Base de Datos que se utilizará es SQL server. Esto permitirá el registro de las Historias Clínicas,
y la eficiencia con que se administrará toda la información del Centro Médico Municipal.
ABSTRACT
The research was conducted to pose as a general problem Inefficiency control of the
Municipal Medical Records Medical Center Mala, thus investigated is to create and
implement an automated system to monitor and manage the clinical histories of patients,
thus optimizing the process search, minimizing Duplication of medical Records, Patient
care and improve service quality.
This automation allows more precise information when generating reports; these
challenges are strategically aligned to achieving this mission, although not all modules
belonging to the Municipal Medical Center implemented.
This project includes the step of Analysis Design and implementation of the system and the RUP
methodology is used in combination with the notation UML, use cases are diagramarán business,
the System Use Case, Sequence, Class Diagram, and prototype application which will contain the
screens.
The system is implemented is developed in Visual Basic Programming Language 6.0 and
the database to be used is SQL server. This will allow the registration of clinical histories,
and the efficiency with which all information from the Municipal Medical Center is
administered.
ÍNDICE
INTRODUCCIÓN……………………………………………………………………….. 12
CAPÍTULO I
EL PROBLEMA DE LA INVESTIGACIÓN
1.1. Planteamiento del Problema……………………………………………………… 14
1.2. Formulación del Problema………………………………………………………… 14
1.3. Objetivos de la Investigación……………………………………………………... 14
1.3.1. Objetivos Generales………………………………………………………... 14
1.3.2. Objetivos Específicos………………………………………………………. 14
1.4. Justificación del Estudio…………………………………………………………... 15
1.5. Limitaciones de la Investigación………………………………………………….. 16
1.6. Alcance de la Investigación……………………………………………………….. 16
CAPÍTULO II
MARCO TEÓRICO
2.1. Antecedentes del Estudio……………………………………………………….… 18
2.2. Bases Teóricas…………………………………………………………………….. 19
2.3. Definición de Términos……………………………………………………………. 44
2.4. Hipótesis…………………………………………………………………………….. 46
2.4.1. Hipótesis General………………………………………………………….. 46
2.4.2. Hipótesis específica……………………………………………………..… 46
2.5. Definición conceptual de la variable……………………………………………... 46
2.5.1. Definición conceptual de la variable…………………………………….. 46
2.5.2. Definición operacional de la variable……………………………………. 46
2.5.3. Operacionalización de la variable……………………………………….. 47
CAPÌTULO III
METODOLOGÍA
3.1. Tipo y nivel de Investigación……………………………………………………… 50
3.2. Descripción del ámbito de la Investigación……………………………………… 50
3.3. La Población y Muestra…………………………………………………………….. 50
3.4. Técnicas e instrumentos para la recolección de datos………………………..... 52
3.5. Validez y confiabilidad del instrumento…………………………………………… 53
3.6. Plan de recolección y procesamiento de datos………………………………...... 54
3.7. Diagrama de Contexto……………………………………………………………… 55
3.8. Diagrama General Cero…………………………………………………………..... 56
3.9. Diagrama Entidad Relación………………………………………………………… 57
3.10. Modelo de Caso de Uso de Negocio…………………………………………….. 58
3.11. Modelado de Requerimientos…………………………………………………….. 59
3.12. Diagrama de Caso de Uso de Sistemas………………………………………… 60
3.13. Diagramas de Actividades de los Casos de Usos de Sistemas………………. 73
3.14. Diagramas de Secuencia…………………………………………………………. 81
3.15. Diagrama de Clases……………………………………………………………….. 89
CAPÍTULO IV
RESULTADOS
4.1. Prototipos del Sistema………………………………………………………………. 91
4.2. Codificación del Sistema……………………………………………………………. 99
DISCUSIÓN………………………………………………………………………………. 103
CONCLUSIONES………………………………………………………………….......... 104
RECOMENDACIONES………………………………………………………………….. 105
REFERENCIAS BIBLIOGRÁFICAS……………………………………………........... 106
Bibliografías……………………………………………………………………………… 106
Páginas Web………………………………………………………………..................... 106
ANEXOS………………………………………………………………………………….. 107
ANEXO A: DIAGRAMA DE GANTT…………………………………….................... 108
ANEXO B: MODELO DE PROCESO PROPUESTO……………………………….. 110
ANEXO C: FOTOS DEL CENTRO MÉDICO MUNICIPAL…………………………. 111
ANEXO D: MATRIZ DE CONSISTENCIA……………………………………………. 117

INDICE DE TABLAS
Tabla 01: Diagramas de Caso de Uso de Negocio...……………………………….. 30
Tabla 02. Modelo de Caso de Uso del Negocio……..………………………………. 32
Tabla 03: Elementos del Diagrama de Actividad…..………………………………... 33
Tabla 04: Elementos del Diagrama de Secuencia…..………………………………. 35
Tabla 05: Población de los Centros de Salud de Mala……………………………… 51
Tabla 06: Determinación del tamaño de la muestra de Paciente………………….. 52
Tabla 07: Especificación del Caso de Uso Iniciar Sesión…………………………... 60
Tabla 08: Especificación del Caso de Uso Mantenimiento de Usuario……………. 62
Tabla 09: Especificación del Caso de Uso Mantenimiento de Doctor……………… 64
Tabla 10: Especificación del Caso de Uso Mantenimiento de Paciente…………… 66
Tabla 11: Especificación del Caso de Uso Enviar Paciente a Triaje……………….. 68
Tabla 12: Especificación del Caso de Uso Enviar Paciente a Consultorio Externo. 70
Tabla 13: Especificación de Caso de Uso Registrar Paciente en Consultorio E…... 71

INDICE DE GRÁFICOS
Gráfico 01: Faces del RUP………………………………………………………………. 24
Gráfico 02: UML Análisis y Diseño de Sistemas I…………………………………….. 26
Gráfico 03: Jerarquía de los Diagramas UML…………………………………………. 28
Gráfico 04: Diagrama de Clase…………………………………………………………. 36
Gráfico 05: Diagrama de Objetos………………………………………………………. 37
Gráfico 06: Diagrama de Estados………………………………………………………. 38
Gráfico 07: Diagrama de Colaboración………………………………………………… 39
Gráfico 08: Diagrama de Componentes……………………………………………….. 40
Gráfico 09: Diagrama de Despliegue…………………………………………………… 41
Gráfico 10: Sistema de Administración de Base de Datos…………………………… 43
Gráfico 11: Diagrama Contexto…………………………………………………………. 55
Gráfico 12: Diagrama General Cero......................................................................... 56
Gráfico 13: Diagrama Entidad Relación………………………………………………... 57
Gráfico 14: Modelo de Caso de Uso de Negocio……………………………………… 58
Gráfico 15: Modelo Detallado de Requerimientos CUS Iniciar Sesión……………… 60
Gráfico 16: Modelo Detallado de Requerimientos CUS Mantenimiento Usuario...... 61
Gráfico 17: Modelo Detallado de Requerimientos CUS Mantenimiento Doctor…… 63
Gráfico 18: Modelo Detallado de Requerimientos CUS Mantenimiento Paciente… 65
Gráfico 19: Modelo Detallado de Requerimientos CUS enviar Paciente a Triaje… 67
Gráfico 20: Modelo Detallado de Requerimiento CUS Seguimiento Paciente……. 69
Gráfico 21: Modelo Detallado de Requerimiento CUS Registrar Paciente C. Externo 71
Gráfico 22: Diagrama de Actividad Iniciar Sesión……………………………………. 73
Gráfico 23: Diagrama de Actividad Nuevo Usuario………………………………….. 73
Gráfico 24: Diagrama de Actividad Buscar Usuario…………………………………. 74

Gráfico 25: Diagrama de Actividad Modificar Usuario………………………………. 74
Gráfico 26: Diagrama de Actividad Eliminar Usuario……………………………….... 75
Gráfico 27: Diagrama de Actividad Nuevo Paciente………………………………..... 75
Gráfico 28: Diagrama de Actividad Buscar Paciente……………………………........ 76
Gráfico 29: Diagrama de Actividad Modificar Paciente…………………………….... 76
Gráfico 30: Diagrama de Actividad Eliminar Paciente……………………………….. 77
Gráfico 31: Diagrama de Actividad Nuevo Doctor……………………………………. 77
Gráfico 32: Diagrama de Actividad Buscar Doctor………………………………….... 78
Gráfico 33: Diagrama de Actividad Modificar Doctor………………………………… 78
Gráfico 34: Diagrama de Actividad Eliminar Doctor………………………………….. 79
Gráfico 35: Diagrama de Actividad Enviar Datos de Paciente a Triaje…………….. 79
Gráfico 36: Diagrama de Actividad Enviar Datos a Consultorio Externo…………… 80
Gráfico 37: Diagrama de Actividad de CUS Registrar Paciente en C. Externo…… 80
Gráfico 38: Diagrama de Secuencia Iniciar Sesión…………………………………... 81
Gráfico 39: Diagrama de Secuencia Nuevo Paciente………………………………... 82
Gráfico 40: Diagrama de Secuencia Buscar Paciente……………………………….. 83
Gráfico 41: Diagrama de Secuencia Modificar Paciente……………………………... 84
Gráfico 42: Diagrama de Secuencia Eliminar Paciente………………………………. 85
Gráfico 43: Diagrama de Secuencia Enviar Datos de Triaje…………………………. 86
Gráfico 44: Diagrama de Secuencia Seguimiento Enviar Datos a Consultorio…….. 87
Gráfico 45: Diagrama de Secuencia Registrar Paciente en Consultorio Externo….. 88
Gráfico 46: Diagrama de Clases…………………………………………………………. 89
Gráfico 47: Iniciar Sesión…………………………………………………………………. 91
Gráfico 48: Interfaz Menú Principal……………………………………………………… 92
Gráfico 49: Interfaz Mantenimiento Doctor……………………………………………… 93

Gráfico 50: Interfaz Mantenimiento Paciente…………………………………………… 94
Gráfico 51: Interfaz Buscar Paciente…………………………………………………….. 95
Gráfico 52: Interfaz Seguimiento de Paciente en Triaje……………………………….. 96
Gráfico 53: Interfaz Mantenimiento Atención de Paciente……………………………. 97
Gráfico 54: Interfaz Mantenimiento Usuarios…………………………………………... 98
Gráfico 55: Diagrama de Gantt…………………………………………………………... 109
Gráfico 56: Modelo de Proceso Propuesto……………………………………………... 110

Universidad Peruana de Integración Global 2015
INTRODUCCIÓN
El presente trabajo, analiza, identifica y soluciona el problema del Centro Médico

Municipal de Mala.
Dentro de los diferentes problemas de Control y Administración de Historias Clínicas que

tiene el Centro Médico Municipal, y que prioritariamente necesitan ser solucionadas
están:
El área de Admisión.- es donde se da inicio a la historia clínica y donde debe ser llenado
los datos del paciente con número de historia específico, y es aquí donde existen
dificultades en la búsqueda y la ocurrencia de redundancia de Historias Clínicas.
El área de Triaje.- a esta área es trasladada la historia clínica, para tomar la temperatura,
presión arterial, peso y talla del paciente y especificando a que área del Hospital se
dirige.
Área de Consulta Externa.- Destino del paciente y consulta realizada por el Doctor. Una
vez llenado y concluido los tres puntos mencionados, se considera Historia Clínica de un
Paciente.
Los reportes son creados en Excel, y cuando son solicitados por la administración surgen
las demoras al realizar los reportes.
Frente a estos problemas que existen en el Centro Médico Municipal, se ha creado un

sistema automatizado, cuyo funcionamiento está basado en el buen control y
administración de las Historias Clínicas, que mediante una serie de Menús, emite reportes
que son enviados a instancias superiores, logrando eficiencia y rapidez en los procesos
y/o atención de los pacientes.
Página 12
CAPÍTULO I
EL PROBLEMA DE
INVESTIGACIÓN
Página 13
1.1. Planteamiento del Problema
 Actualmente el área de Admisión del Centro Médico Municipal, tiene como
responsabilidad la de controlar y administrar las Historias Clínicas.
 Carece de eficiencia, pérdida de tiempo en la búsqueda y el traslado de estos
documentos que se da entre un área y otra.
 Debido a este problema no se agiliza la atención del paciente, formando grandes
colas de esperas y reclamos por parte de ellos.
 Al momento que se solicita los reportes por parte de la administración del hospital
no se entregan con la celeridad del caso, porque no existe una solución
automatizada que mantenga la información actualizada y soporte las diversas
actualizaciones que se necesita.
1.2. Formulación del Problema

1.2.1. Problema General
¿En qué medida el Desarrollo de un sistema de control de historias clínicas
mejorará en la ubicación y minimización de duplicidad documentaria en el área
de admisión del centro médico municipal de Mala – 2015?
1.2.2. Problemas Específicos
a. ¿En qué medida la Funcionalidad del sistema de control de historias
clínicas mejorará en la ubicación y minimización de duplicidad
documentaria en el área de admisión del centro médico municipal de Mala
– 2015?
b. ¿En qué medida la Confiabilidad del sistema de control de historias clínicas

mejorará en la ubicación y minimización de duplicidad documentaria en el
área de admisión del centro médico municipal de Mala – 2015?
Página 14
1.3. Objetivos de la Investigación
1.3.1. Objetivos Generales
Implementar un sistema de control de historia clínicas y su mejoramiento en la
ubicación y minimización de duplicidad documentaria en el área de admisión
del centro médico municipal de Mala – 2015.
1.3.2. Objetivos Específicos

a) Implementar un sistema de historia clínica y su mejoramiento en la
ubicación de los documentos relacionados.
b) Implementar un sistema de historia clínica y su mejoramiento en la

minimización de duplicidad documentaria.
1.4. Justificación del Estudio

La implementación de un sistema automatizado para el área de admisión tiene como
objetivo fundamental controlar y administrar las Historias Clínicas; imprescindible
para el logro de los objetivos planteados. Por tal motivo es necesario garantizar la
correcta elaboración del proyecto, que formara parte de los planes del Centro Médico
Municipal de Mala.
Es por ello que se implementó el sistema que permite automatizar los procesos de
control de la historias clínicas, este sistema desarrollado bajo un entorno escritorio y
enfoque cliente servidor, permitirá mejorar el logro de los procedimientos realizados
y que se ejecuten de manera eficiente y eficaz, alcanzando un control y manejo
adecuado de todas las Historias y celeridad de atención a los pacientes en la
Búsqueda de los Documentos además de la minimización de la Duplicidad de los
mismos.
El sistema es rápido y eficiente en su desempeño lo que evita pérdida de tiempo,

agiliza los procesos y manejo de información, realiza el control de las historias de
Página 15
manera adecuada por parte de las personas involucradas y por ende mejora la
capacidad de respuesta logrando un mejor desempeño y convirtiéndose en una
mejora para la atención de los pacientes.
Asimismo cuenta con un entorno de fácil manejo con seguridad en los accesos de tal
forma que solo el personal autorizado o involucrado podrá ingresar, ver, editar o
eliminar datos o información de una determinada Historia.
1.5. Limitaciones de la Investigación

a) Para el desarrollo del proyecto la limitación fue; la comunicación con el personal
encargado del área de Admisión ya que por falta de tiempo, el personal no puedo
participar en determinadas reuniones y/o preguntas dentro de la etapa de
construcción del sistema, lo que afecto el desarrollo del proyecto, no se puedo
cumplir con todas las expectativas que el usuario del sistema necesitó.
b) Falta de conocimiento y/o experiencia para desarrollar una aplicación de historias
clínicas que permita trabajar en red.
c) No se pudo realizar una implementación de sistema web, ya que el hospital no
pudo proporcionar los recursos económicos apropiados para este tipo de
implementación.
d) Las fuentes de investigación como documentos escritos y digitales, son
proporcionadas sin ninguna dificultad por el área admisión.
e) En cuanto al sistema de información automatizada, solo abarca lo concerniente
al área de admisión, Triaje y Consulta Externa.
1.6. Alcance
a) La Implementación del Sistema de Historias Clínicas, será empleado en el área
de Admisión, Triaje y Consulta Externa, y trabajara en Red.
b) El sistema solo se dedicará, al control y Administración de Historias Clínicas.
Página 16
CAPÍTULO II
MARCO TEÓRICO
Página 17
2.1. Antecedentes del Estudio
Miguel Ángel Rojas Cabrejos y Guillermo Renato Sulca Padilla 1, (Desarrollo de
una Aplicación Web, para el Registro de Historias Clínicas (HC) para el Hospital
Nacional Guillermo Almenara.), sostiene en el año 2012.
Que la forma de archivar las historias clínicas de los pacientes en un hospital limita
su atención, ya que por diversos motivos una persona puede cambiar de lugar de
atención, iniciando así en ese nuevo establecimiento otra historia clínica,
obstaculizando su continuidad en la atención, porque se pueden obviar, omitir o pasar
por alto antecedentes importantes realizados en el centro de salud anterior.
Asimismo, se usan trabajos científicos, de investigación, académicos; es decir, en
toda donde se requiera registrar, almacenar y organizar grandes cantidades de
información para ser empleadas para otras actividades, tareas o trabajos. Con los
avances de las Tecnologías de Información y Comunicación (TIC), las bases de datos
por lo general se encuentran en formato digital o electrónico que se pueden trabajar
muy bien para solucionar una amplia gama de problemas de almacenamiento de
información.
En nuestro caso, los archivos representan un caso análogo, donde se ordenan
inmensas cantidades de información. Concretamente, en el caso de los archivos de
Historias Clínicas, se ve claramente lo efectivo, funcional y práctico que puede ser
las BD en la administración de los expedientes de los enfermos en el Hospital
Nacional Guillermo Almenara.
Su trabajo tiene por objetivo mostrar los beneficios del uso de un Sistema de control
de Historias Clínicas, los cuales se traducen principalmente en: reducción de tiempos,
costos, procesos más eficientes, mejor comunicación, coordinación y un trabajo en
equipo e incluso una nueva organización.
1
http://www.cazova.files.wordpress.com/2012/07/tesis-sistema-para-hospital-esalud.pdf
Página 18
Richard Sabartes Fortuny 2, (Historia Clínica Electrónica en un Departamento de
Obstetricia, Ginecología y Reproducción: Desarrollo e Implementación. Factores
Clave), sostiene en el año 2013.
Que la implantación de un proyecto de estas características tiene muchas
implicaciones relacionadas con la prevención, el diagnóstico, el tratamiento y la
monitorización de pacientes, así como la planificación y el control de la gestión. Es
aquí donde puede contribuir sistemas como la Historia Clínica Electrónica, para ello
se necesita una infraestructura Tecnológica, la interoperabilidad para intercambiar
datos y establecer medidas de seguridad de protección de la información. Otro paso
no menos importante lo contribuye la integración con otros sistemas existentes para
permitir el intercambio de información Clínica.
En mi opinión la Historia Clínica electrónica es una herramienta que contribuye a la
eficiencia de la atención de los pacientes.
2.2. Bases Teóricas

2.2.1. Sistema automatizado
La automatización es un sistema donde se trasfieren tareas de producción,
realizadas habitualmente por operadores humanos a un conjunto de
elementos tecnológicos. Un sistema automatizado consta de dos partes
principales:
a) La Parte Operativa
Es la parte que actúa directamente sobre la máquina. Son los elementos
que hacen que la máquina se mueva y realice la operación deseada. Los
elementos que forman la parte operativa son los accionadores de las
máquinas como motores, cilindros, compresores. Y los captadores como
fotodiodos, finales de carrera.
b) La Parte de Mando suele ser un autómata programable (tecnología
programada), aunque hasta hace bien poco se utilizaban relés
2
http://www.tdx.cat/bitstream/handle/10803/117304/rsf1de1.pdf?sequence=1
Página 19
electromagnéticos, tarjetas electrónicas o módulos lógicos neumáticos
(tecnología cableada). En un sistema de fabricación automatizado el
autómata programable está en el centro del sistema. Este debe ser capaz
de comunicarse con todos los constituyentes de sistema automatizado.3
2.2.2. Historias clínicas es el documento médico legal que contiene todos los datos
psicobiopatológicos de un paciente. Es importante reiterar el valor legal, es
decir sujeta a los mandatos de la ley a la veracidad de su contenido. Es el alma
básica del médico, es la narración escrita, ordenada de todos los datos
relativos a un enfermo que sirven de juicio definitivo de la enfermedad actual.4
2.2.3. RUP – PROCESO UNIFICADO DE DESARROLLO DE SOFTWARE

Proceso Unificado de Desarrollo (RUP): es una metodología de desarrollo de
software que está basado en componentes e interfaces bien definidas, y junto
con el Lenguaje Unificado de Modelado (UML), constituye la metodología
estándar más utilizada para el análisis, implementación y documentación de
sistemas orientados a objetos.5
Es un proceso que puede especializarse para una gran variedad de sistemas

de software, en diferentes áreas de aplicación, diferentes tipos de
organizaciones, diferentes niveles de aptitud y diferentes tamaños de proyecto.
RUP no es un sistema con pasos firmemente establecidos, sino un conjunto

de metodologías adaptables al contexto y necesidades de cada organización.
Es el resultado de varios años de desarrollo y uso práctico en el que se han

unificado técnicas de desarrollo, a través del UML, y trabajo de muchas
metodologías utilizadas por los clientes. La versión que se ha estandarizado
vio la luz en 1998 y se conoció en sus inicios como Proceso Unificado de
3
VICTOR 2009 http://es.scribd.com/doc/51656086/Que-es-un-sistema-automatizado
4
Jhon Miranda Quispe 2013 http://es.slideshare.net/johnmq_iq/historia-clinica-24573066
5
Mike Edwards 2007 http://www.redbooks.ibm.com/redbooks/pdfs/sg247362.pdf
Página 20
Rational 5.0; de ahí las siglas con las que se identifica a éste proceso de
desarrollo.
HISTORIA DEL RUP
Los orígenes de RUP se remontan al modelo espiral original de Barry Boehm.

Ken Hartman, uno de los contribuidores claves de RUP colaboró con Boehm
en la investigación. En 1995Rational Software compró una compañía sueca
llamada Objectory AB, fundada por Ivan Jacobson, famoso por haber
incorporado los casos de uso a los métodos de desarrollo orientados a objetos.
El RationalUnifiedProcess fue el resultado de una convergencia de

RationalApproach y Objectory (el proceso de la empresa Objectory AB). El
primer resultado de esta fusión fue el RationalObjectoryProcess, la primera
versión de RUP, fue puesta en el mercado en 1998, siendo el arquitecto en
jefe PhilippeKruchten.
CARACTERÍSTICAS PRINCIPALES
Como RUP es un proceso, en su modelación define como sus principales

elementos:
Trabajadores (“quién”): Define el comportamiento y responsabilidades (rol) de

un individuo, grupo de individuos, sistema automatizado o máquina, que
trabajan en conjunto como un equipo. Ellos realizan las actividades y son
propietarios de elementos.
Actividades (“cómo”): Es una tarea que tiene un propósito claro, es realizada

por un trabajador y manipula elementos.
Artefactos (“qué”): Productos tangibles del proyecto que son producidos,

modificados y usados por las actividades. Pueden ser modelos, elementos
dentro del modelo, código fuente y ejecutables.
Flujo de actividades (“cuándo”): Secuencia de actividades realizadas por

trabajadores y que produce un resultado de valor observable.
Página 21
CICLO DE VIDA DE RUP
El ciclo de vida de RUP se caracteriza por:
Dirigido por casos de uso: Los casos de uso reflejan lo que los usuarios futuros
necesitan y desean, lo cual se capta cuando se modela el negocio y se
representa a través de los requerimientos. A partir de aquí los casos de uso
guían el proceso de desarrollo ya que los modelos que se obtienen, como
resultado de los diferentes flujos de trabajo, representan la realización de los
casos de uso (cómo se llevan a cabo).
Centrado en la arquitectura: La arquitectura muestra la visión común del

sistema completo en la que el equipo de proyecto y los usuarios deben estar
de acuerdo, por lo que describe los elementos del modelo que son más
importantes para su construcción, los cimientos del sistema que son
necesarios como base para comprenderlo, desarrollarlo y producirlo
económicamente. RUP se desarrolla mediante iteraciones, comenzando por
los CU relevantes desde el punto de vista de la arquitectura. El modelo de
arquitectura se representa a través de vistas en las que se incluyen los
diagramas de UML.
Iterativo e Incremental: Una iteración involucra actividades de todos los flujos

de trabajo, aunque desarrolla fundamentalmente algunos más que otros.
Por ejemplo, una iteración de elaboración centra su atención en el análisis y

diseño, aunque refina los requerimientos y obtiene un producto con un
determinado nivel, pero que irá creciendo incrementalmente en cada iteración.
Es práctico dividir el trabajo en partes más pequeñas o mini proyectos. Cada

mini proyecto es una iteración que resulta en un incremento. Las iteraciones
hacen referencia a pasos en los flujos de trabajo, y los incrementos, al
crecimiento del producto. Cada iteración se realiza de forma planificada es por
eso que se dice que son mini proyectos.
Página 22
FLUJO DE TRABAJO DE RUP
En RUP se han agrupado las actividades en grupos lógicos definiéndose 9

flujos de trabajo principales, los 6 primeros son conocidos como flujos de
ingeniería y los tres últimos como flujos de apoyo.
Modelo del Negocio: Describe los procesos de negocio, identificando quiénes

participan y las actividades que requieren automatización.
Requerimiento: Define qué es lo que el sistema debe hacer, para lo cual se

identifican las funcionalidades requeridas y las restricciones que se imponen.
Análisis y Diseño: Describe cómo el sistema será realizado a partir de la

funcionalidad prevista y las restricciones impuestas (requerimientos), por lo
que indica con precisión lo que se debe programar.
Implementación: Define cómo se organizan las clases y objetos en

componentes, cuáles nodos se utilizarán y la ubicación en ellos de los
componentes y la estructura de capas de la aplicación.
Prueba (Testeo): Busca los defectos a los largo del ciclo de vida.
Instalación o despliegue: Realiza actividades (empaque, instalación,

asistencia a usuarios, etc.) para entregar el software a los usuarios finales.
Administración del proyecto: Involucra actividades con las que se busca

producir un producto que satisfaga las necesidades de los clientes.
Administración de configuración y cambios: Describe cómo controlar los

elementos producidos por todos los integrantes del equipo de proyecto en
cuanto a: utilización/actualización concurrente de elementos, control de
versiones, etc.
Ambiente: Contiene actividades que describen los procesos y herramientas

que soportarán el equipo de trabajo del proyecto; así como el procedimiento
para implementar el proceso en una organización.
Página 23
FASES DEL RUP
Cada fase representa un ciclo de desarrollo en la vida de un producto de

software:
Gráfico 01: FASES DEL RUP
Fuente: http://www.ecured.cu/index.php
La fase de concepción o inicio tiene por finalidad definir la visión, los

objetivos y el alcance del proyecto, tanto desde el punto de vista funcional
como del técnico, obteniéndose como uno de los principales resultados una
lista de los casos de uso y una lista de los factores de riesgo del proyecto. El
principal esfuerzo está radicado en el Modelamiento del Negocio y el Análisis
de requerimientos. Es la única fase que no necesariamente culmina con una
versión ejecutable.
La fase de elaboración tiene como principal finalidad completar el análisis de

los casos de uso y definir la arquitectura del sistema, además se obtiene una
aplicación ejecutable que responde a los casos de uso que la comprometen.
A pesar de que se desarrolla a profundidad una parte del sistema, las
decisiones sobre la arquitectura se hacen sobre la base de la comprensión del
Página 24
sistema completo y los requerimientos (funcionales y no funcionales)
identificados de acuerdo al alcance definido.
La fase de construcción está compuesta por un ciclo de varias iteraciones,

en las cuales se van incorporando sucesivamente los casos de uso, de
acuerdo a los factores de riesgo del proyecto. Éste enfoque permite por
ejemplo contar en forma temprana con versiones el sistema que satisfacen los
principales casos de uso. Los cambios en los requerimientos no se incorporan
hasta el inicio de la próxima iteración.
La fase de transición se inicia con una versión “beta” del sistema y culmina
con el sistema en fase de producción.
2.2.4. UML – LENGUAJE UNIFICADO DE MODELADO

Lenguaje Unificado de Modelado (LUM o UML, por sus siglas en inglés, Iniciad
Modelan Language) es el lenguaje de modelado de sistemas de software más
conocido y utilizado en la actualidad; está respaldado por el OMG (Objeto
Management Grupo). Es un lenguaje gráfico para visualizar, especificar,
construir y documentar un sistema. UML ofrece un estándar para describir un
“plano” del sistema (modelo), incluyendo aspectos conceptuales tales como
procesos de negocio, funciones del sistema, y aspectos concretos como
expresiones de lenguajes de programación, esquemas de bases de datos y
componentes reutilizables.6
6
César Krall, Lenguaje Unificado de Modelado Diagramas Ingeniería del Software, 2°ed, apr2 .com 2006.
Página 25
Gráfico 02: UML Análisis y Diseño de Sistemas I
Fuente: http://www.aprenderaprogramar.com/index.php
UML es ante todo un lenguaje, lenguaje que se centra en representación
gráfica de un sistema. Es un lenguaje visual estándar empleado para la
especificación, construcción y documentación de software orientado a objetos,
por medio de diversos elementos y procesos que interactúan de alguna forma
con el software. Con este lenguaje se puede lograr:
a) Visualizar: Permite expresar de forma gráfica un sistema de una manera

fácil y versátil, para que una persona (distinta al diseñador y/o
programador), lo pueda entender.
b) Especificar: Permite expresar de manera muy explícita y clara, cuales son
las características de un sistema en la etapa previa a su construcción.
c) Construir: Es posible que a partir de los modelos diseñados se pueda
construir el sistema diseñado previamente.
d) Documentar: Maravillosamente todos los diagramas junto con sus
elementos gráficos sirven como documentación del sistema diseñado, lo
que al mismo tiempo son de utilidad para su revisión y evolución del
sistema.
Página 26
A pesar de que UML fue concebido y pensado para modelar sistema con gran
cantidad de software, esto limita sus funciones, ya que el mismo es lo
suficientemente expresivo como para modelar sistemas que no son
informáticos, como lo son el flujo de trabajo (wokflow) en una empresa, diseño
de estructura de una organización y otros sistemas.
Un diagrama UML está compuesto por tres clases de bloques de construcción:
a) Elementos: Los elementos son abstracciones de cosas reales o ficticias

(objetos, acciones, actores, etc.).
b) Relaciones: Son las que le dan vida a la interacción entre los elementos.
c) Diagramas: Que son colecciones de elementos junto con sus respectivas
relaciones.
Diagramas UML
Los diagramas son la representación gráfica de una colección de elementos
con sus relaciones, ofreciendo así una vista del sistema a modelar. Para poder
representar de forma correcta un sistema, el lenguaje presenta una amplia
variedad de diagramas para así visualizar el sistema desde diversas
perspectivas. En UML hay trece tipos diferentes de diagramas y en el siguiente
grafico se muestran categorizados de forma jerárquica.
Página 27
Gráfico 03: Jerarquía de los Diagramas UML
Fuente: Kendall S. (1999)

El modelado del negocio es una técnica para comprender los procesos de
negocios de la organización. El modelado el negocio esta soportado por dos
tipos de modelos de UML: Modelos de caso de uso del negocio y Modelos de
objetos del negocio.
El modelo de Casos de Uso del Negocio describe los procesos de negocio de

una empresa en términos de casos de uso del negocio y actores del negocio
que se corresponden con los procesos del negocio y los clientes,
respectivamente. El modelo de casos de uno del negocio se describe mediante
diagramas de casos de uso.
El modelo de Objetos del Negocio es un modelo interno a un negocio. Describe

como cada caso de uso del negocio es llevado a cabo por parte de un conjunto
de trabajadores que utilizan un conjunto de entidades del negocio y de
unidades de trabajo. Cada realización de un caso de uso del negocio puede
mostrarse en diagramas de interacción y diagramas de actividad. Una entidad
del negocio representa algo, como una factura, que los trabajadores toman,
Página 28
inspeccionan, manipulan, producen o utilizan en un caso de uso del negocio.
Una unidad de trabajo es un conjunto de esas entidades que conforman un
todo reconocible para un usuario final. Las entidades del negocio y las
unidades de trabajo se utilizan para representar los mismos tipos de conceptos
que las clases del dominio. También se tendrán otros diagramas para mostrar
los trabajadores, sus interacciones y como utilizan las entidades de negocio y
las unidades de trabajo.
Cada trabajador, entidad del negocio y unidad de trabajo puede participar en

la realización de más de un caso de uso del negocio.
Un modelo de negocio se desarrolla de la siguiente manera:
a) Los modeladores del negocio deben confeccionar un modelo de caso de

uso del negocio que identifique los actores del negocio y los casos de uso
del negocio que utilicen los actores, este modelo de casos de uso del
negocio permite a los modeladores comprender mejor que valor
proporciona el negocio a sus actores.
b) Los modeladores deben desarrollar un modelo de objetos del negocio
compuesto por trabajadores, entidades del negocio, y unidades de trabajo
que juntos realizan los casos de uso del negocio. Se asocian a estos
diferentes objetos las reglas del negocio y otras normas impuestas por el
negocio.
Vistas
Un sistema describe una serie de vistas, en la que cada vista representa una
proyección de la descripción del sistema completo, mostrando un aspecto en
particular del sistema.
Página 29
Estas vistas son:
a) Vista de Casos de Uso: Una vista que muestra la funcionalidad del

sistema percibida por actores externos.
b) Vista Lógica: Una vista que muestra como la funcionalidad es diseñada
dentro del sistema, en términos de la estructura estática y comportamiento
dinámico.
c) Vista de Componentes: Una vista que muestra la organización de los
componentes de código.
d) Vista de Concurrencia: Una vista que muestra las concurrencias en el
sistema, encaminando los problemas de comunicación y sincronización
que están presentes en un sistema con concurrencia.
e) Vista de Despliegue: Una vista que muestra la implementación del
sistema como una estructura física con computadora y dispositivos
llamados nodos.
Modelo del Negocio con UML

El modelo del negocio con UML es una técnica para modelar el negocio bajo
un mismo lenguaje.
Tabla 01: Diagramas de Caso de Uso del Negocio

Nombre Símbolo Definición
Algo o alguien externo
al negocio que
Actor de Negocio
interactúa con el
negocio.
Rol o conjunto de roles
dentro del negocio. Un
Trabajador del Negocio
trabajador del negocio
interactúa con otros
Página 30
trabajadores y manipula
entidades del negocio.
Algo usado por los
Entidad del Negocio trabajadores del
negocio.
Una secuencia de
acciones que le negocio
Caso de Uso del realiza y en el que se
Negocio observa un resultado d
valor para un actor de
negocio en particular.
Una colección de
diagramas para mostrar
como los elementos de
Realización de un Caso
la organización son
de Uso del Negocio
utilizados para dar
soporte a los procesos
del negocio.
Usado para estructurar

Unidad Organizacional
el negocio en partes.
La línea de
comunicación entre un
Asociación
actor y un caso de uso
en el que participa.
Modelo de Caso de Uso de Negocio

El primer paso en el modelamiento del negocio es definir la interacción entre
las entidades externas al negocio y sus procesos del negocio. Esto es
documentado en el diagrama de casos de uso del negocio (casos de uso del
Página 31
negocio) el cual representa la interacción entre los servicios principales que el
negocio provee y aquellos a los que se les provee dichos servicios (actores del
negocio).
a) Descripción textual del proceso de negocio.
Nos introducimos en cada uno de los procesos identificados para
describirlo (textualmente) en detalle. Para cada proceso de negocio es
necesario determinar que agentes (personas, departamentos, sistemas
software, etc.) participan en el mismo; cada agente juega cierto rol cuando
colabora con el resto para desarrollar las actividades de que consta dicho
proceso de negocio, y así alcanzar el objetivo. Debemos determinar
también cuales son las acciones (actividades) que realizan los actores
dentro del proceso de negocio, y la información necesaria y producida por
dichas actividades. El resultado de este paso es un listado de los roles
internos y externos que intervienen en el proceso y las actividades que
cada uno de ellos lleva a cabo.
Tabla 02: Modelo de Caso de Uso del Negocio
Proceso de
Gestionar los pedidos de un Cliente
Negocio
Objetivo
Descripción 1.-
2.-
3.-
4.-
Prioridad
Riesgo
Posibilidades
Tiempo de
Ejecución
Coste Ejecución
Página 32
Diagrama de Actividad
Son usados para elaborar modelos de flujo de trabajo de un sistema, los cuales
expresan que acciones se requieren, que hace estas acciones, cuando tiene
lugar. Los diagramas de actividad capturan las acciones de una actividad y sus
resultados, estos enfatizan la secuencia de acciones de una actividad,
establecen las condiciones para coordinar comportamiento de bajo nivel y
modelan el flujo de control o de objetos de una actividad.
El diagrama de actividad tiene como uno de sus propósitos modelar los
procesos reales de una organización humana. El modelado de tal negocio es
muy importante en los diagramas de actividad, de igual manera se pueden
utilizar para modelar actividades de software, este nos permite entender el
comportamiento de alto nivel de la ejecución de un sistema, sin profundizar en
los detalles internos de los mensajes. Los símbolos del diagrama de actividad
se reflejan a continuación:
Tabla 03: Elementos del Diagrama de Actividad
Acción Nodo de actividad.
Nodo de control que

indica el inicio de un flujo
Nodo de Inicio
de control cuando una
actividad es invocada.
Nodo de control que
indica el fin de todos los
Nodo de Fin flujos dentro de una
actividad. Muestra el fin
de la actividad.
Usado para separar un
Conector
flujo y restablecer su
Página 33
conexión en un
diagrama.
Nodo de control que
Decisión selecciona entre dos o
más flujos de salida.
Nodo de control que
Nodo de concurrencia sincroniza múltiples
flujos.
Diagrama de Secuencias
Se muestra una colaboración dinámica entre un número determinado de
objetos. El aspecto importante de este diagrama es que muestra una
secuencia de mensajes enviados entre objetos. También muestra una
interacción entre objetos, algo que se pasara en algún punto específico en la
ejecución del sistema. El diagrama consiste de un determinado número de
objetos mostrados con líneas verticales. El tiempo transcurre en forma
descendente en el diagrama, y el diagrama muestra el intercambio de
mensajes entre los objetos a medida que el tiempo transcurre en la secuencia
o función. Los mensajes se muestran como línea con flechas que indican
mensajes entre líneas verticales de los objetos. Las especificaciones del
tiempo y otros comentarios se agregan en un script a un costado del diagrama.
Página 34
Tabla 04: Elementos del Diagrama de Secuencia
La línea de vida de un
objeto representa la vida
del objeto durante la
Línea de Vida interacción. En un
diagrama de secuencia un
objeto se representa
como una línea vertical
punteada.
Muestra el periodo de
tiempo en el cual el objeto
se encuentra
desarrollando alguna
Activación operación, bien sea por sí
mismo o por medio de
delegación a alguno de
sus atributos. Se denota
con un rectángulo sobre la
línea de vida del objeto.
Diagrama de Clases
Un diagrama de clases muestra la estructura estática de las clases en el
sistema. Las clases representan las “cosas” que son manipuladas en el
sistema. Las clases pueden estar relacionadas entre ellas en distintas formas:
asociada (conectada entre ellas), dependiente (una clase depende / usa otra
clase), especializada (una clase es una especialización de otra clase), o
empaquetada (agrupada como una unidad). Todas las relaciones se muestran
en un diagrama de clases junto con la estructura interna de las clases en
términos de atributos y operaciones. El diagrama es considerado estático
cuando la estructura descrita es siempre valida en cualquier punto del ciclo de
vida del sistema.
Un sistema típicamente tiene un determinado número de diagramas de clases.
No todas las clases se insertan en un único diagrama de clases, y una clase
puede participar en varios diagramas de clases.
Página 35
Gráfico 04: Diagrama de Clases
Diagramas de Objetos
Un diagrama de objetos en una variante de un diagrama de clases y usa casi
una notación idéntica. La diferencia entre ambos es que un diagrama de
objetos muestra un número de instancias de objetos de clases, en vez de las
clases reales. Por lo tanto, un diagrama de objetos es un ejemplo de un
diagrama de clases que muestra una posible imagen del sistema en ejecución,
como el sistema se vería en algún punto en el tiempo. Se usa la misma
notación de un diagrama de clases, con dos excepciones: los nombres de los
objetos se subrayan y todas las instancias reales y las relaciones se muestran.
Los diagramas de objetos no son tan importantes como los diagramas de
clases, pero pueden ser utilizados para ejemplificar un diagrama de clases
complejo mostrando como las instancias reales y las relaciones se verían. Los
diagramas de objetos también se usan como parte de los diagramas de
colaboración, en la que la colaboración dinámica entre un conjunto de objetos
se muestra.
Página 36
Gráfico 05: Diagrama de Objetos
Diagramas de Estados
Un diagrama de estado es típicamente un complemento de la descripción de
una clase. Muestra todos los posibles estados que los objetos de una clase
pueden tener, y que eventos provocan el cambio de estado. Un evento puede
ser otro objeto que le envía un mensaje, por ejemplo, que un determinado
tiempo ha transcurrido, o que alguna condición se ha cumplido. Un cambio de
estado se llama transición. Una transición también puede ser una acción
asociada a ella que especifica que se debería hacer con relación a la transición
de estado.
Los diagramas de estado no se hacen para todas las clases, es solo para
aquellas que tengan un número de estados bien definido, y en donde el
comportamiento de la clase es afectado y cambiado por los distintos estados.
Los diagramas de estado también pueden ser hechos para todo el sistema en
su totalidad.
Página 37
Gráfico 06: Diagrama de Estados
Diagramas de Colaboración
Un diagrama de colaboración muestra una colaboración dinámica, así como lo
hace un diagrama de secuencia. Frecuentemente queda a criterio del usuario
elegir mostrar la colaboración ya sea en un diagrama de secuencias o como
un diagrama de colaboración. Además de mostrar el intercambio de mensajes
(interacción), el diagrama de colaboración muestra los objetos y sus relaciones
(algunas veces referida como el contexto). Ya sea que use un diagrama de
secuencia o un diagrama de colaboración frecuentemente se puede decidir
por los siguiente: Si el aspecto más importante de enfatizares el tiempo o
secuencia, escoja el diagrama de secuencia; si importa enfatizar el contexto,
escoja el diagrama de colaboración. La interacción entre los objetos se
muestra en ambos diagramas.
Los diagramas de colaboración se muestran como diagramas de objetos,
donde un número determinado de objetos se muestran junto con sus
relaciones (usando la notación del diagrama de clase / objetos). Las flechas
que representan mensajes se dibujan entre los objetos para mostrar el flujo de
Página 38
mensajes entre los objetos. Los mensajes son rotulados, los cuales entre otras
cosas, muestran el orden en el cual los mensajes son enviados. Esto también
puede mostrar condiciones, iteraciones, valores de retorno, etc. Una vez que
un desarrollador esté familiarizado con la sintaxis de rotular mensajes, puede
leer la colaboración y seguir el flujo de ejecución y el intercambio de mensajes.
Un diagrama de colaboración también puede contener objetos activos,
aquellos que se ejecutan en forma concurrente con otros objetos.
Gráfico 07: Diagramas de Colaboración
Diagrama de Componentes
Un diagrama de componentes muestra la estructura física del código en términos
de componentes de código. Un componente puede ser un componente de código
fuente, un componente ejecutable. Un componente ejecutable. Un componente
contiene información sobre las clases lógicas o clases que implementan, por lo
tanto crea una relación entre la vista lógica y la vista de componentes. La
dependencia entre los componentes se muestra, haciendo más fácil analizar como
otros componentes se ven afectados por cambios en un componente. Los
Página 39
componentes también se pueden mostrar con cualquiera de las interfaces que
exponen, como las interfaces OLE / COM; y pueden ser agrupadas en paquetes.
El diagrama de componentes se utiliza en trabajos de programación prácticos.
Gráfico 08: Diagramas de Componentes
Diagrama de Despliegue
El diagrama de despliegue muestra la arquitectura física de hardware y
software en el sistema. Puede mostrar las computadoras y dispositivos reales
(nodos), junto con las conexiones que presentan entre ellos; también puede
mostrar el tipo d conexiones. Dentro de los nodos, los componentes
ejecutables y objetos son ubicados con el fin de mostrar que unidades de
software se ejecutan en determinados nodos. También puede mostrar las
dependencias entre los componentes.
Como hacemos dicho anteriormente, el diagrama de despliegue, mostrando
en la vista de despliegue, describe la arquitectura física actual del sistema.
Esto es más que la descripción funcional en la vista de casos de usos.
Página 40
Gráfico 09: Diagrama de Despliegue
2.2.5. Base de Datos

Una base de datos es un conjunto de datos almacenados de forma integrada
y compartida. Se entiende por integrada que la base de datos puede
considerarse como un conjunto de varios archivos independientes, donde se
elimina o se reduce al mínimo cualquier redundancia entre los mismo. Por
compartida se entiende que varios usuarios diferentes pueden acceder a la
misma fracción de la base de datos, incluso al mismo tiempo y utilizarla con
fines diferentes. Por otro lado, un usuario determinado solo tendrá acceso a
algún subconjunto de la base de datos.
Desde el punto de vista informático, la base de datos es un sistema formado
por un conjunto de datos almacenados en discos que permiten el acceso
directo a ellos y un conjunto de programas que manipulen ese conjunto de
datos. Cada base de datos se compone de una o más tablas que guarda un
conjunto de datos. Cada tabla tiene una o más columnas y filas. Las columnas
Página 41
guardan una parte de la información sobre cada elemento que queramos
guardar en la tabla, cada fila de la tabla conforma un registro.7
Características de una Base de Datos
a) Una base de datos contiene entidades de información que están
relacionadas vía organización y asociación.
b) La arquitectura lógica de una base de datos se define mediante un
esquema que representa las definiciones de las relaciones entre las
entidades de información.
c) La arquitectura física de una base de datos depende de la configuración
del hardware residente. Sin embargo, tanto el esquema (descripción lógica
como la organización, descripción física) deben adecuarse para satisfacer
los requerimientos funcionales y de comportamiento para el acceso al
análisis y creación de informes.
Ventajas de una Base de Datos

Globalización de la información: permite a los diferentes usuarios considerar
la información como un recurso corporativo, que carece de dueños
específicos.
Eliminación de información inconsistente: si existe dos o más archivos con la

misma información, los cambios que se hagan a estos deberán hacerse a
todas las copias del archivo.
Permite mantener la integridad en la información: la integridad de la

información es una de las cualidades altamente deseable y tiene por objetivo
que solo se almacena la información correcta.
7
Manuel Sierra, Diseño y Modelado de Base de Datos Diagramas Ingeniería del Software, 2°ed, apr2 .com 2006.
Página 42
Sistemas manejadores de Base de Datos
Un sistema manejador de base de datos es básicamente un sistema
computarizado para guardar registros, es un sistema cuya finalidad general es
almacenar información y permitir a los usuarios recuperar y actualizar esa
información con base en peticiones. Los usuarios del sistema pueden realizar
una variedad de operaciones sobre dichos archivos, por ejemplo:
a) Agregar nuevos archivos vacíos a la base de datos.
b) Insertar datos dentro de los archivos existentes.
c) Recuperar datos de los archivos existentes.
d) Modificar datos en archivos existentes.
e) Eliminar datos de los archivos existentes.
f) Eliminar archivos existentes de la base de datos.
Gráfico 10: Sistema de Administración de Base de Datos
Fuente: cjlovevc.blogspot.com
Página 43
2.3. Definición de Términos.
 Sistema de Información
Un sistema de información puede definirse técnicamente como un conjunto de
componentes interrelacionados que permiten capturar, procesar, almacenar y
distribuir la información para apoyar la toma de decisiones y el control en una
institución. Además, para apoyar la toma de decisiones, la coordinación y el
control, los sistemas de Información pueden también ayudar a los administradores
y al personal a analizar problemas, visualizar cuestiones complejas y crear nuevos
productos.
 Arquitectura cliente – servidor
Las palabras Cliente / Servidor define las forma en que se relacionan las
estaciones de trabajo a través de las redes de comunicación. En el modelo Cliente
/ Servidor, existen dos entidades relacionadas, pero de diferente jerarquía. Una de
las partes, el cliente, desea llevara a cabo una operación, en vez de realizarla por
sí solo, le traslada esa operación al servidor, el servidor recibe la petición a través
de algún medio de comunicación y se encargara de realizarla y le devolverá un
resultado. Es por eso que en este contexto, el termino cliente se aplica a la parte
que se encarga de iniciar la transacción. En algunos casos, este término se refiere
a todo un sistema (hardware y software) utilizado por un usuario. También se
puede denominar como cliente a un software específico para un protocolo Internet,
como puede ser un cliente FTP.
 Actividad: Acciones o tareas que se llevan a cabo para generar los resultados
planteados en los objetivos y lograr los productos finales que concretan o hacen
realidad en el tiempo las metas propuestas.
 Actor: Aquel rol o función que asume una persona, sistema o entidad que
interactúa con el sistema que estamos construyendo de la misma forma. Tiene la
propiedad de ser externo al sistema. Teniendo en cuenta que un usuario puede
acceder al sistema como distintos actores.
 Área de Registros Académicos: Administra con eficiencia los registros de
alumnos y docentes.
Página 44
 Automatización: Es la ejecución automática de tareas industriales,
administrativas o científicas haciendo más ágil y efectivo el trabajo ayudando de
este modo al ser humano.
 Base de Datos: Es un formato estructurado para organizar y mantener
informaciones que pueden ser fácilmente recuperadas.
 Clases: Este elemento representa un conjunto de objetos que tienen una
estructura, un comportamiento y unas relaciones con propiedades parecidas.
 Control: Mecanismo para la comprobar que las cosas se realicen como fueron
previstas, de acuerdo con las políticas, objetivos y metas fijadas previamente para
garantizar el cumplimiento de la misión.
 Dependencia: Es la persona a la cual va dirigida un trámite, generalmente esta
persona tiene a su cargo un área de la institución.
 Datos: Son un conjunto discreto de valores (cifras, características, hechos,
transacciones) objetivos sobre un hecho real, captados a través de encuestas,
observaciones, lecturas, mediciones. Un datos en sí mismo no tiene significado ni
aporta razones, tiene poca relevancia o propósito.
 Eficacia: Cumplir una meta en base a los recursos disponibles.
 Eficiencia: Operar de modo que los recursos sean utilizados de forma más
adecuada.
 Factibilidad: Es la disponibilidad de los recursos necesarios para llevar a cabo los
objetivos o metas señaladas. Generalmente la factibilidad se determina sobre un
proyecto.
 Formulario: Una clase estereotipada como un form, es una colección de campos
de entrada que son parte de una página del cliente. Una clase del formulario se
mapea directamente a HTML. Sus atributos representan los campos de la entrada
del formulario de HMTL (input boxes, text áreas, radio buttons, check boxes, y los
campos ocultos).
Página 45
2.4. Hipótesis
2.4.1. Hipótesis General
La Implantación de un sistema de control de historias clínicas mejorará en la
ubicación y minimización de duplicidad documentaria en el área de admisión
del centro médico municipal de Mala – 2015.
2.4.2. Hipótesis específica
a) Si se implementara un sistema de historia clínica mejorará en la ubicación
de los documentos relacionados.
b) Si se implementara un sistema de historia clínica mejorará en la
minimización de duplicidad documentaria.
2.5. Definición conceptual de la variable

2.5.1. Definición conceptual de la variable
Sistema de Control.- Describe la Tecnología que se desarrollará y que
permitirá realizar el Control de las Historias Clínicas en el Centro Médico
Municipal de Mala, y poder obtener la información en manera rápida y precisa.
Ubicación de Historias Clínicas.- Para esta Variable tendremos que precisar
si el Sistema implementado ayudara con la ubicación de las Historias Clínicas.
Minimización de Duplicidad de Historias Clínicas.- Para esta Variable
tendremos que precisar si el Sistema Implementado ayudará con la
minimización de Duplicidad de las Historias Clínicas.
2.5.2. Definición operacional de la variable

Sistema de Control.
Utilización.- Este indicador permitirá que las áreas involucras aprueben el
Sistema de Control.
Accesibilidad.- Permite a los Usuarios Comprobar que tan Accesible es el
Sistema de Control para la obtención de datos.
Página 46
2.5.3. Operacionalización de la variable
VARIABLE INDEPENDIENTE
X= Sistema de Control de Historias Clínicas
A. Indicadores:
X1= Funcionalidad
X2= Confiabilidad
B. Índices
Indicador Índices
X11 =Tiempo promedio de

Búsqueda de Historias
X1 = Funcionalidad Clínicas por día con Sistema /
Tiempo promedio de
Búsqueda de Historias
Clínicas por día sin Sistema.
X21 = Cantidad de Historias

Clínicas Registradas por mes
X2 = Confiabilidad sin duplicidad con Sistema /
Cantidad de Historias Clínicas
Registradas por mes con
duplicidad sin Sistema
Página 47
VARIABLE DEPENDIENTE
Y= Mejoramiento en la Ubicación y Minimización de duplicidad documentaria
en el área de admisión.
A. Indicadores:
Y1= Eficiencia.
Y2= Eficacia.
B. Índices
Indicadores Índices
Y11 = Cantidad de pacientes atendidos

Y1= Eficiencia por día con Sistema / Cantidad de
pacientes atendidos por día sin
Sistema.
Y21 = Cantidad de Reportes de

Historias Clínicas Generados por día
Y2= Eficacia
con Sistema. / Cantidad de Reportes
de Historias Clínicas Generados por día
sin Sistema.
Página 48
CAPÍTULO III
METODOLOGÍA
Página 49
3.1. Tipo y nivel de Investigación
3.1.1. Tipo de Investigación
La naturaleza de esta investigación es “aplicada” porque está basada en la
aplicación de conocimientos teóricos a un proceso definido y a las
consecuencias prácticas que de ellas se derivan.
3.1.2. Nivel de Investigación
Esta investigación es de nivel Descriptiva y luego Correlacionar porque el
propósito principal es saber cómo se puede comportar una variable
conociendo el comportamiento de otra variable relacionada.
Se trata también de descripciones; pero no de variables individuales sino de
sus relaciones.
3.2. Descripción del ámbito de la Investigación
El presente trabajo tiene como ámbito de la investigación el área geográfica del
Distrito de Mala Provincia Cañete.
La investigación comprende específicamente al Centro Médico Municipal de Mala
que dedican a la Atención de Pacientes con bajos recursos económicos y a su vez
quienes controlan y administran las Historias Clínicas, los cuales se consideran los
sujetos de estudio en la investigación.
3.3. La Población y Muestra

3.3.1. La Población
La población objetivo de la presente investigación está conformada por pacientes

de centros de salud públicos de la ciudad de mala de la provincia de Cañete. Se
ha solicitado información del “Centro de Salud Mala”, del “Centro de asegurados
EsSalud” y el “Centro Médico Municipal” recolectándose datos para el año 2015,
tal como se muestra en la Tabla siguiente.
Página 50
Tabla 05: Población de los Centros de Salud de Mala.
Población de los Centros de Salud de Mala.
Centros de Salud TOTAL
Entidades Centro de Salud EsSalud Centro

Mala Médico
Municipal
Pacientes 200 102 307 609
Fuente: Elaboración Propia
Considerando los datos obtenidos de la población de pacientes de los diferentes

centros médicos, se procedió a calcular el tamaño de muestra del total de
población de los Centros Médicos de Mala, utilizando la fórmula para una
población finita, en la que se conoce el tamaño de la población:
n = (N Z2 p q) / (E2 (N – 1) + Z2 p q) Donde:
n : Tamaño de la muestra
N : Tamaño de la población (609).
Z : Nivel de confianza, con un valor de 1.96 para el 95% de confianza.
P : Variabilidad positiva. Se considera 0.5 al no haber antecedentes.
Q : Variabilidad negativa. Se considera 0.5 al no haber antecedentes.
E : Error. Se consideró 4.11% (0.0411).
Las operaciones para el cálculo de la muestra fue la siguiente:
n = (609 * 1.962 * 0.5 * 0.5) / (0.04112 * (609 – 1) + 1.962 * 0.5 * 0.5) = 294.29
Luego se distribuyó la muestra para cada Centro de Salud quedando la muestra

distribuida como se indica en la Tabla.
Página 51
Tabla 06: Determinación del tamaño de la muestra de Pacientes.
Determinación del tamaño de la muestra de Pacientes.

TOTAL
Centros de Salud
Entidades Centro de Salud EsSalud Centro Médico
Mala Municipal
P M P M P M P M
Pacientes 200 148.15 102 86.61 307 199.58 609 294.29
Nota. P: población. M: Muestra. CMM: Centro Médico Mala.
Fuente: Elaboración Propia.

La muestra que se va a considerar en este proyecto es de 10 personas, ya que son
los que nos van a brindar información para desarrollar el sistema.
3.4. Técnicas e instrumentos para la recolección de datos

Las técnicas e instrumentos utilizados, para la recopilación, procesamiento y
despliegue de la información, corresponden a los que se emplean generalmente para
éste tipo de investigación.
3.4.1. Técnicas
Las técnicas son los procedimientos o reglas que se utilizaron para captar la
información. 8,
Las principales técnicas que se han utilizado para el levantamiento de
información son:
a) Entrevistas
b) Análisis Documental.
c) Encuesta.
d) Observación de Campo.
e) Revisión Bibliográfica Electrónica
8
Roberto Hernández Sampieri y otros. Metodología de la Investigación. 3era Ed. 2003. pp. 346.
Página 52
3.4.2. Instrumentos
“Los instrumentos para la recolección de información han sido medios en los
que se consigna la información para su posterior procesamiento.9,
Los instrumentos utilizados fueron los siguientes:
a) Guía de Entrevista.
b) Fichas Resumen.
c) Cuestionario.
d) Guía de observación de campo.
e) Internet – flash memories
3.5. Validez y confiabilidad del instrumento

Para la validez de los instrumentos se acudió a juicio de expertos, investigadores con
grado de Magister, los cuales, luego de analizar los instrumentos (encuestas) a
utilizar procedieron a asignar un puntaje. Los aspectos o indicadores a considerar en
la evaluación son:
 Claridad. Si el instrumento está formulado con lenguaje apropiado.
 Organización. Si existe secuencialidad lógica en los ítems planteados.
 Suficiencia. Si se comprende los aspectos de cantidad y claridad.
 Pertinencia. Si los ítems planteados son adecuados para la optimización de la
investigación.
 Consistencia. Si el instrumento está basado en aspectos teóricos científicos.
 Coherencia. Si existe coherencia entre los ítems y los indicadores.
 Metodología. Si la estrategia responde a los objetivos de la investigación.
Cada experto asignó un puntaje centesimal para cada uno de los criterios y
finalmente reporta un promedio. A continuación el promedio obtenido para los
indicadores de validez del instrumento por juicio de expertos:
 Hernández Peves Juan, con un promedio de Excelente (85 puntos) y con opinión
de aplicabilidad de excelente.
9
Roberto Hernández Sampieri y otros, Metodología de la Investigación, 3era Ed. 2003.pp. 348.
Página 53
 Díaz Yaya María Elena, con un promedio de Bueno (50 puntos) y con opinión
de aplicabilidad positivo.
 García Avalos César Mario, con un promedio de Muy Bueno (80 puntos) y con
opinión de aplicabilidad positivo.
Si se obtiene el promedio de estas tres evaluaciones se obtiene el valor de 72.67
correspondiente a Bueno la valoración del juicio de expertos a los instrumentos a utilizar
en el presente estudio.
3.6. Plan de recolección y procesamiento de datos

3.6.1. Plan de Recolección.
El plan de recolección de información no es más que una explicación detallada de
cómo se va a obtener la información.
Se detalla paso a paso lo que el investigador realiza al momento de recolectar la
información cualquiera que sea la fuente.
Para esto se debe tomar en cuenta las fuentes de información como son libros,
revistas, documentales, videos, entre otros y sobretodo la observación de campo.
3.6.2. Procesamiento de datos.

Explica cómo va hacer la tabulación, el análisis e interpretación de resultados,
incluyendo los estadísticos que va a necesitar para comprobar su hipótesis.
Una vez recolectada toda la información el investigador debe analizar la
información recolectada parte por parte lo recolectado para separar la
información que va a emplear para su trabajo escrito, se sigue el procedimiento
anterior, detallando que se va a hacer para separar la información valida de la
que es inservible para desarrollar el tema de investigación.
Página 54
3.7. Diagrama Contexto
Gráfico 11: Diagrama Contexto
Fuente: Elaboración Propia
Página 55
3.8. Diagrama General Cero.
Gráfico 12: Diagrama General Cero
Página 56
3.9. Diagrama Entidad Relación.
Gráfico 13: Diagrama Entidad Relación.

Página 57
3.10. Modelo de Caso de Uso de Negocio.
Gráfico 14: Modelo de Caso de Uso de Negocio.
Registrar Datos Personales

(from USE CASE DEL NEGO...
Solicitar Atención Médica Encargado de Admisión

Paciente
(from USE CASE DEL NEGO... (from ACTORES DEL NEGOCIO)
(from ACTORES DEL NEGOCIO)
Buscar Historia Generar Reportes

Registrar Historia
Encargado de Triaje Encargado de Consultorio Externo

Página 58
3.11. Modelado de Requerimientos.
En el Modelado de Requerimientos usamos el Modelo de Casos de uso del
Sistema.
El Modelo de Casos de uso del Sistema, es un modelo que describe los
requerimientos funcionales del sistema en forma de Casos de uso.
En el Sistema de Matricula que implementaremos el Colegio Virgen de Guadalupe
encontramos los siguientes casos de uso del sistema:
Identificación de Requerimientos funcionales y no funcionales.

Requerimientos Funcionales:
 Registrar Historias Clínicas.
 Actualizar Historias Clínicas.
 Consultar Paciente Atendidos.
 Consultar Pacientes Atendidos por Doctor y Fecha.
 Consultar Pacientes por Apellidos y Nombres, DNI, N° de Historia Clínica.
 Registra Usuarios para el mantenimiento del Sistema.
 Modificar Usuarios para el mantenimiento del Sistema.
 Eliminar Usuarios.
 Imprimir Reportes de acuerdo al tipo de Consulta solicitado al Sistema.
Requerimientos No Funcionales:
 Se Imprimirán reportes en menos de 2 segundos.
 Las Consultas se realizaran en menos de 2 segundos.
 El Sistema que se implantará funcionará con Windows xp o Superior.
 El Ingreso al Sistema es autenticado, el usuario tendrá que ingresar con un
usuario y Contraseña.
 El Sistema tendrá la opción de funcionar del modo cliente servidor.
 Este Sistema funcionará con el Gestor de Base de datos SQL Server 2000
 Ya que se trabajará con SQL Server se realizará un Backup de la Base de
Datos.
Página 59
 El sistema tendrá una ayuda con la Documentación detallada para la Operación
del mismo.
3.12. Diagramas de Caso de Uso de Sistemas.
Describe los requerimientos Funcionales Generales del Sistema.
3.12.1. Modelo Detallado de Requerimientos del Caso de Uso Iniciar Sesión:
Gráfico 15
Ingresar Datos
Usuario
<<include>> <<include>>
Validar Datos <<extend>> Aceptar Ingreso Cargar Sistema
<<extend>>
Encargado de Triaje
Doctor
Administrador Encargado de
Admision
Mostrar Mensaje de Error
Especificación del Caso de Uso Iniciar Sesión:

Tabla 07: Especificación del Caso de Uso Iniciar Sesión.
CASO DE USO: INICIAR SESIÓN

ACTOR: USUARIO
PRECONDICIÓN: EL USUARIO HA SIDO REGISTRADO EN EL SISTEMA
POSCONDICIÓN: EL USUARIO HA SIDO ADMITIDO POR EL SISTEMA
FLUJO BÁSICO
ACTOR SISTEMA
1. EL C.U empieza cuando el 1. El Sistema muestra la pantalla de

Usuario desea ingresar al ingreso.
Sistema
Página 60
2.El Usuario ingresa su número de 2. Verifica los datos e ingresa al sistema y
usuario y su contraseña el C.U. termina.
FLUJOS ALTERNATIVOS
2.1 Si los datos son válidos el Usuario logrará ingresar al sistema y dependiendo del
tipo de usuario que sea se mostraran la pantalla de menú correspondiente.
2.2 Si los datos ingresados por el Usuario son incorrectos, no se podrá ingresar al
sistema, por consiguiente se mostrará un mensaje de error.
3.12.2. Modelo Detallado de Requerimientos del Caso de Uso Mantenimiento de

Usuario:
Gráfico 16
Nuevo Usuario
<<extend>>
Buscar Usuario <<extend>> Mostrar Usuario

Usuario
<<include>>
Modificar Usuario Grabar Usuario
<<include>>
Administrador
<<extend>>
Eliminar Usuario
Página 61
Especificación del Caso de Uso Mantenimiento de Usuario:
Tabla 08: Especificación del Caso de Uso Mantenimiento de Usuario.
CASO DE USO: MANTENIMIENTO USUARIO

ACTOR: ADMINISTRADOR DE SISTEMAS
PRECONDICIÓN: EL ADMINISTRADOR DE SISTEMAS HA SIDO REGISTRADO EN
EL SISTEMA
POSCONDICIÓN: EL ADMINISTRADOR DE SISTEMAS HA SIDO ADMITIDO POR EL
SISTEMA
FLUJO BÁSICO
ACTOR SISTEMA

Administrador de Sistemas ingresa a Mantenimiento Usuario.
la opción seguridad.
2. El Administrador de Sistemas elige la

opción a trabajar ingresando al botón 2. El Sistema muestra la pantalla que
que desea trabajar, estos son: el actor desea trabajar.
-“Nuevo”
-“Buscar”
-“Editar”
-“Eliminar”
3. El Administrador de Sistemas termina3.El Sistema guarda los datos modificados

con la opción a trabajar y concluye y cierra la sesión del Administrador y el C.U.
cerrando sesión. termina
FLUJOS ALTERNATIVOS
2.1 Si El Administrador elige la opción “Nuevo “el sistema mostrará la pantalla para
crear una nueva cuenta de usuario y una contraseña para éste, el administrador
ingresará los datos del nuevo usuario en el sistema, además podrá configurar
los permisos necesarios para cada usuario que configure, se guardará su
información en el sistema y quedará registrado como un nuevo usuario con
admisión al sistema.
2.2 Si El Administrador elige la opción “Buscar“ el sistema mostrará la pantalla para
buscar a los usuarios registrados en el sistema dependiendo del tipo de
búsqueda el sistema mostrará el pedido del administrador y guardará los
cambios hechos por el administrador.
Página 62
2.3 Si El Administrador elige la opción “Editar “el sistema mostrará la pantalla para
modificar las cuentas de los usuarios, en esta pantalla el administrador podrá
cambiar el nombre y contraseña de los usuarios, así como también modificar
el tipo de usuario.
2.4 Si El Administrador elige la opción “Eliminar “el sistema mostrará la pantalla

para eliminar a los usuarios del sistema.

3.12.3. Modelo Detallado de Requerimientos del Caso de Uso Mantenimiento
Doctor:
Gráfico 17
Nuevo Doctor
<<extend>>
Usuario
(f rom CUS_ATENCION_HOSPITAL)
...)
Buscar Doctor <<extend>> Mostrar Doctor
<<include>>
<<include>>
Modificar Doctor
Grabar Doctor
Administrador
(f rom CUS_ATENCION_HOSPITAL)
Eliminar Doctor <<extend>>
Página 63
Especificación de Caso de Uso Mantenimiento de Doctor.
Tabla 09: Especificación del Caso de Uso Mantenimiento de Doctor.
CASO DE USO: MANTENIMIENTO DOCTOR

ACTOR: ADMINISTRADOR.
PRECONDICIÓN: EL ADMINISTRADOR HA SIDO REGISTRADO EN EL SISTEMA
POSCONDICIÓN: EL ADMINISTRADOR HA SIDO ADMITIDO POR EL SISTEMA
FLUJO BÁSICO
ACTOR SISTEMA

Administrador ingresa a la opción Mantenimiento Doctor.
Mantenimiento Doctor.
2. El Encargado de Admisión elige la

opción a trabajar Seleccionando al 2. El Sistema muestra la pantalla que el
botón que desea trabajar, estos son: actor desea trabajar.
-“Nuevo”
-“Buscar”
-“Editar”
-“Eliminar”
3. El Encargado de Admisión termina 3.El Sistema guarda los datos y cierra la

con la opción a trabajar y concluye sesión del Administrador y el C.U. termina
cerrando sesión.
FLUJOS ALTERNATIVOS
2.1 Si El Administrador del Sistema elige la opción “Nuevo “el sistema mostrará la
pantalla para registrar un nuevo Doctor en el sistema, el Administrador ingresará
los datos del nuevo Doctor en el sistema, se guardará su información en el sistema
y quedará registrado como un nuevo Doctor en el sistema.
2.2 Si El Administrador del Sistema elige la opción “Buscar “el sistema mostrará la
pantalla para buscar Doctor registrados en el sistema dependiendo del tipo de
búsqueda solicitada por el encargado de Admisión, el sistema mostrará a los
Doctores registrados y guardará los cambios realizados.
2.3 Si El Administrador del Sistema elige la opción “Editar “el sistema mostrará la
pantalla para modificar los datos del Doctor, en esta pantalla el Administrador
podrá cambiar los datos del Doctor, luego el sistema guardará los cambios
realizados.
2.4 Si El Administrador elige la opción “Eliminar “el sistema mostrará la pantalla para
eliminar a al Doctor registrado en el sistema.
Página 64
3.12.4. Modelo Detallado de Requerimientos del Caso de Uso Mantenimiento
Paciente
Gráfico 18
Nuevo Paciente Enviar a Triaje
<<extend>>
<<extend>>
Usuario Buscar Paciente Mostrar Paciente
<<extend>>
<<include>>
Modificar Paciente Grabar Paciente
Encargado de <<include>>
Admision <<extend>>
Eliminar Paciente
Página 65
Especificación del Caso de Uso Mantenimiento de Paciente:
CASO DE USO: MANTENIMIENTO PACIENTE

ACTOR: ENCARGADO DE ADMISION.
PRECONDICIÓN: EL ENCARGADO DE ADMISIÓN HA SIDO REGISTRADO EN EL
SISTEMA
POSCONDICIÓN: EL ENCARGADO DE ADMISION HA SIDO ADMITIDO POR EL
SISTEMA
FLUJO BÁSICO
ACTOR SISTEMA

Encargado de Admisión ingresa a la Mantenimiento Paciente.
opción Atención.

opción a trabajar ingresando al botón 2. El Sistema muestra la pantalla que el
que desea trabajar, estos son: actor desea trabajar.
-“Nuevo”
-“Buscar”
-“Editar”
-“Eliminar”
3. El Encargado de Admisión termina 3.El Sistema guarda los datos modificados

con la opción a trabajar y concluye y cierra la sesión del Encargado de
cerrando sesión. Admisión y el C.U. termina
FLUJOS ALTERNATIVOS
2.1 Si El Encargado de Admisión elige la opción “Nuevo “el sistema mostrará la

pantalla para registrar un nuevo Paciente en el sistema, el encargado de Admisión
ingresará los datos del nuevo Paciente en el sistema, se guardará su información
en el sistema y quedará registrado como un nuevo Paciente en el sistema.
2.2 Si El Encargado de Admisión elige la opción “Buscar “el sistema mostrará la
pantalla para buscar a los Pacientes registrados en el sistema dependiendo del
tipo de búsqueda solicitada por el encargado de Admisión, el sistema mostrará a
los Pacientes registrados y guardará los cambios realizados.
Página 66
2.3 Si El Encargado de Admisión elige la opción “Editar “el sistema mostrará la pantalla
para modificar los datos del Paciente, en esta pantalla el encargado de Admisión
podrá cambiar los datos del Paciente, luego el sistema guardará los cambios
realizados.
2.4 Si El Encargado de Admisión elige la opción “Eliminar “el sistema mostrará la
pantalla para eliminar a al Paciente registrado en el sistema.
Tabla 10: Especificación del Caso de Uso Mantenimiento de Paciente.

3.12.5. Modelo Detallado de Requerimientos del Caso de Uso enviar Paciente a

Triaje:
Gráfico 19
Bus car Paciente
<<extend>>
Us uario
Enviar a Triaje
<<extend>>
Encargado de
Admision
Cancelar
Página 67
Especificación del Caso de Uso Enviar Paciente a Triaje:
Tabla 11: Especificación del Caso de Uso Enviar Paciente a Triaje:
CASO DE USO: ENVIAR PACIENTE A TRIAJE.

ACTOR: ENCARGADO DE ADMISION.
PRECONDICIÓN: EL ENCARGADO DE ADMISIÓN HA SIDO REGISTRADO EN EL
SISTEMA
POSCONDICIÓN: EL ENCARGADO DE ADMISION HA SIDO ADMITIDO POR EL
SISTEMA
FLUJO BÁSICO
ACTOR SISTEMA
1. EL C.U empieza cuando el Encargado 1. El Sistema muestra la pantalla de

de Admisión ingresa a la opción Paciente.
Atención, SubOpción Admisión.

opción a trabajar ingresando al botón
2. El Sistema muestra la pantalla que el
que desea trabajar, estos son: actor desea trabajar.
-“Buscar”
-“Enviar”
3. El Encargado de Admisión termina 3.El Sistema envía los datos y el C.U.

con la opción a trabajar y concluye termina
enviando los datos.
FLUJOS ALTERNATIVOS
2.1 Si El Encargado de Admisión elige la opción “Buscar “el sistema mostrará la
pantalla para buscar a los Pacientes registrados en el sistema dependiendo del
tipo de búsqueda solicitada por el encargado de Admisión, el sistema mostrará a
los Pacientes registrados y retornará los datos del paciente para que sean
enviados a Triaje.
2.2 Si El Encargado de Admisión elige la opción “enviar “el sistema mostrará la pantalla
si se desea enviar los datos del Paciente a Triaje.
2.3 Si El Encargado de Admisión elige la opción “cancelar “el sistema mostrará la
pantalla para cancelar los datos del Paciente, en esta pantalla el encargado de
Admisión Cancelar el Envío de Datos.
Fuente. Elaboración Propia.
Página 68
3.12.6. Modelo Detallado de Requerimiento del Caso de Uso de Seguimiento
enviar Paciente a Consultorio Externo:
Gráfico 20
Actualizar
<<include>>
Us uario
Enviar Cons ultorio Externo
Encargado de
Triaje
Eliminar
Página 69
Especificación del Caso de Uso de Seguimiento Enviar Paciente a Consultorio Externo:
Tabla 12: Especificación Seguimiento Enviar Paciente a Consultorio E.

CASO DE USO: ENVIAR PACIENTE A CONSULTORIO EXTERNO.
ACTOR: ENCARGADO DE TRIAJE.
PRECONDICIÓN: EL ENCARGADO DE TRIAJE HA SIDO REGISTRADO EN EL
SISTEMA
POSCONDICIÓN: EL ENCARGADO DE TRIAJE HA SIDO ADMITIDO POR EL
SISTEMA
FLUJO BÁSICO
ACTOR SISTEMA

Encargado de Admisión ingresa a la Mantenimiento Triaje.
opción Atención, SubOpción Triaje.
2. El Encargado de Triaje elige la 2. El Sistema muestra la pantalla que el

opción a trabajar ingresando al botón actor desea trabajar.
que desea trabajar, estos son:
-“Actualizar”
-“Enviar Consultorio Externo”
-“Eliminar” 3.El Sistema envía los datos y el C.U.
termina
3. El Encargado de triaje termina con la
opción a trabajar y concluye enviando
los datos.
FLUJOS ALTERNATIVOS
2.1 Si El Encargado de Triaje elige la opción “Actualizar “el sistema mostrará los datos
de los Pacientes que se encuentran en espera para su posterior atención.
2.2 Si El Encargado de Triaje elige la opción “Eliminar “se eliminaran los datos que no
se desean enviar a consultorio externo.
2.3 Si El Encargado de Triaje elige la opción “Enviar “el sistema mostrará la pantalla
para enviar los datos del Paciente a consultorio externo.
Página 70
3.12.7. Modelo Detallado de Requerimientos del Caso de Uso Registrar Paciente
en Consultorio Externo:
Gráfico 21
Actualizar
Usuario
<<include>>
<<extend>>
Grabar
Doctor
Cancelar
Especificación del Caso de Uso Registrar Paciente en Consultorio

Externo:
Tabla 13: Especificación del Caso de Uso Registrar Paciente en
Consultorio Externo.
CASO DE USO: REGISTRAR PACIENTE EN CONSULTORIO EXTERNO.

ACTOR: DOCTOR.
PRECONDICIÓN: EL DOCTOR HA SIDO REGISTRADO EN EL SISTEMA
POSCONDICIÓN: EL DOCTOR HA SIDO ADMITIDO POR EL SISTEMA
FLUJO BÁSICO
ACTOR SISTEMA
1. EL C.U empieza cuando el Encargado 1. El Sistema muestra la pantalla de

de Admisión ingresa a la opción Mantenimiento Consultorio.
Atención, Opción Consultorio.
Página 71
2. El Usuario Doctor elige la opción a 2. El Sistema muestra la pantalla que el
trabajar ingresando al botón que actor desea trabajar.
desea trabajar, estos son:
-“Actualizar”
-“Grabar
-“Cancelar”
3. El Doctor termina con la opción a 3. El Sistema guarda los datos y cierra la

trabajar y concluye cerrando sesión. sesión el Doctor y el C.U. termina
FLUJOS ALTERNATIVOS
2.1 Si El Usuario Doctor elige la opción “Actualizar “el sistema mostrará los datos de
los Pacientes que se encuentran en espera para su atención.
2.2 Si El Usuario Doctor elige la opción “Grabar “se guardaran los datos de Diagnóstico
del realizado por el Doctor.
2.3 Si El Encargado de Triaje elige la opción “Cancelar “el sistema mostrará la pantalla
para Cancelar los Datos a Grabar.
Página 72
3.13. Diagramas de Actividades de los Casos de Usos de Sistemas.
En un diagrama de actividades se representan los flujos de trabajo en el sistema.
3.13.1. Diagrama de Actividad Iniciar Sesión:

Gráfico 22

3.13.2. Diagrama Actividades Mantenimiento de Usuario
3.13.2.1. Diagrama de Actividad Nuevo Usuario
Gráfico 23
Página 73
3.13.2.2. Diagrama de Actividades Buscar Usuario:
Fuente 24

3.13.2.3. Diagrama Actividades del Caso de Uso Modificar Usuario:
Gráfico 25

Página 74
3.13.2.4. Diagrama de Actividades de Caso de Uso Eliminar Usuario:
Gráfico 26

3.13.3. Diagrama de Actividad Mantenimiento de Paciente:
3.13.3.1. Diagrama de Actividad Nuevo Paciente
Gráfico 27
Página 75
3.13.3.2. Diagrama de Actividad Buscar Paciente
Gráfico 28

3.13.3.3. Diagrama de Actividad Modificar Paciente:
Gráfico 29
Página 76
3.13.3.4. Diagrama de Actividad Eliminar Paciente:
Gráfico 30
3.13.4. Diagrama de Actividad Mantenimiento de Doctor:

3.13.4.1. Diagrama de Actividad Nuevo Doctor:
Gráfico 31

Página 77
3.13.4.2. Diagrama de Actividad Buscar Doctor:
Gráfico 32
3.13.4.3. Diagrama de Actividad Modificar Doctor:

Gráfico 33
Página 78
3.13.4.4. Diagrama de Actividad Eliminar Doctor:
Grafico 34
3.13.5. Diagrama de Actividad Enviar Datos de Paciente a Triaje (Diagnóstico de

Paciente)
Gráfico 35
Página 79
3.13.6. Diagrama de Actividad Enviar datos con Diagnóstico de Pacientes a
Consultorio Externo:
Gráfico 36
3.13.7. Diagrama de Actividades Registrar Paciente en Consultorio Externo:
Gráfico 37
Página 80
3.14. Diagramas de Secuencia.
3.14.1. Diagrama de Secuencia Iniciar Sesión:
Gráfico 38
: Usuario : Iniciar Sesion : CAceptar Sesion : EUsuario : CCancelar Sesion : IMensaje Sesion : CAceptar Sesion : IMenuPrincipal
1:
2:
3:
4:
5:
6:
7:
8:
9:
10
1: Ingresar Datos 6: Cargar Mensaje

2: Capturar Datos 7: Mostrar Mensaje
3: Validar Datos 8: Evaluar Mensaje
4: Respuesta 9: Cargar Pantalla Principal
5: Evaluar Respuesta 10: Cancelar Operación
Página 81
: Encargado de : IMenú Principal : CAdmisión : IMantenimiento Paciente : CNuevo : IMantenimiento Paciente : EPaciente : CGuardar : IMensaje Guardar : CAceptar Mensaje: IMantenimiento Paciente : CCerrar : IMenú Principal
Gráfico 39
Admisión
1:
2:
3:
4:
5:

6:
1: Ingresar al Menú Principal

2: Seleccionar Opción Admsión 7:
3: Cargar Pantalla Matenimiento Paciente
4: Seleccionar Botón Nuevo
5: Carga Pantalla Mantenimiento Paciente 8:
6: Ingresar Datos de Alumno
Página 82
7: Validar Datos
8: Recibir Respuesta
9: Evaluar Respuesta
10: Cargar Mensaje Guardar 9:
11: Seleccionar Botón Aceptar
12: Cargar Pantalla Paciente 10:
3.14.2. Diagrama de Secuencia Nuevo Paciente:
13: Seleccionar Botón Cerrar

14: Cargar Menú Principal
11:
12.
13:
14:
Gráfico 40
: Encargado de : IMenú Principal : CAdmisión : IMantenimiento Paciente : CBuscar : IBuscar Paciente : CAceptar Buscar : EPaciente : IBuscar Paciente : CCerrar : IMenú Principal
Admisión
1:
2:
3:

4:
5:
Página 83
6:
1: Ingresar Menú Principal

2: Seleccionar Opciónn Admision 7:
3: Cargar Pantalla Mantenimiento Paciente
3.14.3. Diagrama de Secuencia Buscar Paciente:
4: Seleccionar Botón Buscar Paciente

5: Cargar Pantalla Buscar Paciente
6: Validar Datos 8:
8: Evaluar Mensaje
9: Seleccioar Botón Aceptar Buscar
10: Cargar Pantallar Buscar Paciente
11. Seleccionarr Botón Cerrar
12 Cargar Pantalla Menú Principal 9:
10:
11:
12:
: Encargado de : IMenú Principal : CAdmisión : IMantenimiento Paciente : CBuscar : IBuscar Paciente : CAceptar Buscar : EPaciente : IBuscar Paciente : CRetorna datos : IMantenimiento Paciente : CModificar : EPaciente : IMensaje Modificar : CAceptar Mensaje: IMantenimiento Paciente
Gráfico 41
Admisión
1:
2:
3:
4:
5:
6:

1: Ingresar Pantalla Menú Principal
2: Seleccionar Opción Admisión 7:
3: Cargar Pantalla Mantenimiento de Paciente
4: Seleccionar Botón Buscar
5: Cargar Pantalla Buscar Paciente 8:
7: Validar Datos
Página 84
9. Evaluar Mensaje 9:
11. Seleccionar Botón Retornar Datos 10:
12. Cargar Pantalla Mantenimiento Paciente
13: Seleccionar Boton Modif icar
14: Validar Datos
15. Recibir Respuesta 11:
16: Evaluar Mensaje
17 Cargar Pantalla Mensaje Modificar
18: Seleccionar Botón Aceptar Mensaje 12:
3.14.4. Diagrama de Secuencia Modificar Paciente:

13:
14:
15:
16:
17:
18:
19:
: Encargado de : IMenú Principal : CAdmisión : IMantenimiento Paciente : CBuscar : IBuscar Paciente : CAceptar Buscar : EPaciente : IBuscar Paciente : CRetorna datos : IMantenimiento Paciente : CEliminar : EPaciente : IMensaje Eliminar : CAceptar Mensaje: IMantenimiento Paciente
Admisión
Grafico 42
1:
2:
3:
4:
5:
6:
7:

1: Ingresar Pantalla Menú Principal
2: Seleccionar Opción Admisión 8:
Página 85
6: Seleccionar Botón Buscar 9:
7: Validar Datos 10:
9. Evaluar Mensaje
11. Seleccionar Botón Retornar Datos
12. Cargar Pantalla Mantenimiento Paciente
3.14.5. Diagrama de Secuencia Eliminar Paciente:
13: Seleccionar Boton Elliminar 12:

14: Validar Datos
15. Recibir Respuesta
16: Evaluar Mensaje 13.
17. Cargar Pantalla Mensaje Eliminar
18: Seleccionar Botón Aceptar Mensaje 14:
15.
16:
17:
18:
19:
Grafico 43
: Encargado de : IMenú Principal : CAdmisión : IMantenimiento Paciente : CBuscar : IBuscar Paciente : CAceptar Buscar : EPaciente : IBuscar Paciente : CRetorna datos : IMantenimiento Paciente: CEnviar Consultorio : IMensaje Enviar : CAceptar Mensaje: IMantenimiento Paciente
Admisión
1:
2:
3:
4:
5:

6:
Página 86
7:
1: Cargar Pantalla Menú Principal
2: Seleccionar Opción Admisión
4: Seleccinar Botón Buscar 8:
6: Seleccionar Botón Aceptar Buscar
7: Validar Datos
8: Recibir Respuesta 9:
9. Evaluar Mensaje
3.14.6. Diagrama de Secuencia Enviar Datos a Triaje

11: Seleccionar Botón Retornar Datos de Paciente
13: Seleccionar Botón Enviar a Triaje
14: Cargar Pantalla Mensaje Enviar 11:
15: Seleccionar Botón Aceptar Mensaje
16. Cargar Pantalla Mantenimiento Paciente 12.
13.
14:
15.
16:
: Encargado de : IMenú Principal : CTriaje : ITriaje : CEnviar Consultorio : EDetalle Historia : IMensaje Enviar : CAceptar Mensaje : ITriaje : CActualizar : ITriaje : CEliminar
Gráfico 44
Triaje
1:
2:
3:
4:
5:
1: Cargar Pantalla Principal
2: Seleccionar Opción Triaje
3: Cargar Pantalla Triaje

4: Seleccionar Botón Enviar Consultorio 6:
5: Validadar Datos
6: Esperar Respuesta
7: Evaluar Mensaje
8: Caragar Pantalla Mensaje Enviar
Página 87
9: Aceptar Mensaje 7:
11: Seleccionar Botón Actualizar 8:
13: Seleccionar Botón Eliminar 9:
14: Eliminar Registro Seleccionado
10:
11:
12:
13:
14:
3.14.7. Diagrama de Secuencia Seguimiento Enviar Datos a Consultorio:
: Doctor : IMenú Principal : CConsultorio : IConsultorio Externo : CGrabar Atención : EDetalle Historia : IMensaje Guardar : CAceptar Mensaje : IConsultorio Externo : CActualizar : IConsultorio Externo : CCancelar
Gráfico 45
1:
2:
3:
4.
5:
Página 88
6:

7:
1: Cargar Pantalla Principal
2: Seleccionar Opción Consultorio
3: Cargar Pantalla Consultorio Externo
4: Ingresar Boton Grabar PacienteConsultorio 8:
5: Validadar Datos
6: Esperar Respuesta
7: Evaluar Mensaje
8: Cargar Pantalla Mensaje Guardar 9:
9: Aceptar Mensaje
10: Cargar Pantalla Consultorio Externo
11: Seleccionar Botón Actualizar 10.
12: Cargar Pantalla Consultorio Externo Con Datos.
13 Seleccionar Botón Cancelar.
14 Cancelar datos
11:
12.
13:
14:
3.14.8. Diagrama de Secuencia Registrar Paciente en Consultorio Externo:
3.15. Diagrama de clases.
Gráfico 46
Página 89
CAPÍTULO IV
RESULTADOS
Página 90
4.1. Prototipos del Sistema:
4.1.1. Iniciar Sesión
El Formulario Inicio Sesión permitirá el acceso al sistema.
Una vez Registrado el Usuario por el administrador, el usuario podrá
acceder al Sistema teniendo dos opciones, como Personal Administrativo
y/o Doctor ya que los accesos están restringidos y solo tendrá acceso y
manejo a parte del sistema de control de Historias clínicas.
Gráfico 47
Página 91
4.1.2. Interfaz Menú Principal
La pantalla Principal es la parte principal del sistema, en donde el
administrador del sistema tendrá opciones de Mantenimiento, Procesos,
Configuraciones, Reportes y Ayuda para el mejor Manejo del mismo.
Gráfico 48
Página 92
4.1.3. Interfaz Mantenimiento Doctor
Este es el Formulario Mantenimiento de Doctor, aquí el Administrador del
sistema podrá realizar el mantenimiento del Doctor y podrá configurar el
área a la que pertenecerá registrando además el acceso al Sistema para
la atención de los pacientes.
Gráfico 49
Página 93
4.1.4. Interfaz Mantenimiento Paciente
En esta parte del Formulario es donde se iniciará el registro al paciente
por parte del Usuario encargado (Registrado por el Administrador del
Sistema) y se podrá realizar la consulta para que estos datos puedan ser
enviados al área de Triaje.
Gráfico 50
Página 94
4.1.5. Interfaz Buscar Paciente
Este Formulario nos permitirá realizar la búsqueda del Paciente teniendo
como opción Búsqueda de Paciente por Número de Historia o por
Nombres y Apellidos.
Una vez encontrados los datos del paciente se retornará seleccionando
los datos para luego ser enviados al área de Triaje.
Gráfico 51
Página 95
4.1.6. Interfaz Seguimiento de Paciente en Triaje
En este formulario se procederá a llenar datos del diagnóstico realizados

por el Encargado del área de Triaje, se Registrará el Peso, Temperatura,
Presión Arterial y Talla. Una vez llenado estos datos se enviarán los datos
a Consultorio Externo o al área donde se atenderá el Paciente.
Gráfico 52
Página 96
4.1.7. Interfaz Mantenimiento Atención de Paciente
Este es el Formulario que permitirá concluir el llenado de una historia
clínica. El Usuario encargado de esta parte del Sistema (Doctor) llenará
los datos de Diagnósticos del paciente como el motivo de la consulta,
tiempo de enfermedad, examen clínico, Diagnóstico, Indicaciones y
Tratamiento y Exámenes complementarios.
Hasta aquí hemos terminado con registrar y terminar con la Historia
Clínica del Paciente, para luego obtener los reportes Correspondientes.
Gráfico 53
Página 97
4.1.8. Interfaz Mantenimiento Usuarios.
Mediante este Formulario el Administrador del Sistema podrá registrar el
usuario y el rol correspondiente para el acceso del Sistema del Menú
Principal.
Gráfico 54
Página 98
4.2. Codificación del Sistema.
4.2.1. Código del Formulario Inicio de Sesión.
Página 99
4.2.2. Código del Formulario Paciente Admisión.
Página
100
4.2.3. Código del Formulario Triaje.
Página
101
4.2.4. Código del Formulario Consultorio Externo.
4.2.5. Código del Formulario Grabar Usuario.
Página
102
Discusión
Esta investigación tuvo como propósito identificar y describir aquellos procesos que no
tenían eficiencia en la búsqueda y minimización de duplicidad de documentaria de las
historias clínicas del área admisión en el centro médico municipal de Mala, además de
resolver la agilización de atención en los pacientes.
Este proyecto contribuyó a que los responsables de las diferentes áreas puedan
trabajar de una nueva forma, y esto se logró recogiendo todos los datos y necesidades
de todos los usuarios implicados a fin de poder avanzar en el desarrollo del software
que debía culminar en la implantación.
De esta forma se consiguió terminar el proyecto que permite el registro de Historias

clínicas así como la atención de pacientes en los diferentes consultorios externos, ya
que el sistema creado es un sistema con enfoque Cliente/Servidor.
El objetivo de este proyecto fue de conseguir crear un sistema ágil y preciso que llegara
a realizar con exactitud las búsquedas, consultas y reportes de los pacientes atendidos
y registrados en el sistema.
El objetivo final es aumentar la calidad, la eficacia y la eficiencia de los procesos que

se realizan en el Centro Médico Municipal.
Página
103
Conclusiones
 Con la Implementación del sistema se agilizó el proceso de búsqueda de Historias

Clínicas logrando la eficiencia y eficacia en la atención de los pacientes.
 El Registros de Historias Clínicas permitió un mejor control en los procesos

administrativos.
 Se optimizó los tiempos de respuestas de las Historias Clínicas de los Pacientes.
 Con la automatización de los procesos se redujo la duplicidad de las Historias

Clínicas.
Página
104
Recomendaciones
 Se deberá de realizar capacitación continua a todo el personal involucrado en el

manejo del Sistema.
 Para la seguridad de la información, se recomienda la generación de backups

diarios.
 Se recomienda someter el sistema a pruebas más rigurosas, queda abierta la

posibilidad de adaptarla a posibles requerimientos que solicite la institución que
adquiera el software.
 Es necesario que los usuarios del sistema se involucren con el mismo, de la forma
que puedan aportar sugerencias para la mejora del sistema y así asegurar su
continua utilización.
Página
105
Referencias Bibliográficas
 Bibliografías
 Alejandro E. Caballero Romero, Metodología de la Investigación Científica, 1ª ed, Perú, Ob_cit,

1991, 104-105 pp
 Hernández Sampieri, Roberto. Metodología de la Investigación, 3° ed, México D.F., Editorial

Mc. Graw Hill. 2003. 705pp.
 E Yourdon, Análisis Estructurado, Prentice Hall, 1990.
 E. Kendall Kenneth y E. kendall Julie Análisis y Diseño de Sistemas, Sexta Edición Pearson
Educación, México 2005.
 Páginas Web
 Manuel Peralta. Sistema de Información. En:

http://www.monografias.com/trabajos7/sisinf/sisinf.shtml.México, 1999, 12pp.
 Meléndez, Ríos David. Gestión Administrativa y sus procesos de gestión, En:

http://www.getec.etsit.upm.es/docencia/gproyectos/historia/evolucion.htm, Madrid, 2002,
pp.
 Martin J. Dürst.Character Model for the World Wide Web. En:

http://www.w3c.es/Consorcio/historia.Chile. 2004, pp.16.
 Getec .Gestión de Proyectos.En:

http://www.getec.etsit.upm.es/docencia/gproyectos/gproyectos.htm/ España, 2004, 6pp.
 Daedalus. Gestión Sistemas. En:

http://www.daedalus.es/AreasISGestion-E.php España, 2004, 6pp.
 www.clikear.com - Tutorial de Desarrolló Orientado a Objetos con UML. En:

http://www.clikear.com/manuales/uml/introduccion.as. Argentina, 2005, 12pp.
 Enterprise Project Management (EPM) Solution Generando valor de negocios a través de:
http://www.microsoft.com/latam/office/project/prodinfo/epm/overview.msp
En: EE.UU 2005, 12pp.
Página
106
ANEXOS
Página
107
1. ANEXO A: Diagrama de Gantt.
Gráfico 55
Página
108
Página
109
2. ANEXO B: Modelo De Proceso Propuesto
Gráfico 55
Servidor de Base de Datos
Ginecología
Admisión
Odontología
Consultorio Medicina
Triaje General
Página
110
3. ANEXO C: FOTOS DEL CENTRO MEDICO MUNICIPAL
3.1. Centro Médico Municipal.
3.2. Área de Caja.
Página
111
3.3. Área de Secretaria.
3.4. Área de Administración.
Página
112
3.5. Área de Admisión.
Página
113
3.6. Área de Triaje
Página
114
3.7. Área de Consultorio Medicina General.
3.8. Área de Ginecología.
Página
115
3.9. Área de Odontología.
Página
116
ANEXO D: MATRIZ DE CONSISTENCIA
TITULO: Desarrollo de un Sistema de control de Historia Clínicas y su mejoramiento en la ubicación y minimización de

duplicidad documentaria en el área de admisión del Centro Médico Municipal de Mala – 2015.
PROBLEMA OBJETIVO HIPOTESIS VARIABLE INDICADORES
GENERAL GENERAL GENERAL INDEPENDIENTE

¿En qué medida el Implementar un sistema H= La Implantación de X= Sistema de X1=Funcionalidad
Desarrollo de un sistema de control de historia un sistema de control de Control de X2=Confiabilidad
de control de historias clínicas y su historias clínicas influirá Historias Clínicas.
clínicas mejorará en la mejoramiento en la en la ubicación y
ubicación y minimización ubicación y minimización minimización de DEPENDIENTE
de duplicidad de duplicidad duplicidad documentaria Y= Mejoramiento en
documentaria en el área documentaria en el área en el área de admisión la Ubicación y Y1=Eficiencia
de admisión del centro de admisión del centro del centro médico Minimización de Y2= Eficacia
médico municipal de médico municipal de municipal de Mala – duplicidad
Mala – 2015? Mala – 2015. 2015. documentaria en
el área de
admisión.
ESPECIFÍCAS ESPECIFÍCAS ESPECIFÍCAS
a. ¿En qué medida la a. Implementar un H1: Si se implementara
Funcionalidad del sistema de historia un sistema de historia
Página
117
sistema de control de clínica y su clínica influirá en la
historias clínicas mejoramiento en la ubicación de los
mejorará en la ubicación ubicación de los documentos
y minimización de documentos relacionados.
duplicidad documentaria relacionados.
en el área de admisión
del centro médico b. Implementar un H2: Si se implementara
municipal de Mala – sistema de historia un sistema de historia
2015? clínica y su clínica influirá en la
b. a. ¿En qué medida la mejoramiento en la minimización de
Confiabilidad del sistema minimización de duplicidad
de control de historias duplicidad documentaria.
clínicas mejorará en la documentaria.
ubicación y minimización
de duplicidad
documentaria en el área
de admisión del centro
médico municipal de
Mala – 2015?
Página
118

Universidad Peruana de Integración Global: Facultad de Ingeniería de Sistemas E Informática

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Universidad Peruana de Integración Global: Facultad de Ingeniería de Sistemas E Informática

Cargado por

Copyright:

Formatos disponibles

UNIVERSIDAD PERUANA DE INTEGRACIÓN GLOBAL

FACULTAD DE INGENIERÍA DE SISTEMAS E INFORMÁTICA

Desarrollo de un Sistema de control de Historia Clínicas y su

PARA OPTAR EL TÍTULO PROFESIONAL DE INGENIERO DE

AUTOR: CHUMPITAZ AVALOS, Victor Manuel

ASESOR: MBA ING. CARLOS ZORRILLA VARGAS

Al Divino hacedor por darnos la vida, a mis padres,

A Dios: Por darnos la luz de la vida y la salud. A la Universidad Peruana de Integración

La investigación se realizó planteando como problema general la Ineficiencia del control de

El sistema que se implementa se desarrolla en el Lenguaje de Programación Visual Basic 6.0 y

ANEXO A: DIAGRAMA DE GANTT…………………………………….................... 108

ANEXO B: MODELO DE PROCESO PROPUESTO……………………………….. 110

ANEXO C: FOTOS DEL CENTRO MÉDICO MUNICIPAL…………………………. 111

ANEXO D: MATRIZ DE CONSISTENCIA……………………………………………. 117

Tabla 01: Diagramas de Caso de Uso de Negocio...……………………………….. 30

Tabla 02. Modelo de Caso de Uso del Negocio……..………………………………. 32

Tabla 03: Elementos del Diagrama de Actividad…..………………………………... 33

Tabla 04: Elementos del Diagrama de Secuencia…..………………………………. 35

Tabla 05: Población de los Centros de Salud de Mala……………………………… 51

Tabla 06: Determinación del tamaño de la muestra de Paciente………………….. 52

Tabla 07: Especificación del Caso de Uso Iniciar Sesión…………………………... 60

Tabla 08: Especificación del Caso de Uso Mantenimiento de Usuario……………. 62

Tabla 09: Especificación del Caso de Uso Mantenimiento de Doctor……………… 64

Tabla 10: Especificación del Caso de Uso Mantenimiento de Paciente…………… 66

Tabla 11: Especificación del Caso de Uso Enviar Paciente a Triaje……………….. 68

Tabla 13: Especificación de Caso de Uso Registrar Paciente en Consultorio E…... 71

Gráfico 01: Faces del RUP………………………………………………………………. 24

Gráfico 02: UML Análisis y Diseño de Sistemas I…………………………………….. 26

Gráfico 03: Jerarquía de los Diagramas UML…………………………………………. 28

Gráfico 04: Diagrama de Clase…………………………………………………………. 36

Gráfico 05: Diagrama de Objetos………………………………………………………. 37

Gráfico 06: Diagrama de Estados………………………………………………………. 38

Gráfico 07: Diagrama de Colaboración………………………………………………… 39

Gráfico 08: Diagrama de Componentes……………………………………………….. 40

Gráfico 09: Diagrama de Despliegue…………………………………………………… 41

Gráfico 10: Sistema de Administración de Base de Datos…………………………… 43

Gráfico 11: Diagrama Contexto…………………………………………………………. 55

Gráfico 12: Diagrama General Cero......................................................................... 56

Gráfico 13: Diagrama Entidad Relación………………………………………………... 57

Gráfico 14: Modelo de Caso de Uso de Negocio……………………………………… 58

Gráfico 15: Modelo Detallado de Requerimientos CUS Iniciar Sesión……………… 60

Gráfico 16: Modelo Detallado de Requerimientos CUS Mantenimiento Usuario...... 61

Gráfico 17: Modelo Detallado de Requerimientos CUS Mantenimiento Doctor…… 63

Gráfico 18: Modelo Detallado de Requerimientos CUS Mantenimiento Paciente… 65

Gráfico 19: Modelo Detallado de Requerimientos CUS enviar Paciente a Triaje… 67

Gráfico 20: Modelo Detallado de Requerimiento CUS Seguimiento Paciente……. 69

Gráfico 21: Modelo Detallado de Requerimiento CUS Registrar Paciente C. Externo 71

Gráfico 22: Diagrama de Actividad Iniciar Sesión……………………………………. 73

Gráfico 23: Diagrama de Actividad Nuevo Usuario………………………………….. 73

Gráfico 24: Diagrama de Actividad Buscar Usuario…………………………………. 74

Gráfico 26: Diagrama de Actividad Eliminar Usuario……………………………….... 75

Gráfico 27: Diagrama de Actividad Nuevo Paciente………………………………..... 75

Gráfico 28: Diagrama de Actividad Buscar Paciente……………………………........ 76

Gráfico 29: Diagrama de Actividad Modificar Paciente…………………………….... 76

Gráfico 30: Diagrama de Actividad Eliminar Paciente……………………………….. 77

Gráfico 31: Diagrama de Actividad Nuevo Doctor……………………………………. 77

Gráfico 32: Diagrama de Actividad Buscar Doctor………………………………….... 78

Gráfico 33: Diagrama de Actividad Modificar Doctor………………………………… 78

Gráfico 34: Diagrama de Actividad Eliminar Doctor………………………………….. 79

Gráfico 35: Diagrama de Actividad Enviar Datos de Paciente a Triaje…………….. 79

Gráfico 36: Diagrama de Actividad Enviar Datos a Consultorio Externo…………… 80

Gráfico 37: Diagrama de Actividad de CUS Registrar Paciente en C. Externo…… 80

Gráfico 38: Diagrama de Secuencia Iniciar Sesión…………………………………... 81