Anda di halaman 1dari 17

CAPITULO III

MARCO METODOLÓGICO

En todo trabajo de investigación es indispensable y fundamental


que los hechos y relaciones que establecen los resultados tengan el
grado de exactitud y confiabilidad. Para ello, existe una metodología y
procedimiento ordenado. Márquez (2006), referente al marco
metodológico expresa:

“Contiene el conjunto de estrategias que se planifican a objeto


de desarrollar la investigación. Las tareas más importantes a
ejecutar son: definir el nivel y diseño de investigación, escoger
el universo y la muestra y elaborar los instrumentos que
servirán para recoger los datos”. (p.38).

Modalidad de la investigación

Para los fines de la temática en cuestión, el estudio corresponde a


la modalidad de Proyecto Factible (2012); al respecto el Manual de
Trabajos de Grado, de Especialización y Maestrías y Tesis Doctorales,
Upel (2006:26), expresa: Consiste en la propuesta de un modelo funcional
viable, o de una solución posible a un problema de tipo práctico, con el
objeto de satisfacer necesidades de un ente específico (Institución,
comunidad, grupo social, persona en particular, etc.)

La propuesta que va a elaborar ha de caracterizarse por tener


apoyo en una investigación de campo, la cual se va a realizar dentro de la
UNELLEZ-Barinas Vpds. El proyecto factible comprende cinco (5) etapas:
Diagnóstico, Elaboración o diseño del proyecto, Estudio de factibilidad,
Ejecución o puesta en marcha del proyecto y Evaluación del proyecto.

Tipo de investigación

La investigación descriptiva, también conocida como la


investigación estadística, describe los datos y características de la
población o fenómeno en estudio. Responde a las preguntas: quién, qué,
dónde, por qué, cuándo y cómo. Por su parte Hernández, Fernández y
Baptista (2010) definen la investigación descriptiva de la siguiente
manera:

“Los estudios descriptivos buscan especificar las propiedades,


las características y los perfiles de personas, grupos,
comunidades, procesos, objetos o cualquier otro fenómeno que
se someta a un análisis. Es decir, únicamente pretenden medir
o recoger información de manera independiente o conjunta
sobre los conceptos o las variables a las que se refieren”. Pág.
80

Cabe agregar que es una investigación descriptiva, puesto que la


meta consiste en describir el evento que ocurre en el departamento de
historias clínicas del centro médico asistencial (SIPROMA) UNELLEZ
Barinas Vpds para poder detallar como ocurre o se manifiesta, logrando
medir las variables relacionadas al estudio.

Diseño de la investigación

Todo trabajo de investigación requiere de un diseño que sirva para


determinar la metodología que se va a utilizar y para corroborar todos los
datos, también es el que permite presentar la información clara y veraz
para dar respuestas a ciertas preguntas, en tal caso Miriam Balestrini
(2006), señala que: “Un diseño de Investigación se define como el plan
global de investigación que integra de un modo coherente y
adecuadamente correcto técnicas de recogidas de datos a utilizar, análisis
previstos y objetivos…”.
Al respecto del diseño de la investigación, Hernández, Fernández y
Baptista (2010: 120), establecen lo siguiente: “El término diseño se refiere
al plan o estrategia concebida para obtener la información que se desea”.

El presente trabajo de investigación está enmarcado en el diseño


de campo, basado en la investigación descriptiva. Según Arias (2012):

“La investigación de campo es aquella que consiste en la


recolección de datos directamente de los sujetos investigados,
o de la realidad donde ocurren los hechos (datos primarios), sin
manipular o controlar variable alguna, es decir, el investigador
obtiene la información pero no altera las condiciones
existentes. De allí su carácter de investigación no
experimental”. Pág. 31

Este diseño de investigación, consiste en recolectar los datos


desde donde ocurren los hechos del objeto de estudio. Por lo que
concierne, es necesario asistir al departamento de historias clínicas del
centro médico asistencial, para una previa recolección de datos, con el fin
de obtener información acerca de los procesos realizados actualmente
para poder responder a las interrogantes hechas en la investigación.

Estudio de factibilidad

Factibilidad técnica

DEPARTAMENTO DE HISTORIAS CLINICAS SIPROMA

Hardware requerido
Hardware disponible

 PC VIT  Ordenador de escritorio


 Pentium Dual core E5500  Pentium Dual core E5500
 2 GB de RAM  2 GB de RAM
 HDD 160 Gb  HDD 80 Gb
Software disponible Software requerido

 Windows 7- 32 Bits  Windows XP, 7.


 Linux

 XAMPP  XAMPP

Por tanto, el departamento cumple con las características suficiente


para la puesta en marcha de sistema a implantar; así el sistema estará en
la capacidad de dar respuestas adecuadas sin importar el número de
consultas. Este sistema está diseñado y orientado a satisfacer las
necesidades y requerimientos del departamento de historias clínicas
(SIPROMA).

Factibilidad Económica

DEPARTAMENTO DE HISTORIAS CLINICAS SIPROMA


Empresa Manual Precio Bs.S Implantación del Sistema Precio Bs.S
Diseño Base de Datos:
Gastos en papelería 0 0
Baseado de la información:
Gastos en personal 0 0
Pantalla:
Gastos en utilería 0 0
Análisis de la propuesta:
Total: 0 0
Instalación del software:
0
Conexión de la red:
0
Total:
0
Nota: El mismo será exonerado por el Trabajo de Tesis
para Optar al Título de TSU en Informática

Factibilidad Operacional

Los encargados del departamento de historias clínicas del centro


médico asistencia de SIPROMA tienen un completo conocimiento y total
manejo en el uso de computadores y los paquetes de trabajo.

Metodología para el desarrollo del software

La metodología de desarrollo del software impone un proceso de


forma disciplinada, con el objetivo de hacerlo más predecible y eficiente
para todas las partes involucradas en la construcción de un sistema. Se
utiliza como una guía de procesos y diseño para llegar a un resultado de
alta calidad.

Para alcanzar el objetivo general del proyecto, se implementará la


Metodología RUP (Proceso Unificado Racional), es un proceso propietario
de la ingeniería de software creado por Rational Software, adquirida por
IBM.
Según Pressman Roger (2010), el Proceso Unificado Racional se
define de la siguiente manera:

“Es un proceso del software “impulsado por el caso de uso,


centrado en la arquitectura, iterativo e incremental”. En cierto
modo, el proceso unificado es un intento por obtener los
mejores rasgos y características de los modelos tradicionales
del proceso del software, pero en forma que implemente
muchos de los mejores principios del desarrollo ágil de
software. El proceso unificado reconoce la importancia de la
comunicación con el cliente y los métodos directos para
describir su punto de vista respecto de un sistema (el caso de
uso). Hace énfasis en la importancia de la arquitectura del
software y ayuda a que el arquitecto se centre en las metas
correctas, tales como que sea comprensible, permita cambios
futuros y la reutilización Es un flujo del proceso iterativo e
incremental, lo que da la sensación evolutiva que resulta
esencial en el desarrollo moderno del software”. Pág. 46.

Fases de la Metodología RUP

Está conformado por 4 fases cada una las cuales son: Fase de
inicio, fase de elaboración, fase de construcción y fase de transición.

Fase de Inicio.

Durante la fase de inicio se define el modelo del negocio y el


alcance del proyecto. Se identifican todos los actores y Casos de Uso, y
se diseñan los Casos de Uso más esenciales (aproximadamente el 20%
del modelo completo).

Fase de Elaboración.

El propósito de la fase de elaboración es analizar el dominio del


problema, establecer los cimientos de la arquitectura, desarrollar el plan
del proyecto y eliminar los mayores riesgos. En esta fase se construye un
prototipo de la arquitectura, que debe evolucionar en iteraciones
sucesivas hasta convertirse en el sistema final. Este prototipo debe
contener los Casos de Uso críticos identificados en la fase de inicio.
También debe demostrarse que se han evitado los riesgos más graves.

Fase de Construcción.

La finalidad principal de esta fase es alcanzar la capacidad


operacional del producto de forma incremental a través de las sucesivas
iteraciones. Durante esta fase todos los componentes, características y
requisitos deben ser implementados, integrados y probados en su
totalidad, obteniendo una versión aceptable del producto.

Fase de Transición.

La finalidad de la fase de transición es poner el producto en manos


de los usuarios finales, para lo que se requiere desarrollar nuevas
versiones actualizadas del producto, completar la documentación,
entrenar al usuario en el manejo del producto, y en general tareas
relacionadas con el ajuste, configuración, instalación y facilidad de uso del
producto.

Fase de Inicio.

Análisis del sistema.


El sistema permitirá agilizar los procesos de registro y búsqueda ya
que con solo digitar el número de orden o de cedula este le mostrara los
datos del paciente en la pantalla y además contara con una base de datos
donde quedaran almacenados todos los registros de las historias clínicas
permitiendo tener una mayor seguridad en el manejo de los datos.

Requerimientos funcionales y no funcionales del sistema.


Funcionales
El usuario ingresa al sistema.
El sistema pide al administrador (Usuario, clave,).
El usuario digita los datos.
El sistema verifica los datos del usuario.
El sistema permite acceso.
El sistema muestra el menú de opciones.
Registrar Historias Clínicas.
Editar Historias Clínicas.
Consultar Historias Clínicas.
No Funcionales
Deficiencia del sistema correspondiente al mal funcionamiento del
hardware.

Actualizaciones del sistema.

Falta de conocimiento por parte del usuario para el manejo del


sistema.

Rendimiento.

Tiempo y espacio.

Fiabilidad.

Robustez.

Mantenimiento.

Portabilidad.

Seguridad.

Disponibilidad del equipo.

Modificación a futuro.

Condiciones del medido (Climáticas alta temperaturas)

Recursos consumidos por el sistema.

Documentación (Usuario, instalación, administración de licencias y


partes legales.)
Cuestiones operacionales (Gestión de errores, frecuencias de
copias de seguridad.)

Interfaz del usuario y factores humanos: tipo de interfaz.

Documentación, tipo de documentación técnica, documentación


requerida, destinatario.

Auditoría y control.

Capacidad actual y prevenciones.

Certificación.

Eficiencia (consumo de recursos por la carga dada.)

Operatividad.

Rendimiento.

Tiempo de respuesta.

Mantenimiento.

Recuperación

Velocidad de memoria.

Velocidad del procesador.

Velocidad de arranque.

Fase de Elaboración.

El propósito de la fase de elaboración es analizar el dominio del


problema y establecer los cimientos de la arquitectura. En esta fase se
construye un prototipo de la arquitectura, que debe evolucionar en
iteraciones sucesivas hasta convertirse en el sistema final. Para ello se
determinará los casos de uso resultantes, para ser capaces de usarlos
para elegir nuestra arquitectura.
Caso de uso

Los diagramas de caso de uso modelan la funcionalidad del


sistema usando actores y casos de uso. Los casos de uso son servicios o
funciones provistas por el sistema para sus usuarios.

A continuación, se muestra el caso de uso general de la interacción del


usuario con el sistema.

 Caso de Uso: Control de Historias médicas.


 Actor: Usuario (Coordinador y/o Doctor-Especialista)
 Propósito: Llevar control sobre las historias médicas de las
diferentes especialidades del seguro social.
 Tipo: General.
 Resumen: El sistema le solicita al usuario identificarse ingresando
el nombre de usuario y la contraseña, así como la especialidad o
cargo que tenga, el cual debe ser ingresado correctamente para
tener acceso al mismo. Dependiendo si es Coordinador entrará al
subsistema1 y si es Doctor entrara al subsistema2.

Fig.1 Caso de uso general.


Fuente: Buitrago y Rondón (2019)

Una vez identificado el usuario, se muestra el caso de uso general


de manera dividida de los dos actores, juntamente con los actores
indirectos que hacen vida para la interacción del actor directo con el
sistema.
 Caso de Uso: Control de Historias médicas.
 Actor: Coordinador y/o Doctor-Especialista
 Propósito: Llevar control sobre las historias médicas de las
diferentes especialidades del centro médico.
 Tipo: General Dividido
 Resumen: El sistema se divide en dos subsistemas, uno para el
coordinador (sub-sistema1) y otro para el doctor (sub-sistema2),
donde el coordinador interactúa con el sistema y para hacer uso del
mismo establece comunicación con los doctores o doctor a
registrar como usuarios.

Fig. 2 Caso de uso general dividido

Fuente: Buitrago y Rondón (2019)

Seguidamente, se muestra el caso de uso primario del


Subsistema1 del software de control de historias médicas, el cual
especifica cada uno de los procesos que se ejecutan dentro del dominio
de la aplicación. Permitiendo así, obtener una visión más clara de la
funcionalidad del sistema.

 Caso de Uso: Control de Historias médicas.


 Actor: Coordinador
 Propósito: Llevar control sobre las historias médicas y registro de
usuarios.
 Tipo: Primario Subsistema1
 Resumen: El coordinador puede realizar los diferentes procesos de
cada uno de los módulos que son ejecutados por el sistema, según
sea el caso; los módulos del sistema son: Usuarios, Historial de
acceso, Historias y Hoja de evolución. Se observa que para poder
dar vida a los diferentes módulos debe establecer contacto o
comunicación con el médico especialista, ya que se debe registrar
en el sistema y éste accederá a las historias clínicas y será el
encargado de crear hojas de evolución, lo cual generará un historial
de acceso. Y con los pacientes para registrar todos los datos, así
como sus historiales médicos existentes y nuevos, en el caso de
ser nuevo este dicta sus datos al administrador y este los introduce
al sistema.

Fig.3 Caso de uso Sub-sistema1.

Fuente: Buitrago y Rondón (2019)


Seguidamente, se muestra el caso de uso primario del Subsistema1
del software de gestión documental de historias clínicas, el cual especifica
cada uno de los procesos que se ejecutan dentro del dominio de la
aplicación. Permitiendo así, obtener una visión más clara de la
funcionalidad del sistema.

 Caso de Uso: Control de Historias médicas.


 Actor: Doctor-Especialista
 Propósito: Llevar control sobre las historias médicas de su
especialidad
 Tipo: Primario Subsistema1
 Resumen: El usuario puede realizar los diferentes procesos de
cada uno de los módulos que son ejecutados por el sistema, según
sea el caso; los módulos del sistema son: Historias Médicas y
Hojas de Evolución. Se observa que para poder dar vida a los
diferentes módulos debe establecer contacto o comunicación con el
paciente.

Fig.4 Caso de uso sub-sistema 2

Fuente: Buitrago y Rondón (2019)


Carta Estructurada

Nombre del Sistema: SIGEDPROMA – Sistema de Gestión


Documental SIPROMA.

Figura. Carta estructurada de SIGEDPROMA.


Mapa de navegación del sistema.

Figura. Mapa de navegación de las diferentes pantallas de SIGEDPROMA.


Diagrama de actividades
Diagrama entidad relación

Diccionario de datos