Documentos de Académico
Documentos de Profesional
Documentos de Cultura
NDICE DE CONTENIDO......................................................................................I
NDICE DE FIGURAS Y TABLAS.......................................................................IV
AGRADECIMIENTOS........................................................................................VII
DEDICATORIA....................................................................................................IX
1. RESUMEN.....................................................................................................X
2. ABSTRACT...................................................................................................XI
3. ANTECEDENTES Y MOTIVACIN.............................................................XII
4. INTRODUCCIN...........................................................................................1
5. OBJETIVOS...................................................................................................2
5.1.
OBJETIVO GENERAL............................................................................2
5.2.
OBJETIVOS ESPECFICOS...................................................................2
6. SITUACIN ACTUAL.....................................................................................3
7. MARCO TEORICO........................................................................................6
8. MARCO REFERENCIAL................................................................................9
9. PARADIGMAS DE DESARROLLO DE SOFTWARE..................................12
9.1
ANLISIS Y COMPARACIN...............................................................12
PATRONES DE DISEO..........................................................................25
10.1
10.2
11
11.1
CASOS DE USO................................................................................28
DIAGRAMA DE ACTIVIDAD..............................................................31
11.3
MODELO DE CLASES......................................................................31
12
13
FACTIBILIDAD Y MEDIOS.......................................................................39
13.1
13.2
13.3
FACTIBILIDAD TCNICA..................................................................39
13.4
FACTIBILIDAD ECONMICA............................................................40
13.5
13.6
FACTIBILIDAD LEGAl........................................................................42
14.
14.1
FASE DE EXPLORACIN.................................................................43
FASE DE PLANIFICACIN...............................................................47
14.3
FASE DE ITERACIONES..................................................................50
Conclusin..............................................................................................117
16.
Bibliografa..............................................................................................118
16.1
Libros................................................................................................118
16.2
Sitios Web........................................................................................118
3|Pgina
7|Pgina
AGRADECIMIENTOS
Al llegar al final de este proceso, me gustara expresar mi agradecimiento a las personas que
siempre han estado conmigo y confiaron plenamente en m, en mi capacidad de poder
cumplir mis objetivos.
Quiero destacar a mis padres Marcela Araneda Gonzlez y Jaime Antonio Meza Prez por
haberme apoyado en todo momento, por estar siempre presentes tanto en mis logros como
en mis derrotas. A mi hermano Leandro Williams Meza Araneda, por aguantar mis malos
momentos y siempre estar ah preocupado por m.
A mis amigos Juan Pablo Gonzlez y Carolina Pino Gaete, por compartir los buenos y malos
momentos, por apoyarme y seguir siendo parte de mi vida. A mis compaeros de la
Universidad Central, con los cuales compart muchos momentos, muchas noches de desvelo
y muchos das de alegra.
No puedo concluir sin hacer un especial reconocimiento a mi abuelo Jos Cirilo Meza Ulloa
que desgraciadamente no pudo ver a su primer nieto salir de la Universidad, s que habra
estado orgulloso.
Gracias!
8|Pgina
9|Pgina
DEDICATORIA
Nos gustara dedicar nuestro proyecto a toda nuestra familia. A nuestros padres y abuelos,
por su comprensin y ayuda en los buenos y malos momentos. Nos han enseado a encarar
las adversidades sin perder nunca la dignidad, ni desfallecer en el intento. Nos han dado todo
lo que somos como persona, nuestros valores, nuestros principios, nuestra perseverancia,
nuestro empeo y todo ello con una gran dosis de amor, sin pedir nunca nada a cambio.
A todos ellos, muchas gracias de todo corazn.
10 | P g i n a
1. RESUMEN
Si se pudiera detectar una enfermedad prematuramente, sera posible mejorar la calidad y
aumentar la esperanza de vida de los pacientes.
Por tal razn, es fundamental que el profesional de la salud disponga de manera oportuna,
toda la informacin y las herramientas disponibles para diagnosticar con antelacin algn tipo
de patologa en los pacientes. Por lo cual, sera de gran utilidad contar con una herramienta
tecnolgica que apoye a la toma de decisiones en el rea de la medicina, permitiendo
detectar, a travs de la informacin estadstica disponible y los antecedentes del paciente, las
eventuales patologas que ste pueda padecer.
En funcin a lo anteriormente mencionado, se desarrollar un sistema de informacin capaz
de satisfacer los requerimientos planteados, para transformarse en un real aporte a la
medicina, en particular al rea de la Urologa, considerando que la medicina en general es
una rama de la ciencia muy extensa y compleja.
Para abordar esta problemtica se recopil toda la informacin estadstica y los antecedentes
de los pacientes relacionados con su historial mdico, datos demogrficos 1, patologas2,
historial familiar de enfermedades genticas e historial de controles del paciente, con el
objetivo de disear un sistema capaz de procesar los datos que ayudarn a detectar
eventuales patologas.
Finalmente, es fundamental destacar que se cuenta con el respaldo de un cirujano
especialista en el rea de la Urologa e inversionista de la clnica Uromed, el Dr. Nelson
Orellana (Urlogo, Universidad de Chile) quien facilitar las instalaciones de Uromed para la
puesta en marcha e implementacin del proyecto.
2. ABSTRACT
If you could detect a disease early, it would be possible to improve the quality and increase
the life expectancy of patients.
For this reason, it is essential that the health care provided in a timely manner, all the
information and tools available to diagnose any medical condition early in patients. Therefore,
it would be useful to have a technological tool to support decision making in the area of
medicine, allowing detection through the available statistical information and patient history,
any conditions that it may suffer.
According to the above, an information system capable of meeting the requirements set to
become a real contribution to medicine, particularly in the area of urology, considering that
general medicine is a branch of science will develop very large and complex.
To address this problem all statistical information and background related to patient medical
history, demographics, diseases, family history of genetic diseases and patient test history
was compiled with the aim of designing a system capable of processing the data that will help
detect any pathologies.
Finally, it is essential to emphasize that it has the backing of a surgeon in the area of urology
and Uromed investor of the clinic, Dr. Nelson Orellana (Urologist, University of Chile) who
provide facilities for start Uromed up and implementation of the project.
12 | P g i n a
3. ANTECEDENTES Y MOTIVACIN
En nuestro pas la mortalidad por el cncer de prstata ha ido en aumento sostenido y se
cuadruplic en los ltimos 50 aos. En 2002 murieron 1.472 hombres por cncer de prstata
en Chile (uno cada seis horas). Cada ao mueren ms hombres por cncer de prstata que
por accidentes automovilsticos; pero, gracias a su deteccin temprana y manejo adecuado,
esto se puede revertir.
De acuerdo a los antecedentes entregados por los especialistas, en la actualidad no existe, o
no se conoce en el mercado local, ningn software especfico que apoye la gestin del rea
de Urologa. Menos an, uno capaz de sugerir eventuales patologas a travs de informacin
existente y el historial mdico del paciente.
El desarrollo de este proyecto se enfoca en contribuir a la salud de las personas, a travs de
la pronta deteccin de patrones de riesgo y el fomento de controles oportunos, con el fin de
apoyar a los mdicos en sus diagnsticos, minimizando las tasas de error por omisin de
informacin, mejorando con ello, la calidad de vida de los pacientes.
4. INTRODUCCIN
En el mbito del desarrollo del proyecto de tesis del segundo semestre del ao 2013, el
mdico cirujano Sr. Nelson Orellana Salinas especialista en Urologa de la clnica Uromed, ha
solicitado disear e implementar un sistema capaz de gestionar la informacin administrativa
de los pacientes.
El sistema permitir al mdico agregar nuevos pacientes, patologas preexistentes,
exmenes fsicos, diagnsticos, imagenologa 1, tratamientos, y evolucin de los pacientes,
1Imagenologa: conjunto
de
las
tcnicas
de
los
procedimientos
que
permiten
14 | P g i n a
5. OBJETIVOS
5.1.OBJETIVO GENERAL
Desarrollar un sistema de informacin que permita ingresar pacientes, con sus respectivos
datos mdicos, con la finalidad de realizar un seguimiento integral al proceso evolutivo de
stos, apoyando la toma de decisiones en el rea de la Urologa, en base a un sistema de
alertas.
5.2.
OBJETIVOS ESPECFICOS
6. SITUACIN ACTUAL
Actualmente la Clnica Uromed no posee ningn software encargado de gestionar la
informacin clnica de los pacientes, por lo que es vital y necesario implementar este sistema,
ya que como se mencion anteriormente, mejorar, en gran medida, la calidad del servicio
entregado a los pacientes y el tiempo de acceso a la informacin por parte de los mdicos.
Cabe sealar, que existe un sistema en la clnica encargado de la administracin de la
reserva de horas a los pacientes. Dicho sistema es utilizado tanto por los mdicos como por
las secretarias, y funciona bsicamente como un tipo de agenda, en el cual se registran las
horas que un cliente solicit por telfono o presencialmente. El flujo de trabajo es el
siguiente:
1. Un Paciente llama a la clnica para preguntar si existen horas disponibles el da
mircoles 24 de Septiembre
2. La secretaria busca en el sistema las horas disponibles y la ingresa junto con el
nombre y apellido del paciente
3. Luego el Mdico en su consulta accede a esta agenda para revisar los das y las
horas en los cuales los pacientes se atendern
A continuacin se expone una imagen del sistema implementado en Uromed.
16 | P g i n a
17 | P g i n a
Descripcin: El mdico puede ver los pacientes que tomaron hora con la secretaria.
18 | P g i n a
7. MARCO TEORICO
La Urologa es una especialidad mdico-quirrgica que se ocupa del estudio, diagnstico y
tratamiento de las patologas que afectan al aparato urinario, glndulas suprarrenales 1, retro
peritoneo de ambos sexos y al aparato reproductor masculino, sin lmite de edad. sta puede
tratar distintas ramas, como por ejemplo:
reproductor masculino
Androloga: La androloga es la parte de la urologa encargada del estudio,
investigacin, y exploracin de cualquier aspecto relacionado con la funcin sexual y
reproduccin masculina.
Los principales problemas de los que se encarga la androloga son los trastornos de
ereccin, otros trastornos sexuales del varn y la infertilidad masculina
20 | P g i n a
prstata
Urodinamia: Examen que permite detectar el mal funcionamiento de la vejiga y los
esfnteres, en enfermedades tan comunes como la incontinencia de orina en la mujer,
como as tambin para diagnosticar las disfunciones neurolgicas de la vejiga
21 | P g i n a
8. MARCO REFERENCIAL
A continuacin se describe brevemente un software que implementa, entre otros, mdulos de
gestin de pacientes:
22 | P g i n a
El sistema est diseado para que cada usuario configure su forma de trabajar; sus tipos de
visita, sus facultativos, sus actos mdicos, los servicios que ofrece y sus tarifas.
Figura 5: Toma de Horas Ofimedic
23 | P g i n a
1 Alertas tempranas: Sistema que indica mediante alertas si un paciente padece de algn
tipo de enfermedad, abastecindose de los exmenes y datos clnicos realizados
previamente.
24 | P g i n a
9.1ANLISIS Y COMPARACIN
9.1.1 Modelo Cascada
El Modelo Cascada fue creado por Winston W. Royce en 1970 y posteriormente revisada por
Barry Boehm en 1980 e Ian Sommerville en 1985.
En este modelo, el producto evoluciona a travs de una secuencia de fases ordenadas en
forma lineal, permitiendo iteraciones al estado anterior. El nmero de etapas suele variar,
pero en general suelen ser:
Anlisis
Diseo del software
Implementacin
Pruebas del sistema
Mantenimiento
Al final de cada fase el personal tcnico y los usuarios tienen la oportunidad de revisar el
progreso del proyecto.
1 Metodologa: Conjunto de mtodos que se siguen en una investigacin cientfica o en una
exposicin doctrinal.
25 | P g i n a
Como se puede ver, el modelamiento en cascada es til cuando estn presentes todas las
condiciones ptimas para el desarrollo del sistema, estas condiciones son: los requerimientos
claros del sistema, una carta Gantt definida, etc., cosa que no ocurre en los proyectos reales
de desarrollo, ya que generalmente ni siquiera los usuarios del sistema tienen claro que
necesitan para satisfacer su necesidad. Rara vez los proyectos siguen una linealidad y casi
siempre hay iteraciones que van ms all de la etapa anterior. Otro problema que presente el
modelo en cascada es que el sistema no estar en funcionamiento hasta finalizar el proyecto.
Figura 6: Modelo Cascada
Ventajas
Despus de cada etapa importante del desarrollo del software, se realizan pruebas
para comprobar el correcto funcionamiento del mdulo desarrollado
Desventajas
Muchas veces, sucede que el cliente no es muy claro de lo que exactamente quiere
del software. Cualquier cambio que se menciona en el medio puede causar mucha
confusin
27 | P g i n a
Los clientes no tienen que esperar hasta que el sistema se entregue completo para
sacar provecho de l. El primer incremento satisface los requerimientos que se
encuentran en la cima de la pirmide de prioridades, de tal forma que el software se
satisfactoria al cliente
Puesto que los servicios de ms alta prioridad se entregan primero, y los incrementos
posteriores se integran en ellos, es inevitable que los servicios ms importantes del
sistema sean a los que se les hagan ms pruebas. Esto significa que es menos
28 | P g i n a
probable que los clientes encuentren fallos de funcionamiento del software en las
partes ms importantes del sistema
Desventajas
Los incrementos deben ser relativamente pequeos y cada uno debe entregar alguna
funcionalidad del sistema. Puede ser difcil adaptar los requerimientos del cliente a
incrementos de tamao apropiado. Es ms, muchos de los sistemas requieren un
conjunto de recursos que se utilizan en diferentes partes del sistema, puesto que los
requerimientos no se definen en detalle hasta que un incremento se implementa,
puede ser difcil identificar los recursos comunes que requieren todos los incrementos.
El modelo incremental tiene una variante llamada programacin extrema, la cual se basa en
el desarrollo y la entrega de incrementos muy pequeos, la participacin constante del cliente
en el proceso, en la mejora constante del cdigo y en la programacin en parejas.
9.1.3 Modelo Espiral
El Modelo en Espiral, fue desarrollado por Barry Boehm en 1988, ste bsicamente tiene las
caractersticas de un desarrollo evolutivo, usando el modelo en cascada para cada etapa de
la iteracin, teniendo en cuenta el riesgo que aparece a la hora de desarrollar el software.
Para su realizacin se parte mirando las distintas alternativas posibles de desarrollo, se elige
la que posee un riesgo ms pequeo (asumible) y se hace un ciclo de espiral, en caso de
que el cliente quisiera seguir haciendo actualizaciones o mejoras al sistema.
29 | P g i n a
30 | P g i n a
Ventajas
Luego de cada evolucin tanto desarrollador como cliente pueden responder de mejor
Desventajas
Modelo costoso
31 | P g i n a
Plan rpido
Modelado, diseo rpido
Construccin del Prototipo
Desarrollo, entrega y retroalimentacin
Comunicacin
Ventajas
Desventajas
El cliente ve funcionando lo que para l es la primera versin del prototipo que ha sido
prcticamente un bosquejo lo que puede desencadenar la desilusin de ste
32 | P g i n a
El desarrollador puede ampliar el prototipo para construir el sistema final sin tener en
cuenta los compromisos de calidad y de mantenimiento que tiene con el cliente
34 | P g i n a
Ventajas
Desventajas
35 | P g i n a
9.2PARADIGMA SELECCIONADO: XP
Las metodologas giles1 estn basadas en el desarrollo incremental, donde los
requerimientos y soluciones evolucionan a medida que se va desarrollando el software,
puesto que los clientes van agregando o modificando las funcionalidades del sistema segn
les parezca conveniente.
Existen muchos mtodos de desarrollo gil, la mayora minimiza riesgos desarrollando
software en lapsos cortos, de esta manera se evita cambiar lo desarrollado hacia atrs.
El software desarrollado en una unidad de tiempo es llamado una iteracin, la cual debe
durar de una a cuatro semanas.
Cada iteracin del ciclo de vida incluye: planificacin, anlisis de requerimientos, diseo,
codificacin, revisin y documentacin. Una iteracin no debe agregar demasiada
funcionalidad para justificar el lanzamiento del producto al mercado, sino que la meta es
tener una demo2. Al final de cada iteracin el equipo vuelve a evaluar las prioridades del
proyecto.
La metodologa que se utilizar para el desarrollo del software: Sistema de Diagnostico
Prematuro para Urologa, ser una de las metodologas giles ms populares: Extreme
Programming (XP) o Programacin Extrema.
La seleccin de la metodologa se basa en:
Al igual que en las otras metodologas, para XP es necesario entender los requisitos, estimar
el esfuerzo, crear la solucin y entregar una solucin (producto) final al cliente.
Por esto, se trata de realizar ciclos de desarrollo cortos (llamados iteraciones), con
entregables funcionales al finalizar cada ciclo. En cada iteracin se realiza un ciclo completo
de anlisis, diseo, desarrollo y pruebas, pero utilizando un conjunto de reglas y prcticas
que caracterizan a XP.
37 | P g i n a
Esta fase dura tpicamente un par de semanas, y el resultado es una visin general del
sistema, y un plazo total estimado.
9.2.2 Fase de planificacin
La planificacin es una fase corta, en la que el cliente, los gerentes y el grupo de
desarrolladores acuerdan el orden en que debern implementarse las historias de usuario, y,
asociadas a stas, las entregas. Tpicamente esta fase consiste en una o varias reuniones
grupales de planificacin. El resultado de esta fase es un Plan de Entregas, o Release
Plan.
9.2.3 Fase de iteraciones
Esta es la fase principal en el ciclo de desarrollo de XP. Las funcionalidades son
desarrolladas en esta fase, generando al final de cada una un entregable funcional que
implementa las historias de usuario asignadas a la iteracin. Como las historias de usuario
no tienen suficiente detalle como para permitir su anlisis y desarrollo, al principio de cada
iteracin se realizan las tareas necesarias de anlisis, recabando con el cliente todos los
datos que sean necesarios. El cliente, por lo tanto, tambin debe participar activamente
durante esta fase del ciclo.
Las iteraciones son tambin utilizadas para medir el progreso del proyecto. Una iteracin
terminada sin errores es una medida clara de avance.
9.2.4 Fase de puesta en produccin
Si bien al final de cada iteracin se entregan mdulos funcionales y sin errores, puede ser
deseable por parte del cliente no poner el sistema en produccin hasta tanto no se tenga la
funcionalidad completa.
En esta fase no se realizan ms desarrollos funcionales, pero pueden ser necesarias tareas
de ajuste (fine tuning).
38 | P g i n a
10 PATRONES DE DISEO
Los patrones de diseo permiten al arquitecto de software resolver problemas de diseo de
software, ya que dan una descripcin de los elementos y tipos de relaciones con el fin de
formalizar la comunicacin y la reutilizacin de cdigo.
Dicho con otras palabras los patrones de diseo son colaboraciones parametrizadas1, es
decir, son un grupo de clases/objetos colaborando entre s que se pueden abstraer de un
conjunto de escenarios generales.
Para que una solucin sea considerada un patrn de diseo
interfaz de usuario.
Controlador: Responde a eventos, usualmente acciones del usuario, e invoca
peticiones al modelo y, probablemente, a la vista.
Para el desarrollo del sistema se utilizar MVC dado los beneficios comprobados que este
patrn de desarrollo ofrece, con MVC la aplicacin se puede desarrollar rpidamente, de
forma modular, facilitando la mantencin del software, a fin de que perdure en el tiempo y
pueda ser utilizado en distintos ambientes de trabajo.
Este modelo separa las funciones de la aplicacin en modelos, vistas y controladores lo que
hace que el sistema sea muy ligero, permitiendo aadir caractersticas nuevas rpidamente y
adaptar las antiguas.
El diseo modular permite a los programadores y diseadores trabajar en paralelo, as como
realizar rpidamente el desarrollo de prototipos. El hecho de que se lleve a cabo estas
separaciones, tambin permite que se puedan realizar adaptaciones en distintas partes de la
aplicacin sin que se vea afectado el resto del software.
Bsicamente en el patrn DAO se tienen 3 capas, Model, Enterprise y la Base de Datos. Por
cada tabla en la base de datos creamos una clase en el CodeBehind 1con el objetivo de
acceder a los datos de la BD2 desde el cdigo de manera ordenada.
La aplicacin se comunica con la capa Enterprise la cual encapsula el cdigo y enva a los
datos a la capa Model, la cual se encarga de generar las correspondientes interacciones con
la base de datos, utilizando los mtodos ShowList (mtodo para mostrar datos de la BD),
Create (Mtodo esttico que inserta en la BD) y mtodo Update (mtodo que actualiza los
datos en la BD), luego estos valores son enviados desde la capa Modela la capa Enterprise y
de la capa Enterprise al CodeBehind (Aplicacin).
1CodeBehind: Cdigo oculto, que solo puede ver el programador desde el intrprete.
2 BD: Base de Datos, aloja la informacin ingresada al sistema.
41 | P g i n a
11.1CASOS DE USO
11.1.1 Diagramas de Casos de Uso
El diagrama de casos de uso representa la forma en cmo un Cliente (Actor) opera con el
sistema en desarrollo, adems de la forma, tipo y orden en como los elementos interactan
(operaciones o casos de uso). Un diagrama de casos de uso consta de los siguientes
elementos:
Actor:
Un actores un rol que un usuario juega con respecto al sistema. Es importante destacar el
uso de la palabra rol, pues con esto se especifica que un actor no necesariamente
representa a una persona en particular, sino ms bien la labor que realiza frente al sistema.
Caso de Uso:
42 | P g i n a
Es una operacin/tarea especfica que se realiza tras una orden de algn agente externo,
sea desde una peticin de un actor o bien desde la invocacin desde otro caso de uso.
Relaciones:
Asociacin
Es el tipo de relacin ms bsica que indica la invocacin desde un actor o caso de uso a
otra operacin (caso de uso). Dicha relacin se denota con una flecha simple.
Generalizacin
Este tipo de relacin es uno de los ms utilizados, cumple una doble funcin dependiendo de
su estereotipo, que puede ser de Uso (<<uses>>) o de Herencia (<<extends>>).
Este tipo de relacin est orientado exclusivamente para casos de uso (y no para actores).
Extends: Se recomienda utilizar cuando un caso de uso es similar a otro (caractersticas).
Uses: Se recomienda utilizar cuando se tiene un conjunto de caractersticas que son
similares en ms de un caso de uso y no se desea mantener copiada la descripcin de la
caracterstica.
11.1.2 Narrativas de Casos de Uso
La ltima fase en el desarrollo de un modelo de casos de uso es la documentacin de los
casos de uso a travs de narrativas. Las narrativas de casos de uso permiten describir con
un alto grado de detalle cada uno de los casos de uso que se han desarrollado en los
diagramas de casos de uso.
La principal caracterstica de una narrativa de caso de uso, es describir paso a paso las
actividades que forman el caso de uso. De forma complementaria se deben aadir pasos
alternativos, as como condiciones, reglas y limitaciones que debe cumplir el caso de uso.
En este se pueden ver:
43 | P g i n a
Actores: son las personas que han participado en este caso de uso, esto sirve para
llevar un registro y saber a quin consultar con posterioridad sobre algn aspecto del
caso de uso.
Curso Normal: Se refiere al curso normal que posea un respectivo caso de uso.
Alternativa: Las alternativas son las condiciones que se deben cumplir, para que un
actor pueda realizar una determinada accin sobre el caso de uso.
Caso de Uso:
Actor:
Curso Normal
Alternativas
Si bien esto describe a la perfeccin el funcionamiento normal del caso de uso no existe un
solo tipo de narrativa de alto nivel, por lo que cada diseador de sistema est libre de poder
utilizar la narrativa que encuentre ms conveniente de acuerdo a sus necesidades.
44 | P g i n a
Transicin
Estado de accin
Nodos de decisin
Nodos de inicio y fin
Figura 15: Objetos Diagrama de actividad
En donde:
Ejemplo:
Una Cuenta Corriente que posee como caracterstica: balance, puede realizar las
operaciones de: depositar, girar y balance
El diseo asociado es:
46 | P g i n a
47 | P g i n a
Atributos y Mtodos
Atributos: Los atributos o caractersticas de una Clase pueden ser de tres tipos, los
que definen el grado de comunicacin y visibilidad de ellos con el entorno, estos son:
o public: Indica que el atributo ser visible tanto dentro como fuera de la clase,
es decir, es accesible desde todos lados.
o prvate: Indica que el atributo slo ser accesible desde dentro de la clase (slo
sus mtodos lo pueden accesar).
o protected: Indica que el atributo no ser accesible desde fuera de la clase,
pero si podr ser accesado por mtodos de la clase adems de las subclases
que se deriven.
Mtodos: Los mtodos u operaciones de una clase son la forma en cmo sta
interacta con su entorno, stos pueden tener las caractersticas:
o public: Indica que el mtodo ser visible tanto dentro como fuera de la clase,
es decir, es accesible desde todos lados.
o Prvate: Indica que el mtodo slo ser accesible desde dentro de la clase
(slo otros mtodos de la clase lo pueden accesar).
o protected: Indica que el mtodo no ser accesible desde fuera de la clase,
pero si podr ser llamado por mtodos de la clase adems de mtodos de las
subclases que se deriven.
Asociacin:
La relacin entre clases conocida como asociacin, permite asociar objetos que colaboran
entre s. Cabe destacar que no es una relacin fuerte, es decir, el tiempo de vida de un objeto
no depende del otro.
Ejemplo:
Un cliente puede tener asociadas muchas rdenes de compra, en cambio una orden de
compra solo puede tener asociado un cliente.
Herencia:
La herencia permite que una clase se derive de otra, de manera que extiende su
funcionalidad. La clase de la que se hereda se suele denominar clase base, clase padre,
superclase, clase ancestro.
49 | P g i n a
Una persona. (Se diferencia de cualquier otra persona, incluso siendo gemelos).
Un automvil. (Aunque sean de la misma marca, el mismo modelo,..., tendrn
Una entidad puede ser un objeto con existencia fsica como: una persona, un animal, una
casa, etc. (entidad concreta); o un objeto con existencia conceptual como: un puesto de
trabajo, una asignatura de clases, un nombre, etc. (entidad abstracta).
Una entidad est descrita y se representa por sus caractersticas o atributos. Por ejemplo, la
entidad Persona las caractersticas: Nombre, Apellido, Gnero, Estatura, Peso, Fecha de
nacimiento.
Atributos
Los atributos son las caractersticas que definen o identifican a una entidad. Estas pueden
ser muchas, y el diseador slo utiliza o implementa las que considere ms relevantes. Los
atributos son las propiedades que describen a cada entidad en un conjunto de entidades.
1 Interrelaciones: Que recprocamente se hace entre dos o ms personas, animales o cosas.
50 | P g i n a
En un conjunto de entidades del mismo tipo, cada entidad tiene valores especficos
asignados para cada uno de sus atributos, de esta forma, es posible su identificacin
unvoca.
Ejemplos:
A la coleccin de entidades alumnos, con el siguiente conjunto de atributos en comn, (id,
nombre, edad, semestre), pertenecen las entidades:
Relacin
Una relacin es una asociacin o relacin matemtica entre varias entidades. Las relaciones
tambin se nombran. Se representan en el diagrama E-R mediante lneas entre las
entidades. Cada entidad interviene en una relacin con una determinada cardinalidad. La
cardinalidad corresponde al nmero de instancias o elementos de una entidad que pueden
asociarse a un elemento de la otra entidad relacionada.
El tipo de relacin se define tomando los mximos de las cardinalidades que intervienen en la
relacin. Hay cuatro tipos posibles:
1. Una a una (1:1). En este tipo de relacin, una vez fijado un elemento de una entidad
se conoce la otra. Ejemplo: nacin y capital
2. Una a muchas (1: n). Ejemplo: cliente y pedidos
3. Muchas a una (n: 1). Simetra respecto al tipo anterior segn el punto de visto de una
u otra entidad
4. Muchas a muchas (n: n). Ejemplo: personas y viviendas
Notacin de Barker
La notacin de Barker se basa en que una entidad es un objeto de importancia que contiene
la informacin que se necesita saber; una entidad es representada de manera diagramtica
51 | P g i n a
por un rectngulo con las esquinas redondeadas con nombre; el nombre debe ser singular y
en mayscula.
Cada entidad debe ser nica y cada instancia tambin debe ser identificable de manera
nica.
Las asociaciones tienen dos terminales, cada una debe tener la cardinalidad que se refiere a
cuntos y la opcionalidad que se refiere si una instancia es opcional u obligatoria. La
terminacin similar a una pata de gallo representa muchos, la terminacin lineal representa
uno, la opcionalidad continua significa que es obligatoria y la opcionalidad discontinua
significa que es opcional.
Cada instancia de la entidad1 DEBE estar asociada con UNA Y SOLAMENTE UNA
instancia de la entidad2
Cada instancia de la entidad2 PUEDE estar asociada con UNA O MS instancias de
la entidad1
Cada instancia de la entidad1 DEBE (1) estar asociada con UNA Y SOLAMENTE UNA
(1) instancia de la entidad2. Esto significa que la cardinalidad explcita de la entidad2
Por tanto, la interpretacin de esta notacin debe hacerse, por un lado, leyendo de izquierda
a derecha la opcionalidad y cardinalidad respectivamente para interpretar la cardinalidad
explcita de la entidad2, y por otro lado, se debe leer de derecha a izquierda la opcionalidad y
cardinalidad respectivamente para interpretar la cardinalidad explcita de la entidad1. En
conclusin la interpretacin cruzada de la cardinalidad y de la opcionalidad de esta notacin
presenta una inconsistencia que plantea una barrera cognitiva e induce a error.
53 | P g i n a
13 FACTIBILIDAD Y MEDIOS
13.1 FACILIDADES PARA ABORDAR EL TEMA
La clnica Uromed ha abierto sus puertas para el desarrollo del sistema, brindando acceso a
informacin privilegiada acerca de sus pacientes. Adems ha puesto a un mdico a cargo de
la realizacin de este proyecto, quien es el encargado de ensear el negocio y de poner a
disposicin de los ingenieros de software la informacin necesaria para poder realizar un
proyecto de calidad.
Dnde:
Vt: flujos de caja en cada periodo
I0: representa el valor del reembolso inicial del proyecto
N: es el nmero de periodos considerados
K: el tipo de inters aplicado
De esta forma si el VAN2 del sistema toma un valor = 0, K pasa a tomar el nombre de TIR 3 .
Es decir el van del proyecto puede tomar 3 valores:
1Es el servicio que provee a los usuarios de Internet un sistema para poder almacenar
informacin, imgenes, vdeo, o cualquier contenido accesible va web.
2Valor Actual Neto
55 | P g i n a
VAN = 574.316
Dado que VAN > 0 resulta rentable realizar el proyecto.
reacios al cambio, facilitando de gran manera el llevar a cabo la migracin del sistema actual
al nuevo sistema de administracin y prevencin.
13.6FACTIBILIDAD LEGAL
El proyecto a desarrollar velar por la privacidad de datos personales y el uso adecuado de
las licencias de software a utilizar, y se regir bajo las siguientes normas respectivamente:
Ley 17.336 PROPIEDAD INTELECTUAL, la cual protege los derechos que, por el
solo hecho de la creacin de la obra, adquieren los autores de obras de la inteligencia
en los dominios literarios, artsticos y cientficos, cualquiera que sea su forma de
expresin, y los derechos conexos que ella determina. El derecho de autor comprende
los derechos patrimonial y moral, que protegen el aprovechamiento, la paternidad y la
integridad de la obra.
57 | P g i n a
14.
Se realizaron diversas reuniones con el Mdico Cirujano Nelson Orellana, en las cuales se
describieron los distintos requerimientos de la Clnica que deben ser considerados en el
proyecto.
A continuacin de describen las historias de usuario resultantes de esta fase.
14.1.1 Historia de Usuario 1: Requerimientos generales
En la primera reunin se establecen los alcances generales, ya que el mdico no tena claro
todos los requerimientos para el desarrollo del software. El resultado de la reunin es la
primera historia de usuario, la cual entrega una visin general de las expectativas
relacionadas al desarrollo del sistema.
Ingenieros: Entonces Sr. Orellana, cules son los aspectos generales que
requiere sean administrados por un software?
59 | P g i n a
si [ ] no [x]
>5[ ]
1 cajetilla[x] y as
60 | P g i n a
travs
alertas
tempranas,
fin
de
diagnosticar
62 | P g i n a
fcilmente
Ingenieros: Entonces para ustedes es fundamental tener una interfaz clara
y simple
Mdico Orellana: Si, bueno eso sobre la interfaz, ahora tambin es
necesario tener una forma de control de usuarios, ya que no cualquier
persona puede realizar cambios en los pacientes, en los exmenes o las
A continuacin se detallan los requisitos del sistema, con su respectiva historia de usuario
(H.U) asociada, tipo de requisito, explicacin y prioridad establecida.
Se definirn los siguientes niveles de prioridad:
1: Mxima Prioridad
2: Alta Prioridad
3: Media Prioridad
4: Baja Prioridad
5: Muy Baja Prioridad
64 | P g i n a
Tabla de requisitos
Tabla 1: Requisitos funcionales y no funcionales
H.Usuario
Tipo de requisito
Explicacin
Prioridad
H1
Requisito
Funcional
H1
Requisito
Funcional
H1
Requisito
Funcional
H1
Requisito
Funcional
H1
Requisito
Funcional
H1
Requisito
Funcional
H1
Requisito
Funcional
H1
Requisito
Funcional
H1
Requisito
Funcional
10
H2
Requisito
Funcional
11
H2
Requisito
Funcional
12
H2
Requisito
Funcional
13
H2
Requisito
Funcional
14
H3
Requisito
Funcional
15
H4
Requisito
Funcional
16
H5
Requisito no
Funcional
Interfaz simple
17
H5
Requisito no
Funcional
65 | P g i n a
18
H5
Requisito no
Funcional
19
H5
Requisito no
Funcional
Filtro de Pacientes
Alternativas
66 | P g i n a
67 | P g i n a
68 | P g i n a
69 | P g i n a
70 | P g i n a
71 | P g i n a
72 | P g i n a
73 | P g i n a
74 | P g i n a
75 | P g i n a
76 | P g i n a
En el siguiente Diagrama de Actividad se puede ver como un mdico puede administrar los
Tipos de Enfermedad existente en el sistema, permitindole realizar acciones como: agregar,
editar, eliminar y listar.
Como se ve en la imagen, ciertas actividades dependen de una serie de restricciones que el
Mdico Administrador deber cumplir, de esta forma si se quiere agregar un Tipo de
Enfermedad nueva al sistema, ser posible siempre que sta no exista previamente, al igual
que si se desea eliminar un Tipo de Enfermedad, se corroborar antes que sta no est
asociado a ninguna Enfermedad vigente en el momento.
Figura 31: Diagrama de Actividad Administracin de Enfermedades
77 | P g i n a
78 | P g i n a
79 | P g i n a
80 | P g i n a
El siguiente Diagrama de Actividades refleja como el Mdico administra los Sntomas de los
pacientes, pudiendo agregar nuevos Sntomas, editar y eliminar los Sntomas existentes.
Figura 35: Diagrama de Actividad Administracin de Sntomas
81 | P g i n a
82 | P g i n a
83 | P g i n a
Diseo
Arquitectura de Hardware
Tanto la aplicacin
como la base de datos estarn alojadas en el servidor (Windows Server 2003) de Uromed, el
cual cuenta con IIS 6.0, como servidor web y aplicaciones, y Microsoft SQL Server 2005,
como servidor de base de datos.
La distribucin de los componentes en el servidor es la siguiente:
84 | P g i n a
85 | P g i n a
Arquitectura de Software
Tal
como
se
86 | P g i n a
87 | P g i n a
Modelo de Clases
88 | P g i n a
89 | P g i n a
Diccionario de datos
Nombre Entidad:
Paciente
Descripcin:
Field
Tipo
IdPaciente
Int PK
Previsin
Varchar
''
Nombre de la Previsin
Rut
Varchar
''
Nombres
Varchar
''
ApellidoPat
Varchar
''
ApellidoMat
Varchar
''
Sexo
Varchar
''
FechaNacimiento
DateTime
'01/01/1900'
Nacionalidad
Varchar
''
Domicilio
Varchar
''
Telfono
Varchar
''
CorreoElectronico
Varchar
''
CodigoArea
Varchar
'
TelefonoMovil
Int
FechaRegistro
DateTime
'01/01/1900'
Usuario
Varchar
''
Estado
Tinyint
Descripcin
Nombre
Entidad:
Sntoma
Descripcin:
Field
Tipo
IdSintoma
Int PK
Nombre
Varchar
'
Descripcin
Varchar
''
Descripcin
FechaCreacion DateTime
Usuario
''
Varchar
90 | P g i n a
Estado
Tinyint
91 | P g i n a
Nombre Entidad:
Tipo Enfermedad
Descripcin:
Field
Tipo
IdTipoEnfermedad
Int PK
Descripcin
Varchar
''
Nombre
Varchar
''
Estado
Tinyint
Usuario
Varchar
''
FechaCreacion
DateTime '01/01/1900'
Nombre Entidad:
Medicamento
Descripcin:
Field
Tipo
IdMedicamento
Int PK
Descripcin
Varchar
''
Componentes
Varchar
''
FechaCreacion
DateTime '01/01/1900'
Usuario
Varchar
''
Estado
Tinyint
Nombre Entidad:
Categora Examen
Descripcin:
Field
Tipo
Descripcin
Descripcin
Descripcin
IdCaterogiaExamen Int PK
Nombre
Varchar
''
Descripcin
Varchar
''
Estado
Tinyint
92 | P g i n a
Usuario
Varchar
''
FechaCreacion
DateTime '01/01/1900'
93 | P g i n a
Nombre Entidad:
Tratamiento
Descripcin:
Field
Tipo
IdTratamiento
Int PK
Nombre
Varchar
''
Descripcin
Varchar
''
Usuario
Varchar
''
Estado
Tinyint
FechaCreacion
Descripcin
Nombre Entidad:
Especialidad
Descripcin:
Field
Tipo
IdEspecialidad
Int PK
Nombre
Varchar
''
Nombre de la especialidad
Descripcin
Varchar
''
Descripcin de la especialidad
Usuario
Varchar
''
Usuario de creacin de la
especialidad
Estado
Tinyint
FechaCreacion
DateTime '01/01/1900'
Descripcin
Nombre Entidad:
Mdico
Descripcin:
Field
Tipo
IdMedico
Int PK
IdEspecialidad
Int FK
Rut
Varchar
''
Cargo
Varchar
''
Nombres
Varchar
''
ApellidoPaterno
Varchar
''
ApellidoMaterno
Varchar
''
Sexo
Varchar
''
Descripcin
94 | P g i n a
FechaNacmiento
DateTime
'01/01/1900'
Nacionalidad
Varchar
''
Domicilio
Varchar
''
Telfono
Varchar
''
CorreoElectronic
o
Varchar
''
CodigoArea
Varchar
'
FechaRegistro
DateTime
'01/01/1900'
Estado
Tinyint
Usuario
Varchar
''
Password
Varchar
''
Construccin
A continuacin se muestra la distribucin de los componentes en el IDE de programacin
Visual Studio 2012.
95 | P g i n a
Mantenedor de Pacientes
96 | P g i n a
97 | P g i n a
98 | P g i n a
Pruebas
Para las pruebas del sistema se utilizan casos de prueba. En Ingeniera de Software los
casos de prueba son un conjunto de condiciones bajo las cules un desarrollador determina
el buen funcionamiento de un sistema informtico.
Con el propsito de comprobar que todos los requisitos del sistema son revisados, se realiza
al menos un caso de prueba para cada requisito. En el caso de que un requisito tenga
requisitos secundarios, se realizaran los casos necesarios para comprobar que se satisface
la totalidad del requerimiento, tanto casos positivos como negativos.
Pruebas Iteracin 1
Caso de
prueba
Categora
Examen
Descripcin del
caso
Ingreso, edicin
y eliminacin de
Categoras de
Exmenes
Medicamento
Ingreso, edicin
y eliminacin de
Medicamentos
Tipo
Enfermedad
Ingreso, edicin
y eliminacin de
Tipos de
Enfermedades
Especialidad
Ingreso, edicin
y eliminacin de
Especialidades
Mdico
Ingreso, edicin
y eliminacin de
Mdicos
Paciente
Ingreso, edicin
y eliminacin de
Pacientes
Pre requisitos
Mantenedor de
Categoras de
Exmenes, Tabla
de Exmanes
(Concluido)
Mantenedor de
Medicamentos,
Tabla Medicacin
(Concluido)
Mantenedor de
Tipos de
Enfermedades,
Tabla de
Enfermedades
(Concluido)
Mantenedor de
Especialidades,
Tabla de Mdicos
(Concluido)
Mantenedor de
Mdicos, Tabla
de Historiales
Mdicos
(Concluido)
Mantenedor de
Pacientes, Tabla
de Historiales
Mdicos
Resultado
esperado
Correcto ingreso,
edicin y
eliminacin de
Categora de
Exmenes.
Estado
Correcto ingreso,
edicin y
eliminacin de
Medicamentos
Cumplido
Correcto ingreso,
edicin y
eliminacin de
Tipos de
Enfermedad.
Cumplido
Correcto ingreso,
edicin y
eliminacin de
Especialidades
Cumplido
Correcto ingreso,
edicin y
eliminacin de
Mdicos.
Cumplido
Correcto ingreso,
edicin y
eliminacin de
Pacientes.
Cumplido
Cumplido
99 | P g i n a
Sntoma
Ingreso, edicin
y eliminacin de
Sntomas
Tratamiento
Ingreso, edicin
y eliminacin de
Tratamientos
(Concluido)
Mantenedor de
Sntomas, Tabla
de
Enfermedades,
Tabla de
Historiales
Mdicos
(Concluido)
Mantenedor de
Tratamientos,
Tabla de
Procedimientos
(Concluido)
Correcto ingreso,
edicin y
eliminacin de
Sntomas.
Cumplido
Correcta ingreso,
edicion y
eliminacin de
tratamientos.
Cumplido
100 | P g i n a
14.2.2 Iteracin 2
Anlisis
101 | P g i n a
102 | P g i n a
103 | P g i n a
104 | P g i n a
105 | P g i n a
106 | P g i n a
107 | P g i n a
108 | P g i n a
Diseo
Modelo de Clases
109 | P g i n a
110 | P g i n a
Diccionario de Datos
Nombre Entidad:
Examen General
Descripcin:
Field
Tipo
IdExamenGeneral
Int PK
Descripcin
0
idCategoriaExamen Int FK
Nombre
Varchar
''
Descripcin
Varchar
''
Precio
Money
FechaCreacion
DateTime '01/01/1900'
Usuario
Varchar
''
Estado
Tinyint
Nombre Entidad:
Examen Especfico
Descripcin:
Field
Tipo
IdExamenEspecfic
o
Int PK
idExamenGeneral
Int FK
Nombre
Varchar
''
Descripcin
Varchar
''
ValorMinimoNormal
Integer
valorMaximoNormal Integer
Descripcin
FechaCreacion
DateTime '01/01/1900'
Usuario
Varchar
''
Estado
Tinyint
Nombre Entidad:
Procedimiento
Descripcin:
111 | P g i n a
Field
Tipo
Descripcin
IdProcedimiento
Int PK
IdTratamiento
Int FK
Descripcin
Varchar
''
Precio
Money
Duracin
Int
Dosis
Int
Frecuencia
Int
Usuario
Varchar
''
Estado
Tinyint
FechaCreacion
Field
Tipo
IdMedicacion
Int PK
IdMedicamento
Int FK
Dosis
Int
Dosis de la medicacin
Descripcin
Varchar
''
Precio
Money
Frecuencia
Int
Duracin
Int
Usuario
Varchar
''
Estado
Tinyint
FechaCreacion
Descripcin
112 | P g i n a
Construccin
Pruebas
Pruebas Iteracin 2
Caso de
prueba
Examen
General
Descripcin del
caso
Ingreso, edicin
y eliminacin
de Exmenes
Generales
Examen
Especfico
Ingreso, edicin
y eliminacin
de Exmenes
Especficos
Procedimiento
Ingreso, edicin
y eliminacin
de
Procedimientos
Medicacin
Ingreso, edicin
y eliminacin
de
Medicaciones
Pre requisitos
Mantenedor de
Exmenes
Generales, Tabla
de Exmenes
Especficos
(Concluido)
Mantenedor de
Exmenes
Especficos,
Tabla
Enfermedades
(Concluido)
Mantenedor de
Procedimientos,
Tabla de
Enfermedades,
Tabla de
Historiales
Mdicos
(Concluido)
Mantenedor de
Medicamentos,
Tabla de
Enfermedades,
Tabla de
Historiales
Mdicos
(Concluido)
Resultado
esperado
Correcto ingreso,
edicin y
eliminacin de
Exmenes
Generales
Estado
Correcto ingreso,
edicin y
eliminacin de
Exmenes
Especficos
Cumplido
Correcta ingreso,
edicion y
eliminacin de
Procedimientos.
Cumplido
Correcta ingreso,
edicion y
eliminacin de
Medicaciones
Cumplido
Cumplido
114 | P g i n a
14.2.3 Iteracin 3
Anlisis
115 | P g i n a
116 | P g i n a
117 | P g i n a
ms operaciones.
118 | P g i n a
119 | P g i n a
120 | P g i n a
121 | P g i n a
Diseo
Modelo de Clases
122 | P g i n a
Diccionario de Datos
Nombre Entidad:
Enfermedad
Descripcin:
Field
Tipo
IdEnfermedad
Int PK
IdTipoEnfermedad
Int FK
Descripcin
Varchar
''
Descripcin de la enfermedad
Nombre
Varchar
''
Nombre de la enfermedad
Gravedad
Integer
Gravedad de la enfermedad
FechaCreacion
Usuario
Varchar
Descripcin
''
123 | P g i n a
el sistema
Estado
Tinyint
Estados 1 = Confirmado , 2= No
Confirmado
Nombre Entidad:
Historial Mdico
Descripcin:
Field
Tipo
IdHistorialMedico
Int PK
IdPaciente
Int FK
IdMedico
Int FK
Descripcin
Varchar
''
FechaCreacion
Usuario
Varchar
''
Estado
Tinyint
Estados 1 = Vigente , 2= no
Vigente
Descripcin
124 | P g i n a
Nombre Entidad:
Enfermedad Sntoma
Descripcin:
Field
Tipo
IdEnfermedadSintom
a
Int PK
IdEnfermedad
Int FK
IdSintoma
Int FK
FechaCreacion
Usuario
Varchar
''
Estado
Tinyint
Estados 1 = Vigente , 2= no
Vigente
Descripcin
Nombre Entidad:
Descripcin:
Field
Tipo
Descripcin
IdHistorialMedicoSintoma Int PK
IdHistorialMedico
Int FK
IdSintoma
Int FK
FechaCreacion
DateTim
e
'01/01/1900
Fecha de creacin de la relacin
'
Usuario
Varchar
''
Estado
Tinyint
Estados 1 = Vigente , 2= no
Vigente
125 | P g i n a
Pruebas
Pruebas Iteracin 3
Caso de
prueba
Enfermedad
Descripcin del
caso
Ingreso, edicin
y eliminacin de
Enfermedades
Historial
Mdico
Ingreso, edicin
y eliminacin de
Historiales
Mdicos
Pre requisitos
Mantenedor de
Enfermedades,
Tabla de
Medicaciones,
Tabla de
Procedimientos,
Tabla de
Exmenes
Especficos,
Tabla de
Diagnsticos,
Tabla de
Enfermedades
Sntomas
(Concluido)
Mantenedor de
Historiales
Mdicos, Tabla
de Diagnstico,
Tabla de
Resultados
Exmenes y/o
Historiales
Mdicos
Sintomas
(Concluido)
Resultado
esperado
Correcta ingreso,
edicion y
eliminacin de
Enfermedades
Estado
Correcta ingreso,
edicion y
eliminacin de
Historiales
Mdicos
Pendiente
Cumplido
126 | P g i n a
14.2.4 Iteracin 4
Anlisis
127 | P g i n a
128 | P g i n a
accin
129 | P g i n a
130 | P g i n a
131 | P g i n a
132 | P g i n a
Diseo
Modelo de Clases
133 | P g i n a
Diccionario de Datos
Nombre Entidad:
Diagnostico
Descripcin:
Field
Tipo
IdDiagnostico
Int PK
IdHistorialMedico
Int FK
IdEnfermedad
Int FK
Descripcin
Varchar
''
FechaCreacion
Usuario
Varchar
Descripcin
''
134 | P g i n a
Estado
Tinyint
Nombre Entidad:
ResultadoExamen
Descripcin:
Field
Tipo
IdResultadoExamen
Int PK
IdHistorialMedico
Int FK
IdExamenGeneral
Int FK
ValorNumerico
Int
ValorDescriptivo
Varchar
''
FechaCreacion
Usuario
Varchar
''
Estado
Tinyint
Descripcin
135 | P g i n a
Construccin
Maqueta Mantenedor Resultados de Exmenes
136 | P g i n a
137 | P g i n a
Pruebas
Pruebas Iteracin 4(Final)
Caso de
prueba
Diagnstico
Descripcin del
caso
Ingreso, edicin
y eliminacin de
Diagnsticos
Pre requisitos
Resultado
Examen
Ingreso, edicin
y eliminacin de
Mantenedor de
Resultados de
Mantenedor de
Diagnsticos
(Concluido)
Resultado
esperado
Correcta ingreso,
edicion y
eliminacin de
Diagnsticos
asociados a un
Historial Mdico
generado por un
determinado
Mdico
Correcta ingreso,
edicion y
Estado
Pendiente
Cumplido
138 | P g i n a
Resultados de
Exmenes
Exmenes
(Concluido)
eliminacin de
Resultados de
Exmenes
asociados a un
Historial Mdico
generado por un
determinado
Mdico
139 | P g i n a
15.
CONCLUSIN
A partir de los resultados obtenidos y la apreciacin de los mdicos que han utilizado el
software, se concluye que este proyecto adquiere gran relevancia, pues contribuye con la
salud de las personas. El sistema de diagnstico prematuro entrega informacin oportuna y
de calidad, teniendo por objetivo apoyar la labor de los mdicos agilizando la toma de
decisiones, disminuyendo la posibilidad de errores. Se disearon las estructuras necesarias
para gestionar la informacin y generar reportes que alertan a los mdicos sobre anomalas
en las tendencias normales de padecimiento de enfermedades.
Para poder cumplir con los objetivos mencionados, se realizaron una serie de capacitaciones
a los mdicos con el fin de fortalecer su aprendizaje, en bsqueda de que este software
llegue a convertirse en una herramienta fundamental al momento de realizar sus labores.
A partir de las primeras versiones del sistema se aprecia una buena adaptacin de los
mdicos, ya que no se presentaron mayores problemas en el uso de los mdulos
implementados. Existe gran inters por los beneficios que el sistema aporta, ya que no slo
es un sistema de registro, como los que generalmente existen para el rea, sino que entrega
gran valor al momento de generar informacin rpida respecto a los pacientes y la tendencia
de enfermedades, apoyando a la investigacin y entrega de informacin relevante a los
profesionales. Es importante considerar que a travs de medicina preventiva y el auto
cuidado del paciente es posible minimizar el riesgo de padecer algn tipo enfermedad.
Finalmente, es fundamental destacar el importante aporte que significa utilizar una
metodologa de software en el desarrollo de un sistema, ya que permite mantener un orden
estructural. Por otra parte, sirven de gua a los ingenieros para interactuar con los clientes,
logrando entender y modelar sus necesidades, dando solucin a problemticas totalmente
distintas al rea informtica, como lo es la medicina.
140 | P g i n a
16.
BIBLIOGRAFA
16.1LIBROS
[PRESSMAN]
[LAURENT]
[MINSAL]
http://www.cancerprostata.cl/quees.html
[OFIMEDIC]
http://www.ofimedic.com/ofimedic-4.html
[UROMED]
http://www.uromed.cl/especialidades.php
[UROLOGIA]
http://es.wikipedia.org/wiki/Urolog%C3%ADa
[UML]
http://users.dcc.uchile.cl/~psalinas/uml/introduccion.html
[REGXP]
http://iie.fing.edu.uy/~josej/docs/XP%20-%20Jose%20Joskowicz.pdf
[RUP1]
http://www-01.ibm.com/software/rational/rup/
[XP1]
http://www.extremeprogramming.org/
[RUP2]
http://yaqui.mxl.uabc.mx/~molguin/as/RUP.htm
[MVC]
http://www.desarrolloweb.com/wiki/mvc-modelo-vista-controlador.html
[ARQ-SW]
http://es.wikipedia.org/wiki/Arquitectura_de_software
[ARQ-HW]
http://www.virtual.unal.edu.co/cursos/ingenieria
RUP
141 | P g i n a