CUERPO TESIS.docx

Í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 MOTIVACIÓN...........................................................XII

4. INTRODUCCIÓN..........................................................................................1

5. OBJETIVOS..................................................................................................2

5.1. OBJETIVO GENERAL...........................................................................2

5.2. OBJETIVOS ESPECÍFICOS..................................................................2

6. SITUACIÓN ACTUAL...................................................................................3

7. MARCO TEORICO.......................................................................................6

8. MARCO REFERENCIAL..............................................................................9

9. PARADIGMAS DE DESARROLLO DE SOFTWARE.................................12

9.1 ANÁLISIS Y COMPARACIÓN..............................................................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 exploración...........................................................................23

9.2.2 Fase de planificación.........................................................................24

1 | P á g i n a

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

9.2.4 Fase de puesta en producción...........................................................24

10 PATRONES DE DISEÑO........................................................................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 RELACIÓN 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 TÉCNICA.................................................................39

13.4 FACTIBILIDAD ECONÓMICA...........................................................40

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

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

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

14.1 FASE DE EXPLORACIÓN................................................................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 médicas............................................45

14.1.4 Historia de Usuario 4: Alertas tempranas........................................45

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

14.2 FASE DE PLANIFICACIÓN..............................................................47

2 | P á g i n a

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

14.3.1 Iteración 1........................................................................................50

14.2.2 Iteración 2........................................................................................80

14.2.3 Iteración 3........................................................................................95

14.2.4 Iteración 4......................................................................................105

15. Conclusión.............................................................................................117

16. Bibliografía.............................................................................................118

16.1 Libros..............................................................................................118

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

3 | P á g i n a

ÍNDICE DE FIGURAS Y TABLAS

Figura 1: Ingreso Petición de Horas....................................................................4

Figura 2: Listado de Horas..................................................................................5

Figura 3: Menú Ofimedic.....................................................................................9

Figura 4 : Historias Médicas 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 Construcción de Prototipos..............................................19

Figura 10: Modelo de Proceso Unificado..........................................................20

Figura 11: Diagrama Metodología XP...............................................................23

Figura 12: Patrón de Diseño 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 Relación de Clases.............................................................34

Figura 19: Objetos Herencia de Clases.............................................................34

Figura 20: Ejemplo de una relación según notación Barker..............................37

Tabla 1: Requisitos funcionales y no funcionales..............................................49

Figura 21: Diagrama Caso de Uso Administración de Categorías de Exámenes

..........................................................................................................................50

Tabla 2: Narrativa Caso de Uso Administración de Categorías de Exámenes. 50

Figura 22: Diagrama Caso de Uso Administración de Medicamentos..............51

Tabla 3: Narrativa Caso de Uso Administración de Medicamentos..................51

Figura 23: Diagrama Caso de Uso Administración de Tipos de Enfermedad.. .52

Tabla 4: Narrativa Caso de Uso Administración de Tipos de Enfermedad.......52

Figura 24: Diagrama Caso de Uso Administración de Especialidades.............53

Tabla 5: Narrativa Caso de Uso Administración de Médicos............................53

Figura 25: Diagrama Caso de Uso Administración de Médicos........................54

Tabla 6: Narrativa Caso de Uso Administración de Médicos............................54

4 | P á g i n a

Figura 26: Diagrama Caso de Uso Administración de Pacientes......................55

Tabla 7: Narrativa Caso de Uso Administración de Pacientes..........................55

Figura 27: Diagrama Caso de Uso Administración de Síntomas......................56

Tabla 8: Narrativa Caso de Uso Administración de Síntomas...........................56

Figura 28: Diagrama Caso de Uso Administración de Tratamientos.................57

Tabla 9: Narrativa Caso de Uso Administración de Tratamientos.....................57

Figura 29: Diagrama de Actividad Administración de Categorías de Exámenes

..........................................................................................................................58

Figura 30: Diagrama de Actividad Administración de Medicamentos...............59

Figura 31: Diagrama de Actividad Administración de Enfermedades...............60

Figura 32: Diagrama de Actividad Administración de Especialidades...............61

Figura 33: Diagrama de Actividad Administración de Médicos.........................62

Figura 34: Diagrama de Actividad Administración de Pacientes.......................63

Figura 35: Diagrama de Actividad Administración de Síntomas........................64

Figura 36: Diagrama de Actividad Administración de Tratamientos..................65

Figura 37: Modelo Lógico (Conceptual) de Base de Datos Iteración 1.............66

Figura 38: Arquitectura de Hardware................................................................67

Figura 39: Arquitectura de Software..................................................................68

Figura 40: Modelo de Clases Iteración 1...........................................................69

Figura 41: Modelo Físico de Base de Datos Iteración 1....................................70

Figura 42: Modelo y Controlador de Sistema....................................................74

Figura 43: Mantenedor de Pacientes................................................................75

Figura 44: Ingreso, edición y eliminación de Síntomas.....................................76

Figura 45: Ingreso, edición y eliminación de Médicos.......................................77

Figura 46: Diagrama Caso de Uso Administración de Medicaciones................80

Tabla 10: Narrativa Caso de Uso Administración de Medicaciones..................80

Figura 47: Diagrama Caso de Uso Administración de Procedimientos.............81

Tabla 11: Narrativa Caso de Uso Administración de Procedimientos...............81

Figura 48: Diagrama Caso de Uso Administración de Exámenes Generales...82

Tabla 12: Narrativa Caso de Uso Administración de Exámenes Generales.....82

Figura 49: Diagrama Caso de Uso Administración de Exámenes Específicos. 83

Tabla 13: Narrativa Caso de Uso Administración de Exámenes Específicos. . .83

Figura 50: Diagrama de Actividad Administración de Medicaciones.................84

Figura 51: Diagrama de Actividad Administración de Procedimientos..............85

5 | P á g i n a

Figura 52: Diagrama de Actividad Administración de Exámenes Generales....86

Figura 53: Diagrama de Actividad Administración de Exámenes Específicos. .87


Figura 55: Modelo de Clases Iteración 2...........................................................89

Figura 56: Modelo Físico de Base de Datos Iteración 2....................................90

Figura 57: Maqueta Listado de Exámenes Generales......................................93

Figura 58: Maqueta Edición de Exámenes Generales......................................93

Figura 59: Diagrama Caso de Uso Administración de Enfermedades..............95

Tabla 14: Narrativa Caso de Uso Administración de Enfermedades................95

Figura 60: Diagrama Caso de Uso Administración de Historiales Médicos......96

Tabla 15: Narrativa Caso de Uso Administración de Historiales Médicos.........96

Figura 61: Diagrama de Actividad Administración de Enfermedades...............97

Figura 62: Diagrama de Actividad Administración de Historiales Médicos........98


Figura 64: Modelo de Clases Iteración 3.........................................................100

Figura 65: Modelo Físico de Base de Datos Iteración 3..................................101

Figura 66: Diagrama Caso de Uso Administración de Diagnósticos...............105

Tabla 16: Narrativa Caso de Uso Administración de Diagnósticos.................105

Figura 67: Diagrama Caso de Uso Administración Resultados de Exámenes.

........................................................................................................................106

Tabla 17: Narrativa Caso de Uso Administración Resultados de Exámenes..106

Figura 68: Diagrama de Actividad Administración de Diagnósticos................107

Figura 69: Diagrama de Actividad Administración Resultados de Exámenes.108

Figura 70: Modelo Lógico (Conceptual) de Base de Datos Iteración 4...........109

Figura 71: Modelo de Clases iteración 4.........................................................110

Figura 72: Modelo Físico de Base de Datos Iteración 4..................................111

Figura 73: Maqueta Mantenedor Resultado de Exámenes.............................113

Figura 74: Maqueta Ingreso Resultados de Exámenes..................................113

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

6 | P á g i n a

AGRADECIMIENTOS

Al llegar al final de este proceso, me gustaría 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 González y Jaime Antonio

Meza Pérez 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 González y Carolina Pino Gaete, por compartir los

buenos y malos momentos, por apoyarme y seguir siendo parte de mi vida. A

mis compañeros de la Universidad Central, con los cuales compartí muchos

momentos, muchas noches de desvelo y muchos días de alegría.

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 habría estado orgulloso.

¡Gracias!

Jaime Esteban Meza Araneda

7 | P á g i n a

En estas líneas quiero expresar mi más profundo y sincero agradecimiento a

todas aquellas personas que con su ayuda han colaborado en la realización del

presente proyecto de tesis, en especial el Sr. Edgardo Mauricio Campos

Martínez, profesor guía de este proyecto, por la orientación, el seguimiento y la

supervisión continua de la misma, pero sobre todo por la motivación y el apoyo

recibido a lo largo de este proyecto.

Especial reconocimiento merece el interés mostrado por nuestro trabajo y las

sugerencias recibidas de la profesora Valentina Tombolini Echeverría, con la

que nos encontramos muy agradecidos por el ánimo infundido y la confianza

depositada en nosotros.

A mi amigo Sebastián Altamirano, por su ayuda incondicional y al Dr. Nelson

Orellana Salinas, Urológo y a su equipo médico por su colaboración en el

suministro de los datos y de las instalaciones de Uromed, necesarias para la

realización de este proyecto.

Un agradecimiento muy especial merece la comprensión, paciencia y el ánimo

recibidos de nuestras familias y amigos a todos ellos, muchas gracias.

André Antoine Autrán Orellana

8 | P á g i n a

DEDICATORIA

Nos gustaría dedicar nuestro proyecto a toda nuestra familia. A nuestros

padres y abuelos, por su comprensión y ayuda en los buenos y malos

momentos. Nos han enseñado 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

empeño y todo ello con una gran dosis de amor, sin pedir nunca nada a

cambio.

A todos ellos, muchas gracias de todo corazón.

9 | P á g i n a

1. RESUMEN

Si se pudiera detectar una enfermedad prematuramente, sería posible mejorar

la calidad y aumentar la esperanza de vida de los pacientes.

Por tal razón, es fundamental que el profesional de la salud disponga de

manera oportuna, toda la información y las herramientas disponibles para

diagnosticar con antelación algún tipo de patología en los pacientes. Por lo

cual, sería de gran utilidad contar con una herramienta tecnológica que apoye a

la toma de decisiones en el área de la medicina, permitiendo detectar, a través

de la información estadística disponible y los antecedentes del paciente, las

eventuales patologías que éste pueda padecer.

En función a lo anteriormente mencionado, se desarrollará un sistema de

información capaz de satisfacer los requerimientos planteados, para

transformarse en un real aporte a la medicina, en particular al área de la

Urología, considerando que la medicina en general es una rama de la ciencia

muy extensa y compleja.

Para abordar esta problemática se recopiló toda la información estadística y los

antecedentes de los pacientes relacionados con su historial médico, datos

demográficos1, patologías2, historial familiar de enfermedades genéticas e

historial de controles del paciente, con el objetivo de diseñar un sistema capaz

de procesar los datos que ayudarán a detectar eventuales patologías.

Finalmente, es fundamental destacar que se cuenta con el respaldo de un

cirujano especialista en el área de la Urología e inversionista de la clínica

Uromed, el Dr. Nelson Orellana (Urólogo, Universidad de Chile) quien facilitará

las instalaciones de Uromed para la puesta en marcha e implementación del

proyecto.

1 Datos demográficos: es toda información de la que se dispone 2 Patologías: Conjunto de síntomas de una enfermedad

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

11 | P á g i n a

3. ANTECEDENTES Y MOTIVACIÓN

En nuestro país la mortalidad por el cáncer de próstata ha ido en aumento

sostenido y se cuadruplicó en los últimos 50 años. En 2002 murieron 1.472

hombres por cáncer de próstata en Chile (uno cada seis horas). Cada año

mueren más hombres por cáncer de próstata que por accidentes

automovilísticos; pero, gracias a su detección 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, ningún software

específico que apoye la gestión del área de Urología. Menos aún, uno capaz de

sugerir eventuales patologías a través de información existente y el historial

médico del paciente.

El desarrollo de este proyecto se enfoca en contribuir a la salud de las

personas, a través de la pronta detección de patrones de riesgo y el fomento de

controles oportunos, con el fin de apoyar a los médicos en sus diagnósticos,

minimizando las tasas de error por omisión de información, mejorando con ello,

la calidad de vida de los pacientes.

12 | P á g i n a

Sistemas de Diagnóstico Prematuro

4. INTRODUCCIÓN

En el ámbito del desarrollo del proyecto de tesis del segundo semestre del año

2013, el médico cirujano Sr. Nelson Orellana Salinas especialista en Urología

de la clínica Uromed, ha solicitado diseñar e implementar un sistema capaz de

gestionar la información administrativa de los pacientes.

El sistema permitirá al médico agregar nuevos pacientes, patologías

preexistentes, exámenes físicos, diagnósticos, imagenología1, tratamientos, y

evolución de los pacientes, con el fin de aumentar el porcentaje de éxito y la

precisión al momento de sugerir un posible diagnóstico.

El sistema pondrá a disposición del médico un avanzado sistema de filtros de

pacientes, capaces de permitir búsquedas por: patología, edad, fecha atención,

nombre, tratamiento, etc., con el fin de poder optimizar su labor como

profesional, en la medida en que se facilita el trabajo de búsqueda de

antecedentes, siendo con ello, más eficaz.

La información ingresada al sistema permitirá saber al médico cuales son las

enfermedades con mayor tendencia y los rangos de edades donde éstas

suceden, lo que apoyará los posteriores estudios de la materia.

Además 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 médico, a través de reportes, agilizar la

planificación y reserva de horas de atención enfocadas en el seguimiento y

control de pacientes, considerando que un factor de éxito determinante en la

recuperación o en la prevención de cualquier tipo de enfermedad es el tiempo.

1Imagenología: conjunto de las técnicas y de los procedimientos que permiten obtener imágenes del cuerpo humano con fines clínicos o científicos.

1 | P á g i n a

http://definicion.de/imagen/

5. OBJETIVOS

5.1. OBJETIVO GENERAL

Desarrollar un sistema de información que permita ingresar pacientes, con sus

respectivos datos médicos, con la finalidad de realizar un seguimiento integral

al proceso evolutivo de éstos, apoyando la toma de decisiones en el área de la

Urología, en base a un sistema de alertas.

5.2. OBJETIVOS ESPECÍFICOS

1. Almacenar y gestionar la información existente, relacionada a

parámetros e indicadores de riesgo de patologías.

ME: Disponer de los antecedentes e informes científicos existentes.

2. Diseñar e implementar estructuras de datos apropiadas que permitan

almacenar y gestionar las fichas clínicas.

ME: Disponer de los antecedentes e historiales clínicos actualizados de

los pacientes.

3. Diseñar y ejecutar los algoritmos1 necesarios para generar reportes que

permitan identificar la necesidad de realizar determinados exámenes

preventivos.

ME: Actualizar oportunamente los antecedentes clínicos de los pacientes

1 Algoritmos: Conjunto ordenado y finito de operaciones que permite hallar la solución de un problema

2 | P á g i n a

6. SITUACIÓN ACTUAL

Actualmente la Clínica Uromed no posee ningún software encargado de

gestionar la información clínica 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 información por parte de los médicos.

Cabe señalar, que existe un sistema en la clínica encargado de la

administración de la reserva de horas a los pacientes. Dicho sistema es

utilizado tanto por los médicos como por las secretarias, y funciona

básicamente como un tipo de agenda, en el cual se registran las horas que un

cliente solicitó por teléfono o presencialmente. El flujo de trabajo es el

siguiente:

1. Un Paciente llama a la clínica para preguntar si existen horas

disponibles el día miércoles 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 Médico en su consulta accede a esta agenda para revisar los

días y las horas en los cuales los pacientes se atenderán

A continuación se expone una imagen del sistema implementado en Uromed.

3 | P á g i n a

Figura 1: Ingreso Petición de Horas

Descripción: La Secretaria ingresa una nueva petición de horas al sistema

4 | P á g i n a

Figura 2: Listado de Horas

Descripción: El médico puede ver los pacientes que tomaron hora con la

secretaria.

5 | P á g i n a

7. MARCO TEORICO

La Urología es una especialidad médico-quirúrgica que se ocupa del estudio,

diagnóstico y tratamiento de las patologías que afectan al aparato urinario,

glándulas suprarrenales1, retro peritoneo de ambos sexos y al aparato

reproductor masculino, sin límite de edad. Ésta puede tratar distintas ramas,

como por ejemplo:

Oncología urológica: La urología oncológica, oncología urológica o

uro-oncología es la especialidad médica que estudia los tumores

benignos y malignos, pero con especial atención a los malignos, esto es,

al cáncer, centrada en el aparato reproductor masculino

Andrología: La andrología es la parte de la urología encargada del

estudio, investigación, y exploración de cualquier aspecto relacionado

con la función sexual y reproducción masculina.

Los principales problemas de los que se encarga la andrología son los

trastornos de erección, otros trastornos sexuales del varón y la

infertilidad masculina

Endourología: Son el conjunto de maniobras diagnósticas o

terapéuticas, percutáneas, endoscópicas o imagenológicas, realizadas

en la luz de las vías urinarias. Algunos autores la definen como cirugía

“mínimamente invasiva”

Urología pediátrica o infantil: La urología pediátrica es aquella

subespecialidad médica dedicada a estudiar las enfermedades del

genital de los niños y bebés, siendo necesario para esto el haber

realizado al menos 1 a 2 años más, después de una especialización en

Cirugía Pediatría o en Urología

Urología geriátrica: La urología geriátrica es aquella subespecialidad

médica dedicada a estudiar las enfermedades del sistema reproductor

de los ancianos

Urolitiasis: La urología de la litiasis o urolitiasis es aquella

subespecialidad que se encarga del estudio, diagnóstico y tratamiento

de las enfermedades que se manifiestan con formación de cálculos

1 Glándulas suprarrenales: adrenal situada en el hombre en la parte superior de los riñones.

6 | P á g i n a

urinarios (piedras o concreciones). Los cálculos pueden formarse en

cualquier punto de la vía urinaria, desde las cavidades del riñón a la

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

localizaciones más comunes son riñón, uréter y vejiga

De las especialidades existentes, Uromed se especializa en las siguientes

áreas:

Urología Femenina: Es una rama de la urología que diagnostica y trata

patologías urinarias femeninas tales como: infecciones urinarias (cistitis)

e incontinencia de orina

Disfunciones Sexuales: Uromed cuenta con un departamento de

disfunción sexual que atiende a pacientes con patología eréctil,

eyaculación precoz, trastornos de la libido. Tratamiento de pareja con

apoyo psicológico

Urología General: La urología es la especialidad médica que evalúa y

trata las enfermedades relacionadas con los riñones, uréteres, vejiga,

próstata, genitales masculinos y enfermedades de transmisión sexual

Oncología Urológica: Consiste en el diagnóstico y tratamiento de los

cánceres de la vía urinaria, próstata, riñones, vejiga, testículos y

genitales masculinos

Urología Pediátrica: Atiende a niños y niñas hasta los 15 años, que

presentan problemas urológicos infantiles tales como: infecciones

urinarias, patología genital, incontinencia de orina (enuresis) y

malformaciones congénitas de la vía urinaria

Infertilidad Masculina: Evalúa las alteraciones reproductivas en los

hombres. Cuenta con un laboratorio especializado.

Cálculos Urinarios: Tiene las más modernas opciones de tratamiento

de los cálculos urinarios. Ondas de choque que permiten eliminar los

cálculos sin la necesidad de cirugía convencional.

7 | P á g i n a

Además Uromed realiza los siguientes exámenes en sus sucursales:

Ecotomografía: La unidad de ecotomografía cuenta con un equipo de

última generación y médicos con gran experiencia en las enfermedades

urológicas

Cistoscopia: Examen que permite la visualización directa de la vejiga

tanto en la mujer como en el hombre. En el hombre también permite

examinar la uretra y la próstata

Urodinamia: Examen que permite detectar el mal funcionamiento de la

vejiga y los esfínteres, en enfermedades tan comunes como la

incontinencia de orina en la mujer, como así también para diagnosticar

las disfunciones neurológicas de la vejiga

8 | P á g i n a

8. MARCO REFERENCIAL

A continuación se describe brevemente un software que implementa, entre

otros, módulos de gestión de pacientes:

Figura 3: Menú Ofimedic

Ofimedic es un sistema que permite la gestión de la información administrativa

y médica, éste permite gestionar los pacientes y acceder a información.

9 | P á g i n a

Figura 4 : Historias Médicas Ofimedic

El sistema está diseñado para que cada usuario configure su forma de trabajar;

sus tipos de visita, sus facultativos, sus actos médicos, los servicios que ofrece

y sus tarifas.

Figura 5: Toma de Horas Ofimedic

Si bien Ofimedic da solución a muchos problemas administrativos, no es una

herramienta específica para el área de urología ni para ningún área en

10 | P á g i n a

especial, por lo cual, si una clínica 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 adaptación y capacitación de los usuarios,

siendo de esta forma una mejor solución para cualquier clínica.

1 Alertas tempranas: Sistema que indica mediante alertas si un paciente padece de algún tipo de enfermedad, abasteciéndose de los exámenes y datos clínicos realizados previamente.

11 | P á g i n a

9. PARADIGMAS DE DESARROLLO DE SOFTWARE

Uno de los problemas más frecuentes con los que se encuentran los ingenieros

de software y programadores al momento de desarrollar una nueva aplicación,

es la escasa información de marcos teóricos comunes.

Es por esta razón que en el presente capítulo se explican las distintas

metodologías1 que pueden ser utilizadas por los programadores para mejorar la

calidad del producto desde el punto de vista técnico.

Cabe destacar que a lo largo de la historia los lenguajes de programación han

ido en paralelo con el desarrollo de los paradigmas de programación. 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.1 ANÁLISIS Y COMPARACIÓN

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 través de una secuencia de fases

ordenadas en forma lineal, permitiendo iteraciones al estado anterior. El

número de etapas suele variar, pero en general suelen ser:

Análisis

Diseño del software

Implementación

Pruebas del sistema

Mantenimiento

Al final de cada fase el personal técnico y los usuarios tienen la oportunidad de

revisar el progreso del proyecto.

Como se puede ver, el modelamiento en cascada es útil cuando están

presentes todas las condiciones óptimas para el desarrollo del sistema, estas

1 Metodología: Conjunto de métodos que se siguen en una investigación científica o en una exposición doctrinal.

12 | P á g i n a

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 más 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

mínimo

La documentación se produce en cada etapa del desarrollo del modelo

de cascada, esto hace que la comprensión del producto a diseñar sea

más sencilla

Después de cada etapa importante del desarrollo del software, se

realizan pruebas para comprobar el correcto funcionamiento del módulo

desarrollado

Desventajas

Si la fase de diseño no ha sido bien implementada, es altamente

probable que las cosas pueden ir mal en la fase de implementación

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 confusión

9.1.2 Modelo Incremental

Como se vio anteriormente, el modelo de diseño en Cascada requiere que los

clientes de un proyecto tengan un conjunto de requerimientos claros antes de

que se inicie el diseño, junto con esto el ingeniero debe cumplir con estrategias

particulares de diseño antes de la implementación. Es importante recordar que

13 | P á g i n a

cuando se producen cambios en los requerimientos es necesario volver a hacer

el trabajo de obtención de requerimientos, análisis, diseño e implementación.

En contraste al modelo en cascada se tiene el modelo de desarrollo evolutivo,

el cual permite que las decisiones de diseño se retrasen, pero origina un

software que puede estar débilmente estructurado y difícil de comprender y

mantener.

El modelo incremental fue propuesto por Harlan Mills en el año 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, ordenándolos por prioridad (de más 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

La asignación de servicios a los incrementos depende de la prioridad del

servicio respecto de los que tienen una prioridad más 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 análisis adicional de

requerimientos, para los incrementos posteriores, pero no se aceptan cambios

en los requerimientos que se tienen en el incremento actual.

14 | P á g i n a

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 visión 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 pirámide 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 más alta prioridad se entregan primero, y los

incrementos posteriores se integran en ellos, es inevitable que los

servicios más importantes del sistema sean a los que se les hagan más

pruebas. Esto significa que es menos probable que los clientes

encuentren fallos de funcionamiento del software en las partes más

importantes del sistema

Desventajas

Los incrementos deben ser relativamente pequeños y cada uno debe

entregar alguna funcionalidad del sistema. Puede ser difícil adaptar los

requerimientos del cliente a incrementos de tamaño apropiado. Es más,

15 | P á g i n a

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 difícil identificar los recursos comunes que requieren todos los

incrementos.

El modelo incremental tiene una variante llamada programación extrema, la

cual se basa en el desarrollo y la entrega de incrementos muy pequeños, la

participación constante del cliente en el proceso, en la mejora constante del

código y en la programación en parejas.

9.1.3 Modelo Espiral

El Modelo en Espiral, fue desarrollado por Barry Boehm en 1988, éste

básicamente tiene las características de un desarrollo evolutivo, usando el

modelo en cascada para cada etapa de la iteración, teniendo en cuenta el

riesgo que aparece a la hora de desarrollar el software. Para su realización se

parte mirando las distintas alternativas posibles de desarrollo, se elige la que

posee un riesgo más pequeño (asumible) y se hace un ciclo de espiral, en caso

de que el cliente quisiera seguir haciendo actualizaciones o mejoras al sistema.

16 | P á g i n a

Figura 8: Modelo Espiral

El Modelo en Espiral, proporciona la capacidad de entregar versiones

incrementales rápidamente. En las primeras iteraciones de este modelo se

podría hablar de un prototipo, para luego en las últimas iteraciones, las

versiones sean cada vez más completas del sistema. Algunas características

de este modelo son:

Puede combinarse con otros modelos de proceso de desarrollo

Es bueno al momento de desarrollar grandes sistemas

Para hacer el análisis de riesgos se necesita la participación 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 están compuestas por un

conjunto de tarea, estas se adaptan a las distintas necesidades de los

proyectos.

17 | P á g i n a

Ventajas

Luego de cada evolución tanto desarrollador como cliente pueden

responder de mejor manera a los riesgos

Este modelo permite al desarrollador aplicar una construcción de

prototipos en cualquiera de sus etapas de evolución

El modelo en espiral demanda una consideración directa de los riesgos

técnicos 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 pequeños sistemas (debido a su

complejidad)

Genera mucho tiempo en el desarrollo del sistema

Modelo costoso

Requiere experiencia en la identificación 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 rápida, con el fin de entender con facilidad

y aclararlas de manera tal que tanto el cliente, usuario y el desarrollador estén

conformes con lo que se va a desarrollar, así como también con la solución 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

diseños, para que el cliente experimente con ellos, y así ir descartándolos a

medida que se van añadiendo 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 interactúa el hombre y la

máquina. Este modelo se encarga principalmente de ayudar tanto al ingeniero

18 | P á g i n a

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

construcción del sistema.

Etapas para la elaboración del Modelo de Prototipos: [Figura13]

1. Plan rápido

2. Modelado, diseño rápido

3. Construcción del Prototipo

4. Desarrollo, entrega y retroalimentación

5. Comunicación

Figura 9: Modelo de Construcción 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 información complementaria a los requerimientos constituyen un

gran apoyo a las estimaciones de esfuerzo de todas las áreas,

incluyendo proveedores

Son más fáciles de abordar con los usuarios finales

Desventajas

El cliente ve funcionando lo que para él es la primera versión del

prototipo que ha sido prácticamente un bosquejo lo que puede

19 | P á g i n a

desencadenar la desilusión de éste

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

genérico que puede ser utilizado para una gran cantidad de tipos de sistemas

de software, para diferentes áreas de aplicación, diferentes tipos de

organizaciones, diferentes niveles de competencia y diferentes tamaños de

proyectos.

Provee un enfoque disciplinado en la asignación de tareas y responsabilidades

dentro de una organización de desarrollo. Su meta es asegurar la producción

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 metodología 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

20 | P á g i n a

http://es.wikipedia.org/wiki/James_Rumbaugh

http://es.wikipedia.org/wiki/Grady_Booch

http://es.wikipedia.org/wiki/Ivar_Jacobson

http://es.wikipedia.org/wiki/Ivar_Jacobson

21 | P á g i n a

Ventajas

• Está basada totalmente en mejoras prácticas de la metodología

• 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

22 | P á g i n a

9.2 PARADIGMA SELECCIONADO: XP

Las metodologías ágiles1 están 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 según les parezca conveniente.

Existen muchos métodos de desarrollo ágil, la mayoría minimiza riesgos

desarrollando software en lapsos cortos, de esta manera se evita cambiar lo

desarrollado hacia atrás.

El software desarrollado en una unidad de tiempo es llamado una iteración, la

cual debe durar de una a cuatro semanas.

Cada iteración del ciclo de vida incluye: planificación, análisis de

requerimientos, diseño, codificación, revisión y documentación. Una iteración

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

iteración el equipo vuelve a evaluar las prioridades del proyecto.

La metodología que se utilizará para el desarrollo del software: “Sistema de

Diagnostico Prematuro para Urología”, será una de las metodologías ágiles

más populares: “Extreme Programming” (XP) o “Programación Extrema”.

La selección de la metodología 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 existirán cambios significativos en los

mismos a lo largo del ciclo de vida del desarrollo

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

1 Metodologías ágiles: Son métodos de ingeniería del software basados en el desarrollo iterativo e incremental.2 Demo: Parte más pequeña del sistema total.

23 | P á g i n a

Al igual que en las otras metodologías, para XP es necesario entender los

requisitos, estimar el esfuerzo, crear la solución y entregar una solución

(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 iteración se realiza

un ciclo completo de análisis, diseño, desarrollo y pruebas, pero utilizando un

conjunto de reglas y prácticas que caracterizan a XP.

Figura 11: Diagrama Metodología XP

Si bien el ciclo de vida de un proyecto XP es muy dinámico, se puede separar

en fases:

9.2.1 Fase de exploración

Es la fase en la que se define el alcance general del proyecto. En esta fase, el

cliente define lo que necesita mediante la redacción de sencillas “historias de

usuarios”. Los programadores estiman los tiempos de desarrollo en base a esta

información. Debe quedar claro que las estimaciones realizadas en esta fase

son primarias, y podrían variar cuando se analicen más en detalle en cada

iteración.

Esta fase dura típicamente un par de semanas, y el resultado es una visión

general del sistema, y un plazo total estimado.

24 | P á g i n a

9.2.2 Fase de planificación

La planificación es una fase corta, en la que el cliente, los gerentes y el grupo

de desarrolladores acuerdan el orden en que deberán implementarse las

historias de usuario, y, asociadas a éstas, las entregas. Típicamente esta fase

consiste en una o varias reuniones grupales de planificación. 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 iteración.

Como las historias de usuario no tienen suficiente detalle como para permitir su

análisis y desarrollo, al principio de cada iteración se realizan las tareas

necesarias de análisis, recabando con el cliente todos los datos que sean

necesarios. El cliente, por lo tanto, también debe participar activamente durante

esta fase del ciclo.

Las iteraciones son también utilizadas para medir el progreso del proyecto. Una

iteración terminada sin errores es una medida clara de avance.

9.2.4 Fase de puesta en producción

Si bien al final de cada iteración se entregan módulos funcionales y sin errores,

puede ser deseable por parte del cliente no poner el sistema en producción

hasta tanto no se tenga la funcionalidad completa.

En esta fase no se realizan más desarrollos funcionales, pero pueden ser

necesarias tareas de ajuste (“fine tuning”).

25 | P á g i n a

10 PATRONES DE DISEÑO

Los patrones de diseño permiten al arquitecto de software resolver problemas

de diseño de software, ya que dan una descripción de los elementos y tipos de

relaciones con el fin de formalizar la comunicación y la reutilización de código.

Dicho con otras palabras los patrones de diseño 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 solución sea considerada un patrón de diseño debe poseer

ciertas características. 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 diseño en distintas circunstancias.

A medida que los patrones se descubren en todo nuevo proyecto, se puede

reutilizar la plantilla básica del patrón desde modelos previos con los nombres

de las variables apropiadas modificados para el proyecto en curso.

10.1 MODELO VISTA CONTROLADOR

MVC2 es un patrón de diseño de software que separa los datos de una

aplicación, la interfaz de usuario, y la lógica de control en tres componentes

distintos. Se ve frecuentemente en aplicaciones web, donde la vista es la

página HTML y el código que provee de datos dinámicos a la página. El modelo

es el Sistema de Gestión de Base de Datos y la Lógica 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 representación específica de la información con la cual el

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

su controlador facilitando las presentaciones visuales complejas. El

sistema también puede operar con más datos no relativos a la

1 Parametrizar: acción de fijar parámetros2 MVC = Modelo Vista Controlador.

26 | P á g i n a

presentación, haciendo uso integrado de otras lógicas 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 patrón de desarrollo ofrece, con MVC la aplicación se

puede desarrollar rápidamente, de forma modular, facilitando la mantención 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 aplicación en modelos, vistas y

controladores lo que hace que el sistema sea muy ligero, permitiendo añadir

características nuevas rápidamente y adaptar las antiguas.

El diseño modular permite a los programadores y diseñadores trabajar en

paralelo, así como realizar rápidamente el desarrollo de prototipos. El hecho de

que se lleve a cabo estas separaciones, también permite que se puedan

realizar adaptaciones en distintas partes de la aplicación sin que se vea

afectado el resto del software.

10.2 DATA ACCESS OBJECT

En el desarrollo del proyecto se utilizará el patrón DAO1, el cual es una solución

al problema diferencial entre un programa orientado a objetos y una base de

datos relacional, implementando únicamente una interfaz de programación.

Este patrón se utiliza para abstraer y encapsular2 los accesos, gestionar las

conexiones a la base de datos y obtener los datos almacenados.

1 DAO: Data AccesObject2 Encapsular: ocultamiento del estado, es decir, de los datos miembros de un objeto de manera que sólo se pueda cambiar mediante las operaciones definidas para ese objeto.

27 | P á g i n a

Figura 12: Patrón de Diseño DAO

Básicamente en el patrón 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

CodeBehind2con el objetivo de acceder a los datos de la BD3 desde el código

de manera ordenada.

La aplicación se comunica con la capa Enterprise la cual encapsula el código y

envía a los datos a la capa Model, la cual se encarga de generar las

correspondientes interacciones con la base de datos, utilizando los métodos

ShowList (método para mostrar datos de la BD), Create (Método estático que

inserta en la BD) y método Update (método 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 (Aplicación).

2CodeBehind: Código oculto, que solo puede ver el programador desde el intérprete.3 BD: Base de Datos, aloja la información ingresada al sistema.

28 | P á g i n a

11 LENGUAJE UNIFICADO DE MODELADO (UML)

El Lenguaje de Modelamiento Unificado (UML –Unified Modeling Language) es

un lenguaje gráfico 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, además de cosas concretas como lo son escribir clases en un

lenguaje determinado, esquemas de base de datos y componentes de software

reusables.

11.1 CASOS DE USO

11.1.1 Diagramas de Casos de Uso

El diagrama de casos de uso representa la forma en cómo un Cliente (Actor)

opera con el sistema en desarrollo, además de la forma, tipo y orden en como

los elementos interactúan (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 más bien la labor

que realiza frente al sistema.

29 | P á g i n a

Caso de Uso:

Figura 14: Caso de Uso

Es una operación/tarea específica que se realiza tras una orden de algún

agente externo, sea desde una petición de un actor o bien desde la invocación

desde otro caso de uso.

Relaciones:

Asociación

Es el tipo de relación más básica que indica la invocación desde un actor o

caso de uso a otra operación (caso de uso). Dicha relación se denota con una

flecha simple.

Generalización

Este tipo de relación es uno de los más utilizados, cumple una doble función

dependiendo de su estereotipo, que puede ser de Uso (<<uses>>) o de

Herencia (<<extends>>).

Este tipo de relación está orientado exclusivamente para casos de uso (y no

para actores).

Extends: Se recomienda utilizar cuando un caso de uso es similar a otro

(características).

Uses: Se recomienda utilizar cuando se tiene un conjunto de características

que son similares en más de un caso de uso y no se desea mantener copiada

la descripción de la característica.

11.1.2 Narrativas de Casos de Uso

La última fase en el desarrollo de un modelo de casos de uso es la

documentación de los casos de uso a través de narrativas. Las narrativas de

30 | P á g i n a

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 característica 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 añadir pasos alternativos, así como condiciones, reglas y limitaciones

que debe cumplir el caso de uso.

En este se pueden ver:

Caso de Uso: Permite identificar el nombre de la acción 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 quién consultar con

posterioridad sobre algún 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 acción 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 número de cliente

2) El sistema obtiene la información básica 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 más productos

Si bien esto describe a la perfección el funcionamiento normal del caso de uso

no existe un solo tipo de narrativa de alto nivel, por lo que cada diseñador de

sistema está libre de poder utilizar la narrativa que encuentre más conveniente

de acuerdo a sus necesidades.

31 | P á g i n a

32 | P á g i n a

11.2 DIAGRAMA DE ACTIVIDAD

El diagrama de actividad representa el comportamiento interno de una

operación o caso de uso, bajo la forma de un desarrollo por etapas, agrupadas

secuencialmente.

El propósito del diagrama de actividades es:

Modelar el flujo de tareas.

Modelar las operaciones.

Elemento de un diagrama de actividades

Transición

Estado de acción

Nodos de decisión

Nodos de inicio y fin

Figura 15: Objetos Diagrama de actividad

33 | P á g i n a

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.

Un diagrama de clases está compuesto por los siguientes elementos:

Clase

Es la unidad básica que encapsula toda la información de un Objeto (un objeto

es una instancia de una clase). A través de ella podemos modelar el entorno en

estudio (una Casa, un Auto, una Cuenta Corriente, etc.).

En UML, una clase es representada por un rectángulo 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 prívate, protected o public).

Inferior: Contiene los métodos u operaciones, los cuales son la forma

como interactúa el objeto con su entorno (dependiendo de la visibilidad:

prívate, protected o public).

Ejemplo:

Una Cuenta Corriente que posee como característica: balance, puede realizar

las operaciones de: depositar, girar y balance

El diseño asociado es:

34 | P á g i n a

Figura 17: Ejemplo de Clase 2

35 | P á g i n a

Atributos y Métodos

Atributos: Los atributos o características de una Clase pueden ser de

tres tipos, los que definen el grado de comunicación 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 prívate: Indica que el atributo sólo será accesible desde dentro de

la clase (sólo sus métodos lo pueden accesar).

o protected: Indica que el atributo no será accesible desde fuera de

la clase, pero si podrá ser accesado por métodos de la clase

además de las subclases que se deriven.

Métodos: Los métodos u operaciones de una clase son la forma en

cómo ésta interactúa con su entorno, éstos pueden tener las

características:

o public: Indica que el método será visible tanto dentro como fuera

de la clase, es decir, es accesible desde todos lados.

o Prívate: Indica que el método sólo será accesible desde dentro

de la clase (sólo otros métodos de la clase lo pueden accesar).

o protected: Indica que el método no será accesible desde fuera de

la clase, pero si podrá ser llamado por métodos de la clase

además de métodos de las subclases que se deriven.

Relaciones entre Clases

Una vez definido el concepto de Clase, es necesario explicar cómo se pueden

interrelacionar dos o más clases.

Antes es necesario explicar el concepto de cardinalidad1 de relaciones: En

UML, la cardinalidad de las relaciones indica el grado y nivel de dependencia,

se anotan en cada extremo de la relación y éstas pueden ser:

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

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

1 Cardinalidad: indica el número o cantidad de elementos de un conjunto, sea esta cantidad finita o infinita

36 | P á g i n a

http://es.wikipedia.org/wiki/Conjunto

http://es.wikipedia.org/wiki/N%C3%BAmero

número fijo: m (m denota el número).

Asociación:

La relación entre clases conocida como asociación, permite asociar objetos que

colaboran entre sí. Cabe destacar que no es una relación fuerte, es decir, el

tiempo de vida de un objeto no depende del otro.

Ejemplo:

Figura 18: Objetos Relación 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

37 | P á g i n a

12 DIAGRAMA ENTIDAD RELACIÓN DE BASE DE DATOS

Un diagrama o modelo entidad relación, es una herramienta que permite

representar las entidades relevantes de un sistema de información así como

sus interrelaciones1 y propiedades.

El modelo de datos entidad relación está basado en una percepción del mundo

real que consta de una colección de objetos básicos, llamados entidades, y de

relaciones entre esos objetos.

Entidad

Representa una “cosa” u "objeto" del mundo real con existencia independiente,

es decir, se diferencia unívocamente 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 automóvil. (Aunque sean de la misma marca, el mismo modelo,...,

tendrán atributos diferentes, por ejemplo, el número de chasis).

Una casa (Aunque sea exactamente igual a otra, aún se diferenciará en

su dirección).

Una entidad puede ser un objeto con existencia física 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 características o atributos.

Por ejemplo, la entidad Persona las características: Nombre, Apellido, Género,

Estatura, Peso, Fecha de nacimiento.

Atributos

Los atributos son las características que definen o identifican a una entidad.

Estas pueden ser muchas, y el diseñador sólo utiliza o implementa las que

1 Interrelaciones: Que recíprocamente se hace entre dos o más personas, animales o cosas.

38 | P á g i n a

http://es.wikipedia.org/wiki/Sistema_de_informaci%C3%B3n

considere más relevantes. Los atributos son las propiedades que describen a

cada entidad en un conjunto de entidades.

En un conjunto de entidades del mismo tipo, cada entidad tiene valores

específicos asignados para cada uno de sus atributos, de esta forma, es

posible su identificación unívoca.

Ejemplos:

A la colección de entidades «alumnos», con el siguiente conjunto de atributos

en común, (id, nombre, edad, semestre), pertenecen las entidades:

(1, Sofía, 38 años, 2)

(2, Josefa, 19 años, 5)

(3, Carlos, 20 años, 2)

Relación

Una relación es una asociación o relación matemática entre varias entidades.

Las relaciones también se nombran. Se representan en el diagrama E-R

mediante líneas entre las entidades. Cada entidad interviene en una relación

con una determinada cardinalidad. La cardinalidad corresponde al número de

instancias o elementos de una entidad que pueden asociarse a un elemento de

la otra entidad relacionada.

El tipo de relación se define tomando los máximos de las cardinalidades que

intervienen en la relación. Hay cuatro tipos posibles:

1. Una a una (1:1). En este tipo de relación, una vez fijado un elemento de

una entidad se conoce la otra. Ejemplo: nación y capital

2. Una a muchas (1: n). Ejemplo: cliente y pedidos

3. Muchas a una (n: 1). Simetría respecto al tipo anterior según el punto de

visto de una u otra entidad

4. Muchas a muchas (n: n). Ejemplo: personas y viviendas

Notación de Barker

La notación de Barker se basa en que una entidad es un objeto de importancia

que contiene la información que se necesita saber; una entidad es

39 | P á g i n a

representada de manera diagramática por un rectángulo con las esquinas

redondeadas con nombre; el nombre debe ser singular y en mayúscula.

Cada entidad debe ser única y cada instancia también debe ser identificable de

manera única.

Las asociaciones tienen dos terminales, cada una debe tener la cardinalidad

que se refiere a cuántos y la opcionalidad que se refiere si una instancia es

opcional u obligatoria. La terminación similar a una pata de gallo representa

muchos, la terminación lineal representa uno, la opcionalidad continua significa

que es obligatoria y la opcionalidad discontinua significa que es opcional.

Figura 20: Ejemplo de una relación según notación 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 MÁS

instancias de la entidad1

Cabe destacar que la notación de Barker se ha malentendido en cuanto a la

interpretación de la cardinalidad y opcionalidad. La interpretación correcta es la

mostrada anteriormente; esto significa que en una notación de cardinalidad

mínima y máxima para una entidad la opcionalidad se interpreta al contrario

como se muestra a continuación:

Cada instancia de la entidad1 DEBE (1) estar asociada con UNA Y

SOLAMENTE UNA (1) instancia de la entidad2. Esto significa que la

cardinalidad explícita de la entidad2 debe interpretarse como (1 : 1)

Cada instancia de la entidad2 PUEDE (0) estar asociada con UNA O

MÁS (n) instancias de la entidad1. Esto significa que la cardinalidad

explícita de la entidad1 debe interpretarse como (0 : n)

40 | P á g i n a

Por tanto, la interpretación de esta notación debe hacerse, por un lado, leyendo

de izquierda a derecha la opcionalidad y cardinalidad respectivamente para

interpretar la cardinalidad explícita de la entidad2, y por otro lado, se debe leer

de derecha a izquierda la opcionalidad y cardinalidad respectivamente para

interpretar la cardinalidad explícita de la entidad1. En conclusión la

interpretación cruzada de la cardinalidad y de la opcionalidad de esta notación

presenta una inconsistencia que plantea una barrera cognitiva e induce a error.

41 | P á g i n a

13 FACTIBILIDAD Y MEDIOS

13.1 FACILIDADES PARA ABORDAR EL TEMA

La clínica Uromed ha abierto sus puertas para el desarrollo del sistema,

brindando acceso a información privilegiada acerca de sus pacientes. Además

ha puesto a un médico a cargo de la realización de este proyecto, quien es el

encargado de enseñar el negocio y de poner a disposición de los ingenieros de

software la información necesaria para poder realizar un proyecto de calidad.

13.2 DIFICULTADES PARA ABORDAR EL TEMA

Una limitación para el proyecto, es que los clientes de Uromed no acepten que

su información personal esté en un sistema informático, lo cual complicaría la

situación, ya que se tendría que trabajar en base a supuestos, lo que

claramente no permitirá ver resultados y los aportes del sistema hasta que esté

implementado.

Una segunda limitación es el rechazo o resistencia al cambio por parte de los

usuarios (médicos) del nuevo sistema, ya que tendrán 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 TÉCNICA

Para el desarrollo del sistema se realizó una evaluación de los conocimientos

de programación de los integrantes del grupo y una evaluación tecnológica de

las herramientas disponibles, este estudio tuvo como fin obtener información de

los componentes con los que se contará al momento de desarrollar el proyecto.

De acuerdo a las tecnologías que son necesarias para el desarrollo en cuanto a

hardware, se debe contar con un servidor que posea los siguientes

requerimientos mínimos:

Windows Server 2003 o superior

Internet Information Services 6.0 o superior

Soporte Microsoft .Net Framework 2.0 o superior

42 | P á g i n a

Soporte Microsoft SQL Server 2005 o superior

Alta velocidad de transferencia de información

Espacio mínimo de 5gb de disco duro

En cuanto a computadores, los médicos deberán contar con acceso a internet.

De acuerdo la información obtenida, se llegó a la conclusión de que la clínica

no deberá incurrir en gastos por equipos personales para los médicos, ya que

se cuenta con este recurso. Por otra parte se contrató un hosting1(ILIHOST) de

prueba, con el cual se realizarán todas las evaluaciones necesarias para la

puesta en marcha del sistema.

13.4 FACTIBILIDAD ECONÓMICA

Para poder calcular la factibilidad económica del presente proyecto se utilizará

el método de valor actual neto (VAN), el cual permitirá determinar la

rentabilidad del proyecto.

La fórmula que se utilizará para calcular el VAN será:

Dónde:

Vt: flujos de caja en cada periodo

I0: representa el valor del reembolso inicial del proyecto

N: es el número de periodos considerados

K: el tipo de interés aplicado

De esta forma si el VAN2 del sistema toma un valor = 0, K pasa a tomar el

nombre de TIR3 . Es decir el van del proyecto puede tomar 3 valores:

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

inversión).

1Es el servicio que provee a los usuarios de Internet un sistema para poder almacenar información, imágenes, vídeo, o cualquier contenido accesible vía web.2Valor Actual Neto3 Tasa Interna de retorno: “rentabilidad del proyecto”

43 | P á g i n a

http://es.wikipedia.org/wiki/Internet

http://es.wikipedia.org/wiki/Usuario_(inform%C3%A1tica)

Si VAN < 0 significa que las ganancias son menores a inversión.

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 implementación del sistema, la clínica será la encargada de asumir los

costos tanto de hosting como dominio. Los encargados de la contratación de

los servicios de hosting y dominio serán 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

caída.

Para efectos de cálculo, se estima que la vida útil será de unos 6 años, por otra

parte Uromed se ahorrará por concepto de impresión de documentos, hojas,

tinta y bodegas para almacenar sus documentos, aproximadamente 140 mil

pesos al año, se estima un rendimiento mínimo del sistema de un 7%

(rentabilidad nominal anual del promedio ponderado de inversiones en renta

fija).

VAN=−93.000+ 140.000(1+0.07 )

+ 140.000

(1+0.07 )2+ 140.000

(1+0.07 )3+ 140.000

(1+0.07 )4+ 140.000

(1+0.07 )5+ 140.000

(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, además se cuenta con el respaldo de la

clínica, lo que implica que Uromed se muestra muy interesado por el sistema,

es decir los usuarios finales no están reacios al cambio, facilitando de gran

manera el llevar a cabo la migración del sistema actual al nuevo sistema de

administración y prevención.

44 | P á g i n a

13.6 FACTIBILIDAD 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 carácter personal en registros o bancos de

datos por organismos públicos 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 jurídico. 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 creación de la obra, adquieren los autores

de obras de la inteligencia en los dominios literarios, artísticos y

científicos, cualquiera que sea su forma de expresión, 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.

45 | P á g i n a

14. PROCESO DE DESARROLLO DE SOFTWARE

14.1 FASE DE EXPLORACIÓN

Se realizaron diversas reuniones con el Médico Cirujano Nelson Orellana, en

las cuales se describieron los distintos requerimientos de la Clínica que deben

ser considerados en el proyecto.

A continuación de describen las “historias de usuario” resultantes de esta fase.

14.1.1 Historia de Usuario 1: Requerimientos generales

En la primera reunión se establecen los alcances generales, ya que el médico

no tenía claro todos los requerimientos para el desarrollo del software. El

resultado de la reunión es la primera historia de usuario, la cual entrega una

visión general de las expectativas relacionadas al desarrollo del sistema.

• Ingenieros: Entonces Sr. Orellana, ¿cuáles son los aspectos generales que

requiere sean administrados por un software?

• Médico Orellana: Miren, a rasgos generales, el sistema debe considerar los

ítems tipos de cirugía e imágenes, me refiero a radiografías. Antes del

diagnóstico de los pacientes, nos interesan los antecedentes y la

sintomatología, también 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 médicos,

sino que también por secretarias, químicos farmacéuticos entre otros, los

cuales son encargadas de buscar información 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 reunión con el médico se profundizan algunos temas a

considerar en el software, detallando síntomas, patologías, tratamientos

previos, enfermedades y sus tipificaciones

46 | P á g i n a

• Ingenieros: En la reunión anterior alcanzamos a revisar los antecedentes

generales que debemos conocer para iniciar el desarrollo del software

• Médico Orellana: Para que se hagan una idea, la medicina consta de lo

siguiente: cuando tú tienes un paciente tienes una anamnesis próxima, que

corresponde a los síntomas, 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 hipertensión, diabetes u otra.

Se realizan exámenes físicos para determinar, por ejemplo, si el paciente

tiene fiebre o tiene el vaso grande.

En base a la anamnesis próxima y la remota, se hace un diagnóstico del

paciente y se define el tratamiento, que puede ser médico o querúbico.

Luego, dependiendo de la patología, se controla la evolución del paciente

para ver cómo está el tratamiento en el tiempo.

Entonces se debe tener “pantallas o planillas” que incluyan datos

demográficos, anamnesis próxima, anamnesis remota, examen físico,

diagnóstico, tratamiento, evolución

Se debe tener sub-ítems, me refiero a cómo 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 día <5 [ ] >5[ ] 1 cajetilla[x] y así”

“si tiene alguna operación y alguna descripción de esta”

“antecedentes familiares de alguna patología, por ejemplo si el papa

sufrió de cáncer, etc.”

Ahora esto es súper a rasgos generales, para ver el detalle debo

mostrarles fichas clínicas para poder ver el detalle de cómo se registran los

datos actualmente en la clínica, ya que es mucho más complejo de lo que

47 | P á g i n a

acabo de decirles.

14.1.3 Historia de Usuario 3: Fichas médicas

En esta reunión se abordaron temas relacionados al acceso oportuno y eficaz

de la información de pacientes, a través de buscadores y filtros, considerando

diversas características.

• 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 información?

• Médico Orellana: Por supuesto, se requiere filtrar la información, por

ejemplo, en ocasiones se necesita identificar todas las mujeres que sufren

de incontinencia urinaria, cáncer, etc. Del mismo modo, se necesita

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

cáncer renal, cuántos son hombres, cuántas son mujeres, cuántos de estos

cánceres se operaron, y así buscar por distintos motivos y poder tener la

información clara y con rapidez. Actualmente tenemos fichas y para buscar

cada ítem, por ejemplo cada persona con cáncer, es tedioso y requiere de

un día entero de la secretaria

• Ingenieros: Con esta información tenemos una visión general de lo que

requiere la Clínica y podremos identificar aquellos aspectos clave que

deben ser abordados en detalle para diseñar un software de calidad

14.1.4 Historia de Usuario 4: Alertas tempranas

En esta reunión se discutió acerca de la necesidad de un sistema de alertas

tempranas, que permita al médico conocer con rapidez aquellas enfermedades

que se presentan con mayor frecuencia en los pacientes. El objetivo es

identificar, a través de información estadística, aquellos factores comunes que

se presentan o influyen directamente en una enfermedad.

• Ingenieros: Sr. Orellana, considerando información existente, ¿qué tan

factible es considerar patrones que permitan establecer acciones

preventivas, a través alertas tempranas, a fin de diagnosticar

48 | P á g i n a

tempranamente potenciales enfermedades?

• Médico Orellana : Sería un gran aporte contar con un sistema de alertas

que identifique tendencias en las enfermedades que se presentan en los

pacientes, en base a su edad, diagnostico, exámenes, etc. Esto ayudaría a

realizar investigaciones que tengan que ver con las enfermedades que

están afectando a los pacientes

• Ingenieros: Se entiende, pero para realizar esto se necesitan parámetros

que indiquen cuáles 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 años

padezcan o son propensos a tener cáncer de próstata, por lo cual es

recomendable que a esa edad se realicen un chequeo médico, 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 información que le

solicitamos anteriormente, sobre los factores influyentes y rangos normales

• Medico Orellana: Está bien, documentaré esa información para poder

hacérselas llegar

14.1.5 Historia de Usuario 5: Interfaz del programa y seguridad

En la quinta reunión con el médico, se conversó sobre la interfaz y la

distribución de la información, en búsqueda de un software amigable al usuario

e intuitivo, facilitando de esta manera la disposición de los funcionarios a utilizar

el software.

Otro factor considerado como fundamental es la seguridad y la capacidad de

auditoría del software. Cada médico debe contar con una cuenta de usuario y

se debe registrar todos cambios que se realicen a la información almacenada.

• Ingenieros: Sr. Orellana cuéntenos cuáles son los requerimientos

relacionados a la interfaz de usuario del software

• Médico Orellana: Principalmente el sistema debe ser intuitivo, porque

49 | P á g i n a

entenderán que tenemos toda clase de usuarios y algunos doctores no son

muy amigos con la tecnología, es por esto que el sistema debe ser muy

visual, quizás con colores o letras y botones que ellos puedan distinguir

fácilmente

• Ingenieros: Entonces para ustedes es fundamental tener una interfaz clara

y simple

• Médico Orellana: Si, bueno eso sobre la interfaz, ahora también es

necesario tener una forma de control de usuarios, ya que no cualquier

persona puede realizar cambios en los pacientes, en los exámenes o las

horas con los distintos médicos

• Ingenieros: Claro, el sistema será capaz de reconocer a los distintos

usuarios, de esta forma cualquier cambio quedará registrado.

14.2 FASE DE PLANIFICACIÓN

Una vez conocidos los requisitos del sistema se procede a identificarlos y

dividirlos en dos categorías principales: funcionales y no-funcionales.

Los requisitos no funcionales son aquellos que describen los aspectos que el

sistema debe tomar y no tienen una relación 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 interacción 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 descripción, desencadenando el desarrollo de los casos de uso.

Los casos de uso son una abstracción que describen un conjunto de

escenarios posibles dentro de los cuales el usuario se puede desenvolver.

A continuación se detallan los requisitos del sistema, con su respectiva historia

de usuario (H.U) asociada, tipo de requisito, explicación y prioridad establecida.

50 | P á g i n a

Se definirán los siguientes niveles de prioridad:

1: Máxima Prioridad

2: Alta Prioridad

3: Media Prioridad

4: Baja Prioridad

5: Muy Baja Prioridad

51 | P á g i n a

Tabla de requisitos

Tabla 1: Requisitos funcionales y no funcionales

# H.Usuario Tipo de requisito Explicación Prioridad

1 H1Requisito Funcional

Buscar, agregar, eliminar y editar Pacientes.

1


Buscar, agregar, eliminar y editar Exámenes e Imagenología.

2


Es necesario poder buscar, agregar y eliminar Resultados de Examen.

3


Buscar, agregar, editar y eliminar Síntomas.

1


Buscar, agregar, editar y eliminar Secretarias.

4


Buscar, agregar, editar y eliminar Personal(químicos)

4


Buscar, agregar, editar y eliminar Médicos.

2


Agregar, editar y eliminar Medicamentos.

3


Buscar, agregar, eliminar y editar Procedimientos.

2


Agregar, Buscar, editar y eliminar Diagnósticos.

3


Buscar, agregar, editar y eliminar Tratamientos.

3


Buscar, agregar, editar y eliminar Tipos de Enfermedades.

2


Buscar, agregar, editar y eliminar datos previos del Paciente.

2


Buscar, agregar, editar y eliminar Historial Médico.

3


Que el sistema alerte anomalías en los Pacientes

1

16 H5Requisito no Funcional

Interfaz simple 5


Seguridad del sistema 5


Filtro de información de las Enfermedades

5


Filtro de Pacientes 5

52 | P á g i n a

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

lógico, los modelos de clases y el modelo de datos físico, 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 Iteración 1

Análisis

Caso de Uso Administración de Categorías de Exámenes

Figura 21: Diagrama Caso de Uso Administración de Categorías de Exámenes

Tabla 2: Narrativa Caso de Uso Administración de Categorías de Exámenes

Caso de Uso: Administración de Categorías de Exámenes (Requisito N°2)

Actor: Médico Administrador


1) El Médico Administrador lista las Categorías de Exámenes

2) El Médico Administrador agrega una nueva Categoría de Examen

2.1) Si el registro existe se informa del problema y no se permite completar la acción

2.2) Si los datos ingresados no son válidos o falta información se informa del problema y no se permite completar la

53 | P á g i n a

acción

3) El Médico Administrador elimina una Categoría de Examen

3.1) Si el registro está asociado a un Examen existente se informa del problema y no se permite completar la acción

4) El Médico Administrador edita una Categoría de Examen

5) Se repiten los pasos 2), 3) y 4 hasta que el Médico Administrador no desee realizar más operaciones

Caso de Uso Administración de Medicamentos

Figura 22: Diagrama Caso de Uso Administración de Medicamentos

Tabla 3: Narrativa Caso de Uso Administración de Medicamentos

Caso de Uso: Administración de Medicamentos (Requisito N°8)

Actor: Químico Farmacéutico


1) El Químico Farmacéutico lista los Medicamentos

2) El Químico Farmacéutico agrega un nuevo Medicamento


2.2) Si los datos ingresados no son válidos o falta información se informa del problema y no se permite completar la acción

3) El Químico Farmaceútico elimina un Medicamento

3.1) Si el registro está asociado a una Medicación existente se informa del problema y no se permite completar la

54 | P á g i n a

acción

4) El Químico edita un Medicamento

5) Se repiten los pasos 2), 3) y 4) hasta que el Químico Farmacéutico no desee realizar más operaciones

Caso de Uso Administración de Tipos de Enfermedad

Figura 23: Diagrama Caso de Uso Administración de Tipos de Enfermedad

Tabla 4: Narrativa Caso de Uso Administración de Tipos de Enfermedad

Caso de Uso: Administración de Tipos de Enfermedad (Requisito N°12)



1) El Médico Administrador lista los Tipos de Enfermedad

2) El Médico Administrador agrega un nuevo Tipo de Enfermedad



3) El Médico 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 acción

4) El Médico Administrador edita un Tipo Enfermedad

55 | P á g i n a

5) Se repiten los pasos 2), 3) y 4) hasta que el Médico Administrador no desee realizar más operaciones

Caso de Uso Administración de Especialidades

Figura 2421: Diagrama Caso de Uso Administración de Especialidades

Tabla 5: Narrativa Caso de Uso Administración de Médicos

Caso de Uso: Administración de Especialidades (Requisito N°7)



1) El Médico Administrador lista las Especialidades

2) El Médico Administrador agrega una nueva Especialidad



3) El Médico Administrador elimina una Especialidad

3.1) Si el registro está asociado a un Médico existente se informa del problema y no se permite completar la acción

4) El Médico Administrador edita una Especialidad

5) Se repiten los pasos 2) ,3) y 4) hasta que el Administrador no desee realizar más operaciones

56 | P á g i n a

Caso de Uso Administración de Médicos

Figura 25: Diagrama Caso de Uso Administración de Médicos

Tabla 6: Narrativa Caso de Uso Administración de Médicos

Caso de Uso: Administración de Médicos (Requisito N°7)



1) El Médico Administrador lista los Médicos

2) El Médico Administrador agrega un nuevo Médico



3) El Médico Administrador elimina un Médico

3.1) Si el registro está asociado a un Historial Médico existente se informa del problema y no se permite completar la acción

4) El Médico Administrador edita un Médico

5) Se repiten los pasos 2) ,3) y 4) hasta que el Médico Administrador no desee realizar más operaciones

57 | P á g i n a

Caso de Uso Administración de Pacientes

Figura 2622: Diagrama Caso de Uso Administración de Pacientes

Tabla 7: Narrativa Caso de Uso Administración de Pacientes

Caso de Uso: Administración de Pacientes (Requisito N°1, N°13 y N°19)

Actor: Secretaria


1) La Secretaria lista los Pacientes

2) La Secretaria agrega un nuevo Paciente



3) La Secretaria elimina un Paciente 3.1) Si el registro está asociado a un Historial Médico existente se informa del problema y no se permite completar la acción

4) La Secretaria edita un Paciente

5) Se repiten los pasos 2) ,3) y 4) hasta que la Secretaria no desee realizar más operaciones

58 | P á g i n a

Caso de Uso Administración de Síntomas

Figura 2723: Diagrama Caso de Uso Administración de Síntomas

Tabla 824: Narrativa Caso de Uso Administración de Síntomas

Caso de Uso: Administración de Síntomas (Requisito N°4)



1) El Médico Administrador lista los Síntomas

2) El Médico Administrador agrega un nuevo Síntoma



3) El Médico Administrador elimina un Síntoma

3.1) Si el registro está asociado a una Enfermedad y/o Historial Médico existente se informa del problema y no se permite completar la acción

4) El Médico Administrador edita un Síntoma


59 | P á g i n a

Caso de Uso Administración de Tratamientos

Figura 28: Diagrama Caso de Uso Administración de Tratamientos

Tabla 925: Narrativa Caso de Uso Administración de Tratamientos

Caso de Uso: Administración de Tratamientos (Requisito N°11)

Actor: Médico


1) El Médico lista los Tratamientos

2) El Médico agrega un nuevo Tratamiento



3) El Médico elimina un Tratamiento 3.1) Si el registro está asociado a un Procedimiento existente se informa del problema y no se permite completar la acción

4) El Médico edita un Tratamiento

5) Se repiten los pasos 2) ,3) y 4) hasta que el Médico no desee realizar más operaciones

60 | P á g i n a

Diagrama de Actividad Administración de Categorías de Exámenes

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

realizar el médico para la administración de Categoría Exámenes.

Figura 29: Diagrama de Actividad Administración de Categorías de Exámenes

61 | P á g i n a

Diagrama de Actividad Administración de Medicamentos

El siguiente Diagrama de Actividades refleja como el Químico Farmacéutico

puede administrar los Medicamentos existentes, éste podrá agregar, editar y

eliminar, siempre que se cumplan las restricciones establecidas.

Figura 30: Diagrama de Actividad Administración de Medicamentos

62 | P á g i n a

Diagrama de Actividad Administración de Tipos de Enfermedades

En el siguiente Diagrama de Actividad se puede ver como un médico puede

administrar los Tipos de Enfermedad existente en el sistema, permitiéndole

realizar acciones como: agregar, editar, eliminar y listar.

Como se ve en la imagen, ciertas actividades dependen de una serie de

restricciones que el Médico 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 Administración de Enfermedades

63 | P á g i n a

Diagrama de Actividad Administración de Especialidades

El siguiente Diagrama de Actividades detalla el flujo de actividades relacionado

a la administración 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

Médico Administrador.

Figura 32: Diagrama de Actividad Administración de Especialidades

64 | P á g i n a

Diagrama de Actividad Administración de Médicos

El siguiente Diagrama de Actividades detalla el flujo de actividades relacionado

a la administración de Médicos, considerando la posibilidad de agregar nuevos

Médicos, eliminar y editar Médicos existentes. Un Médico no puede realizar

estas operaciones a menos que tenga los permisos de Administrador.

Figura 33: Diagrama de Actividad Administración de Médicos

65 | P á g i n a

Diagrama de Actividad Administración 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 Administración de Pacientes

66 | P á g i n a

Diagrama de Actividad Administración de Síntomas

El siguiente Diagrama de Actividades refleja como el Médico administra los

Síntomas de los pacientes, pudiendo agregar nuevos Síntomas, editar y

eliminar los Síntomas existentes.

Figura 35: Diagrama de Actividad Administración de Síntomas

67 | P á g i n a

Diagrama de Actividad Administración de Tratamientos

El siguiente Diagrama de Actividades refleja como el Médico administra los

Tratamientos, agregando nuevos registros y editando y/o eliminando según

corresponda.

Figura 36: Diagrama de Actividad Administración de Tratamientos

68 | P á g i n a

Modelo Lógico (Conceptual) de Base de Datos

Figura 37: Modelo Lógico (Conceptual) de Base de Datos Iteración 1

69 | P á g i n a

Diseño

Arquitectura de Hardware

Tanto la aplicación como la base de datos estarán 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 distribución de los componentes en el servidor es la siguiente:

Figura 38: Arquitectura de Hardware

70 | P á g i n a

71 | P á g i n a

Arquitectura de Software

Tal como se mencionó anteriormente, para la construcción de la aplicación se

utilizarán los patrones de diseño MVC (Model View Controller) y DAO (Data

AccesObject).

La distribución de los componentes de cada patrón es la siguiente:

Figura 39: Arquitectura de Software

72 | P á g i n a

Modelo de Clases

Figura 4026: Modelo de Clases Iteración 1

73 | P á g i n a

Modelo Físico de Base de Datos

Figura 41: Modelo Físico de Base de Datos Iteración 1

74 | P á g i n a

Diccionario de datos

Nombre Entidad: Paciente

Descripción: Contiene los pacientes de la clínica

Field Tipo Descripción

IdPaciente Int PK 0 Código único del paciente

Previsión Varchar ' ' Nombre de la Previsión

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

Teléfono Varchar ' ' Teléfono del paciente

CorreoElectronico Varchar ' ' Mail del paciente

CodigoArea Varchar 'Código de área de la ciudad del paciente

TelefonoMovil Int 0 Celular del paciente

FechaRegistro DateTime '01/01/1900' Fecha de registro del paciente

Usuario Varchar ' ' Usuario de creación del paciente

Estado Tinyint 1 Estados: 1 = Vigente, 2 = No Vigente

Nombre Entidad:

Síntoma

Descripción: Contiene los síntomas


IdSintoma Int PK 0 Código único del síntoma

Nombre Varchar ' Nombre del síntoma

Descripción Varchar ' ' Descripción del síntoma

FechaCreacion DateTime '01/01/1900' Fecha de creación del síntoma

Usuario Varchar ' ' Usuario de creación del síntoma


75 | P á g i n a

Nombre Entidad: Tipo Enfermedad

Descripción: Contiene los tipos de enfermedad


IdTipoEnfermedad Int PK 0 Código único del tipo de enfermedad

Descripción Varchar ' ' Descripción del tipo de enfermedad

Nombre Varchar ' ' Nombre del tipo de enfermedad


Usuario Varchar ' 'Usuario de creación del tipo de enfermedad

FechaCreacion DateTime '01/01/1900'Fecha de creación del tipo de enfermedad

Nombre Entidad: Medicamento

Descripción: Contiene los medicamentos


IdMedicamento Int PK 0 Código único del medicamento

Descripción Varchar ' ' Descripción del medicamento

Componentes Varchar ' ' Ingredientes del medicamento

FechaCreacion DateTime '01/01/1900' Fecha de creación del medicamento

Usuario Varchar ' ' Uuario de creación del medicamento


Nombre Entidad: Categoría Examen

Descripción: Contiene las categoría de exámenes


IdCaterogiaExamen Int PK 0Código único de la categoría del examen

Nombre Varchar ' ' Nombre del examen

Descripción Varchar ' 'Descripción de la categoría del examen


Usuario Varchar ' ' Usuario de creación de la categoría

FechaCreacion DateTime '01/01/1900' Fecha de creación de la categoría

76 | P á g i n a

Nombre Entidad: Tratamiento

Descripción: Contiene los tratamientos


IdTratamiento Int PK 0 Código único del tratamiento

Nombre Varchar ' ' Nombre del tratamiento

Descripción Varchar ' ' Descripción del tratamiento

Usuario Varchar ' ' Usuario de creación del tratamiento


FechaCreacionDateTime

'01/01/1900' Fecha de creación del tratamiento

Nombre Entidad: Especialidad

Descripción: Contiene las especialidades de los médicos


IdEspecialidad Int PK 0 Código único de la especialidad

Nombre Varchar ' ' Nombre de la especialidad

Descripción Varchar ' ' Descripción de la especialidad

Usuario Varchar ' 'Usuario de creación de la especialidad


FechaCreacion DateTime '01/01/1900' Fecha de creación de la especialidad

Nombre Entidad: Médico

Descripción: Contiene los médicos de la clínica


IdMedico Int PK 0 Código único del médico

IdEspecialidad Int FK 0 Llave foránea de especialidad

Rut Varchar ' ' Rut del médico

Cargo Varchar ' 'Cargo que posee el Medico en la Clínica

Nombres Varchar ' ' Nombres del médico

ApellidoPaterno Varchar ' ' Apellido del médico

ApellidoMaterno Varchar ' ' Apellido Materno del médico

Sexo Varchar ' ' Sexo del médico

FechaNacmiento DateTime '01/01/1900' Fecha de nacimiento del médico

Nacionalidad Varchar ' ' Nacionalidad del médico

77 | P á g i n a

Domicilio Varchar ' ' Domicilio del médico

Teléfono Varchar ' ' Teléfono del médico

CorreoElectronico

Varchar ' ' Mail del médico

CodigoArea Varchar ' Código de área de la ciudad del médico

FechaRegistro DateTime '01/01/1900' Fecha de creación del médico

Estado Tinyint 1 Estados: 1 = Vigente, 2= No Vigente

Usuario Varchar ' ' Usuario de creación del médico

Password Varchar ' ' Clave de ingreso al sistema del médico

Construcción

A continuación se muestra la distribución de los componentes en el IDE de

programación Visual Studio 2012.

Figura 42: Modelo y Controlador de Sistema

78 | 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,

también 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

79 | P á g i n a

Ingreso, edición y eliminación de Síntomas

Figura 44: Ingreso, edición y eliminación de Síntomas

80 | P á g i n a

Ingreso, edición y eliminación de Médicos

Figura 45: Ingreso, edición y eliminación de Médicos

81 | P á g i n a

Pruebas

Para las pruebas del sistema se utilizan casos de prueba. En Ingeniería de

Software los casos de prueba son un conjunto de condiciones bajo las cuáles

un desarrollador determina el buen funcionamiento de un sistema informático.

Con el propósito 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 Iteración 1

Caso de prueba

Descripción del caso

Pre requisitos Resultado esperado

Estado

Categoría Examen

Ingreso, edición y eliminación de Categorías de Exámenes

Mantenedor de Categorías de Exámenes, Tabla de Exámanes

(Concluido)

Correcto ingreso, edición y eliminación de Categoría de Exámenes.

Cumplido

Medicamento Ingreso, edición y eliminación de Medicamentos

Mantenedor de Medicamentos, Tabla Medicación

(Concluido)

Correcto ingreso, edición y eliminación de Medicamentos

Cumplido

Tipo Enfermedad

Ingreso, edición y eliminación de Tipos de Enfermedades

Mantenedor de Tipos de Enfermedades, Tabla de Enfermedades

(Concluido)

Correcto ingreso, edición y eliminación de Tipos de Enfermedad.

Cumplido

Especialidad Ingreso, edición y eliminación de Especialidades

Mantenedor de Especialidades, Tabla de Médicos

(Concluido)

Correcto ingreso, edición y eliminación de Especialidades

Cumplido

Médico Ingreso, edición y eliminación de Médicos

Mantenedor de Médicos, Tabla de Historiales Médicos

(Concluido)

Correcto ingreso, edición y eliminación de Médicos.

Cumplido

Paciente Ingreso, edición y eliminación de Pacientes

Mantenedor de Pacientes, Tabla de Historiales Médicos

Correcto ingreso, edición y eliminación de Pacientes.

Cumplido

82 | P á g i n a

http://es.wikipedia.org/wiki/Ingenier%C3%ADa_del_software

(Concluido)

Síntoma Ingreso, edición y eliminación de Síntomas

Mantenedor de Síntomas, Tabla de Enfermedades, Tabla de Historiales Médicos

(Concluido)

Correcto ingreso, edición y eliminación de Síntomas.

Cumplido

Tratamiento Ingreso, edición y eliminación de Tratamientos

Mantenedor de Tratamientos, Tabla de Procedimientos

(Concluido)

Correcta ingreso, edicion y eliminación de tratamientos.

Cumplido

83 | P á g i n a

14.2.2 Iteración 2

Análisis

Caso de Uso Administración de Medicaciones

Figura 46: Diagrama Caso de Uso Administración de Medicaciones

Tabla 10: Narrativa Caso de Uso Administración de Medicaciones

Caso de Uso: Administración de Medicaciones (Requisito N°9)



1) El Médico Administrador lista las medicaciones

2) El Médico Administrador agrega una nueva medicación

2.1) Si el registro existe se informa del problema y no se permite completar la acción.


3) El Médico Administrador elimina una medicación


4) El Médico Administrador edita una medicación


84 | P á g i n a

Agrega Medicación

Elimina Medicación

EditaMedicación

Médico Administrador

ListaMedicación

Caso de Uso Administración de Procedimientos

Figura 47: Diagrama Caso de Uso Administración de Procedimientos

Tabla 11: Narrativa Caso de Uso Administración de Procedimientos

Caso de Uso: Administración de Procedimientos (Requisito N°9)



1) El Médico Administrador lista los Procedimientos

2) El Médico Administrador agrega un nuevo Procedimiento



3) El Médico Administrador elimina un Procedimiento


4) El Médico Administrador edita un Procedimiento


85 | P á g i n a

Caso de Uso Administración de Exámenes Generales

Figura 48: Diagrama Caso de Uso Administración de Exámenes Generales

Tabla 12: Narrativa Caso de Uso Administración de Exámenes Generales

Caso de Uso: Exámenes Generales (Requisito N°2)



1) El Médico Administrador lista los Exámenes Generales

2) El Médico Administrador agrega un nuevo Examen General



3) El Médico Administrador elimina un Examen General

3.1) Si el registro está asociado a un Examen Específico existente se informa del problema y no se permite completar la acción

4) El Médico Administrador edita un Examen General

5) Se repiten los pasos 2) ,3) y 4) hasta que el Médico Administrador no desee realizar más operaciones.

86 | P á g i n a

Caso de Uso Administración de Exámenes Específicos

Figura 49: Diagrama Caso de Uso Administración de Exámenes Específicos

Tabla 13: Narrativa Caso de Uso Administración de Exámenes Específicos

Caso de Uso: Exámenes Específicos (Requisito N°2)



1) El Médico Administrador lista los Exámenes Específicos

2) El Médico Administrador agrega un nuevo Examen Específico



3) El Médico Administrador elimina un Examen Específico

3.1) Si el registro está asociado a una Enfermedad existente se informa del problema y no se permite completar la acción

4) El Médico Administrador edita un Examen Específico

5) Se repiten los pasos 2) ,3) y 4) hasta que el Médico Administrador no desee realizar más operaciones.

87 | P á g i n a

Diagrama de Actividad Administración de Medicaciones

En el siguiente Diagrama de Actividad se ve como el Médico Administrador

puede listar, crear, editar y eliminar Medicaciones.

Figura 50: Diagrama de Actividad Administración de Medicaciones

88 | P á g i n a

Diagrama de Actividad Administración de Procedimientos


puede listar, crear, editar y eliminar Procedimientos.

Figura 51: Diagrama de Actividad Administración de Procedimientos.

89 | P á g i n a

Diagrama de Actividad Administración de Exámenes Generales


puede listar, crear, editar y eliminar Exámenes Generales.

Figura 52: Diagrama de Actividad Administración de Exámenes Generales

90 | P á g i n a

Diagrama de Actividad Administración de Exámenes Específicos


puede listar, crear, editar y eliminar Exámenes Específicos.

Figura 53: Diagrama de Actividad Administración de Exámenes Específicos

91 | P á g i n a



92 | P á g i n a


Diseño

Modelo de Clases


93 | P á g i n a




94 | P á g i n a

Diccionario de Datos

Nombre Entidad: Examen General

Descripción: Contiene los exámenes generales


IdExamenGeneral Int PK 0 Código único del examen

idCategoriaExamen Int FK 0Llave foránea de la categoría del examen

Nombre Varchar ' ' Nombre del examen especifico

Descripción Varchar ' ' Descripción del examen

Precio Money 0 Precio del examen

FechaCreacion DateTime '01/01/1900' Fecha creación del examen

Usuario Varchar ' ' Usuario que ingreso el examen


Nombre Entidad: Examen Específico

Descripción:Contiene los exámenes específicos recomendados para las enfermedades


IdExamenEspecífico

Int PK 0 Código único del examen

idExamenGeneral Int FK 0 Llave foránea del examen general

Nombre Varchar ' ' Nombre del examen específico

Descripción Varchar ' ' Descripción del examen

ValorMinimoNormal Integer 0Valor mínimo del examen según su rango normal.

valorMaximoNormal Integer 0Valor máximo del examen según su rango normal.

FechaCreacion DateTime '01/01/1900' Fecha de creación del examen

Usuario Varchar ' ' Usuario de creación del examen


Nombre Entidad: Procedimiento

Descripción:Contiene los procedimientos recomendados para las enfermedades


IdProcedimiento Int PK 0 Código único del procedimiento

IdTratamiento Int FK 0 Llave foránea del tratamiento

95 | P á g i n a

Descripción Varchar ' ' Descripción del procedimiento

Precio Money 0 Precio del procedimiento

Duración Int 0 Duración del procedimiento

Dosis Int 0 Dosis del procedimiento

Frecuencia Int 0Frecuencia con la que se debe realizar el procedimiento

Usuario Varchar ' ' Usuario de creación del procedimiento



'01/01/1900' Fecha de creación del procedimiento

Nombre Entidad: Medicación

Descripción: Contiene las medicaciones recomendadas para las enfermedades


IdMedicacion Int PK 0 Código único de la medicación

IdMedicamento Int FK 0 Id de la llave foránea de medicamento

Dosis Int 0 Dosis de la medicación

Descripción Varchar ' ' Descripción del medicamento

Precio Money 0 Precio del medicamento

Frecuencia Int 0 Frecuencia del medicamento

Duración Int 0Cantidad de días que se debe administrar el medicamento

Usuario Varchar ' ' Usuario de creación de la medicación


FechaCreacion DateTime '01/01/1900' Fecha de creación de la medicación

96 | P á g i n a

Construcción

Maqueta1 Mantenedor de Exámenes Generales

Figura 57: Maqueta Listado de Exámenes Generales

Figura 58: Maqueta Edición de Exámenes Generales

1 Maqueta: Prototipo de pantalla, muestra de cómo se verá el sistema al estar terminado.

97 | P á g i n a

Pruebas


Caso de prueba



Estado

Examen General

Ingreso, edición y eliminación de Exámenes Generales

Mantenedor de Exámenes Generales, Tabla de Exámenes Específicos

(Concluido)

Correcto ingreso, edición y eliminación de Exámenes Generales

Cumplido

Examen Específico

Ingreso, edición y eliminación de Exámenes Específicos

Mantenedor de Exámenes Específicos, Tabla Enfermedades

(Concluido)

Correcto ingreso, edición y eliminación de Exámenes Específicos

Cumplido

Procedimiento Ingreso, edición y eliminación de Procedimientos

Mantenedor de Procedimientos, Tabla de Enfermedades, Tabla de Historiales Médicos

(Concluido)

Correcta ingreso, edicion y eliminación de Procedimientos.

Cumplido

Medicación Ingreso, edición y eliminación de Medicaciones

Mantenedor de Medicamentos, Tabla de Enfermedades, Tabla de Historiales Médicos

(Concluido)

Correcta ingreso, edicion y eliminación de Medicaciones

Cumplido

98 | P á g i n a

14.2.3 Iteración 3

Análisis

Caso de Uso Administración de Enfermedades

Figura 59: Diagrama Caso de Uso Administración de Enfermedades

Tabla 14: Narrativa Caso de Uso Administración de Enfermedades

Caso de Uso: Administración de Enfermedades (Requisito N°18)



1) El Médico Administrador lista las Enfermedades

2) El Médico Administrador agrega una nueva Enfermedad


2.2) Si los datos ingresados no son válidos o falta información se informa del problema y no se permite completar la acción.

3) El Médico Administrador elimina una Enfermedad

3.1) Si el registro está asociado a una Medicación, Procedimiento, Examen Específico y/o Diagnóstico existente se informa del problema y no se permite completar la acción

4) El Médico Administrador edita una Enfermedad


99 | P á g i n a

Agrega Enfermedad

Elimina Enfermedad

EditaEnfermedad

Médico Administrador

ListaEnfermedad

100 | P á g i n a

Caso de Uso Administración de Historiales Médicos

Figura 60: Diagrama Caso de Uso Administración de Historiales Médicos

Tabla 15: Narrativa Caso de Uso Administración de Historiales Médicos

Caso de Uso: Administración de Historiales Médicos (Requisito N°14)

Actor: Médico Administrador, Médico, Secretaria


1) El Médico Administrador, Médico y/o Secretaria listan los Historiales Médicos de un determinado Paciente

2) El Médico agrega un nuevo Historial Médico


2.2) Si los datos ingresados no son válidos o falta información se informa del problema y no se permite completar la acción.

3) El Médico Administrador elimina un Historial Médico.

3.1) Si el registro está asociado a un Diagnóstico y/o Resultado Examen existente se informa del problema y no se permite completar la acción

4) El Médico Administrador edita un historial.

5) Se repiten los pasos 2), 3) y 4) hasta que el Médico Administrador y/o Médico, según corresponda, no deseen realizar más operaciones.

101 | P á g i n a

102 | P á g i n a

Diagrama de Actividad Administración de Enfermedades

En el siguiente Diagrama de Actividad se ve como al Médico Administrador

puede agregar una nueva Enfermedad y, por otra parte, listar, editar y eliminar

Enfermedades existentes.

Figura 61: Diagrama de Actividad Administración de Enfermedades

103 | P á g i n a

Diagrama Actividad Administración de Historiales Médicos

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

permite la administración de Historiales Médicos considerando los roles y

validaciones descritas en la narrativa del caso de uso.

Figura 62: Diagrama de Actividad Administración de Historiales Médicos

104 | P á g i n a



105 | P á g i n a


Diseño

Modelo de Clases


106 | P á g i n a




107 | P á g i n a



Nombre Entidad: Enfermedad

Descripción: Esta tabla contiene las enfermedades del sistema


IdEnfermedad Int PK 0 Código único del enfermedad

IdTipoEnfermedad Int FK 0 Llave foránea de tipo enfermedad

Descripción Varchar ' ' Descripción de la enfermedad

Nombre Varchar ' ' Nombre de la enfermedad

Gravedad Integer 0 Gravedad de la enfermedad


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

Usuario Varchar ' 'Usuario que ingreso la enfermedad en el sistema

Estado Tinyint 1Estados 1 = Confirmado , 2= No Confirmado

Nombre Entidad: Historial Médico

Descripción:Esta tabla los historiales médicos de los pacientes en el sistema.


IdHistorialMedico Int PK 0 Código único del paciente

IdPaciente Int FK 0 Llave foránea de paciente

IdMedico Int FK 0 Llave foránea medico

Descripción Varchar ' ' Descripción del historial


'01/01/1900' fecha de creación del historial

Usuario Varchar ' 'Nombre del usuario que ingreso este historial

Estado Tinyint 1Estados 1 = Vigente , 2= no Vigente

108 | P á g i n a

Nombre Entidad: Enfermedad Síntoma

Descripción:Esta tabla las relaciones de enfermedades con sus respectivos síntomas.


IdEnfermedadSintoma Int PK 0 Código único de la relación

IdEnfermedad Int FK 0 Llave foránea de la enferdad

IdSintoma Int FK 0 Llave foránea del síntoma


'01/01/1900' Fecha de creación de la relación

Usuario Varchar ' ' Usuario de creación de la relación


Nombre Entidad: Historial Médico Síntoma

Descripción: Esta tabla la relacion entre historial medico y sintomas


IdHistorialMedicoSintoma Int PK 0 Código único de la relación

IdHistorialMedico Int FK 0 Llave foránea de historial médico

IdSintoma Int FK 0 Llave foránea del síntoma


'01/01/1900'

Fecha de creación de la relación

Usuario Varchar ' ' Usuario de creación de la relación


109 | P á g i n a

Pruebas


Caso de prueba



Estado

Enfermedad Ingreso, edición y eliminación de Enfermedades

Mantenedor de Enfermedades, Tabla de Medicaciones, Tabla de Procedimientos, Tabla de Exámenes Específicos, Tabla de Diagnósticos, Tabla de Enfermedades Síntomas

(Concluido)

Correcta ingreso, edicion y eliminación de Enfermedades

Cumplido

Historial Médico

Ingreso, edición y eliminación de Historiales Médicos

Mantenedor de Historiales Médicos, Tabla de Diagnóstico, Tabla de Resultados Exámenes y/o Historiales Médicos Sintomas

(Concluido)

Correcta ingreso, edicion y eliminación de Historiales Médicos

Pendiente

110 | P á g i n a

14.2.4 Iteración 4

Análisis

Caso de Uso Administración de Diagnósticos

Figura 66: Diagrama Caso de Uso Administración de Diagnósticos

Tabla 16: Narrativa Caso de Uso Administración de Diagnósticos

Caso de Uso: Administración de Diagnóstico (Requisito N°10)

Actor: Médico


1) El Médico lista los Diagnósticos de un determinado paciente

2) El Médico agrega un nuevo Diagnóstico a un Historial Médico de su autoría

2.1) Si el registro está asociado a un Historial Médico que no fue generado por el Médico se informa del problema y no se permite completar la acción



3) El Médico elimina un Diagnóstico de un Historial Médico de su autoría


4) El Médico edita un Diagnostico de un Historial Médico de su autoría

4.1) Si el registro está asociado a un Historial Médico que no fue generado por el Médico se informa del problema y no se

111 | P á g i n a

permite completar la acción

5) Se repiten los pasos 2), 3) y 4) hasta que el Médico no desee realizar más operaciones

Caso de Uso Administración Resultados de Exámenes

Figura 67: Diagrama Caso de Uso Administración Resultados de Exámenes.

Tabla 17: Narrativa Caso de Uso Administración Resultados de Exámenes.

Caso de Uso: Administración Resultados de Exámenes (Requisito N°3 y N°15)

Actor: Médico


1) El Médico lista los Resultados de Examen de un determinado Paciente

2) El Médico agrega un nuevo Resultado de Examen a un Historial Médico de su autoría




3) El Médico elimina un Resultado de Examen de un Historial Médico de su autoría

3.1) Si el registro está asociado a un Historial Médico que no fue generado por el Médico se informa del problema y

112 | P á g i n a

no se permite completar la acción

4) El Médico edita un Resultado de Examen de un Historial Médico de su autoría


5) Se repetirán los pasos 2), 3) y 4) hasta que el Médico no desee realizar más operaciones

Diagrama de Actividad Administración de Diagnósticos

En el siguiente Diagrama de Actividad se ve como un Médico puede agregar un

nuevo Diagnóstico, además de listar, editar y eliminar los Diagnósticos

existentes.

Figura 68: Diagrama de Actividad Administración de Diagnósticos

113 | P á g i n a

Diagrama de Actividad de Resultados de Exámenes

En el siguiente Diagrama de Actividad se ve como un Médico puede agregar

un nuevo Resultado de Examen, además de listar, editar y eliminar los

Resultados de Exámenes existente.

Figura 69: Diagrama de Actividad Administración Resultados de Exámenes

114 | P á g i n a




115 | P á g i n a


Diseño

Modelo de Clases

116 | P á g i n a

Figura 71: Modelo de Clases iteración 4

117 | P á g i n a




118 | P á g i n a



Nombre Entidad: Diagnostico

Descripción: Contiene los diagnósticos de los pacientes


IdDiagnostico Int PK 0 Código único del diagnóstico


IdEnfermedad Int FK 0 Llave foránea de la enfermedad

Descripción Varchar ' ' Descripción del diagnóstico


'01/01/1900' Fecha de creación del diagnóstico

Usuario Varchar ' ' Usuario de creación del diagnóstico


Nombre Entidad: ResultadoExamen

Descripción: Contiene los resultados de los exámenes de los pacientes


IdResultadoExamen Int PK 0 Código único del resultado


IdExamenGeneral Int FK 0 Llave foránea del examen general

ValorNumerico Int 0 Valor numérico del resultado

ValorDescriptivo Varchar ' ' Valor descriptivo del resultado


'01/01/1900' Fecha de creación del resultado

Usuario Varchar ' ' Usuario de creación del resultado


119 | P á g i n a

Construcción

Maqueta Mantenedor Resultados de Exámenes

Figura 73: Maqueta Mantenedor Resultado de Exámenes

Maqueta Ingreso Resultados de Exámenes

Figura 74: Maqueta Ingreso Resultados de Exámenes

120 | P á g i n a

Maqueta Sistema de Alertas

En la siguiente imagen se muestra como se alerta al médico, mediante un

icono ubicado en la parte superior de la pantalla, las anomalías detectadas.

Las notificaciones de alerta aparecen en la medida en que se ingresan

resultados de exámenes cuyos valores están fuera del umbral definido por los

valores límites de normalidad para cada enfermedad.

Por ejemplo: Se han definido ciertos rangos de normalidad para el examen de

Antígeno Prostático asociado al cáncer de próstata, 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 médicos soliciten

la realización de exámenes específicos para detectar a tiempo eventuales

patologías en los pacientes.

121 | P á g i n a


Figura 75: Maqueta Alertas

122 | P á g i n a


Pruebas

Pruebas Iteración 4(Final)

Caso de prueba



Estado

Diagnóstico Ingreso, edición y eliminación de Diagnósticos

Mantenedor de Diagnósticos

(Concluido)

Correcta ingreso, edicion y eliminación de Diagnósticos asociados a un Historial Médico generado por un determinado Médico

Pendiente

Resultado Examen

Ingreso, edición y eliminación de Resultados de Exámenes

Mantenedor de Resultados de Exámenes

(Concluido)

Correcta ingreso, edicion y eliminación de Resultados de Exámenes asociados a un Historial Médico generado por un determinado Médico

Cumplido

123 | P á g i n a

15. CONCLUSIÓN

A partir de los resultados obtenidos y la apreciación de los médicos que han

utilizado el software, se concluye que este proyecto adquiere gran relevancia,

pues contribuye con la salud de las personas. El sistema de diagnóstico

prematuro entrega información oportuna y de calidad, teniendo por objetivo

apoyar la labor de los médicos agilizando la toma de decisiones, disminuyendo

la posibilidad de errores. Se diseñaron las estructuras necesarias para

gestionar la información y generar reportes que alertan a los médicos sobre

anomalías en las tendencias normales de padecimiento de enfermedades.

Para poder cumplir con los objetivos mencionados, se realizaron una serie de

capacitaciones a los médicos con el fin de fortalecer su aprendizaje, en

búsqueda 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 adaptación

de los médicos, ya que no se presentaron mayores problemas en el uso de los

módulos implementados. Existe gran interés por los beneficios que el sistema

aporta, ya que no sólo es un sistema de registro, como los que generalmente

existen para el área, sino que entrega gran valor al momento de generar

información rápida respecto a los pacientes y la tendencia de enfermedades,

apoyando a la investigación y entrega de información relevante a los

profesionales. Es importante considerar que a través de medicina preventiva y

el auto cuidado del paciente es posible minimizar el riesgo de padecer algún

tipo enfermedad.

Finalmente, es fundamental destacar el importante aporte que significa utilizar

una metodología de software en el desarrollo de un sistema, ya que permite

mantener un orden estructural. Por otra parte, sirven de guía a los ingenieros

para interactuar con los clientes, logrando entender y modelar sus

necesidades, dando solución a problemáticas totalmente distintas al área

informática, como lo es la medicina.

124 | P á g i n a

16. BIBLIOGRAFÍA

16.1 LIBROS

[PRESSMAN] Pressman Roger, Ingeniería del software, 6th edition, 2010

[LAURENT] Patrones de diseño para C#, LaurentDebrauwer

[MINSAL] Guía clínica Minsal 2010, Cáncer de próstata en personas

de 15 años y más

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/ 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

125 | P á g i n a

http://yaqui.mxl.uabc.mx/~molguin/as/RUP.htm

http://www.extremeprogramming.org/

http://www-01.ibm.com/software/rational/rup/

http://users.dcc.uchile.cl/~psalinas/uml/introduccion.html

http://es.wikipedia.org/wiki/Urolog%C3%ADa

CUERPO TESIS.docx

Documents

Transcript of CUERPO TESIS.docx