Tesis admision municipal_2015_upig

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
Página 12
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 13
CAPÍTULO I
EL PROBLEMA DE
INVESTIGACIÓN

Página 14
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 15
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 16
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 17
CAPÍTULO II
MARCO TEÓRICO

Página 18
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 19
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 20
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 21
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 22
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 23
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 24
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 25
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 26
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 27
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 28
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 29
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 30
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
Actor de Negocio
Algo o alguien externo
al negocio que
interactúa con el
negocio.
Trabajador del Negocio
Rol o conjunto de roles
dentro del negocio. Un
trabajador del negocio
interactúa con otros

Página 31
trabajadores y manipula
entidades del negocio.
Entidad del Negocio
Algo usado por los
trabajadores del
negocio.
Caso de Uso del
Negocio
Una secuencia de
acciones que le negocio
realiza y en el que se
observa un resultado d
valor para un actor de
negocio en particular.
Realización de un Caso
de Uso del Negocio
Una colección de
diagramas para mostrar
como los elementos de
la organización son
utilizados para dar
soporte a los procesos
del negocio.
Unidad Organizacional
Usado para estructurar
el negocio en partes.
Asociación
La línea de
comunicación entre un
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 32
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
Negocio
Gestionar los pedidos de un Cliente
Objetivo
Descripción 1.-
2.-
3.-
4.-
Prioridad
Riesgo
Posibilidades
Tiempo de
Ejecución
Coste Ejecución

Página 33
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 Inicio
Nodo de control que
indica el inicio de un flujo
de control cuando una
actividad es invocada.
Nodo de Fin
Nodo de control que
indica el fin de todos los
flujos dentro de una
actividad. Muestra el fin
de la actividad.
Conector
Usado para separar un
flujo y restablecer su

Página 34
conexión en un
diagrama.
Decisión
Nodo de control que
selecciona entre dos o
más flujos de salida.
Nodo de concurrencia
Nodo de control que
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 35
Tabla 04: Elementos del Diagrama de Secuencia
Línea de Vida
La línea de vida de un
objeto representa la vida
del objeto durante la
interacción. En un
diagrama de secuencia un
objeto se representa
como una línea vertical
punteada.
Activación
Muestra el periodo de
tiempo en el cual el objeto
se encuentra
desarrollando alguna
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 36
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 37
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 38
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 39
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 40
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 41
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 42
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 43
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 44
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 45
 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 46
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 47
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
X1 = Funcionalidad
X11 =Tiempo promedio de
Búsqueda de Historias
Clínicas por día con Sistema /
Tiempo promedio de
Búsqueda de Historias
Clínicas por día sin Sistema.
X2 = Confiabilidad
X21 = Cantidad de Historias
Clínicas Registradas por mes
sin duplicidad con Sistema /
Cantidad de Historias Clínicas
Registradas por mes con
duplicidad sin Sistema

Página 48
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
Y1= Eficiencia
Y11 = Cantidad de pacientes atendidos
por día con Sistema / Cantidad de
pacientes atendidos por día sin
Sistema.
Y2= Eficacia
Y21 = Cantidad de Reportes de
Historias Clínicas Generados por día
con Sistema. / Cantidad de Reportes
de Historias Clínicas Generados por día
sin Sistema.

Página 49
CAPÍTULO III
METODOLOGÍA

Página 50
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 51
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
Mala
EsSalud Centro
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 52
Tabla 06: Determinación del tamaño de la muestra de Pacientes.
Determinación del tamaño de la muestra de Pacientes.
Centros de Salud
TOTAL
Entidades Centro de Salud
Mala
EsSalud Centro Médico
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 53
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 54
 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 55
3.7. Diagrama Contexto
Fuente:ElaboraciónPropia
Gráfico11:DiagramaContexto

Página 56
3.8. Diagrama General Cero.
Gráfico 12: Diagrama General Cero

Página 57
3.9.Diagrama Entidad Relación.
Gráfico 13: Diagrama Entidad Relación.

Página 58
3.10. Modelo de Caso de Uso de Negocio.
Gráfico 14: Modelo de Caso de Uso de Negocio.
Generar Reportes
(fromUSE CASE DEL NEGO...
Encargado de Admisión
(fromACTORES DEL NEGOCIO)
Buscar Historia
Solicitar Atención Médica
Registrar Datos Personales
Paciente
Encargado de Consultorio Externo
Registrar Historia
Encargado de Triaje

Página 59
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 60
 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
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
1. EL C.U empieza cuando el
Usuario desea ingresar al
Sistema
SISTEMA
1. El Sistema muestra la pantalla de
ingreso.
Administrador
Doctor
Encargado de Triaje
Validar Datos
Mostrar Mensaje de Error
Aceptar Ingreso Cargar Sistema
Ingresar Datos
Usuario
Encargado de
Admision
<<include>>
<<extend>>
<<extend>>
<<include>>

Página 61
3.12.2. Modelo Detallado de Requerimientos del Caso de Uso Mantenimiento de
Usuario:
Gráfico 16
Administrador
Mostrar Usuario
Grabar Usuario
Nuevo Usuario
Buscar Usuario
Modificar Usuario
Eliminar Usuario
Usuario
<<include>>
<<include>>
<<extend>>
<<extend>>
<<extend>>
2.El Usuario ingresa su número de
usuario y su contraseña
2. Verifica los datos e ingresa al sistema y
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.

Página 62
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
Administrador de Sistemas ingresa a
la opción seguridad.
2. El Administrador de Sistemas elige la
opción a trabajar ingresando al botón
que desea trabajar, estos son:
-“Nuevo”
-“Buscar”
-“Editar”
-“Eliminar”
3. El Administrador de Sistemas termina
con la opción a trabajar y concluye
cerrando sesión.
SISTEMA
Mantenimiento Usuario.
2. El Sistema muestra la pantalla que
el actor desea trabajar.
3.El Sistema guarda los datos modificados
y cierra la sesión del Administrador y el C.U.
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 63
3.12.3. Modelo Detallado de Requerimientos del Caso de Uso Mantenimiento
Doctor:
Gráfico 17
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.
Mostrar Doctor
Grabar Doctor
Administrador
(f rom CUS_ATENCION_HOSPITAL)
Nuevo Doctor
Buscar Doctor
<<extend>>
Modificar Doctor
<<include>>
<<extend>>
Usuario
(f rom CUS_ATENCION_HOSPITAL)...)
Eliminar Doctor
<<include>>
<<extend>>

Página 64
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
Administrador ingresa a la opción
Mantenimiento Doctor.
2. El Encargado de Admisión elige la
opción a trabajar Seleccionando al
botón que desea trabajar, estos son:
-“Nuevo”
-“Buscar”
-“Editar”
-“Eliminar”
3. El Encargado de Admisión termina
cerrando sesión.
SISTEMA
Mantenimiento Doctor.
2. El Sistema muestra la pantalla que el
actor desea trabajar.
3.El Sistema guarda los datos y cierra la
sesión del Administrador y el C.U. termina
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 65
3.12.4. Modelo Detallado de Requerimientos del Caso de Uso Mantenimiento
Paciente
Gráfico 18
Encargado de
Admision
Mostrar Paciente
Grabar Paciente
Nuevo Paciente
Buscar Paciente
Modificar Paciente
Eliminar Paciente
Usuario
<<extend>>
<<extend>>
<<include>>
<<extend>>
<<include>>
Enviar a Triaje
<<extend>>

Página 66
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
Encargado de Admisión ingresa a la
opción Atención.
-“Nuevo”
-“Buscar”
-“Editar”
-“Eliminar”
cerrando sesión.
SISTEMA
Mantenimiento Paciente.
3.El Sistema guarda los datos modificados
y cierra la sesión del Encargado de
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 67
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
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.
Encargado de
Admision
Buscar Paciente
Enviar a Triaje
<<extend>>
Cancelar
Usuario
<<extend>>

Página 68
Especificación del Caso de Uso Enviar Paciente a Triaje:
Tabla 11: Especificación del Caso de Uso Enviar Paciente a Triaje:
Fuente. Elaboración Propia.
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
1. EL C.U empieza cuando el Encargado
de Admisión ingresa a la opción
Atención, SubOpción Admisión.
-“Buscar”
-“Enviar”
enviando los datos.
SISTEMA
1.El Sistema muestra la pantalla de
Paciente.
2.El Sistema muestra la pantalla que el
3.El Sistema envía los datos y el C.U.
termina
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.

Página 69
3.12.6. Modelo Detallado de Requerimiento del Caso de Uso de Seguimiento
enviar Paciente a Consultorio Externo:
Gráfico 20
Encargado de
Triaje
Usuario
Eliminar
Actualizar
Enviar Consultorio Externo
<<include>>

Página 70
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
Encargado de Admisión ingresa a la
opción Atención, SubOpción Triaje.
2. El Encargado de Triaje elige la
-“Actualizar”
-“Enviar Consultorio Externo”
-“Eliminar”
3. El Encargado de triaje termina con la
opción a trabajar y concluye enviando
los datos.
SISTEMA
Mantenimiento Triaje.
3.El Sistema envía los datos y el C.U.
termina
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 71
3.12.7. Modelo Detallado de Requerimientos del Caso de Uso Registrar Paciente
en Consultorio Externo:
Gráfico 21
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
1. EL C.U empieza cuando el Encargado
de Admisión ingresa a la opción
Atención, Opción Consultorio.
SISTEMA
Mantenimiento Consultorio.
Doctor
Actualizar
Grabar
Usuario
Cancelar
<<include>>
<<extend>>

Página 72
2. El Usuario Doctor elige la opción a
trabajar ingresando al botón que
desea trabajar, estos son:
-“Actualizar”
-“Grabar
-“Cancelar”
3. El Doctor termina con la opción a
trabajar y concluye cerrando sesión.
3. El Sistema guarda los datos y cierra la
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 73
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 74
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 75
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 76
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 77
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 78
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 79
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 80
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 81
3.14. Diagramas de Secuencia.
3.14.1. Diagrama de Secuencia Iniciar Sesión:
Gráfico 38
: Usuario: Usuario : Iniciar Sesion: Iniciar Sesion : CAceptar Sesion: CAceptar Sesion : EUsuario: EUsuario : CCancelar Sesion: CCancelar Sesion : IMensaje Sesion: IMensaje Sesion : CAceptar Sesion: CAceptar Sesion : IMenuPrincipal: IMenuPrincipal
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
1:
2:
3:
4:
5:
3:
6:
7:
8:
9:
7:
10

Página 82
3.14.2. Diagrama de Secuencia Nuevo Paciente:
Gráfico 39
:Encargadode
Admisión
:Encargadode
Admisión
:IMenúPrincipal:IMenúPrincipal:CAdmisión:CAdmisión:IMantenimientoPaciente:IMantenimientoPaciente:CNuevo:CNuevo:IMantenimientoPaciente:IMantenimientoPaciente:EPaciente:EPaciente:CGuardar:CGuardar:IMensajeGuardar:IMensajeGuardar:CAceptarMensaje:CAceptarMensaje:IMantenimientoPaciente:IMantenimientoPaciente:CCerrar:CCerrar:IMenúPrincipal:IMenúPrincipal
1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12.
13:
14:
1:IngresaralMenúPrincipal
2:SeleccionarOpciónAdmsión
3:CargarPantallaMatenimientoPaciente
4:SeleccionarBotónNuevo
5:CargaPantallaMantenimientoPaciente
6:IngresarDatosdeAlumno
7:ValidarDatos
8:RecibirRespuesta
9:EvaluarRespuesta
10:CargarMensajeGuardar
11:SeleccionarBotónAceptar
12:CargarPantallaPaciente
13:SeleccionarBotónCerrar
14:CargarMenúPrincipal

Página 83
3.14.3. Diagrama de Secuencia Buscar Paciente:
Gráfico 40
:Encargadode
Admisión
:Encargadode
Admisión
:IMenúPrincipal:IMenúPrincipal:CAdmisión:CAdmisión:IMantenimientoPaciente:IMantenimientoPaciente:CBuscar:CBuscar:IBuscarPaciente:IBuscarPaciente:CAceptarBuscar:CAceptarBuscar:EPaciente:EPaciente:IBuscarPaciente:IBuscarPaciente:CCerrar:CCerrar:IMenúPrincipal:IMenúPrincipal
1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
1:IngresarMenúPrincipal
2:SeleccionarOpciónnAdmision
3:CargarPantallaMantenimientoPaciente
4:SeleccionarBotónBuscarPaciente
5:CargarPantallaBuscarPaciente
6:ValidarDatos
7:RecibirRespuesta
8:EvaluarMensaje
9:SeleccioarBotónAceptarBuscar
10:CargarPantallarBuscarPaciente
11.SeleccionarrBotónCerrar
12CargarPantallaMenúPrincipal

Página 84
3.14.4. Diagrama de Secuencia Modificar Paciente:
Gráfico 41
:Encargadode
Admisión
:Encargadode
Admisión
:IMenúPrincipal:IMenúPrincipal:CAdmisión:CAdmisión:IMantenimientoPaciente:IMantenimientoPaciente:CBuscar:CBuscar:IBuscarPaciente:IBuscarPaciente:CAceptarBuscar:CAceptarBuscar:EPaciente:EPaciente:IBuscarPaciente:IBuscarPaciente:CRetornadatos:CRetornadatos:IMantenimientoPaciente:IMantenimientoPaciente:CModificar:CModificar:EPaciente:EPaciente:IMensajeModificar:IMensajeModificar:CAceptarMensaje:CAceptarMensaje:IMantenimientoPaciente:IMantenimientoPaciente
1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
15:
16:
17:
18:
19:
1:IngresarPantallaMenúPrincipal
2:SeleccionarOpciónAdmisión
3:CargarPantallaMantenimientodePaciente
4:SeleccionarBotónBuscar
7:ValidarDatos
8:RecibirRespuesta
9.EvaluarMensaje
11.SeleccionarBotónRetornarDatos
12.CargarPantallaMantenimientoPaciente
13:SeleccionarBotonModificar
14:ValidarDatos
15.RecibirRespuesta
16:EvaluarMensaje
17CargarPantallaMensajeModificar
18:SeleccionarBotónAceptarMensaje

Página 85
3.14.5. Diagrama de Secuencia Eliminar Paciente:
Grafico 42
:Encargadode
Admisión
:Encargadode
Admisión
:IMenúPrincipal:IMenúPrincipal:CAdmisión:CAdmisión:IMantenimientoPaciente:IMantenimientoPaciente:CBuscar:CBuscar:IBuscarPaciente:IBuscarPaciente:CAceptarBuscar:CAceptarBuscar:EPaciente:EPaciente:IBuscarPaciente:IBuscarPaciente:CRetornadatos:CRetornadatos:IMantenimientoPaciente:IMantenimientoPaciente:CEliminar:CEliminar:EPaciente:EPaciente:IMensajeEliminar:IMensajeEliminar:CAceptarMensaje:CAceptarMensaje:IMantenimientoPaciente:IMantenimientoPaciente
1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13.
14:
15.
16:
17:
18:
19:
1:IngresarPantallaMenúPrincipal
7:ValidarDatos
8:RecibirRespuesta
9.EvaluarMensaje
11.SeleccionarBotónRetornarDatos
13:SeleccionarBotonElliminar
14:ValidarDatos
15.RecibirRespuesta
16:EvaluarMensaje
17.CargarPantallaMensajeEliminar

Página 86
3.14.6. Diagrama de Secuencia Enviar Datos a Triaje
Grafico 43
:Encargadode
Admisión
:Encargadode
Admisión
:IMenúPrincipal:IMenúPrincipal:CAdmisión:CAdmisión:IMantenimientoPaciente:IMantenimientoPaciente:CBuscar:CBuscar:IBuscarPaciente:IBuscarPaciente:CAceptarBuscar:CAceptarBuscar:EPaciente:EPaciente:IBuscarPaciente:IBuscarPaciente:CRetornadatos:CRetornadatos:IMantenimientoPaciente:IMantenimientoPaciente:CEnviarConsultorio:CEnviarConsultorio:IMensajeEnviar:IMensajeEnviar:CAceptarMensaje:CAceptarMensaje:IMantenimientoPaciente:IMantenimientoPaciente
1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12.
13.
14:
15.
16:
1:CargarPantallaMenúPrincipal
4:SeleccinarBotónBuscar
6:SeleccionarBotónAceptarBuscar
7:ValidarDatos
8:RecibirRespuesta
9.EvaluarMensaje
11:SeleccionarBotónRetornarDatosdePaciente
13:SeleccionarBotónEnviaraTriaje
14:CargarPantallaMensajeEnviar

Página 87
3.14.7. Diagrama de Secuencia Seguimiento Enviar Datos a Consultorio:
Gráfico 44
:Encargadode
Triaje
:Encargadode
Triaje
:IMenúPrincipal:IMenúPrincipal:CTriaje:CTriaje:ITriaje:ITriaje:CEnviarConsultorio:CEnviarConsultorio:EDetalleHistoria:EDetalleHistoria:IMensajeEnviar:IMensajeEnviar:CAceptarMensaje:CAceptarMensaje:ITriaje:ITriaje:CActualizar:CActualizar:ITriaje:ITriaje:CEliminar:CEliminar
1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
1:CargarPantallaPrincipal
2:SeleccionarOpciónTriaje
3:CargarPantallaTriaje
4:SeleccionarBotónEnviarConsultorio
5:ValidadarDatos
6:EsperarRespuesta
7:EvaluarMensaje
8:CaragarPantallaMensajeEnviar
9:AceptarMensaje
11:SeleccionarBotónActualizar
13:SeleccionarBotónEliminar
14:EliminarRegistroSeleccionado

Página 88
3.14.8. Diagrama de Secuencia Registrar Paciente en Consultorio Externo:
Gráfico 45
:Doctor:Doctor:IMenúPrincipal:IMenúPrincipal:CConsultorio:CConsultorio:IConsultorioExterno:IConsultorioExterno:CGrabarAtención:CGrabarAtención:EDetalleHistoria:EDetalleHistoria:IMensajeGuardar:IMensajeGuardar:CAceptarMensaje:CAceptarMensaje:IConsultorioExterno:IConsultorioExterno:CActualizar:CActualizar:IConsultorioExterno:IConsultorioExterno:CCancelar:CCancelar
1:
2:
3:
4.
5:
6:
7:
8:
9:
10.
11:
12.
13:
14:
1:CargarPantallaPrincipal
2:SeleccionarOpciónConsultorio
3:CargarPantallaConsultorioExterno
4:IngresarBotonGrabarPacienteConsultorio
5:ValidadarDatos
6:EsperarRespuesta
7:EvaluarMensaje
8:CargarPantallaMensajeGuardar
9:AceptarMensaje
10:CargarPantallaConsultorioExterno
11:SeleccionarBotónActualizar
12:CargarPantallaConsultorioExternoConDatos.
13SeleccionarBotónCancelar.
14Cancelardatos

Página 89
3.15. Diagrama de clases.
Gráfico 46

Página 90
CAPÍTULO IV
RESULTADOS

Página 91
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

Tesis admision municipal_2015_upig

Tesis admision municipal_2015_upig

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (13)

Similar a Tesis admision municipal_2015_upig

Similar a Tesis admision municipal_2015_upig (20)

Más de Victor Manuel Chumpitaz Avalos

Más de Victor Manuel Chumpitaz Avalos (6)

Último

Último (20)

Tesis admision municipal_2015_upig