REPÚBLICA BOLIVARIANA DE VENEZUELA

UNIVERSIDAD RAFAEL URDANETA

FACULTAD DE INGENIERIA
ESCUELA DE COMPUTACIÓN

“SOFTWARE PARA LA GESTIÓN

DE CONTROL DE HISTORIAS CLÍNICAS
ODONTOLÓGICAS”

Trabajo Especial de Grado para optar al Título de Ingeniero en

Computación

Realizado por:

Br. Duque Persad, Karla Patricia

C.I.: 18.394.188

Tutor Académico:
Prof. Erick Ramos

MARACAIBO,ENERO 2009
 “SOFTWARE PARA LA GESTIÓN
DE CONTROL DE HISTORIAS CLÍNICAS
ODONTOLÓGICAS”
 AGRADECIMIENTOS

A Dios brindarme la salud e inteligencia para culminar este proyecto, que consolida una
de mis metas.

Al Ingeniero Erik Ramos por aceptar el compromiso de ser el tutor académico, por su
apoyo en todo momento, por toda la orientación que me proporciono hasta lograr mi
meta.

A mi mamá, novio, tíos, primos, por estar siempre presentes en todos aquellos momentos
difíciles con que nos pone a prueba la vida, gracias por su apoyo incondicional y sus
orientaciones.

A Efraín, por ese gran apoyo, por la compañía, por el estar conmigo cuando lo necesitaba,
por darme ánimos para continuar
 DEDICATORIA

A Dios y a La Virgen, por iluminarme y ser mis mejores guías.

A mi Mamá, por estar siempre ahí conmigo, con mis preocupaciones, temores, alegrías
y triunfos y darme siempre el apoyo, la comprensión, y el estimulo para poder lograr
las metas que me trazo en la vida

A toda mi familia, por el apoyo que me brindaron, porque de una u otra manera
también me ayudaron a realizar este sueño.

A ti Cesar, por apoyarme, entenderme, escucharme y decirme siempre lo que

necesitaba escuchar para seguir con ánimo y así lograr esta primera meta en mi vida.
Te Amo.
Duque P, Karla P, SOFTWARE PARA LA GESTIÓN DE CONTROL DE
HISTORIAS CLÍNICAS ODONTOLÓGICAS Universidad Rafael Urdaneta.
Facultad de Ingeniería. Escuela de Computación. Trabajo especial de grado.
Maracaibo, 2008.

RESUMEN

La presente investigación, tuvo como propósito fundamental el desarrollo de

software para la gestión de control de historias clínicas odontológicas, con el fin de
tener bien resguardada la información y manejarla de mejor manera, con la
finalidad de poder satisfacer al usuario en las necesidades de consultar, modificar
e ingresar los datos de insumo, proceso y resultado. Utilizo como población a los
odontólogos de la Torre de Consultorios Amado, del municipio Maracaibo, Edo.
Zulia. Esta investigación se consideró del tipo descriptiva, aplicada y proyecto
factible debido a que desarrolla un software permitiendo con esto resolver un
problema. En cuanto al diseño de investigación, se considera no experimental y
transversal descriptivo, por cuanto se recoge la información en un tiempo y
momento único; en la investigación se utilizó como técnicas de recolección de
datos la observación directa y la encuesta. La metodología utilizada para el
desarrollo del sistema es la de Montilva (2000), el modelo de procesos Watch, la
cual consta de ocho fases de las cuales solo se utilizaron seis de ellas: análisis y
dominio de la aplicación, descubrimiento de requerimiento, especificación de
requerimientos, diseño del sistema, implantación del sistema y prueba del sistema,
debido a que dos de las mismas, diseño de componentes y entrega del sistema,
no se adaptaban al contexto de la investigación. El lenguaje de programación
utilizado fue Python y como manejador de base de datos SQLite. Los objetivos
propuestos al inicio de la investigación fueron cumplidos y se obtuvo como
conclusión que el sistema de información automatizado facilita y agiliza de una
manera eficaz la gestión de control de historias odontológicas.

Palabras Claves: Software, Gestión de Control, Historias

 Indice General

ÍNDICE GENERAL

DEDICATORIA ----------------------------------------------------------------------- III

AGRADECIMIENTOS -------------------------------------------------------------- IV
RESUMEN ----------------------------------------------------------------------------- V
INTRODUCCIÓN ------------------------------------------------------------------- VII

CAPITULO I.

PLANTEAMIENTO Y FORMULACIÓN DEL PROBLEMA ---------------- 02

OBJETIVOS DE LA INVESTIGACIÓN ------------------------------------------ 07
Objetivo General -------------------------------------------------------------- 07
Objetivos Específicos --------------------------------------------------------- 08
JUSTIFICACIÓN E IMPORTANCIA --------------------------------------------- 08
DELIMITACIÓN --------------------------------------------------------------------- 10

CAPITULO II.

ANTECENDENTES DE LA INVESTIGACION -------------------------------- 12

FUNDAMENTOS TEORICOS ----------------------------------------------------- 14

CAPITULO III.

MARCO METODOLÓGICO ------------------------------------------------------- 37

TIPO DE INVESTIGACIÓN --------------------------------------------------------37
DISEÑO DE LA INVESTIGACIÓN ----------------------------------------------- 38
 Indice General

POBLACIÓN ------------------------------------------------------------------------ 38
TÉCNICA DE RECOLECCIÓN DE DATOS ------------------------------------ 39
PROCEDIMIENTO DE LA INVESTIGACIÓN --------------------------------- 42
METODOLOGÍA -------------------------------------------------------------------- 43

CAPITULO IV.

ANÁLISIS Y DISCUSIÓN DE RESULTADOS --------------------------------- 45

CAPITULO V.

MANUAL DEL SISTEMA -------------------------------------------------------- 60

CONCLUSIONES ------------------------------------------------------------------ 69
RECOMENDACIONES ----------------------------------------------------------- 72
BIBLIOGRAFÍA ------------------------------------------------------------------- 74
ANEXOS --------------------------------------------------------------------------- 76
 CAPÍTULO I
“EL PROBLEMA”

1.1. PLANTEAMIENTO Y FORMULACIÓN DEL PROBLEMA

Los cambios gestados durante el siglo XX en el ámbito de la informática y la

comunicación fueron verdaderamente sorprendentes por el impacto generado en los

distintos ámbitos de la sociedad, profundizándose estos cada vez más en este tercer

milenio donde la tecnología de la información abre puertas y vislumbra un horizonte

distinto y sorpresivo ante los beneficios prácticos que le ofrece al hombre para el

desarrollo de todas sus actividades.

Es así como la tecnología brinda una serie de ventajas competitivas que permiten el

desarrollo de la globalización, modernización, e integración donde todos los elementos a

nivel internacional, nacional, regional y local, pueden coordinarse para brindar procesos

integrados y efectivos en los sectores económicos sociales, culturales y políticos,

facilitándole al hombre su mundo y el desenvolvimiento de las operaciones que

posiblemente en tiempos pasados eras complejos y en la actualidad son vistos como

aspectos sencillos y fáciles de manejar.

En ese ámbito de integración, los sistemas de información y los software surgieron

como herramientas precisas para condicionar datos importantes no solo para un ambiente
2
si no para generar de forma colectiva conocimientos que pueden ser utilizados en un

punto especifico del mundo, de igual manera que en el mas pequeño y recóndito espacio

de la tierra, de allí que los niveles de eficiencia y efectividad a través de la internet han

progresado desde el punto de vista de rentabilidad y competitividad contribuyendo con el

desarrollo personal y organizacional.

Es por ello que los sistemas de información según lo plantean Laudon y Laudon

(2004) permiten en la actualidad que las organizaciones accesen a los datos ampliando su

alcance hasta lugares muy retirados ofreciendo productos y servicios nuevos reforzando

empleos y flujos de trabajos que quizás puedan cambiar profundamente la manera de

conducir sus negocios, mejorando los procesos técnicos y operativos al integrar cada uno

de los elementos requeridos dentro del sistema, siendo según el estándar 729 del IEEE, el

software es el conjunto de los programas de cómputo, procedimientos, reglas,

documentación y datos asociados que forman parte de las operaciones de un sistema de

computación

Al respecto, Chiavenato (2002) plantea que un sistema es un conjunto de elementos

interdependientes e interactuantes, un grupo de unidades combinadas que forman un todo

organizado y cuyo resultado es mayor que el resultado de las unidades que funcionan

independientemente, formando un todo complejo o unitario. Explica el autor que el

concepto no es una tecnología en si, si no una resultante de ella, que permite una visión

3
comprensiva, amplia y gestáltica de un conjunto complejo dándole una configuración

total.

Este concepto determina que todo aquello que funcione de manera articulada con otros

elementos va a conformar un sistema donde es tan importante el insumo como el proceso

y los resultados, por lo cual, al considerarse tales elementos el procesamiento de los datos

va a implicar que la información recibida sea más valiosa y fidedigna al tomar en cuenta

cada uno de los elementos del mismo. Es así como Ivancevich y otros (1998) manifiestan

que hoy en día casi toda la información se precisa mediante los computadores y por ello,

las empresas están utilizándolos para convertir datos en información valiosa para el

desarrollo de sus operaciones y como antes se mencionó, optimizan la gestión al combinar

la informática con procedimientos regulares y organizados para suministrar a los gerentes

de manera oportuna, la información necesaria para la toma de decisiones y el control.

En tal sentido, Venezuela en su deseo de desarrollo y crecimiento ha incorporado en

sus pequeñas, medianas y grandes empresas, sistemas de información y software que

optimizan las operaciones tanto administrativas como operativas siguiendo el esquema de

accesar datos para que el hardware conjuntamente con el software incorporado en el

computador realice las actividades de organización de manera que el trabajo sea más fácil

y organizado.

Cabe destacar que pequeñas mediana y grandes empresas poseen software con los

cuales pueden organizar información diversa y los resultados obtenidos desde el punto de

4
vista de procesos y productos han sido verdaderamente efectivos, indicando las bondades

que propician tanto a los gerentes o dueños de empresas, como también, a los empleados,

clientes, proveedores, competidores y entorno en general, lo cual indica que en este siglo

XXI todas las organizaciones no importa su tamaño o rubro, deben contar con estos

programas.

En otro orden de ideas, es de hacer notar que los médicos, odontólogos, veterinarios,

nutricionistas, bioanalistas, entre otros profesionales de la salud, trabajan directamente

con clientes que deben ser tratados con el respeto que les corresponde de manera

individual, y por ello en la consulta se lleva una historia médica del caso que caracteriza

al paciente, tomando en cuenta sus particularidades, de manera que al ser atendidos se

lleve un control del pasado, presente para poder el profesional asumir decisiones al

respecto de la situación de cada uno de ellos .

Tal es el caso de los odontólogos quienes como profesionales de la salud atienden en

su consultorio a una cantidad de pacientes, cada uno de ellos con problemas más o menos

similares pero particulares en cuanto a las condiciones que presentan, siendo necesario

desde el primer día hacer triaje para conocer cuáles son las características que manifiestan

y poder seguir tratamiento con el propósito de generar los cambios necesarios en el

paciente, de allí que se lleve una historia médica que informa acerca de todas las

eventualidades que haya tenido, sirviéndole al doctor de guía para saber cuáles decisiones

debe asumir .

5
 Para ello se lleva una historia médica por paciente que se archivan en carpetas y deben

ser consultadas en cada visita del paciente, ocasionando algunas veces pérdida de tiempo

al buscarla, escribirla y llevar el proceso del tratamiento lo cual afecta si se toma en

cuenta el tiempo que se debe disponer para cada caso. Es bien cierto que este proceso lo

ha llevado a cabo el odontólogo con la ayuda de asistentes o enfermeras (os) siendo

verdaderamente efectivo, pero si se toma en cuenta la necesidad de adecuar los procesos a

los avances tecnológicos se considera necesario asumir el cambio incorporando sistemas

de información que no solo pondrían a la empresa en la palestra en cuanto a los procesos

administrativos, organizacionales y tecnológicos, si no que dentro del mercado le

permitiría competir por el servicio de calidad he innovación al facilitar las operaciones

dentro de la misma.

Como situación problemática, los odontólogos comparten la inquietud de tener

dificultad para accesar con facilidad a las historias médicas odontológicas por falta de

organización del material y por la gran cantidad de historias que ocupan espacio el cual es

útil para otras cosas, generando descontrol por parte de la asistente y el mismo

odontólogo, necesitándose paciencia y mayor tiempo para la búsqueda de cada carpeta.

Esto pudiera ser producto de la falta de preparación organizacional y de control, tanto

del odontólogo como asistente o enfermera (ro) para llevar la parte administrativa así

como también, porque a veces por los altos costos le es imposible contar con este

personal, además que posiblemente comparta el consultorio con otros colegas, limitando

6
el espacio para archivar las historias, lo cual trae como consecuencia desorganización en

las historias, descuido, olvidos y por ende trabajos poco satisfactorios; de allí que se dé

pérdida de tiempo de dinero y de esfuerzo debiendo generar medidas para disminuir este

tipo de problemas.

En ese marco de ideas, tomando en cuenta que han surgido diferentes sistemas de

aplicación es interesante diseñar y ofrecer un software para registrar, almacenar y

organizar las historias médicas para la gestión de control en los consultorios

odontológicos tomando en cuenta los criterios o parámetros requeridos en cuanto a las

características del paciente y de las actividades que realiza el odontólogo, lo cual traería

como consecuencia, facilitar los procesos desarrollados teniendo la oportunidad de

brindar un trabajo de mayor calidad y efectividad.

Con base en lo antes planteado surge la siguiente interrogante ¿Qué aspectos

considerar para diseñar software para la gestión de control de historias clínicas

odontológicas?

OBJETIVOS DE LA INVESTIGACIÓN

1.1.1. OBJETIVO GENERAL

Diseñar un software para la gestión de control de las historias clínicas odontológicas.

1.1.2. OBJETIVOS ESPECÍFICOS

7
 ‐ Identificar la situación actual de la gestión de control de historias clínicas

odontológicas.

‐ Analizar los elementos para el desarrollo del software de gestión de control

‐ Diseñar el software que permita la gestión de control de las historias clínicas

odontológicas.

‐ Probar la efectividad del software de gestión de control de historias clínicas

odontológicas.

1.2. JUSTIFICACIÓN E IMPORTANCIA DE LA INVESTIGACIÓN

La presente investigación tiene como objetivo desarrollar un software para la gestión

de control de historias clínicas odontológicas, considerando que por ello tiene su

relevancia social al brindar alternativas para el trabajo que realiza administrativamente el

odontólogo en su consultorio, permitiéndole llevar un proceso organizado en cuanto a la

información necesaria de cada uno de sus pacientes con el propósito de brindarle la

atención, tomando en cuenta las características de rapidez, objetividad científica e

integración.

En cuanto a la relevancia práctica, la presente investigación pretende proponer un

software para la gestión de control que sirve para todos los odontólogos que laboran en

clínicas grandes medianas o pequeñas, por cuanto el programa ofrecido generaliza los

datos que pueden ser utilizados según las características de cada uno de estos

8
consultorios, respetando las individualidades de los pacientes que asisten a las consultas,

resaltando que es práctico el producto brindado por la investigadora al permitirle al

profesional distribuir su tiempo adecuadamente en cuanto a la parte administrativa, de

atención y la odontológica, trayendo como resultado que el paciente se sienta satisfecho

del servicio obtenido, además, estará consciente y seguro de la información que su doctor

registra sobre sus casos.

La relevancia científica y teórica del estudio consiste en haber partido de un hecho

observado y tomando en cuenta la realidad, se desarrolló el software para la gestión de

control de historias clínicas odontológicas, con base en la documentación teórica y técnica

aportada por los expertos en sistemas, adaptándolo a la situación que se pretende

optimizar para lo cual, fue preciso probar el programa y comprobar su efectividad de

manera que los resultados y conclusiones den respuesta a la problemática planteada.

Desde el punto de vista metodológico el estudio se desarrollo tomando en cuenta el

proceso de una investigación positivista, proyecto factible al partir de hechos objetivos y

proponer alternativas de solución que son posibles de ejecutar en el ambiente donde se

diagnosticó la situación problema que en este caso, es en los consultorios odontológicos

de municipio Maracaibo. Además se considera que deja un aporte a futuros investigadores

primero porque se elaborara un cuestionario donde se pretende describir las

características, los elementos, los pasos y la metodología a seguir del software para la

gestión de control de historias clínicas odontológicas, que puede ser utilizado de manera

9
segura al ser válido y confiable. Como segundo aspecto el estudio con sus resultados y

conclusiones propicia la aplicabilidad del programa desarrollado generándole los cambios

necesarios que se le pudieran incorporar si así lo requiriera de acuerdo con las fallas o

debilidades que pudiera presentar.

Por último, se considera su relevancia contemporánea no ciertamente por lo novedoso

porque ya otros investigadores han desarrollado software, si no porque se adecua a las

exigencias que la sociedad del siglo XXI solicita a las empresas sea cual sea su rubro en

cuanto a la gestión automatizada que se debe implementar en sus procesos tomando en

cuenta las bondades que los avances científicos, tecnológicos y de la información le

ofrece al hombre para optimizar su calidad de vida tanto personal como profesional y

ocupacional.

1.3. DELIMITACIÓN

La presente investigación se enmarca en el área de la ingeniería de computación

considerando el desarrollo de un software para la gestión de control de historias clínicas

odontológicas, tomando en cuenta como unidad de información a odontólogos y asistentes

de consultorios públicos y privados del municipio Maracaibo. El estudio se desarrolla

entre mayo y diciembre 2008.

10
 CAPÍTULO II.
“MARCO TEÓRICO”

2.1. ANTECEDENTES DE LA INVESTIGACIÓN

En relación con la automatización de procesos se han realizado diversos estudios,
exponiéndose a continuación algunos de ellos que se consideran pertenecientes con el
estudio

A, Cáceres (2007) realizó un estudio titulado “Sistema de Información Web para el

Control de Historias Clínicas”, el objetivo del estudio fue resguardar la información y
satisfacer al usuario en las necesidades de consultar, ingresar, modificar y eliminar los
datos.

La investigación fue de tipo descriptiva y el diseño de la investigación fue de tipo No

Experimental, es decir, se realizo sin manipular deliberadamente variables. La técnica de
recolección de datos utilizada fue la observación directa.

La Metodología utilizada para el desarrollo del sistema fue la de Montilva (2000),

donde se utilizaron las siguientes fases: Análisis del Dominio de Aplicación,
Descubrimiento de Requerimientos, Especificación de Requerimientos, Diseño del
Sistema, Implementación de Interfaz Web y por ultimo Pruebas al Sistema. Para el
desarrollo de la aplicación se utilizo Windows XP, Macromedia Dreamweaver 8, PHP,
Apache y como manejador de base de datos My SQL

12
 Los resultados obtenidos abarcan los objetivos planteados al inicio de la investigación,
esto permitió aumentar la confiabilidad del usuario por los datos guardados y consultados
en la base de datos.

Así mismo, Giovanna (2001) realizó un estudio titulado: Sistema de Información

Automatizado para el control de Procesos Administrativos caso: Coordinación de
investigación de la facultad de ingeniería de la URBE. Para esta investigación se
utilizaron técnicas de de observación directa, documental y entrevistas. El diseño de la
investigación fue aplicada y de campo.

La metodología utilizada fue la establecida por Senn (1996) la cual consta de 6 fases:
investigación preliminar, determinación de requerimientos, diseño del sistema, desarrollo
del software, prueba e implantación del sistema.

En el desarrollo físico del sistema se seleccionó la herramienta de programación

Visual Basic 6.0 y la de aplicación de manejo de sistema de base de datos Access 2000.
Los objetivos planteados al principio de la investigación fueron cubiertos, los resultados
de la investigación facilitaron el control de procesos administrativos.

De la misma forma, Hernández y Rincón (2002) desarrollaron un Sistema de

información para el control de acceso y registro de personal a las empresas. La
fundamentación teórica del proyecto consistió en una amplia documentación referente a
las teorías de sistemas de programación y sistemas de control.

La metodología utilizada fue la planteada por Laudon y Laudon (2000) y consistió en la

aplicación de las siguientes etapas: definición del proyecto, análisis del sistema, diseño,
programación y prueba.
13
 El lenguaje utilizado fue Visual Basic 6.0, Flash 5.0, y la base de datos se creó bajo
Microsoft Access 2000. La técnica de recolección de datos fue la observación directa, a
través de la entrevista informal sin formato definido. Como resultado final de la
investigación, se determinó que el sistema es aceptable para controlar el acceso y llevar el
registro de personal de aquellas empresas interesadas en adquirir el mismo.

2.2. FUNDAMENTACIÓN TEORICA

Toda persona para poder realizar una investigación debe apoyarse en conocimientos
teóricos. Para un mejor entendimiento del significado de un Software y todo en cuanto a
él se refiere o relacione con este medio, se efectuó una búsqueda de los conceptos
relevantes en esta área tomando en cuenta las teorías de varios autores.

2.2.1. SOFTWARE

Según Montilva, J (2004) es el equipamiento lógico de un computador digital,

comprende el conjunto de los componentes lógicos necesarios para hacer posible la
realización de una tarea específica.

En la actualidad, el software es la tecnología individual más importante en el ámbito

mundial. A medida que la importancia del software ha crecido, se ha intentado de manera
continua desarrollar tecnologías que hagan más fácil, más rápida y menos cara la
construcción y el mantenimiento de programas de computación de alta calidad.

14
 Para Pressman (2005), el papel del software ha experimentado un cambio significativo
en un periodo de un poco mayor a 50 años. Las mejorías sustanciales en el desempeño del
hardware, los cambios profundos en las arquitecturas de cómputo, los enormes
incrementos en las capacidades de memoria y almacenamiento, y la amplia variedad de
opciones de salida y entrada han propiciado el surgimiento de sistemas más elaborados y
complejos basados en computadoras.

2.2.2. CARACTERISTICAS DEL SOFTWARE

Las características esenciales del software según Pressman (2005), son las siguientes:

El software se desarrolla o construye; no se manufactura en el sentido clásico. A

pesar de que existen similitudes entre el desarrollo del software y la manufactura del
hardware, las dos actividades son diferentes en lo fundamental. En ambas la alta calidad
se alcanza por medio del buen diseño, pero la fase de manufactura del hardware puede
incluir problemas de calidad inexistentes en el software. Ambas actividades dependen las
personas, pero la relación de la gente utilizada y el trabajo realizado es diferente por
completo. Ambas actividades requieren la construcción de un “producto”, pero los
enfoques son diferentes. Los costos del software se concentran en la ingeniería. Esto
significa que los proyectos de software no se pueden manejar como si fueran proyectos de
manufactura.

El Software no se “desgasta”. El software es inmune a los males ambientales que

desgasten el hardware. Por lo tanto la curva de tasas de fallas para el software debería
tener la forma de la “curva idealizada”. Los defectos sin descubrir causan tasas de fallas

15
altas en las primeras etapas de vida de un programa. Sin embargo, los errores se corrigen
y la curva se aplana: el software no se desgasta, pero si se deteriora.

Un aspecto del desgaste ilustra la diferencia entre el hardware y el software. Cuando

un componente del hardware se desgasta se sustituye con un repuesto. Pero en el software
no existen repuestos. Cualquier falla del software implica un error en el diseño o el
proceso mediante el cual se pasó del diseño al código máquina ejecutable. Por lo tanto, el
mantenimiento del software implica de manera considerable una complejidad mayor que
el del hardware.

A pesar de que la industria tiene una tendencia hacia la construcción por

componentes, la mayoría del software aún se construye a la medida. Considérese la
forma en que se diseña y construye un hardware de control para un producto de cómputo.
El ingeniero de diseño dibuja un esquema simple del sistema de circuitos digital, realiza
algunos análisis fundamentales para asegurarse de que el diseño realizará las funciones
apropiadas y después busca en los catálogos de componentes digitales cada circuito
integrado de acuerdo con un número de parte, una función definida y validada, una
interfaz bien definida y un conjunto estandarizado de directrices de integración. Una vez
seleccionado cada componente, puede solicitársele para después ensamblarlo.

Cuando una disciplina de ingeniería evoluciona se crea una colección de diseños

estándar de componentes. Los tornillos y los circuitos integrados son sólo dos ejemplos de
los miles de componentes estándar que utilizan los ingenieros mecánicos y eléctricos al
diseñar sistemas nuevos. Los componentes reutilizables se han creado para que el
ingeniero se pueda concentrar en los elementos que en realidad son innovadores en el
diseño; es decir, en las partes que representan algo nuevo. En el mundo del hardware, la

16
reutilización de componentes es una parte natural del proceso de ingeniería. En el ámbito
del software, dicha actividad apenas se ha comenzado a extender.

Un componente de software se debe diseñar e implementar de forma que pueda

utilizarse en muchos programas diferentes. Los componentes reutilizables modernos
encapsulan tanto los datos como el proceso que se aplica a éstos, lo que permite al
ingeniero de software crear aplicaciones nuevas a partir de partes reutilizables. Por
ejemplo, las interfaces actuales con el usuario se construyen con componentes
reutilizables que permiten la creación de ventanas gráficas, menús desplegables y una
amplia variedad de mecanismos de interacción. Las estructuras de datos y los detalles de
procesamiento requeridos para construir la interfaz están contenidos en una librería de
componentes reutilizables para la construcción de la interfaz.

2.2.3. CATEGORIAS DEL SOFTWARE

En la actualidad existen siete grandes categorías del software de computadora que

presentan retos continuos para los ingenieros de software. Pressman (2005) las clasifica
de la siguiente forma.

Software de sistemas. El software de sistemas es una colección de programas escritos

para servir a otros programas. Algunos programas de sistemas (como los compiladores,
editores y utilerías para la administración de archivos) procesan estructuras de
información complejas pero determinadas. Otras aplicaciones de sistemas (por ejemplo,
componentes del sistema operativo, controladores, software de red, procesadores para
telecomunicaciones) procesan datos indeterminados. En cada caso, el área de software de
sistemas se caracteriza por una interacción muy intensa con el hardware de la
17
computadora; utilización por múltiples usuarios; operación concurrente que requiere la
gestión de itinerarios, de compartición de recursos, y de procesos sofisticados; estructuras
de datos complejas y múltiples interfaces externas.

Software de aplicación. El software de aplicación consiste en programas

independientes que resuelven una necesidad de negocios específica. Las aplicaciones en
esta área procesan datos empresariales o técnicos de forma que facilitan las operaciones
de negocios o la toma de decisiones técnicas o de gestión. Además del procesamiento de
datos convencional, el software de aplicación se utiliza para controlar las funciones de
negocios en tiempo real (por ejemplo, el procesamiento de transacciones en los puntos de
venta y el control de procesos de manufactura en tiempo real.)

Software científico y de ingeniería. El software científico y de ingeniería, que se

caracterizaba por algoritmos “devoradores de números”, abarca desde la astronomía hasta
la vulcanología, desde el análisis de la tensión automotriz hasta la dinámica orbital de los
transbordadores espaciales, y desde la biología molecular hasta la manufactura
automatizada. Sin embargo, las aplicaciones modernas dentro del área científica y de
ingeniería se alejan en la actualidad de los algoritmos numéricos convencionales. El
diseño asistido por computadora, la simulación de sistemas y otras aplicaciones
interactivas han comenzado a tomar características de software en tiempo real e incluso
de software de sistemas.

Software empotrado. El software empotrado reside dentro de la memoria de sólo

lectura del sistema y con él se implementan y controlan características y funciones para el
usuario final y el sistema mismo. El software incrustado puede desempeñar funciones
limitadas y curiosas (como el control del teclado de un horno de microondas) o
proporcionar capacidades de control y funcionamiento significativas (por ejemplo, las
18
funciones digitales de un automóvil, como el control de combustible, el despliegue de
datos en el tablero, los sistemas de frenado, etcétera).

Software de línea de productos. El software de línea de productos, diseñado para

proporcionar una capacidad específica y la utilización de muchos clientes diferentes, se
puede enfocar en un nicho de mercado limitado (como en los productos para el control de
inventarios) o dirigirse hacia los mercados masivos (por ejemplo, aplicaciones de
procesadores de palabras, hojas de cálculo, gráficas por computadora, multimedia,
entretenimiento, manejo de bases de datos, administración de personal y finanzas en los
negocios).

Aplicaciones basadas en Web. Las “WebApps” engloban un espectro amplio de

aplicaciones. En su forma más simple, las WebApps son apenas un poco más que un
conjunto de archivos de hipertexto ligados que presenta información mediante texto y
algunas gráficas. Sin embargo, a medida que el comercio electrónico y las aplicaciones
B2B adquieren mayor importancia, las WebApps evolucionan hacia ambientes
computacionales sofisticados que no sólo proporcionan características, funciones de
cómputo y contenidos independientes al usuario final, sino que están integradas con bases
de datos corporativas y aplicaciones de negocios.

Software de inteligencia artificial. Este software utiliza algoritmos no numéricos en

la resolución de problemas complejos que es imposible abordar por medio de un análisis
directo. Las aplicaciones dentro de esta área incluyen la robótica, los sistemas expertos, el
reconocimiento de patrones (imagen y voz), las redes neuronales artificiales, la
comprobación de teoremas y los juegos en computadora.

19
2.2.4. MARCO DE TRABAJO

Cuando se trabaja para construir un producto o sistema es importante seguir una serie
de pasos predecibles: una especie de mapa de carretera que ayude a crear un resultado de
alta calidad y a tiempo; aunque el proceso que se adopte depende del software que se está
construyendo.

En este sentido Pressman. R (2005), nos dice que, un marco de trabajo establece las
bases para un proceso de software completo al identificar un número pequeño de
actividades del marco de trabajo aplicable a todos los proyectos de software, sin importar
su tamaño o su complejidad.
El siguiente marco de trabajo se puede aplicar en la inmensa mayoría de los trabajos de
software:

Comunicación. Esta actividad del marco de trabajo implica una intensa colaboración
y comunicación con los clientes; además, abarca la investigación de requisitos y otras
actividades relacionadas.

Planeación. Esta actividad establece un plan para el trabajo de la ingeniería del

software. Describe las tareas técnicas que deben realizarse, los riesgos probables, los
recursos que serán requeridos, los productos del trabajo que han de producirse y un
programa de trabajo.

Modelado. Esta actividad abarca la creación de modelos que permiten al desarrollador

y al cliente entender mejor los requisitos del software y el diseño que logrará
satisfacerlos.

20
 Construcción. Esta actividad combina la generación del código (ya sea manual o
automatizado) y la realización de pruebas necesarias para descubrir errores en el código.

Despliegue. El software (como una entidad completa o un incremento completado de

manera parcial) se entrega al cliente, quien evalúa el producto recibido proporciona
información basada en su evaluación.

Estas cinco actividades genéricas del marco de trabajo son útiles durante el desarrollo
de programas pequeños, la creación de grandes aplicaciones en la red, y en la ingeniería
de sistemas basados en computadoras grandes y complejas. Los detalles é proceso del
software serán muy diferentes en cada caso, pero las actividades dentro del marco
permanecerán iguales.

2.2.5. MODELOS PRESCRIPTIVOS DE PROCESO

Para cada una las fases o pasos del marco de trabajo, existen sub-etapas. Los modelos
prescriptivos de proceso utilizados para el desarrollo definen el orden para las tareas o
actividades involucradas, también definen la coordinación entre ellas, enlace y
realimentación entre las mencionadas etapas. Los modelos prescriptivos no son perfectos,
pero proporcionan una guía útil para el desarrollo de software de alta calidad.

Pressman, R. (2005) señala que, se les llama “prescriptivos” porque prescriben un

conjunto de elementos del proceso: actividades del marco de trabajo, acciones de
ingeniería del software, tareas, productos del trabajo, aseguramiento de la calidad, y
mecanismos de control del cambio para cada proyecto. Cada modelo de proceso prescribe

21
también un flujo de trabajo; esto es, la forma en la cual los elementos del proceso se
interrelacionan entre sí.

Todos los modelos de proceso del software se ajustan a las actividades genéricas del
marco de trabajo, pero cada uno aplica una importancia diferente a estas actividades y
define un flujo de trabajo que invoca cada actividad del marco de trabajo (así como
acciones y tareas de la ingeniería del software) de una manera diferente.

2.2.5.1. Modelo de Cascada, algunas veces llamado el ciclo de vida clásico, sugiere un
enfoque sistemático, secuencial hacia el desarrollo del software, que se inicia con la
especificación de requerimientos del cliente y que continúa con la planeación, el
modelado, la construcción y el despliegue para culminar en el soporte del software
terminado.

El modelo en cascada es el paradigma más antiguo; sin embargo, en las décadas

pasadas, las críticas a este modelo de proceso han ocasionado que aún sus más fervientes
practicantes hayan cuestionado su eficacia. Entre los problemas que algunas veces se
encuentran al aplicar el modelo en cascada están:

1. Es muy raro que los proyectos reales sigan el flujo secuencial que propone el
modelo. A pesar de que el modelo lineal incluye iteraciones, lo hace de manera
indirecta. Como resultado, los cambios confunden mientras el equipo de proyecto
actúa.

2. Con frecuencia es difícil para el cliente establecer todos los requisitos de manera
explícita. El modelo en cascada lo requiere y se enfrentan dificultades al incorporar
la incertidumbre natural presente en el inicio de muchos proyectos.
22
 3. El cliente debe tener paciencia. Una versión que funcione de los programas estará
disponible cuando el proyecto esté muy avanzado. Un error grave será desastroso
si no se detecta antes de la revisión del programa.

En un análisis interesante de proyectos reales, Bradac (1994) concluyo que la

naturaleza lineal del modelo en cascada conduce a “estados de bloqueo” en los cuales
algunos miembros del equipo del proyecto deben esperar a otros para terminar tareas
dependientes. De hecho, el tiempo de espera puede superar el que se aplica en el trabajo
productivo. El estado de bloqueo tiende a ser más común al principio y al final del
proceso secuencial.

En la actualidad, el trabajo del software está acelerado y sujeto a una cadena infinita de
cambios (de características, funciones y contenido de la información). Con frecuencia, el
modelo en cascada no es apropiado para dicho trabajo. Sin embargo, puede servir como
un modelo de proceso útil en situaciones donde los requerimientos están fijos y donde el
trabajo se realiza, hasta su conclusión, de una manera lineal.

2.2.5.2. Modelos de Proceso Incremental, En muchas situaciones los requisitos

iníciales del software están bien definidos en forma razonable, pero el enfoque global del
esfuerzo de desarrollo excluye un proceso puramente lineal. Además, quizá haya una
necesidad imperiosa de proporcionar de manera rápida un conjunto limitado de
funcionalidad para el usuario y después refinarla y expandirla en las entregas posteriores
del software. En estos casos se elige un modelo de proceso diseñado para producir el
software en forma incremental.

Modelo Incremental, este modelo combina elementos del modelo en cascada aplicado
en forma iterativa. El modelo incremental aplica secuencias lineales de manera
23
escalonada conforme avanza el tiempo en el calendario. Cada secuencia lineal produce
“incrementos” del software.

A menudo, al utilizar un modelo incremental el primer incremento es un producto

esencial. Es decir se incorporan los requisitos básicos, pero muchas características
suplementarias (algunas conocidas, otras no) no se incorporan. El producto esencial queda
en manos del cliente (o se somete a una evaluación detallada). Como resultado de la
evaluación se desarrolla un plan para el incremento siguiente. El plan afronta la
modificación del producto esencial con el fin de satisfacer de mejor manera las
necesidades del cliente y la entrega de características y funcionalidades adicionales. Este
proceso se repite después de la entrega de cada incremento mientras no se haya elaborado
el producto completo.

El modelo de proceso incremental, al igual que la construcción de prototipos y otros

enfoques evolutivos, es iterativo por naturaleza. Pero a diferencia de la construcción de
prototipos, el modelo incremental se enfoca en la entrega de un producto operacional con
cada incremento. Los primeros incrementos son versiones “incompletas” del producto
final, pero proporcionan al usuario la funcionalidad que necesita y una plataforma para
evaluarlo.

El desarrollo incremental es útil sobre todo cuando el personal necesario para una
implementación completa no está disponible. Los primeros incrementos se pueden
implementar con menos gente. Si el producto esencial es bien recibido se agrega (si se
requiere) más personal para implementar el incremento siguiente. Además, los
incrementos se pueden planear para manejar los riesgos técnicos. Por ejemplo, un sistema
grande podría requerir la disponibilidad de un hardware nuevo que está en desarrollo y
cuya fecha de entrega es incierta. Sería posible planear los primeros incrementos de forma
24
que se evite el uso de este hardware, lo que permitiría la entrega de funcionalidad parcial
a los usuarios finales sin retrasos desordenados.

Modelo DRA, el desarrollo rápido de aplicaciones (DRA) es un modelo de proceso de

software incremental que resalta un ciclo de desarrollo corto. El modelo DRA es una
adaptación a “alta velocidad” del modelo en cascada en el que se logra el desarrollo
rápido mediante un enfoque de construcción basado en componentes. Si se entienden bien
los requisitos y se limita el ámbito del proyecto, el proceso DRA permite que un equipo
de desarrollo cree un “sistema completamente funcional” dentro de un periodo muy corto
(por ejemplo, de 60 a 90 días).

Como otros modelos de proceso, el enfoque DRA cumple con las actividades
genéricas del marco de trabajo que ya se han presentado. La comunicación trabaja para
entender el problema de negocios y las características de información que debe incluir el
software. La planeación es esencial porque varios equipos de software trabajan en
paralelo sobre diferentes funciones del sistema. El modelado incluye tres grandes fases —
modelado de negocios, modelado de datos y modelado del proceso— y establece
representaciones del diseño que sirven como base para la actividad de construcción del
modelo DRA. La construcción resalta el empleo de componentes de software existente y
la aplicación de la generación automática de código. Por último, el despliegue establece
una base para las iteraciones subsecuentes, si éstas son necesarias.

Como todos los modelos de proceso, el enfoque DRA tiene inconvenientes:

1) para proyectos grandes, pero escalables, el DRA necesita suficientes recursos humanos
para crear el número correcto de equipos DRA; 2) si los desarrolladores y clientes no se
comprometen con las actividades rápidas necesarias para completar el sistema en un
marco de tiempo muy breve, los proyectos de DRA fallarán; 3) si un sistema no se puede
25
modelar en forma apropiada, la construcción de los componentes necesarios para el DRA
será problemática; 4) si el alto rendimiento es un aspecto importante, y se alcanzará al
convertir interfaces en componentes del sistema, el enfoque DRA podría no funcionar; y
5) el DRA sería inapropiado cuando los riesgos técnicos son altos.

2.2.5.3. Modelos de Procesos Evolutivos El software, como todos los sistemas

complejos, evoluciona con el tiempo. Los requisitos de los negocios y productos a
menudo cambian conforme se realiza el desarrollo; por lo tanto, la ruta lineal que conduce
a un producto final no será real; las estrictas fechas tope del mercado imposibilitan la
conclusión de un producto completo, por lo que se debe presentar una versión limitada
para liberar la presión competitiva y de negocios; se tiene claro un conjunto de requisitos
del producto o sistema esencial, pero todavía se deben definir los detalles de las
extensiones del producto o sistemas. En éstas y otras situaciones similares, los ingenieros
de software necesitan un modelo de proceso que haya sido diseñado de manera explícita
para incluir un producto que evolucione con el tiempo.

Construcción de Prototipos, a menudo un cliente define un conjunto de objetivos

generales para el software, pero no identifica los requisitos detallados de entrada,
procesamiento o salida. En otros casos, el responsable del desarrollo del software está
inseguro de la eficacia de un algoritmo, de la adaptabilidad de un sistema operativo o de
la forma que debería tomar la interacción humano-máquina. En éstas, y en muchas otras
situaciones, un paradigma de construcción de prototipos puede ofrecer el mejor enfoque.
A pesar de que la construcción de prototipos se puede utilizar como un modelo de proceso
independiente, se emplea más comúnmente como una técnica susceptible de
implementarse dentro del contexto de cualquiera de los modelos de proceso. Sin importar
la forma en que éste se aplique, el paradigma de construcción de prototipos ayuda al

26
ingeniero de sistemas y al cliente a entender de mejor manera cuál será el resultado de la
construcción cuando los requisitos estén satisfechos.

El Modelo en Espiral, Propuesto originalmente por Boehm en 1976, es un modelo de

proceso de software evolutivo donde se conjuga la naturaleza de construcción de
prototipos con los aspectos controlados y sistemáticos del modelo lineal y secuencial.
Proporciona el potencial para el desarrollo rápido de versiones incrementales del software
que no se basa en fases claramente definidas y separadas para crear un sistema.

En el modelo espiral, el software se desarrolla en una serie de versiones incrementales.

Durante las primeras iteraciones la versión incremental podría ser un modelo en papel o
un prototipo, durante las últimas iteraciones se producen versiones cada vez más
completas del sistema diseñado.

El modelo en espiral se divide en un número de actividades de marco de trabajo,

también llamadas regiones de tareas , cada una de las regiones están compuestas por un
conjunto de tareas del trabajo llamado conjunto de tareas que se adaptan a las
características del proyecto que va a emprenderse en todos los casos se aplican
actividades de protección.

Este método está basado en dos importantes principios:

1. la práctica de diseño profesional es caracterizar en términos de conocer, actuar en

situaciones, conversación con la situación y reflexión en acción. Hay un distinto
medio de proceso - orientación en esta aproximación al diseño. Es raro que el
diseñador tenga el diseño en su cabeza por adelantado y que después lo transcriba.
Gran parte del tiempo del diseñador está inmiscuido en una progresiva relación con
su entorno. Una buena metáfora para describirlo es "la conversación con el

27
 material", como un escultor, quien está ocupado en una conversación con el medio.
El escultor modela arcilla y luego mira y siente la escultura para ver lo que ha
llegado a ser.
2. la necesidad para diseñadores de tomar la práctica de trabajo seriamente, de
supervisar las formas en las que el trabajo se está haciendo, en el sentido de una
solución abierta y desplegada para aumentar la complejidad de una situación que el
diseñador solo entiende parcialmente. El hecho por el cual se está tratando con
"actores humanos". Los sistemas necesitan tratar o estar en contacto con las
preocupaciones del usuario. Es definitiva, el reconocimiento de que el trabajo es
fundamentalmente social, envolviendo cooperación y comunicación.

Modelo de desarrollo Concurrente, Como el modelo espiral, el modelo concurrente

provee una meta-descripción del proceso de software. Mientras que la contribución
primaria del modelo espiral es en realidad que esas actividades del software ocurran
repetidamente, la contribución del modelo concurrente es su capacidad de describir las
múltiples actividades del software ocurriendo simultáneamente. Esto no sorprende a nadie
que ha estado involucrado con las diversas actividades que ocurren en algún tiempo del
proceso de desarrollo de software.

Los requerimientos son usualmente "líneas de base", cuando una mayoría de los
requerimientos comienzan a ser bien entendidos, en este tiempo se dedica un esfuerzo
considerable al diseño. Sin embargo, una vez que comienza el diseño, cambios a los
requerimientos son comunes y frecuentes (después de todo, los problemas reales cambian,
y nuestro entendimiento de los problemas desarrollados también). Es desaconsejado
detener el diseño en este camino cuando los requerimientos cambian; en su lugar, existe
una necesidad de modificar y rehacer líneas de base de los requerimientos mientras
progresa el diseño. Por supuesto, dependiendo del impacto de los cambios de los

28
requerimientos el diseño puede no ser afectado, medianamente afectado o se requerirá
comenzar todo de nuevo.

Durante el diseño de arquitectura, es posible que algunos componentes comiencen a

ser bien definidos antes que la arquitectura completa sea estabilizada. En tales casos,
puede ser posible comenzar el diseño detallado en esos componentes estables.
Similarmente, durante el diseño detallado, puede ser posible proceder con la codificación
y quizás regular testeando en forma unitaria o realizando testeo de integración previo a
llevar a cabo el diseño detallado de todos los componentes.

En algunos proyectos, múltiples etapas de un producto se han desarrollado

concurrentemente. Por ejemplo, no es inusual estar haciendo mantención de la etapa 1 de
un producto, y al mismo tiempo estar haciendo mantención sobre un componente 2,
mientras que se está haciendo codificación sobre un componente 3, mientras se realiza
diseño sobre una etapa 4, y especificación de requisitos sobre un componente 5.

En todos estos casos, diversas actividades están ocurriendo simultáneamente.

Eligiendo seguir un proyecto usando técnicas de modelación concurrente, se posibilita el
conocimiento del estado verdadero en el que se encuentra el proyecto

Por otra parte, Montilva (2000), describe las metodologías para satisfacer los
requerimientos del Sistema de Información Web, que se nombraran a continuación, según
el Modelo de Procesos WATCH, comprende 8 fases de desarrollo. Estas fases son
ejecutadas secuencialmente en el sentido de las agujas del reloj, comenzando por la fase
de análisis del dominio y finalizando en la fase de entrega del sistema. Sin embargo,
existe una fuerte iteración entre las fases, ya que de cualquier fase es siempre posible
regresar a la anterior, con el fin de:

29
 a. Modificar un producto intermedio o final tal como, un requerimiento, o una
especificación de diseño, un documento, un componente o un subsistema.
b. Reparar un error detectado en un producto intermedio o final.
c. Revisar y elaborar una tarea o actividad de la fase previa

Fase 1. Análisis del dominio de Aplicación. Esta fase identifica y describe en detalle
el ambiente del sistema, llamado dominio de aplicación, en el cual el software operará. El
objetivo de esta fase es que el grupo de desarrollo adquiera un conocimiento adecuado del
dominio de aplicación (el contexto del sistema). El producto de esta fase es el modelo del
dominio de aplicación. Esta fase comienza por definir el dominio de aplicación,
definiendo los límites y objetivos del sistema, luego, se identifican los procesos y actores
del dominio, los cuales deben ser modelados posteriormente.

Fase 2. Descubrimiento de Requerimientos. El objetivo de esta fase es descubrir y

definir informalmente los requerimientos de los usuarios del sistema. Los principales
productos de esta fase son el documento de definición de requerimientos (DDR) y los
prototipos de la interfaz Usuario / Sistema (U/S).

Fase 3. Especificación de requerimientos. Esta fase tiene como objetivo expresar los
requerimientos de los usuarios de una manera formal o técnica que pueda ser entendida,
sin ambigüedad, por los diseñadores del sistema. La estructura y comportamiento del
sistema es especificada usando tres modelos:

a. Funcional: Se construye utilizando el diagrama de casos de uso de

UML.
b. Estructural: Se representa a través del diagrama de clases de UML.
c. Dinámico: Se representa a través del diagrama de secuencia de UML.

30
 Estos modelos conforman el documento de Especificación de Requerimientos
principal producto de esta fase

Fase 4. Diseño del Sistema. Su principal objetivo es traducir los requerimientos del
usuario en una solución de software, es decir, en una especificación del diseño del
sistema. También se especifican los detalles de las interfaces de los usuarios, la estructura
de la base de datos y la documentación del sistema. El principal producto de esta fase es
el Documento del Diseño del Sistema (DDS).

Fase 5. Diseño de componentes. El objetivo de esta fase consiste en especificar el

diseño de cada componente y el conector de la arquitectura del sistema. El principal
producto de esta fase es el Documento de Diseño de Componentes (DDC), el cual
especifica la estructura (atributos) y comportamiento (operaciones) de cada uno de los
componentes, así como las interfaces utilizadas para conectar los componentes. Cada
componente es una colección integrada de clases que son utilizadas a través de interfaces
bien definidas.

Fase 6. Implementación del Sistema. Los objetivos de la fase de implementación del

sistema consisten en traducir las especificaciones de diseño en un producto de software,
verificar que los programas implementen el diseño y asegurar su calidad. Los productos
de esta fase son un sistema parcialmente probado y la documentación del sistema.

Fase 7. Prueba del Sistema. El objetivo de esta fase es asegurar que el sistema hace
lo que el cliente y los usuarios quieren que haga. El principal producto de esta fase lo
constituye un sistema validado que está listo para ser instalado.
31
 Fase 8. Entrega del Sistema. En esta fase el sistema es transferido de su ambiente de
desarrollo a su ambiente de operación. El producto que se obtiene es un sistema instalado
y en operación.

2.2.6. GESTIÓN DE CONTROL

Según Chiavenato (2004) El control es la función dentro de un proceso que permite
verificar los hechos planeados, mide y evalúa el desempeño y toma la acción correctiva
cuando se necesita. De este modo, el control es un proceso esencialmente regulador

2.2.6.1. TIPOS DE CONTROL

a. Control Preliminar: centrado en prevenir posibles desvíos de calidad y la
cantidad de los recursos empleados; los procedimientos preliminares de control
incluyen todas las actividades de gestión encaminadas a acrecentar la
probabilidad de los resultados obtenidos se comparen favorablemente con los
resultados planeados.
b. Control Concurrente: consiste en el seguimiento de las operaciones en curso
para asegurar que se procura alcanzar los objetivos.
c. Control de Retroalimentación: se centra en los resultados finales. La acción
correctiva está orientada a la mejora del proceso de adquisición de recursos o de
las operaciones en curso.

2.2.7. PARAMETROS DE LOS SISTEMAS

32
 El sistema es un proceso en marcha, según Chiavenato (2004), cualquier cosa que esté
en movimiento o que cambie de estado, en un proceso, puede considerarse que es un
sistema. En una definición más general se considera como un conjunto de elementos que
posee una serie de relaciones con sus atributos.

El sistema se caracteriza por determinados parámetros. Estos son constantes arbitrarias

que determinan, por sus propiedades, el valor y la descripción dimensional de un sistema
específico o de un componente del mismo.

Los parámetros de los sistemas son:

- Entrada o insumo (input): es la fuerza de arranque o de partida del sistema que
provee el material o la energía para la operación de éste.
- Procesamiento, proceso o transformación: es el fenómeno que produce cambios, es
el mecanismo de conversión de insumos en productos o resultados.
- Salida, producto o resultado: es la finalidad para la cual se reunieron elementos y
relaciones del sistema.

2.2.8. SISTEMA DE VARIABLES

2.2.9. VARIABLE

Software para la gestión de control

2.2.9.1. DEFINICIÓN CONCEPTUAL
El Software según Pressman (2005), se define como un programa que al ejecutarse
brinda la información necesaria que en este caso sirve para la gestión del control de
historias clínicas odontológicas.

33
2.2.9.2. DEFINICIÓN OPERACIONAL
Operacionalmente el software para la gestión de control asume la situación actual
en referencia a los datos de insumos, los procesos como se desarrollan y los
resultados o productos obtenidos, considerando además los elementos necesarios
para el software en referencia al análisis de contenido, análisis de interacción y
análisis funcional de manera de idear el diseño y arquitectura del sistema, tomando
en cuenta las especificaciones detalladas de las interfases de los usuarios,
especificación de la estructura de base de datos y documentación del sistema, así
como las pruebas de integración y validación como el funcionamiento global.

2.2.10. CUADRO DE VARIABLES

Objetivo General: Diseñar un software para la gestión de control de las historias clínicas
odontológicas.

Objetivos Específicos Variables Dimensiones Indicadores

gestión de
Control
para la

Identificar la situación Situación Actual ‐ Datos de

actual de la gestión de insumos
control de historias ‐ Datos de
34
clínicas odontológicas procesos
‐ Datos de
resultados o
productos
- Análisis del
Analizar los elementos
Contenido
para el desarrollo del Elementos
- Análisis de la
software de gestión de Necesarios
interacción
control
- Análisis Funcional
- Especificación
detallada de las
Diseñar el software que interfases de los
Diseño y
permita la gestión de usuarios
Arquitectura del
control de las historias - Especificación de la
Sistema
clínicas odontológicas estructura de la base de
datos y documentación
del sistema
- Pruebas de
Probar la efectividad
Integración y
del software de gestión Pruebas del
Validación
de control de historias Software
- Funcionamiento
clínicas odontológicas
Global

35
 CAPÍTULO III.
“MARCO METODOLOGICO”

En este capítulo se presenta el tipo y diseño de la investigación, con los niveles de

información, así como la técnica de análisis de los datos, con el procedimiento aplicado.

3.1 TIPO DE LA INVESTIGACION

El presente estudio tiene como objetivo Diseñar un software para la gestión de

control de las historias clínicas odontológicas, por lo cual se tipifica la investigación como
descriptiva, aplicada y proyecto factible

Es descriptiva por cuanto se plantean los hechos tal y como se dan en la realidad. Para
Hernández, Fernández y Baptista (1998), “Estos estudios buscan especificar las
propiedades importantes de personas, grupos, comunicadores o cualquier otro fenómeno
que sea sostenido a análisis”. (p.60), por otro lado, se evalúan diversos aspectos,
dimensiones o componentes del fenómeno a investigar; en un estudio descriptivo se
selecciona una serie de cuestiones y se evalúa cada una de ellas independientemente.
Además, según Chávez (2001) es de tipo aplicada, debido a que tiene como fin principal
resolver un problema en un periodo de tiempo corto y establecido previamente.

De igual manera se considera proyecto factible, por cuanto se diseña el software

permitiendo con esto resolver un problema, que en este caso es para el control de historias
37
clínicas odontológicas. Al respecto Hurtado de Barrera, (2000) considera que las
investigaciones proyectivas consisten en la elaboración de una propuesta o de un modelo
que constituye una solución a un problema o necesidad de tipo práctico.

3.2 DISEÑO DE LA INVESTIGACIÓN.

En cuanto al diseño de la investigación se considera no experimental, porque la

variable sistemas de información, así como sus dimensiones e indicadores, son analizados
en su estado natural, sin la intervención del investigador. Para Hernández (1998), el
diseño no experimental “Es aquella que se realiza sin manipular deliberadamente las
variables, sino que se tratan los fenómenos tal y como se dan en su contexto natural para
después analizarlos”. (p.184).

Además es transversal descriptivo, por cuanto se recoge la información en un tiempo y

momento único sin pretender, como lo explican Hernández, Fernández y Baptista (1998)
evaluar la evolución del proceso, considerando los datos recogidos para el insumo
necesario que sirva de sustento a la elaboración del software para la gestión de control de
historias odontológicas.

3.3 POBLACIÓN

La población es la unidad de información en toda investigación, de ahí que Bavaresco

(1997), la define como el universo donde se circunscribe la investigación, tomando en
cuenta personas eventos o situaciones importantes para el estudio. Con base en esto se
asume como población a los odontólogos y asistentes del los consultorios del Edificio
38
Consultorios Amado, del municipio Maracaibo, quienes aportaran la información
necesaria para la elaboración del software para la gestión de control de historias clínicas
odontológicas

Cuadro N° 1
Población de la Investigación
N° de Odontólogos por
Consultorios Odontológicos
Consultorio
1 2
2 1
3 1
4 3
5 1
6 4
7 2
8 1
9 2
10 1
TOTAL 18

3.4 TECNICAS DE RECOLECCIÓN DE DATOS

Para la recolección de datos se utilizara la encuesta como técnica, la cual, según

Hurtado de Barrera (2000), se parece a la entrevista con la diferencia que no se establece
diálogo con el entrevistado y el grado de interacción es menor, obteniendo la información
39
a través de un cuestionario. El cuestionario es un instrumento que agrupa una serie de
preguntas relativas a un evento o temática en particular.

3.5 DESCRIPCIÓN DE INSTRUMENTO

El instrumento a utilizar es el cuestionario, diseñado en función de las interrogantes

que determinaran la necesidad de diseñar un software para la gestión de control de las
historias clínicas odontológicas. El cuestionario se constituye con 17 ítems de preguntas
cerradas con dos alternativas Si y No. Ver Anexo N° 1

3.6 VALIDEZ

La validez es la prueba que se realiza al cuestionario para saber si es eficaz en cuanto a

lo que se pretende medir. Para Hernández, Fernández y Baptista (2006), explica que la
validez evidencia la pertinencia que tienen los ítems con los indicadores, dimensiones y
variables.

Para realizar la validez se solicita el aporte de 3 validadores expertos en el tema

quienes revisan los ítems en cuanto a la pertinencia con lo que se quiere medir y con la
redacción. Las opiniones aportadas sirven para mejorar el instrumento definitivo.
Los resultados de la validez se observan en el cuadro siguiente.

40
 Cuadro N° 2
Expertos Validadores
Nombre y Cedula de
Titulo Cargo Observaciones
Apellido Identidad
Separar Ítems 6 y
7, Agregar Item
Dra. En ciencias Docente
Dulce Guerra 4.535.880 sobre
de la Educación URU
observaciones.
VALIDO
Elizabeth de Psicólogo
7.716.909 Psicólogo VALIDO
Carrizo II
Clementina Odontólogo
4.750.631 Odontólogo VALIDO
Persad Gerente

3.7 CONFIABILIDAD

La confiabilidad es una prueba que se aplica para saber si el instrumento es congruente

a lo que se quiere medir. Para este caso se usa una prueba piloto con un grupo de 10
odontólogos seleccionando los del Centro Médico Paraíso, por tener las mismas
características que la población seleccionada.

La confiabilidad se realiza con la fórmula de Kuder Richarson, que es una prueba para
instrumentos con dos alternativas. Hernández y Otros (2006), expresan que este
coeficiente desarrolla un coeficiente para estimar la confiabilidad en una medición.

41
 Al aplicar la prueba piloto en 10 sujetos con las mismas características, se procesaron
los datos con el programa SPSS, versión 16.0, obteniendo 0,85 de coeficiente.

3.8 PROCEDIMIENTO

El desarrollo de la investigación sigue los siguientes pasos:

1. Se seleccionó el problema a investigar y se entrego para que fuese aprobado.
2. Se redacto la problemática y la justificación de la investigación.
3. Se estructuraron los objetivos generales y específicos.
4. Se revisaron diferentes bibliografías, se establecieron los antecedentes, bases
teóricas, y el sistema de variables.
5. Se elaboró el marco metodológico especificando el tipo y diseño de investigación,
se estableció la población, la técnica e instrumentos de recolecci6n de datos y se
determinó la validez y la confiabilidad del instrumento.
6. Posteriormente, se describieron los resultados de la investigación donde se realizo
la discusión y análisis de los resultados, así teniendo la información necesaria para
diseñar el software.
7. Elaboración del Software con su debida prueba de verificación.
8. Elaboración de conclusiones y recomendaciones pertenecientes al estudio.

3.9 PLAN DE ANÁLISIS DE DATOS

Con base en el objetivo de la investigación que es diseñar un software para la gestión

de control de historias odontológicas, se recogió información que sirve de insumo a la
investigadora, de allí que el procedimiento a seguir para el análisis de datos es la
42
distribución frecuencial con porcentajes que permite constatar el comportamiento de los
indicadores, dimensiones y variables.

3.10METODOLOGIA UTILIZADA PARA EL DESARROLLO DEL

SOFTWARE

La metodología seleccionada para el desarrollo, del software para el control de

historias clínicas odontológicas, es el modelo de procesos Watch de Montilva (2000) el
cual puede ser utilizado tanto como para pequeños o medianos proyectos de software.

Este modelo comprende 8 fases de desarrollo las cuales son ejecutables

secuencialmente en el sentido de las agujas del reloj, comenzando por el análisis del
dominio y finalizando en la fase de entrega del sistema. Sin embargo, en lo que respecta a
esta investigación solo se aplicaran 6 de estas fases debido a que 2 de ellas no se adecuan
al contexto de la investigación (diseño de componentes y la entrega del sistema). Las
fases a aplicarse son:

Fase 1. Análisis del Dominio de Aplicación

Fase 2. Descubrimiento de Requerimientos
Fase 3. Especificación de Requerimientos
Fase 4. Diseño del Sistema
Fase 5. Implementación de una interfaz
Fase 6. Prueba del Sistema

43
 CAPITULO IV.
“ANÁLISIS Y DISCUSIÓN DE RESULTADOS.”

En este capítulo se presentan los datos obtenidos durante el proceso de recolección,

para hacer el análisis de éstos, así como la discusión donde se hace la confrontación e
interpretación de los resultados con los cuales se procesa el diagnóstico para la
elaboración del software.

Con el propósito de conocer los datos de insumo, del proceso y de los resultados se
plantearon éstos, presentándolos en cuadros, tomando en cuenta la frecuencia absoluta y
porcentual.

Cuadro N° 3

Datos de Insumo

1 2 3 4 5 FA FR
SI 9 18 12 18 12 69 76,66%
NO 9 0 6 0 6 21 23,33%
TOTAL 90 100%

Cuando se encuestó a la población censal de odontólogos y asistentes, en cuanto a

los datos que se consideran necesarios como insumo para llenar el registro de cada
paciente, y poder conformar la historia odontológica, se observó que el 76,66% de ellos
manifestaron que si se identifica al paciente con su cédula de identidad, seleccionar el
apellido para buscar su historia, tomando en cuenta si el paciente tiene seguro, indicando

45
el género, así como también la fecha de nacimiento. El 23,33% considera que no asume
estos datos de insumo.

Cabe destacar que según se observa, cuando se va a elaborar un software para llevar
el control de la historia de cada uno de los pacientes de manera organizada.

Estos aspectos son considerados en el control preliminar que de acuerdo a Ivancevich,

Lorenzi, Skinner y Crosby (1998), permite saber el estado de los insumos que serán
procesados, para evidenciar si están en buena forma o cumplen con los requerimientos
establecidos

Cuadro N° 4

Datos de Procesos

6 7 8 9 10 FA FR
SI 18 18 18 18 12 84 93,33%
NO 0 0 0 0 6 6 6,66%
TOTAL 90 100%

En el cuadro se muestra que el 93,33% considera que si se indica en la historia la

fecha de ingreso (primera visita) del paciente, registra información sobre la tolerancia del
paciente a la anestesia, registrando todos los aspectos referidos a la salud del paciente, si
presenta alergias a medicamentos, así como se registran fotos del avance del paciente. El
6,66 % opina que no se asumen estos para colocarlo en la historia

Estos datos son importantes para el odontólogo de manera que cuando se le de

atención al paciente pueda tomar todas las precauciones posibles, así como tener sustento
acerca del tratamiento que le colocará, de allí la necesidad de tener todo esto registrado y
poder llevar el control.

46
 Al respecto, Chavenato (2004), señala que el procesamiento o proceso, es el
mecanismo de conversión de insumos en productos o resultados, además estos datos parte
del control concurrente, de acuerdo a Ivancevich y otros (1998), ya que sigue las
operaciones en curso para asegurarse de que se procuran alcanzar los objetivos,

Cuadro N°5

Datos de Resultados

11 12 13 14 15 16 17 FA FR
SI 15 18 15 18 18 18 15 117 92,85%
NO 3 0 3 0 0 0 3 9 07,14%
TOTAL 126 100%

En cuanto a los datos de resultados, el 93,85% de los encuestados manifestó que para
poder llevar el control de cada paciente, es importante registrar en la historia el
diagnóstico obtenido, registrando información sobre el plan de tratamiento, dejar registro
del tratamiento sugerido al paciente, toman nota del presupuesto, llevar el control de los
pagos realizados, así como las fechas de consulta realizada además de la fecha de la
próxima consulta que debe tener el paciente. El 07,14% manifestó que no registra estos
datos.

Para Chiavenato (2004), estos datos son el resultado final del sistema, los productos
producidos por el sistema, exporta el resultado de sus operaciones y mejora el proceso de
la adquisición de recursos, es por ello que estos datos son considerados parte importante
del control concurrente.

47
Una vez aplicada la metodología Watch (Montilva 2000) se procedió al desarrollo del
sistema siguiendo el lineamiento de cada una de las fases y obteniendo los siguientes
procesos:

Fase 1. Analisis del dominio de aplicación

El presente análisis se realizo utilizando los instrumentos de recolección de datos a

través de una entrevista informal elaborada a los odontólogos de la torre de consultorios
amados, la cual arrojo como resultado un proceso desactualizado y redundante, para
efectuar el control de las historias odontológicas a los pacientes tratados.

Debido a lo antes mencionado se desarrollo software para automatizar todos los

procedimientos que se realizaban de forma manual, para el cual fue utilizado el lenguaje
de Programación Python, manejador de base de datos SQLite, dichas herramientas
permitieron desarrollar con mayor facilidad cada proceso requerido tales como: reportes,
consultas y diseño de interfaz.

A través de la identificación de los actores fueron definidos los procesos de la

siguiente manera: Diariamente nuevas personas llegan a consulta con odontólogos, a cada
una de ella le es creada una historia odontológica, la secretaria se encarga de llenar los
datos de identificación del paciente, luego, el paciente es evaluado por el odontólogo y su
asistente, quienes son los encargados de anexar los datos de procedimiento referentes a la
consulta. Posteriormente después de la consulta el odontólogo toma nota de los resultados
y el tratamiento en particular.

Cuadro N° 6
Procesos y Actores del Sistema
48
 Procesos Actores
Creación de Historia, llenado de datos de Secretaria
identificación del paciente (Datos de Insumos)
Anexo de datos del proceso de la consulta Odontólogo y/o Asistente
(Datos de Procesos)
Llenado de datos posteriores a la consulta Odontólogo
(Datos de resultados)

Fase 2. Descubrimiento de requerimientos.

Para el comienzo del desarrollo del sistema, es necesario conocer el conjunto de
requerimientos, características o condiciones que establecen los odontólogos, en cuanto a
los datos de insumo del paciente, del proceso o tratamiento, así como del producto
obtenido luego de ser asistida la persona, todo esto con el propósito de satisfacer las
exigencias y cubrir las expectativas de estos profesionales en relación a aligerar el registro
para llevar control de la historia de cada uno de sus pacientes. Cabe destacar que el
requerimiento más importante es que el software sea fácil de utilizar y brinde seguridad
en cuanto al archivo y registro de las historias odontológicas. Estos se presentan en el
siguiente cuadro.
Cuadro N° 7
Requerimientos y condiciones de la población
Requerimientos Condiciones de la Muestra
Software para la gestión de control de Interfaces agradables y fáciles de usar
historias clínicas odontológicas
Seguridad Que solo pueda ser utilizado por el
odontólogo y empleados

49
 En el cuadro anteriormente expuesto se representan los requerimientos y algunas de
las condiciones establecidas para el desarrollo del sistema, como lo son la elaboración de
una interfaz agradable y de fácil uso, lo cual permite una cómoda interacción con el
usuario. El sistema debe ser fácil de manejar y debe poseer seguridad y confiabilidad de
los datos.

Las necesidades surgidas de la información aportada por los odontólogos y

asistentes, se encuentran reflejadas a continuación:

Requerimientos del sistema

a. Incluir o registrar los datos de insumos, tales como, nombre, apellido y cedula del
paciente, además del género y fecha de nacimiento.
b. Incluir datos de Proceso, tales como, fecha de ingreso e información sobre el
estado general de salud del paciente, así como también, el registro de fotos para
cada paciente
c. Anexar los datos de resultados, relacionados a él diagnostico obtenido, plan de
tratamiento, presupuesto, próxima consulta, entre otros datos necesarios para el
control del odontólogo sobre el paciente.

Fase 3. Especificación de Requerimientos.

El Software para la gestión de control de historias odontológicas, es una herramienta
eficaz para automatizar la información sobre los pacientes, que acuden a consultas
odontológicas, en menor tiempo, aumentando las posibilidades de llevar un registro
ordenado y así aumentando la eficiencia y beneficiando a los odontólogos. El objetivo
50
principal de esta fase es representar las especificaciones de los requerimientos de los
usuarios, a través del modelo funcional de diagrama de casos.

Diagrama de Casos de Uso.

Son documentos que describen la secuencia de eventos de un actor (agente externo) que
utiliza un sistema para completar un proceso. Estos documentos, ejemplifican e incluyen
tácitamente los requerimientos en las historias que narran. Continuación, se muestra el
caso de uso general para el control de historias clínicas odontológicas.

Caso de uso: Control de historias clínicas odontológicas

Actor: Secretaria, Odontólogo y/o Asistente
Propósito: Llevar control sobre las historias odontológicas.
Tipo: general.
Resumen: el sistema le solicita al usuario el login y password, el cual debe ser ingresado
de forma correcta para tener acceso al mismo. El usuario puede registra y modificar datos
del paciente.

SISTEMA

Figura 1. Caso de Uso General.

Fuente Duque (2008)

Seguidamente, se muestra el caso de uso primario del software de gestión de control, el

cual especifica cada uno de los procesos que se ejecutan dentro del dominio de la

51
aplicación. Permitiendo así, obtener una visión más clara de la funcionabilidad del
sistema.

Caso de uso: Control de historias clínicas odontológicas

Actor: Secretaria, Odontólogo y/o Asistente
Propósito: Llevar control sobre las historias odontológicas.
Tipo: Primario.
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:
bitácora, citas, control de pagos, paciente, odontograma y presupuesto.

BITACORA

CITAS

CONTROL DE
PAGOS

PACIENTE

ODONTOGRAMA

PRESUPUESTO

52
 Figura 2. Caso de Uso Primario
Fuente Duque (2008)

Por otra parte, se muestran los diagramas de caso de uso secundarios del sistema, los
cuales especifican de forma detallada los pasos que contiene cada proceso incluido en el
diagrama de caso de uso primario. Para lograr una comprensión más explícita del dominio
de la aplicación. En primer lugar, se muestra el diagrama de caso de uso secundario del
Modulo de Bitácora.

Caso de uso: Bitácora

Actor: Secretaria, Odontólogo y/o Asistente
Propósito: Ver, Crear y Modificar datos del trabajo realizado a los pacientes atendidos en
consulta.
Tipo: Secundario.
Resumen: El usuario puede ver, crear y modificar la información anexada a cada paciente
del trabajo o tratamiento realizado en cada consulta.

CREAR DATOS
DE BITÁCORA

VER DATOS DE
BITÁCORA

MODIFICAR
DATOS DE
BITÁCORA

Figura 3. Caso de Uso Secundario - Bitácora

Fuente Duque (2008)

53
Caso de uso: Citas
Actor: Secretaria, Odontólogo y/o Asistente
Propósito: Ver, Crear y Modificar datos las próximas citas del Paciente
Tipo: Secundario.
Resumen: El usuario puede ver, crear y modificar las fechas y motivos de la próxima cita
del paciente dada por el odontólogo.

CREAR UNA
CITA

VER LAS CITAS

PAUTADAS

MODIFICAR
UNA CITA

Figura 4. Caso de Uso Secundario - Citas

Fuente Duque (2008)

Caso de uso: Control de Pagos

Actor: Secretaria, Odontólogo y/o Asistente
Propósito: Ver, Crear y Modificar los pagos realizados por cada paciente
Tipo: Secundario.
Resumen: El usuario puede ver, crear y modificar, los datos de pagos, como el paciente,
las fechas el monto a pagar y el motivo o concepto.

CREAR UN
PAGO

VER LOS PAGOS

54 REALIZADOS

MODIFICAR
UN PAGO
 Figura 5. Caso de Uso Secundario – Control de pagos
Fuente Duque (2008)

Caso de uso: Paciente

Actor: Secretaria, Odontólogo y/o Asistente
Propósito: Ver, Crear y Modificar los datos personales del paciente
Tipo: Secundario.
Resumen: El usuario puede ver, crear y modificar, los datos personales del paciente.

CREAR
UN
PACIENTE

VER LOS DATOS

DE PACIENTE

MODIFICAR
DATOS DE
PACIENTE
Figura 6. Caso de Uso Secundario - Paciente
Fuente Duque (2008)

55
Caso de uso: Odontograma
Actor: Odontólogo y/o Asistente
Propósito: Ver, Crear y Modificar el odontograma de un paciente
Tipo: Secundario.
Resumen: El usuario puede ver, crear y modificar el odontograma de cada paciente

CREAR UN
ODONTOGRAMA

VER UN
ODONTOGRAMA

MODIFICAR UN
ODONTOGRAMA

Figura 7. Caso de Uso Secundario – Odontograma

Fuente Duque (2008)

Caso de uso: Presupuesto

Actor: Odontólogo
Propósito: Ver, Crear y Modificar el presupuesto dado a un paciente
Tipo: Secundario.
Resumen: El usuario puede ver, crear y modificar el presupuesto que el odontólogo
realiza a cada paciente

CREAR UN
PRESUPUESTO

VER
PRESUPUESTOS
56

MODIFICAR UN
PRESUPUESTO
 Figura 8. Caso de Uso Secundario – Presupuesto
Fuente Duque (2008)

Fase 4. Diseño del Sistema

Una vez descubierto los requerimientos funcionales y no funcionales del usuario y de

la organización se procedió a la elaboración del diseño prototipo del sistema. El lenguaje
utilizado para el desarrollo de software para la gestión de control de historias
odontológicas fue Portable Python, el cual está basado en Python, debido a que es un
lenguaje de programación interpretado interactivo y orientado a objetos; incorpora
módulos, excepciones, dinámica mecanografía, tipos de datos dinámicos y clases de muy
alto nivel Python es uno de los más poderosos lenguajes de programación dinámica que se
utiliza en una amplia variedad de ámbitos de aplicación y se utiliza en muchas empresas e
instituciones de todo el mundo (YouTube, Google, NASA, Firaxis Games, etc.) .

La base de datos fue desarrollada con SQLite el cual es un sistema de gestión de base de
datos relacional, este motor de base de datos no es un proceso independiente con el que el
programa principal se comunica. En lugar de eso, la librería SQLite se enlaza con el
programa pasando a ser parte integral del mismo, además permite bases de datos de hasta
2 Terabytes de tamaño.

57
Fase 5. Implementación del Sistema
En esta fase de implementación del sistema se realizaron una serie de actividades para
traducir las especificaciones del diseño en un producto tipo software. El objetivo
alcanzado en esta fase fue el de tener un sistema parcialmente probado para corroborar si
el sistema cumplía con los requerimientos exigidos así como también la documentación
del sistema.

Fase 6. Prueba del Sistema

En esta fase del desarrollo del software para la gestión de control de historias clínicas
odontológicas, se llevan a cabo un conjunto de pruebas aplicadas al software con el fin de
asegurar que el sistema cumpla con todos los requerimientos exigidos. El objetivo
principal de esta etapa se enfoca en probar el producto desarrollando y operando la
aplicación. Al aplicar la prueba Alfa se presentaron errores al generar la búsqueda de
pacientes, los cuales fueron corregidos. Posteriormente se evaluó el software con una
prueba piloto a un grupo de 5 odontólogos se evidenció que luego de una pequeña
explicación, los usuarios siguen las instrucciones siendo de gran facilidad el proceso,
manifestando lo accesible y sencillo que es este software, además de brindar ventajas al
poder accesar con seguridad los datos de los pacientes.

58
 CAPITULO V
MANUAL DEL SISTEMA

1. Descripción del sistema.

El proyecto es realizado con la finalidad de mejorar los procesos que

se manejan actualmente en los consultorios Odontológicos debido a
que los mismo es realizado de forma manual, por este motivo se
desarrollo un software para la gestión de control de las historias
odontológicas para así solucionar el trabajo tedioso que allí se realiza
diariamente.

El software para la gestión de control de las historias odontológicas se

ha creado con el objetivo de cubrir los requerimientos presentados por
los odontólogos de la Torre de Consultorios de la Clínica Amado. Este
fue codificado en el lenguaje de programación Python y para la
realización de la base de datos se utilizo SQLite.

2. Configuración de hardware y software requerido.

Para que el sistema a utilizar tenga un mayor rendimiento se

recomienda los siguientes requerimientos mínimos de hardware:

Microprocesador Intel Pentium IV de 1.87 Ghz., Memoria RAM 256

MB, Disco Duro de 80 GB, Unidad de CD-ROM 52 X, Monitor, Mouse,
Teclado. Además, para la configuración del software se recomienda
cualquier sistema operativo (cliente/servidor), el servidor de HTTP

60
Apache, los modulos de Python y cualquier manejador de base de
datos.

3. Pantallas del Sistema.

Al ingresar al sistema se muestra la pantalla principal, donde

encontramos el menú en la parte superior donde tenemos distintas
opciones: Inicio, Citas, Pacientes y Pagos
Inicio es la pantalla principal donde se encuentran listadas las citas del
día, con los siguientes datos: Nombre del Paciente, Cedula del
Paciente y Motivo de la Cita. También se encuentra un buscador de
Pacientes, atreves del cual se ingresa la cedula del paciente y al
presionar buscar nos lleva al panel de pacientes

Imagen N° 01 Pantalla de Inicio

61
En el Panel de Paciente, Muestra el Menú en la parte superior,
anteriormente mencionado, y en el cuerpo es reflejado el Nombre del
Paciente, Asociado a la Cedula buscada, y los números de teléfono
del paciente, también se muestra los datos de la Última Visita
Registrada; de igual forma son reflejadas las citas del paciente, los
pagos realizados por el paciente y los odontogramas del paciente, en
el caso que existan ,de lo contrario aparece el mensaje informando
que el paciente no posee esos datos.

Atreves de este panel es posible agregar las citas del paciente, los
pagos realizados y subir los odontogramas del paciente.

Imagen N° 02 Panel del Paciente

62
Siguiendo con el Menú, al dar click en Citas, se muestra un listado de
todas las citas existentes, con las opciones de editar y borrar; también
se encuentra un buscador de citas, atreves del cual se pueden buscar
las citas ya sea por nombre de paciente o fecha de la consulta.

Imagen N° 03 Citas

En la Pantalla Pacientes, encontramos el listado de todos los

pacientes, un buscador de pacientes, sea por cedula o nombre y la
opción para agregar paciente

63
 Imagen N° 04 Pacientes

Por último en Pagos se refleja la información financiera del mes, en

otras palabras se muestra las cantidad en bolívares de los montos por
pagar, y la cantidad de bolívares que ingresó en el mes al odontólogo,
esto es solo para el control del odontólogo, no pretende ser un modo
de facturación.

64
 Imagen N° 05 Pagos

Los Otros formatos para agregar datos se muestran a continuación las

Otros formatos para agregar datos se muestran a continuación las
Imágenes 06, 07 y 08, los cuales corresponden a Agregar Citas,
Agregar Pacientes y Agregar Datos en Bitacora, respectivamente.

Imagen N° 06 Agregar
Citas 65
Imagen N° 07 Agregar Paciente

66
Imagen N° 08 Agregar Datos en Bitácora

67
 CONCLUSIONES

Al identificar la situación actual de la gestión de control de las historias clínicas

odontológicas se observó que los encuestados llevan las historias de manera manual, en
fichas, deben ir agregando de manera manual los datos, cada vez que el paciente asiste a
consulta, aunado a la gran cantidad de papel que van almacenando, el cual sufre por la
humedad, y otros aspectos.
Según la información obtenida se concluye que la gestión de control de las historias
clínicas odontológicas que llevan los doctores, no satisface las expectativas de estos
mismos, en cuanto a la creación y modificación los datos de insumos, procesos y
producto que llevan de los pacientes incluidos en las historias.

Al analizar los elementos para el desarrollo del software se concluyó que este debe
partir de los contenidos requeridos por los odontólogos en cuanto a la información del
paciente (insumo, proceso y producto), detectando la necesidad que estos estén
relacionados unos con otros, los cuales deben vincularse para que sea factible para los
odontólogos y asistentes tener de manera rápida y segura la información que necesita cada
paciente.

Para diseñar el software para la gestión de control de historias clínicas odontológicas

se asume el modelo Watch de Jonas Montilva (2000), con diagramas UML, a través de
los cuales es más fácil visualizar, especificar, construir y documentar un sistema de
software, estableciendo la realidad de la utilización en los requerimientos del sistema.

Las interfaces del software fueron desarrolladas bajo el lenguaje de programación

python, gracias a este se ahorro un tiempo considerable en el desarrollo del programa
69
debido a que con este lenguaje no es necesario compilar ni enlazar. El intérprete se puede
utilizar de modo interactivo, lo que facilitó experimentar con las características del
lenguaje; la base de datos utilizada en este proyecto fue SQLite en su versión 3, la cual
permitirá tener hasta 2 terabyte de tamaño.

Al probar el software se comprobó la efectividad a través de la prueba Alfa

evidenciando que se presenta un error al generar la búsqueda de pacientes, el cual fue
corregido. Luego al procesar el software con una prueba piloto a un grupo de 5
odontólogos se evidenció que luego de una pequeña explicación, los usuarios siguen las
instrucciones siendo de gran facilidad el proceso, manifestando lo accesible y sencillo que
es este software, además de brindar ventajas al poder accesar con seguridad los datos de
los pacientes.

70
 RECOMENDACIONES

Los resultados, conclusiones y elaboración de software permiten sugerir las siguientes

recomendaciones:

‐ Programar talleres de inducción a los odontólogos y asistentes para generar un

ambiente de confianza y seguridad en el manejo de software.

‐ Agregar datos en el software vinculantes con la salud general del paciente que
tuviera relación con el tratamiento odontológico

‐ Divulgar los hallazgos en eventos del área de computación, así como en el sector
profesional odontológico.

‐ Respaldar casa cierto periodo de tiempo la información generada en dispositivos de

almacenamientos, para prevenir una posible pérdida de la información debido a
cualquier problema de avería del computador.

‐ Realizar mantenimiento preventivo al sistema.

72
 BIBLIOGRAFÍA

Chavez, N (2001). Introducción a la investigación educativa. Editorial Maria.

Kendall y Kendall (1998), Análisis y Diseño de Sistemas, 4ta Edición Prentice Hall.

Montilva, J. (1999), Desarrollo de Sistema de Información. Segunda Edicion. Consejo

de publicaciones de la Universidad de los Andes.

Montilva, J. (2000), Modelo de procesos para el desarrollo de software orientado a

objetos.

O’Brien, J. (2001). Sistema de Información General. Cuarta Edición. Bogota. Editorial

Mc Graw Hill

Pressman, R (1998), Sistema de información Cuarta edición. Madrid. Editorial Mc Graw

Hill.

Pressman, R (2000), Ingeniaría de Software. Madrid. Editorial Mc Graw Hill.

SENN, J (1999), Análisis y Diseño de Sistemas de información. Segunda edición.

Colombia. Editorial Mc Graw Hill.

LAUDON, (2004), Sistemas de Información Gerencial. Octava edición. Editorial Pearson

74
Anexo N° 1
A continuación se presentan una serie de afirmaciones, conteste con una X SI o NO
de acuerdo a su caso particular

SI NO
1. Identifica al paciente por cedula de Identidad
2. Selecciona el apellido del paciente para buscar su historia
2. Toma en cuenta si el paciente tiene seguro
3. Indica el género del paciente
4. Toma en cuenta la fecha de nacimiento del paciente
5. Indica la fecha de ingreso (primera visita) del paciente
6. Registra información sobre la tolerancia del paciente a la anestesia
7. Registra Información del estado de salud del paciente
8. Registra información si el paciente presenta alergias a medicamentos
9. Necesita registrar fotos del avance del paciente
10. Registra información del diagnostico obtenido
11. Registra información sobre el plan de tratamiento
12. Deja registrado el tratamiento sugerido al paciente
13. Toma nota del Presupuesto
14. Lleva control de los pagos realizados
15. Toma nota de las fechas de consulta realizada
16. Registra la fecha de la próxima consulta

Observaciones:

76