REPBLICA BOLIVARIANA DE VENEZUELA

UNIVERSIDAD RAFAEL URDANETA

FACULTAD DE INGENIERIA
ESCUELA DE COMPUTACIN






SOFTWARE PARA LA GESTIN
DE CONTROL DE HISTORIAS CLNICAS
ODONTOLGICAS




Trabajo Especial de Grado para optar al Ttulo de Ingeniero en
Computacin




Realizado por:
Br. Duque Persad, Karla Patricia
C.I.: 18.394.188

Tutor Acadmico:
Prof. Erick Ramos


MARACAIBO,ENERO 2009
















SOFTWARE PARA LA GESTIN
DE CONTROL DE HISTORIAS CLNICAS
ODONTOLGICAS





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 acadmico, por su
apoyo en todo momento, por toda la orientacin que me proporciono hasta lograr mi
meta.

A mi mam, novio, tos, primos, por estar siempre presentes en todos aquellos momentos
difciles con que nos pone a prueba la vida, gracias por su apoyo incondicional y sus
orientaciones.

A Efran, por ese gran apoyo, por la compaa, 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 guas.

A mi Mam, por estar siempre ah conmigo, con mis preocupaciones, temores, alegras
y triunfos y darme siempre el apoyo, la comprensin, 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
tambin me ayudaron a realizar este sueo.

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 GESTIN DE CONTROL DE
HISTORIAS CLNICAS ODONTOLGICAS Universidad Rafael Urdaneta.
Facultad de Ingeniera. Escuela de Computacin. Trabajo especial de grado.
Maracaibo, 2008.





RESUMEN


La presente investigacin, tuvo como propsito fundamental el desarrollo de
software para la gestin de control de historias clnicas odontolgicas, con el fin de
tener bien resguardada la informacin 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 poblacin a los
odontlogos de la Torre de Consultorios Amado, del municipio Maracaibo, Edo.
Zulia. Esta investigacin se consider del tipo descriptiva, aplicada y proyecto
factible debido a que desarrolla un software permitiendo con esto resolver un
problema. En cuanto al diseo de investigacin, se considera no experimental y
transversal descriptivo, por cuanto se recoge la informacin en un tiempo y
momento nico; en la investigacin se utiliz como tcnicas de recoleccin de
datos la observacin directa y la encuesta. La metodologa 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: anlisis y
dominio de la aplicacin, descubrimiento de requerimiento, especificacin de
requerimientos, diseo del sistema, implantacin del sistema y prueba del sistema,
debido a que dos de las mismas, diseo de componentes y entrega del sistema,
no se adaptaban al contexto de la investigacin. El lenguaje de programacin
utilizado fue Python y como manejador de base de datos SQLite. Los objetivos
propuestos al inicio de la investigacin fueron cumplidos y se obtuvo como
conclusin que el sistema de informacin automatizado facilita y agiliza de una
manera eficaz la gestin de control de historias odontolgicas.


Palabras Claves: Software, Gestin de Control, Historias

Indice General

NDICE GENERAL

DEDICATORIA --------------------------------------------------------------- III
AGRADECIMIENTOS ------------------------------------------------------ IV
RESUMEN --------------------------------------------------------------------- V
INTRODUCCIN ----------------------------------------------------------- VII

CAPITULO I.

PLANTEAMIENTO Y FORMULACIN DEL PROBLEMA -------- 02
OBJ ETIVOS DE LA INVESTIGACIN --------------------------------- 07
Objetivo General ------------------------------------------------------ 07
Objetivos Especficos ------------------------------------------------- 08
J USTIFICACIN E IMPORTANCIA ------------------------------------- 08
DELIMITACIN ------------------------------------------------------------- 10

CAPITULO II.

ANTECENDENTES DE LA INVESTIGACION ------------------------ 12
FUNDAMENTOS TEORICOS --------------------------------------------- 14

CAPITULO III.

MARCO METODOLGICO ----------------------------------------------- 37
TIPO DE INVESTIGACIN ----------------------------------------------- 37
DISEO DE LA INVESTIGACIN -------------------------------------- 38
Indice General

POBLACIN ----------------------------------------------------------------- 38
TCNICA DE RECOLECCIN DE DATOS ---------------------------- 39
PROCEDIMIENTO DE LA INVESTIGACIN ------------------------- 42
METODOLOGA ---------------------------------------------------------- 43

CAPITULO IV.

ANLISIS Y DISCUSIN DE RESULTADOS ------------------------- 45

CAPITULO V.

MANUAL DEL SISTEMA ------------------------------------------------- 60
CONCLUSIONES ---------------------------------------------------------- 69
RECOMENDACIONES --------------------------------------------------- 72
BIBLIOGRAFA ----------------------------------------------------------- 74
ANEXOS -------------------------------------------------------------------- 76

CAPTULO I
EL PROBLEMA



1.1. PLANTEAMIENTO Y FORMULACIN DEL PROBLEMA
Los cambios gestados durante el siglo XX en el mbito de la informtica y la
comunicacin fueron verdaderamente sorprendentes por el impacto generado en los
distintos mbitos de la sociedad, profundizndose estos cada vez ms en este tercer
milenio donde la tecnologa de la informacin abre puertas y vislumbra un horizonte
distinto y sorpresivo ante los beneficios prcticos que le ofrece al hombre para el
desarrollo de todas sus actividades.
Es as como la tecnologa brinda una serie de ventajas competitivas que permiten el
desarrollo de la globalizacin, modernizacin, e integracin donde todos los elementos a
nivel internacional, nacional, regional y local, pueden coordinarse para brindar procesos
integrados y efectivos en los sectores econmicos sociales, culturales y polticos,
facilitndole 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 fciles de manejar.
En ese mbito de integracin, los sistemas de informacin y los software surgieron
como herramientas precisas para condicionar datos importantes no solo para un ambiente

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 pequeo y recndito espacio
de la tierra, de all que los niveles de eficiencia y efectividad a travs 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 informacin segn 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 quizs puedan cambiar profundamente la manera de
conducir sus negocios, mejorando los procesos tcnicos y operativos al integrar cada uno
de los elementos requeridos dentro del sistema, siendo segn el estndar 729 del IEEE, el
software es el conjunto de los programas de cmputo, procedimientos, reglas,
documentacin y datos asociados que forman parte de las operaciones de un sistema de
computacin
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 tecnologa en si, si no una resultante de ella, que permite una visin

comprensiva, amplia y gestltica de un conjunto complejo dndole una configuracin

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 informacin recibida sea ms 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 da casi toda la informacin se precisa mediante los computadores y por ello,
las empresas estn utilizndolos para convertir datos en informacin valiosa para el
desarrollo de sus operaciones y como antes se mencion, optimizan la gestin al combinar
la informtica con procedimientos regulares y organizados para suministrar a los gerentes
de manera oportuna, la informacin necesaria para la toma de decisiones y el control.
En tal sentido, Venezuela en su deseo de desarrollo y crecimiento ha incorporado en
sus pequeas, medianas y grandes empresas, sistemas de informacin 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 organizacin de manera que el trabajo sea ms fcil
y organizado.
Cabe destacar que pequeas mediana y grandes empresas poseen software con los
cuales pueden organizar informacin diversa y los resultados obtenidos desde el punto de

vista de procesos y productos han sido verdaderamente efectivos, indicando las bondades
que propician tanto a los gerentes o dueos de empresas, como tambin, a los empleados,
clientes, proveedores, competidores y entorno en general, lo cual indica que en este siglo
XXI todas las organizaciones no importa su tamao o rubro, deben contar con estos
programas.
En otro orden de ideas, es de hacer notar que los mdicos, odontlogos, 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 mdica 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 situacin de cada uno de ellos .
Tal es el caso de los odontlogos quienes como profesionales de la salud atienden en
su consultorio a una cantidad de pacientes, cada uno de ellos con problemas ms o menos
similares pero particulares en cuanto a las condiciones que presentan, siendo necesario
desde el primer da hacer triaje para conocer cules son las caractersticas que manifiestan
y poder seguir tratamiento con el propsito de generar los cambios necesarios en el
paciente, de all que se lleve una historia mdica que informa acerca de todas las
eventualidades que haya tenido, sirvindole al doctor de gua para saber cules decisiones
debe asumir .

Para ello se lleva una historia mdica por paciente que se archivan en carpetas y deben
ser consultadas en cada visita del paciente, ocasionando algunas veces prdida 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 odontlogo 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 tecnolgicos se considera necesario asumir el cambio incorporando sistemas
de informacin que no solo pondran a la empresa en la palestra en cuanto a los procesos
administrativos, organizacionales y tecnolgicos, si no que dentro del mercado le
permitira competir por el servicio de calidad he innovacin al facilitar las operaciones
dentro de la misma.
Como situacin problemtica, los odontlogos comparten la inquietud de tener
dificultad para accesar con facilidad a las historias mdicas odontolgicas por falta de
organizacin 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
odontlogo, necesitndose paciencia y mayor tiempo para la bsqueda de cada carpeta.
Esto pudiera ser producto de la falta de preparacin organizacional y de control, tanto
del odontlogo como asistente o enfermera (ro) para llevar la parte administrativa as
como tambin, porque a veces por los altos costos le es imposible contar con este
personal, adems que posiblemente comparta el consultorio con otros colegas, limitando

el espacio para archivar las historias, lo cual trae como consecuencia desorganizacin en
las historias, descuido, olvidos y por ende trabajos poco satisfactorios; de all que se d
prdida 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
aplicacin es interesante disear y ofrecer un software para registrar, almacenar y
organizar las historias mdicas para la gestin de control en los consultorios
odontolgicos tomando en cuenta los criterios o parmetros requeridos en cuanto a las
caractersticas del paciente y de las actividades que realiza el odontlogo, lo cual traera
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 disear software para la gestin de control de historias clnicas
odontolgicas?



OBJETIVOS DE LA INVESTIGACIN

1.1.1. OBJETIVO GENERAL
Disear un software para la gestin de control de las historias clnicas odontolgicas.
1.1.2. OBJETIVOS ESPECFICOS

Identificar la situacin actual de la gestin de control de historias clnicas

odontolgicas.
Analizar los elementos para el desarrollo del software de gestin de control
Disear el software que permita la gestin de control de las historias clnicas
odontolgicas.
Probar la efectividad del software de gestin de control de historias clnicas
odontolgicas.



1.2. JUSTIFICACIN E IMPORTANCIA DE LA INVESTIGACIN
La presente investigacin tiene como objetivo desarrollar un software para la gestin
de control de historias clnicas odontolgicas, considerando que por ello tiene su
relevancia social al brindar alternativas para el trabajo que realiza administrativamente el
odontlogo en su consultorio, permitindole llevar un proceso organizado en cuanto a la
informacin necesaria de cada uno de sus pacientes con el propsito de brindarle la
atencin, tomando en cuenta las caractersticas de rapidez, objetividad cientfica e
integracin.
En cuanto a la relevancia prctica, la presente investigacin pretende proponer un
software para la gestin de control que sirve para todos los odontlogos que laboran en
clnicas grandes medianas o pequeas, por cuanto el programa ofrecido generaliza los
datos que pueden ser utilizados segn las caractersticas de cada uno de estos

consultorios, respetando las individualidades de los pacientes que asisten a las consultas,
resaltando que es prctico el producto brindado por la investigadora al permitirle al
profesional distribuir su tiempo adecuadamente en cuanto a la parte administrativa, de
atencin y la odontolgica, trayendo como resultado que el paciente se sienta satisfecho
del servicio obtenido, adems, estar consciente y seguro de la informacin que su doctor
registra sobre sus casos.
La relevancia cientfica y terica del estudio consiste en haber partido de un hecho
observado y tomando en cuenta la realidad, se desarroll el software para la gestin de
control de historias clnicas odontolgicas, con base en la documentacin terica y tcnica
aportada por los expertos en sistemas, adaptndolo a la situacin 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 problemtica planteada.
Desde el punto de vista metodolgico el estudio se desarrollo tomando en cuenta el
proceso de una investigacin positivista, proyecto factible al partir de hechos objetivos y
proponer alternativas de solucin que son posibles de ejecutar en el ambiente donde se
diagnostic la situacin problema que en este caso, es en los consultorios odontolgicos
de municipio Maracaibo. Adems se considera que deja un aporte a futuros investigadores
primero porque se elaborara un cuestionario donde se pretende describir las
caractersticas, los elementos, los pasos y la metodologa a seguir del software para la
gestin de control de historias clnicas odontolgicas, que puede ser utilizado de manera

10

segura al ser vlido y confiable. Como segundo aspecto el estudio con sus resultados y
conclusiones propicia la aplicabilidad del programa desarrollado generndole 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 contempornea 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 gestin automatizada que se debe implementar en sus procesos tomando en
cuenta las bondades que los avances cientficos, tecnolgicos y de la informacin le
ofrece al hombre para optimizar su calidad de vida tanto personal como profesional y
ocupacional.



1.3. DELIMITACIN
La presente investigacin se enmarca en el rea de la ingeniera de computacin
considerando el desarrollo de un software para la gestin de control de historias clnicas
odontolgicas, tomando en cuenta como unidad de informacin a odontlogos y asistentes
de consultorios pblicos y privados del municipio Maracaibo. El estudio se desarrolla
entre mayo y diciembre 2008.

12

CAPTULO II.
MARCO TERICO



2.1. ANTECEDENTES DE LA INVESTIGACIN
En relacin con la automatizacin de procesos se han realizado diversos estudios,
exponindose a continuacin algunos de ellos que se consideran pertenecientes con el
estudio
A, Cceres (2007) realiz un estudio titulado Sistema de Informacin Web para el
Control de Historias Clnicas, el objetivo del estudio fue resguardar la informacin y
satisfacer al usuario en las necesidades de consultar, ingresar, modificar y eliminar los
datos.
La investigacin fue de tipo descriptiva y el diseo de la investigacin fue de tipo No
Experimental, es decir, se realizo sin manipular deliberadamente variables. La tcnica de
recoleccin de datos utilizada fue la observacin directa.

La Metodologa utilizada para el desarrollo del sistema fue la de Montilva (2000),
donde se utilizaron las siguientes fases: Anlisis del Dominio de Aplicacin,
Descubrimiento de Requerimientos, Especificacin de Requerimientos, Diseo del
Sistema, Implementacin de Interfaz Web y por ultimo Pruebas al Sistema. Para el
desarrollo de la aplicacin se utilizo Windows XP, Macromedia Dreamweaver 8, PHP,
Apache y como manejador de base de datos My SQL

13

Los resultados obtenidos abarcan los objetivos planteados al inicio de la investigacin,

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 Informacin
Automatizado para el control de Procesos Administrativos caso: Coordinacin de
investigacin de la facultad de ingeniera de la URBE. Para esta investigacin se
utilizaron tcnicas de de observacin directa, documental y entrevistas. El diseo de la
investigacin fue aplicada y de campo.

La metodologa utilizada fue la establecida por Senn (1996) la cual consta de 6 fases:
investigacin preliminar, determinacin de requerimientos, diseo del sistema, desarrollo
del software, prueba e implantacin del sistema.

En el desarrollo fsico del sistema se seleccion la herramienta de programacin
Visual Basic 6.0 y la de aplicacin de manejo de sistema de base de datos Access 2000.
Los objetivos planteados al principio de la investigacin fueron cubiertos, los resultados
de la investigacin facilitaron el control de procesos administrativos.

De la misma forma, Hernndez y Rincn (2002) desarrollaron un Sistema de
informacin para el control de acceso y registro de personal a las empresas. La
fundamentacin terica del proyecto consisti en unaamplia documentacin referente a
las teoras de sistemas de programacin y sistemas de control.

La metodologa utilizada fue la planteada por Laudon y Laudon (2000) y consisti en la
aplicacin de las siguientes etapas: definicin del proyecto, anlisis del sistema, diseo,
programacin y prueba.

14

El lenguaje utilizado fue Visual Basic 6.0, Flash 5.0, y la base de datos se cre bajo
Microsoft Access 2000. La tcnica de recoleccin de datos fue la observacin directa, a
travs de la entrevista informal sin formato definido. Como resultado final de la
investigacin, 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. FUNDAMENTACIN TEORICA

Toda persona para poder realizar una investigacin debe apoyarse en conocimientos
tericos. 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 bsqueda de los conceptos
relevantes en esta rea tomando en cuenta las teoras de varios autores.



2.2.1. SOFTWARE

Segn Montilva, J (2004) es el equipamiento lgico de un computador digital,
comprende el conjunto de los componentes lgicos necesarios para hacer posible la
realizacin de una tarea especfica.

En la actualidad, el software es la tecnologa individual ms importante en el mbito
mundial. A medida que la importancia del software ha crecido, se ha intentado de manera
continua desarrollar tecnologas que hagan ms fcil, ms rpida y menos cara la
construccin y el mantenimiento de programas de computacin de alta calidad.

15

Para Pressman (2005), el papel del software ha experimentado un cambio significativo

en un periodo de un poco mayor a 50 aos. Las mejoras sustanciales en el desempeo del
hardware, los cambios profundos en las arquitecturas de cmputo, 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 ms elaborados y
complejos basados en computadoras.



2.2.2. CARACTERISTICAS DEL SOFTWARE

Las caractersticas esenciales del software segn Pressman (2005), son las siguientes:

El software se desarrolla o construye; no se manufactura en el sentido clsico. 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 diseo, pero la fase de manufactura del hardware puede
incluir problemas de calidad inexistentes en el software. Ambas actividades dependen las
personas, pero la relacin de la gente utilizada y el trabajo realizado es diferente por
completo. Ambas actividades requieren la construccin de un producto, pero los
enfoques son diferentes. Los costos del software se concentran en la ingeniera. 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 debera
tener la forma de la curva idealizada. Los defectos sin descubrir causan tasas de fallas

16

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 diseo o el
proceso mediante el cual se pas del diseo al cdigo mquina 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 construccin por
componentes, la mayora del software an se construye a la medida. Considrese la
forma en que se disea y construye un hardware de control para un producto de cmputo.
El ingeniero de diseo dibuja un esquema simple del sistema de circuitos digital, realiza
algunos anlisis fundamentales para asegurarse de que el diseo realizar las funciones
apropiadas y despus busca en los catlogos de componentes digitales cada circuito
integrado de acuerdo con un nmero de parte, una funcin definida y validada, una
interfaz bien definida y un conjunto estandarizado de directrices de integracin. Una vez
seleccionado cada componente, puede solicitrsele para despus ensamblarlo.

Cuando una disciplina de ingeniera evoluciona se crea una coleccin de diseos
estndar de componentes. Los tornillos y los circuitos integrados son slo dos ejemplos de
los miles de componentes estndar que utilizan los ingenieros mecnicos y elctricos al
disear 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
diseo; es decir, en las partes que representan algo nuevo. En el mundo del hardware, la

17

reutilizacin de componentes es una parte natural del proceso de ingeniera. En el mbito

del software, dicha actividad apenas se ha comenzado a extender.

Un componente de software se debe disear 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 creacin de ventanas grficas, mens desplegables y una
amplia variedad de mecanismos de interaccin. Las estructuras de datos y los detalles de
procesamiento requeridos para construir la interfaz estn contenidos en una librera de
componentes reutilizables para la construccin de la interfaz.



2.2.3. CATEGORIAS DEL SOFTWARE

En la actualidad existen siete grandes categoras 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 coleccin de programas escritos
para servir a otros programas. Algunos programas de sistemas (como los compiladores,
editores y utileras para la administracin de archivos) procesan estructuras de
informacin 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 interaccin muy intensa con el hardware de la

18

computadora; utilizacin por mltiples usuarios; operacin concurrente que requiere la

gestin de itinerarios, de comparticin de recursos, y de procesos sofisticados; estructuras
de datos complejas y mltiples interfaces externas.

Software de aplicacin. El software de aplicacin consiste en programas
independientes que resuelven una necesidad de negocios especfica. Las aplicaciones en
esta rea procesan datos empresariales o tcnicos de forma que facilitan las operaciones
de negocios o la toma de decisiones tcnicas o de gestin. Adems del procesamiento de
datos convencional, el software de aplicacin 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 cientfico y de ingeniera. El software cientfico y de ingeniera, que se
caracterizaba por algoritmos devoradores de nmeros, abarca desde la astronoma hasta
la vulcanologa, desde el anlisis de la tensin automotriz hasta la dinmica orbital de los
transbordadores espaciales, y desde la biologa molecular hasta la manufactura
automatizada. Sin embargo, las aplicaciones modernas dentro del rea cientfica y de
ingeniera se alejan en la actualidad de los algoritmos numricos convencionales. El
diseo asistido por computadora, la simulacin de sistemas y otras aplicaciones
interactivas han comenzado a tomar caractersticas de software en tiempo real e incluso
de software de sistemas.

Software empotrado. El software empotrado reside dentro de la memoria de slo
lectura del sistema y con l se implementan y controlan caractersticas y funciones para el
usuario final y el sistema mismo. El software incrustado puede desempear 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

19

funciones digitales de un automvil, como el control de combustible, el despliegue de

datos en el tablero, los sistemas de frenado, etctera).

Software de lnea de productos. El software de lnea de productos, diseado para
proporcionar una capacidad especfica y la utilizacin 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 clculo, grficas por computadora, multimedia,
entretenimiento, manejo de bases de datos, administracin de personal y finanzas en los
negocios).

Aplicaciones basadas en Web. Las WebApps engloban un espectro amplio de
aplicaciones. En su forma ms simple, las WebApps son apenas un poco ms que un
conjunto de archivos de hipertexto ligados que presenta informacin mediante texto y
algunas grficas. Sin embargo, a medida que el comercio electrnico y las aplicaciones
B2B adquieren mayor importancia, las WebApps evolucionan hacia ambientes
computacionales sofisticados que no slo proporcionan caractersticas, funciones de
cmputo y contenidos independientes al usuario final, sino que estn integradas con bases
de datos corporativas y aplicaciones de negocios.

Software de inteligencia artificial. Este software utiliza algoritmos no numricos en
la resolucin de problemas complejos que es imposible abordar por medio de un anlisis
directo. Las aplicaciones dentro de esta rea incluyen la robtica, los sistemas expertos, el
reconocimiento de patrones (imagen y voz), las redes neuronales artificiales, la
comprobacin de teoremas y los juegos en computadora.

20

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 nmero pequeo de
actividades del marco de trabajo aplicable a todos los proyectos de software, sin importar
su tamao o su complejidad.
El siguiente marco de trabajo se puede aplicar en la inmensa mayora de los trabajos de
software:

Comunicacin. Esta actividad del marco de trabajo implica una intensa colaboracin
y comunicacin con los clientes; adems, abarca la investigacin de requisitos y otras
actividades relacionadas.

Planeacin. Esta actividad establece un plan para el trabajo de la ingeniera del
software. Describe las tareas tcnicas que deben realizarse, los riesgos probables, los
recursos que sern requeridos, los productos del trabajo que han de producirse y un
programa de trabajo.

Modelado. Esta actividad abarca la creacin de modelos que permiten al desarrollador
y al cliente entender mejor los requisitos del software y el diseo que lograr
satisfacerlos.

21

Construccin. Esta actividad combina la generacin del cdigo (ya sea manual o
automatizado) y la realizacin de pruebas necesarias para descubrir errores en el cdigo.

Despliegue. El software (como una entidad completa o un incremento completado de
manera parcial) se entrega al cliente, quien evala el producto recibido proporciona
informacin basada en su evaluacin.

Estas cinco actividades genricas del marco de trabajo son tiles durante el desarrollo
de programas pequeos, la creacin de grandes aplicaciones en la red, y en la ingeniera
de sistemas basados en computadoras grandes y complejas. Los detalles proceso del
software sern muy diferentes en cada caso, pero las actividades dentro del marco
permanecern 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, tambin definen la coordinacin entre ellas, enlace y
realimentacin entre las mencionadas etapas. Los modelos prescriptivos no son perfectos,
pero proporcionan una gua til para el desarrollo de software de alta calidad.

Pressman, R. (2005) seala que, se les llama prescriptivos porque prescriben un
conjunto de elementos del proceso: actividades del marco de trabajo, acciones de
ingeniera del software, tareas, productos del trabajo, aseguramiento de la calidad, y
mecanismos de control del cambio para cada proyecto. Cada modelo de proceso prescribe

22

tambin 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 genricas 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 ingeniera del software) de una manera diferente.

2.2.5.1. Modelo de Cascada, algunas veces llamado el ciclo de vida clsico, sugiere un
enfoque sistemtico, secuencial hacia el desarrollo del software, que se inicia con la
especificacin de requerimientos del cliente y que contina con la planeacin, el
modelado, la construccin y el despliegue para culminar en el soporte del software
terminado.

El modelo en cascada es el paradigma ms antiguo; sin embargo, en las dcadas
pasadas, las crticas a este modelo de proceso han ocasionado que an sus ms fervientes
practicantes hayan cuestionado su eficacia. Entre los problemas que algunas veces se
encuentran al aplicar el modelo en cascada estn:

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
acta.

2. Con frecuencia es difcil para el cliente establecer todos los requisitos de manera
explcita. El modelo en cascada lo requiere y se enfrentan dificultades al incorporar
la incertidumbre natural presente en el inicio de muchos proyectos.

23

3. El cliente debe tener paciencia. Una versin 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 revisin del programa.

En un anlisis 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 ms comn 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 caractersticas, funciones y contenido de la informacin). 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 estn fijos y donde el
trabajo se realiza, hasta su conclusin, de una manera lineal.

2.2.5.2. Modelos de Proceso Incremental, En muchas situaciones los requisitos
inciales del software estn bien definidos en forma razonable, pero el enfoque global del
esfuerzo de desarrollo excluye un proceso puramente lineal. Adems, quiz haya una
necesidad imperiosa de proporcionar de manera rpida un conjunto limitado de
funcionalidad para el usuario y despus refinarla y expandirla en las entregas posteriores
del software. En estos casos se elige un modelo de proceso diseado 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

24

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 bsicos, pero muchas caractersticas
suplementarias (algunas conocidas, otras no) no se incorporan. El producto esencial queda
en manos del cliente (o se somete a una evaluacin detallada). Como resultado de la
evaluacin se desarrolla un plan para el incremento siguiente. El plan afronta la
modificacin del producto esencial con el fin de satisfacer de mejor manera las
necesidades del cliente y la entrega de caractersticas y funcionalidades adicionales. Este
proceso se repite despus de la entrega de cada incremento mientras no se haya elaborado
el producto completo.

El modelo de proceso incremental, al igual que la construccin de prototipos y otros
enfoques evolutivos, es iterativo por naturaleza. Pero a diferencia de la construccin 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
implementacin 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) ms personal para implementar el incremento siguiente. Adems, los
incrementos se pueden planear para manejar los riesgos tcnicos. Por ejemplo, un sistema
grande podra requerir la disponibilidad de un hardware nuevo que est en desarrollo y
cuya fecha de entrega es incierta. Sera posible planear los primeros incrementos de forma

25

que se evite el uso de este hardware, lo que permitira la entrega de funcionalidad parcial
a los usuarios finales sin retrasos desordenados.

Modelo DRA, el desarrollo rpido de aplicaciones (DRA) es un modelo de proceso de
software incremental que resalta un ciclo de desarrollo corto. El modelo DRA es una
adaptacin a alta velocidad del modelo en cascada en el que se logra el desarrollo
rpido mediante un enfoque de construccin 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 das).

Como otros modelos de proceso, el enfoque DRA cumple con las actividades
genricas del marco de trabajo que ya se han presentado. La comunicacin trabaja para
entender el problema de negocios y las caractersticas de informacin que debe incluir el
software. La planeacin 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 diseo que sirven como base para la actividad de construccin del
modelo DRA. La construccin resalta el empleo de componentes de software existente y
la aplicacin de la generacin automtica de cdigo. 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 nmero correcto de equipos DRA; 2) si los desarrolladores y clientes no se
comprometen con las actividades rpidas necesarias para completar el sistema en un
marco de tiempo muy breve, los proyectos de DRA fallarn; 3) si un sistema no se puede

26

modelar en forma apropiada, la construccin de los componentes necesarios para el DRA

ser problemtica; 4) si el alto rendimiento es un aspecto importante, y se alcanzar al
convertir interfaces en componentes del sistema, el enfoque DRA podra no funcionar; y
5) el DRA sera inapropiado cuando los riesgos tcnicos 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
conclusin de un producto completo, por lo que se debe presentar una versin limitada
para liberar la presin competitiva y de negocios; se tiene claro un conjunto de requisitos
del producto o sistema esencial, pero todava 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 diseado de manera explcita
para incluir un producto que evolucione con el tiempo.

Construccin 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 debera tomar la interaccin humano-mquina. En stas, y en muchas otras
situaciones, un paradigma de construccin de prototipos puede ofrecer el mejor enfoque.
A pesar de que la construccin de prototipos se puede utilizar como un modelo de proceso
independiente, se emplea ms comnmente como una tcnica 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 construccin de prototipos ayuda al

27

ingeniero de sistemas y al cliente a entender de mejor manera cul ser el resultado de la

construccin cuando los requisitos estn 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 construccin de
prototipos con los aspectos controlados y sistemticos del modelo lineal y secuencial.
Proporciona el potencial para el desarrollo rpido 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 versin incremental podra ser un modelo en papel o
un prototipo, durante las ltimas iteraciones se producen versiones cada vez ms
completas del sistema diseado.
El modelo en espiral se divide en un nmero de actividades de marco de trabajo,
tambin llamadas regiones de tareas , cada una de las regiones estn compuestas por un
conjunto de tareas del trabajo llamado conjunto de tareas que se adaptan a las
caractersticas del proyecto que va a emprenderse en todos los casos se aplican
actividades de proteccin.
Este mtodo est basado en dos importantes principios:
1. la prctica de diseo profesional es caracterizar en trminos de conocer, actuar en
situaciones, conversacin con la situacin y reflexin en accin. Hay un distinto
medio de proceso - orientacin en esta aproximacin al diseo. Es raro que el
diseador tenga el diseo en su cabeza por adelantado y que despus lo transcriba.
Gran parte del tiempo del diseador est inmiscuido en una progresiva relacin con
su entorno. Una buena metfora para describirlo es "la conversacin con el

28

material", como un escultor, quien est ocupado en una conversacin 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 diseadores de tomar la prctica de trabajo seriamente, de
supervisar las formas en las que el trabajo se est haciendo, en el sentido de una
solucin abierta y desplegada para aumentar la complejidad de una situacin que el
diseador 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 cooperacin y comunicacin.
Modelo de desarrollo Concurrente, Como el modelo espiral, el modelo concurrente
provee una meta-descripcin del proceso de software. Mientras que la contribucin
primaria del modelo espiral es en realidad que esas actividades del software ocurran
repetidamente, la contribucin del modelo concurrente es su capacidad de describir las
mltiples actividades del software ocurriendo simultneamente. Esto no sorprende a nadie
que ha estado involucrado con las diversas actividades que ocurren en algn tiempo del
proceso de desarrollo de software.
Los requerimientos son usualmente "lneas de base", cuando una mayora de los
requerimientos comienzan a ser bien entendidos, en este tiempo se dedica un esfuerzo
considerable al diseo. Sin embargo, una vez que comienza el diseo, cambios a los
requerimientos son comunes y frecuentes (despus de todo, los problemas reales cambian,
y nuestro entendimiento de los problemas desarrollados tambin). Es desaconsejado
detener el diseo en este camino cuando los requerimientos cambian; en su lugar, existe
una necesidad de modificar y rehacer lneas de base de los requerimientos mientras
progresa el diseo. Por supuesto, dependiendo del impacto de los cambios de los

29

requerimientos el diseo puede no ser afectado, medianamente afectado o se requerir

comenzar todo de nuevo.
Durante el diseo 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 diseo detallado en esos componentes estables.
Similarmente, durante el diseo detallado, puede ser posible proceder con la codificacin
y quizs regular testeando en forma unitaria o realizando testeo de integracin previo a
llevar a cabo el diseo detallado de todos los componentes.
En algunos proyectos, mltiples etapas de un producto se han desarrollado
concurrentemente. Por ejemplo, no es inusual estar haciendo mantencin de la etapa 1 de
un producto, y al mismo tiempo estar haciendo mantencin sobre un componente 2,
mientras que se est haciendo codificacin sobre un componente 3, mientras se realiza
diseo sobre una etapa 4, y especificacin de requisitos sobre un componente 5.
En todos estos casos, diversas actividades estn ocurriendo simultneamente.
Eligiendo seguir un proyecto usando tcnicas de modelacin concurrente, se posibilita el
conocimiento del estado verdadero en el que se encuentra el proyecto
Por otra parte, Montilva (2000), describe las metodologas para satisfacer los
requerimientos del Sistema de Informacin Web, que se nombraran a continuacin, segn
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 anlisis del dominio y finalizando en la fase de entrega del sistema. Sin embargo,
existe una fuerte iteracin entre las fases, ya que de cualquier fase es siempre posible
regresar a la anterior, con el fin de:

30

a. Modificar un producto intermedio o final tal como, un requerimiento, o una

especificacin de diseo, 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. Anlisis del dominio de Aplicacin. Esta fase identifica y describe en detalle
el ambiente del sistema, llamado dominio de aplicacin, en el cual el software operar. El
objetivo de esta fase es que el grupo de desarrollo adquiera un conocimiento adecuado del
dominio de aplicacin (el contexto del sistema). El producto de esta fase es el modelo del
dominio de aplicacin. Esta fase comienza por definir el dominio de aplicacin,
definiendo los lmites 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 definicin de requerimientos (DDR) y los
prototipos de la interfaz Usuario / Sistema (U/S).

Fase 3. Especificacin de requerimientos. Esta fase tiene como objetivo expresar los
requerimientos de los usuarios de una manera formal o tcnica que pueda ser entendida,
sin ambigedad, por los diseadores 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 travs del diagrama de clases de UML.
c. Dinmico: Se representa a travs del diagrama de secuencia de UML.

31

Estos modelos conforman el documento de Especificacin de Requerimientos
principal producto de esta fase

Fase 4. Diseo del Sistema. Su principal objetivo es traducir los requerimientos del
usuario en una solucin de software, es decir, en una especificacin del diseo del
sistema. Tambin se especifican los detalles de las interfaces de los usuarios, la estructura
de la base de datos y la documentacin del sistema. El principal producto de esta fase es
el Documento del Diseo del Sistema (DDS).

Fase 5. Diseo de componentes. El objetivo de esta fase consiste en especificar el
diseo de cada componente y el conector de la arquitectura del sistema. El principal
producto de esta fase es el Documento de Diseo 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 coleccin integrada de clases que son utilizadas a travs de interfaces
bien definidas.


Fase 6. Implementacin del Sistema. Los objetivos de la fase de implementacin del
sistema consisten en traducir las especificaciones de diseo en un producto de software,
verificar que los programas implementen el diseo y asegurar su calidad. Los productos
de esta fase son un sistema parcialmente probado y ladocumentacin 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.

32

Fase 8. Entrega del Sistema. En esta fase el sistema es transferido de su ambiente de
desarrollo a su ambiente de operacin. El producto que se obtiene es un sistema instalado
y en operacin.



2.2.6. GESTIN DE CONTROL
Segn Chiavenato (2004) El control es la funcin dentro de un proceso que permite
verificar los hechos planeados, mide y evala el desempeo y toma la accin 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 desvos de calidad y la
cantidad de los recursos empleados; los procedimientos preliminares de control
incluyen todas las actividades de gestin 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 Retroalimentacin: se centra en los resultados finales. La accin
correctiva est orientada a la mejora del proceso de adquisicin de recursos o de
las operaciones en curso.



2.2.7. PARAMETROS DE LOS SISTEMAS

33

El sistema es un proceso en marcha, segn Chiavenato (2004), cualquier cosa que est
en movimiento o que cambie de estado, en un proceso, puede considerarse que es un
sistema. En una definicin ms general se considera como un conjunto de elementos que
posee una serie de relaciones con sus atributos.

El sistema se caracteriza por determinados parmetros. Estos son constantes arbitrarias
que determinan, por sus propiedades, el valor y la descripcin dimensional de un sistema
especfico o de un componente del mismo.

Los parmetros de los sistemas son:
- Entrada o insumo (input): es la fuerza de arranque o de partida del sistema que
provee el material o la energa para la operacin de ste.
- Procesamiento, proceso o transformacin: es el fenmeno que produce cambios, es
el mecanismo de conversin 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 gestin de control
2.2.9.1. DEFINICIN CONCEPTUAL
El Software segn Pressman (2005), se define como un programa que al ejecutarse
brinda la informacin necesaria que en este caso sirve para la gestin del control de
historias clnicas odontolgicas.

34

2.2.9.2. DEFINICIN OPERACIONAL
Operacionalmente el software para la gestin de control asume la situacin actual
en referencia a los datos de insumos, los procesos como se desarrollan y los
resultados o productos obtenidos, considerando adems los elementos necesarios
para el software en referencia al anlisis de contenido, anlisis de interaccin y
anlisis funcional de manera de idear el diseo y arquitectura del sistema, tomando
en cuenta las especificaciones detalladas de las interfases de los usuarios,
especificacin de la estructura de base de datos y documentacin del sistema, as
como las pruebas de integracin y validacin como el funcionamiento global.



2.2.10. CUADRO DE VARIABLES

Objetivo General: Disear un software para la gestin de control de las historias clnicas
odontolgicas.









Objetivos Especficos Variables Dimensiones Indicadores
Identificar la situacin
actual de la gestin de
control de historias
S
o
f
t
w
a
r
e

p
a
r
a

l
a

g
e
s
t
i

n

d
e

C
o
n
t
r
o
l
Situacin Actual Datos de
insumos
Datos de

35

clnicas odontolgicas procesos

Datos de
resultados o
productos
Analizar los elementos
para el desarrollo del
software de gestin de
control
Elementos
Necesarios
- Anlisis del
Contenido
- Anlisis de la
interaccin
- Anlisis Funcional
Disear el software que
permita la gestin de
control de las historias
clnicas odontolgicas
Diseo y
Arquitectura del
Sistema
- Especificacin
detallada de las
interfases de los
usuarios
- Especificacin de la
estructura de la base de
datos y documentacin
del sistema
Probar la efectividad
del software de gestin
de control de historias
clnicas odontolgicas
Pruebas del
Software
- Pruebas de
Integracin y
Validacin
- Funcionamiento
Global












































37

CAPTULO III.
MARCO METODOLOGICO



En este captulo se presenta el tipo y diseo de la investigacin, con los niveles de
informacin, as como la tcnica de anlisis de los datos, con el procedimiento aplicado.



3.1 TIPO DE LA INVESTIGACION

El presente estudio tiene como objetivo Disear un software para la gestin de
control de las historias clnicas odontolgicas, por lo cual se tipifica la investigacin como
descriptiva, aplicada y proyecto factible

Es descriptiva por cuanto se plantean los hechos tal y como se dan en la realidad. Para
Hernndez, Fernndez y Baptista (1998), Estos estudios buscan especificar las
propiedades importantes de personas, grupos, comunicadores o cualquier otro fenmeno
que sea sostenido a anlisis. (p.60), por otro lado, se evalan diversos aspectos,
dimensiones o componentes del fenmeno a investigar; en un estudio descriptivo se
selecciona una serie de cuestiones y se evala cada una de ellas independientemente.
Adems, segn Chvez (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 disea el software
permitiendo con esto resolver un problema, que en este caso es para el control de historias
38

clnicas odontolgicas. Al respecto Hurtado de Barrera, (2000) considera que las

investigaciones proyectivas consisten en la elaboracin de una propuesta o de un modelo
que constituye una solucin a un problema o necesidad de tipo prctico.



3.2 DISEO DE LA INVESTIGACIN.

En cuanto al diseo de la investigacin se considera no experimental, porque la
variable sistemas de informacin, as como sus dimensiones e indicadores, son analizados
en su estado natural, sin la intervencin del investigador. Para Hernndez (1998), el
diseo no experimental Es aquella que se realiza sin manipular deliberadamente las
variables, sino que se tratan los fenmenos tal y como se dan en su contexto natural para
despus analizarlos. (p.184).

Adems es transversal descriptivo, por cuanto se recoge la informacin en un tiempo y
momento nico sin pretender, como lo explican Hernndez, Fernndez y Baptista (1998)
evaluar la evolucin del proceso, considerando los datos recogidos para el insumo
necesario que sirva de sustento a la elaboracin del software para la gestin de control de
historias odontolgicas.



3.3 POBLACIN

La poblacin es la unidad de informacin en toda investigacin, de ah que Bavaresco
(1997), la define como el universo donde se circunscribe la investigacin, tomando en
cuenta personas eventos o situaciones importantes para el estudio. Con base en esto se
asume como poblacin a los odontlogos y asistentes del los consultorios del Edificio
39

Consultorios Amado, del municipio Maracaibo, quienes aportaran la informacin

necesaria para la elaboracin del software para la gestin de control de historias clnicas
odontolgicas

Cuadro N 1
Poblacin de la Investigacin
Consultorios Odontolgicos
N de Odontlogos por
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 RECOLECCIN DE DATOS

Para la recoleccin de datos se utilizara la encuesta como tcnica, la cual, segn
Hurtado de Barrera (2000), se parece a la entrevista con la diferencia que no se establece
dilogo con el entrevistado y el grado de interaccin es menor, obteniendo la informacin
40

a travs de un cuestionario. El cuestionario es un instrumento que agrupa una serie de

preguntas relativas a un evento o temtica en particular.



3.5 DESCRIPCIN DE INSTRUMENTO

El instrumento a utilizar es el cuestionario, diseado en funcin de las interrogantes
que determinaran la necesidad de disear un software para la gestin de control de las
historias clnicas odontolgicas. 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 Hernndez, Fernndez 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
redaccin. Las opiniones aportadas sirven para mejorar el instrumento definitivo.
Los resultados de la validez se observan en el cuadro siguiente.




41

Cuadro N 2
Expertos Validadores
Nombre y
Apellido
Cedula de
Identidad
Titulo Cargo Observaciones
Dulce Guerra 4.535.880
Dra. En ciencias
de la Educacin
Docente
URU
Separar tems 6 y
7, Agregar Item
sobre
observaciones.
VALIDO
Elizabeth de
Carrizo
7.716.909 Psiclogo
Psiclogo
II
VALIDO
Clementina
Persad
4.750.631 Odontlogo
Odontlogo
Gerente
VALIDO



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
odontlogos seleccionando los del Centro Mdico Paraso, por tener las mismas
caractersticas que la poblacin seleccionada.

La confiabilidad se realiza con la frmula de Kuder Richarson, que es una prueba para
instrumentos con dos alternativas. Hernndez y Otros (2006), expresan que este
coeficiente desarrolla un coeficiente para estimar la confiabilidad en una medicin.

42

Al aplicar la prueba piloto en 10 sujetos con las mismas caractersticas, se procesaron

los datos con el programa SPSS, versin 16.0, obteniendo 0,85 de coeficiente.



3.8 PROCEDIMIENTO

El desarrollo de la investigacin sigue los siguientes pasos:
1. Se seleccion el problema a investigar y se entrego para que fuese aprobado.
2. Se redacto la problemtica y la justificacin de la investigacin.
3. Se estructuraron los objetivos generales y especficos.
4. Se revisaron diferentes bibliografas, se establecieron los antecedentes, bases
tericas, y el sistema de variables.
5. Se elabor el marco metodolgico especificando el tipo y diseo de investigacin,
se estableci la poblacin, la tcnica e instrumentos de recolecci6n de datos y se
determin la validez y la confiabilidad del instrumento.
6. Posteriormente, se describieron los resultados de la investigacin donde se realizo
la discusin y anlisis de los resultados, as teniendo la informacin necesaria para
disear el software.
7. Elaboracin del Software con su debida prueba de verificacin.
8. Elaboracin de conclusiones y recomendaciones pertenecientes al estudio.



3.9 PLAN DE ANLISIS DE DATOS

Con base en el objetivo de la investigacin que es disear un software para la gestin
de control de historias odontolgicas, se recogi informacin que sirve de insumo a la
investigadora, de all que el procedimiento a seguir para el anlisis de datos es la
43

distribucin frecuencial con porcentajes que permite constatar el comportamiento de los

indicadores, dimensiones y variables.



3.10 METODOLOGIA UTILIZADA PARA EL DESARROLLO DEL
SOFTWARE

La metodologa seleccionada para el desarrollo, del software para el control de
historias clnicas odontolgicas, es el modelo de procesos Watch de Montilva (2000) el
cual puede ser utilizado tanto como para pequeos 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 anlisis del
dominio y finalizando en la fase de entrega del sistema. Sin embargo, en lo que respecta a
esta investigacin solo se aplicaran 6 de estas fases debido a que 2 de ellas no se adecuan
al contexto de la investigacin (diseo de componentes y la entrega del sistema). Las
fases a aplicarse son:

Fase 1. Anlisis del Dominio de Aplicacin
Fase 2. Descubrimiento de Requerimientos
Fase 3. Especificacin de Requerimientos
Fase 4. Diseo del Sistema
Fase 5. Implementacin de una interfaz
Fase 6. Prueba del Sistema

45

CAPITULO IV.
ANLISIS Y DISCUSIN DE RESULTADOS.



En este captulo se presentan los datos obtenidos durante el proceso de recoleccin,
para hacer el anlisis de stos, as como la discusin donde se hace la confrontacin e
interpretacin de los resultados con los cuales se procesa el diagnstico para la
elaboracin del software.
Con el propsito de conocer los datos de insumo, del proceso y de los resultados se
plantearon stos, presentndolos 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 poblacin censal de odontlogos 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 odontolgica, se observ que el 76,66% de ellos
manifestaron que si se identifica al paciente con su cdula de identidad, seleccionar el
apellido para buscar su historia, tomando en cuenta si el paciente tiene seguro, indicando

46

el gnero, as como tambin la fecha de nacimiento. El 23,33% considera que no asume

estos datos de insumo.
Cabe destacar que segn 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 sern
procesados, para evidenciar si estn 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 informacin 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 odontlogo de manera que cuando se le de
atencin 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.

47

Al respecto, Chavenato (2004), seala que el procesamiento o proceso, es el

mecanismo de conversin de insumos en productos o resultados, adems 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 N5
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
diagnstico obtenido, registrando informacin 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 adems de la fecha de la
prxima 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 adquisicin de recursos, es por ello que estos datos son considerados parte importante
del control concurrente.

48

Una vez aplicada la metodologa 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 aplicacin

El presente anlisis se realizo utilizando los instrumentos de recoleccin de datos a
travs de una entrevista informal elaborada a los odontlogos de la torre de consultorios
amados, la cual arrojo como resultado un proceso desactualizado y redundante, para
efectuar el control de las historias odontolgicas 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 Programacin Python, manejador de base de datos SQLite, dichas herramientas
permitieron desarrollar con mayor facilidad cada proceso requerido tales como: reportes,
consultas y diseo de interfaz.

A travs de la identificacin de los actores fueron definidos los procesos de la
siguiente manera: Diariamente nuevas personas llegan a consulta con odontlogos, a cada
una de ella le es creada una historia odontolgica, la secretaria se encarga de llenar los
datos de identificacin del paciente, luego, el paciente es evaluado por el odontlogo y su
asistente, quienes son los encargados de anexar los datos de procedimiento referentes a la
consulta. Posteriormente despus de la consulta el odontlogo toma nota de los resultados
y el tratamiento en particular.

Cuadro N 6
Procesos y Actores del Sistema

49

Procesos Actores
Creacin de Historia, llenado de datos de
identificacin del paciente (Datos de Insumos)
Secretaria
Anexo de datos del proceso de la consulta
(Datos de Procesos)
Odontlogo y/o Asistente
Llenado de datos posteriores a la consulta
(Datos de resultados)
Odontlogo


Fase 2. Descubrimiento de requerimientos.
Para el comienzo del desarrollo del sistema, es necesario conocer el conjunto de
requerimientos, caractersticas o condiciones que establecen los odontlogos, 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 propsito de satisfacer las
exigencias y cubrir las expectativas de estos profesionales en relacin a aligerar el registro
para llevar control de la historia de cada uno de sus pacientes. Cabe destacar que el
requerimiento ms importante es que el software sea fcil de utilizar y brinde seguridad
en cuanto al archivo y registro de las historias odontolgicas. Estos se presentan en el
siguiente cuadro.
Cuadro N 7
Requerimientos y condiciones de la poblacin
Requerimientos Condiciones de la Muestra
Software para la gestin de control de
historias clnicas odontolgicas
Interfaces agradables y fciles de usar
Seguridad Que solo pueda ser utilizado por el
odontlogo y empleados

50

En el cuadro anteriormente expuesto se representan los requerimientos y algunas de
las condiciones establecidas para el desarrollo del sistema, como lo son la elaboracin de
una interfaz agradable y de fcil uso, lo cual permite una cmoda interaccin con el
usuario. El sistema debe ser fcil de manejar y debe poseer seguridad y confiabilidad de
los datos.

Las necesidades surgidas de la informacin aportada por los odontlogos y
asistentes, se encuentran reflejadas a continuacin:


Requerimientos del sistema
a. Incluir o registrar los datos de insumos, tales como, nombre, apellido y cedula del
paciente, adems del gnero y fecha de nacimiento.
b. Incluir datos de Proceso, tales como, fecha de ingreso e informacin sobre el
estado general de salud del paciente, as como tambin, el registro de fotos para
cada paciente
c. Anexar los datos de resultados, relacionados a l diagnostico obtenido, plan de
tratamiento, presupuesto, prxima consulta, entre otros datos necesarios para el
control del odontlogo sobre el paciente.


Fase 3. Especificacin de Requerimientos.
El Software para la gestin de control de historias odontolgicas, es una herramienta
eficaz para automatizar la informacin sobre los pacientes, que acuden a consultas
odontolgicas, en menor tiempo, aumentando las posibilidades de llevar un registro
ordenado y as aumentando la eficiencia y beneficiando a los odontlogos. El objetivo

51

principal de esta fase es representar las especificaciones de los requerimientos de los

usuarios, a travs 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
tcitamente los requerimientos en las historias que narran. Continuacin, se muestra el
caso de uso general para el control de historias clnicas odontolgicas.

Caso de uso: Control de historias clnicas odontolgicas
Actor: Secretaria, Odontlogo y/o Asistente
Propsito: Llevar control sobre las historias odontolgicas.
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.





Figura 1. Caso de Uso General.
Fuente Duque (2008)


Seguidamente, se muestra el caso de uso primario del software de gestin de control, el
cual especifica cada uno de los procesos que se ejecutan dentro del dominio de la
SISTEMA

52

aplicacin. Permitiendo as, obtener una visin ms clara de la funcionabilidad del

sistema.

Caso de uso: Control de historias clnicas odontolgicas
Actor: Secretaria, Odontlogo y/o Asistente
Propsito: Llevar control sobre las historias odontolgicas.
Tipo: Primario.
Resumen: El usuario puede realizar los diferentes procesos de cada uno de los mdulos
que son ejecutados por el sistema, segn sea el caso; los mdulos del sistema son:
bitcora, citas, control de pagos, paciente, odontograma y presupuesto.

















BITACORA
CITAS
CONTROLDE
PAGOS
PACIENTE
ODONTOGRAMA
PRESUPUESTO

53

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 comprensin ms explcita del dominio
de la aplicacin. En primer lugar, se muestra el diagrama de caso de uso secundario del
Modulo de Bitcora.

Caso de uso: Bitcora
Actor: Secretaria, Odontlogo y/o Asistente
Propsito: 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 informacin anexada a cada paciente
del trabajo o tratamiento realizado en cada consulta.











Figura 3. Caso de Uso Secundario - Bitcora
Fuente Duque (2008)

VERDATOSDE
BITCORA
CREARDATOS
DEBITCORA
MODIFICAR
DATOSDE
BITCORA

54

Caso de uso: Citas

Actor: Secretaria, Odontlogo y/o Asistente
Propsito: Ver, Crear y Modificar datos las prximas citas del Paciente
Tipo: Secundario.
Resumen: El usuario puede ver, crear y modificar las fechas y motivos de la prxima cita
del paciente dada por el odontlogo.








Figura 4. Caso de Uso Secundario - Citas
Fuente Duque (2008)

Caso de uso: Control de Pagos
Actor: Secretaria, Odontlogo y/o Asistente
Propsito: 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.



VERLASCITAS
PAUTADAS
CREARUNA
CITA
MODIFICAR
UNACITA
VERLOSPAGOS
REALIZADOS
CREARUN
PAGO
MODIFICAR
UNPAGO

55

Figura 5. Caso de Uso Secundario Control de pagos
Fuente Duque (2008)

Caso de uso: Paciente
Actor: Secretaria, Odontlogo y/o Asistente
Propsito: Ver, Crear y Modificar los datos personales del paciente
Tipo: Secundario.
Resumen: El usuario puede ver, crear y modificar, los datos personales del paciente.












Figura 6. Caso de Uso Secundario - Paciente
Fuente Duque (2008)
VERLOSDATOS
DEPACIENTE
CREARUN
PACIENTE
MODIFICAR
DATOSDE
PACIENTE

56

Caso de uso: Odontograma
Actor: Odontlogo y/o Asistente
Propsito: Ver, Crear y Modificar el odontograma de un paciente
Tipo: Secundario.
Resumen: El usuario puede ver, crear y modificar el odontograma de cada paciente








Figura 7. Caso de Uso Secundario Odontograma
Fuente Duque (2008)

Caso de uso: Presupuesto
Actor: Odontlogo
Propsito: Ver, Crear y Modificar el presupuesto dado a un paciente
Tipo: Secundario.
Resumen: El usuario puede ver, crear y modificar el presupuesto que el odontlogo
realiza a cada paciente




VERUN
ODONTOGRAMA
CREARUN
ODONTOGRAMA
MODIFICARUN
ODONTOGRAMA
VER
PRESUPUESTOS
CREARUN
PRESUPUESTO
MODIFICARUN
PRESUPUESTO

57

Figura 8. Caso de Uso Secundario Presupuesto
Fuente Duque (2008)


Fase 4. Diseo del Sistema
Una vez descubierto los requerimientos funcionales y no funcionales del usuario y de
la organizacin se procedi a la elaboracin del diseo prototipo del sistema. El lenguaje
utilizado para el desarrollo de software para la gestin de control de historias
odontolgicas fue Portable Python, el cual est basado en Python, debido a que es un
lenguaje de programacin interpretado interactivo y orientado a objetos; incorpora
mdulos, excepciones, dinmica mecanografa, tipos de datos dinmicos y clases de muy
alto nivel Python es uno de los ms poderosos lenguajes de programacin dinmica que se
utiliza en una amplia variedad de mbitos de aplicacin 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 gestin 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 librera SQLite se enlaza con el
programa pasando a ser parte integral del mismo, adems permite bases de datos de hasta
2 Terabytes de tamao.

58

Fase 5. Implementacin del Sistema

En esta fase de implementacin del sistema se realizaron una serie de actividades para
traducir las especificaciones del diseo en un producto tipo software. El objetivo
alcanzado en esta fase fue el de tener un sistema parcialmente probado para corroborar si
el sistema cumpla con los requerimientos exigidos as como tambin la documentacin
del sistema.


Fase 6. Prueba del Sistema
En esta fase del desarrollo del software para la gestin de control de historias clnicas
odontolgicas, 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
aplicacin. Al aplicar la prueba Alfa se presentaron errores al generar la bsqueda de
pacientes, los cuales fueron corregidos. Posteriormente se evalu el software con una
prueba piloto a un grupo de 5 odontlogos se evidenci que luego de una pequea
explicacin, los usuarios siguen las instrucciones siendo de gran facilidad el proceso,
manifestando lo accesible y sencillo que es este software, adems de brindar ventajas al
poder accesar con seguridad los datos de los pacientes.


60

CAPITULO V
MANUAL DEL SISTEMA

1. Descripcin del sistema.

El proyecto es realizado con la finalidad de mejorar los procesos que
se manejan actualmente en los consultorios Odontolgicos debido a
que los mismo es realizado de forma manual, por este motivo se
desarrollo un software para la gestin de control de las historias
odontolgicas para as solucionar el trabajo tedioso que all se realiza
diariamente.

El software para la gestin de control de las historias odontolgicas se
ha creado con el objetivo de cubrir los requerimientos presentados por
los odontlogos de la Torre de Consultorios de la Clnica Amado. Este
fue codificado en el lenguaje de programacin Python y para la
realizacin de la base de datos se utilizo SQLite.

2. Configuracin de hardware y software requerido.

Para que el sistema a utilizar tenga un mayor rendimiento se
recomienda los siguientes requerimientos mnimos 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. Adems, para la configuracin del software se recomienda
cualquier sistema operativo (cliente/servidor), el servidor de HTTP
61

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
da, con los siguientes datos: Nombre del Paciente, Cedula del
Paciente y Motivo de la Cita. Tambin 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
62

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 nmeros de telfono
del paciente, tambin 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

63

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; tambin
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.



En la Pantalla Pacientes, encontramos el listado de todos los
pacientes, un buscador de pacientes, sea por cedula o nombre y la
opcin para agregar paciente

Imagen N 03 Citas

64

Por ltimo en Pagos se refleja la informacin financiera del mes, en
otras palabras se muestra las cantidad en bolvares de los montos por
pagar, y la cantidad de bolvares que ingres en el mes al odontlogo,
esto es solo para el control del odontlogo, no pretende ser un modo
de facturacin.

Imagen N 04 Pacientes

65

Los Otros formatos para agregar datos se muestran a continuacin las
Otros formatos para agregar datos se muestran a continuacin las
Imgenes 06, 07 y 08, los cuales corresponden a Agregar Citas,
Agregar Pacientes y Agregar Datos en Bitacora, respectivamente.
Imagen N 05 Pagos

Imagen N 06 Agregar
Citas
66

Imagen N 07 Agregar Paciente
67

Imagen N 08 Agregar Datos en Bitcora

69

CONCLUSIONES



Al identificar la situacin actual de la gestin de control de las historias clnicas
odontolgicas 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.
Segn la informacin obtenida se concluye que la gestin de control de las historias
clnicas odontolgicas que llevan los doctores, no satisface las expectativas de estos
mismos, en cuanto a la creacin y modificacin 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 odontlogos en cuanto a la informacin del
paciente (insumo, proceso y producto), detectando la necesidad que estos estn
relacionados unos con otros, los cuales deben vincularse para que sea factible para los
odontlogos y asistentes tener de manera rpida y segura la informacin que necesita cada
paciente.
Para disear el software para la gestin de control de historias clnicas odontolgicas
se asume el modelo Watch de Jonas Montilva (2000), con diagramas UML, a travs de
los cuales es ms fcil visualizar, especificar, construir y documentar un sistema de
software, estableciendo la realidad de la utilizacin en los requerimientos del sistema.
Las interfaces del software fueron desarrolladas bajo el lenguaje de programacin
python, gracias a este se ahorro un tiempo considerable en el desarrollo del programa
70

debido a que con este lenguaje no es necesario compilar ni enlazar. El intrprete se puede
utilizar de modo interactivo, lo que facilit experimentar con las caractersticas del
lenguaje; la base de datos utilizada en este proyecto fue SQLite en su versin 3, la cual
permitir tener hasta 2 terabyte de tamao.
Al probar el software se comprob la efectividad a travs de la prueba Alfa
evidenciando que se presenta un error al generar la bsqueda de pacientes, el cual fue
corregido. Luego al procesar el software con una prueba piloto a un grupo de 5
odontlogos se evidenci que luego de una pequea explicacin, los usuarios siguen las
instrucciones siendo de gran facilidad el proceso, manifestando lo accesible y sencillo que
es este software, adems de brindar ventajas al poder accesar con seguridad los datos de
los pacientes.

72

RECOMENDACIONES

Los resultados, conclusiones y elaboracin de software permiten sugerir las siguientes
recomendaciones:

Programar talleres de induccin a los odontlogos 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 relacin con el tratamiento odontolgico

Divulgar los hallazgos en eventos del rea de computacin, as como en el sector
profesional odontolgico.

Respaldar casa cierto periodo de tiempo la informacin generada en dispositivos de
almacenamientos, para prevenir una posible prdida de la informacin debido a
cualquier problema de avera del computador.

Realizar mantenimiento preventivo al sistema.

74

BIBLIOGRAFA

Chavez, N (2001). Introduccin a la investigacin educativa. Editorial Maria.

Kendall y Kendall (1998), Anlisis y Diseo de Sistemas, 4ta Edicin Prentice Hall.

Montilva, J. (1999), Desarrollo de Sistema de Informacin. 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.

OBrien, J. (2001). Sistema de Informacin General. Cuarta Edicin. Bogota. Editorial
Mc Graw Hill

Pressman, R (1998), Sistema de informacin Cuarta edicin. Madrid. Editorial Mc Graw
Hill.

Pressman, R (2000), Ingeniara de Software. Madrid. Editorial Mc Graw Hill.

SENN, J (1999), Anlisis y Diseo de Sistemas de informacin. Segunda edicin.
Colombia. Editorial Mc Graw Hill.

LAUDON, (2004), Sistemas de Informacin Gerencial. Octava edicin. Editorial Pearson

76

AnexoN1
A continuacin se presentan una serie de afirmaciones, conteste con una X SI o NO
deacuerdoasucasoparticular

SI NO
1.IdentificaalpacienteporceduladeIdentidad
2.Seleccionaelapellidodelpacienteparabuscarsuhistoria
2. Tomaencuentasielpacientetieneseguro
3. Indicaelgnerodelpaciente
4. Tomaencuentalafechadenacimientodelpaciente
5. Indicalafechadeingreso(primeravisita)delpaciente
6. Registrainformacinsobrelatoleranciadelpacientealaanestesia
7. RegistraInformacindelestadodesaluddelpaciente
8. Registrainformacinsielpacientepresentaalergiasamedicamentos
9. Necesitaregistrarfotosdelavancedelpaciente
10. Registrainformacindeldiagnosticoobtenido
11. Registrainformacinsobreelplandetratamiento
12. Dejaregistradoeltratamientosugeridoalpaciente
13. TomanotadelPresupuesto
14. Llevacontroldelospagosrealizados
15. Tomanotadelasfechasdeconsultarealizada
16. Registralafechadelaprximaconsulta

Observaciones:_________________________________________________________
______________________________________________________________________
______________________________________________________________________