1.

INTRODUCCION
La simulacin es una herramienta muy importante para empezar a practicar algo que se desea realizar con teoras y referencias de algo ya estipulado para practicar. La simulacin es la investigacin de una hiptesis o a un conjunto de hiptesis de trabajo utilizando modelos y guas de estudio para realizarlo envase a las necesidades que se estipulen por medio del analista. Simulacin es una tcnica numrica para conducir experimentos en una computadora y por medio de ella controlar y verificar su estado. Estos experimentos comprenden ciertos tipos de relaciones matemticas ya que engloban nmeros aleatorios, las cuales son necesarias para describir el comportamiento y la estructura de sistemas complejos en el mundo real a travs de largos periodos. Simular es imitar un sistema real utilizando recursos ajenos a esa realidad sin poner en riesgo nada de lo que se tiene para realizar ese experimento es decir implica simplificar a la realidad y parecerse lo mayormente posible a la realidad. Simulacin por computadora Es un intento de modelar situaciones de la vida real por medio de un programa de computadora, lo que requiere ser estudiado para ver cmo es que trabaja el sistema. Ya sea por cambio de variables, quizs predicciones hechas acerca del comportamiento del sistema. La simulacin por computadora se ha convertido en una parte til del modelado de muchos sistemas naturales en fsica, qumica y biologa, y sistemas humanos como la economa y las ciencias sociales, as como en dirigir para ganar la penetracin su comportamiento cambiar cada simulacin segn el conjunto de parmetros iniciales supuestos por el entorno. Las simulaciones por computadora son a menudo consideradas seres humanos fuera de un loop de simulacin. Es cada vez ms comn escuchar acerca de simulaciones a muchas clases designadas como "ambientes sintticos". Esta etiqueta ha sido adoptada al ampliar la definicin de "simulacin", que abarca virtualmente cualquier representacin

computarizada
1

2. ANTEPROYECTO
2.1 Planteamiento del Problema
Actualmente los mdicos no cuentan con herramientas que coadyuven a su formacin profesional, por lo que es necesario de la ayuda de algn software que facilite la interaccin con los pacientes y un mayor acercamiento con lo que son las enfermedades ms comunes. En la actualidad la demanda de mdicos es muy alta, los costos en salud son elevados para la poblacin, y esta a su vez requiere de un diagnstico previo para tratar enfermedades comunes y ayudar a mdicos practicantes en sus diagnsticos. Los mdicos practicantes cuentan con simuladores de frecuencia cardiaca y de signos vitales, pero no con un simulador que sea capaz de dar un diagnstico previo de aluna enfermedad comn. Por qu se va a desarrollar un simulador medico?

2.2 Justificacin
Los simuladores son un arte en el mundo digital por lo que se debe implementar para resolver problemas comunes como el tratamiento mdico que no siempre est disponible, un simulador mdico resuelve este problema teniendo a la mano un diagnstico previo y sus costos son bajos por lo que brinda mayores beneficios: Brinda una mejor atencin para el paciente y con mayor rapidez. Tratamiento eficaz y oportuno. Realiza un diagnstico previo. Brindar informacin previa sobre sus pacientes. Proporcionar informacin preventiva para controlar las enfermedades.

2.3 Objetivos
2.3.1 General Disear e implementar un simulador para mdicos practicantes que sea capaz de detectar que enfermedad tiene el paciente, conforme a sus sntomas en general. 2.3.2 Especficos Determinar las enfermedades ms comunes de la poblacin en general, para incluirlas en el simulador. Implementar una base de datos sobre las enfermedades para que el simulador pueda realizar un diagnstico previo. Establecer condiciones en el simulador para que haga el diagnstico ms ptimo. Elegir y determinar el lenguaje de programacin que se va a utilizar, para poder realizarlo correctamente y con las especificaciones estipuladas. Seleccionar algn diseo y formato del simulador, para poder implementar y desarrollar una interfaz adecuada.

2.4 Hiptesis
Si se implementa un simulador para diagnosticar enfermedades comunes, entonces un mdico contar con una herramienta til, que le brindara informacin previa sobre sus pacientes para realizar un diagnstico ms eficiente.

2.5 Alcances y Lmites

2.5.1 Alcances Se desarrollar un simulador para detectar enfermedades comunes tales como: gripa, diarrea, vomito, infeccin de vas urinarias, gastritis, respiratorias, bronquitis infecciosa que presentan los pacientes, disminuyendo los costos mdicos, y orientando el tratamiento ms adecuado.

2.5.2 Lmites El simulador mdico no es un mdico certificado, ste slo propone un diagnstico conforme a los sntomas ms comunes; el tratamiento que este simulador proponga debe ser aprobado por un mdico real.

2.6 Cronograma
MARZO ACTIVIDADES P Investigacin previa R P Anteproyecto Eleccin del software y metodologa Desarrollo: Programacin, base de datos, detalles. R P R P R P Pruebas R P Implementacin R P Informe final R TOTAL 62 hrs 18 hrs ABRIL MAYO JUNIO 3 4 4 hrs SUBTOTAL 1 2 3 4 1 2 V A C A C I O N E S 2 hrs 8 hrs 22 hrs 2 hrs 6 hrs 3 4 1 2 3 4 1 2

3. SIMULACIN
3.1 Antecedentes
La simulacin en cualquier disciplina es la constante bsqueda del hombre por adquirir conocimientos relativos a la prediccin del futuro. Tal bsqueda es tan antigua como la historia de la humanidad; antes del siglo XVII, esa indagacin estaba casi limitada a mtodos deductivos de los filsofos como Platn, Aristteles, Euclides, en una apreciacin crtica de la metodologa de estos filsofos, denomin filosofa especulativa a la bsqueda del conocimiento predictivo.
4

La simulacin se utiliza en diferentes disciplinas para describir la construccin de modelos a escalas, en la computadora se puede apreciar el comportamiento de dichos modelos ya sea en comportamientos o estudio de ciencias fsicas. La importancia de los modelos y su construccin como parte integrante de la investigacin cientfica, ha sido expuesta de forma muy sucinta ninguna parte del universo es tan simple como para comprenderse s abstraccin. Para Jennifer (1992) la abstraccin consiste en: reemplazar la parte del universo bajo anlisis, por un modelo de estructura similar, pero ms sencillo. (p.56) Los modelos constituyen entonces una necesidad central del procedimiento cientfico. Su empleo se remonta hacia finales de 1940 cuando Von Neumann y Ulam acuaron el anlisis de Mote Carlo para aplicar tcnicas matemticas en la resolucin de problemas de proteccin nuclear que no se podan resolver mediante experimentacin, el anlisis de Monte Carlo involucra la solucin de un problema mediante la simulacin de un proceso. Al simular en computadoras poderosas, surgieron nuevos ms aplicaciones y con ello problemas tericos prcticos.

3.2 Importancia de la Simulacin

La Simulacin es una de las herramientas ms importantes y ms el usuario define la estructura del sistema que quiere simular, la simulacin correspondiente le dice cul ser el comportamiento dinmico de su empresa o de la mquina que est diseando. As podemos ver los pronsticos para la utilidad de nuestro producto, o ver cuando un mecanismo pueda fallar en las condiciones adversas del ambiente donde funcionar. Para Pardo (1987) las aplicaciones de la simulacin parecen no: tener lmites, se simulan los comportamientos hasta las partes ms pequeas de un mecanismo, las plantas productivas, sucursales bancarias, partidos y torneos de ftbol, movimiento de los planetas

y la evolucin del universo, para mencionar unos pocos ejemplos de las aplicaciones de esta herramienta. (p.43) La creciente importancia de la Simulacin en la Investigacin de operaciones y en sus aplicaciones industriales. En los pases altamente desarrollados la simulacin es una herramienta principal en los procesos de toma de decisiones. De tal manera que la simulacin es indispensable en la actualidad donde el desarrollo de nuevas tecnologas y conocimientos estn ligados al estudio de los modelos evaluados en un simulador de tal manera que se pueda anticipar eventos ya sea en la industria o en la ciencia.

3.3 Conceptos
3.3.1 Sistema Pueden darse varias definiciones de sistema: Para Naylor (1998) los sistemas son: conjunto de elementos cuya interaccin interesa estudiar". (p.23) Tambin se puede considerar como un conjunto de elementos que interactan entre s, con un fin comn, que se asla del universo para su estudio. Para Pardinas (1998) los sistemas son un: conjunto de partes organizado funcionalmente de manera tal de constituir una unidad interconectada. (p.21) Un sistema es un conjunto de elementos que interactan entre ellos. 3.3.2 Subsistema Para Naylor (1998) un subsistema es: un conjunto que se asla dentro del sistema. El sistema puede verse como un subsistema del Universo. Cada subsistema puede ser tratado dentro del sistema o estudiado en forma aislada. (p.89) El comportamiento del sistema total depende de: 1) El comportamiento de cada subsistema.
6

2) Las relaciones entre los subsistemas. 3) Las relaciones con el mundo exterior, o sea con el medio ambiente que lo circunda. El sistema en estudio, puede subdividirse en subsistemas interconectados, cada uno de los cuales est compuesto por elementos interconectados entre s El comportamiento del sistema depender del comportamiento de cada subsistema, de sus relaciones y del medio ambiente donde se lo inserta. Los elementos y las relaciones que los ligan entre s definen los subsistemas. Los subsistemas y las relaciones entre s definen al sistema en estudio. Las relaciones entre los elementos del sistema constituyen la estructura del sistema. Estas ideas son fundamentales para la resolucin de problemas que implican la construccin de modelos. 3.3.3 Modelo La simulacin de sistemas implica la construccin de modelos. Para Pardinas (1998) es el: objetivo es averiguar qu pasara en el sistema si acontecieran determinadas hiptesis. (p.67) 3.3.4 Clasificacin de los Modelos Existen mltiples tipos de modelos para representar la realidad. Algunos de ellos son: Dinmicos: Utilizados para representar sistemas cuyo estado vara con el tiempo. Estticos: Utilizados para representar sistemas cuyo estado es invariable a travs del tiempo. Matemticos: Representan la realidad en forma abstracta de muy diversas maneras.

 Fsicos: Son aquellos en que la realidad es representada por algo tangible, construido en escala o que por lo menos se comporta en forma anloga a esa realidad (maquetas, prototipos, modelos analgicos, etc.). Analticos: La realidad se representa por frmulas matemticas. Estudiar el sistema consiste en operar con esas frmulas matemticas (resolucin de ecuaciones). Numricos: Se tiene el comportamiento numrico de las variables intervinientes. No se obtiene ninguna solucin analtica. Continuos: Representan sistemas cuyos cambios de estado son graduales. Las variables intervinientes son continuas. Discretos: Representan sistemas cuyos cambios de estado son de a saltos. Las variables varan en forma discontinua. Determinsticos: Son modelos cuya solucin para determinadas condiciones es nica.

3.4 Tipos de simulacin

De acuerdo al tipo de sistema o problema que se estudia o ms precisamente al tipo de modelo que lo representa, la simulacin (Pardo, 1987), puede ser: 1. De tiempo continuo: Este tipo de simulacin trata modelos descritos por ecuaciones diferenciales ordinarias o ecuaciones diferenciales parciales. 2. De tiempo discreto: Trata modelos discretos por ecuaciones diferenciales. 3. De eventos discretos: Para Pardo (1987), trata con sistemas que pueden ser modelados: Como una secuencia de eventos contables, asumiendo que nada importante ocurre entre esos eventos. (p.35). El tipo de simulacin, depende de dos factores: 1). El tipo de modelo que mejor se ajuste al sistema o que mejor le parezca al diseador de la simulacin; y 2). La forma en que mejor se ve el sistema ya que debe cumplir las expectativas deseadas para la necesidad que fue creado.

3.5 Etapas de la simulacin

Las etapas (Senn, 1992), que se requieren para el diseo y elaboracin de un simulador son: Primera etapa: Formulacin del problema y captura de requerimientos En este apartado se plantea la definicin del problema, primero se tienen que identificar las necesidades de una entidad y de ah se empiezan a postular y ver alternativas para la solucin. Del planteamiento del problema se comienzan a establecer requerimientos, los cuales nos van a servir de ayuda para ir guiando el sistema de simulacin, y son la base para ir fomentando y formando el sistema. Para la captura de requerimientos se hace con base en las necesidades para las que va a ser creado el simulador ya que debe cubrir su expectativa primordial sin dejar de tomar en cuenta las especificaciones acordadas. En este aparatado se debe aclarar lo que se va a tomar como base o principio, porque en algunas ocasiones no se abarcan por completo los requerimientos establecidos y pueden ocurrir conflictos a la hora de realizarlo. Para Senn, (1992), los requerimientos son: Una condicin o capacidad que debe estar presente en un sistema o componentes de sistema para satisfacer un contrato, estndar, especificacin u otro documento formal. (p.87) Los requerimientos pueden dividirse en requerimientos funcionales y

requerimientos no funcionales. Los requerimientos funcionales definen las funciones que el sistema ser capaz de realizar. Describen las transformaciones que el sistema realiza sobre las entradas para producir salidas. Los requerimientos no funcionales tienen que ver con caractersticas que de una u otra forma puedan limitar el sistema, como por ejemplo, el rendimiento (en tiempo y espacio), interfaces de usuario, fiabilidad (robustez del sistema, disponibilidad de equipo), mantenimiento, seguridad, portabilidad, estndares, etctera.
9

Para Senn (1992), las caractersticas de un requerimiento son: sus propiedades principales en estado de madurez, deben presentar una serie de caractersticas tanto individualmente como en grupo. (p. 90). Los requerimientos tienen caractersticas primordiales como lo son: Necesario: esto quiere decir que si su omisin provoca deficiencia dentro del sistema entonces se considera un requerimiento necesario u ptimo. Conciso: se describe como un requerimiento fcil de entender y de leer por que no crea ambigedad y es preciso. Completo: se considera as si no se necesita ampliar detalles en su redaccin es decir la informacin que brinda es estable y eficaz. Consistente: se dice as porque no crea conflictos con otros requerimientos ya que debe ser nico e irrepetible. Verificable: se dice as cunado un requerimiento puede ser cuantificado de manera que pueda ser entendido con facilidad. Los requerimientos deben ser especificados por escrito como un contrato, ya que de aqu parten los alcances y lmites del simulador. Los requerimientos de un sistema de software cuando se ven son extensos y detallados, adems contienen mltiples relaciones lo que podemos concluir que el conjunto de requerimientos de un sistema computacional son muy complejos y se deben especificar muy detalladamente. Para Coss (2002), el anlisis de requerimientos es: la tarea que plantea la asignacin de software a nivel de sistema y el diseo de programas. (p.43) El anlisis de requerimientos facilita al desarrollador especificar la funcin y comportamiento de los programas, ya que indica la interfaz de la aplicacin como sus posibles configuraciones para una mejor visualizacin y la posible interconexin entre otras herramienta que coadyuve a una mejor interpretacin, que debe cumplir el programa.

10

Para Naylor (1995), El anlisis de requerimientos: permite al ingeniero refinar la asignacin de software y representar el dominio de la informacin que ser tratada por el programa. (p.78) La evaluacin detallada del problema y la sntesis de la solucin es un punto importante para el anlisis de sistemas de simulacin ya que de aqu parte una visin o proyeccin de lo que se desea realizar o alguna mejora que se desee implementar en alguna aplicacin ya existente. Segunda etapa: Recopilacin de la informacin y definicin del modelo La recopilacin de informacin se obtiene mediante entrevistas, cuestionarios y encuestas ya que son mtodos utilizados por los analistas de sistemas para recopilar datos sobre los requerimientos de informacin, los analistas proponen metas y alternativas de solucin, tambin venden los programas durante la entrevista, ya que es una conversacin directa. Para Pardinas (1998), las entrevistas son: dilogo de preguntas y respuestas entre dos personas, planeados de antemano. (p.34) El analista se vale de la informacin que recaba durante la entrevista para desarrollar una vinculacin con el cliente, debe observar tambin el lugar de trabajo para recopilar datos relacionados con el plan de seguimientos. Existen dos tipos de preguntas las cerradas y abiertas: las abiertas permiten al entrevistado contestar las preguntas con congruencia, pero al mismo tiempo con la perspectiva del mismo y las cerradas se ajusta o limitan las opiniones posibles. Las preguntas pueden estructurarse de tres maneras posibles; de pirmide, de embudo y de diamante: La estructura de diamante comienza con preguntas cerradas y detalladas, ya que al final se culmina con preguntas ms amplias y generales y debe abarcar todos los aspectos posibles que ayuden a una entrevista adecuada y bien formulada. La estructura de embudo empieza con preguntas abiertas en general y al terminar pasan con preguntas cerradas ya que no se limitan a las opiniones posibles. La estructura con forma de

11

diamante se fortalece de las otras dos estructuras ya que es la ms compleja y difcil de emplear por su estructura tan amplia y difcil de manipular. Para Prez (1995), los analistas podran considerar: como una alternativa el diseo conjunto de aplicaciones. Con jad, los analistas pueden examinar los requerimientos y disear una interfaz de usuario de manera conjunta con los usuarios. (p.55) Tercera etapa: Implementacin La implementacin es la realizacin de una aplicacin que se ajusta a las necesidades de una organizacin, para lograr un fin en especfico tambin se puede considerar como la ejecucin de un plan, idea, modelo cientfico, diseo, especificacin, estndar, algoritmo o poltica. Es la realizacin de una especificacin tcnica o algoritmos como un programa esta implementacin viene de la mano con la informacin adquirida de la entrevista ya que se ajusta a lo que arroja. Para Knowledge (1992), la implementacin: se refiere al proceso post-venta de gua de un cliente sobre el uso del software o hardware que el cliente ha comprado. (p.32) Cuarta etapa: Ejecucin de experimentos El carcter experimental de la simulacin, de los modelos es una herramienta muy importante al simular, ya que se basa en las pruebas y requisitos que se desean desarrollar como sujetos del experimento, como sustitutos de la realidad. Un estudio de simulacin segn la metodologa que hemos establecido busca respuestas a preguntas sobre el sistema objeto estudiado a travs de la informacin que le proporciona los experimentos con el modelo de un sistema. Los experimentos buscan, en general respuestas a preguntas de tipo Qu pasara si? Preguntas que pueden plantearse en cualquier etapa del ciclo de vida del sistema, tanto en la fase de diseo tanto como de desarrollo cuyo caso primordial es encontrar respuestas alternativas de solucin para el sistema de simulacin. En general las respuestas que buscamos mediante los experimentos servirn de soporte para la toma de decisin racional sobre el sistema, por lo que nos interesa que las
12

respuestas queden expresadas numricamente en trminos que se puedan expresar por un analista y para poder manejarlo dentro del sistema que se presenten las medidas de la utilidad o del rendimiento esperado para la alternativa que nos ocupa de diseo o de cambio del sistema en este apartado se fomenta la formalidad de las situaciones tanto como aleatorias o discretas. Las alternativas de diseo o variante de configuracin del sistema constituirn una variable adecuada para el sistema o como una variable del modelo o escenario de simulacin con las que realizaremos los experimentos. Para Pardinas (1998), en esta ocasin: es la metodologa de la estadstica y en particular la de tcnicas de muestreo la que nos permitir dar una respuesta correcta a este tipo de cuestiones. (p.45) Otro aspecto que hay que tomar en cuenta para garantizar la calidad de las estimaciones de las variables de respuesta desde el punto de vista estadstico es la necesidad de estudiar estimadores, ya que estos nos proporcionan a estudiar ms a fondo el sistema de simulacin que requiere o que satisfaga las necesidades estipuladas. Una manera de conseguir estos objetivos consiste en recurrir a las tcnicas de reduccin de varianza diseadas especficamente para incrementar la precisin de la estimacin de variables de respuesta y facilitarlas comparaciones entre las tcnicas reduccin de variancia ms utilizadas en simulacin figura el muestreo de estratificacin. A la hora de interpretar las observaciones producidas durante la experimentacin de la simulacin es conveniente interpretarlos adecuadamente porque estos tipos de estrategias son una herramienta muy importante para producir mejoras en el sistema o simplemente para ver si en verdad lo que se est desarrollando es factible o cumple con las expectativas con las que fue creado y de aqu se considera si el sistema es estable o existe la posibilidad de perfeccionarlo o simplemente pensar en otra alternativa de desarrollo. Recordemos que hemos considerado que la simulacin de un sistema con estados discretos puede interpretarse como un seguimiento de la evolucin del sistema entre sus estados, teniendo en cuenta el carcter aleatorio del input es obvio que la tal evolucin puede
13

considerarse como un proceso estocstico y como tal podemos considerar dos tipos de situacin la que corresponde a la fase transitoria del proceso y la del estado estacionario. Para Pardo (1987), en general, la fase transitoria depender de las condiciones iniciales mientras que entendemos que la situacin estacionaria si el sistema la tiene y llega a ella es independiente de su estado de partida. (p.23) En el caso de la simulacin hay que hacer una observacin con respecto al punto de vista del analista encargado de llevar a cabo las entrevistas al punto de vista del diseo de experimentos en estadstica y es que, es decir, se pueden estipular y manejar de acuerdo a las necesidades de los usuarios esta originado nicamente por la aleatoriedad del muestreo no por el modelo que se supone que el analista conoce y domina completamente, ya que debe conocer tanto como el rea de anlisis y en la parte de desarrollo. Quinta epata: Anlisis de resultados En este apartado se debe terminar de usar los mtodos y herramientas seleccionadas para el estudio se debe tener informacin almacenada en cuadernos archivos e ndices organizada cronolgicamente ya que son las bases para interpretar lo que nos est arrojando el sistema. Esta fase trata sobre los procesos que permite analizar la informacin recopilada; verificar su confiabilidad mediante la formulacin de preguntas y respuestas en interpretar y comprender los resultados y presentar y usar los resultados para que el sistema de simulacin sea ms completo y tenga una mejor eficiencia a la hora de implementarlo. Debido a que la documentacin es uno de los resultados ms importantes de un estudio de evaluacin de la higiene se demuestra, en trminos prcticos, cmo la investigacin y el anlisis se vinculan con la redaccin de informes. La descripcin y anlisis de la informacin cualitativa estn estrechamente vinculados, de ah la frase anlisis descriptivo. Este anlisis incluye una descripcin de la finalidad del estudio, la localidad y personas comprometidas, y sus generalidades usualmente se presentan en la introduccin del informe.

14

El anlisis descriptivo se centra en cmo, dnde y quin recolect la informacin, lo cual implica revisar la informacin, identificar vnculos, patrones y temas comunes, ordenar los hechos y presentarlos como son, sin agregar ningn comentario sobre su importancia. En el informe, esto se presenta generalmente en la seccin de Resultados. El orden de los resultados puede ser cronolgico, segn la secuencia de observacin de los hechos, o jerrquico, de acuerdo a la importancia de los temas. Las respuestas a estas preguntas requieren un anlisis y descripcin rigurosos, pero no una interpretacin. En el anlisis descriptivo se debe incluir detalles suficientes para permitir que el lector vea qu pasos sigui en la investigacin, cmo tom decisiones metodolgicas o cambios de direccin y por qu. Los hechos tienen que presentarse de manera clara, coherente y completa antes de que puedan ser interpretados. Una caracterstica muy importante del anlisis es la verificacin, seguida de la verificacin cruzada de la informacin a fin de establecer la calidad y confiabilidad de los resultados. La segunda etapa es determinar el significado de los resultados y cun significativos son en su contexto especfico. Las razones que motivan ciertas prcticas de higiene y la influencia de los factores socioculturales sobre ellas pueden analizarse con el aporte de las mltiples perspectivas del equipo de estudio. Tomando como base los resultados, tambin pueden explorarse temas ms amplios que vinculen las prcticas de higiene con la salud. Para Naylor (1998) el anlisis descriptivo es: la interpretacin de los resultados, en ltimo trmino, permiten evaluar los resultados como positivos, negativos o ambos y determinar sus razones. (p.45) Los valores del equipo de estudio y de las partes interesadas influyen en los resultados del estudio. Sexta etapa: Verificacin y pruebas La verificacin y prueba es esencial para minimizar los riesgos por uso de tecnologa y es para verificar que lo que se desarroll se hizo de manera adecuada y si
15

surgen algunos errores poder corregirlos antes de que salga al mercado o simplemente sea entregado a la persona que lo va a utilizar. Es conveniente realizar la verificacin y pruebas antes de utilizar el sistema tanto en s mismo como de manera conjunta con el equipo y las comunicaciones que colaboraron para la realizacin del simulador, ya que se debe probar en frente de todas las personas involucradas para ver si tiene algn error y poder corregirlo al instante por que pudo haber surgido en una esta etapa en la que no estn involucradas todas las personas por ejemplo en la de desarrollo y hay debe poner en marcha el desarrollador una posible solucin para corregirlo. El nivel de importancia de la tecnologa impactar el grado de rigor aplicado a los programas de verificacin, prueba y mantenimiento de los programas. Para Coos (2002), un sistema es: de gran importancia, como un simulador de doctor, es conveniente que una autoridad independiente lleve a cabo las pruebas de verificacin. Para sistemas de menor importancia, la verificacin puede realizarse internamente. (p.123) Puede ser necesario realizar auditoras a los cdigos de los programas, particularmente cuando estos se utilicen para sistemas cruciales. Generalmente estas auditoras son ms efectivas cuando las llevan a cabo expertos independientes de los autores del cdigo. Una vez que los programas han sido verificados, requieren ser rigurosamente probados para asegurar que cada componente opere como es debido y que el sistema funcione exactamente de acuerdo con los requerimientos locales especficos. Sptima etapa: Documentacin presentacin e interpretacin de los resultados En este apartado lo que se hace es documentar como se realiz el simulador de acuerdo a las necesidades de cada entidad y se presenta por escrito ya que este es revisado por el usuario aqu se estipulan todos los paso que se siguieron para conseguirlos desde el anlisis, el desarrollo hasta la implementacin.

16

Tambin se desarrolla un manual de usuario y un manual tcnico, el manual de usuario lo que hace es decirle al usuario como usar el simulador y el manual tcnico es para ver cmo se desarroll, ya sea para darle mantenimiento o si en alguna ocasin est fallando algo checarlo y poder darle una solucin efectiva. La interpretacin de resultados es lo que nos arroja el simulador y para probar si es benfico o no.

3.6 Sistema Gestor de Base de Datos (SGBD)

De acuerdo a los sistemas gestores de base de datos que se estudien, son una herramienta muy importante para manipular bases de datos ya que nos permite interpretar, visualizar y agilizarlas, los sistemas gestores de bases de datos puede ser: Para Elena Castro (1992), Un Sistema Gestor de base de datos es: un conjunto de programas que permiten crear y mantener una Base de datos, asegurando su integridad, confidencialidad y seguridad. (p.34) Por lo tanto debe permitir: 1) Definir una base de datos, especificar tipos estructuras y restricciones de datos. 2) Construir la base de datos, guardar los datos en algn medio controlado por el sistema gestor de base de datos. 3) Manipular la base de datos, realizar consultas, actualizarlas y generar informes. Las caractersticas principales de los sistemas gestores de base de datos son: 1) Control de la redundancia; la redundancia de datos tiene varios aspectos negativos (duplicar el trabajo al actualizarla, desperdiciar espacio en disco, puede provocar inconsistencia de datos) aunque a veces es deseable por cuestiones de rendimiento y de entrega de rapidez. 2) Restriccin de los accesos no autorizados cada usuario ha de tener algunos permisos y privilegio dentro de la base de datos ya que son por cuestiones de seguridad y un mejor mantenimiento y control para la misma. 3) Cumplimiento de restriccin de integridad ha de ofrecer recursos para definir y garantizar el cumplimiento de las restricciones de integridad. En una base de datos existen las transacciones y para Castro (1992), las transacciones son: un programa que se ejecuta como una sola operacin. Esto quiere decir que luego de una ejecucin en la que se produce una falla es el mismo que se obtendra si el
17

programa no se hubiera ejecutado. Los SGBD proveen mecanismos para programar las modificaciones de los datos de una forma mucho ms simple que si no se dispusiera de ellos. (p.89) En una base de datos debe existir independencia y la independencia de los datos consiste en la capacidad de modificar el esquema (fsico o lgico) de una base de datos sin tener que realizar cambios en las aplicaciones que sirve de ella, ya que si se modifica una base, se tiene que modificar la aplicacin que va de la mano con la misma.

3.7 Lenguajes de programacin

Un lenguaje de programacin (Joyanes 1995) debe expresar procesos que pueden ser llevados a cabo por las computadoras y son lenguajes artificiales ya que solo son entendibles por un ordenador o mquina. Pueden ser usados para realizar programas que controlen el comportamiento fsico o lgico de una mquina, para expresar algoritmos con precisin o modos de comunicacin humana. Est formado por un conjunto de smbolos y reglas sintcticas y semnticas que definen su estructura y diseo de los elementos y expresiones que comprenden para formar un lenguaje de programacin de alto nivel. Al proceso por el cual se escribe, se prueba, se depura, se compila y se mantiene el cdigo fuente de un programa informtico se llama programacin ya que comprende todas las etapas de la elaboracin de un sistema. Para Joyanes (1995) la palabra programacin se: define como el proceso de

creacin de un programa de computadora mediante la aplicacin de procedimientos lgicos y una serie de pasos que permiten una mejor visualizacin de lo que se va a realizar. (p.45) A continuacin se mencionan algunos pasos de la programacin: El desarrollo lgico del programa para resolver un problema en partculas con las especificaciones estipuladas por el cliente junto con el analista.

18

 Escritura lgica del programa que se va a desarrollar empleando un lenguaje de programacin especfico y entendible por el ordenador. Ensamble o compilacin del programa hasta convertirlo en lenguaje de mquina y este tipo de lenguaje son 0 y 1, ya que es el lenguaje que reconocen las computadoras. Pruebas y depuracin del programa, aqu se prueba el sistema y se ven los posibles errores que tiene para poder hacerle mejoras. Desarrollo de la documentacin, en este aparatado se explica cmo se desarroll. 3.7.1 Visual Basic Visual Basic (Aguilar, 1990) es un lenguaje de programacin dirigido por eventos. Este lenguaje de programacin es un dialecto de BASIC con importantes agregados ya que permite enlazar varias aplicaciones para el desarrollo de un sistema. Para Aguilar (1990) el entorno de desarrollo se: puede ejecutar el programa que se est desarrollando es decir en modo interprete (en realidad pseudo-compila el programa muy rpidamente ya que cuenta con un intrprete no con un compilador y su funcin principal del interprete es checar todo el cdigo fuente de una sola pasada y es ms rpido y el compilador lo hace lnea por lnea y es ms tardado) y luego lo ejecuta simulando la funcin de un intrprete puro. (p.51) Desde ese entorno tambin se puede generar el programa en cdigo ejecutable (exe). Ese programa as generado en disco puede ser ejecutado luego fuera del ambiente de programacin, ya que contiene todas las libreras para arrancar y ejecutarse sin tener abierto el lenguaje de programacin. Visual Basic provee soporte para empaquetado y distribucin es decir, permite generar un mdulo instalador que contiene el programa ejecutable y las bibliotecas DLL necesarias para su ejecucin. Con ese mdulo, la aplicacin desarrollada se distribuye y puede ser instalada en cualquier equipo que tenga un sistema compatible.

19

As como bibliotecas DLL, (colocar lo que son las siglas hay numerosas aplicaciones desarrolladas por terceros que permiten dispones de variadas y numerosas funciones y mejoras posibles para Visual Basic, incluyendo algunos para empaquetado y distribucin hasta para otorgar mayor funcionalidad al mismo entorno de programacin. Para Jennifer (1992) Visual Basic es: un lenguaje de programacin que utiliza menos codificacin que cualquier otro lenguaje ya que permite trabajar por mdulos y al realizarlo de esta manera es ms fcil de interpretarlo por la maquina a diferencia de java y utiliza las mismas plantillas y entorno de trabajo. (p.57) Es un lenguaje de programacin considerado como un lenguaje de alto nivel, ya que puede interactuar con otras aplicaciones para desarrollar programas que satisfagan una necesidad. 3.7.2 Java Es un lenguaje Becerril (1998) de programacin orientado a objetos y tambin es un lenguaje de alto nivel. Las aplicaciones java estn tpicamente compiladas en un bytecode, aunque la compilacin en cdigo maquina nativo tambin es posible. En el tiempo de ejecucin el bytecode es normalmente interpretado o compilado a cdigo nativo para la ejecucin aunque la ejecucin directa por el hardware del bytecode por un procesador java tambin es posible. 3.7.2.1 Filosofa El lenguaje java se cre con cinco objetivos principales: 1. Debera usar el paradigma de la programacin orientada a objetos. 2. Debera permitir la ejecucin de un mismo programa en mltiples sistemas operativos entonces debera cumplir la caracterstica principal de multi plataforma que puede ser ejecutado en cualquier sistema. 3. Debera incluir por defecto soporte para trabajo en red que fuera posible comunicarse con otras mquinas pero ejecutando el mismo programa.

20

4. Debera disearse para ejecutar cdigo en sistemas remotos de forma segura y eficaz. 5. Debera ser fcil de usar y tomar lo mejor de otros lenguajes orientados a objetos. 3.7.2.2 Orientado a objetos Para Becerril (1998) orientada a objetos se: refiere a un mtodo de programacin y al diseo del lenguaje que satisfaga las necesidades del cliente. (p.23) Una primera idea es disear en software de forma que los distintos tipos de datos que se usen estn unidos a sus operaciones para una mejor codificacin y representacin. As los datos y el cdigo (funciones o mtodos) se combinan en entidades llamadas objetos. Un objeto puede verse como un paquete que contiene el comportamiento del cdigo y el estado de datos. El principio es separar a aquellos que cambian de las cosas que permanecen inalterables. Frecuentemente cambiar una estructura de datos implica un cambio en el cdigo que opera sobre los mismos o viceversa. Esta separacin en objetos coherentes e independientes ofrece una base ms estable para el diseo de un sistema software. El objetivo es hacer que grandes proyectos sean fciles de gestionar y manejar, mejorando como consecuencia su calidad y reduciendo el nmero de proyectos fallidos. Otra de las grandes promesas de la programacin orientada a objetos es la creacin de entidades ms genricas (objetos) que permitan la reutilizacin del software entre proyectos, una de las premisas fundamentales de la Ingeniera del Software. Un objeto genrico cliente, por ejemplo, debera en teora tener el mismo conjunto de comportamiento en diferentes proyectos, sobre todo cuando estos coinciden en cierta medida, algo que suele suceder en las grandes organizaciones En este sentido, los objetos podran verse como piezas reutilizables que pueden emplearse en mltiples proyectos distintos, posibilitando as a la industria del software a construir proyectos de envergadura empleando componentes ya existentes y de comprobada calidad; conduciendo esto finalmente a una reduccin drstica del tiempo de desarrollo.
21

La reutilizacin del software ha experimentado resultados dispares, encontrando dos dificultades principales: el diseo de objetos realmente genricos es pobremente comprendido, y falta una metodologa para la amplia comunicacin de oportunidades de reutilizacin. Algunas comunidades de cdigo abierto quieren ayudar en este problema dando medios a los desarrolladores para diseminar la informacin sobre el uso y versatilidad de objetos reutilizables y bibliotecas de objetos. 3.7.2.3 Independencia de la plataforma La segunda caracterstica la independencia de la plataforma significa que programas escritos en lenguaje java pueden ejecutarse igualmente en cualquier tipo de hardware. Este es el significado de ser capaz de escribir un programa una vez y que puede ejecutarse las veces que desee el cliente o que sean posibles en cualquier dispositivo. Para ello se compila el cdigo fuente escrito en lenguaje java, para generar un cdigo conocido como lenguaje entendible para el ordenador, instrucciones mquina simplificada especficas de la plataforma java. Esta pieza est a medio camino entre el cdigo fuente y el cdigo mquina que entiende el dispositivo destino. Hay implementaciones del compilador de Java que convierten el cdigo fuente directamente en cdigo objeto nativo, como GCJ. Esto elimina la etapa intermedia donde se genera el bytecode, pero la salida de este tipo de compiladores slo puede ejecutarse en un tipo de arquitectura. El concepto de independencia de la plataforma de Java cuenta, sin embargo, con un gran xito en las aplicaciones en el entorno del servidor, como los Servicios Web, los Servlets, los Java Beans, as como en sistemas empotrados basados en OSGi, usando entornos Java empotrados. 3.7.2.4 Recolector de basura En Java el problema de las fugas de memoria se evita en gran medida gracias a la recoleccin de basura. El programador determina cundo se crean los objetos y el entorno
22

en tiempo de ejecucin de Java (Java runtime) es el responsable de gestionar el ciclo de vida de los objetos. El programa, u otros objetos pueden tener localizado un objeto mediante una referencia a ste. Cuando no quedan referencias a un objeto, el recolector de basura de Java borra el objeto, liberando as la memoria que ocupaba previniendo posibles fugas (ejemplo: un objeto creado y nicamente usado dentro de un mtodo slo tiene entidad dentro de ste; al salir del mtodo el objeto es eliminado). Aun as, es posible que se produzcan fugas de memoria si el cdigo almacena referencias a objetos que ya no son necesarios es decir, pueden an ocurrir, pero en un nivel conceptual superior. En definitiva, el recolector de basura de Java permite una fcil creacin y eliminacin de objetos y mayor seguridad.

5. PROCEDIMIENTO
5.1 Deteccin de necesidades
En la actualidad el acceso a servicios de salud es escaso para la gran mayora de la poblacin mexicana que no cuenta con un seguro mdico y mucho menos el capital econmico para el servicio mdico privado, el servicio disponible para atender a la

poblacin en el municipio de Jilotepec se encuentra saturado, en gran medida por las enfermedades comunes que pueden detectarse con un simulador que reconozca los patrones de comportamiento de los padecimientos aprender a reconocer estos patrones tambin puede ayudar mdicos en formacin y de esta manera proponer un tratamiento alternativo de acuerdo al paciente, de esta manera ampliar la calidad y cobertura del sector salud. Por lo tanto las necesidades detectadas para el desarrollo del simulador fueron: * Se sonde a nivel local cules son las 10 enfermedades ms frecuentes que saturan los centros de atencin mdica, esto se realiz en el Hospital General de Jilotepec, en el Centro de Salud y en la Unidad Integral de Rehabilitacin Social; en los cuales se entrevist a 7 mdicos que estn en contacto directo con la poblacin. La entrevista fue realizada de manera informal debido a la carga de trabajo de los mdicos, por lo cual slo nos concedieron unos minutos.
23

Los datos que arroj fueron que las enfermedades ms comunes son: * Obtener estadsticas sobre el comportamiento de cada enfermedad con diferentes mdicos. * Generar diagramas de flujo para la evaluacin del paciente con los datos que este proporcione. * Almacenar la informacin recabada en una base de datos que alimente al simulador.

5.2 Diseo del simulador

Como es bien conocido en la programacin para que una aplicacin sea factible de realizar e implementar esta debe ser sencilla de utilizar por parte del usuario final, por lo tanto se considera utilizar una interfaz grfica intuitiva de tal manera que solo se tiene que elegir de una serie de listas desplegables, la informacin que el simulador necesita para realizar el procedimiento de diagnstico. El diseo de la base de datos ser realiza apoyados de las tcnicas de normalizacin, para no tener redundancia de datos e incrementar la seguridad del simulador para garantizar una probabilidad de asertividad alta. Las herramientas que se utilizaran para el desarrollo de este producto son: Netbeans en el cual se realizara la programacin correspondiente, MySQL un gestor de base de datos. Estos programas fueron seleccionados debido a que son de distribucin libre lo cual reduce significativamente los costos implcitos en el desarrollo y as poder acercarlo fcilmente a la poblacin con menos recursos econmicos.

5.3 Descripcin del modelo entidad-relacin de la base de datos del simulador.

24

5.4 Recoleccin datos Los datos requeridos para el diseo del simulador se obtendrn de una investigacin de campo que abarca los siguientes puntos: Realizar encuestas en todos los cetros de salud del municipio de Jilotepec (entidad donde se implementara este simulador) y de ah partir hacia el estudio de cada enfermedad. Entrevistarse con mdicos con experiencia de 3 aos en el campo laboral acerca de los padecimientos as como de sus tratamientos ms ptimos para cada uno de acuerdo a las mtricas utilizadas por ellos. Implementar las mtricas ms utilizadas en mtodos del simulador.

Considerando la magnitud del proyecto es imperativo complementar el desarrollo del simulador con la consulta de libros de medicina y delos artculos publicados en internet que tengan relevancia con la enfermedades que se incorporan al proyecto. 5.3 implementacin de mtricas Traducir a un algoritmo los parmetros ms exitosos y frecuentes utilizados por los mdicos en la evaluacin de los pacientes por enfermedad, de tal manera tendremos un algoritmo para cada enfermedad que ser traducido a java. Algunas mtricas son: Sntomas presentados por el paciente Datos fsicos del paciente Sntomas de cada padecimiento.

25