Está en la página 1de 141

NDICE DE CONTENIDO

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

9.1.1 Modelo Cascada.................................................................................12


9.1.2 Modelo Incremental............................................................................14
9.1.3 Modelo Espiral....................................................................................16
9.1.4 Modelo de Prototipos..........................................................................18
9.1.5 Modelo de Proceso Unificado de Desarrollo......................................20
9.2

PARADIGMA SELECCIONADO: XP.....................................................22

9.2.1 Fase de exploracin............................................................................23


9.2.2 Fase de planificacin..........................................................................24
1|Pgina

9.2.3 Fase de iteraciones.............................................................................24


9.2.4 Fase de puesta en produccin...........................................................24
10

PATRONES DE DISEO..........................................................................25

10.1

MODELO VISTA CONTROLADOR...................................................25

10.2

DATA ACCESS OBJECT...................................................................26

11

LENGUAJE UNIFICADO DE MODELADO (UML)...................................28

11.1

CASOS DE USO................................................................................28

11.1.1 Diagramas de Casos de Uso............................................................28


11.1.2 Narrativas de Casos de Uso.............................................................29
11.2

DIAGRAMA DE ACTIVIDAD..............................................................31

11.3

MODELO DE CLASES......................................................................31

12

DIAGRAMA ENTIDAD RELACIN DE BASE DE DATOS......................35

13

FACTIBILIDAD Y MEDIOS.......................................................................39

13.1

FACILIDADES PARA ABORDAR EL TEMA......................................39

13.2

DIFICULTADES PARA ABORDAR EL TEMA....................................39

13.3

FACTIBILIDAD TCNICA..................................................................39

13.4

FACTIBILIDAD ECONMICA............................................................40

13.5

FACTIBILIDAD HUMANA U OPERACIONAL....................................41

13.6

FACTIBILIDAD LEGAl........................................................................42

14.

PROCESO DE DESARROLLO DE SOFTWARE.....................................43

14.1

FASE DE EXPLORACIN.................................................................43

14.1.1 Historia de Usuario 1: Requerimientos generales............................43


14.1.2 Historia de Usuario 2: Especificaciones del sistema........................43
14.1.3 Historia de Usuario 3: Fichas mdicas.............................................45
14.1.4 Historia de Usuario 4: Alertas tempranas.........................................45
2|Pgina

14.1.5 Historia de Usuario 5: Interfaz del programa y seguridad................46


14.2

FASE DE PLANIFICACIN...............................................................47

14.3

FASE DE ITERACIONES..................................................................50

14.3.1 Iteracin 1.........................................................................................50


14.2.2 Iteracin 2.........................................................................................80
14.2.3 Iteracin 3.........................................................................................95
14.2.4 Iteracin 4.......................................................................................105
15.

Conclusin..............................................................................................117

16.

Bibliografa..............................................................................................118

16.1

Libros................................................................................................118

16.2

Sitios Web........................................................................................118

3|Pgina

NDICE DE FIGURAS Y TABLAS


Figura 1: Ingreso Peticin de Horas.....................................................................4
Figura 2: Listado de Horas...................................................................................5
Figura 3: Men Ofimedic......................................................................................9
Figura 4 : Historias Mdicas Ofimedic................................................................10
Figura 5: Toma de Horas Ofimedic.....................................................................10
Figura 6: Modelo Cascada..................................................................................13
Figura 7: Modelo Incremental.............................................................................14
Figura 8: Modelo Espiral.....................................................................................17
Figura 9: Modelo de Construccin de Prototipos...............................................19
Figura 10: Modelo de Proceso Unificado...........................................................20
Figura 11: Diagrama Metodologa XP................................................................23
Figura 12: Patrn de Diseo DAO......................................................................27
Figura 13: Actor..................................................................................................28
Figura 14: Caso de Uso......................................................................................28
Figura 15: Objetos Diagrama de actividad.........................................................31
Figura 16: Ejemplo de Clase..............................................................................32
Figura 17: Ejemplo de Clase 2...........................................................................32
Figura 18: Objetos Relacin de Clases..............................................................34
Figura 19: Objetos Herencia de Clases.............................................................34
Figura 20: Ejemplo de una relacin segn notacin Barker..............................37
Tabla 1: Requisitos funcionales y no funcionales...............................................49
Figura 21: Diagrama Caso de Uso Administracin de Categoras de Exmenes50
Tabla 2: Narrativa Caso de Uso Administracin de Categoras de Exmenes..50
Figura 22: Diagrama Caso de Uso Administracin de Medicamentos...............51
Tabla 3: Narrativa Caso de Uso Administracin de Medicamentos...................51
Figura 23: Diagrama Caso de Uso Administracin de Tipos de Enfermedad....52
Tabla 4: Narrativa Caso de Uso Administracin de Tipos de Enfermedad........52
Figura 24: Diagrama Caso de Uso Administracin de Especialidades..............53
Tabla 5: Narrativa Caso de Uso Administracin de Mdicos.............................53
4|Pgina

Figura 25: Diagrama Caso de Uso Administracin de Mdicos.........................54


Tabla 6: Narrativa Caso de Uso Administracin de Mdicos.............................54
Figura 26: Diagrama Caso de Uso Administracin de Pacientes......................55
Tabla 7: Narrativa Caso de Uso Administracin de Pacientes...........................55
Figura 27: Diagrama Caso de Uso Administracin de Sntomas.......................56
Tabla 8: Narrativa Caso de Uso Administracin de Sntomas............................56
Figura 28: Diagrama Caso de Uso Administracin de Tratamientos.................57
Tabla 9: Narrativa Caso de Uso Administracin de Tratamientos......................57
Figura 29: Diagrama de Actividad Administracin de Categoras de Exmenes58
Figura 30: Diagrama de Actividad Administracin de Medicamentos................59
Figura 31: Diagrama de Actividad Administracin de Enfermedades................60
Figura 32: Diagrama de Actividad Administracin de Especialidades...............61
Figura 33: Diagrama de Actividad Administracin de Mdicos..........................62
Figura 34: Diagrama de Actividad Administracin de Pacientes........................63
Figura 35: Diagrama de Actividad Administracin de Sntomas........................64
Figura 36: Diagrama de Actividad Administracin de Tratamientos...................65
Figura 37: Modelo Lgico (Conceptual) de Base de Datos Iteracin 1.............66
Figura 38: Arquitectura de Hardware..................................................................67
Figura 39: Arquitectura de Software...................................................................68
Figura 40: Modelo de Clases Iteracin 1............................................................69
Figura 41: Modelo Fsico de Base de Datos Iteracin 1....................................70
Figura 42: Modelo y Controlador de Sistema.....................................................74
Figura 43: Mantenedor de Pacientes.................................................................75
Figura 44: Ingreso, edicin y eliminacin de Sntomas......................................76
Figura 45: Ingreso, edicin y eliminacin de Mdicos.......................................77
Figura 46: Diagrama Caso de Uso Administracin de Medicaciones................80
Tabla 10: Narrativa Caso de Uso Administracin de Medicaciones...................80
Figura 47: Diagrama Caso de Uso Administracin de Procedimientos.............81
Tabla 11: Narrativa Caso de Uso Administracin de Procedimientos................81
Figura 48: Diagrama Caso de Uso Administracin de Exmenes Generales.. .82
Tabla 12: Narrativa Caso de Uso Administracin de Exmenes Generales......82
5|Pgina

Figura 49: Diagrama Caso de Uso Administracin de Exmenes Especficos. 83


Tabla 13: Narrativa Caso de Uso Administracin de Exmenes Especficos....83
Figura 50: Diagrama de Actividad Administracin de Medicaciones.................84
Figura 51: Diagrama de Actividad Administracin de Procedimientos...............85
Figura 52: Diagrama de Actividad Administracin de Exmenes Generales.....86
Figura 53: Diagrama de Actividad Administracin de Exmenes Especficos...87
Figura 54: Modelo Lgico (Conceptual) de Base de Datos Iteracin 2.............88
Figura 55: Modelo de Clases Iteracin 2............................................................89
Figura 56: Modelo Fsico de Base de Datos Iteracin 2....................................90
Figura 57: Maqueta Listado de Exmenes Generales.......................................93
Figura 58: Maqueta Edicin de Exmenes Generales.......................................93
Figura 59: Diagrama Caso de Uso Administracin de Enfermedades...............95
Tabla 14: Narrativa Caso de Uso Administracin de Enfermedades.................95
Figura 60: Diagrama Caso de Uso Administracin de Historiales Mdicos.......96
Tabla 15: Narrativa Caso de Uso Administracin de Historiales Mdicos.........96
Figura 61: Diagrama de Actividad Administracin de Enfermedades................97
Figura 62: Diagrama de Actividad Administracin de Historiales Mdicos........98
Figura 63: Modelo Lgico (Conceptual) de Base de Datos Iteracin 3.............99
Figura 64: Modelo de Clases Iteracin 3..........................................................100
Figura 65: Modelo Fsico de Base de Datos Iteracin 3..................................101
Figura 66: Diagrama Caso de Uso Administracin de Diagnsticos...............105
Tabla 16: Narrativa Caso de Uso Administracin de Diagnsticos..................105
Figura 67: Diagrama Caso de Uso Administracin Resultados de Exmenes.106
Tabla 17: Narrativa Caso de Uso Administracin Resultados de Exmenes.. 106
Figura 68: Diagrama de Actividad Administracin de Diagnsticos.................107
Figura 69: Diagrama de Actividad Administracin Resultados de Exmenes. 108
Figura 70: Modelo Lgico (Conceptual) de Base de Datos Iteracin 4...........109
Figura 71: Modelo de Clases iteracin 4..........................................................110
Figura 72: Modelo Fsico de Base de Datos Iteracin 4...................................111
Figura 73: Maqueta Mantenedor Resultado de Exmenes..............................113
Figura 74: Maqueta Ingreso Resultados de Exmenes...................................113
6|Pgina

Figura 75: Maqueta Alertas...............................................................................115

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!

Jaime Esteban Meza Araneda

8|Pgina

En estas lneas quiero expresar mi ms profundo y sincero agradecimiento a todas aquellas


personas que con su ayuda han colaborado en la realizacin del presente proyecto de tesis,
en especial el Sr. Edgardo Mauricio Campos Martnez, profesor gua de este proyecto, por la
orientacin, el seguimiento y la supervisin continua de la misma, pero sobre todo por la
motivacin y el apoyo recibido a lo largo de este proyecto.
Especial reconocimiento merece el inters mostrado por nuestro trabajo y las sugerencias
recibidas de la profesora Valentina Tombolini Echeverra, con la que nos encontramos muy
agradecidos por el nimo infundido y la confianza depositada en nosotros.
A mi amigo Sebastin Altamirano, por su ayuda

incondicional y al Dr. Nelson Orellana

Salinas, Urolgo y a su equipo mdico por su colaboracin en el suministro de los datos y de


las instalaciones de Uromed, necesarias para la realizacin de este proyecto.
Un agradecimiento muy especial merece la comprensin, paciencia y el nimo recibidos de
nuestras familias y amigos a todos ellos, muchas gracias.

Andr Antoine Autrn Orellana

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.

1 Datos demogrficos: es toda informacin de la que se dispone


2 Patologas: Conjunto de sntomas de una enfermedad
11 | P g i n a

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

obtener imgenes del cuerpo humano con fines clnicos o cientficos.


13 | P g i n a

con el fin de aumentar el porcentaje de xito y la precisin al momento de sugerir un posible


diagnstico.
El sistema pondr a disposicin del mdico un avanzado sistema de filtros de pacientes,
capaces de permitir bsquedas por: patologa, edad, fecha atencin, nombre, tratamiento,
etc., con el fin de poder optimizar su labor como profesional, en la medida en que se facilita
el trabajo de bsqueda de antecedentes, siendo con ello, ms eficaz.
La informacin ingresada al sistema permitir saber al mdico cuales son las enfermedades
con mayor tendencia y los rangos de edades donde stas suceden, lo que apoyar los
posteriores estudios de la materia.
Adems de lo anterior, el sistema ser capaz de mostrar alertas, con el fin de avisar que un
paciente debe realizarse un determinado examen y la periodicidad de ste, permitiendo al
mdico, a travs de reportes, agilizar la planificacin y reserva de horas de atencin
enfocadas en el seguimiento y control de pacientes, considerando que un factor de xito
determinante en la recuperacin o en la prevencin de cualquier tipo de enfermedad es el
tiempo.

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

1. Almacenar y gestionar la informacin existente, relacionada a parmetros e


indicadores de riesgo de patologas.
ME: Disponer de los antecedentes e informes cientficos existentes.
2. Disear e implementar estructuras de datos apropiadas que permitan almacenar y
gestionar las fichas clnicas.
ME: Disponer de los antecedentes e historiales clnicos actualizados de los pacientes.
3. Disear y ejecutar los algoritmos1 necesarios para generar reportes que permitan
identificar la necesidad de realizar determinados exmenes preventivos.
ME: Actualizar oportunamente los antecedentes clnicos de los pacientes

1 Algoritmos: Conjunto ordenado y finito de operaciones que permite hallar la solucin de un


problema
15 | P g i n a

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

Figura 1: Ingreso Peticin de Horas

Descripcin: La Secretaria ingresa una nueva peticin de horas al sistema

17 | P g i n a

Figura 2: Listado de Horas

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:

Oncologa urolgica: La urologa oncolgica, oncologa urolgica o uro-oncologa es


la especialidad mdica que estudia los tumores benignos y malignos, pero con
especial atencin a los malignos, esto es, al cncer, centrada en el aparato

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

Endourologa: Son el conjunto de maniobras diagnsticas o teraputicas,


percutneas, endoscpicas o imagenolgicas, realizadas en la luz de las vas

urinarias. Algunos autores la definen como ciruga mnimamente invasiva


Urologa peditrica o infantil: La urologa peditrica es aquella subespecialidad
mdica dedicada a estudiar las enfermedades del genital de los nios y bebs, siendo
necesario para esto el haber realizado al menos 1 a 2 aos ms, despus de una

especializacin en Ciruga Pediatra o en Urologa


Urologa geritrica: La urologa geritrica es aquella subespecialidad mdica

dedicada a estudiar las enfermedades del sistema reproductor de los ancianos


Urolitiasis: La urologa de la litiasis o urolitiasis es aquella subespecialidad que se
encarga del estudio, diagnstico y tratamiento de las enfermedades que se
manifiestan con formacin de clculos urinarios (piedras o concreciones). Los clculos
pueden formarse en cualquier punto de la va urinaria, desde las cavidades del rin a

1 Glndulas suprarrenales: adrenal situada en el hombre en la parte superior de los riones.


19 | P g i n a

la uretra, conformando lo que se ha llamado "mal de piedra". Las localizaciones ms


comunes son rin, urter y vejiga
De las especialidades existentes, Uromed se especializa en las siguientes reas:

Urologa Femenina: Es una rama de la urologa que diagnostica y trata patologas

urinarias femeninas tales como: infecciones urinarias (cistitis) e incontinencia de orina


Disfunciones Sexuales: Uromed cuenta con un departamento de disfuncin sexual
que atiende a pacientes con patologa erctil, eyaculacin precoz, trastornos de la

libido. Tratamiento de pareja con apoyo psicolgico


Urologa General: La urologa es la especialidad mdica que evala y trata las
enfermedades relacionadas con los riones, urteres, vejiga, prstata, genitales

masculinos y enfermedades de transmisin sexual


Oncologa Urolgica: Consiste en el diagnstico y tratamiento de los cnceres de la

va urinaria, prstata, riones, vejiga, testculos y genitales masculinos


Urologa Peditrica: Atiende a nios y nias hasta los 15 aos, que presentan
problemas urolgicos infantiles tales como: infecciones urinarias, patologa genital,

incontinencia de orina (enuresis) y malformaciones congnitas de la va urinaria


Infertilidad Masculina: Evala las alteraciones reproductivas en los hombres. Cuenta

con un laboratorio especializado.


Clculos Urinarios: Tiene las ms modernas opciones de tratamiento de los clculos
urinarios. Ondas de choque que permiten eliminar los clculos sin la necesidad de
ciruga convencional.

20 | P g i n a

Adems Uromed realiza los siguientes exmenes en sus sucursales:

Ecotomografa: La unidad de ecotomografa cuenta con un equipo de ltima

generacin y mdicos con gran experiencia en las enfermedades urolgicas


Cistoscopia: Examen que permite la visualizacin directa de la vejiga tanto en la
mujer como en el hombre. En el hombre tambin permite examinar la uretra y la

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:

Figura 3: Men Ofimedic

Ofimedic es un sistema que permite la gestin de la informacin administrativa y mdica,


ste permite gestionar los pacientes y acceder a informacin.

22 | P g i n a

Figura 4 : Historias Mdicas Ofimedic

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

Si bien Ofimedic da solucin a muchos problemas administrativos, no es una herramienta


especfica para el rea de urologa ni para ningn rea en especial, por lo cual, si una clnica
desea adquirir este sistema deber adaptarse al producto, en cambio, como el sistema de
alertas tempranas1 est creado a medida, es este quien resolver las necesidades del
usuario, lo que implicar un menor tiempo de adaptacin y capacitacin de los usuarios,
siendo de esta forma una mejor solucin para cualquier clnica.

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. PARADIGMAS DE DESARROLLO DE SOFTWARE


Uno de los problemas ms frecuentes con los que se encuentran los ingenieros de software y
programadores al momento de desarrollar una nueva aplicacin, es la escasa informacin de
marcos tericos comunes.
Es por esta razn que en el presente captulo se explican las distintas metodologas 1 que
pueden ser utilizadas por los programadores para mejorar la calidad del producto desde el
punto de vista tcnico.
Cabe destacar que a lo largo de la historia los lenguajes de programacin han ido en paralelo
con el desarrollo de los paradigmas de programacin. Estos ltimos representan
principalmente los distintos enfoques para el desarrollo de soluciones, lo que implica que
afecten directamente el proceso completo de desarrollo de software.

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

Es muy simple de implementar

La cantidad de recursos necesarios para implementar este modelo es mnimo

La documentacin se produce en cada etapa del desarrollo del modelo de cascada,


esto hace que la comprensin del producto a disear sea ms sencilla

Despus de cada etapa importante del desarrollo del software, se realizan pruebas
para comprobar el correcto funcionamiento del mdulo desarrollado

Desventajas

Si la fase de diseo no ha sido bien implementada, es altamente probable que las


cosas pueden ir mal en la fase de implementacin
26 | P g i n a

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

9.1.2 Modelo Incremental


Como se vio anteriormente, el modelo de diseo en Cascada requiere que los clientes de un
proyecto tengan un conjunto de requerimientos claros antes de que se inicie el diseo, junto
con esto el ingeniero debe cumplir con estrategias particulares de diseo antes de la
implementacin. Es importante recordar que cuando se producen cambios en los
requerimientos es necesario volver a hacer el trabajo de obtencin de requerimientos,
anlisis, diseo e implementacin.
En contraste al modelo en cascada se tiene el modelo de desarrollo evolutivo, el cual permite
que las decisiones de diseo se retrasen, pero origina un software que puede estar
dbilmente estructurado y difcil de comprender y mantener.
El modelo incremental fue propuesto por Harlan Mills en el ao 1980 y tiene un enfoque
intermedio que combina las ventajas de ambos modelos. En un proyecto que se utiliza el
modelo incremental el cliente debe identificar los servicios que proporcionar el sistema,
ordenndolos por prioridad (de ms a menos importante). Entonces se definen varios
incrementos (entregas) en donde cada uno de estos proporciona una sub-funcionalidad del
sistema a desarrollar.
Figura 7: Modelo Incremental

27 | P g i n a

La asignacin de servicios a los incrementos depende de la prioridad del servicio respecto de


los que tienen una prioridad ms alta y que fueron entregados anteriormente.
Una vez que los incrementos del sistema han sido identificados, los requerimientos para los
servicios que se van a entregar en el primer incremento se definen en detalle y luego ste se
desarrolla.
Durante la etapa de desarrollo se puede llevar a cabo un anlisis adicional de
requerimientos, para los incrementos posteriores, pero no se aceptan cambios en los
requerimientos que se tienen en el incremento actual.
Una vez que un incremento se completa y entrega, los clientes pueden ponerlo en marcha.
Lo que significa que tienen una entrega temprana de una parte de la funcionalidad del
sistema. Los usuarios pueden experimentar con el sistema, lo cual les ayuda a tener una
visin clara de los requerimientos para las entregas posteriores y para las ltimas versiones
del incremento actual. A medida que se van completando los nuevos incrementos, se
integran en los ya existentes de modo que la funcionalidad del sistema va mejorando
paulatinamente con cada incremento entregado. Los servicios comunes se pueden
implementar al inicio del proceso o de forma incremental, tan pronto como requeridos por un
incremento.
Ventajas

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

pueda utilizar inmediatamente


Los clientes pueden utilizar los incrementos iniciales como prototipos y obtener

experiencia sobre los requerimientos de los incrementos posteriores del sistema


Existe un bajo riesgo de un fallo total del proyecto. Aunque se pueden encontrar
problemas en algunos incrementos, lo ideal es que el sistema se entregue de forma

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

Figura 8: Modelo Espiral

El Modelo en Espiral, proporciona la capacidad de entregar versiones incrementales


rpidamente. En las primeras iteraciones de este modelo se podra hablar de un prototipo,
para luego en las ltimas iteraciones, las versiones sean cada vez ms completas del
sistema. Algunas caractersticas de este modelo son:

Puede combinarse con otros modelos de proceso de desarrollo


Es bueno al momento de desarrollar grandes sistemas
Para hacer el anlisis de riesgos se necesita la participacin de personal calificado
No existe un numero definido de iteraciones

El Modelo en Espiral se divide en 4 regiones llamadas marco de trabajo (regiones de tareas),


cada una de estas regiones estn compuestas por un conjunto de tarea, estas se adaptan a
las distintas necesidades de los proyectos.

30 | P g i n a

Ventajas

Luego de cada evolucin tanto desarrollador como cliente pueden responder de mejor

manera a los riesgos


Este modelo permite al desarrollador aplicar una construccin de prototipos en

cualquiera de sus etapas de evolucin


El modelo en espiral demanda una consideracin directa de los riesgos tcnicos en
todas las etapas del proyecto y si se aplica adecuadamente debe reducir los riesgos
antes de que se conviertan en problemas

Desventajas

Dificultad de confiabilidad por parte de los clientes

No es aconsejable su uso en pequeos sistemas (debido a su complejidad)

Genera mucho tiempo en el desarrollo del sistema

Modelo costoso

Requiere experiencia en la identificacin de riesgos

9.1.4 Modelo de Prototipos


El modelo de prototipos, creado por McCracken y Jackson en 1982, tiene la particularidad de
hacer de que todo el sistema o solamente algunas de sus funciones se construyan de
manera rpida, con el fin de entender con facilidad y aclararlas de manera tal que tanto el
cliente, usuario y el desarrollador estn conformes con lo que se va a desarrollar, as como
tambin con la solucin que se propone, de esta forma se minimiza el riesgo y la
incertidumbre durante el desarrollo. Este modelo se encarga de presentar al cliente distintos
tipos de diseos, para que el cliente experimente con ellos, y as ir descartndolos a medida
que se van aadiendo nuevas especificaciones, es ideal para medir el alcance de un
sistema, pero sin asegurar su uso real.
Este modelo se debe aplicar cuando un cliente define un conjunto de objetivos generales
para un sistema a desarrollar, pero no detalla cada uno de estos, es decir cuando el cliente
no est seguro de la eficacia de un algoritmo, de la adaptabilidad del sistema o de la forma
en que interacta el hombre y la mquina. Este modelo se encarga principalmente de ayudar

31 | P g i n a

tanto al ingeniero de software como al cliente a entender de mejor manera el resultado de la


construccin del sistema.
Etapas para la elaboracin del Modelo de Prototipos: [Figura13]
1.
2.
3.
4.
5.

Plan rpido
Modelado, diseo rpido
Construccin del Prototipo
Desarrollo, entrega y retroalimentacin
Comunicacin

Figura 9: Modelo de Construccin de Prototipos

Ventajas

Permiten el desarrollo de un sistema a partir de requerimientos poco claros o


cambiantes. Esto ocurre con cierta frecuencia en muchos proyectos de software

Como informacin complementaria a los requerimientos constituyen un gran apoyo a


las estimaciones de esfuerzo de todas las reas, incluyendo proveedores

Son ms fciles de abordar con los usuarios finales

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

9.1.5 Modelo de Proceso Unificado de Desarrollo


El Proceso Unificado de Desarrollo de Software fue publicado en 1999 por Ivar Jacobson,
Grady Booch y James Rumbaugh. RUP1 es un proceso de software genrico que puede ser
utilizado para una gran cantidad de tipos de sistemas de software, para diferentes reas de
aplicacin, diferentes tipos de organizaciones, diferentes niveles de competencia y diferentes
tamaos de proyectos.
Provee un enfoque disciplinado en la asignacin de tareas y responsabilidades dentro de una
organizacin de desarrollo. Su meta es asegurar la produccin de software de muy alta
calidad que satisfaga las necesidades de los usuarios finales, dentro de un calendario y
presupuesto predecible.
Este modelo es dirigido por casos de uso ya que es una metodologa que tiene como meta
conocer todos los requerimientos del usuario de manera clara.

Figura 10: Modelo de Proceso Unificado

1RUP: Modelo de procesos Unificados de Desarrollo


33 | P g i n a

34 | P g i n a

Ventajas

Est basada totalmente en mejoras prcticas de la metodologa

Reduce riesgos del proyecto

Incorpora fielmente el objetivo de calidad

Integra desarrollo con mantenimiento

Desventajas

Pretende prever y tener todo el control de antemano

Modelo genera trabajo adicional

Genera muchos costos

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:

No se conoce de antemano los detalles de los requerimientos, ya que el cliente no es


capaz de especificarlos al comienzo del proyecto, principalmente porque no existe una
herramienta de referencia. Por otra parte, no es posible asumir que no existirn cambios
significativos en los mismos a lo largo del ciclo de vida del desarrollo

1 Metodologas giles: Son mtodos de ingeniera del software basados en el desarrollo


iterativo e incremental.
2 Demo: Parte ms pequea del sistema total.
36 | P g i n a

La necesidad de contar con el cliente participando durante todo el proceso de desarrollo,


por lo cual es fundamental enfocarse en la simplicidad y agilidad, a fin de entregar
frecuentemente piezas de software de calidad que cumpla las expectativas

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.

Figura 11: Diagrama Metodologa XP

Si bien el ciclo de vida de un proyecto XP es muy dinmico, se puede separar en fases:


9.2.1 Fase de exploracin
Es la fase en la que se define el alcance general del proyecto. En esta fase, el cliente define
lo que necesita mediante la redaccin de sencillas historias de usuarios. Los
programadores estiman los tiempos de desarrollo en base a esta informacin. Debe quedar
claro que las estimaciones realizadas en esta fase son primarias, y podran variar cuando se
analicen ms en detalle en cada iteracin.

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

debe poseer ciertas

caractersticas. Una de ellas es que debe haber comprobado su efectividad resolviendo


problemas similares en ocasiones anteriores. Otra es que debe ser reusable, lo que significa
que es aplicable a diferentes problemas de diseo en distintas circunstancias.
A medida que los patrones se descubren en todo nuevo proyecto, se puede reutilizar la
plantilla bsica del patrn desde modelos previos con los nombres de las variables
apropiadas modificados para el proyecto en curso.

10.1 MODELO VISTA CONTROLADOR


MVC2 es un patrn de diseo de software que separa los datos de una aplicacin, la interfaz
de usuario, y la lgica de control en tres componentes distintos. Se ve frecuentemente en
aplicaciones web, donde la vista es la pgina HTML y el cdigo que provee de datos
dinmicos a la pgina. El modelo es el Sistema de Gestin de Base de Datos y la Lgica de
negocio, y el controlador es el responsable de recibir los eventos de entrada desde la vista.
MVC se divide en 3 partes que son:

Modelo: Es la representacin especfica de la informacin con la cual el sistema


opera. En resumen, el modelo se limita a lo relativo de la vista y su controlador

1 Parametrizar: accin de fijar parmetros


2 MVC = Modelo Vista Controlador.
39 | P g i n a

facilitando las presentaciones visuales complejas. El sistema tambin puede operar


con ms datos no relativos a la presentacin, haciendo uso integrado de otras lgicas

de negocio y de datos afines con el sistema modelado.


Vista: Presenta el modelo en un formato adecuado para interactuar, usualmente la

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.

10.2 DATA ACCESS OBJECT


En el desarrollo del proyecto se utilizar el patrn DAO 1, el cual es una solucin al problema
diferencial entre un programa orientado a objetos y una base de datos relacional,
implementando nicamente una interfaz de programacin.
Este patrn se utiliza para abstraer y encapsular 2 los accesos, gestionar las conexiones a la
base de datos y obtener los datos almacenados.

1 DAO: Data AccesObject


2 Encapsular: ocultamiento del estado, es decir, de los datos miembros de un objeto de
manera que slo se pueda cambiar mediante las operaciones definidas para ese objeto.
40 | P g i n a

Figura 12: Patrn de Diseo DAO

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 LENGUAJE UNIFICADO DE MODELADO (UML)


El Lenguaje de Modelamiento Unificado (UML Unified Modeling Language) es un lenguaje
grfico para visualizar, especificar y documentar cada una de las partes que comprende el
desarrollo de software. UML entrega una forma de modelar cosas conceptuales como lo son
procesos de negocio y funciones de sistema, adems de cosas concretas como lo son
escribir clases en un lenguaje determinado, esquemas de base de datos y componentes de
software reusables.

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:

Figura 13: 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:

Figura 14: 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

Caso de Uso: Permite identificar el nombre de la accin que se est realizando en el


caso de uso.

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

1) El cliente se comunica con la oficina


de ventas, e informa su nmero de
cliente
2) El sistema obtiene la informacin
bsica sobre el cliente

2.1) Si no est registrado, se le informa


que debe registrarse en la oficina de
clientes

3) Se repite el paso 2) hasta que el


cliente no informa ms productos

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

11.2 DIAGRAMA DE ACTIVIDAD


El diagrama de actividad representa el comportamiento interno de una operacin o caso de
uso, bajo la forma de un desarrollo por etapas, agrupadas secuencialmente.
El propsito del diagrama de actividades es:

Modelar el flujo de tareas.


Modelar las operaciones.

Elemento de un diagrama de actividades

Transicin
Estado de accin
Nodos de decisin
Nodos de inicio y fin
Figura 15: Objetos Diagrama de actividad

11.3 MODELO DE CLASES


Un diagrama de clases sirve para visualizar las relaciones entre las clases que involucran el
sistema, las cuales pueden ser asociativas, de herencia, de uso.
45 | P g i n a

Un diagrama de clases est compuesto por los siguientes elementos:


Clase
Es la unidad bsica que encapsula toda la informacin de un Objeto (un objeto es una
instancia de una clase). A travs de ella podemos modelar el entorno en estudio (una Casa,
un Auto, una Cuenta Corriente, etc.).
En UML, una clase es representada por un rectngulo que posee tres divisiones:
Figura 16: Ejemplo de Clase

En donde:

Superior: Contiene el nombre de la Clase


Intermedio: Contiene los atributos (o variables de instancia) que caracterizan a la

Clase (pueden ser prvate, protected o public).


Inferior: Contiene los mtodos u operaciones, los cuales son la forma como interacta
el objeto con su entorno (dependiendo de la visibilidad: prvate, protected o public).

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

Figura 17: Ejemplo de Clase 2

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.

Relaciones entre Clases


Una vez definido el concepto de Clase, es necesario explicar cmo se pueden interrelacionar
dos o ms clases.
Antes es necesario explicar el concepto de cardinalidad 1 de relaciones: En UML, la
cardinalidad de las relaciones indica el grado y nivel de dependencia, se anotan en cada
extremo de la relacin y stas pueden ser:

uno o muchos: 1..* (1..n)


0 o muchos: 0..* (0..n)

nmero fijo: m (m denota el nmero).

1 Cardinalidad: indica el nmero o cantidad de elementos de un conjunto, sea esta cantidad


finita o infinita
48 | P g i n a

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:

Figura 18: Objetos Relacin de Clases

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.

Figura 19: Objetos Herencia de Clases

49 | P g i n a

12 DIAGRAMA ENTIDAD RELACIN DE BASE DE DATOS


Un diagrama o modelo entidad relacin, es una herramienta que permite representar las
entidades relevantes de un sistema de informacin as como sus interrelaciones1 y
propiedades.
El modelo de datos entidad relacin est basado en una percepcin del mundo real que
consta de una coleccin de objetos bsicos, llamados entidades, y de relaciones entre esos
objetos.
Entidad
Representa una cosa u "objeto" del mundo real con existencia independiente, es decir, se
diferencia unvocamente de otro objeto o cosa, incluso siendo del mismo tipo, o una misma
entidad.
Ejemplos:

Una persona. (Se diferencia de cualquier otra persona, incluso siendo gemelos).
Un automvil. (Aunque sean de la misma marca, el mismo modelo,..., tendrn

atributos diferentes, por ejemplo, el nmero de chasis).


Una casa (Aunque sea exactamente igual a otra, an se diferenciar en su direccin).

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:

(1, Sofa, 38 aos, 2)


(2, Josefa, 19 aos, 5)
(3, Carlos, 20 aos, 2)

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.

Figura 20: Ejemplo de una relacin segn notacin Barker

La manera de leer el anterior diagrama es la siguiente:

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

Cabe destacar que la notacin de Barker se ha malentendido en cuanto a la interpretacin de


la cardinalidad y opcionalidad. La interpretacin correcta es la mostrada anteriormente; esto
significa que en una notacin de cardinalidad mnima y mxima para una entidad la
opcionalidad se interpreta al contrario como se muestra a continuacin:

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

debe interpretarse como (1 : 1)


Cada instancia de la entidad2 PUEDE (0) estar asociada con UNA O MS (n)
instancias de la entidad1. Esto significa que la cardinalidad explcita de la entidad1
debe interpretarse como (0 : n)
52 | P g i n a

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.

13.2 DIFICULTADES PARA ABORDAR EL TEMA


Una limitacin para el proyecto, es que los clientes de Uromed no acepten que su
informacin personal est en un sistema informtico, lo cual complicara la situacin, ya que
se tendra que trabajar en base a supuestos, lo que claramente no permitir ver resultados y
los aportes del sistema hasta que est implementado.
Una segunda limitacin es el rechazo o resistencia al cambio por parte de los usuarios
(mdicos) del nuevo sistema, ya que tendrn que aprender a utilizar una nueva herramienta y
que, a pesar de que ser un beneficio para ellos en un futuro, no se den el tiempo necesario
para asimilarla.

13.3 FACTIBILIDAD TCNICA


Para el desarrollo del sistema se realiz una evaluacin de los conocimientos de
programacin de los integrantes del grupo y una evaluacin tecnolgica de las herramientas
disponibles, este estudio tuvo como fin obtener informacin de los componentes con los que
se contar al momento de desarrollar el proyecto.
De acuerdo a las tecnologas que son necesarias para el desarrollo en cuanto a hardware, se
debe contar con un servidor que posea los siguientes requerimientos mnimos:

Windows Server 2003 o superior


Internet Information Services 6.0 o superior
54 | P g i n a

Soporte Microsoft .Net Framework 2.0 o superior


Soporte Microsoft SQL Server 2005 o superior
Alta velocidad de transferencia de informacin
Espacio mnimo de 5gb de disco duro

En cuanto a computadores, los mdicos debern contar con acceso a internet.


De acuerdo la informacin obtenida, se lleg a la conclusin de que la clnica no deber
incurrir en gastos por equipos personales para los mdicos, ya que se cuenta con este
recurso. Por otra parte se contrat un hosting 1(ILIHOST) de prueba, con el cual se realizarn
todas las evaluaciones necesarias para la puesta en marcha del sistema.

13.4 FACTIBILIDAD ECONMICA


Para poder calcular la factibilidad econmica del presente proyecto se utilizar el mtodo de
valor actual neto (VAN), el cual permitir determinar la rentabilidad del proyecto.
La frmula que se utilizar para calcular el VAN ser:

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

Si VAN > 0 significa que la rentabilidad es buena (ganancias mayores a la inversin).


Si VAN < 0 significa que las ganancias son menores a inversin.
Si VAN = 0 no existe ni perdida ni ganancia.
Se sabe que para el desarrollo del proyecto se necesitar invertir en un servidor, un hosting y
un dominio en NIC lo que implica un costo de alrededor de $743 mil (pesos chilenos), pero
dado que Uromed ya cuenta con un servidor, solo se necesitar de $93.990 mil (pesos
chilenos).
Para la implementacin del sistema, la clnica ser la encargada de asumir los costos tanto
de hosting como dominio. Los encargados de la contratacin de los servicios de hosting y
dominio sern los mismos desarrolladores del sistema, por lo que dentro de sus labores
estar mantener un buen contacto con la empresa que proporcionara est servicio en caso
de problemas o alguna cada.
Para efectos de clculo, se estima que la vida til ser de unos 6 aos, por otra parte
Uromed se ahorrar por concepto de impresin de documentos, hojas, tinta y bodegas para
almacenar sus documentos, aproximadamente 140 mil pesos al ao, se estima un
rendimiento mnimo del sistema de un 7% (rentabilidad nominal anual del promedio
ponderado de inversiones en renta fija).
VAN =93.000+

140.000 140.000 140.000 140.000 140.000 140.000


+
+
+
+
+
( 1+0.07 ) ( 1+0.07 )2 ( 1+0.07 )3 ( 1+ 0.07 )4 (1+ 0.07 )5 ( 1+0.07 )6

VAN = 574.316
Dado que VAN > 0 resulta rentable realizar el proyecto.

13.5 FACTIBILIDAD HUMANA U OPERACIONAL


Dado que el personal del proyecto est capacitado para llevar a cabo el trabajo no existen
problemas de este tipo, adems se cuenta con el respaldo de la clnica, lo que implica que
Uromed se muestra muy interesado por el sistema, es decir los usuarios finales no estn
3 Tasa Interna de retorno: rentabilidad del proyecto
56 | P g i n a

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 19.628 PROTECCION DE LA VIDA PRIVADA, que habla sobre el tratamiento de


los datos de carcter personal en registros o bancos de datos por organismos pblicos
o por particulares. sta indica que toda persona puede efectuar el tratamiento de
datos personales, siempre que se haga de manera concordante con esta ley y para
finalidades permitidas por el ordenamiento jurdico. En todo caso deber respetar el
pleno ejercicio de los derechos fundamentales de los titulares de los datos y de las
facultades que esta ley les reconoce

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.

PROCESO DE DESARROLLO DE SOFTWARE


14.1 FASE DE EXPLORACIN

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?

Mdico Orellana: Miren, a rasgos generales, el sistema debe considerar los


tems tipos de ciruga e imgenes, me refiero a radiografas. Antes del
diagnstico de los pacientes, nos interesan los antecedentes y la
sintomatologa, tambin es importante que el sistema considere los
medicamentos que se le administran a los pacientes, por otra parte es
necesario considerar que este sistema no solo ser utilizado por mdicos,
sino que tambin por secretarias, qumicos farmacuticos entre otros, los
cuales son encargadas de buscar informacin importante de los pacientes,
o informar de los medicamentos existentes en el sistema.

14.1.2 Historia de Usuario 2: Especificaciones del sistema


En la segunda reunin con el mdico se profundizan algunos temas a considerar en el
software, detallando sntomas, patologas, tratamientos previos, enfermedades y sus
tipificaciones
58 | P g i n a

59 | P g i n a

Ingenieros: En la reunin anterior alcanzamos a revisar los antecedentes


generales que debemos conocer para iniciar el desarrollo del software

Mdico Orellana: Para que se hagan una idea, la medicina consta de lo


siguiente: cuando t tienes un paciente tienes una anamnesis prxima, que
corresponde a los sntomas, es decir, lo que le duele o aqueja, y una
anamnesis remota, relacionada a datos previos, es decir, si fuma o tiene
alguna enfermedad como hipertensin, diabetes u otra.
Se realizan exmenes fsicos para determinar, por ejemplo, si el paciente
tiene fiebre o tiene el vaso grande.
En base a la anamnesis prxima y la remota, se hace un diagnstico del
paciente y se define el tratamiento, que puede ser mdico o querbico.
Luego, dependiendo de la patologa, se controla la evolucin del paciente
para ver cmo est el tratamiento en el tiempo.
Entonces se debe tener pantallas o planillas que incluyan datos
demogrficos, anamnesis prxima, anamnesis remota, examen fsico,
diagnstico, tratamiento, evolucin
Se debe tener sub-tems, me refiero a cmo se vean los datos en el
sistema, por ejemplo, se necesita una planilla en la cual se pueda
registrar:
tabaco (fuma)

si [ ] no [x]

cuantos fuma al da <5 [ ]

>5[ ]

1 cajetilla[x] y as

si tiene alguna operacin y alguna descripcin de esta


antecedentes familiares de alguna patologa, por ejemplo si el papa
sufri de cncer, etc.
Ahora esto es sper a rasgos generales, para ver el detalle debo
mostrarles fichas clnicas para poder ver el detalle de cmo se registran los
datos actualmente en la clnica, ya que es mucho ms complejo de lo que
acabo de decirles.

60 | P g i n a

14.1.3 Historia de Usuario 3: Fichas mdicas


En esta reunin se abordaron temas relacionados al acceso oportuno y eficaz de la
informacin de pacientes, a travs de buscadores y filtros, considerando diversas
caractersticas.

Ingenieros: Sr. Orellana, nos ha explicado conceptos relacionados al


tratamiento de pacientes, pero qu puede decirnos respecto a las
necesidades relacionadas al acceso de la informacin?

Mdico Orellana: Por supuesto, se requiere filtrar la informacin, por


ejemplo, en ocasiones se necesita identificar todas las mujeres que sufren
de incontinencia urinaria, cncer, etc.

Del mismo modo, se necesita

identificar a los pacientes por enfermedades, es decir, quienes tienen


cncer renal, cuntos son hombres, cuntas son mujeres, cuntos de
estos cnceres se operaron, y as buscar por distintos motivos y poder
tener la informacin clara y con rapidez. Actualmente tenemos fichas y
para buscar cada tem, por ejemplo cada persona con cncer, es tedioso y

requiere de un da entero de la secretaria


Ingenieros: Con esta informacin tenemos una visin general de lo que
requiere la Clnica y podremos identificar aquellos aspectos clave que
deben ser abordados en detalle para disear un software de calidad

14.1.4 Historia de Usuario 4: Alertas tempranas


En esta reunin se discuti acerca de la necesidad de un sistema de alertas tempranas, que
permita al mdico conocer con rapidez aquellas enfermedades que se presentan con mayor
frecuencia en los pacientes. El objetivo es identificar, a travs de informacin estadstica,
aquellos factores comunes que se presentan o influyen directamente en una enfermedad.

Ingenieros: Sr. Orellana, considerando informacin existente, qu tan


factible es considerar patrones que permitan establecer acciones
preventivas,

travs

alertas

tempranas,

fin

de

diagnosticar

tempranamente potenciales enfermedades?

Mdico Orellana: Sera un gran aporte contar con un sistema de alertas


61 | P g i n a

que identifique tendencias en las enfermedades que se presentan en los


pacientes, en base a su edad, diagnostico, exmenes, etc. Esto ayudara a
realizar investigaciones que tengan que ver con las enfermedades que

estn afectando a los pacientes


Ingenieros: Se entiende, pero para realizar esto se necesitan parmetros
que indiquen cules son los ndice normal de padecimiento de las

enfermedades que ustedes tratan


Medico Orellana: Si miren, yo he realizado algunas investigaciones sobre
el tema, por ejemplo siempre se da que los hombres mayores a 40 aos
padezcan o son propensos a tener cncer de prstata, por lo cual es
recomendable que a esa edad se realicen un chequeo mdico, esta es una
de las razones por las cuales creo que es importante investigar sobre el
tema, ya que nos puede ayudar a saber que otros factores son influyentes

en esta u otras enfermedades


Ingenieros: Por lo mismo necesitamos el acceso a la informacin que le

solicitamos anteriormente, sobre los factores influyentes y rangos normales


Medico Orellana: Est bien, documentar esa informacin para poder
hacrselas llegar

14.1.5 Historia de Usuario 5: Interfaz del programa y seguridad


En la quinta reunin con el mdico, se convers sobre la interfaz y la distribucin de la
informacin, en bsqueda de un software amigable al usuario e intuitivo, facilitando de esta
manera la disposicin de los funcionarios a utilizar el software.
Otro factor considerado como fundamental es la seguridad y la capacidad de auditora del
software. Cada mdico debe contar con una cuenta de usuario y se debe registrar todos
cambios que se realicen a la informacin almacenada.

62 | P g i n a

Ingenieros: Sr. Orellana cuntenos cules son los requerimientos


relacionados a la interfaz de usuario del software

Mdico Orellana: Principalmente el sistema debe ser intuitivo, porque


entendern que tenemos toda clase de usuarios y algunos doctores no son
muy amigos con la tecnologa, es por esto que el sistema debe ser muy
visual, quizs con colores o letras y botones que ellos puedan distinguir

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

horas con los distintos mdicos


Ingenieros: Claro, el sistema ser capaz de reconocer a los distintos
usuarios, de esta forma cualquier cambio quedar registrado.

14.2 FASE DE PLANIFICACIN


Una vez conocidos los requisitos del sistema se procede a identificarlos y dividirlos en dos
categoras principales: funcionales y no-funcionales.
Los requisitos no funcionales son aquellos que describen los aspectos que el sistema debe
tomar y no tienen una relacin directa con la funcionalidad del sistema. Reflejan, por ejemplo,
el tiempo de respuesta que debe tener el sistema, bajo qu condiciones debe funcionar y si
debe tener un sistema de seguridad, entre otros.
Por otra parte, los requisitos funcionales describen la interaccin del sistema con su
ambiente, es decir con los usuarios o sistemas con los que debe relacionarse.
Para representarlos de mejor manera, es necesario realizar un levantamiento de requisitos
que consiste en un listado que posee los elementos que tendr el sistema y su descripcin,
desencadenando el desarrollo de los casos de uso. Los casos de uso son una abstraccin
que describen un conjunto de escenarios posibles dentro de los cuales el usuario se puede
desenvolver.
63 | P g i n a

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

Buscar, agregar, eliminar y editar


Pacientes.

H1

Requisito
Funcional

Buscar, agregar, eliminar y editar


Exmenes e Imagenologa.

H1

Requisito
Funcional

Es necesario poder buscar, agregar


y eliminar Resultados de Examen.

H1

Requisito
Funcional

Buscar, agregar, editar y eliminar


Sntomas.

H1

Requisito
Funcional

Buscar, agregar, editar y eliminar


Secretarias.

H1

Requisito
Funcional

Buscar, agregar, editar y eliminar


Personal(qumicos)

H1

Requisito
Funcional

Buscar, agregar, editar y eliminar


Mdicos.

H1

Requisito
Funcional

Agregar, editar y eliminar


Medicamentos.

H1

Requisito
Funcional

Buscar, agregar, eliminar y editar


Procedimientos.

10

H2

Requisito
Funcional

Agregar, Buscar, editar y eliminar


Diagnsticos.

11

H2

Requisito
Funcional

Buscar, agregar, editar y eliminar


Tratamientos.

12

H2

Requisito
Funcional

Buscar, agregar, editar y eliminar


Tipos de Enfermedades.

13

H2

Requisito
Funcional

Buscar, agregar, editar y eliminar


datos previos del Paciente.

14

H3

Requisito
Funcional

Buscar, agregar, editar y eliminar


Historial Mdico.

15

H4

Requisito
Funcional

Que el sistema alerte anomalas en


los Pacientes

16

H5

Requisito no
Funcional

Interfaz simple

17

H5

Requisito no
Funcional

Seguridad del sistema

65 | P g i n a

18

H5

Requisito no
Funcional

Filtro de informacin de las


Enfermedades

19

H5

Requisito no
Funcional

Filtro de Pacientes

14.3 FASE DE ITERACIONES


En esta fase se analizaran una por una las historias de usuario, identificando los casos de
uso, diagrama de actividad, el modelo de datos conceptual o lgico, los modelos de clases y
el modelo de datos fsico, con el fin de hacer entrega de un prototipo funcional que cumpla
con los requisitos del cliente en cada una de las iteraciones.
14.3.1 Iteracin 1
Anlisis

Caso de Uso Administracin de Categoras de Exmenes

Figura 21: Diagrama Caso de Uso Administracin de Categoras de Exmenes

Tabla 2: Narrativa Caso de Uso Administracin de Categoras de Exmenes

Caso de Uso: Administracin de Categoras de Exmenes (Requisito N2)


Actor: Mdico Administrador
Curso Normal
1) El Mdico Administrador lista las
Categoras de Exmenes

Alternativas

66 | P g i n a

2) El Mdico Administrador agrega una


nueva Categora de Examen

3) El Mdico Administrador elimina una


Categora de Examen

2.1) Si el registro existe se informa del


problema y no se permite completar la
accin
2.2) Si los datos ingresados no son vlidos
o falta informacin se informa del
problema y no se permite completar la
accin
3.1) Si el registro est asociado a un
Examen existente se informa del problema
y no se permite completar la accin

4) El Mdico Administrador edita una


Categora de Examen
5) Se repiten los pasos 2), 3) y 4 hasta
que el Mdico Administrador no desee
realizar ms operaciones

Caso de Uso Administracin de Medicamentos

Figura 22: Diagrama Caso de Uso Administracin de Medicamentos


Tabla 3: Narrativa Caso de Uso Administracin de Medicamentos

Caso de Uso: Administracin de Medicamentos (Requisito N8)


Actor: Qumico Farmacutico
Curso Normal
Alternativas
1) El Qumico Farmacutico lista los
Medicamentos
2) El Qumico Farmacutico agrega un
2.1) Si el registro existe se informa del
nuevo Medicamento
problema y no se permite completar la
accin
2.2) Si los datos ingresados no son vlidos

67 | P g i n a

o falta informacin se informa del


problema y no se permite completar la
accin
3) El Qumico Farmacetico elimina un
Medicamento

3.1) Si el registro est asociado a una


Medicacin existente se informa del
problema y no se permite completar la
accin

4) El Qumico edita un Medicamento


5) Se repiten los pasos 2), 3) y 4) hasta
que el Qumico Farmacutico no desee
realizar ms operaciones

Caso de Uso Administracin de Tipos de Enfermedad

Figura 23: Diagrama Caso de Uso Administracin de Tipos de Enfermedad


Tabla 4: Narrativa Caso de Uso Administracin de Tipos de Enfermedad

Caso de Uso: Administracin de Tipos de Enfermedad (Requisito N12)


Actor: Mdico Administrador
Curso Normal
Alternativas
1) El Mdico Administrador lista los Tipos
de Enfermedad
2) El Mdico Administrador agrega un
2.1) Si el registro existe se informa del
nuevo Tipo de Enfermedad
problema y no se permite completar la
accin
2.2) Si los datos ingresados no son vlidos
o falta informacin se informa del

68 | P g i n a

problema y no se permite completar la


accin
3) El Mdico Administrador elimina un
Tipo de Enfermedad

3.1) Si el registro est asociado a una


Enfermedad existente se informa del
problema y no se permite completar la
accin

4) El Mdico Administrador edita un Tipo


Enfermedad
5) Se repiten los pasos 2), 3) y 4) hasta
que el Mdico Administrador no desee
realizar ms operaciones

Caso de Uso Administracin de Especialidades

Figura 2421: Diagrama Caso de Uso Administracin de Especialidades


Tabla 5: Narrativa Caso de Uso Administracin de Mdicos

Caso de Uso: Administracin de Especialidades (Requisito N7)


Actor: Mdico Administrador
Curso Normal
Alternativas
1) El Mdico Administrador lista las
Especialidades
2) El Mdico Administrador agrega una
2.1) Si el registro existe se informa del
nueva Especialidad
problema y no se permite completar la
accin
2.2) Si los datos ingresados no son vlidos
o falta informacin se informa del
problema y no se permite completar la
accin

69 | P g i n a

3) El Mdico Administrador elimina una


Especialidad

3.1) Si el registro est asociado a un


Mdico existente se informa del problema
y no se permite completar la accin

4) El Mdico Administrador edita una


Especialidad
5) Se repiten los pasos 2) ,3) y 4) hasta
que el Administrador no desee realizar
ms operaciones

70 | P g i n a

Caso de Uso Administracin de Mdicos

Figura 25: Diagrama Caso de Uso Administracin de Mdicos


Tabla 6: Narrativa Caso de Uso Administracin de Mdicos

Caso de Uso: Administracin de Mdicos (Requisito N7)


Actor: Mdico Administrador
Curso Normal
Alternativas
1) El Mdico Administrador lista los
Mdicos
2) El Mdico Administrador agrega un
2.1) Si el registro existe se informa del
nuevo Mdico
problema y no se permite completar la
accin
2.2) Si los datos ingresados no son vlidos
o falta informacin se informa del
problema y no se permite completar la
accin
3) El Mdico Administrador elimina un
3.1) Si el registro est asociado a un
Mdico
Historial Mdico existente se informa del
problema y no se permite completar la
accin
4) El Mdico Administrador edita un
Mdico
5) Se repiten los pasos 2) ,3) y 4) hasta
que el Mdico Administrador no desee
realizar ms operaciones

71 | P g i n a

Caso de Uso Administracin de Pacientes

Figura 2622: Diagrama Caso de Uso Administracin de Pacientes


Tabla 7: Narrativa Caso de Uso Administracin de Pacientes

Caso de Uso: Administracin de Pacientes (Requisito N1, N13 y N19)


Actor: Secretaria
Curso Normal
Alternativas
1) La Secretaria lista los Pacientes
2) La Secretaria agrega un nuevo
2.1) Si el registro existe se informa del
Paciente
problema y no se permite completar la
accin
2.2) Si los datos ingresados no son vlidos
o falta informacin se informa del
problema y no se permite completar la
accin
3) La Secretaria elimina un Paciente
3.1) Si el registro est asociado a un
Historial Mdico existente se informa del
problema y no se permite completar la
accin
4) La Secretaria edita un Paciente
5) Se repiten los pasos 2) ,3) y 4) hasta
que la Secretaria no desee realizar ms
operaciones

72 | P g i n a

Caso de Uso Administracin de Sntomas

Figura 2723: Diagrama Caso de Uso Administracin de Sntomas


Tabla 824: Narrativa Caso de Uso Administracin de Sntomas

Caso de Uso: Administracin de Sntomas (Requisito N4)


Actor: Mdico Administrador
Curso Normal
Alternativas
1) El Mdico Administrador lista los
Sntomas
2) El Mdico Administrador agrega un
2.1) Si el registro existe se informa del
nuevo Sntoma
problema y no se permite completar la
accin
2.2) Si los datos ingresados no son vlidos
o falta informacin se informa del
problema y no se permite completar la
accin
3) El Mdico Administrador elimina un
3.1) Si el registro est asociado a una
Sntoma
Enfermedad y/o Historial Mdico existente
se informa del problema y no se permite
completar la accin
4) El Mdico Administrador edita un
Sntoma
5) Se repiten los pasos 2) ,3) y 4) hasta
que el Mdico Administrador no desee
realizar ms operaciones

73 | P g i n a

Caso de Uso Administracin de Tratamientos

Figura 28: Diagrama Caso de Uso Administracin de Tratamientos


Tabla 925: Narrativa Caso de Uso Administracin de Tratamientos

Caso de Uso: Administracin de Tratamientos (Requisito N11)


Actor: Mdico
Curso Normal
Alternativas
1) El Mdico lista los Tratamientos
2) El Mdico agrega un nuevo
2.1) Si el registro existe se informa del
Tratamiento
problema y no se permite completar la
accin
2.2) Si los datos ingresados no son vlidos
o falta informacin se informa del
problema y no se permite completar la
accin
3) El Mdico elimina un Tratamiento
3.1) Si el registro est asociado a un
Procedimiento existente se informa del
problema y no se permite completar la
accin
4) El Mdico edita un Tratamiento
5) Se repiten los pasos 2) ,3) y 4) hasta
que el Mdico no desee realizar ms
operaciones

74 | P g i n a

Diagrama de Actividad Administracin de Categoras de Exmenes

El siguiente Diagrama de Actividades muestra el flujo de actividades que puede realizar el


mdico para la administracin de Categora Exmenes.

Figura 29: Diagrama de Actividad Administracin de Categoras de Exmenes

75 | P g i n a

Diagrama de Actividad Administracin de Medicamentos

El siguiente Diagrama de Actividades refleja como el Qumico Farmacutico puede


administrar los Medicamentos existentes, ste podr agregar, editar y eliminar, siempre que
se cumplan las restricciones establecidas.

Figura 30: Diagrama de Actividad Administracin de Medicamentos

76 | P g i n a

Diagrama de Actividad Administracin de Tipos de Enfermedades

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

Diagrama de Actividad Administracin de Especialidades

El siguiente Diagrama de Actividades detalla el flujo de actividades relacionado a la


administracin de Especialidades, considerando la posibilidad de agregar nuevas
Especialidades, eliminar y editar Especialidades existentes. Un usuario no puede realizar
estas operaciones a menos que tenga los permisos de Mdico Administrador.
Figura 32: Diagrama de Actividad Administracin de Especialidades

78 | P g i n a

Diagrama de Actividad Administracin de Mdicos

El siguiente Diagrama de Actividades detalla el flujo de actividades relacionado a la


administracin de Mdicos, considerando la posibilidad de agregar nuevos Mdicos, eliminar
y editar Mdicos existentes. Un Mdico no puede realizar estas operaciones a menos que
tenga los permisos de Administrador.

Figura 33: Diagrama de Actividad Administracin de Mdicos

79 | P g i n a

Diagrama de Actividad Administracin de Pacientes

El siguiente Diagrama de Actividades refleja como la Secretaria puede administrar los


Pacientes, pudiendo agregar nuevos Pacientes, editar y eliminar los Pacientes existentes.
Figura 34: Diagrama de Actividad Administracin de Pacientes

80 | P g i n a

Diagrama de Actividad Administracin de Sntomas

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

Diagrama de Actividad Administracin de Tratamientos

El siguiente Diagrama de Actividades refleja como el Mdico administra los Tratamientos,


agregando nuevos registros y editando y/o eliminando segn corresponda.
Figura 36: Diagrama de Actividad Administracin de Tratamientos

82 | P g i n a

Modelo Lgico (Conceptual) de Base de Datos

Figura 37: Modelo Lgico (Conceptual) de Base de Datos Iteracin 1

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

Figura 38: Arquitectura de Hardware

85 | P g i n a

Arquitectura de Software

Tal

como

se

mencion anteriormente, para la construccin de la aplicacin se utilizarn los patrones de


diseo MVC (Model View Controller) y DAO (Data AccesObject).
La distribucin de los componentes de cada patrn es la siguiente:
Figura 39: Arquitectura de Software

86 | P g i n a

87 | P g i n a

Modelo de Clases

Figura 4026: Modelo de Clases Iteracin 1

88 | P g i n a

Modelo Fsico de Base de Datos

Figura 41: Modelo Fsico de Base de Datos Iteracin 1

89 | P g i n a

Diccionario de datos

Nombre Entidad:

Paciente

Descripcin:

Contiene los pacientes de la clnica

Field

Tipo

IdPaciente

Int PK

Cdigo nico del paciente

Previsin

Varchar

''

Nombre de la Previsin

Rut

Varchar

''

Rut del paciente

Nombres

Varchar

''

Nombres del paciente

ApellidoPat

Varchar

''

Apellido Paterno del paciente

ApellidoMat

Varchar

''

Apellido Materno del paciente

Sexo

Varchar

''

Sexo del paciente

FechaNacimiento

DateTime

'01/01/1900'

Fecha de nacimiento del paciente

Nacionalidad

Varchar

''

Nacionalidad del paciente

Domicilio

Varchar

''

Domicilio del paciente

Telfono

Varchar

''

Telfono del paciente

CorreoElectronico

Varchar

''

Mail del paciente

CodigoArea

Varchar

'

Cdigo de rea de la ciudad del


paciente

TelefonoMovil

Int

Celular del paciente

FechaRegistro

DateTime

'01/01/1900'

Fecha de registro del paciente

Usuario

Varchar

''

Usuario de creacin del paciente

Estado

Tinyint

Estados: 1 = Vigente, 2 = No Vigente

Descripcin

Nombre
Entidad:

Sntoma

Descripcin:

Contiene los sntomas

Field

Tipo

IdSintoma

Int PK

Cdigo nico del sntoma

Nombre

Varchar

'

Nombre del sntoma

Descripcin

Varchar

''

Descripcin del sntoma

Descripcin

FechaCreacion DateTime

'01/01/1900' Fecha de creacin del sntoma

Usuario

''

Varchar

Usuario de creacin del sntoma

90 | P g i n a

Estado

Tinyint

Estados: 1 = Vigente, 2 = No Vigente

91 | P g i n a

Nombre Entidad:

Tipo Enfermedad

Descripcin:

Contiene los tipos de enfermedad

Field

Tipo

IdTipoEnfermedad

Int PK

Cdigo nico del tipo de enfermedad

Descripcin

Varchar

''

Descripcin del tipo de enfermedad

Nombre

Varchar

''

Nombre del tipo de enfermedad

Estado

Tinyint

Estados: 1 = Vigente, 2 = No Vigente

Usuario

Varchar

''

Usuario de creacin del tipo de


enfermedad

FechaCreacion

DateTime '01/01/1900'

Nombre Entidad:

Medicamento

Descripcin:

Contiene los medicamentos

Field

Tipo

IdMedicamento

Int PK

Cdigo nico del medicamento

Descripcin

Varchar

''

Descripcin del medicamento

Componentes

Varchar

''

Ingredientes del medicamento

FechaCreacion

DateTime '01/01/1900'

Fecha de creacin del medicamento

Usuario

Varchar

''

Uuario de creacin del medicamento

Estado

Tinyint

Estados: 1 = Vigente, 2 = No Vigente

Nombre Entidad:

Categora Examen

Descripcin:

Contiene las categora de exmenes

Field

Tipo

Descripcin

Fecha de creacin del tipo de


enfermedad

Descripcin

Descripcin

IdCaterogiaExamen Int PK

Cdigo nico de la categora del


examen

Nombre

Varchar

''

Nombre del examen

Descripcin

Varchar

''

Descripcin de la categora del


examen

Estado

Tinyint

Estados: 1 = Vigente, 2 = No Vigente

92 | P g i n a

Usuario

Varchar

''

FechaCreacion

DateTime '01/01/1900'

Usuario de creacin de la categora


Fecha de creacin de la categora

93 | P g i n a

Nombre Entidad:

Tratamiento

Descripcin:

Contiene los tratamientos

Field

Tipo

IdTratamiento

Int PK

Cdigo nico del tratamiento

Nombre

Varchar

''

Nombre del tratamiento

Descripcin

Varchar

''

Descripcin del tratamiento

Usuario

Varchar

''

Usuario de creacin del tratamiento

Estado

Tinyint

Estados: 1 = Vigente, 2 = No Vigente

FechaCreacion

DateTime '01/01/1900' Fecha de creacin del tratamiento

Descripcin

Nombre Entidad:

Especialidad

Descripcin:

Contiene las especialidades de los mdicos

Field

Tipo

IdEspecialidad

Int PK

Cdigo nico de la especialidad

Nombre

Varchar

''

Nombre de la especialidad

Descripcin

Varchar

''

Descripcin de la especialidad

Usuario

Varchar

''

Usuario de creacin de la
especialidad

Estado

Tinyint

Estados: 1 = Vigente, 2 = No Vigente

FechaCreacion

DateTime '01/01/1900'

Fecha de creacin de la especialidad

Descripcin

Nombre Entidad:

Mdico

Descripcin:

Contiene los mdicos de la clnica

Field

Tipo

IdMedico

Int PK

Cdigo nico del mdico

IdEspecialidad

Int FK

Llave fornea de especialidad

Rut

Varchar

''

Rut del mdico

Cargo

Varchar

''

Cargo que posee el Medico en la


Clnica

Nombres

Varchar

''

Nombres del mdico

ApellidoPaterno

Varchar

''

Apellido del mdico

ApellidoMaterno

Varchar

''

Apellido Materno del mdico

Sexo

Varchar

''

Sexo del mdico

Descripcin

94 | P g i n a

FechaNacmiento

DateTime

'01/01/1900'

Fecha de nacimiento del mdico

Nacionalidad

Varchar

''

Nacionalidad del mdico

Domicilio

Varchar

''

Domicilio del mdico

Telfono

Varchar

''

Telfono del mdico

CorreoElectronic
o

Varchar

''

Mail del mdico

CodigoArea

Varchar

'

Cdigo de rea de la ciudad del mdico

FechaRegistro

DateTime

'01/01/1900'

Fecha de creacin del mdico

Estado

Tinyint

Estados: 1 = Vigente, 2= No Vigente

Usuario

Varchar

''

Usuario de creacin del mdico

Password

Varchar

''

Clave de ingreso al sistema del mdico

Construccin
A continuacin se muestra la distribucin de los componentes en el IDE de programacin
Visual Studio 2012.

Figura 42: Modelo y Controlador de Sistema

95 | P g i n a

Mantenedor de Pacientes

En la siguiente imagen se muestra la captura de pantalla del mantenedor de pacientes, la


cual muestra el listado de pacientes que existen en el sistema, tambin se muestran botones
que permite realizar ciertas acciones, tales como acceder al men de ingreso, eliminar y
editar un paciente.

Figura 43: Mantenedor de Pacientes

96 | P g i n a

Ingreso, edicin y eliminacin de Sntomas

Figura 44: Ingreso, edicin y eliminacin de Sntomas

97 | P g i n a

Ingreso, edicin y eliminacin de Mdicos

Figura 45: Ingreso, edicin y eliminacin de Mdicos

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

Caso de Uso Administracin de Medicaciones

Figura 46: Diagrama Caso de Uso Administracin de Medicaciones


Tabla 10: Narrativa Caso de Uso Administracin de Medicaciones

Caso de Uso: Administracin de Medicaciones (Requisito N9)


Actor: Mdico Administrador
Curso Normal
Alternativas
1) El Mdico Administrador lista las
medicaciones
2) El Mdico Administrador agrega una
2.1) Si el registro existe se informa del
nueva medicacin
problema y no se permite completar la
accin.
2.2) Si los datos ingresados no son
vlidos o falta informacin se informa del
problema y no se permite completar la
accin
3) El Mdico Administrador elimina una
3.1) Si el registro est asociado a una
medicacin
Enfermedad y/o Historial Mdico existente
se informa del problema y no se permite
completar la accin
4) El Mdico Administrador edita una
medicacin
5) Se repiten los pasos 2), 3) y 4) hasta
que el Mdico Administrador no desee
realizar ms operaciones

101 | P g i n a

Caso de Uso Administracin de Procedimientos

Figura 47: Diagrama Caso de Uso Administracin de Procedimientos


Tabla 11: Narrativa Caso de Uso Administracin de Procedimientos

Caso de Uso: Administracin de Procedimientos (Requisito N9)


Actor: Mdico Administrador
Curso Normal
Alternativas
1) El Mdico Administrador lista los
Procedimientos
2) El Mdico Administrador agrega un
2.1) Si el registro existe se informa del
nuevo Procedimiento
problema y no se permite completar la
accin
2.2) Si los datos ingresados no son
vlidos o falta informacin se informa del
problema y no se permite completar la
accin
3) El Mdico Administrador elimina un
3.1) Si el registro est asociado a una
Procedimiento
Enfermedad y/o Historial Mdico existente
se informa del problema y no se permite
completar la accin
4) El Mdico Administrador edita un
Procedimiento
5) Se repiten los pasos 2) ,3) y 4) hasta
que el Mdico Administrador no desee
realizar ms operaciones

102 | P g i n a

Caso de Uso Administracin de Exmenes Generales

Figura 48: Diagrama Caso de Uso Administracin de Exmenes Generales


Tabla 12: Narrativa Caso de Uso Administracin de Exmenes Generales

Caso de Uso: Exmenes Generales (Requisito N2)


Actor: Mdico Administrador
Curso Normal
Alternativas
1) El Mdico Administrador lista los
Exmenes Generales
2) El Mdico Administrador agrega un
2.1) Si el registro existe se informa del
nuevo Examen General
problema y no se permite completar la
accin
2.2) Si los datos ingresados no son
vlidos o falta informacin se informa del
problema y no se permite completar la
accin
3) El Mdico Administrador elimina un
3.1) Si el registro est asociado a un
Examen General
Examen Especfico existente se informa
del problema y no se permite completar
la accin
4) El Mdico Administrador edita un
Examen General
5) Se repiten los pasos 2) ,3) y 4) hasta
que el Mdico Administrador no desee
realizar ms operaciones.

103 | P g i n a

Caso de Uso Administracin de Exmenes Especficos

Figura 49: Diagrama Caso de Uso Administracin de Exmenes Especficos


Tabla 13: Narrativa Caso de Uso Administracin de Exmenes Especficos

Caso de Uso: Exmenes Especficos (Requisito N2)


Actor: Mdico Administrador
Curso Normal
Alternativas
1) El Mdico Administrador lista los
Exmenes Especficos
2) El Mdico Administrador agrega un
2.1) Si el registro existe se informa del
nuevo Examen Especfico
problema y no se permite completar la
accin
2.2) Si los datos ingresados no son
vlidos o falta informacin se informa del
problema y no se permite completar la
accin
3) El Mdico Administrador elimina un
3.1) Si el registro est asociado a una
Examen Especfico
Enfermedad existente se informa del
problema y no se permite completar la
accin
4) El Mdico Administrador edita un
Examen Especfico
5) Se repiten los pasos 2) ,3) y 4) hasta
que el Mdico Administrador no desee
realizar ms operaciones.

104 | P g i n a

Diagrama de Actividad Administracin de Medicaciones

En el siguiente Diagrama de Actividad se ve como el Mdico Administrador puede listar,


crear, editar y eliminar Medicaciones.

Figura 50: Diagrama de Actividad Administracin de Medicaciones

105 | P g i n a

Diagrama de Actividad Administracin de Procedimientos

En el siguiente Diagrama de Actividad se ve como el Mdico Administrador puede listar,


crear, editar y eliminar Procedimientos.

Figura 51: Diagrama de Actividad Administracin de Procedimientos.

106 | P g i n a

Diagrama de Actividad Administracin de Exmenes Generales

En el siguiente Diagrama de Actividad se ve como el Mdico Administrador puede listar,


crear, editar y eliminar Exmenes Generales.

Figura 52: Diagrama de Actividad Administracin de Exmenes Generales

107 | P g i n a

Diagrama de Actividad Administracin de Exmenes Especficos

En el siguiente Diagrama de Actividad se ve como el Mdico Administrador puede listar,


crear, editar y eliminar Exmenes Especficos.

Figura 53: Diagrama de Actividad Administracin de Exmenes Especficos

108 | P g i n a

Modelo Lgico (Conceptual) de Base de Datos

Figura 54: Modelo Lgico (Conceptual) de Base de Datos Iteracin 2

Diseo

Modelo de Clases

Figura 55: Modelo de Clases Iteracin 2

109 | P g i n a

Modelo Fsico de Base de Datos

Figura 56: Modelo Fsico de Base de Datos Iteracin 2

110 | P g i n a

Diccionario de Datos

Nombre Entidad:

Examen General

Descripcin:

Contiene los exmenes generales

Field

Tipo

IdExamenGeneral

Int PK

Descripcin
0

Cdigo nico del examen

idCategoriaExamen Int FK

Llave fornea de la categora del


examen

Nombre

Varchar

''

Nombre del examen especifico

Descripcin

Varchar

''

Descripcin del examen

Precio

Money

Precio del examen

FechaCreacion

DateTime '01/01/1900'

Fecha creacin del examen

Usuario

Varchar

''

Usuario que ingreso el examen

Estado

Tinyint

Estados: 1 = Vigente, 2= No Vigente

Nombre Entidad:

Examen Especfico

Descripcin:

Contiene los exmenes especficos recomendados para las


enfermedades

Field

Tipo

IdExamenEspecfic
o

Int PK

Cdigo nico del examen

idExamenGeneral

Int FK

Llave fornea del examen general

Nombre

Varchar

''

Nombre del examen especfico

Descripcin

Varchar

''

Descripcin del examen

ValorMinimoNormal

Integer

Valor mnimo del examen segn su


rango normal.

valorMaximoNormal Integer

Valor mximo del examen segn su


rango normal.

Descripcin

FechaCreacion

DateTime '01/01/1900'

Fecha de creacin del examen

Usuario

Varchar

''

Usuario de creacin del examen

Estado

Tinyint

Estados: 1 = Vigente, 2= No Vigente

Nombre Entidad:

Procedimiento

Descripcin:

Contiene los procedimientos recomendados para las


enfermedades

111 | P g i n a

Field

Tipo

Descripcin

IdProcedimiento

Int PK

Cdigo nico del procedimiento

IdTratamiento

Int FK

Llave fornea del tratamiento

Descripcin

Varchar

''

Descripcin del procedimiento

Precio

Money

Precio del procedimiento

Duracin

Int

Duracin del procedimiento

Dosis

Int

Dosis del procedimiento

Frecuencia

Int

Frecuencia con la que se debe realizar


el procedimiento

Usuario

Varchar

''

Usuario de creacin del procedimiento

Estado

Tinyint

Estados: 1 = Vigente, 2= No Vigente

FechaCreacion

DateTime '01/01/1900' Fecha de creacin del procedimiento

Nombre Entidad: Medicacin


Descripcin:

Contiene las medicaciones recomendadas para las enfermedades

Field

Tipo

IdMedicacion

Int PK

Cdigo nico de la medicacin

IdMedicamento

Int FK

Id de la llave fornea de medicamento

Dosis

Int

Dosis de la medicacin

Descripcin

Varchar

''

Descripcin del medicamento

Precio

Money

Precio del medicamento

Frecuencia

Int

Frecuencia del medicamento

Duracin

Int

Cantidad de das que se debe administrar


el medicamento

Usuario

Varchar

''

Usuario de creacin de la medicacin

Estado

Tinyint

Estados: 1 = Vigente, 2= No Vigente

FechaCreacion

DateTime '01/01/1900' Fecha de creacin de la medicacin

Descripcin

112 | P g i n a

Construccin

Maqueta1 Mantenedor de Exmenes Generales

Figura 57: Maqueta Listado de Exmenes Generales

Figura 58: Maqueta Edicin de Exmenes Generales

1 Maqueta: Prototipo de pantalla, muestra de cmo se ver el sistema al estar terminado.


113 | P g i n a

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

Caso de Uso Administracin de Enfermedades

Figura 59: Diagrama Caso de Uso Administracin de Enfermedades


Tabla 14: Narrativa Caso de Uso Administracin de Enfermedades

Caso de Uso: Administracin de Enfermedades (Requisito N18)


Actor: Mdico Administrador
Curso Normal
Alternativas
1) El Mdico Administrador lista las
Enfermedades
2) El Mdico Administrador agrega una
2.1) Si el registro existe se informa del
nueva Enfermedad
problema y no se permite completar la
accin.
2.2) Si los datos ingresados no son
vlidos o falta informacin se informa del
problema y no se permite completar la
accin.
3) El Mdico Administrador elimina una
3.1) Si el registro est asociado a una
Enfermedad
Medicacin, Procedimiento, Examen
Especfico y/o Diagnstico existente se
informa del problema y no se permite
completar la accin
4) El Mdico Administrador edita una
Enfermedad

115 | P g i n a

5) Se repiten los pasos 2), 3) y 4) hasta


que el Mdico Administrador no desee
realizar ms operaciones

116 | P g i n a

Caso de Uso Administracin de Historiales Mdicos

Figura 60: Diagrama Caso de Uso Administracin de Historiales Mdicos


Tabla 15: Narrativa Caso de Uso Administracin de Historiales Mdicos

Caso de Uso: Administracin de Historiales Mdicos (Requisito N14)


Actor: Mdico Administrador, Mdico, Secretaria
Curso Normal
Alternativas
1) El Mdico Administrador, Mdico y/o
Secretaria listan los Historiales Mdicos
de un determinado Paciente
2) El Mdico agrega un nuevo Historial
2.1) Si el registro existe se informa del
Mdico
problema y no se permite completar la
accin.
2.2) Si los datos ingresados no son
vlidos o falta informacin se informa del
problema y no se permite completar la
accin.
3) El Mdico Administrador elimina un
3.1) Si el registro est asociado a un
Historial Mdico.
Diagnstico y/o Resultado Examen
existente se informa del problema y no se
permite completar la accin
4) El Mdico Administrador edita un
historial.
5) Se repiten los pasos 2), 3) y 4) hasta
que el Mdico Administrador y/o Mdico,
segn corresponda, no deseen realizar

117 | P g i n a

ms operaciones.

118 | P g i n a

Diagrama de Actividad Administracin de Enfermedades

En el siguiente Diagrama de Actividad se ve como al Mdico Administrador puede agregar


una nueva Enfermedad y, por otra parte, listar, editar y eliminar Enfermedades existentes.
Figura 61: Diagrama de Actividad Administracin de Enfermedades

119 | P g i n a

Diagrama Actividad Administracin de Historiales Mdicos

En el siguiente Diagrama de Actividad se ve detalla el flujo de actividades que permite la


administracin de Historiales Mdicos considerando los roles y validaciones descritas en la
narrativa del caso de uso.

Figura 62: Diagrama de Actividad Administracin de Historiales Mdicos

120 | P g i n a

Modelo Lgico (Conceptual) de Base de Datos

Figura 63: Modelo Lgico (Conceptual) de Base de Datos Iteracin 3

121 | P g i n a

Diseo

Modelo de Clases

Figura 64: Modelo de Clases Iteracin 3

122 | P g i n a

Modelo Fsico de Base de Datos

Figura 65: Modelo Fsico de Base de Datos Iteracin 3

Diccionario de Datos

Nombre Entidad:

Enfermedad

Descripcin:

Esta tabla contiene las enfermedades del sistema

Field

Tipo

IdEnfermedad

Int PK

Cdigo nico del enfermedad

IdTipoEnfermedad

Int FK

Llave fornea de tipo enfermedad

Descripcin

Varchar

''

Descripcin de la enfermedad

Nombre

Varchar

''

Nombre de la enfermedad

Gravedad

Integer

Gravedad de la enfermedad

FechaCreacion

DateTime '01/01/1900' Fecha en que se cre la enfermedad

Usuario

Varchar

Descripcin

''

Usuario que ingreso la enfermedad en

123 | P g i n a

el sistema
Estado

Tinyint

Estados 1 = Confirmado , 2= No
Confirmado

Nombre Entidad:

Historial Mdico

Descripcin:

Esta tabla los historiales mdicos de los pacientes en el


sistema.

Field

Tipo

IdHistorialMedico

Int PK

Cdigo nico del paciente

IdPaciente

Int FK

Llave fornea de paciente

IdMedico

Int FK

Llave fornea medico

Descripcin

Varchar

''

Descripcin del historial

FechaCreacion

DateTime '01/01/1900' fecha de creacin del historial

Usuario

Varchar

''

Nombre del usuario que ingreso este


historial

Estado

Tinyint

Estados 1 = Vigente , 2= no
Vigente

Descripcin

124 | P g i n a

Nombre Entidad:

Enfermedad Sntoma

Descripcin:

Esta tabla las relaciones de enfermedades con sus


respectivos sntomas.

Field

Tipo

IdEnfermedadSintom
a

Int PK

Cdigo nico de la relacin

IdEnfermedad

Int FK

Llave fornea de la enferdad

IdSintoma

Int FK

Llave fornea del sntoma

FechaCreacion

DateTime '01/01/1900' Fecha de creacin de la relacin

Usuario

Varchar

''

Usuario de creacin de la relacin

Estado

Tinyint

Estados 1 = Vigente , 2= no
Vigente

Descripcin

Nombre Entidad:

Historial Mdico Sntoma

Descripcin:

Esta tabla la relacion entre historial medico y sintomas

Field

Tipo

Descripcin

IdHistorialMedicoSintoma Int PK

Cdigo nico de la relacin

IdHistorialMedico

Int FK

Llave fornea de historial mdico

IdSintoma

Int FK

Llave fornea del sntoma

FechaCreacion

DateTim
e

'01/01/1900
Fecha de creacin de la relacin
'

Usuario

Varchar

''

Usuario de creacin de la relacin

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

Caso de Uso Administracin de Diagnsticos

Figura 66: Diagrama Caso de Uso Administracin de Diagnsticos


Tabla 16: Narrativa Caso de Uso Administracin de Diagnsticos

Caso de Uso: Administracin de Diagnstico (Requisito N10)


Actor: Mdico
Curso Normal
Alternativas
1) El Mdico lista los Diagnsticos de un
determinado paciente
2) El Mdico agrega un nuevo
Diagnstico a un Historial Mdico de su
autora

3) El Mdico elimina un Diagnstico de


un Historial Mdico de su autora

2.1) Si el registro est asociado a un


Historial Mdico que no fue generado por
el Mdico se informa del problema y no se
permite completar la accin
2.2) Si el registro existe se informa del
problema y no se permite completar la
accin
2.3) Si los datos ingresados no son
vlidos o falta informacin se informa del
problema y no se permite completar la
accin
3.1) Si el registro est asociado a un
Historial Mdico que no fue generado por
el Mdico se informa del problema y no se
permite completar la accin

127 | P g i n a

4) El Mdico edita un Diagnostico de un


Historial Mdico de su autora

4.1) Si el registro est asociado a un


Historial Mdico que no fue generado por
el Mdico se informa del problema y no se
permite completar la accin

5) Se repiten los pasos 2), 3) y 4) hasta


que el Mdico no desee realizar ms
operaciones

Caso de Uso Administracin Resultados de Exmenes

Figura 67: Diagrama Caso de Uso Administracin Resultados de Exmenes.


Tabla 17: Narrativa Caso de Uso Administracin Resultados de Exmenes.

Caso de Uso: Administracin Resultados de Exmenes (Requisito N3 y N15)


Actor: Mdico
Curso Normal
Alternativas
1) El Mdico lista los Resultados de
Examen de un determinado Paciente
2) El Mdico agrega un nuevo Resultado 2.1) Si el registro est asociado a un
de Examen a un Historial Mdico de su
Historial Mdico que no fue generado
autora
por el Mdico se informa del problema y
no se permite completar la accin
2.2) Si el registro existe se informa del
problema y no se permite completar la
accin
2.3) Si los datos ingresados no son
vlidos o falta informacin se informa del
problema y no se permite completar la

128 | P g i n a

accin

3) El Mdico elimina un Resultado de


Examen de un Historial Mdico de su
autora
4) El Mdico edita un Resultado de
Examen de un Historial Mdico de su
autora

3.1) Si el registro est asociado a un


Historial Mdico que no fue generado
por el Mdico se informa del problema y
no se permite completar la accin
4.1) Si el registro est asociado a un
Historial Mdico que no fue generado
por el Mdico se informa del problema y
no se permite completar la accin

5) Se repetirn los pasos 2), 3) y 4)


hasta que el Mdico no desee realizar
ms operaciones

Diagrama de Actividad Administracin de Diagnsticos

En el siguiente Diagrama de Actividad se ve como un Mdico puede agregar un nuevo


Diagnstico, adems de listar, editar y eliminar los Diagnsticos existentes.
Figura 68: Diagrama de Actividad Administracin de Diagnsticos

129 | P g i n a

130 | P g i n a

Diagrama de Actividad de Resultados de Exmenes

En el siguiente Diagrama de Actividad se ve como un Mdico puede agregar un nuevo


Resultado de Examen, adems de listar, editar y eliminar los Resultados de Exmenes
existente.

Figura 69: Diagrama de Actividad Administracin Resultados de Exmenes

131 | P g i n a

Modelo Lgico (Conceptual) de Base de Datos

Figura 70: Modelo Lgico (Conceptual) de Base de Datos Iteracin 4

132 | P g i n a

Diseo

Modelo de Clases

Figura 71: Modelo de Clases iteracin 4

133 | P g i n a

Modelo Fsico de Base de Datos

Figura 72: Modelo Fsico de Base de Datos Iteracin 4

Diccionario de Datos

Nombre Entidad:

Diagnostico

Descripcin:

Contiene los diagnsticos de los pacientes

Field

Tipo

IdDiagnostico

Int PK

Cdigo nico del diagnstico

IdHistorialMedico

Int FK

Llave fornea de historial mdico

IdEnfermedad

Int FK

Llave fornea de la enfermedad

Descripcin

Varchar

''

Descripcin del diagnstico

FechaCreacion

DateTime '01/01/1900' Fecha de creacin del diagnstico

Usuario

Varchar

Descripcin

''

Usuario de creacin del diagnstico

134 | P g i n a

Estado

Tinyint

Estados: 1 = Vigente, 2 = No Vigente

Nombre Entidad:

ResultadoExamen

Descripcin:

Contiene los resultados de los exmenes de los pacientes

Field

Tipo

IdResultadoExamen

Int PK

Cdigo nico del resultado

IdHistorialMedico

Int FK

Llave fornea de historial mdico

IdExamenGeneral

Int FK

Llave fornea del examen general

ValorNumerico

Int

Valor numrico del resultado

ValorDescriptivo

Varchar

''

Valor descriptivo del resultado

FechaCreacion

DateTime '01/01/1900' Fecha de creacin del resultado

Usuario

Varchar

''

Usuario de creacin del resultado

Estado

Tinyint

Estados: 1 = Vigente, 2 = No Vigente

Descripcin

135 | P g i n a

Construccin
Maqueta Mantenedor Resultados de Exmenes

Figura 73: Maqueta Mantenedor Resultado de Exmenes

Maqueta Ingreso Resultados de Exmenes

Figura 74: Maqueta Ingreso Resultados de Exmenes

136 | P g i n a

Maqueta Sistema de Alertas

En la siguiente imagen se muestra como se alerta al mdico, mediante un icono ubicado en


la parte superior de la pantalla, las anomalas detectadas.
Las notificaciones de alerta aparecen en la medida en que se ingresan resultados de
exmenes cuyos valores estn fuera del umbral definido por los valores lmites de
normalidad para cada enfermedad.
Por ejemplo: Se han definido ciertos rangos de normalidad para el examen de Antgeno
Prosttico asociado al cncer de prstata, por lo cual es relevante que el sistema alerte
aquellos casos en que los resultados de los pacientes sobrepasen el umbral definido como
normal, a fin de que los mdicos soliciten la realizacin de exmenes especficos para
detectar a tiempo eventuales patologas en los pacientes.

137 | P g i n a

Figura 75: Maqueta Alertas

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]

Pressman Roger, Ingeniera del software, 6th edition, 2010

[LAURENT]

Patrones de diseo para C#, LaurentDebrauwer

[MINSAL]

Gua clnica Minsal 2010, Cncer de prstata en personas de 15 aos y


ms

16.2 SITIOS WEB


[CANCER]

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

También podría gustarte