bibdigital.epn.edu.ec · escuela politÉcnica nacional facultad de ingenierÍa de sistemas...
TRANSCRIPT
ESCUELA POLITÉCNICA NACIONAL
FACULTAD DE INGENIERÍA DE SISTEMAS
DESARROLLO DE UN SUBSISTEMA DE ATENCIÓN MÉDICA PARA LA DIRECCIÓN DE BIENESTAR ESTUDIANTIL Y
SOCIAL DE LA ESCUELA POLITÉCNICA NACIONAL
PROYECTO PREVIO A LA OBTENCIÓN DEL TÍTULO DE INGENIERO EN
SISTEMAS INFORMÁTICOS Y DE COMPUTACIÓN
DIANA PAOLA OÑA NACIMBA
PABLO ANDRÉS ROSERO TAICUD
DIRECTORA: Ing. SHEILA NOBOA CRUZ, MSc.
Quito, marzo de 2016
i
DECLARACIÓN
Nosotros Diana Paola Oña Nacimba y Pablo Andrés Rosero Taicud, declaramos
bajo juramento que el trabajo aquí descrito es de nuestra autoría; que no ha sido
previamente presentada para ningún grado o calificación profesional; y, que
hemos consultado las referencias bibliográficas que se incluyen en este
documento.
A través de la presente declaración cedemos nuestros derecho de propiedad
intelectual correspondientes a este trabajo, a la Escuela Politécnica Nacional,
según lo establecido por la Ley de Propiedad Intelectual, por su Reglamento y su
normativa institucional vigente.
Diana Paola Oña Nacimba Pablo Andrés Rosero Taicud
ii
CERTIFICACIÓN
Certifico que el presente trabajo fue desarrollado por Diana Paola Oña Nacimba y
Pablo Andrés Rosero Taicud, bajo mi supervisión.
Ing. Sheila Noboa, MSc.
Directora de proyecto
iii
AGRADECIMIENTOS
Agradecemos a Sheila Noboa nuestra directora de proyecto de titulación, por su
profesionalismo, tiempo, dedicación y paciencia; por transmitir su conocimiento
hacia nosotros; por corregirnos una y otra vez en cada revisión y por las
anécdotas, risas y debates compartidos.
Queremos también agradecer a la Dirección de Gestión Informática y de Procesos
(DGIP) y a la Dirección de Bienestar Estudiantil y Social (DBEYSO) de la Escuela
Politécnica Nacional por habernos confiado y concedido este proyecto, y por
todas las facilidades brindadas en su momento.
Diana, Andrés
iv
AGRADECIMIENTO
A Dios, por la salud, el amor, la familia, las bendiciones y la guía para alcanzar los
objetivos que me he propuesto.
A mis padres, por formarme con valores y enseñarme que con esfuerzo,
dedicación, honestidad y fe en Dios se consiguen grandes sueños.
A mi esposo, por su apoyo, comprensión y paciencia. Te amo amor.
A mi hijo Alan, quien es mi motivo de superación, gracias por darme tu mano y
seguir a mi ritmo con ánimo y comprensión, te amo luz de mis ojos.
A Andrés, mi mejor amigo y compañero de proyecto de titulación por compartir su
conocimiento y ser una gran persona. Por aquellos momentos alegres, tristes,
desesperantes que hemos afrontado para finalizar este proyecto.
A mis amigos y amigas, porque con cada uno de ellos aprendí que con
perseverancia se puede con aquello que parece difícil.
A Carmen S. y Rosa S., por ayudarme a cuidar a mi pequeño.
¡Gracias!
Diana
v
AGRADECIMIENTO
A la vida, por permitirme vivir momentos únicos e inolvidables, por darme el aire,
lo verde, lo bueno, lo incógnito,…pensamientos, gritos, emociones, tristezas,
alegrías, y más que nada por la magia de los pequeños detalles.
A mi mamá Mélfida Rosero, mi primer apego terrenal, gracias por tu ternura, tus
consejos, tus abrazos, tu coraje. Tú has sido mi guía y mi fortaleza. Gracias por
hacer de mí una persona de bien. Sin ti y tu esfuerzo yo no hubiese estado aquí.
Te amo ma.
A mi hermano Daniel Gómez, mi segundo apego terrenal, eres el regalo más
bonito que el universo me ha dado, gracias por tus locuras, iras y sonrisas,
gracias por llenar mi vida desde que llegaste a este mundo. Te amo ñaño.
A Diana, mi amiga y compañera en este desafío, gracias por la paciencia,
dedicación y ganas en cumplir este reto, por las risas, historias y vivencias
compartidas. Gracias en serio, tu impulso y motivación me ayudaron mucho.
A mis amigos, compañeros de estudio y de dirigencia, ustedes fueron parte del
engranaje estudiantil y de vida, gracias por todos los momentos vividos y todas
las lecciones aprendidas dentro y fuera de la poli.
A la EPN y FEPON, porque me formó como profesional y me permitió entender la
vida desde un punto más humano y coherente, porque me dejó conocer a
excelentes personas y sembrar buenas amistades.
¡Gracias!
Andrés Rosero T.
vi
DEDICATORIA
Dedico el presente proyecto de titulación a mi hijo Alan quien es mi razón de ser y
el motivo para lograr cada una de mis metas propuestas. Deseo que consigas con
esfuerzo, dedicación, humildad y fe en Dios todos los objetivos que te propongas,
te ofrezco mi apoyo y amor incondicional para que puedas afrontar con sabiduría
y paciencia cada obstáculo que se te presente para ser una persona de bien.
A mis padres y esposo que con su amor, esfuerzo y comprensión me ayudaron a
culminar con éxito el presente proyecto.
Diana
vii
DEDICATORIA
Dedico el presente trabajo a mi familia, en especial a mi mami y a mi hermano, a
quienes les debo lo que soy, siempre son mi fuerza y mi motivo para seguir.
A mi abuelito Marco Tulio Rosero, quien desde allá, desde el Cúmulo de energía
de vida está renaciendo nuevamente. Te extraño.
A quienes quiero y aprecio: Romario C., Marianela P., Ceci Ch., Adriana L, Diana
R, Lily G, Adriana Ch., André Ll., Jessy M., Gaby C., Sandy Ch., You F., Grace
M., Andrés B, Jóse P.
Andrés Rosero T.
viii
CONTENIDO
CAPÍTULO 1. DETECCIÓN DE NECESIDADES Y SOLUCIONES .................... 3
1.1. RECONOCIMIENTO DEL DEPARTAMENTO MÉDICO-EPN .................. 3
1.1.1. LEYES Y REGLAMENTACIÓN .......................................................... 3
1.1.2. ESTRUCTURA ORGÁNICA ............................................................... 4
1.1.3. PROCESOS Y SERVICIOS DEL DEPARTAMENTO ......................... 4
1.2. ALCANCE DEL SUBSISTEMA ................................................................. 7
CAPÍTULO 2. ASPECTOS METODOLÓGICOS Y HERRAMIENTAS A USAR .. 9
2.1. ASPECTOS METODOLÓGICOS .............................................................. 9
2.1.1. RELACIÓN FLUJOS DE TRABAJO Y FASES ................................. 17
2.1.2. MATRIZ GUÍA DE DESARROLLO ................................................... 19
2.2. HERRAMIENTAS A UTILIZAR ............................................................... 24
CAPÍTULO 3. DESARROLLO DE LA SOLUCIÓN ............................................ 30
3.1. MODELO DEL NEGOCIO ....................................................................... 30
3.1.1. Fase inicio ........................................................................................ 31
3.1.2. Fase elaboración .............................................................................. 31
3.2. MODELO DE REQUISITOS .................................................................... 32
3.2.1. Fase inicio ........................................................................................ 32
3.2.2. Fase elaboración .............................................................................. 33
3.2.3. Fase de construcción ........................................................................ 33
3.3. MODELO DE ANÁLISIS .......................................................................... 34
3.3.1. Fase inicio ........................................................................................ 34
3.3.2. Fase elaboración .............................................................................. 35
3.4. MODELO DE DISEÑO ............................................................................ 35
3.4.1. Fase elaboración .............................................................................. 35
ix
3.4.2. Fase construcción ............................................................................. 37
3.5. IMPLEMENTACIÓN ................................................................................ 38
3.5.1. Fase de elaboración ......................................................................... 39
3.5.2. Fase de construcción ........................................................................ 40
3.5.3. Fase de transición ............................................................................ 45
3.6. PRUEBAS ............................................................................................... 45
3.6.1. Fase inicio ........................................................................................ 45
3.6.2. Fase elaboración .............................................................................. 48
3.6.3. Fase construcción ............................................................................. 53
CAPÍTULO 4. IMPLANTACIÓN DE UN PROTOTIPO ...................................... 69
4.1. RECOPILAR DATOS .............................................................................. 69
4.2. INSTALACIÓN ........................................................................................ 69
4.3. EVALUACIÓ DE LA INSTALACIÓN........................................................ 71
CAPÍTULO 5. CONCLUSIONES Y RECOMENDACIONES ............................. 72
CONCLUSIONES ............................................................................................. 72
RECOMENDACIONES ..................................................................................... 75
GLOSARIO DE TÉRMINOS ................................................................................. 77
BIBLIOGRAFÍA .................................................................................................... 81
ANEXOS .............................................................................................................. 83
x
ÍNDICE DE FIGURAS
Figura 1.1: Estructura orgánica de la DBEYSO ...................................................... 4
Figura 2.1 Fases del PUD .................................................................................... 10
Figura 2.2 Flujos de trabajo del PUD ................................................................... 11
Figura 2.3: Flujos de trabajo y fases de PUD. ...................................................... 17
Figura 2.4: Componentes JEE6 [4] ...................................................................... 25
Figura 3.1 Cruce de requisitos vs casos de uso ................................................... 58
Figura 3.2 Primer escaneo con SonarQube ......................................................... 64
Figura 3.3 Segundo escaneo con SonarQube ..................................................... 65
Figura 3.4: Categoría B para el proyecto AtencionMedica ................................... 66
Figura 3.5: Categoría A para el proyecto AtencionMedica ................................... 66
Figura 3.6: Categoría B para el proyecto ServiciosAtencionMedica ..................... 67
Figura 3.7: Categoría A para el proyecto ServiciosAtencionMedica ..................... 67
ÍNDICE DE TABLAS
Tabla 2.1 Diagramas UML.................................................................................... 15
Tabla 2.2 Matriz guía de desarrollo ...................................................................... 19
Tabla 2.3: Categorización Sonarqube .................................................................. 28
Tabla 3.1: Menús vs Roles de acceso .................................................................. 42
Tabla 3.2: Plan de pruebas .................................................................................. 47
Tabla 3.3: Evaluación del modelamiento Fase de elaboración ............................ 49
Tabla 3.4: Evaluación del modelamiento Fase Construcción ............................... 54
Tabla 3.5: Evaluación de la Implementación vs Modelamiento ............................ 59
Tabla 3.6: Pruebas de funcionalidad con el técnico informático ........................... 62
Tabla 3.7: Pruebas de funcionalidad con el usuario experto ................................ 63
ANEXOS FÍSICOS
ANEXO I – Manual técnico
ANEXO II – Pruebas de funcionalidad con el técnico informático
xi
ANEXO III – Pruebas de funcionalidad con el usuario experto
ANEXO IV – Pruebas de código fuente con SonarQube (Resultados x eje de cal.)
ANEXO V – Carta de aceptación
ANEXOS DIGITALES
ANEXO D1 – Estatuto de la Escuela Politécnica Nacional
ANEXO D2 – Código de trabajo
ANEXO D3 – Ley Orgánica de Educación Superior (LOES)
ANEXO D4 – Informativo UBEYSO 2013
ANEXO D5 – Macro Proceso Bienestar Estudiantil (K)
ANEXO D6 – Procesos formalizados con la DGIP
ANEXO D7 – Productos Intermedios: Fase Inicio
ANEXO D8 – Productos Intermedios: Fase Elaboración
ANEXO D9 – Productos Intermedios: Fase Construcción
ANEXO D10 – Script de la base de datos
ANEXO D11 – Respaldo de la base de datos
ANEXO D12 – Código fuente del subsistema
ANEXO D13 – Manual de usuario
ANEXO D14 – Código ejecutable
ANEXO D15 – Manual de instalación
ANEXO D16 – Llave de certificado web
ANEXO D17 – Pruebas de código fuente con SonarQube (Detalle de evidencias)
1
RESUMEN
En el presente proyecto de titulación se desarrolló un subsistema de atención
médica para la Dirección de Bienestar Estudiantil y Social de la Escuela
Politécnica Nacional (EPN), integrado al SAEW (Sistema Académico Estudiantil
Web), a Recursos Humanos EPN y al Registro civil del Ecuador para tomar datos
personales y de identificación de los pacientes. Este proyecto se desarrolló en
base a una matriz guía sustentada en el Proceso Unificado de Desarrollo (PUD) y
las técnicas del Lenguaje Unificado de Modelado (UML). Se usaron: arquitectura
JEE, EJB, JSF, Primefaces; como ambiente de desarrollo JBOSS Developer
Studio; como motor de base de datos PostgreSQL, como herramienta de
modelado Enterprise Architect y como herramienta de software para evaluar la
calidad del código fuente SonarQube.
Capítulo 1 – Detección de Necesidades y Soluciones: se reconoció el
departamento médico, leyes, reglamentos, estructura orgánica, procesos
administrativos y servicios que brinda. Se definió el alcance del subsistema.
Capítulo 2 – Aspectos metodológicos y herramientas a usar: Se realizó una matriz
guía para el desarrollo donde se especificaron las actividades y los productos a
realizar.
Capítulo 3 – Desarrollo de la solución: en base a la matriz guía de desarrollo se
construyeron los distintos productos. Los modelos construidos fueron: modelo del
negocio, de requisitos, de análisis, de diseño (funcional, estructural, dinámico,
despliegue). Estos productos en su estado final de madurez se presentan en el
Manual técnico. También se ejecutaron los flujos de trabajo implementación y
pruebas.
Capítulo 4 – Implantación de un prototipo: se documentó cómo implantar el
prototipo desarrollado, donde consta la recopilación de datos de prueba y los
pasos a seguir para la instalación. Se presentaron los resultados de la evaluación
que incluye la carta de aceptación del subsistema.
Capítulo 5 – Conclusiones y recomendaciones: acorde a los objetivos general y
específicos se presentaron las conclusiones y recomendaciones.
2
INTRODUCCIÓN
En el Ecuador, las entidades médicas brindan servicios integrales de salud
valiéndose de herramientas de soporte como sistemas informáticos o sistemas
expertos para ofrecer un servicio de calidad optimizando tiempos y recursos.
En la Escuela Politécnica Nacional (EPN) la Dirección de Bienestar Estudiantil y
Social (DBEYSO) brinda a toda la comunidad politécnica atención integral de
salud y bienestar social. Actualmente el área de prestación de servicios de salud
no cuenta con un módulo para el control de inventario de medicamentos. Mientras
que para la atención médica cuenta con un aplicativo de escritorio que, a criterio
de la DBEYSO y de la Dirección de Gestión de la Información y de Procesos
(DGIP)1, ya no brinda un buen soporte a sus requisitos: no permite ver el historial
clínico de pacientes, no funciona el módulo de reportes, los usuarios consideran
que por la carga excesiva de pacientes atendidos por semestre (aprox. 3200) el
aplicativo no responde a lo esperado en tiempo de respuesta ni en calidad de los
datos y conforme pasa el tiempo sienten que se degrada más.
La DGIP gestiona los proyectos y desarrollos informáticos de mayor prioridad en
la EPN. Según expresa la Jefa de desarrollo de la DGIP, necesitan de grupos de
estudiantes que requieran hacer el proyecto de titulación para incorporarlos en
sus proyectos. Considerando lo mencionado, la DGIP ha asignado este desarrollo
como proyecto de titulación y ha sido concedida esta responsabilidad a los
autores. A su vez la DGIP expresa que brindará su apoyo y colaboración.
El presente proyecto de titulación tiene como objetivo general Desarrollar un
Subsistema de Atención Médica para la Dirección de Bienestar Estudiantil y
Social (DBEYSO) de la Escuela Politécnica Nacional (EPN) (SAMWeb), integrado
al subsistema SAEW (Sistema Académico Estudiantil Web) y al subsistema de
Recursos Humanos EPN con el objetivo de tomar datos personales y de
identificación de los pacientes para registrarlos en el subsistema. PUD y UML se
tomarán como referencias metodológicas, por sugerencia de la DGIP se
documentarán los diagramas que consideran estrictamente necesarios.
1 DGIP: “La ex Unidad de Gestión de la Información (UGI) tomó la nueva denominación de Dirección de
Gestión de la Información y Procesos (DGIP) según lo dispone la resolución del CES emitida el 17 de octubre
de 2013 y de conformidad con la Resolución de Consejo Politécnico No 93 del 1 de marzo de 2012”.
3
1 DETECCIÓN DE NECESIDADES Y SOLUCIONES
En el presente capítulo se realiza el reconocimiento de la Dirección de Bienestar
Estudiantil y Social de la Escuela Politécnica Nacional verificando las leyes y
reglamentos que lo gobiernan; se describe su estructura orgánica con las áreas
operativas vigentes; se detallan los procesos y servicios que brinda; y finalmente
se determina el alcance de la solución.
1.1 RECONOCIMIENTO DEL DEPARTAMENTO MÉDICO-EPN
Este punto describe la situación actual del departamento médico resaltando
aspectos como: cuál es su estado legal, cuál es su dependencia, cómo está
organizado administrativa y operativamente, y detalla qué procesos y servicios
provee a la comunidad politécnica.
1.1.1 LEYES Y REGLAMENTACIÓN
La EPN tiene una Dirección de Bienestar Estudiantil y Social (DBEYSO) que se
encarga de brindar servicios de medicina interna, ginecología, psicología,
odontología, nutrición y dietética a los empleados, docentes y estudiantes.
El Reglamento al que se rige la DBEYSO es al Estatuto de la Escuela Politécnica
Nacional aprobado en octubre de 2013.
En el TITULO II CAPITULO I - De las Autoridades, se estipula que en el Nivel
Ejecutivo, el Vicerrectorado de Docencia dirige a la “Dirección de Bienestar
Estudiantil y Social”2. Ver ANEXO D1 – Estatuto de la Escuela Politécnica Nacional
(Anexo digital).
En el TITULO IV CAPITULO IV artículo 63 - Del personal de Servidores y
Trabajadores, expresa que tienen derecho a “Acceder sin exclusión a los servicios
integrales de salud”. Mientras que en el Código de Trabajo artículo 430 está
reglamentado que el empleador (EPN) establecerá en el lugar de trabajo un
servicio médico permanente, proporcionando atención en medicina preventiva y 2 En el Estatuto de la Escuela Politécnica Nacional, aprobado en octubre de 2013, en el TITULO II CAPITULO I
- De las Autoridades, se menciona a la “Unidad de Bienestar Estudiantil y Social” (UBEYSO) como “Dirección
de Bienestar Estudiantil y Social” (DBEYSO), es por ello que en este proyecto se lo referencia como
DBEYSO.
4
atención médica en casos de emergencia, por accidentes de trabajo o de
enfermedad común repentina. Ver ANEXO D2 – Código de trabajo
Para la atención médica, los estudiantes de la EPN se rigen de acuerdo a la Ley
Orgánica de Educación Superior (LOES). El artículo 86 menciona que las
instituciones deben tener una Unidad de Bienestar Estudiantil que ofrezca
servicios asistenciales. Ver ANEXO D3 – Ley Orgánica de Educación Superior (LOES) .
1.1.2 ESTRUCTURA ORGÁNICA
La DBEYSO está bajo la dirección del Vicerrectorado de Docencia de la EPN. En
la Figura 1.1: Estructura orgánica de la DBEYSO se observa que hay un director
de la Unidad que gestiona las distintas áreas operativas.
Figura 1.1: Estructura orgánica de la DBEYSO3
El presente proyecto hace referencia al área médica, por ello es necesario definir
los servicios que ofrece para detectar las necesidades y obtener los requisitos
funcionales para el subsistema. Es importante reiterar que el área médica cuenta
con el apoyo de la enfermería, y esta a su vez brinda información sobre las
actividades del área.
1.1.3 PROCESOS Y SERVICIOS DEL DEPARTAMENTO
Un proceso es un conjunto de actividades interconectadas de forma lógica, estas
reciben entradas a las que agregan valor para producir una salida o resultado,
para de este modo cumplir con el objetivo del proceso.
Usar un proceso permite brindar un servicio, un servicio permite obtener un
beneficio. 3 Gráfico tomado del tríptico informativo de la DBEYSO 2013. Ver ANEXO D4 – Informativo UBEYSO 2013
VICERRECTORADO DE DOCENCIA
DIRECTOR DBEYSO
LIBRERÍA ÁREA MÉDICA TRABAJO SOCIAL NUTRICIÓN Y DIETÉTICA
5
La Dirección de Gestión de la Información y Procesos ha definido formalmente
para la DBEYSO un macro proceso denominado “Bienestar Estudiantil” con
identificación K. Ver el ANEXO D5 – Macro Proceso Bienestar Estudiantil (K) . Este
macroproceso se encuentra dividido en tres procesos principales4:
1. Prestación de Servicios de Salud (K.1)
2. Prestación de Servicios Sociales (K.2)
3. Gestión de Librería (K.3)
Los servicios que presta la DBEYSO mediante la ejecución de los procesos
brindan beneficios y bienestar a la comunidad politécnica (estudiantes, docentes,
administrativos (personal de la EPN) y Otros (familiares del personal de la EPN).
Cada proceso está asociado a varios subprocesos y estos a su vez están
asociados a los servicios que brinda.
A continuación se detallan los procesos y subprocesos de la DBEYSO:
1. Proceso: Prestación de Servicios de Salud (K.1): Este brinda los siguientes
servicios:
· Subproceso (K.1.1): Atención Médica Ambulatoria, ofrece los siguientes
servicios:
o Atención de consulta externa en medicina interna, medicina
general y urgencias.
o Planificación y ejecución de programas de medicina preventiva.
o Chequeo médico semestral a los estudiantes nuevos de
propedéutico.
o Emisión de certificados médicos.
· Subproceso (K.1.2): Atención Odontológica, ofrece los siguientes
servicios:
o Tratamientos preventivos: Profilaxis dental y aplicación de flúor.
o Tratamientos curativos: Extracciones simples y restauraciones
estéticas.
o Atención de urgencias odontológicas.
4 Para este proyecto la documentación de los procesos ha sido facilitada por la DGIP, información levantada
en la EPN durante el 2009.
6
o Emisión de certificados odontológicos.
· Servicio de Subproceso (K.1.3): Atención Médica Ginecológica, ofrece
los siguientes servicios:
o Atención de especialidad para mantenimiento de la salud
ginecológica.
o Orientación sobre planificación familiar, anticoncepción y
prevención de enfermedades de transmisión sexual.
o Control del embarazo.
o Prevención y diagnóstico oportuno del cáncer de cuello de útero.
o Control de pre menopausia, menopausia y osteoporosis.
· Subproceso (K.1.4): Atención Nutricional y Dietética, ofrece los
siguientes servicios:
o Atención de consultas para asesoramiento nutricional y dietético.
o Evaluación nutricional, diagnóstico y tratamiento.
o Orientación y supervisión de las actividades de cafeterías y
comedores de la EPN.
o Control en la aplicación de normas y técnicas en el tratamiento y
procesamiento de alimentos.
· Subproceso (K.1.6): Atención Psicológica, ofrece los siguientes
servicios:
o Prevención, diagnóstico y tratamiento de enfermedades relativas
a problemas de ansiedad, depresión, estrés, bajo rendimiento en
los estudios, trastornos psicomáticos, alcoholismo, drogadicción,
disfunción familiar o de pareja.
o Orientación profesional.
o Investigación sobre temas de salud mental.
o Emisión de certificados psicológicos.
2. Proceso: Prestación de Servicios Sociales (K.2): este brinda los siguientes
servicios:
· Asistencia y asesoramiento en problemas de índole familiar.
· Estudios y reclasificación socioeconómica para el pago de la matrícula
diferenciada.
7
· Promoción y trámites relacionados con el Sistema de Becas
Estudiantiles.
· Investigación y certificación de calamidades domésticas.
3. Proceso: Gestión de Librería (K.3): promueve la venta, promoción e
intermediación de: libros, publicaciones, prospectos académicos, material
didáctico, útiles, materiales de oficina, uniformes y símbolos politécnicos al
alcance de la comunidad politécnica.
1.2 ALCANCE DEL SUBSISTEMA
De los procesos y subprocesos de la DBEYSO, la DGIP seleccionó los siguientes
subprocesos: Atención Médica Ambulatoria (K.1.1) y Atención Médica
Ginecológica (K.1.3) para que sean atendidos en el presente proyecto de
titulación con el desarrollo de un software de apoyo.
Al revisar los dos subprocesos administrativos se reconoce que estos generan
una “orden de entrega de medicación” sin embargo no se encuentra formalmente
definido un subproceso de Administración de Inventario, por lo cual se procederá
a levantarlo para ser atendido en este software.
Por lo tanto se define como alcance del subsistema lo siguiente:
· Punto de vista administrativo
El subsistema apoyará a los subprocesos administrativos: atención médica
ambulatoria y la atención médica ginecológica, se considerará también el
subproceso de manejo de inventario una vez formalizado.
Para cada actividad de estos subprocesos administrativos se reconocerán los
requisitos funcionales que deberán ser atendidos dentro del subsistema.
· Punto de vista tecnológico
El modelamiento del subsistema se basará en el Proceso Unificado de Desarrollo
(PUD) y el Lenguaje Unificado de Modelado (UML); en vista que la DGIP
mantiene una documentación mínima en los proyectos que desarrollan, para el
8
presente proyecto se ha establecido en acuerdo con la DGIP que tendrá un
enfoque restringido de modo que se generará la mínima documentación
necesaria que esta exige.
Para la implementación se utilizarán tecnologías web bajo la arquitectura JEE6
con Primefaces 3.4. La base de datos en la que se implementará es PostgreSQL.
· Punto de vista funcional
Si bien, el subsistema atenderá a la DBEYSO, cabe recalcar que para tomar los
datos de identificación de los pacientes y registrarlos dentro del subsistema
médico se integrará parcialmente con los subsistemas: SAEW (Sistema
Académico Estudiantil Web) cuando son estudiantes matriculados y con el
subsistema de RRHH cuando son profesores o personal administrativo de la
EPN.
Se prevé realizar 3 módulos:
1. El módulo de Atención Médica: manejará las Historias Clínicas que incluye
la identificación y descripción de los pacientes, atenciones de consultas
médicas ambulatoria, ginecológica y medicina preventiva.
2. El módulo de reportes para la atención médica: permitirá generar listas,
cuadros de cruce y gráficos estadísticos para ayudar al entendimiento de
tendencias y patrones dados en las atenciones.
3. El módulo de Manejo de Inventario: comprende el registro de ingreso y
consumo de medicamentos, ajuste por toma de inventario y alertas
esenciales para controlar el saldo.
Para las pruebas del subsistema se espera contar con la colaboración de la
DGIP, caso contrario se limitará a las pruebas que realizarán los desarrolladores.
Para la implantación se simulará las tablas necesarias del subsistema SAEW y
del subsistema de RRHH en ambientes propios de los desarrolladores.
El subsistema no implementará funcionalidades para ningún otro subproceso del
Proceso Servicio de Salud, ni de ningún otro proceso del macro proceso
Bienestar estudiantil.
9
2 ASPECTOS METODOLÓGICOS Y HERRAMIENTAS A
USAR
2.1 ASPECTOS METODOLÓGICOS
Este proyecto se desarrolló respetando los principios de orientación a objetos y
considerando para el modelamiento los lineamientos del Proceso Unificado de
Desarrollo (PUD) y las técnicas del Lenguaje Unificado de Modelado (UML)
planteado por los mismos autores de PUD.
A continuación se da una introducción a PUD y UML:
Proceso Unificado de Desarrollo (PUD) es un marco de trabajo genérico
adaptable a diferentes organizaciones para el desarrollo de sistemas de software
de cualquier tamaño.
El Proceso Unificado de Desarrollo se centra en tres ejes principales:
· Es Dirigido por casos de uso porque, los requisitos del sistema se
representan por medio de casos de uso, que a su vez son fragmentos de
funcionalidad. Los casos de uso proporcionan una guía para el desarrollo, al
ser requisitos solventados en funcionalidades guían el proceso de desarrollo
de tal forma que los desarrolladores crean varios modelos de diseño e
implementación a partir de los casos de uso.
· Es Centrado en la arquitectura porque, la especificación de los principales
casos de uso permite definir cuál será el comportamiento global del sistema,
de esta manera se define la arquitectura o columna vertebral del sistema. La
arquitectura por definición es “una vista del diseño completo con las
características más importantes resaltadas, dejando de lado los detalles” [1, p.
6], esta depende de cómo los casos de uso son desarrollados. Tanto los
casos de uso como la arquitectura deben corresponderse, “los casos de uso
deben encajar en la arquitectura cuando se lleven a cabo y la arquitectura
debe permitir el desarrollo de todos los casos de uso requeridos en este
momento y en el futuro, ambos deben progresar a la par”. [1, p. 6]
10
· Es Iterativo e Incremental porque, es una buena táctica dividir el desarrollo
en partes pequeñas o iteraciones, cada iteración resulta ser un incremento.
“Las Iteraciones hacen referencia a pasos por flujos de trabajo, y los
incrementos al crecimiento del sistema” [1, p. 7]. En cada iteración se trabaja
con los casos de uso principales creando un diseño y utilizando una
arquitectura definida como guía, es decir, cada iteración produce artefactos
del modelo, al final de cada iteración se obtiene un nuevo incremento del
modelo de requisitos, de análisis, de diseño, de implementación, de pruebas y
de despliegue.
Un producto de software es el resultado de un ciclo de vida del desarrollo de
software, conocida también como una versión del producto. En PUD el ciclo de
vida es matricial (donde las actividades se realizan en paralelo) y está
comprendida por fases y flujos de trabajo. Al menos deben existir cuatro
iteraciones, una por cada fase.
Las Fases son:
Figura 2.1 Fases del PUD
En la Figura 2.1 se expresa las cuatro fases del PUD ejecutadas a lo largo del
tiempo.
· Fase de inicio: el propósito de esta fase es conocer el negocio, identificar
los objetivos del sistema a través de la captura de la mayoría de requisitos,
reconocer los riesgos críticos y determinar su viabilidad para delimitar el
alcance del sistema.
Inicio Elaboración Construcción Transición
Un ciclo de vida genera una versión del software
Línea del tiempo
11
· Fase de elaboración: en esta fase se desarrolla el plan del proyecto,
elimina riesgos críticos, y se establece la línea base de la arquitectura
identificando los casos de uso con mayor impacto, de esta forma se
identifican los subsistemas e interfaces que conformarán el sistema.
En esta fase se establece mayormente el diseño del sistema.
· Fase de construcción: el propósito en esta fase es implementar el
sistema software codificándolo en base del diseño a través de una serie de
iteraciones que generan incrementos, optimizando tiempo y costos, hasta
que alcance una capacidad operacional inicial y empiece su transición
hacia los usuarios.
La fase de construcción termina con la funcionalidad operativa inicial.
· Fase de transición: en esta fase se realizan los últimos cambios y corrigen
defectos en la versión vigente o beta del producto hasta que alcance una
operatividad aceptable y esté listo para su entrega final a los usuarios,
además se completa la documentación y se entrena al usuario en el
manejo del sistema con lo cual se consiguen los objetivos establecidos en
la fase de inicio.
Termina esta fase con el lanzamiento del producto.
Los Flujos de trabajo son:
Figura 2.2 Flujos de trabajo del PUD
La Figura 2.2 expresa los flujos de trabajo de PUD; cada uno devuelve productos
(modelo, descripción o software) que van madurando a través del tiempo.
Modelo del Negocio
Requisitos
Análisis
Diseño
Implementación
Pruebas
Despliegue
Flujos de
trabajo
12
· Modelo del Negocio: el propósito de este modelo es entender la
estructura de la organización donde se describen los procesos del negocio
que el sistema soportará. Dentro de cada proceso se definen: tipos de
trabajadores responsables y roles (operaciones que llevan a cabo).
· Requisitos: en este flujo se capturan los requisitos del sistema donde se
establece qué hace el sistema, para ello es necesario la utilización de un
modelo de casos de uso que capture todos los requisitos funcionales y los
no funcionales.
El producto fundamental en el flujo Requisitos es el modelo de casos de
uso de requisitos. Un modelo de casos de uso es un modelo del sistema
que abarca actores, casos de uso y sus relaciones, asegurando que todos
los requisitos capturados sean los correctos, este modelo parte del modelo
del negocio anteriormente definido. Para explicar cómo se relacionan los
casos de uso con los actores estos son representados a través de
diagramas y descripciones UML.
· Análisis: al finalizar este flujo se obtiene una arquitectura consistente.
El artefacto resultante de este flujo es el modelo de análisis. Un modelo de
análisis permite comprender el funcionamiento global del sistema y se lo
describe utilizando un lenguaje que los desarrolladores entiendan; este
modelo contiene clases de análisis y casos de uso jerarquizados por
paquetes. Una clase de análisis representa una abstracción de una o
varias clases y/o subsistemas del diseño del sistema y se centra en los
requisitos funcionales posponiendo los requisitos no funcionales.
· Diseño: en el flujo Diseño se modela el sistema encontrando su forma y
arquitectura para que soporte todos los requisitos. Este flujo se alimenta de
los modelos anteriores Análisis y Requisitos. Este flujo viene a ser el punto
de partida para las actividades de la siguiente fase Implementación,
permitiendo así tener un modelo de diseño que visualice la implementación
y que soporte las técnicas de programación gráfica. El modelo de diseño
describe la realización física de los casos de uso centrándose en cómo los
13
requisitos tienen impacto en el sistema. Un modelo de casos de uso es un
modelo del sistema que abarca actores, casos de uso y sus relaciones,
asegurando que todos los requisitos capturados sean los correctos y estén
solventados. Este modelo de diseño adicionalmente está compuesto por
clases de diseño, interfaces, paquetes y subsistemas. En este modelo se
describen los controles que se deben considerar para los casos de uso del
sistema
Adicionalmente se obtiene como resultado un modelo de despliegue, que
describe todas las configuraciones de hardware y de red sobre las cuáles
debería implantarse el sistema, este incluye las características de hardware
y software más relevantes.
· Implementación: su propósito principal es codificar el sistema,
considerando elementos significativos de la arquitectura: clases,
subsistemas y componentes.
La implementación describe cómo los elementos del modelo de diseño se
desarrollan y organizan en componentes, cómo están estructurados y
divididos en módulos, todos codificados con el o los lenguajes de
programación necesarios para obtener archivos ejecutables.
Durante este flujo se desarrollan clases, componentes y subsistemas,
cuando ya se encuentran listos se integran entre sí para formar el sistema
con los incrementos de cada iteración.
· Pruebas: el flujo de trabajo Pruebas tiene como objetivo principal validar la
calidad de los productos generados en cada construcción, para esto las
pruebas se deben planificar, ejecutar y evaluar, estas deben estar
especificadas en un Plan de pruebas. El plan de pruebas describe la
estrategia de pruebas, responsables y la planificación, la estrategia incluye
la definición del tipo de pruebas a realizar con sus objetivos y la cantidad
de pruebas a ejecutar.
Entre las pruebas a realizar se encuentran: evaluaciones al modelamiento,
a la implementación vs modelamiento y al producto. La evaluación al
producto consiste en realizar pruebas funcionales. Las pruebas funcionales
14
las realiza el técnico informático y el usuario experto. El técnico informático
evalúa si las funciones desarrolladas soportan los casos de uso planteados
mientras que el usuario experto valida si las funciones desarrolladas
aportan a los procesos administrativos.
La aplicación de las pruebas permite encontrar defectos a tiempo y que
estos sean corregidos oportunamente en las siguientes iteraciones.
· Despliegue: en este flujo de trabajo se realizan varias actividades
necesarias para la instalación de todos los artefactos desarrollados en las
fases anteriores, principalmente se toman en consideración el modelo de
despliegue definido en el flujo Diseño, de tal manera que se ponen a
prueba todas las especificaciones de hardware y software base que
requiere el producto desarrollado para su funcionamiento. El modelo de
despliegue puede cambiar dependiendo de las circunstancias y la
severidad de cambios realizados en el sistema durante el ciclo de vida de
desarrollo.
Lenguaje Unificado De Modelado (UML) brinda soporte al PUD para
representar gráficamente los esquemas y artefactos que usa. UML es un
lenguaje de modelado que permite representar procesos del negocio y funciones
del sistema incorporando buenas prácticas de diseño. Proporciona soporte a la
mayoría de los procesos de desarrollo desde los requisitos hasta la
implementación, puede ser utilizado en diferentes etapas del ciclo de vida de
desarrollo.
“Es un lenguaje de modelado visual de propósito general que se utiliza para
especificar, visualizar, construir y documentar los artefactos de un sistema
software. Captura decisiones y conocimiento sobre sistemas que deben ser
construidos.” [2, p. 3]
15
UML es un lenguaje gráfico que utiliza una notación visual para representar
diagramas que constituyen un aspecto del sistema a modelar. Ofrece una gama
de diagramas que permiten visualizar al sistema desde varios puntos de vista.
Para una mayor comprensión de los diagramas en este proyecto se los ha
agrupado en cuatro puntos de vista.
PUNTO DE VISTA DIAGRAMA FUNCIONAL · Diagrama de casos de uso
ESTRUCTURAL · Diagrama de clases · Diagrama de objetos
DINÁMICO · Diagrama de estados
· Diagrama de actividad
· Diagrama de secuencia
DESPLIEGUE · Diagrama de componentes · Diagrama de despliegue
Tabla 2.1 Diagramas UML
El primer punto vista, el Funcional, permite apreciar la funcionalidad real del
sistema mediante casos de uso, escenarios y restricciones, incluye el siguiente
diagrama:
· Diagrama de Casos de uso: muestra las relaciones (asociación,
extensión, generalización, inclusión) entre los casos de uso y las
dependencias entre un grupo de casos de uso por los objetos que
comparten y los actores participantes en el proceso. Los diagramas de
casos de uso determinan las características que tendrá el sistema, es
decir, describen que hará el sistema.
El segundo punto de vista permite tener una apreciación estructural de datos del
sistema, describiendo todos sus elementos y cómo se relacionan para lograr los
objetivos del sistema, este contiene los siguientes diagramas:
· Diagrama de Clases: los diagramas de clases muestran al conjunto de
clases (métodos y atributos) que conforman un sistema y sus relaciones.
· Diagrama de Objetos: contiene objetos, es decir este diagrama muestra
las instancias de las clases del diagrama de clases presentando los objetos
16
del sistema en un instante dado, puede incluir especificaciones de los
valores de objetos.
El tercer punto de vista, el Dinámico, permite describir el comportamiento del
sistema en el tiempo, los diagramas que lo componen son los siguientes:
· Diagrama de Estados: los diagramas de estado muestran los diferentes
estados de un objeto durante su vida y los eventos que provocan los
cambios de estado, un cambio de estado afecta significativamente al
funcionamiento del objeto.
· Diagrama de Actividad: los diagramas de actividad modelan los flujos de
trabajo de una organización o de un caso de uso, es decir, describen las
actividades que se pueden realizar por diferentes objetos o personas en
una organización representándolos en hilos, donde se muestra el flujo de
valores de objetos y el flujo de control.
· Diagrama de Secuencia: muestra el intercambio de un conjunto de
mensajes ordenados (secuencia temporales de mensajes) en una
funcionalidad dada. Útiles para mostrar el diseño detallado de llamadas a
métodos.
El cuarto punto de vista se refiere al despliegue, describe los recursos de TI
(Tecnologías de la Información) que el sistema y los usuarios necesitan.
· Diagrama de Componentes: muestra los componentes de un sistema que
son las unidades de software que construye la aplicación y las
dependencias entre componentes para valorar el impacto de un cambio
propuesto.
· Diagrama de Despliegue: muestra los tipos de nodos que hay en el
sistema y los componentes que se implantarán sobre estos. Un nodo es un
recurso de TI (computadora, memoria,…) y un producto es una unidad de
implementación física (archivo, componente,…). Este diagrama permite
valorar la distribución y la asignación de recursos que se usarán en tiempo
de ejecución.
17
2.1.1 RELACIÓN FLUJOS DE TRABAJO Y FASES
Para el entendimiento de la relación existente entre los flujos de trabajo y las
fases, se efectúa una síntesis de PUD y UML.
En la Figura 2.3 se aprecia que los Flujos de Trabajo tienen relación con el esfuerzo
o actividades realizadas para conseguir productos mientras que las Fases tienen
relación con el tiempo empleado para conseguir esos productos. Esta figura se
construyó en base a la referencia del PUD [1, p. 11] y a la figura completa de RUP
referenciada en [3]. Los flujos de trabajo son esfuerzos que se invierten para la
entrega de productos que con el tiempo van madurando.
Flujos de trabajo fundamentales
Fases
Inicio Elaboración Construcción Transición
Modelo del negocio
Requisitos
Análisis
Diseño
Implementación
Prueba
Despliegue
Iter. 1
Iter. 2 – – – – –
Iter. n-1
Iter. n
Figura 2.3: Flujos de trabajo y fases de PUD.
En la fase de inicio la actividad se centra en los flujos de trabajo: modelo del
negocio y requisitos, realizando un menor esfuerzo en los flujos de trabajo análisis
y prueba.
En la fase de elaboración el esfuerzo es menor en el modelo del negocio y se
realiza un gran esfuerzo para completar los requisitos. En los flujos de trabajo
análisis y diseño el esfuerzo incrementa para la creación de la arquitectura. Se
registra actividades en los flujos implementación, prueba y despliegue.
En la fase de construcción el esfuerzo en los flujos de trabajo modelo del negocio,
requisitos y análisis es mínimo, se enfoca el mayor esfuerzo en los flujos de
diseño, implementación y prueba. Se inician actividades para el despliegue.
18
En la fase de transición la actividad de los distintos flujos de trabajo disminuye, el
esfuerzo está concentrado en los flujos de trabajo pruebas y despliegue. Si las
pruebas descubren algún defecto en la implementación habrá una actividad
considerable en los flujos de trabajo de implementación, prueba y despliegue para
conseguir un producto acorde a los requisitos y satisfactorio para el usuario final.
Al final de cada fase se establecen controles principales que constituyen
revisiones, donde se asegura que las decisiones importantes sean parte de los
modelos y estos evolucionen en el ciclo de vida del producto.
Lo expuesto hasta este momento expresa la relación global de las fases y flujos
de trabajo dentro del PUD.
En el siguiente numeral que hace referencia a la Matriz guía de desarrollo en la
cual se especifica a detalle la relación entre fases y flujos de trabajo incluyendo la
relación de PUD y UML.
19
2.1.
2 M
AT
RIZ
GU
ÍA D
E D
ES
AR
RO
LL
O
La
Ma
triz
gu
ía d
e d
esa
rro
llo s
irve
co
mo
gu
ía m
eto
do
lógi
ca p
ara
est
e p
roye
cto,
mu
est
ra la
rela
ción
de
los
flujo
s d
e t
rab
ajo
y l
as
fase
s de
de
sarr
ollo
, re
salta
ndo
los
pro
duct
os
que
se
en
trega
n p
or
cad
a f
lujo
de
tra
bajo
al
fina
l d
e c
ada
fa
se s
ean
o n
o d
e t
ipo
UM
L.
En
ca
da
fa
se,
fren
te
a
cad
a
flujo
de
tr
ab
ajo
co
nst
a
el
po
rce
nta
je
de
m
ad
ure
z qu
e
de
be
n
alc
anza
r lo
s p
rod
uct
os
corr
esp
ond
ien
tes.
Al
fina
l d
e c
ad
a f
ase
el
con
junt
o d
e p
rod
uct
os
ob
ten
ido
s e
n t
odo
s lo
s flu
jos
de t
rab
ajo
en
su
est
ad
o d
e
ma
dure
z co
rre
spo
ndie
nte
, p
erm
iten
exp
resa
r e
l ape
go a
los
prin
cipio
s d
el P
UD
y c
on
sta
n c
om
o a
nexo
s d
igita
les.
Ver
AN
EX
O D
7 –
Pro
du
cto
s
inte
rmed
ios
: F
ase
inic
io,
AN
EX
O
D8
–
Pro
du
cto
s
inte
rmed
ios:
Fase
ela
bo
ració
n,
AN
EX
O
D9 –
Pro
du
cto
s
inte
rmed
ios:
Fas
e
co
nstr
ucció
n. M
ien
tras
que
los
pro
du
cto
s e
n s
u e
sta
do f
ina
l de
ma
dur
ez
con
stitu
yen
el M
an
ua
l té
cnic
o d
el s
ubsi
ste
ma.
Ver
AN
EX
O
I -
Man
ual T
écn
ico
.
FA
SE
S IN
ICIO
E
LA
BO
RA
CIÓ
N
CO
NS
TR
UC
CIÓ
N
TR
AN
SIC
IÓN
FL
UJO
S D
E
TR
AB
AJO
P
RO
DU
CT
OS
% d
e M
adu
rez
de
los
pro
du
ctos
en
cad
a fa
se
Mo
del
o d
el N
ego
cio
D
iagr
am
a d
e a
ctiv
idad
es
de lo
s pro
ceso
s adm
inis
trativ
os
del n
egoci
o*
95%
100%
Req
uis
ito
s
Lis
ta d
e re
quis
itos
func
iona
les
90%
98%
100%
Lis
ta d
e re
quis
itos
no f
unc
iona
les
90%
100%
Dia
gram
a d
e r
equ
isito
s 90%
98%
100%
An
áli
sis
Dia
gram
a d
e a
ctore
s* 80%
100%
D
iagr
am
a d
e c
aso
s de
uso
a n
ive
l co
ntext
ua
l* 80%
100%
D
iagr
am
a d
e c
lase
s de
an
ális
is*
80%
100%
Lis
ta d
e ri
esg
os c
rític
os
y su
via
bili
dad
80%
100%
19
D
iseñ
o
Dis
eño
fu
nci
on
al
D
iagr
am
a d
e c
aso
s de
uso
por
módu
lo*
80%
100%
Desc
ripci
ón
de
caso
s de
uso
80%
100%
Dis
eño
est
ruct
ura
l
Dia
gram
a d
e c
lase
s de
dis
eño
*
80%
100%
Dia
gram
a d
e o
bje
tos*
80%
100%
Dic
cion
ario
de
dat
os
del
D.
de
clase
s
80%
100%
Dis
eño
din
ámic
o
D
iagr
am
as
de
act
ivid
ade
s de
los
caso
s de
uso
com
ple
jos*
80%
100%
Dia
gram
a d
e s
ecu
enci
a d
e lo
s ca
sos
de
uso
que
llam
an
méto
dos
de
cla
ses*
80%
100%
Dia
gram
a d
e e
stad
os
de
obje
tos
qu
e
cam
bia
n de
est
ado
*
80%
100%
Dis
eño
de
des
pli
egu
e
D
iagr
am
a d
e c
om
pon
ente
s *
90%
100%
Dia
gram
a d
e d
esp
liegue
*
90%
100%
Imp
lem
enta
ció
n
Est
ruct
ura
de la
BD
D
100%
Scr
ipt
de
la b
ase
de d
ato
s
100%
Base
de d
ato
s in
icia
l
100%
Códig
o fu
en
te d
el s
ubs
iste
ma
20%
98%
100%
Pru
ebas
P
lan d
e p
rueba
s 50%
100%
Aplic
aci
ón
de p
rueba
s
40%
90%
100%
Des
pli
egu
e
Man
ual d
e usu
ario
60%
100%
Códig
o eje
cuta
ble
98%
100%
Man
ual d
e in
sta
laci
ón
20%
100%
Tab
la 2
.2 M
atr
iz g
uía
de
desa
rrollo
* E
stos
pro
duc
tos
son
de
tipo U
ML
.
20
La matriz expuesta en la Tabla 2.2 se interpreta desde dos puntos de vista: punto
de vista de los desarrolladores y punto de vista del gestor del proyecto.
Desde el punto de vista de los desarrolladores, la matriz expresa los productos
que se deben conseguir ejecutando cada uno de los flujos de trabajo, a la derecha
se observa el porcentaje de madurez que deben lograr los productos en el tiempo
que coincide con el final de cada fase.
A continuación, para cada flujo de trabajo se expresan las actividades que deben
realizarse para conseguir los diferentes productos.
En el flujo de trabajo Modelo del negocio en trabajo conjunto con el personal que
domina los procesos administrativos del negocio se reconocen aquellos que serán
atendidos por el subsistema, cada uno debe ser descrito en un Diagrama de
actividades de los procesos administrativos del negocio, en el cual se establecen
calles para cada responsable.
En el flujo de trabajo Requisitos para las actividades que merezcan un soporte
informático deben ser reconocidos uno o más requisitos funcionales globales,
mismos que se mencionan a la derecha del Modelo del negocio y sirven para
realizar una Lista de requisitos funcionales reconocidos en el Modelo del negocio
por cada proceso administrativo.
Los requisitos funcionales se reconocen a través de un Diagrama de requisitos lo
cual no contradice el principio de PUD. Este diagrama de requisitos reemplaza al
diagrama de casos de uso de requisitos. A cada uno de los requisitos funcionales
que constan en la lista se los considera requisitos centrales en el Diagrama de
requisitos y se los desglosa a detalle en requisitos más pequeños y explicativos.
Adicionalmente se hace una Lista de requisitos no funcionales, se los obtiene
considerando las características de los usuarios, la cobertura geográfica y los
principios de calidad de software esperados.
En el flujo de trabajo Análisis todos los responsables de actividades para las que
se han reconocido requisitos funcionales, deben constar como actores en un
Diagrama de actores.
21
Así como también todos los requisitos especificados deben a futuro satisfacerse
en algún caso de uso del Diagrama de casos de uso a nivel contextual.
Cada caso de uso debe estar atendido o tener como responsable a algún actor
definido en el Diagrama actores, puede ser un actor generalizado.
A continuación se reconocen los objetos principales que constan en el Diagrama
actividades de los procesos administrativos del negocio para ser representados
en el Diagrama de clases de análisis. En estas clases no se hacen constar ni los
atributos ni los métodos. Estas clases por lo general coinciden con los objetos que
manejan los procesos administrativos en el Modelo del negocio.
El flujo de trabajo Diseño está estructurado por el Diseño funcional, Diseño
estructural, Diseño dinámico y Diseño de despliegue.
· En el Diseño funcional cada caso de uso del Diagrama casos de uso a nivel
contextual es desglosado en el Diagrama casos de uso por módulo. Todo
requisito reconocido en el Modelo del negocio debe estar satisfecho en un
sólo caso de uso. Cada requisito central en el Diagrama de requisitos
consta como caso de uso base. Si existen funcionalidades que se repiten
dentro de los casos de uso base, se los unifica en un caso de uso incluido,
o si existen funcionalidades adicionales se lo representa en un caso de uso
extensor. En el Diagrama de casos de uso por módulo consta una
Descripción de casos de uso y las restricciones y escenarios para cada
caso uso.
· En el Diseño estructural, para satisfacer la funcionalidad de cada caso de
uso del Diagrama casos de uso por módulo se deben definir las clases
necesarias en el Diagrama clases de diseño. Todos los atributos que se
requieren para la funcionalidad de cada caso de uso, en el Diagrama casos
de uso por módulo, deben constar como atributo en el Diagrama clases de
diseño. Para que la estructura del subsistema sea consistente toda clase
definida en el Diagrama de clases de análisis debe constar en el Diagrama
clases de diseño de manera explotada si fuera necesario, pero con sus
atributos, métodos y roles. Todos los métodos que acceden a la base de
datos en un caso de uso deben constar como métodos en este diagrama.
22
Cada clase de este diagrama debe tener una instancia en el Diagrama de
objetos, la misma que debe estar relacionada con las otras instancias
pertenecientes al resto de clases, tal como están relacionadas las clases.
Todos los tipos de datos que manejen las diferentes clases definidos en el
Diagrama de clases de diseño deben constar en el Diccionario de datos del
diagrama de clases para facilitar su comprensión.
· En el Diseño dinámico, para entender el comportamiento del subsistema,
todos los casos de uso complicados deben tener un Diagrama actividades
de casos de uso complejo. Todos los envíos de mensajes deben constar
como métodos en el Diagrama de clases de diseño. Todos los objetos que
están implícitos en el Diagrama actividades de casos de uso complejo
deben constar en el Diagrama de objetos.
Se debe crear un Diagrama de estados por cada objeto que en el tiempo
cambia de estado. El cambio de estado de un objeto se debe dar por medio
de un método especificado en el Diagrama de clases de diseño dado por
un escenario de algún caso de uso, estos deben constar en el Diagrama de
estados de objetos que cambian de estado.
Se realiza un Diagrama de secuencia de los casos de uso que llamen
métodos de clases, donde los métodos deben ser los mismos que constan
en su correspondiente clase en el Diagrama de clases de diseño. Los
objetos que constan en este diagrama deben constar en el Diagrama de
objetos. Los mensajes que constan en el Diagrama de secuencia de los
casos de uso que llamen métodos de clases deben constar como envíos
de mensajes en el Diagrama actividades de casos de uso complejo si
existiese.
· En el Diseño de despliegue los componentes en el Diagrama de
componentes deben constar como burbuja en el Diagrama de casos de uso
a nivel contextual. Todo componente mostrado en el Diagrama de
componentes debe ser desarrollado en este proyecto. En el Diagrama de
despliegue deben constar todos los recursos de TI donde se van a
desplegar los componentes desarrollados.
23
En el flujo de trabajo Implementación deben estar definidos los roles o perfiles de
usuario de acuerdo a los actores. Cada burbuja del Diagrama de casos de uso a
nivel contextual representa un módulo del subsistema implementado. Todos los
casos de uso del Diagrama de casos de uso por módulo deben contar con su
código fuente.
Todos los casos de uso base deben ser parte de un menú. Los casos extendidos
deben tener una interfaz para que el usuario pueda ejecutarlo. Los casos de uso
incluidos no deben tener interface para ser ejecutados por el usuario dado que se
ejecutan de forma automática.
Todas las clases reconocidas en el diseño se representan en alguna tabla de la
base de datos. Los métodos deben estar implementados en procedimientos
almacenados de la base de datos, o sino en alguna clase del negocio. Los roles
en las clases de diseño deben constar como roles o perfiles de usuario. La base
de datos debe constar con todas las restricciones sujetas a lo que dicen las
relaciones de las clases de diseño.
Los programadores deben basarse en la lógica del Diagrama de casos de uso por
módulo y del Diagrama de actividades de los casos de uso complejos. Todas las
actividades de cambios de estado que se han planteado en el Diagrama de
estados de objetos que cambian de estado deben estar implementadas en su
correspondiente clase. Finalmente se verifica que todos los componentes hayan
sido desarrollados y que todos los requisitos hayan sido satisfechos.
En el flujo de trabajo Pruebas, mediante el Plan de pruebas y la Aplicación de las
pruebas se evalúa el modelamiento de software y el producto final a entregar con
el fin de obtener un conjunto de artefactos de calidad. Se comprueba que todos
los objetivos: de las fases y flujos de trabajo, de la metodología y de la
planificación se cumplan de forma óptima y eficaz, en función del alcance y en los
tiempos determinados. Al finalizar se realiza la documentación necesaria.
En el flujo de trabajo Despliegue se verifica que en el ambiente de los
desarrolladores se instale los componentes declarados en el Diagrama de
despliegue.
24
Desde el punto de vista del gestor del proyecto, la matriz simplifica de manera
ágil el trabajo que debe realizar, esta permite controlar el avance de las
actividades y el nivel de madurez de los productos al final de cada fase o
iteración. Las actividades del gestor son:
· Facilitar todos los recursos necesarios para el desarrollo del proyecto
· Procurar el aporte adecuado de los usuarios durante el desarrollo del
proyecto (que los usuarios intervengan en la validación de las
funcionalidades del subsistema)
· Reconocer el estado de madurez de los productos
· Controlar que los desarrolladores cumplan el avance de los productos
respecto del tiempo
· Retroalimentar al equipo de desarrollo con las diferentes observaciones
· Controlar que los desarrolladores cumplan con la calidad esperada de los
productos entregados
Aplicación de la Matriz Guía durante el desarrollo del software, para el
desarrollo de la solución los usuarios deben basarse en la matriz guía de
desarrollo, expresando en la práctica cómo se ejecutan las actividades en cada
flujo de trabajo para ir consiguiendo los productos en el estado de madurez que
exige cada fase.
2.2 HERRAMIENTAS A UTILIZAR
El subsistema se desarrollará con herramientas de Software Libre para cumplir
con los estándares utilizados en otros subsistemas de la EPN dirigidos por la
Dirección de Gestión de la Información y Procesos.
El presente Proyecto de Titulación utilizará como herramientas de desarrollo la
Plataforma Java Enterprise Edition (JEE6) con Primefaces, JBOSS como servidor
de aplicaciones y el gestor de base de datos PostgreSQL por disposición de la
DGIP.
25
Para el modelamiento del subsistema se usará la herramienta case Enterprise
Architect por el soporte que brinda al Proceso Unificado de Desarrollo (PUD) y el
Lenguaje de Modelamiento Unificado (UML).
A continuación se expone una breve introducción de las herramientas que se
usarán para el desarrollo del subsistema.
Plataforma JEE6: Es una plataforma abierta que utiliza un modelo de aplicaciones
distribuido multicapa basada en componentes, centradas en un servidor y
habilitado para la web. Esta permite desarrollar, desplegar y manejar aplicaciones
empresariales, aplicaciones web y aplicaciones móviles.
La Figura 2.4 muestra que las aplicaciones JEE6, son generalmente considerados
como aplicaciones de tres niveles, ya que se distribuyen en tres lugares: las
máquinas de los clientes, la máquina del servidor JEE6, y el servidor de base de
datos.
Figura 2.4: Componentes JEE6 [4]
Un componente es una unidad de software funcional con clases y archivos
relacionados que permiten la comunicación con otros componentes en una
aplicación JEE6. Estos componentes son:
· Componentes Capa Cliente: Páginas web de la aplicación ejecutadas en la
máquina del cliente
26
· Componentes Capa Web: Usan tecnología Java Servlet, Java Server
Faces (JSF) o Java Server Pages (JSP) para crear páginas y aplicaciones
dinámicas, estos componentes son ejecutados en el servidor.
· Componentes Capa Negocio: Usa Enterprise Java Bean (EJB).
Representan la lógica de un negocio concreto y se ejecutan en el servidor
· Componentes Capa de Sistema de Información Empresarial: Es el acceso
a datos y son ejecutadas en el servidor de base de datos es decir en el
sistema de información empresarial.
Primefaces 3.4: Es una librería de componentes para Java Server Faces (JSF) de
código abierto que cuenta con un conjunto de componentes reusables que
facilitan la construcción de una interfaz de usuario en la creación de aplicaciones
web.
JBoss Application Server: Es un servidor de aplicaciones JEE de código abierto
implementado en Java. Al estar basado en Java, JBoss es independiente del
sistema operativo y puede ser utilizado en cualquier sistema operativo para el que
esté disponible la máquina virtual de Java. [5]
JBoss Developer Studio: Es un entorno de desarrollo integrado (IDE) basado en
Eclipse y en la arquitectura orientada a servicios (SOA). Proporciona un
rendimiento superior para todo el ciclo de vida de desarrollo al integrar y certificar
las herramientas y componentes de tiempo de ejecución. Soporta diversos
marcos de programación, incluyendo JEE6, RichFaces, JavaServer Faces (JSF),
Enterprise JavaBeans (EJB), Java Persistence API (JPA) e Hibernate, HTML5,
entre otros. [6]
PostgreSQL: Es un Sistema de Gestión de Bases de Datos Objeto-Relacionales.
Libre y multiplataforma. Tiene cuatro propiedades principales Atomicidad,
Consistencia, Aislamiento y Durabilidad que la convierten una base de datos
ACID. Diseñada para ambientes de alto volumen y una alta concurrencia de
usuarios, posee un Acceso concurrente multiversión (MVCC) que permite que un
proceso escriba en una tabla y otros accedan a la misma tabla sin bloqueos. [7]
[8]
27
Enterprise Architec (modelamiento): “Enterprise Architect es una herramienta de
análisis y diseño intuitiva, flexible y poderosa para construir software robusto y
mantenible. Desde la recolección de requerimientos, pasando por el análisis,
modelado, implementación y pruebas hasta despliegue y mantenimiento,
Enterprise Architect es una herramienta de modelado UML rápida, rica en
funcionalidad, multiusuario, que conduce el éxito de su proyecto de software” [9]
SonarQube (pruebas de código fuente): Es una plataforma de uso libre para
evaluar la calidad del código fuente de una aplicación, siendo compatible con
varios lenguajes de programación. El análisis se realiza en base a 7 ejes de
calidad que son [10]:
· Reglas y estándares de codificación del lenguaje: falta de uso de normas
y estándares formalizados en el código fuente dados para el equipo de
desarrollo.
· Errores y errores potenciales: fragmentos de código que se detectan
como errores leves después del análisis pero que pueden provocar errores
graves en producción, por ejemplo en rendimiento.
· Mala distribución de código por complejidad: condiciones compuestas o
más de 3 niveles de condiciones o bucles (if, for, while, case, catch, throw,
return, &&, ||, ?).
· Duplicación de código: bloques de código duplicados o secuencias de
código usadas repetidamente. Dentro de: 1 mismo archivo, varios archivos
de un proyecto, módulos de un proyecto, y de varios proyectos.
· Demasiados o insuficientes comentarios: poca o mucha documentación
en los métodos y en el API desarrollado.
· Arquitectura y diseño: diseño tallarín con alto nivel de complejidad.
· Falta de pruebas unitarias PU: código fuente que no fue escrito con
enfoque de pruebas unitarias. Las PU son un respaldo que permite validar
que el código fuente haga lo que debe hacer antes y después de realizar
cambios, re factorizar, eliminar duplicados, y/o reducir la complejidad. Con
ellas se mide la cobertura del código fuente.
28
Por cada error encontrado en el código fuente en función de los 7 ejes de calidad
se levanta una evidencia que debe ser corregida, mejorada u optimizada, siendo
así una evidencia no necesariamente un error. Las evidencias se conocen
también como problemas (issues en inglés) o alertas [11].
SonarQube plantea los resultados en forma de Deuda técnica (DT) expresada en
número de días, horas y/o minutos, esta indican el tiempo que el desarrollador se
demorará en mejorar/optimizar/corregir las evidencias. Mientras menos deuda
técnica tenga un proyecto analizado la calidad del código fuente es mayor y se
podría considerar que está en buen estado de salud.
En base a la deuda técnica se categorizan los proyectos analizados tal como se
muestra a continuación:
CATEGORÍA RANGO DE DT ESTADO
A <10% Sano, no hacer nada
B >10% Y <20% Aceptable, medidas preventivas
C >21% Y <50% Poca salud, medidas correctivas
D >51% Y <100% Peligro, urgente cambiar el código
E >100% Rescate, medir el esfuerzo tiempo vs dinero
Tabla 2.3: Categorización Sonarqube
Como se puede observar A es la mejor y E la peor calificación. Esta
categorización se lleva a cabo mediante la técnica SQALE (Software Quality
Assessment based on Lifecycle Expectations), que en base a los 7 ejes de calidad
indicados anteriormente realiza cálculos con algoritmos internos en función de las
evidencias y mide la calidad del código fuente como un todo.
Las evidencias tienen niveles de severidad desde informativos hasta bloqueantes,
tal como se muestra a continuación:
· Bloqueador: evidencia con alta probabilidad de impacto en el
comportamiento de la aplicación (por ejemplo: pérdida de memoria,
conexión JDBC no cerrada,...). El código debe optimizarse
inmediatamente.
29
· Crítico: evidencia con una baja probabilidad de impactar el comportamiento
de la aplicación por complejidad, o un problema que representa una falla
de seguridad (por ejemplo: bloque catch vacío, inyección SQL,...). El
código debe ser revisado inmediatamente para descartar su criticidad.
· Principal: defecto de calidad que puede tener un impacto en la
productividad (por ej.: código no cubierto, bloques duplicados, parámetros
no utilizados,...).
· Menor: defecto de calidad que puede afectar levemente la productividad de
los desarrolladores (por ejemplo: las líneas no deben ser demasiado
largas, las declaraciones "switch" debe tener al menos 3 casos,...).
· Informativo: Ni un error ni un defecto de calidad, sólo un hallazgo.
30
3 DESARROLLO DE LA SOLUCIÓN
Este capítulo se sustenta en la matriz guía de desarrollo que consta en el capítulo
2. Este capítulo está organizado por flujos de trabajo. En cada flujo de trabajo
consta el avance que se consigue en cada fase.
Según lo sugiere la Matriz guía de desarrollo al final de cada fase se logra un
avance de los productos mismos que cada vez son refinados y mejorados.
En el presente proyecto los productos en estado intermedio al término de cada
fase constan como anexos digitales:
· Anexo D7 – Productos Intermedios: Fase Inicio.
· Anexo D8 – Productos Intermedios: Fase Elaboración.
· Anexo D9 – Productos Intermedios: Fase Construcción.
Por otro lado los productos terminados del modelamiento constan impresos en el
ANEXO I - Manual Técnico.
3.1 MODELO DEL NEGOCIO
En el modelo del negocio, para cada uno de los subprocesos administrativos se
reconocieron sus tareas en diagramas de actividades, estos expresan los
procedimientos del área médica que son atendidos por el subsistema.
A continuación se menciona los dos subprocesos administrativos seleccionados
del proceso “Prestación de Servicios de Salud (K.1)” que la UBEYSO solicitó sea
soportado por el subsistema SAMWeb Ver ANEXO D5 – Macro proceso Bienestar
Estudiantil (K) (Anexo Digital):
· Atención Médica Ambulatoria (K.1.1).
· Atención Médica Ginecológica (K.1.3).
Para este proyecto estos subprocesos serán mencionados como procesos.
31
3.1.1 FASE INICIO
Durante la fase de inicio al analizar los dos procesos se apreció que las tareas
que los conforman son similares razón por la cual se propuso a la DGIP su
unificación. El nuevo proceso unificado mantiene el nombre de “Atención médica
ambulatoria” y fue desarrollado en conjunto con la DGIP.
Adicionalmente el personal del Área médica de la UBEYSO solicitó que en el
subsistema se atienda de manera sencilla el manejo de inventario de insumos
médicos, sin embargo se observó que no existe un proceso formal para su
administración.
Por estos inconvenientes en lugar de cumplir el 95% del Modelo del Negocio
esperado en la fase de inicio de acuerdo a la matriz guía de desarrollo, en
realidad se cumplió con el 60%.
Analizando el Proceso administrativo de atención médica ambulatoria se
evidenció que ninguna de las actividades documentadas apoyaba al
reconocimiento de las Políticas del servicio de atención médica como tampoco a
su Análisis.
Los productos que se obtuvieron al final de esta fase constan como anexos
digitales. Ver ANEXO D7 – Documentos: Fase inicio.
3.1.2 FASE ELABORACIÓN
En reuniones sucesivas con diferentes enfermeras de la UBEYSO se estudiaron
las tareas que realiza y se levantó el Proceso de manejo de inventario en conjunto
con la DGIP.
Se afinaron y socializaron los procesos de Atención médica ambulatoria y de
Manejo de inventario. Su revisión y validación se realizó con el representante del
área médica y ginecológica obteniendo ambos la madurez esperada.
Posteriormente las dos propuestas se formalizaron con la DGIP5 llegando a su
consenso y aprobación total, cumpliendo al 100% el Modelo de Negocio. Cabe
mencionar que para su aprobación la DGIP solicitó que estos procesos quedaran
5 La aprobación la realizó la Ing. Mónica Játiva del área de Procesos de la DGIP, quien es responsable de
levantar, formalizar y aprobar los procesos en la EPN.
32
documentados en la herramienta Microsoft Office Visio. Ver ANEXO D6 – Procesos
formalizados con la DGIP.
Estos diagramas de procesos son la base para la identificación de los requisitos
funcionales pues para cada actividad que consta en estos diagramas se analizó si
necesitan apoyo informático.
Finalmente quedaron documentados los procedimientos que intervienen en el
subsistema. Como entregables del modelo del negocio se tienen los siguientes
diagramas de actividades:
· Proceso de atención médica.
· Proceso de manejo de inventario.
· Proceso de políticas del servicio de atención médica y manejo de
inventario.
· Proceso de análisis de políticas del servicio de atención médica y manejo
de inventario.
Los cuales se encuentran en el ANEXO I – Manual Técnico. (1) Modelo del Negocio. Ver
ANEXO D8 – Productos Intermedios: Fase Elaboración.
3.2 MODELO DE REQUISITOS
Los requisitos funcionales y los no funcionales levantados se enfocan en construir
un subsistema que soporte los procesos analizados.
Para el reconocimiento de los requisitos funcionales se revisó cada una de las
actividades del Modelo del Negocio con el fin de reconocer si requerían o no de
apoyo informático. Una actividad que requirió de apoyo informático se ligó a una
nota a manera de requisito funcional. Estos requisitos funcionales se colocaron en
el mismo diagrama de actividades en una columna adicional ubicada a la derecha.
3.2.1 FASE INICIO
Durante la fase de inicio, por las demoras presentadas en el Modelo del negocio
al afinar y formalizar los procesos de atención médica ambulatoria y por no tener
un proceso definido para el manejo de inventario, de acuerdo a la matriz guía de
33
desarrollo en lugar de cumplir el 90% del Modelo de requisitos esperado para esta
fase en realidad se cumplió con el 60%.
Conforme se iban revisando los procesos administrativos para conseguir los
requisitos funcionales también se investigó los requisitos no funcionales exigentes
para este subsistema. Si bien se planificó en un 90% de acuerdo a la matriz guía,
los requisitos no funcionales se definieron en un 100% en esta fase. Ver ANEXO I –
Manual Técnico, (2) Modelo de requisitos, (2.2) Lista de requisitos no funcionales. Ver
ANEXO D7 – Productos Intermedios: Fase Inicio.
Los requisitos no funcionales se reconocieron considerando las características de
los usuarios, los parámetros de calidad esperados y la cobertura geográfica.
3.2.2 FASE ELABORACIÓN
Una vez ratificados los requisitos funcionales y los requisitos no funcionales en la
fase de inicio, y definido el Proceso de manejo de inventario se obtuvo la Lista de
requisitos funcionales reconocidos en el Modelo del negocio y en conjunto con la
afinación y formalización de los procesos considerados se obtiene el 98% del
listado de requisitos funcionales. Si bien se reconocieron la totalidad de los
requisitos funcionales se establece que existe un avance del 98% puesto que falta
una revisión final.
Por cada proceso administrativo se realizó un Diagrama de requisitos a partir de
las notas que constan a la derecha de los Diagramas de actividades del Modelo
del negocio. Estos requisitos funcionales se consideraron como requisitos
centrales en el Diagrama de requisitos. Estos Diagramas de requisitos alcanzan
un avance del 98% en esta fase.
Los Diagramas de requisitos realizados se explotaron al máximo reconociendo
requisitos más pequeños que permitieron complementar los requisitos centrales
llegando al 100%. Ver ANEXO I - Manual Técnico, (2) Modelo de requisitos, (2.3) Diagrama
de requisitos. Ver ANEXO D8 – Productos Intermedios: Fase Elaboración.
3.2.3 FASE DE CONSTRUCCIÓN
Si bien durante las fases anteriores de este flujo y del flujo de trabajo Modelo del
Negocio se refinaron los procesos de atención médica y manejo de inventario y en
34
reuniones con los usuarios y con la Jefe de Desarrollo de la DGIP, en esta fase de
construcción no se reconocieron requisitos adicionales, pero su revisión definitiva
hizo que se consiga el 100% de la Lista de requisitos funcionales. Ver ANEXO I -
Manual Técnico, (2) Modelo de requisitos, (2.1) Lista de requisitos funcionales.
3.3 MODELO DE ANÁLISIS
Para obtener una arquitectura general consistente se analizaron y estructuraron
los requisitos capturados. Para comprender el funcionamiento interno del
subsistema se reconocieron los actores, las clases que intervienen y posibles
riesgos críticos.
3.3.1 FASE INICIO
Durante la fase de inicio, se identificaron como actores a todos los responsables
de actividades de los procesos administrativos para las que se han reconocido
requisitos funcionales, estos constan en el Diagrama de actores que en esta fase
alcanzó el 100% porque se reconocieron a todos los usuarios del subsistema. Ver
ANEXO I - Manual Técnico, (3) Modelo de análisis, (3.1) Diagrama de actores.
Para representar a cada proceso administrativo se reconoció un módulo dentro de
este subsistema para añadirlo al diagrama de casos de uso a nivel contextual.
Este módulo dentro del diagrama de casos de uso a nivel contextual se lo
representa como un caso de uso. Este se completó al 100% en esta fase aunque
metodológicamente se esperaba obtener un 80%. Ver ANEXO I - Manual técnico, (3)
Modelo de análisis, (3.2) Diagrama de casos de uso a nivel contextual.
Para tener una perspectiva de datos del subsistema en esta fase se representó en
un 80% los objetos que constan en el Modelo del negocio en el Diagrama de
clases de análisis, por todas las variantes que se tuvo en la fase anterior
(revisiones y cambios constantes por parte de la DGIP y la UBEYSO para aprobar
los procesos en cuestión).
Mientras se explotaban los requisitos levantados se reconoció como riesgo crítico
no tener formalmente levantado el proceso de manejo de inventario, la falta de
respuesta por parte de la DGIP para la aprobación y formalización de los
35
procesos propuestos, y la falta de conocimiento formal de la teoría de procesos
por parte del personal médico de la UBEYSO. Una vez realizada la Lista de
riesgos críticos y su viabilidad para mitigarlos se tuvo avance real del 80% tal
como se indica en la matriz guía de desarrollo. Ver ANEXO D7 – Productos
Intermedios: Fase Inicio.
3.3.2 FASE ELABORACIÓN
Cuando se concretó la formalización de los procesos analizados se pudo terminar
el Diagrama de clases de análisis porque se estudió qué objetos eran los
necesarios para la ejecución exitosa del subsistema, en ese momento se obtuvo
el 100% de la madurez de dicho diagrama. Ver ANEXO I - Manual técnico, (3) Modelo
de análisis, (3.3) Diagrama de clases de análisis.
La Lista de riesgos críticos con su viabilidad alcanzó el 100%. Ver ANEXO I - Manual
técnico, (3) Modelo de análisis, (3.4) Lista de riesgos críticos y su viabilidad. En paralelo
se mitigaron los riesgos mediante la formalización y aprobación de los procesos
propuestos y la realización de cada una de las formas de viabilidad descritas, aun
cuando los tiempos para este flujo se hayan extendido más de lo previsto. Ver
ANEXO D8 – Productos Intermedios: Fase Elaboración.
3.4 MODELO DE DISEÑO
Para obtener una arquitectura que soporte todos los requisitos reconocidos se
diseñó la parte funcional, estructural, dinámica y despliegue del subsistema
SAMWeb partiendo de los flujos anteriores. Permitiendo así tener un modelo de
diseño que soporte la implementación.
3.4.1 FASE ELABORACIÓN
Para obtener el Diseño funcional del subsistema se representaron los requisitos
centrales del Modelo de requisitos en sus Diagramas de casos de uso por módulo
en un 80% tal como indica en la matriz. Los requisitos centrales representados en
el Modelo de requisitos fueron colocados cada uno como caso de uso base en el
Diagrama de casos de uso por módulo.
36
A continuación se realizó la descripción de casos de uso, inicialmente no había
una evolución notoria en la documentación sino hasta cuando se comprendió el
funcionamiento de cada caso de uso, su desarrollo tuvo un avance real del 70%
aunque se esperaba un 80%. Para la descripción se diseñaron en paralelo las
interfaces web que se mostrarán a los actores del subsistema, en esta actividad
se necesitó de la participación de la DGIP para validar que las interfaces cumplan
con los estándares de presentación manejados por la DGIP.
Para obtener el Diseño estructural del subsistema se verificó que las estructuras
de datos reconocidas satisfagan la funcionalidad de cada caso de uso
transformando las clases del diagrama de clases de análisis en clases del
diagrama de clases de diseño con sus atributos y métodos. Específicamente en la
clase paciente, los usuarios expertos han definido que, los atributos nombres y
apellidos deben estar por separado: nombre1, nombre2, apellido1 y apellido2,
para procurar la calidad en la captura de la información y para facilitar la
identificación del paciente.6 Para el atributo correspondiente al número de cédula
de identidad, el campo se lo denominó como numeroCedula tal como lo indica la
cédula de identidad como documento público.7
Paralelamente se realizó un Diccionario de datos del diagrama de clases con la
finalidad de facilitar su comprensión. Además se instanció cada una de las clases
en un Diagrama de objetos. Todos estos diagramas se realizaron en un 60% y se
esperaba un 80%.
Para obtener el Diseño dinámico del subsistema se realizó el Diagrama de
actividades de los casos de uso que se consideraron complejos. En este caso
solo se escogió el caso de uso de Registrar atención médica. Este se realizó en 6 En la Ley Orgánica de Gestión de la Identidad y Datos Civiles, Título III Hechos y actos relativos al estado
civil de las personas, Capítulo III Inscripciones y registros extraordinarios, Artículo 36 – Nombres en la
inscripción de nacimiento, se establece que no podrá asignarse más de dos nombres simples o uno
compuesto. Y en la misma ley Artículo 37 – Apellidos en la inscripción de nacimiento, indica que los
apellidos serán el primero de cada uno de los padres, o si existe una sola filiación se asignarán los mismos
apellidos del progenitor que realiza la inscripción, en caso de tener el progenitor o progenitora un solo
apellido se le asignará al inscrito dos veces el mismo apellido. Según la disposición tramitada el 28 de enero
de 2016. Sesión 367 de la Asamblea Nacional del Ecuador. 7 En la Ley Orgánica de Gestión de la Identidad y Datos Civiles, Título V Cédula de identidad, Capítulo I
Disposiciones comunes, Artículo 94 – Contenido, indica que la cédula de identidad contendrá… el número
de cédula,… nombres y apellidos del titular…. Según la disposición tramitada el 28 de enero de 2016. Sesión
367 de la Asamblea Nacional del Ecuador.
37
un nivel de madurez del 50% al igual que los Diagramas de secuencia de los
casos de uso que llaman métodos de clases, puesto que inicialmente no se
definía en su totalidad la descripción de todos los caso de uso.
Se identificó que el objeto “Movimiento de inventario” cambia de estado, motivo
por el cual se desarrolló el Diagrama de estados para este objeto en un 80%,
cumpliendo con el porcentaje de madurez acordado en la matriz guía de
desarrollo para esta fase.
Para obtener el Diseño de despliegue del subsistema se realizó el Diagrama de
componentes y el Diagrama de despliegue en un 100%. Ver ANEXO I - Manual
técnico, (4) Modelo de diseño, (4.4) Diseño de despliegue, (4.4.1) Diagrama de
componentes, (4.4.2) Diagrama de despliegue.
3.4.2 FASE CONSTRUCCIÓN
El Diseño funcional y el Diseño estructural del subsistema se completaron al
100% con todos sus diagramas inclusive con la retroalimentación necesaria por el
nuevo requisito presentado. Ver ANEXO I - Manual Técnico, (4) Modelo de Diseño, (4.1)
Diseño funcional y (4.2) Diseño estructural.
En el Diseño dinámico del subsistema se completó el Diagrama de Actividades
del casos de uso registrar atención médica. Ver ANEXO I - Manual Técnico, (4) Modelo
de Diseño, (4.3) Diseño dinámico, (4.3.1) Diagrama de actividades del caso de uso registrar
atención médica. Los diagramas de secuencia de casos de uso que llaman a
métodos de clases alcanzaron el 100% de su nivel de madurez. Estos diagramas
de secuencia son:
· Diagrama de secuencia del caso de uso Registrar apertura de HCL.
· Diagrama de secuencia del caso de uso registrar atención médica.
· Diagrama de secuencia del caso de uso consultar historial clínico.
· Diagrama de secuencia del caso de uso registrar orden de despacho de
insumos médicos.
· Diagrama de secuencia del caso de uso registrar insumo médico.
· Diagrama de secuencia del caso de uso registrar movimiento de inventario.
38
· Diagrama de secuencia del caso de uso registrar despacho de insumos
médicos.
Ver ANEXO I - Manual Técnico, (4) Modelo de Diseño, (4.3) Diseño dinámico, (4.3.2)
Diagramas de secuencia de los casos de uso que llaman a métodos de clases.
El Diagrama de estados para el objeto Movimiento de inventario se desarrolló al
100%. Ver ANEXO I - Manual Técnico, (4) Modelo de Diseño, (4.3) Diseño dinámico, (4.3.3)
Diagrama de estados de objetos que cambian de estado.
Al término de esta fase se receptó a última hora un requisito que no se lo trató
desde un inicio, Registrar presentación de documentos de salud de estudiantes
nuevos, lo que obligó a modificar la documentación y los modelos generados
hasta ese momento realizando una retroalimentación. Se declaró el nuevo caso
de uso, se lo describió, se analizó si se cumplía o no con la estructura de datos
necesaria para su funcionamiento y se revisó que su implementación no afectara
a ningún cambio de estado de los objetos existentes.
Se observó que llamaba a métodos de la base de datos por lo cual se realizó el
respectivo diagrama de secuencia. Ver ANEXO I - Manual Técnico, (4) Modelo de
Diseño, (4.3) Diseño dinámico, (4.3.2) Diagramas de secuencia de los casos de uso que
llaman a métodos de clases.
3.5 IMPLEMENTACIÓN
En el flujo de trabajo Implementación se consideró el modelamiento de diseño
para desarrollar y estructurar el producto de software.
Para la implementación del subsistema el equipo de desarrollo se acopló a las
tecnologías y estándares usados por la DGIP. Como tecnologías se utilizaron las
siguientes:
· Como IDE de desarrollo: JBoss Developer Studio 5 y Eclipse Luna.
· Para el back-end: Enterprise Java Beans (EJB 3.1) y JEE6.
· Para el front-end: Java Server Faces (JSF) 2.0, Prime faces 3.4, JavaScript, y
JQuery.
· Para la persistencia: JPA 2.0.
39
· Para generar reportes: JasperReports® Library.
· Para la base de datos: Postgres 9.X.
· Para el despliegue de aplicaciones web: jboss-as-7.1.3.
En este flujo de trabajo se llevó a cabo:
· La generación de la base de datos.
· El desarrollo del código fuente del subsistema.
Este flujo de trabajo Implementación fue desarrollado durante las fases de
elaboración y de construcción.
3.5.1 FASE DE ELABORACIÓN
Para comenzar esta fase, la DGIP (encargada de los desarrollos web en la EPN),
dispuso las indicaciones técnicas de implementación.
Se estableció que para este proyecto la implementación debe estar divida en dos
proyectos, la presentación en un proyecto web y el negocio en un proyecto de
servicios.
El proyecto web estará constituido por:
· Páginas JSF.
· Controladores de página BakingBean.
· Conexión con los sistemas relacionados.
Los controladores de página BackingBean se deben comunicar por medio de
interfaces con el proyecto de servicios.
El proyecto de servicios está constituido por:
· Clases de negocio de tipo EJB, es decir, los servicios ServiceBean con sus
respectivas interfaces Service.
· Entidades de negocio mapeadas directamente con el modelo de base de
datos.
Cada proyecto debe estar organizado por paquetes en un explorador.
40
Al proyecto web se lo denominó AtencioMedica y al proyecto de servicios se lo
denominó ServiciosAtencionMedica.
Una vez definida la arquitectura del subsistema SAMWEB se continuó con la
implementación, en el proyecto web AtencionMedica, se codificaron las pantallas
iniciales correspondientes a los módulos de Atención médica ambulatoria, Manejo
de inventario y Políticas de Atención Médica e Inventario:
· Atención Médica Ambulatoria.
o Registrar Apertura HCL.
o Registrar Atención Médica.
o Registrar Docs de Salud.
· Manejo de Inventario.
o Registrar Despacho.
o Registrar Movimiento Inventario.
· Políticas Atención M / Inventario.
o Registrar Insumo Médico.
Se obtuvo un avance aproximado del 15% del código fuente aun cuando se
esperaba un avance planificado del 20%.
3.5.2 FASE DE CONSTRUCCIÓN
En esta fase se desarrolló:
· La base de datos.
· El código fuente.
3.5.2.1 Base de datos
Dentro del mismo ambiente del modelamiento se partió del diagrama de clases de
diseño para generar la estructura de la base de datos, representando cada tabla a
cada clase, cada una con los atributos correspondientes.
Una vez generada la estructura de base de datos inicial se analizó y se encontró
que varias tablas, las que tienen que ver con tipos (tablas referenciales o
manuales o catálogos), por tener un comportamiento similar deberían ser tratadas
de una manera global y estandarizada. Estas tablas son:
41
· Tipo_paciente.
· Tipo_atencion_medica.
· Tipo_especialidad.
· Tipo_movimiento_inventario.
· Tipo_estado_movimiento_inventario.
· Tipo_insumo_medico.
· Tipo_presentacion_insumo_medico.
Se decidió juntarlas en una estructura de dos tablas CATALOGO y
CATALOGOTIPO ya que esto simplificaría la codificación del mantenimiento y el
trato de dichas tablas. La estructura de la base de datos SAMWeb consta en el
Manual técnico. Ver Anexo I – Manual técnico. Estructura de la base de datos SAMWeb.
Los métodos específicos de sus correspondientes clases del diagrama de clases
de diseño fueron tratados de forma generalizada a través de las clases de
implementación CATALOGO y CATALOGOTIPO.
Una vez afinada la Estructura de base de datos SAMWeb se generó el Script sql
respectivo y se lo ejecutó en el motor de base de datos Postgres Ver Anexo D9 –
Script de la base de datos SAMWeb – 1_scriptBDD.sql.
Luego se cargaron datos iniciales para las tablas CATALOGO, CATALOGOTIPO,
TOPOGRAFIACIE, PERSONAL e INSUMOMEDICO, con el fin de tener datos
base para comenzar con el desarrollo de SAMWeb. Ver Anexo D10 – Script de la base
de datos SAMWeb – 2_CatalogosDeTipos.sql - 3_ TopografiaCIE.sql. Para completar esta
tarea la DGIP facilitó un respaldo de base de datos corporativo “bddcorpepn.bak”
que contenía la mayoría de esquemas de los subsistemas de la EPN. Sobre esa
base de datos se ejecutó el script sql generado para crear el esquema: “Médico”.
Dentro del proyecto de servicios se crearon las entidades mapeándolas como
Entities desde las tablas de la base de datos.
La DGIP solicitó que el acceso al subsistema SAMWeb sea a través de su propio
módulo de autentificación ya implementado “Central Authentication Service”
(CAS). Este lee las configuraciones de seguridad desde el esquema de base de
datos “public” y presta las siguientes funcionalidades:
42
· Controlar la autentificación de usuarios.
· Generación de menús y submenús.
· Autorización de acceso a los menús, submenús y funcionalidades.
Con la mayoría de las pantallas codificadas y a partir de los Diagramas de casos
de uso por módulo se consideraron los actores para definir Perfiles de acceso a
los diferentes menús del subsistema SAMWeb tal como se indica en la siguiente
tabla:
NOMBRE DEL MENÚ (NOMBRE PANTALLA IMPLEMENTADA)
PERFIL
MÉDICO ENFERMERA DIRECTOR
Atención Médica Ambulatoria
Registrar Apertura HCL (registrarAperturaHCL.xhtml)
X
Registrar Atención Médica (registrarAtencionMedica.xhtml)
X
Registrar Docs de Salud (registrarPresentacionDocumentosM.xhtml)
X
Manejo de Inventario Registrar Despacho (registrarDespacho.xhtml)
X
Registrar Movimiento Inventario (registrarMovimientoInventario.xhtml)
X X
Análisis Atención M / Inventario Reportes (reportesAtencionMedica.xhtml)
X X X
Políticas Atención M / Inventario Registrar Personal (registrarPersonal.xhtml)
X
Registrar Insumo Médico (registrarInsumoMedico.xhtml)
X
Registrar Catálogo (registrarCatalogo.xhtml)
X X
Tabla 3.1: Menús vs Roles de acceso
Después se insertaron los registros necesarios para la generación de menús, la
autentificación de usuarios y el control de acceso autorizado a las distintas
páginas y funcionalidades codificadas. Ver Anexo D9 – Script de la base de datos
SAMWeb – 4_script inserts esquema public.sql. La inserción se realizó en el esquema
Public de la base de datos bddcorpepn en las tablas:
· Usuario.
· Perfil.
· Perfil_usuario.
43
· Aplicación.
· Menú.
· Autorización.
Una vez finalizado el afinamiento de los datos iniciales de SAMWeb en los
esquemas “Public “y “Medico”, se realizó un respaldo con todos los catálogos y
configuraciones de seguridad de la Base de datos inicial “bddcorpepn”. Ver Anexo
D11 – Respaldo de la Base de Datos.
3.5.2.2 Código fuente
Con respecto al código fuente, en esta fase se mejoraron las pantallas realizadas
previamente en la fase elaboración y se codificaron nuevas pantallas para:
· Políticas Atención M / Inventario.
o Registrar Personal.
· Análisis Atención M / Inventario.
o Reportes.
Se codificaron las funcionalidades correspondientes al proyecto
ServiciosAtencionMedica descritas en los casos de uso base y sus dependientes,
entre ellas:
· Registrar apertura de HCL.
· Registrar atención médica.
· Registrar despacho de orden de insumos médicos.
· Registrar movimiento de insumos médicos.
· Registrar personal.
· Registrar insumo médico.
Para el registro de datos de la tabla CATALOGO se construyó una sola
funcionalidad que atiende a los casos de uso que constan pintados de celeste en
el “Diagrama de CU del módulo del proceso de políticas del servicio de atención
médica y manejo de inventario”, estos son:
· Registrar tipos de paciente (Digitado).
· Registrar tipos de atención médica (Digitado).
· Registrar tipos de especialidad (Digitado).
44
· Registrar tipos de movimiento de inventario (Digitado).
· Registrar tipos de estado de movimiento de inventario (Digitado).
· Registrar tipos de presentación de insumo médico (Digitado).
· Registrar tipos de insumo médico (Digitado).
Se mejoró la pantalla correspondiente al caso de uso “Administrar criterios de
selección” (Reportes) del “Diagrama de casos de uso de Análisis del servicio de
atención médica y manejo de inventario”. En primera instancia su implementación
se inició con la herramienta Business Intelligence and Reporting Tools (BIRT)
pero a solicitud de la DGIP se cambió a JasperReports. Para esto se
estructuraron plantillas que fueron llamadas dinámicamente desde el controlador
de la interfaz gráfica web.
La curva de aprendizaje que tomó estudiar BIRT fue considerable por lo que esto
retrasó los tiempos de la planificación; luego para cambiar la implementación de
los reportes con JasperReports se tomó una versión anterior del proyecto web
previo a la configuración con BIRT.
En las opciones Registrar apertura de HCL y Registrar personal la DGIP
estableció a último momento que SAMWeb, para implementar la funcionalidad de
consulta de datos de identificación, debe únicamente conectarse con el servicio
web del Registro Civil con el fin de agilitar el desarrollo.
A medida que se avanzó en la construcción del código fuente y se agregaron las
validaciones correspondientes se determinó que SAMWEB debe estar conectado
también con el servicio web del subsistema SAEW para tomar datos de
identificación de todos los pacientes de tipo Estudiante, mientras que para los
pacientes de tipo Administrativo debe hacerlo mediante consultas sql al esquema
de base de datos “RRHH” (Recursos Humanos). Esto implicó que se aplique el
acuerdo original planteado en este proyecto con la DGIP.
Además la DGIP sugirió que la conexión al servicio web del Registro Civil se
mantenga simultáneamente para la consulta de datos de identificación cuando el
servicio SAEW y el esquema de base de datos RRHH se encuentren inactivos o
no disponibles.
45
En esta fase Construcción se obtuvo un avance del 100% de la Estructura de la
base de datos, del Script sql y la preparación de la Base de datos inicial.
El código fuente del subsistema tuvo un avance real del 90%, se esperaba un
avance del 98%.
3.5.3 FASE DE TRANSICIÓN
Debido al nuevo caso de uso “Registrar presentación de documentos de salud de
estudiantes nuevos” se procedió con su implementación codificando la interfaz
gráfica web “Registrar Docs de Salud” y la funcionalidad respectiva.
Una vez estable el subsistema SAMWeb con sus interfaces y funcionalidades
probadas a nivel de desarrollo se refinó la generación de reportes y se afinó la
ortografía, mensajes, etiquetas, títulos de páginas, íconos de botones y logos de
todas las interfaces.
El código fuente del subsistema alcanzó un porcentaje de madurez del 100%. De
esta manera el producto quedó listo para ser evaluado dentro del Flujo de trabajo
Pruebas. Ver Anexo D12 – Código fuente del subsistema.
3.6 PRUEBAS
Para evaluar la calidad de los productos generados, en el flujo de trabajo Pruebas
se definió la estrategia, se realizó el plan de pruebas y se lo ejecutó.
3.6.1 FASE INICIO
En la fase de inicio se estableció la estrategia del plan de pruebas y el plan de
pruebas al 100%.
Estrategia del plan de pruebas
Para este proyecto las pruebas se orientaron a los siguientes temas:
· Modelamiento del software.
· Implementación vs modelamiento.
· Producto de software.
46
Para cada uno de estos temas se establece la estrategia de pruebas en términos
de: objetivo de la prueba, tipo de prueba que se aplicará, la técnica y la
periodicidad. La estrategia y el plan fueron definidos considerando el estándar de
pruebas International Software Testing Qualifications Broad (ISTQB) [12, pp. 64-
66]
Estrategia del plan de prueba del modelamiento del software:
· Objetivo: verificar que los modelos sean consistentes entre sí y satisfagan
los requisitos.
· Tipo de prueba: revisión.
· Técnica: estática de revisión manual de los modelos.
· Periodicidad: por cada fase del PUD a la que aplique.
Estrategia del plan de prueba del modelamiento vs implementación:
· Objetivo: verificar si la Implementación (codificación y construcción de la
base de datos) respetan el modelamiento de Diseño.
· Tipo de prueba: revisión.
· Técnica: estática de revisión del código vs documentación del
modelamiento del software.
· Periodicidad: por cada fase del PUD a la que aplique.
Estrategia del plan de prueba del producto de software.
Se realizarán pruebas de funcionalidad con el usuario experto, pruebas de
funcionalidad con el técnico informático y pruebas de código fuente.
Pruebas de funcionalidad con el usuario experto:
· Objetivo: validar que la funcionalidad del software desarrollado satisfaga las
necesidades del usuario experto.
· Tipo de prueba: funcional - caja negra.
· Técnica: dinámica.
· Periodicidad: al final de la fase construcción.
Pruebas de funcionalidad con el técnico informático:
· Objetivo: validar con el técnico informático la funcionalidad del software
desarrollado para su aceptación.
47
· Tipo de prueba: funcional - caja negra.
· Técnica: dinámica.
· Periodicidad: al final de la fase construcción.
Pruebas de código fuente · Objetivo: validar la calidad del código fuente mediante la aplicación de una
herramienta de análisis, revisar los resultados del análisis y realizar ajustes
respectivos para mejorar el código fuente.
· Tipo de prueba: estructural.
· Técnica: estática – análisis automatizado del código.
· Periodicidad: durante la fase de transición.
Plan de pruebas
La siguiente tabla expresa la planificación para el plan de pruebas:
TEMA A EVALUAR
TIPO DE PRUEBA
PARTICIPANTES FASE RESULTADOS ESPERADOS
Pruebas de modelamiento del software (MS)
Modelo del negocio
MS
Responsable de la DBEYSO Responsable de la DGIP Desarrolladores
Al principio de la fase de Elaboración y Construcción
Aceptación / Defectos
Modelo de requisitos
MS Responsable de la DGIP Desarrolladores
Elaboración y Construcción
Aceptación / Defectos
Modelo de análisis
MS Responsable de la DGIP Desarrolladores
Elaboración y Construcción
Aceptación / Defectos
Modelo de diseño: modelo funcional
MS Responsable de la DGIP Desarrolladores
Elaboración y Construcción
Aceptación / Defectos
Modelo de diseño: modelo estructural
MS Responsable de la DGIP Desarrolladores
Elaboración y Construcción
Aceptación / Defectos
Modelo de diseño: diseño dinámico
MS Responsable de la DGIP Desarrolladores
Construcción Aceptación
Modelo de diseño: diseño despliegue
MS Responsable de la DGIP Desarrolladores
Construcción Aceptación
Tabla 3.2: Plan de pruebas
48
TEMA A EVALUAR
TIPO DE PRUEBA
PARTICIPANTES FASE RESULTADOS ESPERADOS
Pruebas de implementación vs modelamiento
Implementación del Modelo de análisis
I-M Responsable de la DGIP Desarrolladores
Construcción Aceptación
Implementación del Modelo de diseño: diseño funcional
I-M Responsable de la DGIP Desarrolladores
Construcción Aceptación
Implementación del Modelo de diseño: diseño estructural
I-M Responsable de la DGIP Desarrolladores
Construcción Aceptación
Implementación del Modelo de diseño: diseño dinámico
I-M Responsable de la DGIP Desarrolladores
Construcción Aceptación
Implementación del Modelo de diseño: diseño despliegue
I-M Responsable de la DGIP Desarrolladores
Construcción Aceptación
Pruebas del producto de software
Funcionalidad del subsistema revisada por casos de uso.
PS-FTI Director de la DGIP Desarrolladores
Al final de la fase Construcción
Aceptación
Funcionalidad del subsistema revisada por casos de prueba
PS-FUE Responsable de la DBEYSO Desarrolladores
Al final de la fase Construcción
Aceptación
Estándares de codificación, duplicación, comentarios
PS-CF Desarrolladores Transición Aceptación / Defectos
Tipo de prueba: Modelamiento del software (MS), Implementación vs modelamiento (I-M), Producto de
software - Funcionalidad con el técnico informático (PS-FTI). Producto de software - Funcionalidad con el
usuario experto (PS-FUE). Producto de software - Código fuente (PS-CF).
Tabla 3.2: Plan de pruebas (Continuación)
Los parámetros de modelamiento tuvieron un avance del 50%, quedando
pendientes los parámetros para la evaluación al modelado vs implementación y
los parámetros de evaluación del producto. Los parámetros de evaluación del
modelamiento se encuentran en la: segunda columna “Evaluación”.
3.6.2 FASE ELABORACIÓN
En relación a la ejecución de las pruebas se llevó a cabo la evaluación del
modelamiento que estuvo planificado en un 50%. Ver columnas: “Revisado por”,
49
“Fecha de revisión”, “Observación”. Se verificaron los avances realizados hasta la
fase de elaboración. Hasta ese momento la aplicación de las pruebas generaron
cumplimiento solo en algunas evaluaciones (color verde), mientras que otras
evaluaciones quedaron pendientes con observaciones que deben ser cumplidas
(color amarillo) hasta la siguiente revisión.
Tema a evaluar
Evaluación Revisado por
Fecha de revisión
Observación (Si cumple / No cumple)
Modelo del negocio
1. ¿Se han descrito todos los procesos administrativos que van a ser atendidos por el subsistema en el Diagrama de actividades de los procesos administrativos del negocio?
Dr. Patricio Lopez, Ing. Geovanna Saltos Diana Oña, Andrés Rosero
25/07/2014 No cumple, porque la institución decide añadir un nuevo proceso llamado Manejo de inventario.
Modelo de Requisitos
2. ¿Se han reconocido las actividades administrativas que necesitan soporte informático como requisitos funcionales globales?
Ing. Geovanna Saltos Diana Oña, Andrés Rosero
25/07/2014 No cumple, se reconoció la actividad administrativa Abrir HCL pero no se reconoció el requisito Registrar presentación de documentos de salud de estudiantes nuevos.
Modelo de Requisitos
3. ¿Se han validado que todos los requisitos reconocidos en el modelo del negocio consten como requisitos centrales en el Diagrama de requisitos?
Ing. Geovanna Saltos Diana Oña, Andrés Rosero
25/07/2014 No cumple, el requisito Registrar presentación de documentos de salud de estudiantes nuevos no consta en el Diagrama de requisitos
4. ¿Se han desglosado a detalle en requisitos más pequeños y explicativos los requisitos centrales?
Ing. Geovanna Saltos Diana Oña, Andrés Rosero
25/07/2014 No cumple, el requisito central Registrar presentación de documentos de salud de estudiantes nuevos no ha sido desglosado.
Tabla 3.3: Evaluación del modelamiento Fase de elaboración
50
Tema a evaluar
Evaluación Revisado por
Fecha de revisión
Observación (Si cumple / No cumple)
Modelo de Análisis
5. ¿Se han definido los actores que van a ser usuarios del subsistema?
Ing. Geovanna Saltos Diana Oña, Andrés Rosero
25/07/2014 Si cumple
Modelo de requisitos
6. ¿Se han considerado las características de los usuarios, la cobertura geográfica y los principios de calidad de software en la Lista de requisitos no funcionales?
Ing. Geovanna Saltos Diana Oña, Andrés Rosero
25/07/2014 Si cumple
Modelo de análisis
7. ¿Se satisfacen todos los requisitos en los casos de uso del Diagrama de casos de uso a nivel contextual?
Ing. Geovanna Saltos Diana Oña, Andrés Rosero
25/07/2014 Si cumple
8. ¿Todos los casos de uso han sido atendidos por algún actor definido en el Diagrama actores?
Ing. Geovanna Saltos Diana Oña, Andrés Rosero
19/06/2014 Si cumple
9. ¿Han sido atendidos todos los requisitos que constan en el modelo del negocio en alguno de los módulos que constan en el diagrama de casos de uso a nivel contextual?
Ing. Geovanna Saltos Diana Oña, Andrés Rosero
25/07/2014 Si cumple
10. ¿Se han reconocido todos los objetos principales que constan en el Diagrama actividades de los procesos administrativos del negocio representados en el Diagrama de clases de análisis?
Ing. Geovanna Saltos Diana Oña, Andrés Rosero
25/07/2014 Si cumple
Tabla 3.3: Evaluación del modelamiento Fase de elaboración (Continuación)
51
Tema a evaluar
Evaluación Revisado por
Fecha de revisión
Observación (Si cumple / No cumple)
Modelo de análisis
9. ¿Han sido atendidos todos los requisitos que constan en el modelo del negocio en alguno de los módulos que constan en el diagrama de casos de uso a nivel contextual?
Ing. Geovanna Saltos Diana Oña, Andrés Rosero
25/07/2014 Si cumple
10. ¿Se han reconocido todos los objetos principales que constan en el Diagrama actividades de los procesos administrativos del negocio representados en el Diagrama de clases de análisis?
Ing. Geovanna Saltos Diana Oña, Andrés Rosero
25/07/2014 Si cumple
Modelo de diseño: diseño
funcional
11. ¿Se ha desglosado cada caso de uso del Diagrama casos de uso a nivel contextual en el Diagrama casos de uso por módulo?
Ing. Geovanna Saltos Diana Oña, Andrés Rosero
25/07/2014 Si cumple
12. ¿Se ha satisfecho cada requisito del Modelo del negocio en casos de uso?
Ing. Geovanna Saltos Diana Oña, Andrés Rosero
25/07/2014 No cumple, el requisito Registrar presentación de documentos de salud de estudiantes nuevos no se ha satisfecho en ningún caso de uso.
13. ¿Se han validado que cada requisito central en el Diagrama de requisitos consta como caso de uso base?
Ing. Geovanna Saltos Diana Oña, Andrés Rosero
25/07/2014 No cumple, el requisito central Registrar presentación de documentos de salud de estudiantes nuevos no consta como caso de uso base.
14. ¿Se han reconocido las funcionalidades que se repiten dentro de los casos de uso base, que se puedan unificar en casos de uso incluidos?
Ing. Geovanna Saltos Diana Oña, Andrés Rosero
25/07/2014 Si cumple
Tabla 3.3: Evaluación del modelamiento Fase de elaboración (Continuación)
52
Tema a evaluar
Evaluación Revisado por
Fecha de revisión
Observación (Si cumple / No cumple)
Modelo de diseño: diseño
funcional
15. ¿Se han reconocido si existen funcionalidades adicionales que se puedan representar en casos de uso extensores?
Ing. Geovanna Saltos Diana Oña, Andrés Rosero
25/07/2014 Si cumple
16. ¿Se ha verificado que en el Diagrama de casos de uso por módulo conste la Descripción de casos de uso y las restricciones y escenarios para cada caso uso?
Ing. Geovanna Saltos Diana Oña, Andrés Rosero
25/07/2014 No cumple, falta la descripción del caso de uso Registrar presentación de documentos de salud de estudiantes nuevos es notificado y se requiere realizar la retroalimentación respectiva.
Modelo de diseño: diseño
estructural
17. ¿Se ha satisfecho la funcionalidad de cada caso de uso del Diagrama casos de uso por módulo mediante la definición de clases que se necesiten en el Diagrama clases de diseño?
Ing. Geovanna Saltos Diana Oña, Andrés Rosero
25/07/2014 Si cumple
18. ¿Se han verificado que todos los atributos que se requieren para la funcionalidad de cada caso de uso, en el Diagrama casos de uso por módulo consten como atributo en el Diagrama clases de diseño?
Ing. Geovanna Saltos Diana Oña, Andrés Rosero
25/07/2014 Si cumple
19. ¿Se han revisado que toda clase definida en el Diagrama de clases de análisis conste en el Diagrama clases de diseño de manera explotada con atributos, métodos?
Ing. Geovanna Saltos Diana Oña, Andrés Rosero
25/07/2014 Si cumple
Tabla 3.3: Evaluación del modelamiento Fase de elaboración (Continuación)
53
Tema a evaluar
Evaluación Revisado por
Fecha de revisión
Observación (Si cumple / No cumple)
Modelo de diseño: diseño
estructural
20. ¿Se han comprobado que todos los métodos que acceden a la base de datos en un caso de uso consten como métodos en el Diagrama clases de diseño?
Ing. Geovanna Saltos Diana Oña, Andrés Rosero
25/07/2014 Si cumple
Tabla 3.3: Evaluación del modelamiento Fase de elaboración (Continuación)
Adicionalmente se completa el 100% del Plan de pruebas respecto de los
parámetros de Evaluación del Modelamiento. Ver Tabla 3.4: Evaluación del
modelamiento Fase Construcción, segunda columna “Evaluación” a partir del numeral
22 (color blanco).
3.6.3 FASE CONSTRUCCIÓN
En esta fase se concluyó las Pruebas de la evaluación del modelamiento, se
planificaron en su totalidad las Pruebas del modelamiento vs implementación, a la
vez que fueron ejecutadas y también se terminó la planificación de las Pruebas
del producto que también se aplicaron. A continuación se detallan:
3.6.3.1 Pruebas del modelamiento
La evaluación planificada que corresponde al modelamiento se completó al 100%
consta en la Tabla 3.4: Evaluación del modelamiento Fase Construcción en la
segunda columna “Evaluación”. En esta columna se puede notar que:
· Se resalta en amarillo evaluaciones complementarias de puntos ya
evaluados en la Fase de elaboración que quedaron como puntos
pendientes. El numeral se mantiene igual al plan original hasta la
evaluación nº 17.
· Se aplican las nuevas validaciones para completar la evaluación del
modelamiento, a partir del numeral 22.
Se ejecutaron todas las pruebas restantes para verificar la validez del
modelamiento, es decir, las revisiones parciales fruto de las evaluaciones
pendientes y las evaluaciones nuevas.
54
Como conclusión de las pruebas, al final de esta fase, se determinó que la
evaluación se cumple para todo el modelamiento (color verde), en la siguiente
tabla columna “Observación”.
Tema a evaluar
Evaluación Revisado por Fecha de revisión
Observación (Si cumple / No cumple)
Modelo del negocio
1. ¿Se ha levantado y formalizado el proceso administrativo Manejo de Inventario?
Dr. Patricio Lopez, Ing. Geovanna Saltos Ing. Mónica Játiva, Diana Oña, Andrés Rosero
12/08/2014 Si cumple
Modelo de requisitos
2. ¿Se reconoció como requisito funcional global al requisito Registrar presentación de documentos de salud de estudiantes nuevos?
Ing. Geovanna Saltos Diana Oña, Andrés Rosero
12/08/2014 Si cumple
3. ¿El requisito Registrar presentación de documentos de salud de estudiantes nuevos consta como requisito central en el Diagrama de requisitos?
Ing. Geovanna Saltos Diana Oña, Andrés Rosero
30/10/2014 Si cumple
4. ¿Se ha desglosado a detalle en requisitos más pequeños y explicativos el requisito central Registrar presentación de documentos de salud de estudiantes nuevos?
Ing. Geovanna Saltos Diana Oña, Andrés Rosero
30/10/2014 Si cumple
12. ¿Se ha satisfecho el requisito Registrar presentación de documentos de salud de estudiantes nuevos del Modelo del negocio en un caso de uso?
Ing. Geovanna Saltos Diana Oña, Andrés Rosero
30/10/2014 Si cumple
13. ¿El requisito central Registrar presentación de documentos de salud de estudiantes nuevos consta como caso de uso base?
Ing. Geovanna Saltos Diana Oña, Andrés Rosero
30/10/2014 Si cumple
Tabla 3.4: Evaluación del modelamiento Fase Construcción
55
Tema a evaluar
Evaluación Revisado por Fecha de revisión
Observación (Si cumple / No cumple)
Modelo de análisis
14. ¿Se ha verificado que todos los requisitos son atendidos por algún caso de uso?
Diana Oña, Andrés Rosero
25/07/2014 Si cumple. Ver Figura 3.1 Cruce de requisitos vs casos de uso
Modelo de diseño: diseño
funcional
16. ¿Se ha verificado que en el Diagrama de casos de uso por módulo conste la Descripción de casos de uso y las restricciones y escenarios para el caso uso Registrar presentación de documentos de salud de estudiantes nuevos?
Ing. Geovanna Saltos Diana Oña, Andrés Rosero
30/10/2014 Si cumple
Modelo de diseño: diseño
estructural
17. ¿Se ha satisfecho la funcionalidad del caso de uso Registrar presentación de documentos de salud de estudiantes nuevos del Diagrama casos de uso por módulo mediante la definición de clases que se necesiten en el Diagrama clases de diseño?
Ing. Geovanna Saltos Diana Oña, Andrés Rosero
30/10/2014 Si cumple
22. ¿Se ha validado que todos los tipos de datos que manejan las diferentes clases definidas en el Diagrama de clases de diseño consten en el Diccionario de datos del diagrama de clases?
Ing. Geovanna Saltos Diana Oña, Andrés Rosero
30/10/2014 Si cumple
Modelo de diseño: diseño
dinámico
23. ¿Se han realizado los Diagramas de actividades de casos de uso complejo para los casos de uso complicados?
Ing. Geovanna Saltos Diana Oña, Andrés Rosero
22/12/2014 Si cumple
24. ¿Se verificaron que constan todos los envíos de mensajes como métodos en el Diagrama de clases de diseño?
Ing. Geovanna Saltos Diana Oña, Andrés Rosero
22/12/2014 Si cumple
25. ¿Todos los objetos que están implícitos en el Diagrama de actividades de casos de uso complejo constan en el Diagrama de objetos?
Ing. Geovanna Saltos Diana Oña, Andrés Rosero
22/12/2014 Si cumple
Tabla 3.4: Evaluación del modelamiento Fase Construcción (continuación)
56
Tema a evaluar
Evaluación Revisado por Fecha de revisión
Observación (Si cumple / No cumple)
Modelo de diseño: diseño
dinámico
26. ¿Se ha creado un Diagrama de estados por cada objeto que en el tiempo cambia de estado?
Ing. Geovanna Saltos Diana Oña, Andrés Rosero
22/12/2014 Si cumple
27. ¿Se han verificado que el cambio de estado de un objeto se debe dar por medio de un método especificado en el Diagrama de clases de diseño dado por un escenario de algún caso de uso y que estos consten en el Diagrama de estados de objetos que cambian de estado?
Ing. Geovanna Saltos Diana Oña, Andrés Rosero
22/12/2014 Si cumple
28. ¿Se han realizado los Diagramas de secuencia de los casos de uso que llamen métodos de clases, donde los métodos deben ser los mismos que constan en su correspondiente clase en el Diagrama de clases de diseño?
Ing. Geovanna Saltos Diana Oña, Andrés Rosero
22/12/2014 Si cumple
29. ¿Se ha verificado que todos los objetos que constan en el Diagrama de clases de diseño consten en el Diagrama de objetos?
Ing. Geovanna Saltos Diana Oña, Andrés Rosero
22/12/2014 Si cumple
30. ¿Se ha revisado que todos los mensajes que constan en el Diagrama de secuencia de los casos de uso que llamen métodos de clases consten como envíos de mensajes en el Diagrama actividades de casos de uso complejo si existiese?
Ing. Geovanna Saltos Diana Oña, Andrés Rosero
22/12/2014 Si cumple
Modelo de diseño:
diseño de despliegue
31. ¿Se ha validado que todos los componentes en el Diagrama de componentes consten como burbuja en el Diagrama de casos de uso a nivel contextual?
Ing. Geovanna Saltos Diana Oña, Andrés Rosero
22/12/2014 Si cumple
Tabla 3.4: Evaluación del modelamiento Fase Construcción (continuación)
57
Tema a evaluar
Evaluación Revisado por Fecha de revisión
Observación (Si cumple / No cumple)
Modelo de diseño:
diseño de despliegue
32. ¿Se ha revisado que todo componente mostrado en el Diagrama de componentes se desarrolle en el transcurso del proyecto?
Ing. Geovanna Saltos Diana Oña, Andrés Rosero
22/12/2014 Si cumple
33. ¿Se ha verificado que en el Diagrama de despliegue consten todos los recursos de TI donde se van a desplegar los componentes desarrollados?
Ing. Geovanna Saltos Diana Oña, Andrés Rosero
22/12/2014 Si cumple
Implementación
34. ¿Cada burbuja del Diagrama de casos de uso a nivel contextual representa un módulo del subsistema implementado?
Ing. Geovanna Saltos Diana Oña, Andrés Rosero
22/12/2014 Si cumple
35. ¿Se ha validado que todos los casos de uso del Diagrama de casos de uso por módulo cuenten con su código fuente?
Ing. Geovanna Saltos Diana Oña, Andrés Rosero
22/12/2014 Si cumple
36. ¿Se ha revisado que todos los casos de uso base son parte de un menú.
Ing. Geovanna Saltos Diana Oña, Andrés Rosero
22/12/2014 Si cumple
37. ¿Se ha revisado que todos los casos extendidos tengan una interfaz para que el usuario pueda ejecutarlo?
Ing. Geovanna Saltos Diana Oña, Andrés Rosero
22/12/2014 Si cumple
38. ¿Se ha revisado que todos los casos de uso incluidos no deben tener interface para ser ejecutados por el usuario dado que se ejecutan de forma automática?
Ing. Geovanna Saltos Diana Oña, Andrés Rosero
22/12/2014 Si cumple
39. ¿Se ha verificado que todas las clases reconocidas en el diseño se representan en alguna tabla de la bd?
Ing. Geovanna Saltos Diana Oña, Andrés Rosero
22/12/2014 Si cumple
40. ¿Se ha comprobado que en la base de datos consten todas las restricciones sujetas a lo que dicen las relaciones de las clases de diseño?
Ing. Geovanna Saltos Diana Oña, Andrés Rosero
22/12/2014 Si cumple
Tabla 3.4: Evaluación del modelamiento Fase Construcción (continuación)
58
En la figura siguiente se observa los requisitos atendidos por casos de uso. Esta
matriz demuestra el cumplimiento del numeral 14 de la Tabla 3-3.
Figura 3.1 Cruce de requisitos vs casos de uso
59
3.6.3.2 Pruebas de Implementación vs Modelamiento
Con el fin de evaluar que los programadores hayan realizado un desarrollo
apegado al modelamiento se planificaron algunas pruebas y se ejecutaron
también en esta fase.
En la siguiente tabla se muestran preguntas para esta evaluación en la segunda
columna “Evaluación”. En relación a la ejecución de estas pruebas se llevó a cabo
la evaluación que consta en las columnas: “Revisado por”, “Fecha de revisión”,
“Observación”. La aplicación de las pruebas dio por resultado el cumplimiento
total en las evaluaciones, columna “Observación” (color verde).
Tema a evaluar
Evaluación Revisado por Fecha de revisión
Observación (Si cumple / No cumple)
Implementación del Modelo de
análisis
1. ¿Están definidos los roles o perfiles de usuario de acuerdo a los actores?
Diana Oña, Andrés Rosero
10/03/2015 Si cumple: se han definido perfiles.
2. ¿Cada burbuja del Diagrama de casos de uso a nivel contextual representa un módulo/submenú del sistema implementado? - ¿Representa un módulo
la Atención médica ambulatoria en el menú de Samweb?
- ¿Representa un módulo el Manejo de inventario en el menú de Samweb?
- ¿Representa un módulo las Políticas del servicio en el menú de Samweb?
¿Representa un módulo el Análisis del servicio en el menú de Samweb?
Diana Oña, Andrés Rosero
10/03/2015 Si cumple
Tabla 3.5: Evaluación de la Implementación vs Modelamiento
60
Tema a evaluar Evaluación Revisado por
Fecha de revisión
Observación (Si cumple / No cumple)
Implementación del Modelo de diseño: diseño
funcional
3. ¿Los casos de uso del Diagrama de casos de uso por módulo cuentan con su código en la implementación? - ¿El módulo de Atención
médica cuenta con código en la implementación?
- ¿El módulo de Manejo de inventario cuenta con código en la implementación?
- ¿El módulo de Políticas del servicio cuenta con código en la implementación?
- ¿El módulo de Análisis del servicio cuenta con código en la implementación?
Diana Oña, Andrés Rosero
10/03/2015 Si cumple
4. ¿Los casos de uso base son parte del menú o corresponden a una opción implementada en clases GUI? - ¿Los casos de uso base de
SAMWEB son parte de una opción implementada en clases GUI?
Diana Oña, Andrés Rosero
10/03/2015 Si cumple
5. ¿Los casos extensores tienen link en una interfaz para que el usuario pueda ejecutarlo opcionalmente, deben implementarse en clases GUI?
Diana Oña, Andrés Rosero
10/03/2015 Si cumple
6. ¿Los casos de uso incluidos no deben tener interface para ser ejecutados a voluntad del usuario, pues son funcionalidades obligatorias, deben implementarse como funciones en la misma clase GUI de su correspondiente caso de uso base?
Diana Oña, Andrés Rosero
10/03/2015 Si cumple
Implementación del Modelo de diseño: diseño
estructural
7. ¿Todas las clases reconocidas en el Diagrama de clases de diseño están representadas en alguna tabla de la base de datos?
Diana Oña, Andrés Rosero
07/05/2015 Si cumple
Tabla 3.5: Evaluación de la Implementación vs Modelamiento (continuación…)
61
Tema a evaluar Evaluación Revisado por
Fecha de revisión
Observación (Si cumple / No cumple)
Implementación del Modelo de diseño: diseño estructural
8. ¿Los métodos del Diagrama de clases de diseño están implementados en procedimientos almacenados de la base de datos, o en alguna clase manejadora?
Diana Oña, Andrés Rosero
07/05/2015 Si cumple: están en clases manejadoras
Implementación del Modelo de diseño: diseño dinámico
9. ¿Todas las actividades que se han planteado en el Diagrama estados de objetos están implementadas en su correspondiente caso de uso o método de las clases?
Diana Oña, Andrés Rosero
07/05/2015 Si cumple
10. ¿Los métodos que están en el Diagrama de secuencia se ejecutan en el programa en el mismo orden que aparecen?
Diana Oña, Andrés Rosero
07/05/2015 Si cumple
Implementación del Modelo de diseño:
diseño de despliegue
11. ¿Se han verificado que todos los componentes hayan sido desarrollados? - ¿Se ha desarrollado el
componente Atención médica?
- ¿Se ha desarrollado el componente Servicios de atención médica?
Diana Oña, Andrés Rosero
07/05/2015 Si cumple
Tabla 3.5: Evaluación de la Implementación vs Modelamiento (continuación…)
3.6.3.3 Pruebas del producto de software
Para la Evaluación del producto software entregado se ejecutaron:
· Pruebas de funcionalidad con el técnico informático.
· Pruebas de funcionalidad con el usuario experto.
· Pruebas de código fuente.
Pruebas funcionales con el técnico informático
Se llevaron a cabo las Pruebas de funcionalidad con el técnico informático (Ing.
Roberto García, representante DGIP).
62
Las funcionalidades que fueron revisados con sus casos de uso involucrados en
la siguiente tabla:
Funcionalidad Casos de uso
Abrir apertura de HCL. Registrar apertura de HCL.
Abrir apertura de HCL consultando datos de identificación de los pacientes en sistemas relacionados.
Registrar apertura de HCL. Buscar datos de identificación de pacientes en sistemas relacionados.
Registrar atención médica para el tipo de paciente Estudiante.
Registrar atención médica. Registrar orden de despacho de insumos médicos.
Llevar a cabo una atención médica para el tipo de atención Emergencia.
Registrar atención médica. Registrar orden de despacho de insumos médicos.
Llevar a cabo una atención médica cuando el paciente es de Tipo Docente.
Registrar atención médica.
Revisar historial clínico del paciente. Consultar historial clínico.
Despachar de insumos médicos. Registrar despacho de insumos médicos.
Aplicar movimiento de inventario. Registrar movimiento de inventario.
Identificar y describir un insumo médico. Registrar insumo médico.
Controlar presentación de documentos de salud de estudiantes nuevos.
Registrar presentación de documentos de salud de estudiantes nuevos.
Obtener información de Atención médica ambulatoria e Inventario
- Administrar criterios de selección. Generar Reportes de “Pacientes atendidos”. - Administrar criterios de selección. Generar Reportes de “Casos atendidos”. - Administrar criterios de selección. Generar Reportes de listas de “Insumos médicos”. - Administrar criterios de selección. Generar Reportes de “Movimientos de insumos médicos”.
Tabla 3.6: Pruebas de funcionalidad con el técnico informático
Según el plan se evaluó la funcionalidad del subsistema revisando los casos de
uso involucrados en esa funcionalidad. Los detalles de estas evaluaciones
constan en el ANEXO II – Pruebas de funcionalidad con el técnico informático.
Pruebas funcionales con el usuario experto
Para aplicar las Pruebas de funcionalidad con el usuario experto del subsistema
se seleccionaron 3 casos de prueba con diferentes escenarios a ser evaluados,
para cada uno se describió un Guion de pruebas.
63
Caso de prueba Objetivo Guion de prueba
Registrar presentación de documentos de salud de un estudiante nuevo y registrar atención médica.
Verificar que el subsistema apoya adecuadamente durante una atención médica completa a un paciente nuevo de tipo Estudiante.
- Verificar que el estudiante cuente con una cita asignada por el SAEW y presente los documentos de salud correspondientes.
- Aperturar la historia clínica del paciente. - Llevar a cabo la atención médica. - En el caso de que la atención médica requiera
despachar insumos médicos ya sea suministrándole en ese momento o entregando para su uso posterior debe incluir una orden de despacho de insumos médicos.
- Si existe una orden de despacho de insumos médicos habrá que despacharlos.
Registrar una atención médica a un paciente de tipo Docente.
Verificar que el subsistema apoya adecuadamente durante una atención médica completa a un paciente de tipo Docente.
- Verificar si el paciente está registrado. - Si el paciente no está registrado deberá
aperturarse una historia clínica. - Si el paciente ya cuenta con la historia clínica
su búsqueda se lo hará mediante una consulta a través de su cedula de identidad.
- Una vez que ya se cuenta con la historia clínica del paciente se procederá a la atención médica.
- Se deberá hacer notar que a pacientes de tipo Docente no se les puede crear una orden de despacho de insumos médicos.
Registrar un insumo médico, Registrar un movimiento de inventario con el insumo médico registrado.
Que el subsistema maneja adecuadamente los movimientos de inventario de insumos médicos considerando desde la creación del insumo médico, el incremento en inventario y el egreso de inventario.
- Incluir en el catálogo de inventario un nuevo insumo médico.
- Realizar una transacción de ingreso a inventario sea por donación, compra y cambio.
- Realizar una atención médica a un paciente de tipo Estudiante que incluya una orden de despacho de insumos médicos correspondiente al ítem incluido.
- Verificar que una vez que haya sido despachado el insumo médico el saldo sea el adecuado.
Tabla 3.7: Pruebas de funcionalidad con el usuario experto
En primera instancia, estas pruebas se ejecutaron con el usuario experto (Dr.
Patricio López en aquel momento Director del área médica de la DBEYSO), quien
estuvo de acuerdo con las pruebas realizadas al subsistema, logrando tener su
aceptación más no su firma en la carta de aceptación debido a su jubilación, este
acontecimiento ocurrió en el desarrollo del presente proyecto. Posteriormente por
cambio del personal, se ejecutaron con un nuevo usuario experto (Dra. Valeria
Lazar, Directora de la DBEYSO) con quien se obtuvo la aceptación. En la
redacción de esas pruebas hay errores en el texto: El texto “Pruebas de
integración” corresponde a “Prueba de funcionalidad”, lamentablemente ese
64
documento no pudo ser cambiado puesto que cuenta con una firma de
aprobación. Sin embargo, esto no desmerece la validez de la prueba. Estas
pruebas se planificaron y ejecutaron en esta misma fase. Los detalles de la
ejecución de los casos de prueba se encuentran en el ANEXO III. – Pruebas de
funcionalidad con el usuario experto.
Pruebas de código fuente
SAMWeb en su arquitectura técnica está conformado por dos proyectos, el
primero AtencionMedica es de tipo Web dinámico basado en Java, y el segundo
ServiciosAtencionMedica de tipo Java. Los dos proyectos fueron analizados con
el software Sonarqube.
Para el análisis de código fuente de este proyecto se tomaron en cuenta los
siguientes ejes de calidad:
· Estándares de codificación.
· Errores potenciales.
· Complejidad.
· Duplicación.
· Comentarios.
· Arquitectura y diseño.
Se realizaron 2 ejecuciones para cada uno de los proyectos, a continuación se
muestra los resultados obtenidos en cada escaneo (ejecución del sonar-runner
para Sonarqube):
Figura 3.2 Primer escaneo con SonarQube
En la primera escaneada se obtuvo calificación B (columna Calificacion SQALE)
para los dos proyectos. Esto indica que en primera instancia SAMWeb es
65
aceptable, pero para ver mejorías en la calidad del código fuente se procedió con
las correcciones preventivas del caso.
A continuación se observa la segunda aplicación:
Figura 3.3 Segundo escaneo con SonarQube
En este último escaneo se obtuvo la categoría A para ambos proyectos, dando
como resultado dos proyectos sanos.
Las columnas indican lo siguiente:
· Evidencia: número encontrado de “posibles errores”
· Evidencias críticas: número encontrado de erres críticos, asociados con la
complejidad de los métodos
· Lineas Dup: porcentaje de líneas duplicadas
· Comentarios: porcentaje de líneas de código que corresponden a
comentarios
· CMPJ: sumatoria total de la complejidad ciclomática encontrada en los
métodos de cada proyecto
· Deuda técnica: número de días aproximado a invertir para resolver las
evidencias encontradas.
· LOCS: número de líneas de código (sin comentarios)
· Calificación SQALE: calificación de la deuda técnica basada en el modelo
SQALE
Se realizó la primera ejecución para el proyecto web AtencionMedica, el resultado
se observa en la siguiente figura:
66
Figura 3.4: Categoría B para el proyecto AtencionMedica
Se vuelve a realizar el análisis sobre proyecto con las mejoras realizadas al
código fuente del subsistema en base a las recomendaciones. Se evidencia que
el proyecto subió de categoría B a A.
Figura 3.5: Categoría A para el proyecto AtencionMedica
67
A continuación se realizó la primera ejecución para el proyecto
ServicioAtencionMedica, el resultado se observa en la siguiente figura:
Figura 3.6: Categoría B para el proyecto ServiciosAtencionMedica
Se muestra la segunda aplicación de sonarQube en proyecto y se evidencia que
el proyecto subió de categoría B a A.
Figura 3.7: Categoría A para el proyecto ServiciosAtencionMedica
Para ver un detalle de los resultados para cada eje de calidad Vea el Anexo VI –
Pruebas de código fuente con SonarQube (Resultados por eje de calidad).
68
Para ver un detalle de las evidencias Vea el Anexo D17 – Pruebas de código fuente
con SonarQube (Detalle de evidencias).
Las pruebas de código fuente dieron como resultado un código más accesible con estándares de codificación y un código fuente que permite su rápido y fácil mantenimiento.
Como resultado final para las pruebas de código fuente se concluye que analizar
el código fuente con una herramienta automatizada permite mejorar el
rendimiento de la aplicación para dar resultados a tiempo y para dar una mejor
experiencia de uso a los usuarios. Al igual que implementar las mejoras permite
tener un código fuente de calidad que soporte y brinde las funcionalidades que se
plantearon en los requisitos del proyecto para el subsistema SAMWeb.
69
4 IMPLANTACIÓN DE UN PROTOTIPO
El desarrollo de este capítulo corresponde a lo que en PUD se lo conoce como
Despliegue. Para dejar implantado un prototipo se recibió la aprobación del
subsistema por parte del equipo de desarrollo de la DGIP y de la DBEYSO.
El detalle de los pasos que se efectuaron para la implantación del prototipo se
expresa en este documento.
4.1 RECOPILAR DATOS
Para obtener los datos de identificación de los pacientes en los sistemas
relacionados que serían accedidos por el SAMWeb se recibió:
· Un respaldo de la base de datos de Recursos Humanos con
aproximadamente 500 registros de personal docente y administrativo.
· Credenciales de acceso para la conexión con los servicios Web del SAEW y
Registro civil. La conexión al SAEW permitió consultar datos de identificación
de los estudiantes apuntando a bases de datos en ambientes de prueba,
mientras que la conexión al registro civil permitió consultar datos de
identificación de todos los pacientes apuntando a bases de datos en
ambientes de producción.
4.2 INSTALACIÓN
Superadas las pruebas se procedió con la instalación del prototipo. La DGIP
dispuso que la instalación se realice en equipos propiedad de los desarrolladores
y se efectué la demostración en dicho ambiente, para lo cual se procede:
· Instalar el motor de base de datos PostgreSQL.
· Ejecutar los script de la base de datos SAMWeb. Ver ANEXO D10 – Script de la
base de datos SAMWeb.
· Instalar el Servidor de aplicaciones JBoss.
· Instalar los archivos jar, war y/o ear del SAMWeb entregados por los
desarrolladores en el contenedor del servidor de aplicaciones. Ver ANEXO D15 –
Manual de instalación.
70
· Instalar la llave del certificado web, proporcionado por la DGIP, en la
configuración de seguridad del servidor de aplicaciones. Ver ANEXO D16 – Llave
de certificado web.
· Iniciar el servidor de aplicaciones.
· Utilizar el navegador web Google Chrome o Mozilla Firefox para ejecutar el
subsistema SAMWeb. URL: https://samweb.epn.edu.ec/AtencionMedica.
El procedimiento listado permite instalar e iniciar el funcionamiento del prototipo.
Se realizaron varios productos para la instalación, uso y mantenimiento del
subsistema SAMWeb que fueron entregados formalmente a la DGIP. Los
productos finales que le permiten poner en producción el subsistema fueron:
· Manual técnico: Documento donde se encuentran todos los productos
descritos en la MATRIZ GUÍA DE DESARROLLO en su estado final de
madurez. Ver ANEXO I - Manual Técnico.
· Manual de usuario: Documento donde expresa lo que cada opción del
subsistema realiza y que adicionalmente consta de los ejemplos de reportes
que genera el subsistema. Ver ANEXO D13 – Manual de usuario.
· Código ejecutable: Son los encapsulados de los componentes desarrollados,
entre ellos están la aplicación web (AtencionMedica.war) y la librería java
(ServiciosAtencionMedica.jar). Ver ANEXO D14 – Código ejecutable.
· Manual de instalación: Indica paso a paso cómo instalar y levantar el
subsistema en un servidor de pruebas. Ver ANEXO D15 – Manual de instalación.
· Script SQL de la base de datos SAMWeb. Ver ANEXO D10 – Script de la base de
datos.
· Respaldo de la base de datos inicial. Ver ANEXO D11 – Respaldo de la base de
datos.
· Código fuente. Ver ANEXO D12 – Código fuente del subsistema.
En paralelo la DGIP hizo su propio Despliegue en su ambiente de Test.
71
4.3 EVALUACIÓN DE LA INSTALACIÓN
Una vez instalado el prototipo en el ambiente de los desarrolladores se realizaron
las demostraciones del funcionamiento del software con los representantes de la
DGIP (Ing. Geovanna Saltos, Ing Roberto Gracia e Ing. Juan Carlos Maldonado;
Jefa de desarrollos y Analistas IT respectivamente) y DBEYSO (Dr. Patricio López
director encargado). Posteriormente el Dr. López fue sustituido por un nuevo
director la Dra. Valeria Lazar.
Por el cambio de usuario experto en la DBEYSO y a solicitud expresa de la
directora se realizó una revisión de las pruebas de funcionalidad con la nueva
directora DBEYSO, es decir, se volvieron a aplicar las pruebas de funcionalidad
del subsistema debido a dicho cambio.
Finalmente los usuarios de la DBEYSO navegaron por todo el subsistema
haciendo una revisión minuciosa del mismo.
Con las pruebas realizadas y aprobadas se obtuvo el certificado de aceptación del
subsistema SAMWeb por parte del técnico informático DGIP y el usuario experto
DBEYSO. Ver ANEXO V – Certificado de aceptación.
72
5 CONCLUSIONES Y RECOMENDACIONES
CONCLUSIONES
· El objetivo general de este proyecto se cumplió puesto que como producto
de este proyecto se desarrolló el subsistema de atención médica web para
la Dirección de Bienestar Estudiantil y Social (DBEYSO anteriormente
UBEYSO) de la EPN a satisfacción de los usuarios de la dirección
mencionada y de los informáticos de la DGIP tal como lo demuestra la
carta de aceptación que se presenta como anexo V de este proyecto.
Este subsistema se integra con el SAEW mediante el consumo de un
servicio web que permite:
o Obtener datos de identificación, datos personales y datos
académicos básicos para estudiantes que no están registrados en el
subsistema de atención médica, es decir para la primera cita.
o Obtener el estado actual del estudiante.
o Enviar un aviso de que el estudiante nuevo presentó documentos de
salud por primera vez, para que el SAEW registre en su sistema
este aviso que constituye un requisito para su primera matrícula.
Este subsistema se integra con el subsistema de Recursos Humanos
mediante una conexión a su base de datos para obtener datos de
identificación de personal administrativo y docente que concurre por
primera vez a la atención médica.
Este subsistema adicionalmente se integra con el Registro Civil mediante el
consumo de un servicio web que permite obtener datos de identificación de
personas que reciben atención médica por primera vez y no son
estudiantes, docentes o personal administrativo.
· Se modeló el subsistema en base a los requisitos levantados con los
usuarios expertos del área médica y a las especificaciones previstas por la
73
DGIP. Para el modelado se utilizó los lineamientos provistos por PUD y se
representaron con la especificación UML.
· Se implementó el subsistema con tecnologías web tomando como base el
modelado realizado. Para el back-end se utilizó la Plataforma JEE6 y para
el fron-end JSF con Primefaces.
· Para evaluar la validez del subsistema se realizaron las siguientes pruebas:
o Del modelamiento, para garantizar la consistencia entre los modelos.
o Del modelamiento vs implementación, para garantizar que el
producto desarrollado responda a los modelos.
o Del producto, para garantizar la calidad del software, mediante:
§ Pruebas funcionales realizadas con los usuarios expertos del
área médica e informáticos de la DGIP.
§ Análisis de calidad del código del subsistema, mediante el
software sonarQube.
· La matriz guía de desarrollo, preparada para este proyecto, facilitó la
aplicación de los pasos a seguir permitiendo visualizar y controlar el
avance de los productos a entregar en cada fase y flujo del PUD.
· Para el desarrollo de SAMWeb fue importante el análisis de las actividades
de los procesos administrativos de la DBEYSO, esto permitió reconocer las
que necesitaban apoyo informático. De esa manera se recolectaron los
requisitos funcionales y no funcionales del subsistema. Los desarrolladores
quedamos satisfechos por haber revisado cada actividad administrativa ya
que si se reconocieron requisitos para ellas.
· El equipo de desarrollo de software aportó al reconocimiento de falencias
en los proceso administrativos dentro de este negocio. En el presente
proyecto la DBEYSO no tenía un proceso formalizado de inventario, razón
por la cual los autores de este proyecto levantaron y formalizaron desde
cero el proceso Manejo de inventario, este proceso se refiere a la gestión y
74
control correcto de los insumos médicos existentes en la bodega del
departamento médico de la EPN.
· La implementación de un software sustentado en documentos formales de
diseño aporta a conseguir un producto de software de calidad consistente a
la realidad del negocio. Esto se aprecia porque pese al cambio radical de
usuarios en la DBEYSO se pudo demostrar que el subsistema atendió
adecuadamente al modelo del negocio.
· La falta de experiencia de los usuarios y la falta de formalización de los
procesos administrativos influye de manera negativa, generando
dificultades en el desarrollo de software. En el presente proyecto fue
necesario dar una orientación a los usuarios con respecto a las facilidades
que pueden brindar los sistemas informáticos y también se tuvo que
participar en la definición de los procesos administrativos.
· El cambio inesperado de usuarios a mitad del proyecto dificulta de manera
significativa en el cumplimiento del cronograma de desarrollo por los
nuevos enfoques que traen los nuevos usuarios. Pese a esto fue factible
cumplir con los objetivos del presente proyecto y entregar un producto a
satisfacción del usuario.
75
RECOMENDACIONES
· Usar la matriz guía de desarrollo preparada en este proyecto para futuros
desarrollos de sistemas en los que se aplique PUD y UML.
· El equipo de desarrollo debe estar capacitado en las metodologías y
tecnologías a usar para el desarrollo de software, este conocimiento previo
disminuirá la curva de aprendizaje y el tiempo de implementación del
producto.
· El equipo de desarrollo debe estar capacitado en estándares y
herramientas de pruebas de software para facilitar su planificación,
ejecución y elaboración de informes.
· El equipo de desarrollo que va a implementar un producto a la medida debe
involucrase y entender los procesos administrativos del negocio.
· Previo al inicio del proyecto capacitar a los usuarios respecto de las
tecnologías de la información y la comunicación (TIC’s) a fin de que
conozcan las potencialidades y facilidades que los sistemas informáticos
ofrecen y se facilite la comunicación entre el equipo de desarrollo y el
usuario.
· Los responsables del Sistema de gestión de calidad de la EPN, en el que
se incluye la gestión de procesos, deben difundir y capacitar a los usuarios
que participarían en el desarrollo de software respecto de los procesos
formalizados. Esto, a fin de que los usuarios se basen en los procesos
formalizados para establecer sus requisitos.
· Una vez culminado el presente proyecto de titulación es importante que la
DGIP ponga en producción este subsistema a la brevedad posible porque
76
será de utilidad para la DBEYSO tal como lo expresa la carta de
aceptación.
· La DGIP podrá dar mantenimiento a este subsistema incluyendo
funcionalidades específicas para que las especialidades de odontología,
psicología y nutrición puedan ser atendidas a través de este mismo
subsistema.
77
GLOSARIO DE TÉRMINOS
Actividad: Tarea con un resultado y responsabilidad definida para un
actor/trabajador, que se efectúa en un flujo de trabajo.
Actor: Rol que un usuario desempeña en el sistema, responsable de actividades
para las que se han reconocido requisitos funcionales.
Aislamiento: Garantiza que una operación no puede afectar a otras, de tal forma
que dos transacciones al mismo tiempo se efectúan independientemente sobre la
misma información.
Plataforma JEE6: Es una plataforma abierta que utiliza un modelo de
aplicaciones distribuido multicapa basada en componentes, centradas en un
servidor y habilitado para la web. Esta permite desarrollar, desplegar y manejar
aplicaciones empresariales siguiendo el patrón de arquitectura MVC (Modelo-
Vista-Controlador). [13]
Arquitectura SOA: Es un marco de trabajo que permite a las organizaciones
alinear los objetivos de negocio con la infraestructura de TI, optimizando la
flexibilidad en los procesos del negocio y reduciendo los costos para crear
sistemas escalables. [14]
Artefacto: Pieza de información tangible que es usada por los actores al realizar
las actividades en el proceso de desarrollo. Un artefacto puede ser un documento,
un modelo, un elemento del modelo, un producto, entre otros.
Atomicidad: Garantiza que la operación se ha realizado cumpliendo con todos
los procedimientos propuestos.
Caso de uso: Es un conjunto de escenarios que describen una secuencia de
acciones entre el sistema y el usuario. Es ejecutado por un actor o por una
invocación desde otro caso de uso en un modelo para conseguir un determinado
resultado.
78
Caso de prueba: Es un conjunto de pasos que prueban y validan una
funcionalidad determinada, si el resultado obtenido es exitoso la funcionalidad
satisface al requisito o a los requisitos asociados al caso de prueba
Componente: Constituye un módulo del sistema.
Consistencia: Garantiza que los datos sean exactos e íntegros de tal modo que
la información expuesta al usuario sea la esperada.
Diagrama: Conjunto de elementos y sus relaciones representados gráficamente.
Durabilidad: Garantiza que realizada la operación ésta permanecerá aun cuando
ocurra un fallo en el sistema.
Estado: Es un evento en la existencia de un objeto de una clase durante la cual
se ejecuta una condición.
Hibernate: Marco de trabajo que proporciona el mapeo de atributos entre una
base de datos relacional y el modelo orientado a objetos de una aplicación a
través de un ORM (Mapeo objeto-relacional). Permite la independencia de la base
de datos, puesto que desde la aplicación se manipulan los atributos de la base al
operar sobre los objetos.
Iteración: Es el paso por uno o varios flujos de trabajo para tener un conjunto de
productos y obtener un nuevo incremento.
Incremento: es una versión del sistema.
Java Persistence API (JPA): Marco de trabajo que permite persistir los datos en
un sistema de manejo de base de datos relacional usando los objetos persistentes
como tablas en la base de datos.
Java Server Faces (JSF): Marco de trabajo con componentes reutilizables, útil en
la construcción de interfaces de usuario.
Lenguaje Unificado De Modelado (UML): Es un lenguaje de modelado que
permite representar procesos del negocio y funciones del sistema incorporando
buenas prácticas de diseño. Brinda soporte a la metodología de desarrollo de
79
software PUD para representar gráficamente los esquemas y artefactos que usa.
[2]
Modelo: Representa la descripción de un sistema desde un punto de vista.
MVC: Modelo-Vista-Controlador. Es un patrón de arquitectura propuesta para el
diseño de software que organiza el código en tres capas: [13]
Modelo: Especifica la lógica del negocio y el acceso a datos.
Vista: Es la interfaz gráfica que se muestra al usuario.
Controlador: Encargado de recibir e interpretar las peticiones del usuario, se
comunica con el modelo para obtener los datos y se los trasmite a la vista para
que se muestre al usuario.
Procedimientos de prueba: Conjunto de pasos ordenados necesarios para
probar un caso de prueba.
Proceso: Es un conjunto de actividades interconectadas de forma lógica, estas
reciben entradas a las que agregan valor para producir una salida o resultado,
para de este modo cumplir con el objetivo del proceso.
Proceso Unificado de Desarrollo (PUD) es un marco de trabajo genérico
adaptable a diferentes organizaciones para el desarrollo de sistemas de software
de cualquier tamaño.
Producto: Artefacto creado en un flujo de trabajo, es el resultado tangible de un
proceso.
Pruebas unitarias: Son aquellas pruebas que verifican la validez de un método
codificado. Si el resultado obtenido es el deseado la prueba es válida o aceptada.
Pruebas funcionales: Se refiere a las funciones que un sistema, subsistema,
componente debe llevar a cabo en función de una especificación de requisitos,
casos de uso o especificación funcional. Las funciones son “lo que hace” el
sistema. [12]
80
Relación: En base de datos es la conexión entre dos tablas a través de un
atributo en común que evita datos redundantes y permite la optimización de
recursos. Es el vínculo existente entre los elementos de un modelo.
Relación de asociación: relación entre objetos de diferentes clases.
Relación de extensión: Enlace representado con una flecha discontinua y con el
estereotipo <<extend>> que apunta del caso de uso extendido al caso de uso
base. Al caso de uso base se añaden casos de uso que extienden o amplían su
comportamiento.
Relación de Inclusión: Enlace con una flecha discontinua y con el estereotipo
<<include>> que va desde un caso de uso base a un caso de uso incluido. Un
caso de uso incluido añade su comportamiento al caso de uso base
compartiendo una funcionalidad en común.
Relación de generalización: Relación entre una descripción específica y una
descripción general, que permite compartir atributos y operaciones.
Riesgo: Es la probabilidad de ocurrencia de un suceso que impide el éxito del
proyecto.
81
BIBLIOGRAFÍA
[1] I. JACOBSON, G. BOOCH y J. RUMBAUGH, EL PROCESO UNIFICADO DE
SOFTWARE, MADRID: ADDISON WESLEY, 2000.
[2] J. RUMBAUGH, G. BOOCH y I. JACOBSON, Lenguaje Unificado de
Modelado - Manual de Referencia, Madrid: Pearson - Addison Wesley, 2007.
[3] M. J. M. O. Espinoza, «RUP,» FACULTAD DE INGENIERIA EN
COMPUTACION - UNIVERSIDAD AUTONOMA DE BAJA CALIFORNIA, Julio
2009. [En línea]. Available: http://yaqui.mxl.uabc.mx/~molguin/as/RUP.htm.
[Último acceso: 28 Marzo 2014].
[4] Oracle, «The Java EE 6 Tutorial,» Enero 2013. [En línea]. Available:
http://docs.oracle.com/javaee/6/tutorial/doc/javaeetutorial6.pdf. [Último
acceso: 5 Mayo 2013].
[5] Wikipedia, «JBoss,» 7 Julio 2015. [En línea]. Available:
https://es.wikipedia.org/wiki/JBoss. [Último acceso: 15 Noviembre 2015].
[6] JBoss Community, «Red Hat JBoss Product,» [En línea]. Available:
https://www.jboss.org/products/devstudio.html. [Último acceso: 05 Mayo 2014].
[7] D. Sandoval, «Postgresql-dbms,» Enero 2015. [En línea]. Available:
http://postgresql-dbms.blogspot.com/p/limitaciones-puntos-de-recuperacion.html.
[8] R. M., «PostgreSQL-es,» 02 Octubre 2010. [En línea]. Available:
http://www.postgresql.org.es/sobre_postgresql. [Último acceso: 15 Julio 2015].
[9] G. Sparks, Enterprise Architect User Guide, Sparx Systems, 2012.
[10] B. L. d. Rafael, «SonarQube,» Adictosaltrabajo, 03 Marzo 2015. [En línea].
Available: http://www.adictosaltrabajo.com/tutoriales/sonarqube-4-5-2/. [Último
82
acceso: 20 Enero 2016].
[11] A. Campbell, «SonarQube Documentation,» SonarSource S.A, 11 Diciembre
2015. [En línea]. Available:
http://docs.sonarqube.org/display/HOME/Developers%27+Seven+Deadly+Sins.
[Último acceso: 5 Febrero 2016].
[12] ISTQB - International Software Testing Qualifications Board, Probador
certificado - Programa de estudio de nivel básico, Foundation Level Syllabus,
2010.
[13] J. M. Gómez, «Arquitectura MVC - Experiencias de un ingeniero,» 15
Noviembre 2011. [En línea]. Available: http://jorge.queideas.com/wp-
content/uploads/2011/11/Arquitectura-MVC.pdf. [Último acceso: 28 Junio
2015].
[14] M. A. Rodríguez, «Tipos de Servicios SOA,» Adictosaltrabajo,
23 Septiembre 2013. [En línea]. Available:
http://www.adictosaltrabajo.com/tutoriales/tutoriales.php?pagina=SOATipos
Servicios. [Último acceso: 20 Agosto 2015].
83
ANEXOS
ANEXO I
MANUAL TÉCNICO
MANUAL TÉCNICO - SAMWEB ENERO/2016
CONTENIDO 1. MODELO DEL NEGOCIO ......................................................................................................... 1
1.1. DIAGRAMA DE ACTIVIDADES DEL PROCESO DE ATENCIÓN MÉDICA ..................... 2
1.2. DIAGRAMA DE ACTIVIDADES DEL PROCESO DE MANEJO DE INVENTARIO ........... 3
1.3. DIAGRAMA DE ACTIVIDADES DE LAS POLÍTICAS DEL SERVICIO DE ATENCIÓN
MÉDICA Y MANEJO DE INVENTARIO......................................................................................... 4
1.4. DIAGRAMA DE ACTIVIDADES DEL ANÁLISIS DEL SERVICIO DE ATENCIÓN MÉDICA
Y MANEJO DE INVENTARIO ........................................................................................................ 5
2. MODELO DE REQUISITOS ...................................................................................................... 6
2.1. LISTA DE REQUISITOS FUNCIONALES ......................................................................... 6
2.1.1. PROCESO DE ATENCIÓN MÉDICA AMBULATORIA: ............................................. 6
2.1.2. PROCESO DE MANEJO DE INVENTARIO: ............................................................. 7
2.1.3. PROCESO DE POLÍTICAS DEL SERVICIO DE ATENCIÓN MÉDICA Y MANEJO
DE INVENTARIO ....................................................................................................................... 7
2.1.4. PROCESO DE ANÁLISIS DEL SERVICIO DE ATENCIÓN MÉDICA Y MANEJO DE
INVENTARIO ............................................................................................................................. 8
2.2. LISTA DE REQUISITOS NO FUNCIONALES ................................................................... 8
2.3. DIAGRAMA DE REQUISITOS ......................................................................................... 10
3. MODELO DE ANÁLISIS .......................................................................................................... 14
3.1. DIAGRAMA DE ACTORES .............................................................................................. 14
3.2. DIAGRAMA DE CASOS DE USO A NIVEL CONTEXTUAL............................................ 15
3.3. DIAGRAMA DE CLASE DE ANÁLISIS ............................................................................ 16
3.4. LISTA DE RIESGOS CRÍTICOS Y SU VIABILIDAD ....................................................... 17
4. MODELO DE DISEÑO ............................................................................................................ 18
4.1. DISEÑO FUNCIONAL ...................................................................................................... 18
4.1.1. DIAGRAMA DE CASOS DE USO POR MODULO .................................................. 18
4.1.2. DESCRIPCIÓN DE LOS CASOS DE USO .............................................................. 22
4.2. DISEÑO ESTRUCTURAL ................................................................................................ 83
4.2.1. DIAGRAMA DE CLASES DE DISEÑO .................................................................... 83
4.2.2. DIAGRAMA DE OBJETOS ...................................................................................... 85
4.2.3. DICCIONARIO DE DATOS DEL DIAGRAMA DE CLASES .................................... 86
MANUAL TÉCNICO - SAMWEB ENERO/2016
4.3. DISEÑO DINÁMICO ......................................................................................................... 87
4.3.1. DIAGRAMA DE ACTIVIDADES ............................................................................... 87
4.3.2. DIAGRAMAS DE SECUENCIA ................................................................................ 88
4.3.3. DIAGRAMA DE ESTADOS ...................................................................................... 94
4.4. DISEÑO DE DESPLIEGUE .............................................................................................. 95
4.4.1. DIAGRAMA DE COMPONENTES ........................................................................... 95
4.4.2. DIAGRAMA DE DESPLIEGUE ................................................................................ 96
5. IMPLEMENTACIÓN ................................................................................................................ 97
5.1. ESTRUCTURA DE LA BASE DE DATOS ....................................................................... 97
ÍNDICE DE FIGURAS
Figura 1.1: Diagrama de actividades del proceso de atención médica ............................................. 2
Figura 1.2: Diagrama de actividades del proceso de inventario ........................................................ 3
Figura 1.3: Diagrama de actividades de las políticas del negocio ..................................................... 4
Figura 1.4: Diagrama de actividades del análisis de las políticas del negocio .................................. 5
Figura 2.1: Diagrama de requisitos para el proceso de atención médica ambulatoria .................... 10
Figura 2.2: Diagrama de requisitos del proceso de manejo de inventario ....................................... 11
Figura 2.3: Diagrama de requisitos del proceso de políticas del servicio de atención médica y
manejo de inventario ........................................................................................................................ 12
Figura 2.4: Diagrama de requisitos del proceso de análisis del servicio de atención médica y
manejo de inventario ........................................................................................................................ 13
Figura 3.1: Diagrama de actores del subsistema SAMWeb ............................................................ 14
Figura 3.2: Diagrama de casos de uso a nivel contextual del subsistema SAMWeb ...................... 15
Figura 3.3: Diagrama de clase de análisis ....................................................................................... 16
Figura 4.1: Diagrama de casos de uso del módulo del proceso atención médica ambulatoria ...... 18
Figura 4.2: Diagrama de CU del módulo del proceso de manejo de inventario .............................. 19
Figura 4.3: Diagrama de CU del módulo del proceso de políticas del servicio de atención médica y
manejo de inventario ........................................................................................................................ 20
Figura 4.4: Diagrama de CU del módulo del proceso de análisis del servicio de atención médica y
manejo de inventario ........................................................................................................................ 21
Figura 4.5: Diagrama de clases de diseño ....................................................................................... 84
Figura 4.6 Diagrama de objetos ....................................................................................................... 85
Figura 4.7 Diagrama de actividades del CU Registrar atención médica. ........................................ 87
Figura 4.8 Diagrama de secuencia del CU Registrar atención médica ........................................... 88
MANUAL TÉCNICO - SAMWEB ENERO/2016
Figura 4.9 Diagrama de secuencia del CU Consultar historial clínico ............................................. 88
Figura 4.10 Diagrama de secuencia del CU registrar apertura de HCL .......................................... 89
Figura 4.11 Diagrama de secuencia del CU Registrar orden de despacho de insumos médicos .. 90
Figura 4.12 Diagrama de secuencia del CU Registrar insumo médico ........................................... 90
Figura 4.13 Diagrama de secuencia del CU Registrar movimiento de inventario ........................... 91
Figura 4.14 Diagrama de secuencia del CU Registrar despacho de insumos médicos .................. 92
Figura 4.15: Diagrama de secuencia del CU registrar presentación de documentos de salud de
estudiantes nuevos .......................................................................................................................... 93
Figura 4.16: Diagrama de estados para el objeto Movimiento de inventario ................................... 94
Figura 4.17: Diagrama de componentes .......................................................................................... 95
Figura 4.18: Diagrama de despliegue .............................................................................................. 96
Figura 5.1: Estructura de la base de datos SAMWeb ...................................................................... 98
ÍNDICE DE TABLAS
Tabla 2.1: Lista de requisitos para el proceso de atención médica ................................................... 6
Tabla 2.2: Lista de requisitos para el proceso de manejo de inventario ............................................ 7
Tabla 2.3: Lista de requisitos para el proceso de políticas del área médica. .................................... 7
Tabla 2.4: Lista de requisitos para el proceso de análisis políticas del área médica ........................ 8
1
MANUAL TÉCNICO - SAMWEB ENERO/2016
MANUAL TÉCNICO
El presente manual brinda información técnica de la arquitectura del Subsistema
de atención médica web (SAMWeb), los modelos presentados están
desarrollados respetando los Principios de orientación a objetos, considerando los
lineamientos del Proceso Unificado de Desarrollo (PUD) y las técnicas del
Lenguaje Unificado de Modelado (UML).
1 MODELO DEL NEGOCIO
En el Modelo del negocio se reconocieron cada uno de los subprocesos
administrativos, de la Dirección de bienestar estudiantil y social (DBEYSO) de la
Escuela Politécnica Nacional (EPN), mediante diagramas de actividades; estos
expresan los procedimientos del área médica para cada proceso atendido por el
subsistema.
Los dos subprocesos administrativos seleccionados del proceso “Prestación de
Servicios de Salud (K.1)”8 que la DBEYSO solicitó sea soportado por el
subsistema SAMWeb son:
· Atención Médica Ambulatoria (K.1.1)
· Atención Médica Ginecológica (K.1.3)
Luego de analizarlos profundamente se determinó que ambos subprocesos se
unifiquen en un solo proceso9 denominado:
· Atención Médica Ambulatoria
Mientras que para la gestión de inventario se formalizó desde cero el proceso:
· Manejo de inventario
Para complementar el modelado se tomó en cuenta también los siguientes
procesos, producto de la observación y recopilación de procedimientos de
configuración y análisis de los procesos estudiados:
8 Dichos procesos están formalizados por la DGIP y se encuentran referenciados en el ANEXO 5 – Macro
proceso Bienestar Estudiantil (K) (Anexo Digital). 9 Para este proyecto estos subprocesos serán mencionados como procesos.
2
MANUAL TÉCNICO - SAMWEB ENERO/2016
· Políticas del servicio de atención médica y manejo de inventario
· Análisis del servicio de atención médica y manejo de inventario
1.1 DIAGRAMA DE ACTIVIDADES DEL PROCESO DE ATENCIÓN
MÉDICA
A continuación se presenta el Diagrama de Actividades del Proceso de Atención
Médica. Muestra las tareas administrativas asociadas a este proceso y se
desprenden las tareas informáticas consideradas como requisitos funcionales
para este proceso.
act Diagrama de activ idades del proceso de atención médica ambulatoria
Enfermera Médico Requisito
Receptar paciente
Inicio
Tomar signos v itales
Realizar examen clínico
Entregar turno de atención médica
Receptar paciente
Consultar paciente (Apellido, CI o HCl)
¿Se requiere tratamiento
de emergencia?
Realizar pedido de exámenes médicos
¿Ha recido atención
médica anterior?
Abrir HCl
Registrar apertura de HCL (datos personales)
Inv estigar antecedentes familiares y personales de
salud
Consultar historial clínico
¿Requiere exámenes nuev os?
¿Es necesario suministrar
medicamentos?Rev isar exámenes médicos
Realizar examen clínico
Registrar presentación de documentos de salud de estudiantes nuevos
SI
NO
NO
SI
SI
NO
2
MANUAL TÉCNICO - SAMWEB ENERO/2016
Identificar diagnóstico
Otorgar transferencia hospitalaria
Establecer tratamiento
¿Existen medicamentos?
¿El paciente es
estudiante?
Preescribir receta
Consultar insumos médicos
Entregar medicamentos gratuitos
Generar orden de medicación
por entrega
Registrar la atención
médica
Fin
Registrar la atencion medica (Antecedentes, Hábitos y Adicionales de la especialidad, Signos vitales, Examen clínica, Motivo, Diagnóstico, Tratamiento)
¿Existen medicamentos?
Suministrar medicamentos gratuitos
Generar orden de medicación por
suministro
Orden_medicacion (suministro)
Orden_medicacion (entrega)
Registrar la atención médica
Entregar medicamentos gratuitos Registrar orden de
despacho de insumosmédicos (por suministro, por entrega)
SI
SI
NO
NO
NO
NO
SI
SI
Figura 1.1: Diagrama de actividades del proceso de atención médica
3
MANUAL TÉCNICO - SAMWEB ENERO/2016
1.2 DIAGRAMA DE ACTIVIDADES DEL PROCESO DE MANEJO
DE INVENTARIO
El Diagrama de Actividades del Proceso de Inventario en la Figura 1.2: Diagrama
de actividades del proceso de inventario. Muestra las tareas administrativas
asociadas a este proceso y se desprenden las tareas informáticas que serán
consideradas como requisitos funcionales.
act Diagrama de activ idades del proceso de manejo de inv entario
Médico Enfermera Requisitos
Inicio
Realizar ingreso de insumos médicos
¿Se requiere ingreso de
insumos médicos?
Analizar mov imientos de inv entario
Realizar informe de insumos médicos
ingresados
Recibir insumos médicos
Verificar saldo y estado de insumos médicos
¿Se requiere egreso de
insumos médicos por
entrega o suministro?
Realizar egreso de medicación
Registrar movimiento de inventario (- egreso por entrega, - egreso por suministro, - egreso por baja,
¿Se requiere
egreso de
Orden_medicacion (entrega)
Insumos_médicos
Generar listas de insumos médicos (- Lista de insumos médicos agrupado por tipo de presentación o tipo de insumo médico- Lista de insumos médicos bajo saldo de re-orden agrupado por tipo de presentación o tipo de insumo médico)
Orden_medicacion (suministro)
Generar reporte de movimientos de insumos médicos (- Número de movimientos de ingreso realizados según insumo médico por tipo de ingreso- Número de movimientos de egreso realizados según insumo médico por tipo de egreso- Número de insumos medicos ingresados según insumo médico por tipo de ingreso- Número de insumos medicos egresados según insumo médico por tipo de egreso)
Generar orden de medicación por
entrega
(from Atención médica ambulatoria)
Generar orden de medicación por
suministro
(from Atención médica ambulatoria)
Entregar insumos médicos al paciente
Registrar despacho de orden de insumos médicos (- por suministro, - por entrega)
Verificar la orden de medicación entregada al
paciente
Nombre: Diagrama de actividades del proceso de manejo de inventarioAutor: Diana Oña; Andrés Rosero T.Versión: 6Creado: 10/03/2014 12:24:29Actualizado:12/12/2015 23:09:26
SI
SI
NO
NO
3
MANUAL TÉCNICO - SAMWEB ENERO/2016
Realizar egreso por baja
Fin
Retirar medicamentos físicamente
Abalizar informe de la baja
Dev olv er o destruir insumos médicos
Realizar informe de ajuste por
excedente de inv entario
Realizar lista de insumos médicos a dar de baja
¿Se requiere realizar
ajustes de inv entario?
Realizar egreso por ajuste faltante
de inv entario físico
¿Existen
excedentes?
Realizar ingreso por ajuste
excedente de inv entario físico
Realizar informe de ajuste por
faltante de inv entario
- egreso por suministro, - egreso por baja, - egreso por ajuste faltante, - ingreso por compra, - ingreso por donación, - ingreso por ajuste excedente )
egreso de insumos médicos
por baja?
Abalizar informe de egreso por ajuste faltante
Abalizar informe de ingreso por
ajuste excedente
¿Existen
faltantes?
NO
NO
SI
NO
SI
NO
SI
SI
Figura 1.2: Diagrama de actividades del proceso de inventario
4
MANUAL TÉCNICO - SAMWEB ENERO/2016
1.3 DIAGRAMA DE ACTIVIDADES DE LAS POLÍTICAS DEL
SERVICIO DE ATENCIÓN MÉDICA Y MANEJO DE
INVENTARIO
Las políticas del negocio es un proceso que generalmente no se encuentra
formalizado, para determinar cuáles son los datos o supuestos existentes en el
área médica se ha levantado este proceso y se han determinado las siguientes
actividades administrativas con sus respectivas tareas informáticas, como se
puede observar en la Figura 1.3.
act Diagrama de activ idades de las políticas del serv icio de atención médica y manejo de inv entario
Director Enfermera Requisito
Organizar personal médico que atiende en
el área médica
Determinar tipos de pacientes a ser atendidos
Determinar tipos de especialidades disponibles
Establecer tipos de mov imientos de inv entario de insumos médicos
Inicio
Fin
Registrar personal médico (médicos y enfermeras)
Registrar tipos de pacientes
Registrar tipos de especialidades
Registrar tipos de movimientos de inventario
Establecer tipos de atención médica Registrar tipos de atención médica
Establecer insumos médicos q se
v an a entregar o suministrarRegistrar Insumo Médico
Establecer tipos de estado de mov imientos de inv entario
Registrar tipos de estado de movimientos de inventario
Establecer los tipos de medicamentos que se entregarán o
suministrarán
Registrar tipos de insumos médicos y tipos de presentación
Nombre: Diagrama de actividades de las políticas del servicio de atención médica y manejo de inventarioAutor: Diana Oña, Andrés Rosero T.Versión: 4Creado: 02/04/2014 7:33:41Actualizado:14/12/2015 0:57:57
Registrar Insumo Médico
Registrar tipos de insumos médicos y tipos
de presentación
Figura 1.3: Diagrama de actividades de las políticas del negocio
5
MANUAL TÉCNICO - SAMWEB ENERO/2016
1.4 DIAGRAMA DE ACTIVIDADES DEL ANÁLISIS DEL SERVICIO
DE ATENCIÓN MÉDICA Y MANEJO DE INVENTARIO
Una vez definido el diagrama de políticas del negocio este es analizado para
tomar en cuenta algunos requisitos adicionales tal como se muestra en la Figura
1.4.
act Diagrama de activ idades del análisis del serv icio de atención médica y manejo de inv entario
Médico Usuario Requisitos
Inicio
Analizar número de pacientes
atendidos según médico por
tipo de paciente
Analizar número de pacientes
atendidos según fecha por
médico
Analizar diagnósticos por
sexo
Analizar los insumos médicos
ingresados y egresados
Generar número de pacientes atendidos según médico por tipo de paciente
Generar número de pacientes atendidos según médico por años y meses
Generar número de casos según diagnostico por sexo.
Generar reporte de movimientos de insumos médicos
Fin
Analizar la cantidad de insumos médicos existentes y bajo saldo
de reordenGenerar l istas de insumos médicos
Generar número de casos según diagnostico por tipo de pacientes
Generar número de casos según diagnostico por edades
Analizar diagnósticos por
tipo de pacientes
Analizar diagnósticos por
edades
Analizar número de pacientes
atendidos según médico por
especialidad
Analizar número de pacientes
atendidos según médico por tipo de
atención médica
Generar número de pacientes atendidos según médico por tipo de atención médica
Generar número de pacientes atendidos según médico por especialidad
Nombre: Diagrama de actividades del análisis del servicio de atención médica y manejo de inventarioAutor: AdminVersión: 1.0Creado: 02/04/2014 17:33:50Actualizado:22/12/2015 0:36:23
Figura 1.4: Diagrama de actividades del análisis de las políticas del negocio
6
MANUAL TÉCNICO - SAMWEB ENERO/2016
2 MODELO DE REQUISITOS
Los requisitos levantados se enfocan en construir un subsistema que soporte
tanto los requisitos funcionales y los no funcionales de las tareas informáticas que
se desprenden de los procesos analizados.
Para el reconocimiento de los requisitos funcionales se revisó cada una de las
actividades del Modelo del Negocio con el fin de reconocer si requerían o no de
apoyo informático. Una actividad que requiera de apoyo informático se ligó a una
nota a manera de requisito funcional. Estos requisitos funcionales se colocaron en
el mismo diagrama de actividades en una columna adicional ubicada a la derecha.
2.1 LISTA DE REQUISITOS FUNCIONALES
A continuación se especifica la lista de requisitos funcionales planteados por la
DBEYSO y por la DGIP para cada proceso administrativo.
2.1.1 PROCESO DE ATENCIÓN MÉDICA AMBULATORIA:
En la Tabla 2.1 se puede apreciar la lista de requisitos con su respectivo
responsable para el Proceso de atención médica ambulatorio.
Nº Requisito Responsable
1 Consultar paciente (por Apellido, CI, HCL) Médico, Enfermera
2 Registrar apertura de HCL (datos personales) Médico, Enfermera
3 Registrar presentación de documentos de salud de estudiantes nuevos Médico
4 Consultar historial clínico Médico
5
Registrar la atención médica (Antecedentes, Hábitos y Adicionales de la especialidad, Signos vitales, Examen clínica, Motivo, Diagnóstico, Tratamiento) Médico
6 Registrar orden de despacho de insumos médicos (por suministro, por entrega) Médico
7 Consultar insumos médicos Médico, Enfermera Tabla 2.1: Lista de requisitos para el proceso de atención médica
7
MANUAL TÉCNICO - SAMWEB ENERO/2016
2.1.2 PROCESO DE MANEJO DE INVENTARIO:
En la siguiente tabla se puede apreciar la lista de requisitos con su respectivo
responsable para el proceso de manejo de inventario.
Nº Requisito Responsable
1
Generar listas de insumos médicos ( - Lista de insumos médicos agrupado por tipo de presentación o tipo de insumo médico - Lista de insumos médicos bajo saldo de re-orden agrupado por tipo de presentación o tipo de insumo médico)
Enfermera, Médico
2
Generar reporte de movimientos de insumos médicos ( - N de movimientos de ingreso realizados según ins. méd. por tipo de ingreso - N de movimientos de egreso realizados según ins. méd.por tipo de egreso - Número de insumos médicos ingresados según ins. méd.por tipo de ingreso - Número de insumos médicos egresados según ins. méd.por tipo de egreso)
Enfermera, Médico
3
Registrar despacho de orden de insumos médicos ( - por suministro, - por entrega) Enfermera
4
Registrar movimiento de inventario ( - egreso por entrega, - egreso por suministro, - egreso por baja, - egreso por ajuste faltante, - ingreso por compra, - ingreso por donación, - ingreso por ajuste excedente )
Enfermera, Médico
Tabla 2.2: Lista de requisitos para el proceso de manejo de inventario
2.1.3 PROCESO DE POLÍTICAS DEL SERVICIO DE ATENCIÓN
MÉDICA Y MANEJO DE INVENTARIO
En la siguiente tabla se puede apreciar la lista de requisitos con su respectivo
responsable para el Proceso de políticas del servicio de atención médica y
manejo de inventario.
Nº Requisito Responsable
1 Registrar personal médico Director DBEYSO
2 Registrar tipos de pacientes (Digitado)
Implementado 3 Registrar tipos de especialidades (Digitado)
4 Registrar tipos de movimientos de inventario (Digitado)
5 Registrar tipos de atención médica (Digitado)
6 Registrar tipos de estado de movimiento de inventario (Digitado)
7 Registrar insumo médico Director DBEYSO
8 Registrar tipos de insumos médicos y tipos de presentación Director DBEYSO Tabla 2.3: Lista de requisitos para el proceso de políticas del área médica.
8
MANUAL TÉCNICO - SAMWEB ENERO/2016
2.1.4 PROCESO DE ANÁLISIS DEL SERVICIO DE ATENCIÓN
MÉDICA Y MANEJO DE INVENTARIO
En la Tabla 2.4 se muestra la lista de requisitos con su respectivo responsable
para el Proceso de análisis de las políticas del servicio de atención médica y
manejo de inventario.
Nº Requisito Responsable
1 Generar número de pacientes atendidos según médico por tipo de paciente
Director, Médico, Enfermera
2 Generar número de pacientes atendidos según médico por años y meses Director, Médico, Enfermera
3 Generar número de pacientes atendidos según médico por especialidad Director, Médico, Enfermera
4 Generar número de pacientes atendidos según médico por tipo de atención médica
Director, Médico, Enfermera
5 Generar número de casos según diagnostico por sexo. Director, Médico, Enfermera
6 Generar número de casos según diagnostico por tipo de pacientes Director, Médico, Enfermera
7 Generar número de casos según diagnostico por edad Director, Médico, Enfermera
8 Generar número de movimientos de ingreso realizados según insumo médico por tipo de ingreso
Director, Médico, Enfermera
9 Generar número de insumos médicos ingresados según insumo médico por tipo de ingreso
Director, Médico, Enfermera
10 Generar número de movimientos de egreso realizados según insumo médico por tipo de egreso
Director, Médico, Enfermera
11 Generar número de insumos médicos egresados según insumo médico por tipo de egreso
Director, Médico, Enfermera
12 Generar lista de insumos médicos bajo saldo de re-orden agrupado por tipo de presentación
Director, Médico, Enfermera
13 Generar lista de insumos médicos agrupado por tipo de presentación Director, Médico, Enfermera
14 Generar lista de insumos médicos bajo saldo de re-orden agrupado por tipo de insumo médico
Director, Médico, Enfermera
15 Generar lista de insumos médicos agrupado por tipo de insumo médico Director, Médico, Enfermera
Tabla 2.4: Lista de requisitos para el proceso de análisis políticas del área médica
2.2 LISTA DE REQUISITOS NO FUNCIONALES
Los requisitos no funcionales se reconocieron considerando las características de
los usuarios, los parámetros de calidad esperados y la cobertura geográfica.
§ Características de los usuarios
La jefa de desarrollo de la DGIP y los usuarios del subsistema no
presentaron solicitudes especiales ni limitaciones en relación al correcto
uso que permitieran hacer una consideración especial de requisitos no
9
MANUAL TÉCNICO - SAMWEB ENERO/2016
funcionales. Se definieron los usuarios, perfiles y autorizaciones con
características de los usuarios
§ Parámetros de calidad
o Seguridad y confidencialidad: Solicitaron que el acceso al
subsistema sea a través de su propio módulo de autentificación
Central Authentication Service (CAS) ya implementado por la DGIP
para accesar a determinadas funciones del subsistema SAMWeb y
restringir el acceso a usuarios solo autorizados para evitar la
alteración de datos y el uso de datos no autorizados.
o Disponibilidad: El subsistema se encontrará accesible para los
usuarios en horarios de oficina de 8am a 5pm, este control no será
activado por SAMWeb sino que su activación dependerá de la DGIP.
o Portabilidad: Ante la eventualidad de que a futuro se cambiara de
sistema operativo, el subsistema será desarrollado con la plataforma
Java a pedido de la DGIP, debido a que Java es Multiplataforma
podría ser instalado en equipos servidores con otros sistemas
operativos.
o Integración: El subsistema estará integrado al Sistema de
información integrado de la Escuela Politécnica Nacional – SII, para
tomar los datos de identificación de los pacientes de los
subsistemas: Subsistema Académico Estudiantil Web (SAEw)
cuando son estudiantes matriculados y base de datos de RRHH
cuando son docentes o personal administrativo de la EPN.
Adicionalmente el subsistema permitirá tomar los datos de
identificación para todos los tipos de pacientes desde el servicio web
de consulta de datos del Registro Civil.
o
§ Cobertura geográfica
Si bien el subsistema atenderá trabajos dentro del Campus Politécnico, es
requerimiento de la DGIP que sea un subsistema web, de modo que podría
estar disponible fuera del campus para ser usado en distintos lugares
geográficos si tuvieran previsto realizar campañas.
10
MANUAL TÉCNICO - SAMWEB ENERO/2016
2.3 DIAGRAMA DE REQUISITOS
El diagrama de requisitos captura los requisitos funcionales levantados en el área
médica de la DBEYSO.
La Figura 2.1 muestra el Diagrama de requisitos del proceso de Atención médica:
uc Diagrama de requisitos del proceso de atención médica ambulatoria
Registrar apertura de HCL
Consultar historial clínico
Registrar atención médica
Registrar orden de despacho de insumos médicos
Consultar datos de identificación del paciente
Nombre: Diagrama de requisitos del proceso de atención médica ambulatoriaAutor: Diana Oña; Andrés Rosero T.Versión: 5.0Creado: 03/07/2014 23:18:10Actualizado:12/12/2015 22:38:24
Validar apertura de HCL
Validar atención médica
Validar orden de despacho de insumos médicos
Consultar paciente
Registrar presentación de documentos de salud de estudiantes nuevos
Buscar datos de identificación en el Sistema relacionado SAEW
Validar presentación de documentos de salud de estudiantes nuevos
Buscar datos de identificación de pacientes en sistemas relacionados
Consultar insumos médicos
(from Manejo de inventario)
Figura 2.1: Diagrama de requisitos para el proceso de atención médica ambulatoria
11
MANUAL TÉCNICO - SAMWEB ENERO/2016
La Figura 2.2 muestra el Diagrama de requisitos para el proceso de manejo de
inventario.
uc Diagrama de requisitos del proceso de manejo de inv entario
Nombre: Diagrama de requisitos del proceso de manejo de inventarioAutor: Diana Oña; Andrés Rosero T.Versión: 4.0Creado: 03/07/2014 23:19:40Actualizado:13/12/2015 1:56:46
Validar movimiento de inventario
Registrar despacho de orden de insumos médicos
Validar despacho de orden de insumos médicos
Modificar a liberado las ordenes de medicación no despachadas por más de 1 día
Visualizar orden de medicación pendiente
Registrar movimiento de inventario
Consultar insumos médicos
Consultar movimientos de inventario
Generar l istas de insumos médicos
(from Análisis del servicio)
Generar reportes de movimientos de insumos médicos
(from Análisis del servicio)
Figura 2.2: Diagrama de requisitos del proceso de manejo de inventario
12
MANUAL TÉCNICO - SAMWEB ENERO/2016
La Figura 2.3 muestra el Diagrama de requisitos del proceso de políticas del
servicio de atención médica ambulatoria y manejo de inventario.
uc Diagrama de requisitos del proceso de políticas del serv icio de atención médica y manejo de inv entario
Registrar personal médico
Registrar tipos de paciente (Digitado)
Registrar tipos de especialidad (Digitado)
Registrar tipos de movimiento de inventario (Digitado)
Registrar tipos de estado de movimiento de inventario (Digitado)
Registrar tipos de atención médica (Digitado)
Nombre: Diagrama de requisitos del proceso de políticas del servicio de atención médica y manejo de inventarioAutor: Diana Oña; Andrés Rosero T.Versión: 5.0Creado: 03/07/2014 23:20:09Actualizado:06/01/2016 8:14:33
Validar personal médico
Registrar tipos de inumo médico (Digitado)
Registrar tipos de presentación de insumos médicos (Digitado)
Registrar insumo médico
Validar insumo médico
Buscar datos de identificación en sistemas relacionados
Figura 2.3: Diagrama de requisitos del proceso de políticas del servicio de atención médica y manejo
de inventario
13
MANUAL TÉCNICO - SAMWEB ENERO/2016
La Figura 2.4 muestra el Diagrama de requisitos del proceso de análisis del
servicio de atención médica y manejo de inventario.
uc Diagrama de requisitos del proceso de análisis del serv icio de atención médica y manejo de inv entario
Generar número de pacientes atendidos según médico por tipo de paciente
Generar número de pacientes atendidos según médico por años y meses
Generar número de casos según diagnostico por sexo
Nombre: Diagrama de requisitos del proceso de análisis del servicio de atención médica y manejo de inventarioAutor: Diana Oña; Andrés Rosero T.Versión: 5.0Creado: 03/07/2014 23:19:59Actualizado:13/12/2015 1:39:13
Generar reportes de casos atendidos
Generar número de pacientes atendidos según médico por especialidad
Generar l istas de insumos médicos
Generar número de casos según diagnostico por tipo de pacientes
Generar número de casos según diagnostico por edades
Generar reportes de movimientos de insumos médicos
Generar número de pacientes atendidos según médico por tipo de atención médica
Generar reportes de pacientes atendidos
Generar l ista de insumos médicos agrupado por tipo de presentación
Generar l ista de insumos médicos agrupado por tipo de insumo médico
Generar l ista de insumos médicos bajo saldo de re-orden agrupado por tipo de presentación
Generar l ista de insumos médicos bajo saldo de re-orden agrupado por tipo de insumo médico
Generar número de movimientos de ingreso realizados según insumo médico por tipo de ingreso
Generar número de movimientos de egreso realizados según insumo médico por tipo de egreso
Generar número de insumos medicos ingresados según insumo médico por tipo de ingreso
Generar número de insumos medicos egresados según insumo médico por tipo de egreso
Figura 2.4: Diagrama de requisitos del proceso de análisis del servicio de atención médica y manejo
de inventario
14
MANUAL TÉCNICO - SAMWEB ENERO/2016
3 MODELO DE ANÁLISIS
Para obtener una arquitectura consistente se analizó y estructuraron los requisitos
capturados. Para comprender el funcionamiento interno del subsistema se
empezó por reconocer los actores, las clases que intervienen y posibles riesgos
críticos.
3.1 DIAGRAMA DE ACTORES
La Figura 3.1 muestra los actores que interactúan con el subsistema SAMWeb.
uc Diagrama de actores
Médico Enfermera
Usuario
Director
Médico-Enfermera
Figura 3.1: Diagrama de actores del subsistema SAMWeb
15
MANUAL TÉCNICO - SAMWEB ENERO/2016
3.2 DIAGRAMA DE CASOS DE USO A NIVEL CONTEXTUAL
A nivel de contexto los casos de uso se visualizan en la Figura 3.2
uc Diagrama de casos de uso a niv el contextual
Atención médica
ambulatoria
Manejo de inv entario
Políticas del serv icio de
atención médica y manejo de
inv entario
Análisis del serv icio de
atención médica y manejo de
inv entario
Enfermera
(from Actores)
Médico
(from Actores)
Médico-Enfermera
(from Actores)
Director
(from Actores)
Nombre: Diagrama de casos de uso a nivel contextualAutor: Diana Oña; Andrés Rosero TVersión: 3.0Creado: 13/08/2014 5:16:19Actualizado:14/12/2015 1:05:28
Usuario
(from Actores)
Central Authentication
Serv ice
Figura 3.2: Diagrama de casos de uso a nivel contextual del subsistema SAMWeb
16
MANUAL TÉCNICO - SAMWEB ENERO/2016
3.3 DIAGRAMA DE CLASE DE ANÁLISIS
En la siguiente figura se puede visualizar el diagrama de clase de análisis para el
subsistema.
class Diagrama de clase de análisis
Nombre: Diagrama de clase de análisisAutor: Diana Oña; Andrés Rosero T.Versión: 2Creado: 14/12/2015 1:17:08Actualizado:14/12/2015 1:49:54
Tipo_estado_mov imiento_inv entario
Atencion_medica
Detalle_mov imiento_inv entario
Insumo_medico
Mov imiento_inv entario
Paciente
Personal
Tipo_CIE
Tipo_especialidad
Tipo_mov imiento_inv entario
Tipo_paciente Tipo_atencion_medica
Tipo_presentacion_insumo_medico Tipo_insumo_medico
0..*atencionMed_personal
+atiende
1
0..*
atencion_movimiento
+dispone 1
+atendido
1atencion_paciente
0..*
1
atencion_diagnostico
+diagnosticado con
0..*
+califica 1
tipo_insumoMedico
0..*
+califica 1
tipo_presentacion
0..*
+se encuentra en
0..*
tipo_estado_movimiento
1
+registra
1personal_movimiento_inventario
0..*
0..*movimiento_inventario_tipo
+califica
1
0..*
movimientoInventario_detalle
+incluye 1
+mueven 0..*
insumoMedico_detalleMovimiento
1
+corresponde 0..*
atencion_medica_tipo
1
0..*
personal_tipo_especialidad
+califica 1
+es de 0..*
paciente_tipo_paciente
1
Figura 3.3: Diagrama de clase de análisis
17
MANUAL TÉCNICO - SAMWEB ENERO/2016
3.4 LISTA DE RIESGOS CRÍTICOS Y SU VIABILIDAD
Para listar los riesgos críticos se utiliza la notación:
R + Número del riesgo + Descripción del riesgo.
R1. Estimaciones de tiempo deficientes.
Viabilidad: Ajustarse a los tiempos estimados en la planificación realizada.
R2. No se ha realizado una revisión de los procesos levantados desde el 2009.
R3. La no aprobación de la propuesta de unificación de los procesos de Atención
médica ambulatoria y de Atención ginecológica.
Viabilidad: Se solucionó con reuniones sucesivas insistentes para conseguir la
aprobación pronta de la propuesta de unificación por el área de Procesos de la
DGIP.
R4. El Proceso de manejo de inventario no se encontraba formalmente definido.
Viabilidad: Levantar y aprobar formalmente el Proceso de manejo de inventario y
los flujos que de este se desprenden por parte de la DGIP.
R5. La falta de respuesta por parte de la DGIP para la aprobación y formalización
de los procesos propuestos.
Viabilidad: Presionar al personal de la DGIP para obtener una pronta respuesta,
brindando toda la colaboración e información necesaria por parte de los autores.
R6. La falta de conocimiento formal de la teoría de procesos por parte del
personal médico de la DBEYSO.
Viabilidad: Explicar de manera fácil y generalizada la teoría de procesos, los
elementos que se utilizan para su representación y realizar continuas revisiones
para validar y continuar con los avances planificados.
18
MANUAL TÉCNICO - SAMWEB ENERO/2016
4 MODELO DE DISEÑO
Para obtener una arquitectura que soporte todos los requisitos reconocidos se
diseñó la parte funcional, estructural, dinámica y de despliegue del subsistema
SAMWeb partiendo de los flujos anteriores. Permitiendo así tener un modelo de
diseño que soporte las técnicas de programación gráfica.
4.1 DISEÑO FUNCIONAL
En el Diseño funcional del subsistema se representaron los requisitos centrales
del Modelo de requisitos en el Diagrama de casos de uso por módulo.
4.1.1 DIAGRAMA DE CASOS DE USO POR MODULO
En la Figura 4.1 se muestra el diagrama de casos de uso del módulo del proceso
atención médica ambulatoria.
uc Diagrama de CU del proceso de atencion médica ambulatoria
Registrar apertura de HCL
Registrar orden de despacho de insumos
médicos
Consultar historial clínico
Registrar atención
médica
Médico
(from Actores)
Enfermera
(from Actores)
Nombre: Diagrama de CU del proceso de atencion médica ambulatoriaAutor: Diana Oña; Andrés Rosero T.Versión: 7.0Creado: 04/07/2014 2:10:35Actualizado:22/12/2015 3:08:23
Buscar datos de identificación de pacientes
en sistemas relacionados
Validar atención
médica
Validar orden de despacho de
insumos médicos
Central Authentication
Serv ice
Registrar presentación de
documentos de salud de estudiantes nuev os
Validar presentación de
documentos de salud de estudiantes nuev os
Validar apertura de HCL
«include»«include»
«include»
«extend»
«include»
«include»
«extend»
«include»
Figura 4.1: Diagrama de casos de uso del módulo del proceso atención médica ambulatoria
19
MANUAL TÉCNICO - SAMWEB ENERO/2016
En la Figura 4.2 se muestra el diagrama de casos de uso del módulo del proceso
de manejo de inventario.
uc Diagrama de CU del proceso de manejo de inv entario
Registrar despacho de orden de insumos
médicos
Enfermera
(from Actores)
Nombre: Diagrama de CU del proceso de manejo de inventarioAutor: Diana Oña; Andrés Rosero T.Versión: 7.0Creado: 04/07/2014 2:10:12Actualizado:13/12/2015 1:57:25
Validar mov imiento de inv entario
Registrar mov imiento de inv entario
(from Atencion médica ambulatoria)
Central Authentication
Serv ice
«include»
Figura 4.2: Diagrama de CU del módulo del proceso de manejo de inventario
20
MANUAL TÉCNICO - SAMWEB ENERO/2016
En la Figura 4.3 se muestra el diagrama de casos de uso del módulo del proceso
de políticas del servicio de atención médica y manejo de inventario.
uc Diagrama de CU del proceso de políticas del serv icio de atención médica y manejo de inv entario
Nombre: Diagrama de CU del proceso de políticas del servicio de atención médica y manejo de inventarioAutor: Diana Oña; Andrés Rosero T.Versión: 4.0Creado: 04/07/2014 2:10:26Actualizado:06/01/2016 6:00:03
Registrar personal médico
Registrar tipos de paciente (Digitado)
Registrar tipos de especialidad
(Digitado)
Registrar tipos de mov imiento de
inv entario (Digitado)
Registrar tipos de atención médica
(Digitado)
Director
(from Actores)
(from Atencion médica ambulatoria)
Central Authentication
Serv ice
Registrar tipos de estado de mov imiento de inv entario (Digitado)
Registrar tipos de insumo médico
(Digitado)
Validar personal médico
Registrar tipos de presentación de
insumo médico
(Digitado)
Registrar insumo médico
Validar insumo médico
Enfermera
(from Actores)
«include»
«include»
Figura 4.3: Diagrama de CU del módulo del proceso de políticas del servicio de atención médica y
manejo de inventario
21
MANUAL TÉCNICO - SAMWEB ENERO/2016
En la Figura 4.4 se muestra el diagrama de casos de uso del módulo del proceso
de análisis del servicio de atención médica y manejo de inventario.
uc Diagrama de CU del proceso de análisis del serv icio de atención médica y manejo de inv entario
Nombre: Diagrama de CU del proceso de análisis del servicio de atención médica y manejo de inventarioAutor: Diana Oña; Andrés Rosero T.Versión: 4.0Creado: 04/07/2014 2:09:59Actualizado:13/12/2015 2:03:59
Médico-Enfermera
(from Actores)
Administrar criterios de selección
Generar reportes de "Mov imientos de insumos
médicos"
Generar reportes de "Pacientes atendidos"
Generar reportes de "Casos atendidos"
(from Atencion médica ambulatoria)
Central Authentication
Serv ice
Generar listas de "Insumos médicos"
Figura 4.4: Diagrama de CU del módulo del proceso de análisis del servicio de atención médica y
manejo de inventario
22
MANUAL TÉCNICO - SAMWEB ENERO/2016
4.1.2 DESCRIPCIÓN DE LOS CASOS DE USO
A continuación se encuentran enumerados todos los casos de uso indicados
anteriormente. Mientras que para todos los reportes generados se ha adjuntado
un esbozo del reporte.
4.1.2.1 Casos de uso para el proceso de Atención médica ambulatoria
4.1.2.1.1 C.U.: REGISTRAR ATENCIÓN MÉDICA Descripción: Este caso de uso permite al usuario registrar toda la información
generada en la Atención médica, por ejemplo: signos vitales, motivo, examen
clínico, diagnóstico, tratamiento y pedido o resultado de exámenes médicos. Esta
información es ingresada como texto. El médico puede completar el diagnóstico
seleccionando la Topografía.
El usuario puede:
· Consultar el paciente registrado en la base de datos SAMWEB.
· Actualizar hábitos, antecedentes y adicionales para completar información de
la historia clínica del paciente.
· Consultar el historial clínico del paciente visualizando el detalle de atenciones
pasadas.
Requisitos incluidos:
· Consultar paciente
· Registrar antecedentes, hábitos y adicionales de la especialidad
· Registrar atención médica
Restricciones
· Pre-condición o El usuario debe tener permisos sobre la opción. o Al menos debe existir un paciente registrado en la base de datos
SAMWEB. · Post-condición
o Atención Médica registrada
Escenarios
23
MANUAL TÉCNICO - SAMWEB ENERO/2016
· Escenario básico:
10. Validar las precondiciones.
15. El subsistema le permite al usuario escoger el Tipo de atención, la Fecha y la
Hora se cargan automáticamente del sistema.
18. El subsistema le permite al usuario ingresar el criterio de búsqueda para
consultar un paciente, puede ser Número de cédula (texto de 10 caracteres),
Nombres y apellidos (Texto de 120 caracteres) o Número de HCL (tipo integer).
20. Si el usuario pulsa “Buscar paciente”
20.1. Valida que el criterio de búsqueda haya sido ingresado.
20.2. Busca por acercamiento hacia apellidos (texto de 200 caracteres) o
nombres (texto de 200 caracteres) o cédula (texto de 10 caracteres, sin
guion medio) o HCL, ejecutando el método
Paciente.obtenerListaPacientes(criterio String).
20.3. Despliega en una grilla los pacientes que coinciden con el criterio de
búsqueda para que el usuario escoja un paciente de la grilla.
Los datos de la grilla son: Número de cédula (texto de 10 caracteres, sin
guion medio), Nombres y apellidos (texto de 200 caracteres), Tipo de
paciente (texto de 100 caracteres), HCL (tipo integer), y los datos con la
característica de columna escondida: id_tipo de paciente (tipo integer),
Edad (tipo integer) dato calculado a partir de la Fecha de nacimiento (tipo
date), Sexo (texto de 10 caracteres), Nacionalidad (texto de 30 caracteres),
Id_paciente (tipo integer), Hábitos tabaco (texto de 3000 caracteres),
Hábitos alcohol (texto de 3000 caracteres), Otros hábitos (texto de 3000
caracteres), Antecedentes familiares (texto de 3000 caracteres),
Antecedentes personales (texto de 3000 caracteres), Adicionales (texto de
3000 caracteres), Grupo sanguíneo (texto de 1) y Factor RH (texto de 8
caracteres).
24
MANUAL TÉCNICO - SAMWEB ENERO/2016
30. Si el usuario escoge un paciente de la grilla llena la sección Datos del
paciente con los datos obtenidos de la grilla. Los datos son: Número de cédula,
Paciente (nombres y apellidos), Tipo de paciente, HCL, Edad, Sexo, Nacionalidad.
40. Presenta las pestañas: Detalle de atención médica, Consultar historial clínico.
50. Por defecto presenta activa la pestaña “Detalle de atención médica”. Esta
pestaña tiene las siguientes secciones:
50.1. Sección Hábitos, antecedentes y adicionales con los siguientes datos:
Hábitos tabaco (texto de 3000 caracteres), Hábitos alcohol (texto de 3000
caracteres), Hábitos Otro (texto de 3000 caracteres), Antecedentes
familiares (texto de 3000 caracteres), Antecedentes personales (texto de
3000 caracteres), Adicionales (texto de 3000 caracteres), Grupo sanguíneo
(texto de 1) y Factor RH (texto de 8 caracteres). Todos estos datos se
cargan automáticamente al seleccionar un paciente en la grilla anterior.
50.2. Sección de Signos vitales (Texto de 100 caracteres) con los
siguientes datos: Peso, Talla, IMC, Temperatura, Pulso, Respiración,
Tensión arterial sistólica, Tensión arterial diastólica. El Índice de masa
corporal (IMC) se calcula automáticamente a partir del Peso y la Talla.
50.3. Sección Motivo para digitar el motivo (texto de 3000 caracteres) de la
consulta médica.
50.4. Sección Examen clínico para digitar el examen clínico (texto de 3000
caracteres) de la consulta médica.
50.5. Sección Diagnóstico con los siguientes datos: Grupo topográfico con
acercamiento, Subsitio topográfico con acercamiento (ambos tienen Código
topográfico texto de 9 caracteres y nombre topográfico texto de 300
caracteres) y el Diagnóstico descriptivo (texto de 3000 caracteres).
50.6. Sección Tratamiento para digitar el tratamiento (texto de 3000
caracteres) de la atención médica.
50.7. Sección Exámenes médicos para digitar los exámenes médicos (texto
de 3000 caracteres) de la atención médica.
25
MANUAL TÉCNICO - SAMWEB ENERO/2016
50.8 Sección Orden de despacho, para agregar una “Nueva orden de
despacho” y mostrar en una grilla las órdenes de despacho (entrega,
suministro) agregadas.
Los datos de la grilla son: Orden tipo (texto de 60 caracteres) para
diferenciar si es un egreso por despacho (entregar) o egreso por despacho
(suministrar).
Las acciones permitidas para cada fila son: Visualizar orden de medicación
y Eliminar orden de medicación.
70. Si usuario pulsa “Nueva Orden de despacho”, en la sección Orden de
despacho.
70.1. Ejecuta el caso de uso extensor: Registrar orden de despacho de
insumos médicos.
74. Si el usuario pulsa “Eliminar” en uno de las ordenes tipo. Se presenta el
mensaje “Seguro de que desea eliminar el insumo médico”.
74.1. Si el usuario pulsa “SI”, se elimina la orden de despacho.
75. Si el usuario pulsa el botón “Grabar atención médica”
75.10. Ejecuta el caso de uso incluido: Validar atención médica.
75.20. Ejecuta el método Paciente.guardarPaciente(Paciente).
75.30 Ya sea que la atención médica incluya órdenes de despacho o no se
ejecuta el método Atencionmedica.guardarAtencion(Atencionmedica),
internamente realiza las acciones desde 75.40 hasta 75.46 del escenario
básico.
75.40. Ejecuta el caso de uso incluido: Validar orden de despacho de
medicación.
75.42. Ejecuta el método Movimiento_inventario.
guardarMovimientoInventario (movimientoInventario:
Movimiento_inventario) dicho método se encarga de guardar el movimiento
con sus detalles en Detalle_movimiento..
26
MANUAL TÉCNICO - SAMWEB ENERO/2016
75.44. Si la transacción atómica de la orden de despacho de medicación es
exitoso devuelve el id generado. Si no pudo grabar, devuelve un indicador
que exprese que falló la grabación.
75.46. Devuelve “True” para indicar que la grabación del movimiento fue
exitosa y continúa con la acción 75.48 del escenario básico.
75.48. Si recibe “True” de la acción 75.46 continúa con la acción 75.50 del
escenario básico, como indicador de que el registro del movimiento de
inventario ha sido exitoso.
75.50 Si la transacción atómica de guardar la atención médica es exitosa
devuelve el id generado. Si no pudo grabar, devuelve un indicador que
exprese que falló la grabación, continúa con la siguiente acción.
75.60. Emitir mensaje “Registro correcto”.
80. Si usuario pulsa la pestaña “Consultar historial clínico”.
80.1. Ejecuta el caso de uso extensor: Consultar historial clínico
enviando el parámetro id paciente.
90. Si el usuario no realiza ninguna acción o no guarda la atención médica.
90.1. El caso de uso termina.
· Escenario excepción: Para la acción 10
10. Emitir mensaje de la precondición que no se cumple.
20. El caso de uso termina.
Para la acción 20.1
10. Emitir mensaje “El criterio de búsqueda debe contener algún dato parcial de
cédula, apellidos, nombres o historia clínica”.
20. Regresar al escenario básico, acción 20.
27
MANUAL TÉCNICO - SAMWEB ENERO/2016
Para la acción 20.2
10. Emitir mensaje “No hay coincidencias”.
20. Regresar al escenario básico, acción 20.
Para la acción 70.1
10. Regresar al escenario básico, acción 15.
Para la acción 70.2
10. Emitir el mensaje de error que exprese la falla específica al intentar guardar
los Hábitos, antecedentes y adicionales.
20. El caso de uso termina.
Para la acción 70.3
10. Emitir el mensaje de error “Error al guardar”.
20. El caso de uso termina.
Para la acción 70.4
10. Emitir el mensaje de error “Error al guardar”.
20. El caso de uso termina.
Para la acción 75.46
10. Devuelve “False” lo que indica una falla al intentar guardar Movimiento de
inventario al método que lo invoca.
20. Regresar al escenario básico, acción 75.50.
4.1.2.1.2 C.U.: VALIDAR ATENCIÓN MÉDICA
Descripción: Permite validar que los datos de la atención médica se hayan
ingresado correctamente para ser guardados.
28
MANUAL TÉCNICO - SAMWEB ENERO/2016
Requisitos incluidos:
· Validar antecedentes, hábitos y adicionales de la especialidad
· Validar atención médica
Restricciones
· Pre-condición o El usuario debe tener permisos sobre la opción.
· Post-condición o Ninguna
Escenarios
· Escenario básico:
10. Valida que los campos ingresados correspondan a las longitudes y tipos de
datos establecidos.
20. Validar que se haya seleccionado Tipo de atención médica.
30. Valida que se haya seleccionado el Subsitio topográfico.
40. Si no hay mensajes de error acumulados retorna un indicador de éxito de la
validación.
50. El caso de uso termina.
· Escenario excepción: Para la acción 10
10. Acumula mensaje de error que exprese la falla específica de tipo de dato o
longitud para cada dato capturado.
20. Retorna al escenario básico acción 20.
Para la acción 20
10. Acumula mensaje de error que exprese la falla “Seleccione Tipo de atención
médica”.
20. Retornar acción básico 30.
29
MANUAL TÉCNICO - SAMWEB ENERO/2016
Para la acción 30
10. Acumula mensaje de error que exprese la falla “Seleccione el diagnóstico
(Subsitio topográfico)”.
20. Retornar acción básico 40.
Para la acción 40
10. Despliega el mensaje de error acumulado
20. Retorna un indicador de validación fallida.
30. El caso de uso termina
30
MANUAL TÉCNICO - SAMWEB ENERO/2016
4.1.2.1.3 C.U.: REGISTRAR ORDEN DE DESPACHO DE INSUMOS MÉDICOS Descripción: Permite registrar un nuevo movimiento de inventario de Tipo egreso
por despacho (suministro o entrega) antes de grabar la atención médica.
Requisitos incluidos:
· Consultar saldo de medicamentos
· Registrar orden de medicación
Restricciones
· Pre-condición o El usuario debe tener permisos sobre la opción.
· Post-condición o El Tipo de estado del movimiento se guarda como Comprometido.
Escenarios
· Escenario básico:
08. El subsistema muestra una sección para realizar las actividades de agregar la
orden de despacho.
10. El subsistema internamente como dato oculto asigna los siguientes datos: el
médico Responsable que realiza la transacción (texto de 200 caracteres),
id_personal (tipo integer) que realiza la transacción, el motivo del movimiento
(texto de 400 caracteres) se asigna el texto “Recetado por el médico.”, el Código
de documento (texto de 100 caracteres) se asigna a modo de texto el código del
médico del Ministerio de Salud Pública.
15. El subsistema le permite al usuario activar la casilla de verificación para
Suministrar la medicación en ese momento. Si la casilla se encuentra activa el
Tipo de movimiento de inventario (texto de 100 caracteres) se calificaría como
Egreso por despacho (suministro), caso contrario como Egreso por despacho
(entrega).
20. Si en Emitir orden de despacho de insumos médicos el usuario pulsa el botón
“Agregar insumos médicos”
31
MANUAL TÉCNICO - SAMWEB ENERO/2016
20.1. Permite Agregar los insumos médicos al detalle de la transacción.
20.2. El subsistema le permite al usuario buscar Insumos médicos por
acercamiento ingresando mínimo 3 caracteres del Nombre genérico (texto
de 60 caracteres), ejecutando el método
Insumo_medico.obtenerListaInsumos(criterio String).
20.3. Si hay coincidencias, muestra a manera de combo la lista de
resultados.
20.4. Al seleccionar un insumo médico, se valida que la Cantidad
comprometida sea menor a la Cantidad actual, se carga a modo de lectura
la Cantidad actual y la Cantidad comprometida, y como dato oculto se
carga el id_insumoMedico (tipo integer).
20.5. El subsistema le permite al usuario ingresar la Cantidad transaccional
(tipo integer) que va a recetar.
30. Si en “Agregar insumo médico” el usuario pulsa el botón “Consultar insumo
médico”
30.1. Ejecutando el método Insumo_medico.obtenerListaInsumos(criterio
String) y devuelve la lista de insumos médicos disponibles
30.2. Despliega en una grilla los insumos médicos encontrados para que el
usuario escoja el deseado.
Los datos de la grilla son: Nombre genérico (texto de 60 caracteres),
Presentación (texto de 60 caracteres), Cantidad actual (tipo integer) y el
dato id_insumoMedico (tipo integer) con la característica de columna
escondida.
30.3. Regresar a la acción 20.4 del escenario básico.
40. Si en “Agregar insumo médico” el usuario pulsa el botón “Añadir al detalle”
40.1. Valida que la Cantidad transaccional no supere a la resta entre la
Cantidad actual y la Cantidad comprometida.
32
MANUAL TÉCNICO - SAMWEB ENERO/2016
40.2 El insumo médico se agrega dentro de la grilla Detalle de la
transacción. Los datos de la grilla son: Nombre genérico, Presentación,
Cantidad actual y Cantidad transaccional. La acción permitida para cada
insumo médico añadido es: Eliminar.
50. Si en Emitir orden de despacho de insumos médicos el usuario pulsa el botón
“Guardar orden de despacho”:
50.1 Se almacena en memoria las órdenes para ser guardadas
posteriormente por el caso de uso que invocó este escenario.
50.2 Continúa con la acción 70 del escenario básico.
60. Si el usuario pulsa el botón “Atrás”
60.1. Continuar en la acción 70 del escenario básico.
70. El caso de uso termina.
· Escenario excepción: Para la acción 20.2
10. Añadir como ITEMTIP “No hay coincidencias”.
20. Regresar al escenario básico, acción 20.
Para la acción 20.4 10. Emitir mensaje “No hay suficientes unidades.” 20. Regresar al escenario básico, acción 20.
Para la acción 30.1
10. Emitir mensaje “No hay insumos médicos disponibles”.
20. Regresar al escenario básico, acción 20.
Para la acción 40.1 10. Emitir mensaje “La cantidad transaccional supera a las unidades disponibles.” 20. Regresar al escenario básico, acción 20.2
33
MANUAL TÉCNICO - SAMWEB ENERO/2016
Para la acción 50.1 10. Regresar al escenario básico, acción 20.
Para la acción 50.3
10. Emitir el mensaje de error que exprese la falla específica al intentar guardar el
Detalle de movimiento de inventario.
20. Regresar al escenario básico, acción 20.
1.1.1.1.1. C.U.: VALIDAR ORDEN DE DESPACHO DE INSUMOS MÉDICOS
Descripción: Permite validar que los datos de la orden de despacho de
medicación se hayan ingresado correctamente para ser guardados.
Requisitos incluidos:
· Validar orden de medicación
Restricciones
· Pre-condición o El usuario debe tener permisos sobre la opción.
· Post-condición o Ninguna
Escenarios
· Escenario básico:
10. Valida que exista al menos un insumo médico en el detalle.
20. Si no hay mensajes de error acumulados retorna un indicador de éxito de la
validación.
30. El caso de uso termina.
34
MANUAL TÉCNICO - SAMWEB ENERO/2016
· Escenario excepción: Para la acción 10
10. Acumula el mensaje de error que exprese la falla “Agregue insumos médicos”.
20. Retorna al escenario básico acción 20.
Para la acción 20
10. Despliega el mensaje de error acumulado
20. Retorna un indicador de validación fallida.
30. El caso de uso termina
4.1.2.1.4 C.U.: CONSULTAR HISTORIAL CLÍNICO
Descripción: Este caso de uso permite consultar las atenciones médicas
anteriores del paciente.
Requisitos incluidos:
· Consultar historial clínico del paciente
Restricciones
· Pre-condición
o El usuario debe tener permisos sobre la opción.
o El usuario debe haber ejecutado la opción Registrar atención médica,
buscado un paciente y seleccionarlo para cargar sus datos.
· Post-condición
o Ninguna
Escenarios
· Escenario básico:
10. El subsistema toma el Id_paciente que se encuentra disponible y ejecuta el
método Antencion_Medica.obtenerListaAtenciones(String criterio).
35
MANUAL TÉCNICO - SAMWEB ENERO/2016
10.1. Si encontró coincidencias, despliega en una grilla atenciones pasadas
en orden cronológico asociados al paciente.
Los datos de la grilla son: Número ordinal (tipo integer), Fecha (tipo date),
Especialidad (texto de 100 caracteres), Tipo de atención (texto de 100
caracteres), Diagnóstico (concatenación de Código topográfico texto de 9
caracteres y Nombre topográfico texto de 300 caracteres), Orden de
Medicación (texto de 15 caracteres) que sirve para saber si hay órdenes de
medicación asociadas a esa atención médica; y los siguientes datos con
característica de columna oculta: id_atenciónMedica (tipo integer), Hora de
la atención (tipo time), Doctor (concatenación de Apellido1, Apellido2 y
Nombre1 del personal asociado a esa atención textos de 60 caracteres);
Signos vitales (texto de 100 caracteres que concatenan: Peso, Talla, IMC,
Temperatura, Pulso, Respiración, Tensión arterial sistólica, Tensión arterial
diastólica, el Índice de masa corporal (IMC) se calcula automáticamente a
partir del Peso y la Talla); Motivo (texto de 3000 caracteres) de la consulta
médica, Examen clínico (texto de 3000 caracteres) de la consulta médica;
el diagnóstico con los siguientes datos: Grupo topográfico con
acercamiento, Subsitio topográfico con acercamiento (ambos tienen Código
topográfico texto de 9 caracteres y nombre topográfico texto de 300
caracteres) y el Diagnóstico descriptivo (texto de 3000 caracteres);
Tratamiento (texto de 3000 caracteres) de la consulta médica, y Exámenes
médicos (texto de 1000 caracteres); en el caso de haber órdenes de
medicación también se carga el id_movimientoInventario (tipo integer),
Fecha y hora de la orden de medicación (tipo date time), el Motivo del
movimiento (texto de 400 caracteres), y el Código de documento que
sustentó la orden (texto de 100 caracteres).
10.2. Permite que el usuario escoja una atención pasada.
20. Si el usuario sobre la grilla presiona en “Ver detalle” de una atención médica
pasada.
20.1. Permite visualizar el detalle de la atención seleccionada.
36
MANUAL TÉCNICO - SAMWEB ENERO/2016
20.2. Únicamente si existen datos registrados carga y muestra a modo de
lectura las secciones: Signos vitales, Motivo, Examen clínico, Diagnóstico,
Tratamiento y Exámenes médicos.
20.3. Si existen órdenes de medicación asociadas a la atención médica
indicado en la columna Medicación como Entregada o Suministrada carga
la cabecera y el detalle:
La Cabecera contiene la Fecha y hora de la orden de medicación (tipo date
time), el Motivo del movimiento (texto de 400 caracteres), y el Código de
documento que sustentó la orden (texto de 100 caracteres), Tipo de
movimiento (texto de 100 caracteres), Responsable (texto de 120
caracteres).
20.4. Para desplegar el detalle del movimiento se ejecuta el método
Detalle_movimiento.obtenerListaDetallesMovimientos(id_movimientoIntege
r)
20.5. Devuelve los Detalles de la orden.
El detalle consta de: el id_insumo_medico (tipo integer), el nombre del
insumo médico (texto de 60 caracteres), la presentación del insumo médico
(texto de 60 caracteres), la cantidad (tipo integer).
30. Si el usuario presiona el botón “Imprimir historial clínico”
30.1. Se ejecuta el reporte “Generar el reporte de historial clínico”.
40. El caso de uso finaliza.
· Escenario excepción:
Para la acción 10.1
10. Emitir mensaje “No hay atenciones médicas registradas”.
20. Regresar al escenario básico, acción 40.
37
MANUAL TÉCNICO - SAMWEB ENERO/2016
4.1.2.1.5 C.U.: REGISTRAR APERTURA DE HCL Descripción: Permite al usuario registrar los datos de identificación de un
paciente que no se encuentra en la base de datos SAMWeb y asignar un número
de historia clínica. Los datos de identificación de todos los pacientes se pueden
consultar en sistemas relacionados.
Únicamente cuando los sistemas relacionados no se encuentran disponibles los
datos de identificación se ingresan manualmente en los campos obligatorios
respectivos.
Requisitos incluidos:
· Registrar apertura de HCL
Restricciones
· Pre-condición o El usuario debe tener permisos sobre la opción. o Los datos de identificación del paciente no deben estar registrados en la
base de datos SAMWeb. · Post-condición
o Paciente registrado.
Escenarios
· Escenario básico:
10. Validar las precondiciones.
15. Si el usuario presiona “Nuevo paciente”
15.1. Se genera un Número de historia clínica para el nuevo paciente.
15.2. Para completar el registro de los datos de identificación del paciente,
el subsistema le permite al usuario consultar dichos datos en fuentes
externas confiables o ingresarlos manualmente.
o Para consultar los datos de identificación en una fuente externa el caso de uso continúa en la acción 20.
o Para ingresar los datos de identificación manualmente el caso de uso continúa en la acción 30.
20. Si, en Nuevo paciente, el usuario pulsa “Buscar datos de identificación”
38
MANUAL TÉCNICO - SAMWEB ENERO/2016
20.1. Ejecuta el caso de uso incluido: Buscar datos de identificación de
pacientes en sistemas relacionados.
20.2. Si los datos de identificación son válidos, carga la información a modo
de lectura en el formulario de Nuevo paciente.
20.3. Continuar en la acción 40.
30. En caso de que cualquiera de los subsistemas alternos no se encuentren
disponibles, no arrojen resultados o no se realice consulta alguna
30.1 El usuario debe digitar la información del paciente.
40. Los datos de identificación del paciente que se deben cargar, ingresar o
seleccionar son:
§ Tipo de paciente (Estudiante, Docente, Administrativo, Otro), § Número de cédula (texto de 10 caracteres), § Apellido1 (texto de 30 caracteres), § Apellido2 (texto de 30 caracteres), § Nombre1 (texto de 30 caracteres), § Nombre2 (texto de 30 caracteres), § Fecha de nacimiento (tipo de dato Date), § Sexo (texto de 10 caracteres), § Nacionalidad (texto de 30 caracteres).
50. Si el usuario presiona el botón “Grabar”.
50.1. Ejecuta el caso de uso incluido: Validar apertura de HCl.
50.2. Ejecuta el método Paciente.guardarPaciente (Número de HCL String,
Número de cédula String, Apellido1 String, Apellido2 String, Nombre1
String, Nombre2 String, Fecha de nacimiento Date, Sexo String,
Nacionalidad String), si es exitosa, devuelve el id generado para el
paciente. Si no pudo grabar, devuelve un indicador que exprese que falló la
grabación.
50.3. El subsistema emite el mensaje “Registro correcto”.
60. Por defecto el subsistema muestra la sección “Buscar pacientes registrados”
con una grilla de resultados vacía, el subsistema le permite al usuario ingresar el
39
MANUAL TÉCNICO - SAMWEB ENERO/2016
Número de cédula (texto de 10 caracteres, sin guion medio) o los Apellidos y
nombres (texto de 120 caracteres) para consultar los pacientes ya registrados en
la base de datos SAMWEB.
65. Si el usuario presiona el botón “Consultar paciente”
65.1. Valida que el criterio de búsqueda haya sido ingresado.
65.2. Busca los pacientes registrados con el criterio de búsqueda ingresado
ejecutando el método Paciente.obtenerListaPacientes(criterio String). Si no
devuelve resultados definitivos significa que el paciente aún no ha sido
registrado.
65.3. Despliega en una grilla los pacientes que coinciden con el criterio de
búsqueda.
Los datos de la grilla son: Historia clínica (texto de 11 caracteres), Número
de cédula (texto de 10 caracteres, sin guion medio), Nombres y apellidos
(texto de 120 caracteres), Tipo de paciente (texto de 100 caracteres), y los
datos con la característica de columna escondida: id_tipo de paciente (tipo
integer), Tipo de paciente (Estudiante, Docente, Administrativo, Familiares,
Otro), Número de cédula (texto de 10 caracteres), Apellido1 (texto de 30
caracteres), Apellido2 (texto de 30 caracteres), Nombre1 (texto de 30
caracteres), Nombre2 (texto de 30 caracteres), Fecha de nacimiento (tipo
de dato Date), Sexo (texto de 10 caracteres), Nacionalidad (texto de 30
caracteres) y Origen dato (texto de 15 caracteres).
Las acciones permitidas para cada fila de la grilla son: Editar, la acción
Editar solo se activa cuando el atributo Origen dato es Digitado.
70. Si el usuario presiona “Ver detalles”, se despliegan los datos de identificación
del paciente seleccionado.
80. Si el usuario presiona “Editar”,
80.1. El subsistema le permite modificar los datos de identificación del
paciente Apellido1, Apellido2, Nombre1, Nombre2, Fecha de nacimiento,
Sexo y Nacionalidad.
40
MANUAL TÉCNICO - SAMWEB ENERO/2016
80.2. El usuario debe presionar el botón “Guardar cambios” para guardar
los cambios realizados ejecutando el método Paciente.guardarPaciente
(Apellido1 String, Apellido2 String, Nombre1 String, Nombre2 String, Fecha
de nacimiento Date, Sexo String, Nacionalidad String), si es exitosa,
devuelve el id del paciente. Si no pudo grabar, devuelve un indicador
numérico que exprese que falló la grabación.
80.3. El subsistema emite el mensaje “Cambio exitoso”.
90. Si el usuario pulsa el botón “Cancelar” o “Cerrar”.
90.1. El caso de uso termina.
· Escenario excepción: Para la acción 10
10. Emitir mensaje de la precondición que no se cumple.
20. El caso de uso termina.
Para la acción 50.1
10. Regresar al escenario básico, acción 15.
Para la acción 50.2
10. Emitir el mensaje de error que exprese la falla específica al intentar guardar.
20. Regresar al escenario básico, acción 15.
Para la acción 65.1,
10. Emitir mensaje “Ingrese criterio de búsqueda”.
Para la acción 65.2
10. Emitir mensaje “No hay coincidencias”.
20. Regresa al Escenario básico, acción 30.
41
MANUAL TÉCNICO - SAMWEB ENERO/2016
Para la acción 80.2
10. Emitir el mensaje de error que exprese la falla específica al intentar guardar.
20. Regresar al escenario básico, acción 65.3.
4.1.2.1.6 C.U.: VALIDAR APERTURA DE HCL Descripción: Permite validar que los datos de la apertura de la historia clínica se
hayan ingresado correctamente para ser guardados.
Requisitos incluidos:
· Validar apertura de HCL
Restricciones
· Pre-condición o El usuario debe tener permisos sobre la opción. o Los datos de identificación del paciente no deben estar registrados en la
base de datos SAMWeb. · Post-condición
o Ninguna
Escenarios
· Escenario básico:
10. Valida que los campos ingresados correspondan a las longitudes y tipos de
datos establecidos.
20. Valida que se haya seleccionado Tipo de paciente.
30. Valida que se encuentren los campos obligatorios.
40. Si no hay mensajes de error acumulados retorna un indicador de éxito de la
validación.
50. El caso de uso termina.
42
MANUAL TÉCNICO - SAMWEB ENERO/2016
· Escenario excepción: Para la acción 10
10. Acumula mensaje de error que exprese la falla específica de tipo de dato o
longitud para cada dato capturado.
20. Retorna al escenario básico acción 20.
Para la acción 20
10. Acumula mensaje de error que exprese la falla “Seleccione Tipo de paciente”
20. Retornar acción básico 30.
Para la acción 30
10. Acumula mensaje de error que exprese la falla específica “Completar datos
obligatorios” indicando cada uno que le corresponda. Es específico para cada
campo.
20. Retornar acción básico 35.
Para la acción 40
10. Despliega el mensaje de error acumulado
20. Retorna un indicador de validación fallida.
30. El caso de uso termina
43
MANUAL TÉCNICO - SAMWEB ENERO/2016
4.1.2.1.7 C.U.: BUSCAR DATOS DE IDENTIFICACIÓN DE PACIENTES EN SISTEMAS RELACIONADOS
Descripción: Este caso de uso permite consultar en fuentes externas fidedignas
los datos de identificación de todos los pacientes. La comunicación hacia los
sistemas relacionados se realiza por medio de Web Services.
Para los Tipos de paciente: Estudiante, Administrativo, Docente y Otro los datos
de identificación se leerán del Registro Civil del Ecuador.
Requisitos incluidos:
· Consultar datos de identificación de pacientes
Restricciones
· Pre-condición
o El usuario debe tener permisos sobre la opción.
o La comunicación hacia los Web Services debe estar disponible siempre
que lo requiera el usuario.
· Post-condición
o Ninguna
Escenarios
· Escenario básico:
10. El subsistema le permite al usuario escoger el Tipo de paciente (Estudiante,
Docente, Administrativo, Otro) y a la vez ingresar los Apellidos y Nombres (texto
de 120 caracteres) o el Número de cédula (texto de 10 caracteres, sin guion
medio) para proceder con la consulta.
20. Si el usuario presiona el botón “Consultar datos de identificación”
20.2. Valida que el criterio de búsqueda sea la cedula de identidad (texto
de 10 caracteres, sin guion medio).
44
MANUAL TÉCNICO - SAMWEB ENERO/2016
20.4. El Web Services del Registro Civil devuelve los siguientes datos
siempre y cuando se encuentren disponibles:
§ Tipo de paciente (Estudiante, Docente, Administrativo, Otro), § Número de cédula (texto de 10 caracteres), § Nombres y apellidos(texto de 120 caracteres), § Fecha de nacimiento (tipo de dato Date), § Sexo (texto de 10 caracteres), § Nacionalidad (texto de 30 caracteres).
20.5. Se despliega en una grilla la lista de resultados a modo de lectura.
Los datos de la grilla son los mismos que devuelve el Web Service.
30. El subsistema le permite al usuario seleccionar un paciente.
30.1. Al seleccionar un paciente, el subsistema devuelve los datos de
identificación al caso de uso que lo llamó.
40. Si el usuario presiona el botón “Cancelar”
40.1. El caso de uso termina.
· Escenario excepción:
Para la acción 20.1,
10. Emitir mensaje “Seleccione Tipo de paciente”.
20. Regresa al Escenario básico, acción 10.
Para la acción 20.2,
10. Emitir mensaje “Ingrese número de cedula correcta”.
20. Regresa al Escenario básico, acción 10.
Para la acción 20.4
10. Emitir mensaje “No hay coincidencias”.
20. Regresa al Escenario básico, acción 10.
Para la acción 20.4.
45
MANUAL TÉCNICO - SAMWEB ENERO/2016
10. Emitir mensaje “La comunicación con el Registro Civil se ha suspendido
intente más tarde”.
20. Regresa al Escenario básico, acción 10.
46
MANUAL TÉCNICO - SAMWEB ENERO/2016
4.1.2.1.8 C.U.: REGISTRAR PRESENTACIÓN DE DOCUMENTOS DE SALUD DE ESTUDIANTES NUEVOS
Descripción: Este caso de uso es sencillo pero su uso es muy particular ya que
de por medio se realizan diversas operaciones, este caso de uso solo aplica para
pacientes de tipo Estudiante:
1. Permite consultar datos de identificación y datos de carrera de estudiantes
devolviendo una lista con varios o un solo elemento (estudiantes), por
medio de un criterio de búsqueda:
a. Fecha de presentación (fecha facilitada por la DGIP por semestre)
b. Número de consultorio (opcional)
c. Número de cédula (opcional)
2. Permite visualizar la información del estudiante, información que abarca:
a. Datos de identificación
b. Datos de la carrera
c. Estado del estudiante con respecto al área médica
d. Estado del estudiante con respecto a la EPN
3. Permite registrar la fecha de presentación de documentos de salud
únicamente para estudiantes nuevos. Si es un estudiante nuevo que viene
por primera vez, aparte de registrar la presentación de documentos de
salud también se le apertura una historia clínica de forma automática.
Para la consulta de datos lo hace a través del sistema relacionado SAEW. Si se
ingresa un Número de cédula solo se muestra información para dicho estudiante.
Este caso de uso se centra en el registro de la fecha de presentación de
documentos de salud para estudiantes nuevos, se puede usar opcionalmente
para consultar los datos de un estudiante y verificar su estado respecto al área
médica o a la institución, es decir únicamente visualizar:
a. La fecha de la cita médica asignada por la DGIP.
b. Si el estudiante nuevo ha presentado o no documentos de salud
c. Si el estudiante está o no matriculado en el periodo actual
Requisitos incluidos:
47
MANUAL TÉCNICO - SAMWEB ENERO/2016
· Registrar presentación de documentos de salud de estudiantes nuevos
· Registrar apertura de HCL
Restricciones
· Pre-condición o El usuario debe tener permisos sobre la opción. o Los datos de identificación del paciente no deben estar registrados en la
base de datos SAMWeb. · Post-condición
o Registro de fecha de presentación documentos exitosa o Paciente registrado.
Escenarios
· Escenario básico:
10. Validar las precondiciones.
15. Si el usuario presiona el botón “Consultar”
15.1. Valida que no se haya ingresado cédula y continúa con el punto 18.
16. Si el criterio de búsqueda es un Número de cédula se realiza lo siguiente:
16.2 Se valida el estado del estudiante con respecto a la institución para lo
cual el subsistema ejecuta el método
DatosMedicoWSSoap.consultarEstudiante (criterio, ""), se realiza la
consulta del estado por medio del Número de cédula, el resultado se
guarda en una variable,
16.4. A continuación el subsistema realiza la consulta ejecutando el método
DatosMedicoWSSoap.datosMedico(criterio, "", "","") enviando en criterio el
Número de cédula. Se recibe una lista de estudiantes que coincidan con el
criterio de búsqueda. Dicha lista para este caso contiene un solo
estudiante. Si no devuelve resultados significa que esa cédula no está
registrada en el SAEW.
18. Si el criterio de búsqueda no es una cédula, es decir se ha ingresado una
fecha válida y/o se ha seleccionado un número de consultorio:
48
MANUAL TÉCNICO - SAMWEB ENERO/2016
18.2. Se ejecuta el método DatosMedicoWSSoap.datosMedico("", "",
fechaConsulta [en formato "dd/MM/yyyy"], numeroConsultorio). Se recibe
una lista de estudiantes que coincidan con el criterio de búsqueda. Dicha
lista para este caso contiene varios estudiantes. Si no devuelve resultados
significa que para dicha fecha no hay estudiantes con cita agendada en el
SAEW.
20. Si existieron uno o varios estudiantes en la lista recibida se despliega en una
grilla los pacientes que coinciden con el criterio de búsqueda.
Los datos de la grilla son: Número de cédula (texto de 10 caracteres, sin
guion medio en el formato recibido), Nombres y apellidos (texto en el
formato recibido), Fecha (texto en el formato recibido), Consultorio (texto en
el formato recibido), Hora (texto en el formato recibido) y Fecha de
Presentación de Documentos (texto en el formato recibido) para los dos
casos haya o no presentado los documentos.
Las acciones permitidas para cada fila de la grilla son: Ver detalles.
30. Si el usuario presiona “Ver detalles” se ejecuta únicamente el punto 16.2 y
continúa con:
30.2. Se despliegan los datos del paciente seleccionado, en 4 secciones:
- Sección Datos del estudiante, se muestran en el mismo formato que se
recibe la data la siguiente información:
§ Cédula
§ Código
§ Nombres y apellidos
§ Fecha nacimiento
§ Género
§ Teléfono
§ Celular
§ Estado civil
§ País
49
MANUAL TÉCNICO - SAMWEB ENERO/2016
§ Provincia
§ Cantón
§ Dirección
- Sección Datos de la carrera, se muestran en el mismo formato que se
recibe la data la siguiente información:
§ Código de carrera
§ Carrera
§ Estado
§ Email institucional
- Sección Datos médicos, se muestran en el mismo formato que se recibe
la data la siguiente información:
§ Fecha turno
§ Hora turno
§ Consultorio
- Sección Observación, se muestra el estado del estudiante con respecto a
la institución. Se carga la información guardada en la variable de estado del
estudiante.
30.4. Si el paciente ya ha presentado los documentos médicos, en la grilla
principal columna “Fecha de Presentación de Documentos” se mostrará la
fecha caso contrario el campo estará vacío. En dicho caso, cuando el
campo se encuentra vacío al visualizar los detalles del paciente se cargará
el botón “Validar”, de lo contrario esa pantalla solo es informativa.
40. Si el usuario presiona Validar:
40.2. El subsistema ejecuta el método
DatosMedicoWSSoap.chequeoDatosMedico(Cedula) para registrar la fecha
de presentación de documentos de salud para estudiantes nuevos.
40.4. El subsistema ejecuta el método Paciente.guardarPaciente (Número
de HCL String, Número de cédula String, Apellido1 String, Apellido2 String,
Nombre1 String, Nombre2 String, Fecha de nacimiento Date, Sexo String,
50
MANUAL TÉCNICO - SAMWEB ENERO/2016
Nacionalidad String), si es exitosa, devuelve el id generado para el
paciente. Si no pudo grabar, devuelve un indicador que exprese que falló la
grabación.
40.6. El subsistema emite el mensaje “Validación de documentos exitosa”.
40.8. El subsistema emite el mensaje “Apertura de historia clínica exitosa.”.
90. Si el usuario pulsa el botón “Cancelar” o “Cerrar”.
90.1. El caso de uso termina.
· Escenario excepción: Para la acción 10
10. Emitir mensaje de la precondición que no se cumple.
20. El caso de uso termina.
Para la acción 20
5. Emite el mensaje: “No existen coincidencias”
10. Regresar al escenario básico, acción 10.
Para la acción 40.6
10. Emitir el mensaje de error que exprese la falla específica al intentar guardar.
20. Regresar al escenario básico, acción 10.
Para la acción 40.8,
10. Emitir el mensaje de error que exprese la falla específica al intentar guardar.
20. Regresar al escenario básico, acción 10.
4.1.2.1.9 C.U.: VALIDAR PRESENTACIÓN DE DOCUMENTOS DE SALUD DE ESTUDIANTES NUEVOS*
51
MANUAL TÉCNICO - SAMWEB ENERO/2016
Descripción: Permite validar que los datos de la apertura de la historia clínica se
hayan ingresado correctamente para ser guardados.
Requisitos incluidos:
· Validar apertura de HCL
Restricciones
· Pre-condición o El usuario debe tener permisos sobre la opción. o Los datos de identificación del paciente no deben estar registrados en la
base de datos SAMWeb. · Post-condición
o Ninguna
Escenarios
· Escenario básico:
10. Valida que los campos ingresados correspondan a las longitudes y tipos de
datos establecidos.
20. Valida que se haya seleccionado Tipo de paciente.
30. Valida que se encuentren los campos obligatorios.
40. Si no hay mensajes de error acumulados retorna un indicador de éxito de la
validación.
50. El caso de uso termina.
· Escenario excepción: Para la acción 10
10. Acumula mensaje de error que exprese la falla específica de tipo de dato o
longitud para cada dato capturado.
20. Retorna al escenario básico acción 20.
Para la acción 20
52
MANUAL TÉCNICO - SAMWEB ENERO/2016
10. Acumula mensaje de error que exprese la falla “Seleccione Tipo de paciente”
20. Retornar acción básico 30.
Para la acción 30
10. Acumula mensaje de error que exprese la falla específica “Completar datos
obligatorios” indicando cada uno que le corresponda. Es específico para cada
campo.
20. Retornar acción básico 35.
Para la acción 40
10. Despliega el mensaje de error acumulado
20. Retorna un indicador de validación fallida.
30. El caso de uso termina
53
MANUAL TÉCNICO - SAMWEB ENERO/2016
4.1.2.2 Casos de uso para el proceso de Manejo de inventario
4.1.2.2.1 C.U.: REGISTRAR MOVIMIENTO DE INVENTARIO Descripción: Permite registrar un nuevo movimiento de inventario de Tipo:
Ingreso por compra, Ingreso por donación, Ingreso por cambio, Ingreso por ajuste
excedente, Egreso por ajuste faltante y Egreso por baja.
Requisitos incluidos:
· Registrar ajuste de inventario de insumos médicos
· Registrar baja de insumos médicos
· Registrar ingreso de insumos médicos
· Registrar atención médica
· Generar reporte de ajuste de inventario
· Generar reporte de insumos médicos dados de baja
· Generar reporte de insumos médicos ingresados
Restricciones
· Pre-condición o El usuario debe tener permisos sobre la opción.
· Post-condición o El Tipo de estado del movimiento de inventario se guarda como
Ejecutado.
Escenarios
· Escenario básico:
10. Validar las precondiciones.
13. Por defecto muestra el Historial de movimientos de Tipo: Ingreso por compra,
Ingreso por donación, Ingreso por cambio, Ingreso por ajuste excedente, Egreso
por ajuste faltante y Egreso por baja, para su efecto ejecuta el método
Movimiento_inventario.ObtenerListaMovimientos(fechaInicial: Date, fechaFinal:
Date).
54
MANUAL TÉCNICO - SAMWEB ENERO/2016
13.1. Si encontró coincidencias, despliega en una grilla los movimientos
que coinciden con el criterio de búsqueda en orden cronológico.
Los datos de la grilla son: Fecha (tipo date), Tipo de movimiento (texto de
100 caracteres), Responsable (texto de 120 caracteres), Medicamentos
(texto de 100 caracteres) y como dato oculto: id_movimiento (tipo integer).
Las acciones permitidas para cada fila de la grilla son “Visualizar
movimiento de inventario”.
13.2. Permite que el usuario escoja un movimiento de la grilla.
16. Si el usuario presiona “Visualizar movimiento de inventario” en uno de los
movimientos del historial
16.1. Se muestra el detalle del movimiento que incluye la cabecera y el
detalle del movimiento.
La cabecera incluye: Fecha (tipo date), Código de documento (texto de 100
caracteres), Responsable (texto de 120 caracteres), Motivo (texto de 400
caracteres), Tipo de movimiento (texto de 100 caracteres).
16.2. Para desplegar el detalle del movimiento se ejecuta el método
Detalle_movimiento.obtenerListaDetallesMovimientos (String criterio)
16.3. Presenta en una grilla el Detalle de la transacción.
El detalle de la transacción consta de: Nombre genérico (texto de 60
caracteres), Presentación (texto de 60 caracteres) y Cantidad transaccional
(tipo integer). Como columna oculta: id_insumo_medico (tipo integer).
18. Si el usuario presiona “Imprimir detalle” en uno de los movimientos del historial
18.1. Se ejecuta el reporte Generar detalle de movimiento enviando el
id_movimiento.
19. Si el usuario presiona “Imprimir historial”
55
MANUAL TÉCNICO - SAMWEB ENERO/2016
19.1. Se ejecuta el reporte Generar reporte de movimientos de
inventario.
20. Si el usuario pulsa el botón “Nuevo movimiento”.
20.1 El subsistema le permite al usuario completar la cabecera del
movimiento. Los datos que constan en la cabecera son: Código de
documento (texto de 100 caracteres), Motivo (texto de 100 caracteres), y
debe seleccionar el Tipo de transacción (Ingreso por compra, Ingreso por
donación, Ingreso por cambio, Ingreso por ajuste excedente, Egreso por
ajuste faltante y Egreso por baja). Carga automáticamente el Responsable
(texto de 120 caracteres) y la fecha y hora del movimiento.
30. Si el usuario presiona el botón “Agregar insumos médicos”
30.1. Permite Agregar los insumos médicos al detalle de la transacción.
30.2. El subsistema le permite al usuario buscar Insumos médicos por
acercamiento ingresando mínimo 3 caracteres del Nombre medicamento
(texto de 60 caracteres), ejecutando el método
Insumo_medico.obtenerListaInsumos(criterio String).
30.3. Si hay coincidencias, muestra a manera de combo una lista de
resultados.
30.4. Al seleccionar un insumo médico se carga a modo de lectura la
Cantidad actual (tipo integer), Cantidad comprometida (tipo integer) y
como dato oculto se carga el id_insumoMedico (tipo integer).
30.5. El subsistema le permite al usuario ingresar la Cantidad transaccional
(tipo integer).
35. Si en “Agregar insumos médicos” el usuario pulsa el botón “Consultar insumo
médico”
35.1. Ejecutan el método Insumo_medico.obtenerListaInsumos(criterio
String) y devuelve la lista de insumos médicos disponibles
56
MANUAL TÉCNICO - SAMWEB ENERO/2016
35.2. Despliega en una grilla los insumos médicos encontrados para que el
usuario escoja el deseado. Los datos de la grilla son: Nombre (texto de 60
caracteres), Presentación (texto de 60 caracteres), Cantidad actual (tipo
integer), Cantidad comprometida (tipo integer), y el dato id_insumoMedico
(tipo integer) con la característica de columna escondida.
35.3. Regresar a la acción 30.4 del escenario básico.
40. Si en “Agregar insumo médico” el usuario pulsa el botón “Añadir al detalle”
40.1. Valida que el Resultado de la siguiente operación sea mayor o igual
que 0 (cero):
Resultado = Cantidad Actual – Cantidad Comprometida + Cantidad
transaccional
Resultado >= 0
40.2 El insumo médico se agrega dentro de la grilla Detalle de la
transacción.
Los datos de la grilla son: Nombre genérico, Cantidad actual, Cantidad
transaccional. La acción permitida para cada insumo médico añadido es:
Eliminar.
50. Si el usuario pulsa el botón “Guardar movimiento de inventario”
50.1. Ejecuta el caso de uso incluido: Validar movimiento de inventario.
50.2. Ejecuta el método Movimiento_inventario.
guardarMovimientoInventario (movimientoInventario:
Movimiento_inventario) dicho método se encarga de guardar el movimiento
como sus detalles en Detalle_movimiento.
50.4. Si el registro atómico del movimiento es exitoso devuelve el id
generado. Si no pudo grabar, devuelve un indicador que exprese que falló
la grabación.
57
MANUAL TÉCNICO - SAMWEB ENERO/2016
50.5. Emitir mensaje “Registro correcto”.
60. Si el usuario pulsa el botón “Cancelar” o “Cerrar”.
60.1. Continuar en la acción 70 del escenario básico.
70. El caso de uso termina.
· Escenario excepción: Para la acción 10
10. Emitir mensaje de la precondición que no se cumple.
20. El caso de uso termina.
Para la acción 30.3
10. Añadir como ITEMTIP “No hay coincidencias”.
20. Regresar al escenario básico, acción 20.
Para la acción 35.1
10. Emitir mensaje “No hay insumos médicos disponibles”.
20. Regresar al escenario básico, acción 20.
Para la acción 40.1
10. Emitir mensaje “La Cantidad transaccional supera a las unidades disponibles”.
20. Regresa al Escenario básico, acción 30.
Para la acción 50.1 10. Regresar al escenario básico, acción 30.
Para la acción 50.2
10. Emitir el mensaje de error que exprese la falla específica al intentar guardar
Movimiento de inventario.
20. Regresar al escenario básico, acción 30.
Para la acción 50.3
10. Emitir el mensaje de error que exprese la falla específica al intentar guardar el
Detalle de movimiento de inventario.
58
MANUAL TÉCNICO - SAMWEB ENERO/2016
20. Regresar al escenario básico, acción 30.
4.1.2.2.2 C.U.: VALIDAR MOVIMIENTO DE INVENTARIO Descripción: Permite validar que los datos del movimiento de inventario se hayan
ingresado correctamente para ser guardados.
Requisitos incluidos:
· Validar ajuste de inventario de insumos médicos.
· Validar baja de insumos médicos.
· Validar ingreso de insumos médicos.
· Validar movimiento de inventario
Restricciones
· Pre-condición o El usuario debe tener permisos sobre la opción.
· Post-condición o Ninguna
Escenarios
· Escenario básico:
10. Valida que los campos ingresados correspondan a las longitudes y tipos de
datos establecidos.
20. Validar que se haya seleccionado Tipo de transacción.
25. Validar que haya al menos una línea de detalle.
30. Valida que se encuentren los campos obligatorios.
40. Si no hay mensajes de error acumulados retorna un indicador de éxito de la
validación.
50. El caso de uso termina.
· Escenario excepción: Para la acción 10
59
MANUAL TÉCNICO - SAMWEB ENERO/2016
10. Acumula mensaje de error que exprese la falla específica de tipo de dato o
longitud para cada dato capturado.
20. Retorna al escenario básico acción 20.
Para la acción 20
10. Acumula mensaje de error que exprese la falla “Seleccione Tipo de
transacción”
20. Retornar acción básico 25.
Para la acción 25
10. Acumula mensaje de error que exprese la falla “Añadir registros al detalle”
20. Retornar acción básico 30.
Para la acción 30
10. Acumula mensaje de error que exprese la falla específica “Completar datos
obligatorios” indicando cada uno que le corresponda.
20. Retornar acción básico 40.
Para la acción 40
10. Despliega el mensaje de error acumulado
20. Retorna un indicador de validación fallida.
30. El caso de uso termina
60
MANUAL TÉCNICO - SAMWEB ENERO/2016
4.1.2.2.3 C.U.: REGISTRAR DESPACHO DE ORDEN DE INSUMOS MÉDICOS Descripción: Permite listar los Tipos de movimiento Egreso por despacho
(suministro y entrega) que tengan como estado Comprometido, estos se pondrán
despachar físicamente y su estado se guarda como Ejecutado.
Requisitos incluidos:
· Consultar órdenes de medicación emitidas
· Modificar a liberado las órdenes de medicación no despachadas
· Registrar despacho de la orden de medicación
· Validar a liberado el estado de las órdenes de medicación no despachadas en un día
· Validar despacho de la orden de medicación
Restricciones
· Pre-condición o El usuario debe tener permisos sobre la opción. o Deben existir al menos un Tipo de movimiento Egreso por despacho
(suministro) o Egreso por despacho (entrega). · Post-condición
o El Tipo de estado del movimiento de inventario se guarda como Ejecutado.
Escenarios
· Escenario básico:
10. Validar las precondiciones.
20. Muestra los movimientos de inventario del día de Tipo: Egreso por despacho
(suministro) o Egreso por despacho (entrega), con Estado de movimiento
Comprometido, para su efecto ejecuta el método
Movimiento_inventario.ObtenerListaDespachosPendientes(tipoEstadoMovimiento:
txt).
20.1. Si los movimientos de inventario del día de Tipo: Egreso por
despacho (suministro) o Egreso por despacho (entrega), despliega en una
61
MANUAL TÉCNICO - SAMWEB ENERO/2016
grilla los movimientos en orden cronológico correspondientes al día
presente.
Los datos de la grilla son: Tipo de movimiento como “Orden de” (texto de
100 caracteres), Paciente (Texto de 150 caracteres), CI (Texto de 10
caracteres), Tipo de paciente (Texto de 100 caracteres), Especialidad
(Texto de 100 caracteres), Médico (texto de 120 caracteres) y como dato
oculto: id_movimiento (tipo integer), Fecha del movimiento (tipo date9,
Motivo del movimiento (texto de 400 caracteres), Código de documento
(texto de 100 caracteres).
Las acciones permitidas para cada fila de la grilla son Visualizar.
20.2. Permite que el usuario escoja un movimiento de la grilla.
30. Si el usuario presiona “Visualizar” en uno de los movimientos del historial
30.1. Se muestra el detalle del movimiento que incluye la cabecera y el
detalle del movimiento.
La cabecera incluye los datos personales del paciente: Paciente (Texto de
150 caracteres), Número de cédula (Texto de 10 caracteres), Tipo de
paciente (Texto de 100 caracteres), HCL, Sexo(Texto de 10 caracteres),
Nacionalidad (Texto de 30 caracteres), Especialidad (Texto de 100
caracteres), Médico (texto de 120 caracteres)Fecha del movimiento (tipo
date), Hora del movimiento (tipo time), Motivo del movimiento (texto de 400
caracteres).
30.2. Para desplegar el detalle del movimiento se ejecuta el método
Detalle_movimiento.obtenerListaDetallesMovimientos(id_movimiento
Integer)
30.3. Presenta en una grilla el Detalle.
El detalle consta de: Nombre genérico del insumo médico como
“Medicación” (texto de 60 caracteres), Presentación (texto de 60
62
MANUAL TÉCNICO - SAMWEB ENERO/2016
caracteres) y Cantidad recetada (tipo integer). Como columna oculta:
id_insumo_medico (tipo integer).
35. Si el usuario presiona “Despachar” en uno de los movimientos del historial
35.1. Por cada insumo médico del detalle se resta la cantidad
comprometida de la cantidad actual, ejecutando el método
Insumo_medico.guardarCantidadActualInsumo(Id_insumoMedico integer,
Cantidad integer)
35.2. Si se completa la anterior tarea a continuación se ejecuta el método
Movimiento_inventario.guardarMovimientoDespacho(id_movimiento
integer, TipoEstadoMovimiento integer) para cambiar el estado del
movimiento de Comprometido a Ejecutado.
35.3. Adicionalmente se ejecuta el método
Movimiento_inventario.guardarMovimientosLiberados(FechaActual Date,
TipoEstadoMovimiento integer) que permite liberar los movimientos de tipo
despacho para pacientes que no han retirado la medicación al final del día.
El objetivo de este método es cambiar el estado del movimiento de
Comprometido a Liberado para movimientos de tipo Egreso por despacho
(suministro) y Egreso por despacho (ejecutado) siempre y cuando haya
pasado 24 horas a partir de la fecha y hora del movimiento.
35.4. El conjunto de transacciones se realiza de forma atómica y si es
exitoso devuelve un indicador de éxito. Si no pudo guardar, devuelve un
indicador numérico que exprese la falla.
35.5. Emitir mensaje “Despacho exitoso”.
40. Si el usuario presiona “Imprimir detalle” en uno de los movimientos del historial
40.1. Se ejecuta el reporte Generar detalle de movimiento enviando el
id_movimiento.
50. Si el usuario pulsa el botón “Cancelar” o “Cerrar”.
50.1. Continuar en la acción 60 del escenario básico.
63
MANUAL TÉCNICO - SAMWEB ENERO/2016
60. El caso de uso termina.
· Escenario excepción: Para la acción 10
10. Emitir mensaje de la precondición que no se cumple.
20. El caso de uso termina.
Para la acción 35.1
10. Emitir el mensaje de error que exprese la falla específica al intentar guardar
Insumo médico.
20. Regresar al escenario básico, acción 20.
Para la acción 35.2
10. Emitir el mensaje de error que exprese la falla específica al intentar guardar
Movimiento de inventario.
20. Regresar al escenario básico, acción 20.
Para la acción 35.3
10. Emitir el mensaje de error que exprese la falla específica al intentar guardar
Movimientos de inventario liberados.
20. Regresar al escenario básico, acción 20.
64
MANUAL TÉCNICO - SAMWEB ENERO/2016
4.1.2.3 Casos de uso para el proceso de Políticas del servicio de atención médica y
manejo de inventario
4.1.2.3.1 C.U.: REGISTRAR INSUMO MÉDICO Descripción: Permite registrar nuevos insumos médicos a la base de datos
SAMWeb.
Requisitos incluidos:
· Registrar insumos médicos
Restricciones
· Pre-condición o El usuario debe tener permisos sobre la opción. o El nombre del insumo médico no debe estar registrado previamente en
la base de datos SAMWeb. · Post-condición
o Insumo médico registrado.
Escenarios
· Escenario básico:
10. Validar las precondiciones.
13. Por defecto lista los insumos médicos registrados, para su efecto ejecuta el
método Insumo_medico.ObtenerListaInsumos(String criterio).
13.1. Si encontró coincidencias, despliega en una grilla los insumos
médicos que coinciden con el criterio de búsqueda.
Los datos de la grilla son: Nombre del medicamento (texto de 60
caracteres), Presentación (texto de 60 caracteres), Tipo de insumo médico
[Ingresados por el usuario] (texto de 100 caracteres), Cantidad mínima (tipo
integer) y como dato oculto: id_insumo (tipo integer).
Las acciones permitidas para cada fila de la grilla son Editar y Eliminar.
13.2. Permite que el usuario escoja un insumo médico de la grilla.
65
MANUAL TÉCNICO - SAMWEB ENERO/2016
16. Si el usuario pulsa “Editar” en uno de los insumos médicos listados.
16.1. Se muestra el detalle del insumo médico que incluye:
Tipo de insumo médico [Ingresados por el usuario] (texto de 100
caracteres), Nombre del insumo médico (texto de 60 caracteres),
Presentación (texto de 60 caracteres), Cantidad mínima (tipo integer).
16.2. Para desplegar el detalle del insumo médico se ejecuta el método
Insumo_medico.ObtenerInsumo(String criterio).
16.3. Presenta en una grilla el Detalle.
El detalle consta de: Nombre del insumo médico (texto de 60 caracteres),
Presentación del insumo médico (texto de 60 caracteres) y Cantidad (tipo
integer). Como columna oculta: id_insumo_medico (tipo integer).
18. Si el usuario pulsa “Eliminar” en uno de los insumos médicos. Se presenta el
mensaje “Seguro de que desea eliminar el insumo médico”.
18.1. Si el usuario pulsa “SI”, se ejecuta el método
Insumo_medico.eliminarInsumomedico(Insumomedico obj, String
operacion);
20. Si el usuario pulsa “Nuevo insumo”
20.1. El sistema le permite seleccionar e ingresar los datos: Tipo de insumo
médico [Ingresados por el usuario] (texto de 100 caracteres), Nombre del
medicamento (texto de 60 caracteres), Presentación (texto de 60
caracteres), Cantidad mínima (tipo integer).
30. Si el usuario presiona el botón “Grabar”
30.1. Ejecuta el caso de uso incluido: Validar insumo médico.
30.2. Ejecuta el método Insumo_medico.guardarInsumoMedico
(Insumo_medico), si es exitoso, devuelve el id generado. Si no pudo
grabar, devuelve un indicador que exprese que falló la grabación.
66
MANUAL TÉCNICO - SAMWEB ENERO/2016
30.3. El subsistema emite el mensaje “Registro correcto”.
40. Si el usuario pulsa el botón “Cancelar” o “Cerrar”.
40.1. Continuar en la acción 98 del escenario básico.
50. Por defecto lista los tipos de insumos médicos registrados, para su efecto
ejecuta el método Tipo_ Insumo_medico.ObtenerListaTipoInsumoMedico(Tipo_
Insumo_medico Array).
50.1. Si encontró coincidencias, despliega en una grilla los insumos
médicos que coinciden con el criterio de búsqueda.
Los datos de la grilla son: Nombre del tipo de insumo medico (texto de 100
caracteres), y como dato oculto: id_tipoInsMed (tipo integer).
Las acciones permitidas para cada fila de la grilla son Editar y Eliminar.
50.2. Permite que el usuario escoja un tipo de insumo médico de la grilla.
60. Si el usuario pulsa “Editar” en uno de los tipos de insumos médicos listados.
60.1. Se muestra el detalle del tipo insumo médico que incluye:
Nombre del tipo de insumo medico (texto de 100 caracteres)
60.2. Para desplegar el detalle del tipo de insumo médico se ejecuta el
método Tipo_insumo_medico.ObtenerTipoInsumoMedico(String criterio).
16.3. Presenta en una grilla el Detalle.
El detalle consta de: Nombre del tipo de insumo médico (texto de 60
caracteres). Como columna oculta: id_tipo_insumo_medico (tipo integer).
98. El caso de uso termina.
· Escenario excepción: Para la acción 10
10. Emitir mensaje de la precondición que no se cumple.
67
MANUAL TÉCNICO - SAMWEB ENERO/2016
20. El caso de uso termina.
Para la acción 30.1
10. Regresar al escenario básico, acción 20.
Para la acción 30.2
10. Emitir el mensaje de error que exprese la falla específica al intentar guardar.
20. Regresar al escenario básico, acción 20.
Para la acción 90.1
10. Regresar al escenario básico, acción 20.
Para la acción 90.2
10. Emitir el mensaje de error que exprese la falla específica al intentar guardar.
20. Regresar al escenario básico, acción 20.
4.1.2.3.2 C.U.: VALIDAR INSUMO MÉDICO Descripción: Permite validar que los datos del insumo médico se hayan
ingresado correctamente para ser guardados.
Requisitos incluidos:
· Validar insumo médico
Restricciones
· Pre-condición o El usuario debe tener permisos sobre la opción.
· Post-condición o Ninguna
Escenarios
· Escenario básico:
68
MANUAL TÉCNICO - SAMWEB ENERO/2016
10. Valida que los campos ingresados correspondan a las longitudes y tipos de
datos establecidos.
20. Validar que se haya seleccionado Tipo de insumo médico.
25. Validar que la Cantidad mínima sea mayor que cero.
27. Validar que se encuentre digitados los campos obligatorios.
30. Si no hay mensajes de error acumulados retorna un indicador de éxito de la
validación.
40. El caso de uso termina.
· Escenario excepción: Para la acción 10
10. Acumula mensaje de error que exprese la falla específica de tipo de dato o
longitud para cada dato capturado.
20. Retorna al escenario básico acción 20.
Para la acción 20
10. Acumula mensaje de error que exprese la falla “Seleccione Tipo de insumo
médico”
20. Retornar acción básico 25.
Para la acción 25
10. Acumula mensaje de error que exprese la falla “La cantidad mínima debe ser
mayor que 0”
20. Retornar acción básico 25.
Para la acción 27
10. Acumula mensaje de error que exprese la falla específica indicando cada uno
que le corresponda.
69
MANUAL TÉCNICO - SAMWEB ENERO/2016
20. Retornar acción básico 30.
Para la acción 30
10. Despliega el mensaje de error acumulado
20. Retorna un indicador de validación fallida.
30. El caso de uso termina
70
MANUAL TÉCNICO - SAMWEB ENERO/2016
4.1.2.3.3 C.U.: REGISTRAR TIPOS DE <CATÁLOGOS>(DIGITADOS O NO) Descripción: Este caso de uso permite definir los términos que se usarán en el
catálogo del subsistema SAMWeb, empezando por registrar.
· Los datos de información del personal médico y enfermería · Las especialidades que el área médica dispone · Los tipos de pacientes que serán atendidos · Los tipos de movimiento de inventario de medicamentos · Los tipos de estados para turnos de atención médica · Los tipos de atención médica · Los código de diagnósticos · Los tipo de medicamentos a entregar
Requisitos incluidos
· Validar tipo de catálogo.
Restricciones
· Pre-condición
- El usuario debe estar autorizado.
· Post-condición:
- No aplica
Escenarios
· Escenario básico
10. El subsistema valida que se cumplan las precondiciones.
20. Si el usuario ha seleccionado “Nuevo catálogo”.
20.1. El subsistema le permite al usuario ingresar el nombre del catálogo y
un código único para ese catálogo.
20.2. A continuación debe añadir los elementos del catálogo. Tantos
elementos como requiera.
30. Si el usuario pulsa “Grabar registro”.
30.1. El subsistema valida que los campos estén completos.
71
MANUAL TÉCNICO - SAMWEB ENERO/2016
30.2. El subsistema registra el nuevo catálogo y sus elementos.
30.3. El subsistema emite el mensaje "Catálogo Nuevo Registrado".
· Escenario alternativo
Para la acción 10,
10. Emitir mensaje de la precondición que no se cumple.
20. El caso de uso termina.
Para la acción 30.1,
10. Emitir mensaje “Completar campos obligatorios”.
Para la acción 30.3,
10. Emitir mensaje “Error en el registro”.
20. El caso de uso termina.
4.1.2.3.4 C.U.: REGISTRAR PERSONAL MÉDICO Descripción: Permite al usuario registrar los datos de identificación del personal
médico que no se encuentra en la base de datos SAMWeb.Los datos de
identificación se pueden consultar en sistemas relacionados.
Únicamente cuando los sistemas relacionados no se encuentran disponibles los
datos de identificación se ingresan manualmente en los campos obligatorios
respectivos.
Requisitos incluidos:
· Registrar personal médico
Restricciones
72
MANUAL TÉCNICO - SAMWEB ENERO/2016
· Pre-condición o El usuario debe tener permisos sobre la opción. o Los datos de identificación no deben estar registrados en la base de
datos SAMWeb. · Post-condición
o Personal registrado.
Escenarios
· Escenario básico:
10. Validar las precondiciones.
15. Si el usuario presiona “Nuevo”
15.2. Para completar el registro de los datos de identificación, el
subsistema le permite al usuario consultar dichos datos en fuentes externas
confiables o ingresarlos manualmente.
a. Para consultar los datos de identificación en una fuente externa el caso de uso continúa en la acción 20.
b. Para ingresar los datos de identificación manualmente el caso de uso continúa en la acción 30.
20. Si, en Nuevo, el usuario pulsa “Buscar datos de identificación”
20.1. Ejecuta el caso de uso incluido: Buscar datos de identificación en
sistemas relacionados.
20.2. Si los datos de identificación son válidos, carga la información a modo
de lectura en el formulario de Nuevo.
20.3. Continuar en la acción 40.
30. En caso de que cualquiera de los subsistemas alternos no se encuentren
disponibles, no arrojen resultados o no se realice consulta alguna
30.1 El usuario debe digitar la información del personal.
40. Los datos de identificación del personal que se deben cargar, ingresar o
seleccionar son:
§ Tipo de paciente (Estudiante, Docente, Administrativo, Otro),
73
MANUAL TÉCNICO - SAMWEB ENERO/2016
§ Número de cédula (texto de 10 caracteres), § Apellido1 (texto de 30 caracteres), § Apellido2 (texto de 30 caracteres), § Nombre1 (texto de 30 caracteres), § Nombre2 (texto de 30 caracteres), § Fecha de nacimiento (tipo de dato Date), § Sexo (texto de 10 caracteres), § Nacionalidad (texto de 30 caracteres). § Código del MSP (texto de 30 caracteres) § Dirección y teléfono si aplica (texto de 30 caracteres)
50. Si el usuario presiona el botón “Grabar”.
50.1. Ejecuta el caso de uso incluido: Validar apertura de HCl.
50.2. Ejecuta el método personal.guardarPersonal (Número de cédula
String, Apellido1 String, Apellido2 String, Nombre1 String, Nombre2 String,
Fecha de nacimiento Date, Sexo String, Nacionalidad String, CódigoMSP
String), si es exitosa, devuelve el id generado para el paciente. Si no pudo
grabar, devuelve un indicador que exprese que falló la grabación.
50.3. El subsistema emite el mensaje “Registro correcto”.
60. Por defecto el subsistema muestra la sección “Buscar personal registrados”
con una grilla de resultados vacía, el subsistema le permite al usuario ingresar el
Número de cédula (texto de 10 caracteres, sin guion medio) o los Apellidos y
nombres (texto de 120 caracteres) para consultar los pacientes ya registrados en
la base de datos SAMWEB.
65. Si el usuario presiona el botón “Consultar personal”
65.1. Valida que el criterio de búsqueda haya sido ingresado.
65.2. Busca los personal registrados con el criterio de búsqueda ingresado
ejecutando el método personal.obtenerListaPersonal(criterio String). Si no
devuelve resultados definitivos significa que el paciente aún no ha sido
registrado.
65.3. Despliega en una grilla del personal que coinciden con el criterio de
búsqueda.
74
MANUAL TÉCNICO - SAMWEB ENERO/2016
Los datos de la grilla son: Historia clínica (texto de 11 caracteres), Número
de cédula (texto de 10 caracteres, sin guion medio), Nombres y apellidos
(texto de 120 caracteres), Tipo de paciente (texto de 100 caracteres), y los
datos con la característica de columna escondida: id_tipo de paciente (tipo
integer), Tipo de paciente (Estudiante, Docente, Administrativo, Familiares,
Otro), Número de cédula (texto de 10 caracteres), Apellido1 (texto de 30
caracteres), Apellido2 (texto de 30 caracteres), Nombre1 (texto de 30
caracteres), Nombre2 (texto de 30 caracteres), Fecha de nacimiento (tipo
de dato Date), Sexo (texto de 10 caracteres), Nacionalidad (texto de 30
caracteres) y Origen dato (texto de 15 caracteres).
Las acciones permitidas para cada fila de la grilla son: Editar, la acción
Editar solo se activa cuando el atributo Origen dato es Digitado.
70. Si el usuario presiona “Ver detalles”, se despliegan los datos de identificación
del personal seleccionado.
80. Si el usuario presiona “Editar”,
80.1. El subsistema le permite modificar los datos de identificación del
paciente Apellido1, Apellido2, Nombre1, Nombre2, Fecha de nacimiento,
Sexo y Nacionalidad.
80.2. El usuario debe presionar el botón “Guardar cambios” para guardar
los cambios realizados ejecutando el método Paciente.guardarPaciente
(Apellido1 String, Apellido2 String, Nombre1 String, Nombre2 String, Fecha
de nacimiento Date, Sexo String, Nacionalidad String), si es exitosa,
devuelve el id del paciente. Si no pudo grabar, devuelve un indicador
numérico que exprese que falló la grabación.
80.3. El subsistema emite el mensaje “Cambio exitoso”.
90. Si el usuario pulsa el botón “Cancelar” o “Cerrar”.
90.1. El caso de uso termina.
75
MANUAL TÉCNICO - SAMWEB ENERO/2016
· Escenario excepción: Para la acción 10
10. Emitir mensaje de la precondición que no se cumple.
20. El caso de uso termina.
Para la acción 50.1
10. Regresar al escenario básico, acción 15.
Para la acción 50.2
10. Emitir el mensaje de error que exprese la falla específica al intentar guardar.
20. Regresar al escenario básico, acción 15.
Para la acción 65.1,
10. Emitir mensaje “Ingrese criterio de búsqueda”.
Para la acción 65.2
10. Emitir mensaje “No hay coincidencias”.
20. Regresa al Escenario básico, acción 30.
Para la acción 80.2
10. Emitir el mensaje de error que exprese la falla específica al intentar guardar.
20. Regresar al escenario básico, acción 65.3.
76
MANUAL TÉCNICO - SAMWEB ENERO/2016
4.1.2.3.5 C.U.: VALIDAR PERSONAL MÉDICO Descripción: Permite validar que los datos del registro se hayan ingresado
correctamente para ser guardados.
Requisitos incluidos:
· Validar personal médico.
Restricciones
· Pre-condición o El usuario debe tener permisos sobre la opción. o Los datos de identificación del personal no deben estar registrados en
la base de datos SAMWeb. · Post-condición
o Ninguna
Escenarios
· Escenario básico:
10. Valida que los campos ingresados correspondan a las longitudes y tipos de
datos establecidos.
20. Valida que se haya seleccionado Tipo de personal.
30. Valida que se encuentren los campos obligatorios.
40. Si no hay mensajes de error acumulados retorna un indicador de éxito de la
validación.
50. El caso de uso termina.
· Escenario excepción: Para la acción 10
77
MANUAL TÉCNICO - SAMWEB ENERO/2016
4.1.2.4 Casos de uso para el proceso de Análisis del servicio de atención médica y
manejo de inventario
4.1.2.4.1 C.U.: ADMINISTRAR CRITERIOS DE SELECCIÓN Descripción: Permite seleccionar los criterios de selección de los reportes a
generar entre ellos se encuentran reportes de:
· Pacientes atendidos
· Movimientos de insumos médicos
· Casos atendidos
· Listas de insumos médicos
Requisitos incluidos:
· Generar reportes de “Pacientes atendidos”
· Generar reportes de “Movimientos de insumos médicos”
· Generar reportes de “Casos atendidos”
· Generar reportes de “Listas de insumos médicos”
Restricciones
· Pre-condición o El usuario debe tener permisos sobre la opción.
· Post-condición o El usuario debe seleccionar el grupo de reporte a generar
Escenarios
· Escenario básico:
10. Se cargan dos combos, el primero con los Grupos de reportes existentes y el
segundo con los Reportes específicos a generarse. Como se muestra a
continuación:
· Pacientes atendidos
· Movimientos de insumos médicos
78
MANUAL TÉCNICO - SAMWEB ENERO/2016
· Casos atendidos
· Listas de insumos médicos
20. Si usuario selecciona el Grupo de reporte “Pacientes atendidos”
20.1. Se ejecuta el caso de uso dependiente: Generar reportes de
“Pacientes atendidos”
30. Si usuario selecciona el Grupo de reporte “Movimientos de insumos médicos”
30.1. Se ejecuta el caso de uso dependiente: Generar reportes de
“Movimientos de insumos médicos”
40. Si usuario selecciona el Grupo de reporte “Casos atendidos”
40.1. Se ejecuta el caso de uso dependiente: Generar reportes de “Casos
atendidos”
50. Si usuario selecciona el Grupo de reporte “Listas de insumos médicos”
50.1. Se ejecuta el caso de uso dependiente: Generar reportes de “Listas de
insumos médicos”
55. El usuario debe seleccionar el criterio fecha inicio y fecha fin para el rango del
reporte a generarse.
60. Si el usuario ya ha seleccionado el Grupo de reporte y el Reporte específico
se:
60.2. Se valida que existan datos para el reporte a generarse.
60.4. Se genera el reporte seleccionado.
· Escenario excepción: Para la acción 60.2
10. Si existe error alguno emitir el mensaje correspondiente al error.
20. Regresar al escenario básico, acción 10.
79
MANUAL TÉCNICO - SAMWEB ENERO/2016
4.1.2.4.2 C.U.: GENERAR REPORTES DE “PACIENTES ATENDIDOS” Descripción: Permite seleccionar el reporte específico a generar para ese grupo.
Requisitos incluidos:
· Número de pacientes atendidos según médico por tipo de paciente
· Número de pacientes atendidos según médico por meses
· Número de pacientes atendidos según médico por años
· Número de pacientes atendidos según médico por especialidad
· Número de pacientes atendidos según médico por tipo de atención médica
Restricciones
· Pre-condición o El usuario debe tener permisos sobre la opción. o El usuario debe seleccionar el grupo de reporte a generar
· Post-condición o El usuario debe presionar Generar el reporte.
Escenarios
· Escenario básico:
10. Se carga en el segundo combo los Reportes específicos a generarse. Como
se muestra a continuación:
· Número de pacientes atendidos según médico por tipo de paciente
· Número de pacientes atendidos según médico por meses
· Número de pacientes atendidos según médico por años
· Número de pacientes atendidos según médico por especialidad
· Número de pacientes atendidos según médico por tipo de atención médica.
20. Regresar al caso de uso base.
· Escenario excepción: N/A.
80
MANUAL TÉCNICO - SAMWEB ENERO/2016
4.1.2.4.3 C.U.: GENERAR REPORTES DE “MOVIMIENTOS DE INSUMOS
MÉDICOS” Descripción: Permite seleccionar el reporte específico a generar para ese grupo.
Requisitos incluidos:
· Número de transacciones de ingreso realizados según insumo médico por tipo
de ingreso
· Número de transacciones de egreso realizados según insumo médico por tipo
de egreso
· Número de insumos médicos ingresados según insumo médico por tipo de
ingreso
· Número de insumos médicos egresados según insumo médico por tipo de
egreso
Restricciones
· Pre-condición o El usuario debe tener permisos sobre la opción. o El usuario debe seleccionar el grupo de reporte a generar
· Post-condición o El usuario debe presionar Generar el reporte.
Escenarios
· Escenario básico:
10. Se carga en el segundo combo los Reportes específicos a generarse. Como
se muestra a continuación:
o Número de transacciones de ingreso realizados según insumo médico
por tipo de ingreso
o Número de transacciones de egreso realizados según insumo médico
por tipo de egreso
o Número de insumos médicos ingresados según insumo médico por tipo
de ingreso
o Número de insumos médicos egresados según insumo médico por tipo
de egreso
81
MANUAL TÉCNICO - SAMWEB ENERO/2016
20. Regresar al caso de uso base.
· Escenario excepción: N/A.
4.1.2.4.4 C.U.: GENERAR REPORTES DE “CASOS ATENDIDOS” Descripción: Permite seleccionar el reporte específico a generar para ese grupo.
Requisitos incluidos:
· Número de casos atendidos según diagnóstico por sexo
· Número de casos atendidos según diagnóstico por tipo de pacientes
· Número de casos atendidos según diagnóstico por edades
Restricciones
· Pre-condición o El usuario debe tener permisos sobre la opción. o El usuario debe seleccionar el grupo de reporte a generar
· Post-condición o El usuario debe presionar Generar el reporte.
Escenarios
· Escenario básico:
10. Se carga en el segundo combo los Reportes específicos a generarse. Como
se muestra a continuación:
· Número de casos atendidos según diagnóstico por sexo
· Número de casos atendidos según diagnóstico por tipo de pacientes
· Número de casos atendidos según diagnóstico por edades
20. Regresar al caso de uso base.
· Escenario excepción: N/A.
82
MANUAL TÉCNICO - SAMWEB ENERO/2016
4.1.2.4.5 C.U.: GENERAR REPORTES DE “LISTAS DE INSUMOS MÉDICOS” Descripción: Permite seleccionar el reporte específico a generar para ese grupo.
Requisitos incluidos:
· Listas de insumos médicos agrupado por tipo de presentación
· Listas de insumos médicos agrupado por tipo de insumo médico
· Listas de insumos médicos bajo saldo de re-orden agrupado por tipo de
presentación
· Listas de insumos médicos bajo saldo de re-orden agrupado por tipo de
insumo médico
Restricciones
· Pre-condición o El usuario debe tener permisos sobre la opción. o El usuario debe seleccionar el grupo de reporte a generar
· Post-condición o El usuario debe presionar Generar el reporte.
Escenarios
· Escenario básico:
10. Se carga en el segundo combo los Reportes específicos a generarse. Como
se muestra a continuación:
· Listas de insumos médicos agrupado por tipo de presentación
· Listas de insumos médicos agrupado por tipo de insumo médico
· Listas de insumos médicos bajo saldo de re-orden agrupado por tipo de
presentación
· Listas de insumos médicos bajo saldo de re-orden agrupado por tipo de
insumo médico.
20. Regresar al caso de uso base.
· Escenario excepción: N/A.
83
MANUAL TÉCNICO - SAMWEB ENERO/2016
4.2 DISEÑO ESTRUCTURAL
En el Diseño estructural se encuentra el Diagrama de clases de diseño con su
aplicación en el Diagrama de objetos y también se adjunta un Diccionario de
datos para entender cuáles son los datos que manejará el diagrama de clases.
4.2.1 DIAGRAMA DE CLASES DE DISEÑO
En este diagrama se verificó que las estructuras de datos reconocidas satisfagan
la funcionalidad de cada caso de uso transformando las clases del diagrama de
clases de análisis en clases del diagrama de clases de diseño con sus atributos y
métodos.
Específicamente en la clase paciente, los usuarios expertos han definido que, los
atributos nombres y apellidos deben estar por separado: nombre1, nombre2,
apellido1 y apellido2, para procurar la calidad en la captura de la información y
para facilitar la identificación del paciente.10
Para el atributo correspondiente al número de Número de cédula, el campo se lo
denominó como numeroCedula tal como lo indica el Número de cédula como
documento público.11
A continuación la Figura 4.5 muestra el diagrama de clases de diseño.
10
En la Ley Orgánica de Gestión de la Identidad y Datos Civiles, Título III Hechos y actos relativos al estado
civil de las personas, Capítulo III Inscripciones y registros extraordinarios, Artículo 36 – Nombres en la
inscripción de nacimiento, se establece que no podrá asignarse más de dos nombres simples o uno
compuesto. Y en la misma ley Artículo 37 – Apellidos en la inscripción de nacimiento, indica que los
apellidos serán el primero de cada uno de los padres, o si existe una sola filiación se asignarán los mismos
apellidos del progenitor que realiza la inscripción, en caso de tener el progenitor o progenitora un solo
apellido se le asignará al inscrito dos veces el mismo apellido. Según la disposición tramitada el 28 de enero
de 2016. Sesión 367 de la Asamblea Nacional del Ecuador. 11
En la Ley Orgánica de Gestión de la Identidad y Datos Civiles, Título V Cédula de identidad, Capítulo I
Disposiciones comunes, Artículo 94 – Contenido, indica que la cédula de identidad contendrá… el número
de cédula,… nombres y apellidos del titular…. Según la disposición tramitada el 28 de enero de 2016. Sesión
367 de la Asamblea Nacional del Ecuador.
84
MA
NU
AL
TÉ
CN
ICO
- S
AM
WE
B
E
NE
RO
/201
6
cla
ss
Dia
gra
ma
de
cla
se
s d
e d
ise
ño
Pa
cie
nte
- a
dic
ion
ale
s_p
ac:
txt
(50
0)
- a
nte
ce
de
nte
sFa
m_
pa
c:
txt
(50
0)
- a
nte
ce
de
nte
sPe
r_p
ac:
txt
(50
0)
- a
pe
llid
o1
_p
ac:
txt
(30
)-
ap
ell
ido
2_
pa
c:
txt
(30
)-
est
ad
oU
ltim
aA
ctu
ali
za
cio
n_
pa
c-
facto
rRh
_p
ac:
txt
(8)
- fe
ch
aA
pe
rtu
ra_
pa
c:
da
te-
fech
aN
ac_
pa
c:
da
te-
fech
aU
ltim
aA
ctu
ali
za
cio
n_
pa
c:
da
te-
gru
po
Sa
ng
uin
eo
_p
ac:
txt
(1)
- h
ab
ito
Alc
oh
ol_
pa
c:
txt
(50
0)
- h
ab
ito
Otr
os_
pa
c:
txt
(50
0)
- h
ab
ito
Ta
ba
co
_p
ac:
txt
(50
0)
- n
acio
na
lid
ad
: t
xt
(30
)-
no
mb
re1
_p
ac:
txt
(30
)-
no
mb
re2
_p
ac:
txt
(30
)+
n
um
ero
Ce
du
la_
pa
c:
te
xt(
10
)+
n
um
Hcl_
pa
c:
txt
(11
)-
ori
ge
nD
ato
: t
xt
(10
)-
sexo
_p
ac:
txt
(10
)
«id
»+
id
_p
acie
nte
: i
nt
+
eli
min
arP
acie
nte
(pa
cie
nte
:P
acie
nte
) :
bo
ole
an
+
gu
ard
arP
acie
nte
(pa
cie
nte
:P
acie
nte
, o
pe
racio
n :
txt)
: b
oo
lea
n+
o
bte
ne
rLis
taP
acie
nte
s(cri
teri
o :
txt)
: L
ist(
Pa
cie
nte
)+
o
bte
ne
rPa
cie
nte
(cri
teri
o :
txt)
: P
acie
nte
Tip
o_
pa
cie
nte
- a
cti
vo
_tp
a:
bo
ole
an
- d
esc
rip
cio
n_
tpa
: t
xt
(10
0)
«id
»+
id
_ti
po
Pa
c:
in
t
+
ob
ten
erL
ista
Tip
oP
acie
nte
() :
Lis
t<T
ipo
_p
acie
nte
>
Ate
nc
ion
_m
ed
ica
- d
iag
no
stic
oD
esc
rip
tivo
_a
tm:
txt
(50
0)
- e
xa
me
ne
sMe
dic
os_
atm
: t
xt
(10
00
)-
exa
me
nF
isic
o_
atm
: t
xt
(50
0)
- fe
ch
a_
atm
: d
ate
- h
ora
_a
tm:
tim
e-
mo
tivo
_a
tm:
txt
(50
0)
- si
gn
osV
ita
les_
atm
: t
xt
(10
0)
= T
AL
L:0
*/T
EM
P:0
*...
- tr
ata
mie
nto
_a
tm:
txt
(50
0)
«id
»+
id
_a
ten
cio
nM
ed
: i
nt
+
gu
ard
arA
ten
cio
nM
ed
ica
(ate
ncio
nM
ed
ica
:A
ten
cio
n_
me
dic
a)
: b
oo
lea
n+
o
bte
ne
rAte
ncio
nM
ed
ica
(ate
ncio
n :
Ate
ncio
n_
me
dic
a)
: A
ten
cio
n_
me
dic
a+
o
bte
ne
rLis
taA
ten
cio
ne
sYM
ovim
ien
tos(
cri
teri
o :
txt)
: L
ist<
Ate
ncio
n_
me
dic
a>
Pe
rso
na
l
- a
pe
llid
o1
_p
rs:
txt
(10
0)
- a
pe
llid
o2
_p
rs:
txt
(10
0)
- co
dig
oM
SP
_p
rs:
txt
(15
)-
dir
eccio
n_
prs
: i
nt
- d
isp
on
ibil
ida
d:
txt
(15
)-
ide
nti
fica
cio
n_
prs
: t
xt
(10
)-
na
cio
na
lid
ad
: t
xt
(30
)-
no
mb
re1
_p
rs:
txt
(10
0)
- n
om
bre
2_
prs
: t
xt
(10
0)
- te
lefo
no
s_p
rs:
txt
(50
)
«id
»+
id
_p
ers
on
al:
in
t
+
gu
ard
arP
ers
on
al(
pe
rso
na
l :P
ers
on
al)
: b
oo
lea
n+
o
bte
ne
rLis
taP
ers
on
al(
cri
teri
o :
txt)
: L
ist<
Pe
rso
na
l>+
o
bte
ne
rPe
rso
na
l(cri
teri
o :
txt)
: P
ers
on
al
Tip
o_
es
pe
cia
lid
ad
- a
cti
vo
_ts
p:
bo
ole
an
- d
esc
rip
cio
n_
tsp
: t
xt
(10
0)
«id
»+
id
_ti
po
Esp
: i
nt
+
ob
ten
erL
ista
Tip
oE
spe
cia
lid
ad
() :
Lis
t<T
ipo
_e
spe
cia
lid
ad
>
Mo
vim
ien
to_
inv
en
tari
o
- co
dig
oD
ocu
me
nto
_m
ov:
txt
(10
0)
- fe
ch
a_
mo
v:
da
te-
ho
ra_
mo
v:
tim
e-
mo
tivo
_m
ov:
txt
(40
0)
«id
»+
id
_m
ovim
ien
toIn
v:
in
t
+
actu
ali
za
rDe
spa
ch
oD
eM
ovim
ien
to(m
ovim
ien
toIn
ve
nta
rio
:M
ovim
ien
to_
inve
nta
rio
) :
bo
ole
an
+
gu
ard
arM
ovim
ien
toIn
ve
nta
rio
(mo
vim
ien
toIn
ve
nta
rio
:M
ovim
ien
to_
inve
nta
rio
) :
bo
ole
an
+
lib
era
rMo
vim
ien
tosD
eD
esp
ach
o()
: i
nt
+
ob
ten
erL
ista
De
spa
ch
osP
en
die
nte
s(ti
po
Est
ad
oM
ovim
ien
to :
txt)
: L
ist<
Mo
vim
ien
to_
inve
nta
rio
>+
o
bte
ne
rLis
taM
ovim
ien
tos(
fech
aIn
icia
l :D
ate
, fe
ch
aF
ina
l :D
ate
) :
Lis
t<M
ovim
ien
to_
inve
nta
rio
>+
o
bte
ne
rMo
vim
ien
toIn
ve
nta
rio
(cri
teri
o :
txt)
: M
ovim
ien
to_
inve
nta
rio
De
tall
e_
mo
vim
ien
to_
inv
en
tari
o
- ca
nti
da
d_
de
t:
int
«id
»+
id
_d
eta
lle
Mo
v:
in
t
+
ob
ten
erC
an
tid
ad
Co
mp
rom
eti
da
Insu
mo
(cri
teri
o :
txt)
: i
nt
+
ob
ten
erD
eta
lle
Mo
vim
ien
toIn
ve
nta
rio
(cri
teri
o :
txt)
: D
eta
lle
_m
ovim
ien
to_
inve
nta
rio
+
ob
ten
erL
ista
De
tall
esM
ovim
ien
tos(
id_
mo
vim
ien
to :
inte
ge
r) :
Lis
t <
De
tall
e_
mo
vim
ien
to_
inve
nta
rio
>
Ins
um
o_
me
dic
o
+
ca
nti
da
d_
actu
al_
ism
: i
nt
+
ca
nti
da
d_
reo
rde
n_
ism
: i
nt
- d
esc
rip
cio
n_
ism
: t
xt
(10
0)
- fo
rma
_fa
rma
ce
uti
ca
_is
m:
txt
(60
)-
no
mb
re_
ism
: t
xt
(60
)
«id
»+
id
_in
sum
oM
ed
: i
nt
+
eli
min
arI
nsu
mo
Me
dic
o(I
nsu
mo
Me
dic
o :
Insu
mo
_m
ed
ico
) :
bo
ole
an
+
gu
ard
arI
nsu
mo
Me
dic
o(i
nsu
mo
Me
dic
o :
Insu
mo
_m
ed
ico
, o
pe
racio
n :
txt)
: b
oo
lea
n+
o
bte
ne
rIn
sum
o(c
rite
rio
:tx
t) :
In
sum
o_
me
dic
o+
o
bte
ne
rLis
taIn
sum
os(
cri
teri
o :
txt)
: L
ist
<In
sum
o_
me
dic
o>
Tip
o_
mo
vim
ien
to_
inv
en
tari
o
- a
cti
vo
_tm
i:
bo
ole
an
- d
esc
rip
cio
n_
tmi:
tx
t (1
00
)-
tip
oIn
gre
soE
gre
so_
tmi:
tx
t(3
0)
«id
»+
id
_ti
po
Mo
v:
in
t
+
ob
ten
erL
ista
Tip
oM
ovim
ien
toIn
ve
nta
rio
() :
Lis
t <
Tip
o_
mo
vim
ien
to_
inve
nta
rio
>+
o
bte
ne
rLis
taT
ipo
Mo
vim
ien
toIn
ve
nta
rio
De
spa
ch
o()
: L
ist
<T
ipo
_m
ovim
ien
to_
inve
nta
rio
>
Tip
o_
ate
nc
ion
_m
ed
ica
- a
cti
vo
_ta
m:
bo
ole
an
- d
esc
rip
cio
n_
tam
: t
xt
(10
0)
«id
»+
id
_ti
po
Atm
: i
nt
+
ob
ten
erL
ista
Tip
oA
ten
cio
nM
ed
ica
() :
Lis
t<T
ipo
_a
ten
cio
n_
me
dic
a>
Tip
o_
es
tad
o_
mo
vim
ien
to_
inv
en
tari
o
- a
cti
vo
_e
st:
bo
ole
an
- d
esc
rip
cio
n_
est
: t
xt
(10
0)
«id
»+
id
_ti
po
Est
Mo
v:
in
t
+
ob
ten
erL
ista
Tip
oE
sta
do
Mo
vim
ien
toIn
ve
nta
rio
() :
Lis
t<T
ipo
_e
sta
do
_m
ovim
ien
to>
To
po
gra
fia
_C
IE
- co
dig
o_
top
: t
xt
(9)
- n
om
bre
_to
p:
txt
(26
0)
«id
»+
id
_to
po
gra
fia
: i
nt
+
ob
ten
erL
ista
To
po
gra
fia
s(cri
teri
o :
txt,
bu
squ
ed
aP
or
:txt)
: L
ist<
To
po
gra
fia
_C
IE>
No
mb
re:
Dia
gra
ma
de
cla
ses
de
dis
eñ
oA
uto
r:D
ian
a O
ña
; A
nd
rés
Ro
sero
T.
Ve
rsió
n:
7.0
Cre
ad
o:
24
/03
/20
14
11
:59
:24
Actu
ali
za
do
:15
/03
/20
16
11
:23
:56
Tip
o_
ins
um
o_
me
dic
o
- a
cti
vo
_ti
m:
bo
ole
an
- d
esc
rip
cio
n_
tim
: t
xt
(10
0)
«id
»+
id
_ti
po
InsM
ed
: i
nt
+
ob
ten
erL
ista
Tip
oIn
sum
oM
ed
ico
() :
Lis
t<T
ipo
_in
sum
o_
me
dic
o>
Tip
o_
pre
se
nta
cio
n_
ins
um
o_
me
dic
o
- a
cti
vo
_tp
i:
bo
ole
an
- d
esc
rip
cio
n_
tpi:
tx
t(1
00
)
«id
»-
id_
tip
oP
rese
nta
cio
nIM
+
ob
ten
erL
ista
Tip
oP
rese
nta
cio
nIn
sum
oM
ed
ico
() :
Lis
t<T
ipo
_p
rese
nta
cio
nIM
>
+a
tie
nd
e 1
ate
ncio
nM
ed
_p
ers
on
al
0..
*
0..
*
mo
vim
ien
to_
inve
nta
rio
_ti
po
+ca
lifi
ca
1+
inclu
ye
1
mo
vim
ien
toIn
ve
nta
rio
_d
eta
lle 0
..*
1
insu
mo
Me
dic
o_
de
tall
eM
ovim
ien
to
+m
ue
ve
n
0..
*
+co
rre
spo
nd
e0
..*
ate
ncio
n_
me
dic
a_
tip
o
1
+e
s d
e0
..*
pa
cie
nte
_ti
po
_p
acie
nte
1
0..
*
pe
rso
na
l_m
ovim
ien
to_
inve
nta
rio
+re
gis
tra
1
0..
*
pe
rso
na
l_ti
po
_e
spe
cia
lid
ad
+ca
lifi
ca
1
0..
*
ate
ncio
n_
mo
vim
ien
to+
dis
po
nib
le1
0..
* tip
o_
pre
sen
tacio
n
+ca
lifi
ca
1
0..
*
tip
o_
insu
mo
Me
dic
o
+ca
lifi
ca
1
1
gru
po
_to
po
gra
fia
0..
*
1a
ten
cio
n_
dia
gn
ost
ico
+d
iag
no
stic
ad
o c
on
0..
*
+a
ten
did
o
1
ate
ncio
n_
pa
cie
nte
0..
*
1
tip
o_
est
ad
o_
mo
vim
ien
to
+se
en
cu
en
tra
n e
n0
..*
F
igu
ra 4
.5:
Dia
gra
ma
de
cla
ses
de
dis
eñ
o
85
MA
NU
AL
TÉ
CN
ICO
- S
AM
WE
B
E
NE
RO
/201
6
4.2.
2 D
IAG
RA
MA
DE
OB
JET
OS
En
la F
igu
ra 4
.6 s
e o
bse
rva
el d
iagr
am
a d
e o
bje
tos
ob
jec
t D
iag
ram
a d
e o
bje
tos
Lu
is G
óm
ez :
Pa
cie
nte
ap
ell
ido
1_
pa
c =
Gó
me
zn
om
bre
1_
pa
c =
Lu
isfe
ch
aN
ac_
pa
c =
11
/07
/19
88
an
tece
de
nte
sPe
r_p
ac =
1 h
ijo
ap
ell
ido
2_
pa
c =
Tit
ua
ña
facto
rRh
_p
ac =
+g
rup
oS
an
gu
ine
o_
pa
c =
Oid
_p
acie
nte
= 1
71
01
85
77
2n
om
bre
2_
pa
c =
Da
nie
ln
um
Hcl_
pa
c =
21
24
5se
xo
_p
ac =
Ma
scu
lin
oa
dic
ion
ale
s_p
ac =
Hip
ert
en
soa
nte
ce
de
nte
sFa
m_
pa
c =
Ab
ue
la d
iab
éti
ca
ce
du
la_
pa
c =
17
21
14
08
69
fech
aA
pe
rtu
ra_
pa
c =
11
/11
/20
15
fech
aU
ltim
aA
ctu
ali
za
cio
n_
pa
c =
11
/11
/20
15
ha
bit
oO
tro
s_p
ac =
de
po
rtis
tah
ab
ito
Alc
oh
ol_
pa
c =
So
cia
lh
ab
ito
Ta
ba
co
_p
ac =
No
na
cio
na
lid
ad
= E
cu
ato
ria
na
ori
ge
nD
ato
= S
AE
We
sta
do
Ult
ima
Actu
ali
za
cio
n_
pa
c =
Acti
vo
Dr.
Pa
tric
io L
óp
ez :
Pe
rs
on
al
ap
ell
ido
1_
prs
= L
óp
ez
no
mb
re1
_p
rs =
Pa
tric
ioid
_p
ers
on
al
= 1
co
dig
oM
SP
_p
rs =
51
32
48
5
Do
ce
nte
:Tip
o p
ac
ien
te
id_
tip
oP
ac =
01
de
scri
pcio
n_
tpa
= E
stu
dia
nte
acti
vo
_tp
a =
tru
e1
5/1
2/2
01
5 1
8:2
6 :
Ate
nc
ion
_m
ed
ica
id_
ate
ncio
nM
ed
= 1
25
8fe
ch
a_
atm
= 1
5/1
2/2
01
5h
ora
_a
tm =
10
:57
:03
am
exa
me
ne
sMe
dic
os_
atm
= C
op
rop
ara
sita
rio
e
xa
me
nF
isic
o_
atm
= D
olo
r a
l p
resi
on
ar
el
ab
do
me
nm
oti
vo
_a
tm =
Vie
ne
po
r d
olo
r e
sto
ma
ca
ltr
ata
mie
nto
_a
tm =
Ag
ua
tib
ia p
or
las
no
ch
es.
Bu
sca
pin
a c
/8 p
or
3 d
ías
dia
gn
ost
ico
_a
tm =
Ga
stri
tis
dia
gn
ost
ico
De
scri
pti
vo
_a
tm =
Ga
stri
tis
Me
dic
ina
ge
ne
ral
:Tip
o_
es
pe
cia
lid
ad
id_
tip
oE
sp =
1d
esc
rip
cio
n_
tsp
= M
ed
icin
a g
en
era
la
cti
vo
_ts
p =
tru
e
No
rma
l :T
ipo
ate
nc
ion
id_
tip
oA
tm =
1d
esc
rip
cio
n_
tam
= N
orm
al
acti
vo
_ta
m =
tru
eA
An
alg
és
ico
:Tip
o_
ins
um
o_
me
dic
o
id_
ord
en
Me
d =
1fe
ch
a_
orm
= 1
0/0
7/2
01
4
Pa
sti
lla
s :
Tip
o_
pre
se
nta
cio
n_
ins
um
o_
me
dic
o
de
scri
pcio
n_
tpi
= P
ast
illa
sa
cti
vo
_tp
i =
tru
eid
_ti
po
Pre
sen
tacio
nIM
= 4
Eg
res
o p
or
de
sp
ac
ho
(s
um
inis
tro
) :
Tip
o_
mo
vim
ien
to_
inv
en
tari
o
id_
tip
oS
to =
1d
esc
rip
cio
n_
tmi
= D
esp
ach
ad
oid
_ti
po
Mo
v =
1a
cti
vo
_tm
i =
tru
eti
po
Ing
reso
Eg
reso
_tm
i =
IN
GR
ES
O
2 :
De
tall
e_
mo
vim
ien
to_
inv
en
tari
o
id_
drc
= 1
00
1ca
nti
da
d_
de
t =
5
Bu
sc
ap
ina
:In
su
mo
_m
ed
ico
id_
insu
mo
Me
d =
1n
om
bre
_is
m =
Bu
sca
pin
asa
ldo
_a
ctu
al_
ism
= 3
8sa
ldo
_m
inim
o_
ism
= 5
Mo
vim
ien
to i
nv
en
tari
o
id_
mo
vim
ien
toIn
v =
1fe
ch
a_
mo
v =
10
/07
/20
14
ho
ra_
mo
v =
11
:00
am
co
dig
oD
ocu
me
nto
_m
ov =
EP
N1
23
-s4
mo
tivo
_m
ov =
Co
mp
ra d
e m
ed
ica
ció
n p
or
ren
ova
ció
n
Co
mp
rom
eti
do
:Tip
o_
es
tad
o_
mo
vim
ien
to_
inv
en
tari
o
id_
tip
oM
ov =
1d
esc
rip
cio
n_
tmi
= C
om
pro
me
tid
oa
cti
vo
_e
st =
tru
e
No
mb
re:
Dia
gra
ma
de
ob
jeto
sA
uto
r:D
ian
a O
ña
; A
nd
rés
Ro
sero
T.
Ve
rsió
n:
3.0
Cre
ad
o:
16
/07
/20
14
17
:50
:04
Actu
ali
za
do
:16
/12
/20
15
4:0
9:2
2
A0
6 :
To
po
gra
fia
_C
IE
co
dig
o_
top
= A
06
no
mb
re_
top
= E
nfe
rme
da
de
s in
feccio
sas
inte
stin
ale
sid
_to
po
gra
fia
= 1
35
0
A0
65
:To
po
gra
fia
_C
IE
co
dig
o_
top
= A
06
5n
om
bre
_to
p =
Am
eb
iasi
sid
_to
po
gra
fia
= 1
25
67
F
igu
ra 4
.6 D
iag
ram
a d
e o
bje
tos
86
MANUAL TÉCNICO - SAMWEB ENERO/2016
4.2.3 DICCIONARIO DE DATOS DEL DIAGRAMA DE CLASES
Los valores que se usarán en los atributos de las clases definidas son los
siguientes:
o Especialidades § Medicina general § Ginecología § Odontología § Psicología § Nutrición
o Pacientes § Estudiante § Docente § Administrativo § Otro
o Disponibilidad del personal § Vigente § Inactivo § Vacaciones § Permiso
o Atención médica § Emergencia § Normal § Medicina preventiva
o Movimientos del inventario de medicamentos § Ingreso por compra § Ingreso por donación § Ingreso por cambio § Ingreso por ajuste excedente § Egreso por ajuste faltante § Egreso por baja § Egreso por despacho (suministro) § Egreso por despacho (entrega)
o Estado del movimiento de inventario § Comprometido § Ejecutado § Liberada
o Origen dato § Fuente externa § Digitado
o Tipos CIE Abreviaturas convenidas
HCL: Es una abreviatura convenida en el ámbito médico que significa Historia
clínica. El término es utilizado en los hospitales, clínicas y centros de salud país.
87
MANUAL TÉCNICO - SAMWEB ENERO/2016
4.3 DISEÑO DINÁMICO
A continuación se encuentra el Diagrama de actividades del CU Registrar
atención médica ya que necesita una explicación a detalle al ser un CU Complejo.
4.3.1 DIAGRAMA DE ACTIVIDADES
La Figura 4.7 muestra el Diagrama de actividades del CU Registrar atención
médica.
act Diagrama de activ idades del CU Registrar atención médica
Presentación Negocio Acceso a datos
InicioDeActividad
Asignar fecha y hora actual para la atención
médica
Mostrar interfaz Registrar atención médica
Capturar Tipo de atención
Capturar el criterio de búsqueda
Emitir mensaje de error "No hay coincidencias"
Despliega en una grilla los pacientes que
coinciden con el criterio de búsqueda
Asigna la información del
paciente seleccionado en la sección Datos del paciente
Emitir mensaje de error correspondiente
Capturar datos de la Atención
médica: signos v itales, motiv o,
examen clínico, diagnóstico,
tratamiento y exámenes médicos
Emitir mensaje de error “Los
hábitos, antecedentes y adicionales
no se guardaron”
Ev aluar ev ento escogido
CU: Validar atención médica
CU: Consultar historial clínico (id_paciente)
Nombre: Diagrama de actividades del CU Registrar atención médicaAutor: Diana Oña; Andrés Rosero T.Versión: 4.0Creado: 08/10/2014 16:31:54Actualizado:14/03/2016 14:43:11
Paciente.guardarPaciente(pacienteSeleccionado Paciente, "Actualizar" operacion)
Atención_médica.guardarAtencionMedica(Atencion_medica)
Paciente.obtenerListaPacientes(criterio String)
[Éxito]
[“Consultar historial clínico”]
[“Consultar paciente”]
[Guardar atención médica]
[Éxito][Error]
[Error]
[error]
[coincidencias ok]
[Seleccionar paciente de la gril la]
87
MANUAL TÉCNICO - SAMWEB ENERO/2016
FinalDeActividad
Emitir mensaje “Registro
exitoso”
Validar que Tipo paciente sea Estudiante o Tipo atención
sea Emergencia
Validar si la atención
médica ha sido guardada
Emitir mensaje de error “La atención medica no
se pudo guardar”
Emitir mensaje "¿Salir sin
guardar?"
CU: Registrar orden de despacho de medicación
[identificador error]
[identificador correcto]
[“Registrar orden de despacho de medicación”]
[No cumple]
[si cumple]
[SI]
["Salir"]
[No]
Figura 4.7 Diagrama de actividades del CU Registrar atención médica.
88
MANUAL TÉCNICO - SAMWEB ENERO/2016
4.3.2 DIAGRAMAS DE SECUENCIA
La Figura 4.8 muestra el Diagrama de secuencia del CU registrar atención
médica.
sd Diagrama de secuencia del CU Registrar atención médica
Médico
(from Actores)
Registrar atención
médica
«table»
Paciente
Atencion_medica DatosMedicoWS(Subsistema
externo)
Nombre: Diagrama de secuencia del CU Registrar atención médica Autor: Diana Oña; Andrés Rosero T.Versión: 6.0Creado: 08/10/2014 16:35:07Actualizado:08/01/2016 2:11:20
Registrar Atenciòn Médica()
obtenerListaPacientes(criterio String) :List(Paciente)
DatosMedicoWS.ConsultaEstudiante(String cedula, String apellidosNombres) :String:
:String: "Estado paciente: Estudiante"
Guardar Atención Médica()
guardarPaciente(paciente :Paciente, operacion :txt) :boolean
guardarAtencionMedica(atencionMedica :Atencion_medica) :boolean
:"Atención médica registrada"
Figura 4.8 Diagrama de secuencia del CU Registrar atención médica
El Diagrama de secuencia del CU Consultar historial clínico se lo muestra en la
Figura 4.9.
sd Diagrama de secuencia del CU Consultar historial clínico
Médico
(from Actores)
Consultar historialclínico
Atencion_medica
Nombre: Diagrama de secuencia del CU Consultar historial clínicoAutor: andyerytoVersión: 1.0Creado: 18/10/2014 22:13:59Actualizado:18/10/2014 22:17:35
AcciónConsultarHistorialClínicoClic(Id_paciente integer)
obtenerListaAtencionesYMovimientos(criterio :txt) :List<Atencion_medica>
Figura 4.9 Diagrama de secuencia del CU Consultar historial clínico
89
MANUAL TÉCNICO - SAMWEB ENERO/2016
El Diagrama de secuencia del CU registrar apertura de HCL se lo muestra en la
Figura 4.10.
sd Diagrama de secuencia del CU Registrar apertura de HCL
Enfermera
(from Actores)
Registrar aperturade HCL
«table»
Paciente
DatosMedicoWS(Subsistema
externo)
Nombre: Diagrama de secuencia del CU Registrar apertura de HCLAutor: Diana Oña; Andrés Rosero T.Versión: 3.0Creado: 18/10/2014 22:09:23Actualizado:08/01/2016 2:11:13
RegistrarAperturaHCL()
obtenerListaPacientes(criterio :txt) :List(Paciente)
:List(Paciente)
DatosMedicoWS.ConsultaEstudiante(String cedula, String apellidosNombres) :String estado
:String "Estado del paciente: Estudiante"
GuardarPaciente()
obtenerPaciente(criterio :txt) :Paciente
guardarPaciente(paciente :Paciente, operacion :txt) :boolean
:"Registro correcto"
Figura 4.10 Diagrama de secuencia del CU registrar apertura de HCL
90
MANUAL TÉCNICO - SAMWEB ENERO/2016
La Figura 4.11 muestra el Diagrama de secuencia del CU Registrar orden de
despacho de insumos médicos
sd Diagrama de secuencia del CU registrar orden de despacho de insumos medicos
Registrar ordende despacho de
medicación
Insumo_medico Movimiento_inventario Detalle_movimiento_inventario
Médico
(from Actores)
Nombre: Diagrama de secuencia del CU registrar orden de despacho de insumos medicosAutor: andyerytoVersión: 1.0Creado: 18/10/2014 17:45:11Actualizado:18/10/2014 22:24:11
BotonConsultarInsumoMédicoClick()
obtenerListaInsumos(txt) :List <Insumo_medico>
BotonGuardarOrdenDespachoClick()
guardarMovimientoInventario(Movimiento_inventario):boolean
guardarDetalleMovimiento(Detalle_movimiento_inventario):boolean
Figura 4.11 Diagrama de secuencia del CU Registrar orden de despacho de insumos médicos
La Figura 4.12 muestra el Diagrama de secuencia del CU Registrar insumo
médico
sd Diagrama de secuencia del CU Registrar insumo médico
Enfermera
(from Actores)
Insumo_medico
Registrar insumomédico
Nombre: Diagrama de secuencia del CU Registrar insumo médicoAutor: andyerytoVersión: 1.0Creado: 18/10/2014 21:40:20Actualizado:18/10/2014 21:52:03
BotónRegistrarInsumoMédicoClic()
obtenerListaInsumos(criterio :txt) :List <Insumo_medico>
BotónGuardarInsumoMédicoClic()
guardarInsumoMedico(insumoMedico :Insumo_medico) :boolean
:"Registro exitoso"
Figura 4.12 Diagrama de secuencia del CU Registrar insumo médico
91
MANUAL TÉCNICO - SAMWEB ENERO/2016
El Diagrama de secuencia del CU Registrar movimiento de inventario está
representado en la Figura 4.13.
sd Diagrama de secuencia del CU Registrar mov imientos de inv entario
Enfermera
(from Actores)
Registrarmov imientos de
inv entario
Insumo_medico Movimiento_inventario Detalle_movimiento_inventario
Nombre: Diagrama de secuencia del CU Registrar movimientos de inventarioAutor: andyerytoVersión: 1.0Creado: 18/10/2014 22:07:01Actualizado:18/10/2014 22:23:49
BotónConsultarInsumoMédicoClic()
obtenerListaInsumos(criterio :txt) :List <Insumo_medico>
BotónGuardarMovimientoDeInventarioClic()
guardarMovimientoInventario(movimientoInventario :Movimiento_inventario) :boolean
guardarDetalleMovimiento(detalle :Detalle_movimiento_inventario) :boolean
Figura 4.13 Diagrama de secuencia del CU Registrar movimiento de inventario
92
MANUAL TÉCNICO - SAMWEB ENERO/2016
La Figura 4.14 muestra el Diagrama de secuencia del CU Registrar despacho de
insumos médicos
sd Diagrama de secuencia del CU Registrar despacho de insumos médicos
Enfermera
(from Actores)
Movimiento_inventario
Registrardespacho de
insumos médicos
Insumo_medico
AcciónListarDespachosPendientesEvento()
guardarMovimientoInventario(movimientoInventario :Movimiento_inventario) :boolean
BotónDespacharClic()
actualizarDespachoDeMovimiento(movimientoInventario :Movimiento_inventario) :boolean
actualizarCantidadActualInsumo(Cantidad :integer,Id_insumoMedico :integer) :int
l iberarMovimientosDeDespacho(tipoEstadoMovimiento:integer)
:"Despacho registrado"
Figura 4.14 Diagrama de secuencia del CU Registrar despacho de insumos médicos
93
MANUAL TÉCNICO - SAMWEB ENERO/2016
La siguiente figura muestra el Diagrama de secuencia del CU registrar
presentación de documentos de salud de estudiantes nuevos.
sd Diagrama de secuencia del CU registrar presentación de documentos de salud de estudiantes nuev os
DatosMedicoWS(Subsistema
externo)Médico
(from Actores)
Registrarpresentación de
Docs. Médicos
Nombre: Diagrama de secuencia del CU registrar presentación de documentos de salud de estudiantes nuevosAutor: Diana Oña, Andrés RoseroVersión: 1.0Creado: 08/01/2016 0:34:28Actualizado:08/01/2016 1:46:06
Consultar()
DatosMedicoWS.ConsultaEstudiante(String cedula, String apellidosNombres) :String
:String "Estado del estudiante"
DatosMedicoWS.DatosMedico(String cedula, String apellidosNombres, String fecha, String consultorio): List<Estudiante>
:List<Estudiante>
:Mostrar l ista de Estudiantes
Ver detalles()
DatosMedicoWS.ConsultaEstudiante(String cedula, String apellidosNombres) :String
:String "Estado del estudiante"
cargarDatosEstudianteSeleccionado() :Estudiante:Mostrar datos de identifiacióny estado del estudiante
Validar documentos de salud()DatosMedicoWS.ChequeoDatosMedico(String cedula) :String
:String "OK":String "Validación dedocumentos exitosa"
Figura 4.15: Diagrama de secuencia del CU registrar presentación de documentos de salud de
estudiantes nuevos
94
MANUAL TÉCNICO - SAMWEB ENERO/2016
4.3.3 DIAGRAMA DE ESTADOS
El único objeto reconocido que cambia de estados son los Movimientos de
inventario cuando se llama al CU: Registrar orden de despacho de insumos
médicos pasa a ser Comprometido, o si se llama al CU: Registrar movimiento de
insumos médicos pasa a ser a Ejecutado, o si se ejecuta el CU Registrar
despacho de orden de insumos médicos si la fecha de orden de despacho es
igual a la fecha actual pasa a ser Ejecutado caso contrario si es igual a la fecha
de día anterior pasa a ser Liberado.
El diagrama de estados para el objeto Movimiento de inventario se lo representa
en la Figura 4.16.
stm Diagrama de estados para el objeto Mov imiento de inv entario
Inicio
Fin
Comprometido
Ejecutado
Liberada
Nombre: Diagrama de estados para el objeto Movimiento de inventarioAutor: Diana Oña; Andrés Rosero T.Versión: 1.0Creado: 14/12/2015 2:06:10Actualizado:18/12/2015 1:30:39
[Si fecha de orden de despacho == hoy]
CU: Registrar movimiento de insumos médicos
[Si fecha de orden de despacho == ayer]
CU: Registrar despacho de orden de insumos médicos:
CU: Registrar orden de despacho de insumos médicos
Figura 4.16: Diagrama de estados para el objeto Movimiento de inventario
95
MA
NU
AL
TÉ
CN
ICO
- S
AM
WE
B
E
NE
RO
/201
6
4.4
D
ISE
ÑO
DE
DE
SP
LIE
GU
E
El
Dis
eñ
o d
e d
esp
liegu
e c
onsi
de
ra t
oda
s la
s e
spe
cific
aci
one
s d
e h
ard
wa
re y
so
ftw
are
ba
se q
ue
requ
iere
el
pro
du
cto
de
sarr
olla
do p
ara
su
fun
cion
amie
nto
.
4.4.
1 D
IAG
RA
MA
DE
CO
MP
ON
EN
TE
S
El
Dia
gram
a
de
co
mp
one
nte
s m
uest
ra
las
un
idad
es
de
soft
wa
re
y su
s re
laci
on
es
pa
ra
el
fun
ciona
mie
nto
de
l
sub
sist
ema
SA
MW
eb e
n
la F
igu
ra 4
.17
.
cm
p D
iag
ram
a d
e c
om
po
ne
nte
s
We
bS
erv
icio
sD
ato
s
Sis
tem
a e
xte
rno
(R
eg
istr
o C
ivil
)
reg
istr
arA
pe
rtu
raH
CL
Re
gis
tra
rAp
ert
ura
HC
LB
ac
kin
gB
ea
n
Pa
cie
nte
_S
erv
ice
Be
an
Pe
rso
na
l_S
erv
ice
Be
an
reg
istr
arP
ers
on
al
Re
gis
tra
rPe
rso
na
lBa
ck
ing
Be
an
Pa
cie
nte
_E
nti
da
d
Pe
rso
na
l_E
nti
da
d
WS
Re
gis
tro
Civ
ilC
on
su
lta
Ce
du
laC
ed
ula
Em
ple
ad
o_
En
tid
ad
RR
HH
_S
erv
ice
Be
an
SE
RV
IDO
R D
E
SE
RV
ICIO
S W
EB
DE
L
RE
GIS
TRO
CIV
IL
No
mb
re:
Dia
gra
ma
de
co
mp
on
en
tes
Au
tor:
Dia
na
Oñ
a,
An
dré
s R
ose
ro T
.V
ers
ión
:2
.0C
rea
do
:1
3/1
0/2
01
5 1
:32
:28
Act
ua
liza
do
:08
/01
/20
16
2:1
2:0
8
96
MA
NU
AL
TÉ
CN
ICO
- S
AM
WE
B
E
NE
RO
/201
6
Se
rvic
io e
xte
rno
(S
AE
W)
Ate
nc
ion
Me
dic
a_
Se
rvic
eB
ea
nA
ten
cio
nM
ed
ica
_E
nti
da
d
JP
A_
Pe
rsis
ten
cia
Mo
vim
ien
toIn
ve
nta
rio
_S
erv
ice
Be
an
De
tall
eM
ov
imie
nto
Inv
en
tari
o_
Se
rvic
eB
ea
n
Top
og
rafi
aC
IE_
Se
rvic
eB
ea
nre
gis
tra
rAte
nc
ion
Me
dic
a
reg
istr
arD
es
pa
ch
o
reg
istr
arM
ov
imie
nto
Inv
en
tari
o
reg
istr
arP
res
en
tac
ion
Do
cu
me
nto
sM
Re
gis
tra
rPre
se
nta
cio
nD
oc
sM
ed
ico
sB
ac
kin
gB
ea
n
Re
gis
tra
rAte
nc
ion
Me
dic
aB
ac
kin
gB
ea
n
Re
gis
tra
rMo
vim
ien
toIn
ve
nta
rio
Ba
ck
ing
Be
an
Re
gis
tra
rDe
sp
ac
ho
IMB
ac
kin
Be
an
Ins
um
oM
ed
ico
_E
nti
da
d
Mo
vim
ien
toIn
ve
nta
rio
_E
nti
da
d
De
tall
eM
ov
imie
nto
Inv
en
tari
o_
En
tid
ad
Top
og
rafi
aC
IE_
En
tid
ad
Da
tos
Me
dic
oW
SE
stu
dia
nte
SE
RV
IDO
R D
E
SE
RV
ICIO
S W
EB
DE
L
SA
EW
95
MA
NU
AL
TÉ
CN
ICO
- S
AM
WE
B
E
NE
RO
/201
6
Ins
um
oM
ed
ico
_S
erv
ice
Be
an
Ca
talo
go
_S
erv
ice
Be
an
reg
istr
arI
ns
um
oM
ed
ico
rep
ort
es
Ate
nc
ion
Me
dic
a
Ge
ne
rarR
ep
ort
eB
ac
kin
gB
ea
n
Re
gis
tra
rIn
su
mo
Me
dic
oB
ac
kin
gB
ea
n
Re
gis
tra
rCa
talo
go
Ba
ck
ing
Be
an
Ca
talo
go
_E
nti
da
d
Ca
talo
go
Tip
o_
En
tid
ad
Co
ns
ult
aR
ep
ort
es
_S
erv
ice
Be
an
Re
po
rte
Me
taD
ata
_E
nti
da
d
Re
po
rte
_E
nti
da
d
reg
istr
arC
ata
log
o
Fig
ura
4.1
7:
Dia
gra
ma
de
co
mp
on
en
tes
96
MANUAL TÉCNICO - SAMWEB ENERO/2016
4.4.2 DIAGRAMA DE DESPLIEGUE
La Figura 4.18 muestra los recursos de TI que hay en el sistema y los componentes
que se implantarán sobre estos. El diagrama de despliegue permite valorar la
distribución y la asignación de recursos que se usarán en tiempo de ejecución.
deployment Diagrama de despliegue
CLIENTE
SERVIDOR DE SERVICIOS WEB DEL REGISTRO
CIVIL
SERVIDOR DE SERVICIOS WEB
DEL SAEW
SERVIDOR DE APLICACIONES JBoss Aplication Serv er
SERVIDOR DE BASE DE DATOS POSTGRES
- SAMWEB- CAS - SERVICIOS DE ATENCION MEDICA - SERVICIOS DE SEGURIDAD CAS
BD: bddcorpepn- Medico- RRHH- Public
- Google Chrome- Mozilla Firefox- Safari- Opera
Nombre: Diagrama de despliegueAutor: Diana Oña, Andrés Rosero T.Versión: 2.0Creado: 12/10/2015 23:03:17Actualizado:18/12/2015 1:51:22
Figura 4.18: Diagrama de despliegue
97
MANUAL TÉCNICO - SAMWEB ENERO/2016
5 IMPLEMENTACIÓN
Dentro de la implementación se tienen la estructura de la base de datos y el código
fuente. Para visualizar el código fuente Ver el ANEXO D12 - Código fuente del
subsistema.
1.1. ESTRUCTURA DE LA BASE DE DATOS
Se implementó la base de datos, se analizó (luego de generada la estructura de base
de datos inicial) y se encontró que varias tablas, las que tienen que ver con tipos
(tablas referenciales o manuales o catálogos), por tener un comportamiento similar
deberían ser tratadas de una manera global y estandarizada. Estas tablas son:
· Tipo_paciente.
· Tipo_atencion_medica.
· Tipo_especialidad.
· Tipo_movimiento_inventario.
· Tipo_estado_movimiento_inventario.
· Tipo_insumo_medico.
· Tipo_presentacion_insumo_medico.
Se decidió juntarlas en una estructura de dos tablas CATALOGO y CATALOGOTIPO
ya que esto simplificaría la codificación del mantenimiento y el trato de dichas tablas.
A continuación se observa la estructura de la base de datos del subsistema realizado
a partir del diagrama de clases de diseño.
98
MA
NU
AL
TÉ
CN
ICO
- S
AM
WE
B
E
NE
RO
/201
6
ate
nci
on
_p
aci
en
te
ate
nd
ido
tip
o_
Pa
cie
nte
cla
sifi
cad
o p
or
tip
o_
cata
log
o
pe
rte
ne
ce a
tip
o_
ate
nci
on
Me
dic
aco
rre
spo
nd
e
ate
nci
on
_d
iag
no
stic
o
dia
gn
ost
ica
do
co
n
ate
nci
on
Me
d_
pe
rso
na
l
ati
en
de
ate
nci
on
_m
ovi
mie
nto
dis
po
nib
le
pe
rso
na
l_M
ovI
nve
nta
rio
reg
istr
a
tip
o_
pe
rso
na
lEsp
eci
ali
da
d
tie
ne
mo
vim
ien
to_
de
tall
e
incl
uye
tip
o_
Est
ad
oM
ovi
mie
nto
dis
po
ne
tip
o_
mo
vim
ien
toIn
ven
tari
oca
lifi
cad
o p
or
Insu
mo
Me
dic
o_
De
tall
em
ue
ve
tip
o_
insu
mo
Me
dic
o
cla
sifi
cad
o p
or
sub
tip
o_
top
og
rafi
co
tip
o_
pe
rso
na
lMe
dic
o
cali
fica
do
po
r
tip
o_
pre
sen
taci
on
Insu
mo
Me
dic
o
pa
cie
nte
# o * o * o * * * o o * o o o o o o o o * o
id_
pa
cie
nte
nu
me
roC
ed
ula
_p
ac
ap
ell
ido
1_
pa
ca
pe
llid
o2
_p
ac
no
mb
re1
_p
ac
no
mb
re2
_p
ac
fech
aN
ac_
pa
cse
xo_
pa
cn
aci
on
ali
da
d_
pa
ce
sta
do
Ult
ima
Act
ua
liza
cio
n_
pa
cfe
cha
Ult
ima
Act
ua
liza
cio
n_
pa
cfe
cha
Ap
ert
ura
_p
ac
ha
bit
osA
lco
ho
l_p
ac
ha
bit
osT
ab
aco
_p
ac
ha
bit
osO
tro
s_p
ac
an
tece
de
nte
sFa
m_
pa
ca
nte
ced
en
tesP
er_
pa
ca
dic
ion
ale
s_p
ac
fact
orR
H_
pa
cg
rup
oS
an
gu
ine
o_
pa
cn
um
ero
HC
L_
pa
co
rig
en
Da
to
Se
ria
lC
ha
ract
ers
(1
0)
Ch
ara
cte
rs (
30
)C
ha
ract
ers
(3
0)
Ch
ara
cte
rs (
30
)C
ha
ract
ers
(3
0)
Da
teC
ha
ract
ers
(1
0)
Ch
ara
cte
rs (
30
)C
ha
ract
ers
(1
5)
Tim
est
am
pT
ime
sta
mp
Va
ria
ble
ch
ara
cte
rs (
30
00
)V
ari
ab
le c
ha
ract
ers
(3
00
0)
Va
ria
ble
ch
ara
cte
rs (
30
00
)V
ari
ab
le c
ha
ract
ers
(3
00
0)
Va
ria
ble
ch
ara
cte
rs (
30
00
)V
ari
ab
le c
ha
ract
ers
(3
00
0)
Ch
ara
cte
rs (
8)
Ch
ara
cte
rs (
1)
Se
ria
lV
ari
ab
le c
ha
ract
ers
(1
0)
ate
nci
on
Me
dic
a
# o o o o o o *
id_
ate
nci
on
Me
dsi
gn
osV
ita
les_
atm
mo
tivo
_a
tme
xam
en
Fis
ico
_a
tmd
iag
no
stic
oD
esc
rip
tivo
_a
tmtr
ata
mie
nto
_a
tme
xam
en
esM
ed
ico
s_a
tmfe
cha
Ho
ra_
atm
Se
ria
lV
ari
ab
le c
ha
ract
ers
(1
00
)V
ari
ab
le c
ha
ract
ers
(3
00
0)
Va
ria
ble
ch
ara
cte
rs (
30
00
)V
ari
ab
le c
ha
ract
ers
(3
00
0)
Va
ria
ble
ch
ara
cte
rs (
30
00
)V
ari
ab
le m
ult
ibyt
e (
30
00
)T
ime
sta
mp
top
og
rafi
aC
ie
# * *
id_
To
po
gra
fia
cod
igo
_to
pn
om
bre
_to
p
Se
ria
lC
ha
ract
ers
(9
)V
ari
ab
le c
ha
ract
ers
(3
00
)
pe
rso
na
l
# * o o o * * * * o *
id_
pe
rso
na
la
pe
llid
o1
_p
rsa
pe
llid
o2
_p
rsn
om
bre
1_
prs
no
mb
re2
_p
rsco
dig
oM
SP
_p
rsd
isp
on
ibil
ida
d_
prs
dir
ecc
ion
_p
rste
lefo
no
s_p
rsn
aci
on
ali
da
d_
prs
nu
me
roC
ed
ula
_p
rs
Se
ria
lC
ha
ract
ers
(3
0)
Ch
ara
cte
rs (
30
)C
ha
ract
ers
(3
0)
Ch
ara
cte
rs (
30
)C
ha
ract
ers
(2
0)
Ch
ara
cte
rs (
10
)C
ha
ract
ers
(1
00
)C
ha
ract
ers
(5
0)
Ch
ara
cte
rs (
30
)C
ha
ract
ers
(1
3)
mo
vim
ien
toIn
ven
tari
o
# * o o
id_
mo
vim
ien
toIn
vfe
cha
Ho
ra_
mo
vm
oti
vo_
mo
vn
um
ero
Do
cum
en
to_
mo
v
Se
ria
lT
ime
sta
mp
Va
ria
ble
ch
ara
cte
rs (
10
00
)V
ari
ab
le c
ha
ract
ers
(1
00
)
insu
mo
Me
dic
o
# * * * *
id_
insu
mo
Me
dn
om
bre
_is
mp
rese
nta
cio
n_
ism
can
tid
ad
Act
ua
l_is
mca
nti
da
dM
inim
a_
ism
Se
ria
lV
ari
ab
le c
ha
ract
ers
(1
00
)V
ari
ab
le c
ha
ract
ers
(1
00
)In
teg
er
Inte
ge
r
cata
log
o
# * o *
id_
cata
log
od
esc
rip
cio
n_
cat
op
era
cio
n_
cat
act
ivo
_ca
t
Se
ria
lC
ha
ract
ers
(5
0)
Va
ria
ble
ch
ara
cte
rs (
20
)B
oo
lea
n
de
tall
eM
ovi
mie
nto
# *id
_d
eta
lle
Mo
vca
nti
da
d_
de
tS
eri
al
Sh
ort
in
teg
er
cata
log
oT
ipo
# * *
id_
cata
log
oT
ipo
no
mb
re_
cat
ed
ita
ble
_ca
t
Se
ria
lC
ha
ract
ers
(5
0)
Bo
ole
an
F
igu
ra 5
.1:
Es
tru
ctu
ra d
e la
ba
se
de
da
tos
SA
MW
eb
ANEXO II
PRUEBAS DE FUNCIONALIDAD
CON EL TÉCNICO INFORMÁTICO
ANEXO III
PRUEBAS DE FUNCIONALIDAD
CON EL USUARIO EXPERTO
Página 1 de 29 26/11/2015
Pruebas de funcionalidad con el usuario experto
Corrección: El texto “Pruebas de integración” corresponde a “Prueba de
funcionalidad”, lamentablemente este documento no pudo ser cambiado puesto que cuenta con una firma de aprobación. Sin embargo, esto no desmerece la validez de la prueba.
Página 2 de 29 26/11/2015
Para verificar que el estudiante nuevo no tenga una historia clínica, el usuario
debe ingresar al subsistema con el rol Enfermería y seleccionar del menú
Atención Médica Ambulatoria la opción Registrar Apertura HCL. Podrá visualizar
una tabla con los datos de HCL, CI, Nombres y el Tipo de pacientes registrados,
se observa que no existe ningún paciente de apellido Bonilla.
Página 3 de 29 26/11/2015
Pulsar el botón Validar para registrar la presentación de documentos de salud del
estudiante nuevo y a su vez registrar una apertura de historia clínica con los datos
personales del estudiante importados desde el sistema relacionado SAEW. Se
visualizan los mensajes de éxito: “Validación de documentación exitosa” y
“Apertura de historia clínica exitosa”.
El usuario debe ingresar al subsistema con el rol Enfermería y seleccionar del
menú Atención Médica Ambulatoria la opción Registrar Apertura HCL con el
objetivo de comprobar si fue registrada la apertura de la historia clínica del
estudiante nuevo al cual fue registrada su presentación de documentos de salud.
La búsqueda se la realiza a través de la digitación de parte de la cédula, hcl,
apellidos y nombres o simplemente buscando los datos en la tabla de pacientes
registrados. El registro de apertura de historia clínica puede ser modificado si
pulsa el botón Editar.
Página 4 de 29 26/11/2015
En la interfaz Información de estudiante, el usuario podrá actualizar datos
estrictamente necesarios antes de grabar los cambios con el botón Actualizar.
Para registrar una atención médica el usuario debe ingresar al subsistema con el
rol Médico y seleccionar del menú Atención Médica Ambulatoria la opción
Registrar Atención Médica. Debe Buscar un paciente digitando parte de la
cédula, HCL, apellidos o nombres y presionar el botón Buscar paciente. Buscar al
Página 5 de 29 26/11/2015
paciente Bonilla Zarate, en el resultado pulsar el botón Atender Paciente para que
los datos personales se carguen en la sección Datos del paciente.
En Detalle de atención médica, el usuario podrá seleccionar el Tipo de atención
y llenar los campos correspondientes a (Hábitos, Antecedentes y Adicionales;
Signos vitales; Motivo; Examen clínico)
Página 6 de 29 26/11/2015
Aparece también La sección orden de despacho, al crear una Nueva orden de despacho, le permite al usuario agregar insumos médicos a la atención.
Página 7 de 29 26/11/2015
La interfaz Emitir orden de despacho de insumos médicos permite pulsar el botón agregar insumos médicos.
La interfaz Agregar insumos médicos permite buscar un insumo médico y digitar la cantidad transaccional para dar clic en Añadir al detalle.
Cuando ya se añadió al detalle el usuario debe pulsar el botón Guardar orden de despacho.
Página 8 de 29 26/11/2015
Pulsar Guardar atención médica para grabar el registro. Se emite una orden de
despacho porque es un paciente de tipo Estudiante y las políticas institucionales
permiten otorgar insumos médicos.
Mensaje de éxito “Registro correcto”.
El usuario debe ingresar al subsistema con el rol Enfermería y seleccionar del
menú Manejo de inventario la opción Registrar. La interfaz Registrar despacho de
insumos médicos muestra la Fecha y el responsable de realizar los despachos.
Página 9 de 29 26/11/2015
Las órdenes pendientes se encuentran en una tabla con campos: Orden de,
Paciente, CI, Tipo de paciente, Especialidad y Médico. Cada fila de la tabla es una
orden pendiente, puede ver el detalle de la orden de medicación al pulsar el botón
Despachar.
En el detalle de la orden de medicación se visualiza los nombres y apellidos,
cedula de identidad, tipo de paciente, HCL, sexo y nacionalidad del paciente; la
especialidad y el médico por el que fue atendido y la medicación recetada. Para
despachar la orden pulsar el botón Despachar.
El usuario debe confirmar el despacho pulsando el botón Despachar.
Página 10 de 29 26/11/2015
La orden fue despachada con éxito cuando aparece el mensaje de éxito
“Despacho correcto”.
Página 11 de 29 26/11/2015
Corrección: El texto “Pruebas de integración” corresponde a “Prueba de
funcionalidad”, lamentablemente este documento no pudo ser cambiado puesto que cuenta con una firma de aprobación. Sin embargo, esto no desmerece la validez de la prueba.
Página 12 de 29 26/11/2015
El usuario deberá seleccionar el tipo de paciente e ingresar una cédula de
ciudadanía válida y pulsar en el botón Buscar, para que aparezcan los datos
personales del paciente buscado (CI, nombres y apellidos, género, fecha de
nacimiento).
Cuando se seleccionó el tipo de paciente DOCENTE, el subsistema realiza la
búsqueda en el sistema relacionado, base de datos de Talento Humano, el cual
proporcionará los datos asociados a la cédula de identidad del paciente.
Posteriormente cuando los datos de identificación son encontrados el usuario
pulsó el botón Seleccionar datos de identificación.
Página 13 de 29 26/11/2015
Para grabar la atención clínica el usuario debe pulsar el botón Guardar
Se verificó que los campos obligatorios estén llenos y se procede a grabar el
registro pulsando el botón Guardar, se observa el mensaje de éxito: Apertura de
historia clínica exitosa.
Página 14 de 29 26/11/2015
Comprobamos la apertura de la historia clínica al Digitar la cédula de identidad del
paciente ya registrado y pulsamos el botón Buscar.
EL resultado de la búsqueda fue satisfactorio.
Página 15 de 29 26/11/2015
Para registrar una atención médica el usuario debe ingresar al subsistema con el
rol Médico y seleccionar del menú Atención Médica Ambulatoria la opción
Registrar Atención Médica. Debe Buscar un paciente digitando parte de la
cédula, HCL, apellidos o nombres y presionar el botón Buscar paciente. Buscar al
paciente Alcivar Espin, en el resultado pulsar el botón Atender Paciente. Los
datos personales se cargan en la sección Datos del paciente.
En Detalle de atención médica, el usuario podrá seleccionar el Tipo de atención
y llenar los campos correspondientes a
· Hábitos, Antecedentes y Adicionales
Página 16 de 29 26/11/2015
· Signos vitales
· Motivo
· Examen clínico Aparece también La sección orden de despacho, al crear una Nueva orden de despacho, le permite al usuario agregar insumos médicos a la atención, pero al momento de Guardar la atención no le permite.
Página 17 de 29 26/11/2015
Al Guardar la atención médica le aparece el siguiente mensaje de error: “Solo se
permite despachar medicación a ESTUDIANTES o cuando se trate de una atención de tipo EMERGENCIA”. La razón es porque el tipo de paciente es un
Docente, los Docentes en una atención Normal no deben recibir medicación.
Eliminar la orden de despacho para así guardar la atención médica del paciente
de tipo Docente en una atención Normal.
Página 18 de 29 26/11/2015
Al pulsar el botón Guardar atención médica aparece el mensaje de éxito:
“Registro correcto”.
Página 19 de 29 26/11/2015
Corrección: El texto “Pruebas de integración” corresponde a “Prueba de
funcionalidad”, lamentablemente este documento no pudo ser cambiado puesto que cuenta con una firma de aprobación. Sin embargo, esto no desmerece la validez de la prueba.
Página 20 de 29 26/11/2015
Al guardar el registro del insumo médico se presenta el mensaje de éxito:
“Registro correcto”.
Verificar que el insumo médico se encuentre en la tabla de insumos médicos
registrados o Digitar parte del nombre y pulsar el botón Buscar.
Página 21 de 29 26/11/2015
El usuario debe ingresar al subsistema con el rol Enfermería y seleccionar del
menú Manejo de Inventario la opción Registrar Movimiento Inventario. Para
registrar un movimiento de inventario el usuario debe pulsar el botón de Nuevo
movimiento.
Página 22 de 29 26/11/2015
La interfaz Nuevo movimiento de inventario en la cual debe seleccionar el tipo de
transacción e ingresar el Código de documento y Motivo para pulsar el botón
Agregar insumos médicos.
En la interfaz Agregar insumo médico, el usuario debe buscar el insumo médico e
ingresar la cantidad transaccional y pulsar el botón Añadir al detalle.
En el detalle de la transacción se visualiza una tabla con el o los insumos médicos
añadidos. Clic en Guardar movimiento de inventario para grabar el registro.
Página 23 de 29 26/11/2015
Al grabar el registro del movimiento de inventario se presenta el mensaje de
éxito:”Registro correcto”.
Verificar el registro en la interfaz Registrar movimiento de inventario en la tabla
Historial de movimientos.
Página 24 de 29 26/11/2015
Para verificar el consumo del insumo médico se registra una atención médica.
Para registrar una atención médica el usuario debe ingresar al subsistema con el
rol Médico y seleccionar del menú Atención Médica Ambulatoria la opción
Registrar Atención Médica. Debe Buscar paciente digitando parte de la cédula,
HCL, apellidos o nombres y presionar el botón Buscar paciente. Pulsar el botón
Buscar paciente para que se despliegue la tabla con información de pacientes
registrados.
Página 25 de 29 26/11/2015
Pulsar Atender paciente para que los datos personales se carguen en la sección
datos del paciente.
Seleccionar el tipo de atención y completar los campos de Hábitos, antecedentes
y adicionales.
Página 26 de 29 26/11/2015
Completar los campos: Signos vitales, motivo, examen clínico, diagnóstico,
tratamiento y pulsar en Nueva orden de despacho para agregar insumos médicos.
Página 27 de 29 26/11/2015
En la interfaz Emitir orden de despacho de insumo médicos pulsar el botón
Agregar insumos médicos.
En la interfaz Agregar insumo médico digitar parte del nombre genérico para que
se busque el insumo médico
Podrá observar la cantidad actual del insumo médico y deberá ingresar la
cantidad transaccional para pulsar Añadir al detalle.
Al añadir al detalle el insumo médico se presenta en la tabla Detalle de la
transacción. Pulsar Guardar orden de despacho para grabar la orden.
Página 28 de 29 26/11/2015
Para grabar la atención médica pulsar el botón Guardar atención médica.
Mensaje de éxito “Registro correcto” que indica que la atención ha sido registrada.
Página 29 de 29 26/11/2015
Si el médico consulta desde Registrar atención médica, sección Nueva orden de
despacho >Agregar insumo médico>Buscar insumo médico podrá visualizar que
se descontó del saldo actual la cantidad de insumo médico despachado en la
atención médica. En la orden anterior se despachó 15 unidades de 1000, por
tanto el saldo actual es 985.
ANEXO IV
PRUEBAS DE CÓDIGO FUENTE CON SONARQUBE
(RESULTADOS POR EJE DE CALIDAD)
1 SAMWeb –2016
PRUEBAS DE CÓDIGO FUENTE CON SONARQUBE
(Resultados por eje de calidad)
CONTENIDO
1. ANÁLISIS DEL PROYECTO WEB ATENCIONMEDICA ............................................... 3
1.1. Errores potenciales y Estándares de codificación ..................................... 3
1.2. Duplicación ................................................................................................ 4
1.3. Arquitectura y diseño ................................................................................. 5
1.4. Complejidad .............................................................................................. 6
1.5. Comentarios .............................................................................................. 8
2. ANÁLISIS DEL PROYECTO WEB SERVICIOSATENCIONMEDICA .............................. 9
2.1. Errores potenciales y Estándares de codificación ..................................... 9
2.2. Duplicación .............................................................................................. 10
2.3. Arquitectura y diseño ............................................................................... 11
2.4. Complejidad ............................................................................................ 11
2.5. Comentarios ............................................................................................ 13
ÍNDICE DE TABLAS
Tabla 1.1: Prueba de código con SonarQube (proyecto web) – Tipos de
evidencias encontradas .......................................................................................... 4
Tabla 1.2: Prueba de código con SonarQube (proyecto web) – Complejidad
promedio por componente ..................................................................................... 7
Tabla 1.3: Prueba de código con SonarQube (proyecto web) – Archivos con más
complejidad ............................................................................................................ 8
Tabla 2.1: Prueba de código con SonarQube (proyecto servicios) – Tipos de
evidencias encontradas ........................................................................................ 10
Tabla 2.2: Prueba de código con SonarQube (proyecto servicios) – Complejidad
promedio por componente ................................................................................... 12
2 SAMWeb –2016
Tabla 2.3: Prueba de código con SonarQube (proyecto servicios) – Archivos con
más complejidad .................................................................................................. 13
ÍNDICE DE FIGURAS
Figura 1.1: Prueba de código con SonarQube (proy. web) - Deuda técnica .......... 3
Figura 1.2: Prueba de código con SonarQube (proy. web) – Errores potenciales y
estándares de codificación ..................................................................................... 4
Figura 1.3: Prueba de código con SonarQube (proy. web) – Duplicación .............. 5
Figura 1.4: Prueba de código con SonarQube (proy. web) – Arquitectura y diseño 5
Figura 1.5: Prueba de código con SonarQube (proy. web) – Componentes
analizados .............................................................................................................. 6
Figura 1.6: Prueba de código con SonarQube (proy. web) – Complejidad ............ 7
Figura 1.7: Prueba de código con SonarQube (proy. web) - Comentarios ............. 8
Figura 2.1: Prueba de código con SonarQube (proy. servicios) - Deuda técnica ... 9
Figura 2.2: Prueba de código con SonarQube (proy. servicios) – Errores
potenciales y estándares de codificación ............................................................. 10
Figura 2.3: Prueba de código con SonarQube (proy. servicios) – Duplicación .... 10
Figura 2.4: Prueba de código con SonarQube (proy. servicios) – Arquitectura y
diseño ................................................................................................................... 11
Figura 2.5: Prueba de código con SonarQube (proy. servicios) – Componentes
analizados ............................................................................................................ 11
Figura 2.6: Prueba de código con SonarQube (proy. web) – Complejidad .......... 12
Figura 2.7: Prueba de código con SonarQube (proy. servicios) - Comentarios.... 13
3 SAMWeb –2016
1. ANÁLISIS DEL PROYECTO WEB ATENCIONMEDICA
Dentro de este análisis se puede observar que notablemente se redujeron las
evidencias de 1292 a 286, bajando de 22días de deuda técnica a 6 días. La
evidencias que más se redujeron fueron las Mayores, Críticas, Menores e
Informativas, ordenadas por cantidad de evidencias tratadas, esto permitió subir la
categoría del proyecto de B a A, esto se logró en aproximadamente 13 días como
indica la 2da aplicación.
Deuda técnica en el
1er análisis Deuda técnica en el
2do análisis Figura 1.1: Prueba de código con SonarQube (proyecto web) - Deuda técnica
1.1. ERRORES POTENCIALES Y ESTÁNDARES DE CODIFICACIÓN
Como resultado del primer análisis, en la detección de errores potenciales y
estándares de codificación, se observa en la siguiente figura que los tipos de
evidencias más comunes que se tiene son: código no usado, mala práctica, de
convención y manejo de errores. Mientras que en el segundo análisis se mejoró el
aspecto de código no usado y mala práctica, se destacan las evidencias por
convención que no han sido mejoradas en su totalidad.
4 SAMWeb –2016
Tipos de error encontrados en el
1er análisis Tipos de error encontrados en el
2do análisis Figura 1.2: Prueba de código con SonarQube (proyecto web) – Errores potenciales y estándares de
codificación
Si se realiza una comparación por número de evidencias encontradas se observa
que la reducción de evidencias es notoria tal como se observa en la siguiente
tabla.
Tipo de evidencia Evidencias
1er análisis Evidencias 2do análisis
convention 408 114 bad-practice 351 26
unused 341 26
brain-overload 152 25
security 130 25
error-handling 127 23 pitfall 71 20
clumsy 56 19
cwe 754 17
misra 16 16 Tabla 1.1: Prueba de código con SonarQube (proyecto web) – Tipos de evidencias encontradas
1.2. DUPLICACIÓN
Como se puede observar la duplicación se redujo en un 2.1% del total de código
analizado, reduciendo 20 bloques de código. Se evidencia que hubo reducción de
código con 398 líneas duplicadas.
5 SAMWeb –2016
% de duplicación encontrado en
el 1er análisis % de duplicación encontrado en el
2do análisis Figura 1.3: Prueba de código con SonarQube (proyecto web) – Duplicación
1.3. ARQUITECTURA Y DISEÑO
Dentro de la estructura en la siguiente figura se indica el número de clases,
directorios, ficheros, métodos, líneas de código y sentencias que fueron
analizadas. Se indica también que el proyecto es de tipo Java 100%.
Estructura reconocida en el
1er análisis Estructura reconocida en el
2do análisis Figura 1.4: Prueba de código con SonarQube (proyecto web) – Arquitectura y diseño
Se puede observar que hubo reducción de métodos y sentencias, pero la
estructura y sus componentes se mantienen como se muestra en la siguiente
figura. Se observa que se eliminó un componente servlets (último de la lista en
1er análisis), se lo realizó puesto que no tenía ninguna funcionalidad en el
subsistema.
6 SAMWeb –2016
Componentes reconocidos en el
1er análisis Componentes reconocidos en el
2do análisis Figura 1.5: Prueba de código con SonarQube (proyecto web) – Componentes analizados
1.4. COMPLEJIDAD
Dentro de la complejidad se observa que el proyecto tiene una complejidad inicial
de 888, las mejoras han reducido 13 puntos hasta obtener 875, se concluye que
por complejidad no habido una mejora notoria.
La primera fila Complejidad/método indica por ejemplo que hay 319 métodos con
nivel aproximado de complejidad 1, 72 métodos con complejidad aproximada 2,
etc…, solo 8 métodos tienen más de 12 como nivel de complejidad, es decir
sobrepasan el límite de 10 indicado por la herramienta.
La segunda fila Complejidad/fichero indica que hubo una reducción promedio de
0.1 de complejidad en cada fichero. Se observa que 5 archivos tienen complejidad
aproximada de 30, 1 tiene aproximadamente 60 y otro más de 90 como
complejidad.
7 SAMWeb –2016
% de duplicación encontrado en el
1er análisis % de duplicación encontrado en el
2do análisis Figura 1.6: Prueba de código con SonarQube (proyecto web) – Complejidad
A continuación se muestra complejidad promedio por componente analizado.
Componente
Promedio de la
complejidad / componente
1er análisis 2do análisis
src/ec/edu/epn/atencionmedica/backingbean 41.7 40.6 src/ec/edu/epn/atencionmedica/converters 8.8 8.8 src/ec/gob/registrocivil/consultacedula 7.6 7.6 src/ec/edu/epn/saew/datosMedicosService 6.6 6.6 src/ec/edu/epn/becas/model 5.5 5.5 src/ec/gob/senescyt/titulos/webservices 4.9 4.9 src/ec/gob/bsg/accesobsgservice 4.2 4.2 src/rich/tree/test 4.0 4.0 src/ec/edu/epn/cpa/servicios 3.8 3.9 src/ec/edu/epn/atencionmedica/servlets 1.0 Eliminado
Tabla 1.2: Prueba de código con SonarQube (proyecto web) – Complejidad promedio por componente
8 SAMWeb –2016
En la siguiente tabla se muestran los archivos con más complejidad de todo el
proyecto analizado.
Archivos con más complejidad del proyecto Complejidad en el archivo
1er análisis 2do análisis
src/ec/edu/epn/atencionmedica/backingbean/RegistrarAtencionMedicaBackingBean.java
142.0 141.0
src/ec/edu/epn/atencionmedica/backingbean/GenerarReporteBackingBean.java
64.0 63.0
src/ec/edu/epn/atencionmedica/backingbean/RegistrarMovimientoInventarioBackingBean.java
52.0 52.0
src/ec/edu/epn/atencionmedica/backingbean/RegistrarAperturaHCLBackingBean.java
52.0 50.0
Tabla 1.3: Prueba de código con SonarQube (proyecto web) – Archivos con más complejidad
1.5. COMENTARIOS
Como se puede observar en la siguiente figura las se han reducido los
comentarios respecto a al código basura comentado, se puede observar que se
redujo un 8% de código comentado. Se observa que la documentación javadoc de
la aplicación desarrollada está al 62.4%.
% Comentarios encontrado en el
1er análisis % Comentarios encontrado en el
2do análisis Figura 1.7: Prueba de código con SonarQube (proyecto web) - Comentarios
9 SAMWeb –2016
2. ANÁLISIS DEL PROYECTO WEB
SERVICIOSATENCIONMEDICA
Dentro de este análisis se puede observar que notablemente se redujeron las
evidencias de 1072 a 419, bajando de 18 días de deuda técnica a 9 días 7 horas.
La evidencias que más se redujeron fueron las Mayores, Menores, Críticas e
Informativas, ordenadas por cantidad de evidencias tratadas, esto permitió subir la
categoría del proyecto de B a A, esto se logró en aproximadamente 13 días como
indica la 2da aplicación.
Deuda técnica en el
1er análisis Deuda técnica en el
2do análisis Figura 2.1: Prueba de código con SonarQube (proyecto servicios) - Deuda técnica
2.1. ERRORES POTENCIALES Y ESTÁNDARES DE CODIFICACIÓN
Como resultado del primer análisis, en la detección de errores potenciales y
estándares de codificación, se observa en la siguiente figura que los tipos de
evidencias más comunes que se tiene son: código no usado, mala práctica y de
convención (misra aplica proyectos de tipo C o C++). Mientras que en el segundo
análisis se mejoró el aspecto de código no usado y manejo de errores, se
destacan las evidencias por convención y mala práctica que no han sido
mejoradas en su totalidad.
10 SAMWeb –2016
Tipos de error encontrados en el
1er análisis Tipos de error encontrados en el
2do análisis Figura 2.2: Prueba de código con SonarQube (proyecto servicios) – Errores potenciales y estándares
de codificación
Si se realiza una comparación por número de evidencias encontradas se observa
que la reducción de evidencias es notoria tal como se observa en la siguiente
tabla.
Tipo de evidencia Evidencias 1er análisis Evidencias 2do análisis
Unused 334 53 misra 234 40 convention 221 88 bad-practice 220 99 error-handling 77 53 security 77 53 cwe 57 20 pitfall 56 19 suspicious 56 24 design 47 43
Tabla 2.1: Prueba de código con SonarQube (proyecto servicios) – Tipos de evidencias encontradas
2.2. DUPLICACIÓN
Como se puede observar la duplicación no se redujo sino más bien que subió al
4.3% del total de código analizado, aumentando las líneas de código. Esto se
debió a que por convención se debían separar algunas líneas que contenían
varias sentencias en la misma línea, y al hacerlo se sumaron varias.
% de duplicación encontrado en
el 1er análisis % de duplicación encontrado en el
2do análisis Figura 2.3: Prueba de código con SonarQube (proyecto servicios) – Duplicación
11 SAMWeb –2016
2.3. ARQUITECTURA Y DISEÑO
Dentro de la estructura en la siguiente figura se indica el número de clases,
directorios, ficheros, métodos, líneas de código y sentencias que fueron
analizadas. Se indica también que el proyecto es de tipo Java 100%.
Estructura reconocida en el
1er análisis Estructura reconocida en el
2do análisis Figura 2.4: Prueba de código con SonarQube (proyecto servicios) – Arquitectura y diseño
Se puede observar que hubo reducción de clases, archivos, métodos, líneas y
sentencias, pero la estructura y sus componentes se mantienen como se muestra
en la siguiente figura. Se observa que se eliminó un componente servlets (último
de la lista en 1er análisis), se lo realizó puesto que no tenía ninguna funcionalidad
en el subsistema.
Componentes reconocidos en el
1er análisis Componentes reconocidos en el
2do análisis Figura 2.5: Prueba de código con SonarQube (proyecto servicios) – Componentes analizados
2.4. COMPLEJIDAD
Dentro de la complejidad se observa que el proyecto tiene una complejidad inicial
de 717, las mejoras han reducido 6 puntos hasta obtener 711, se concluye que
por complejidad no habido una mejora notoria.
12 SAMWeb –2016
La primera fila Complejidad/método indica por ejemplo que hay 203 métodos con
nivel aproximado de complejidad 1, que hay 47 métodos con complejidad
aproximada 4, etc…, solo 6 métodos tienen más de 12 como nivel de complejidad,
es decir sobrepasan el límite de 10 indicado por la herramienta.
La segunda fila Complejidad/fichero indica que hubo una reducción promedio de
1.9 de complejidad en cada fichero. Se observa que 5 archivos tienen complejidad
aproximada de 20, 4 tiene aproximadamente 30 como complejidad.
% de duplicación encontrado en el
1er análisis % de duplicación encontrado en el
2do análisis Figura 2.6: Prueba de código con SonarQube (proyecto web) – Complejidad
A continuación se muestra complejidad promedio por componente analizado.
Componente
Promedio de la complejidad / componente
1er análisis
2do análisis
src/ec/edu/epn/rrhh/entities 86.0 86.0
src/ec/edu/epn/atencionmedica/entities 16.9 18.3
src/ec/edu/epn/atencionmedica/util 16.6 38.5
src/ec/edu/epn/atencionmedica/service 11.8 12.9
src/ec/edu/epn/usuario/entities 8.7 8.7
src/ec/edu/epn/rrhh/service 6.5 6.5
src/ec/edu/epn/usuario/services 3.0 3.0
Tabla 2.2: Prueba de código con SonarQube (proyecto servicios) – Complejidad promedio por
componente
13 SAMWeb –2016
En la siguiente tabla se muestran los archivos con más complejidad de todo el
proyecto analizado.
Archivos con más complejidad del proyecto Complejidad en el archivo
1er análisis 2do análisis
ConsultaReportesServiceBean.java 42.0 40.0
util.java 13.3 13.0
AtencionMedicaServiceBean.java 15.0 9.0
DetalleMovimientoServiceBean.java 7.3 7.1 Tabla 2.3: Prueba de código con SonarQube (proyecto servicios) – Archivos con más complejidad
2.5. COMENTARIOS
Como se puede observar en la siguiente figura las se han reducido los
comentarios respecto a al código basura comentado, se puede observar que se
redujo un 12.8% de código comentado. Se observa que la documentación javadoc
de la aplicación desarrollada está al 15.3%.
% Comentarios encontrado en el
1er análisis % Comentarios encontrado en el
2do análisis Figura 2.7: Prueba de código con SonarQube (proyecto servicios) - Comentarios
Para ver información más detallada sobre las evidencias encontradas, reglas
aplicadas, tipos de evidencias, módulos y archivos analizados, y las severidades
tratadas Vea el ANEXO DIGITAL D17 - Pruebas de código fuente (Detalle de
evidencias).
ANEXO V
CERTIFICADO DE ACEPTACIÓN
