SISTEMA AUTOMATIZADO PARA GESTIÓN DE MANTENIMIENTO DE EQUIPOS MÉDICOS EN LA FUNDACIÓN CLÍNICA INFANTIL CLUB NOEL UTILIZANDO HERRAMIENTAS DE SOFTWARE LIBRE: MÓDULO DE INGENIERÍA INFORMÁTICA JOHN ALEJANDRO MURILLO HURTADO UNIVERSIDAD AUTÓNOMA DE OCCIDENTE FACULTAD DE INGENIERÍA DEPARTAMENTO DE CIENCIAS DE LA INFORMACIÓN PROGRAMA DE INGENIERÍA INFORMÁTICA SANTIAGO DE CALI 2012
176
Embed
SISTEMA AUTOMATIZADO PARA GESTIÓN DE MANTENIMIENTO DE …
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
SISTEMA AUTOMATIZADO PARA GESTIÓN DE MANTENIMIENTO DE EQUIPOS MÉDICOS EN LA FUNDACIÓN CLÍNICA INFANTIL CLUB NOEL
UTILIZANDO HERRAMIENTAS DE SOFTWARE LIBRE: MÓDULO DE INGENIERÍA INFORMÁTICA
JOHN ALEJANDRO MURILLO HURTADO
UNIVERSIDAD AUTÓNOMA DE OCCIDENTE FACULTAD DE INGENIERÍA
DEPARTAMENTO DE CIENCIAS DE LA INFORMACIÓN PROGRAMA DE INGENIERÍA INFORMÁTICA
SANTIAGO DE CALI 2012
2
SISTEMA AUTOMATIZADO PARA GESTIÓN DE MANTENIMIENTO DE EQUIPOS MÉDICOS EN LA FUNDACIÓN CLÍNICA INFANTIL CLUB NOEL
UTILIZANDO HERRAMIENTAS DE SOFTWARE LIBRE: MÓDULO DE INGENIERÍA INFORMÁTICA
JHON ALEJANDRO MURILLO
Pasantía Institucional para optar por el título de profesional en Ingeniero de Informático y Sistemas
Director ING. ORLANDO ARBOLEDA
Ingeniero de Sistemas
UNIVERSIDAD AUTÓNOMA DE OCCIDENTE
FACULTAD DE INGENIERÍAS DEPARTAMENTO DE CIENCIAS DE LA INFORMACIÓN
PROGRAMA DE INGENIERÍA INFORMÁTICA Y DE SISTEMAS SANTIAGO DE CALI
2012
3
Nota de aceptación
Aprobado por el Comité de Grado en cumplimiento de los requisitos exigidos por la Universidad Autónoma de Occidente para optar al título de Profesional en Ingeniería Informática y de Sistemas. JESÚS ANTONIO LEMOS Jurado OLMEDO ARCILA _________________________________
3. ANTECEDENTES ............................................................................................. 18 3.1 SOFTWARE DE MANTENIMIENTO DE EQUIPOS ....................................... 18 3.1.1 SMACOR®. ................................................................................................. 18 3.1.2 MS2000™. ................................................................................................... 18
3.1.3 MP. .............................................................................................................. 19 4. MARCO TEÓRICO ........................................................................................... 20 4.1 EL NÚCLEO DEL SISTEMA DE GESTIÓN DE MANTENIMIENTO COMPUTARIZADO (CMMS) ................................................................................ 20 4.2 INVENTARIO DE EQUIPOS ........................................................................... 21 4.3 MANTENIMIENTO PREVENTIVO .................................................................. 21 4.4 MANTENIMIENTO PREVENTIVO ORIENTADO A RIESGOS ...................... 21
4.5 CÁLCULO DEL NIVEL DE PRIORIDAD ....................................................... 22 4.6 ÍNDICE DE MANTENIMIENTO PREVENTIVO E INSPECCIONES (IPM)...... 24
5
4.7 MANTENIMIENTO CORRECTIVO ................................................................. 25 4.8 ORDEN DE TRABAJO ................................................................................... 25
4.9 ELABORACIÓN DEL PROGRAMA DE MANTENIMIENTO ANUAL ............ 26 4.10 PROCEDIMIENTO PARA LA INSPECCIÓN Y EL MANTENIMIENTO PREVENTIVO. ...................................................................................................... 27
4.11 INDICADORES DE GESTIÓN DE MANTENIMIENTO PREVENTIVO ......... 27 4.11.1 Indicador de disponibilidad. ................................................................... 27 4.11.2 Eficacia del mantenimiento correctivo. .................................................. 28
4.11.3 Indicador de falsas solicitudes. .............................................................. 28 4.12 IMPLEMENTACIÓN DE GESTIÓN DE EQUIPOS MÉDICOS ..................... 29 4.13 LA GESTIÓN AUTOMATIZADA DE MANTENIMIENTO PARA LOS EQUIPOS MÉDICO-HOSPITALARIO .................................................................. 29
5. OBJETIVOS ..................................................................................................... 30 5.1 OBJETIVO GENERAL ................................................................................... 30
5.2 OBJETIVOS ESPECÍFICOS .......................................................................... 30 6. METODOLOGÍA ............................................................................................... 31 6.1 PROCESO UNIFICADO RACIONAL (RUP- RATIONAL UNIFIED PROCESS) ........................................................................................................... 31 6.1.1 Modelo de requisitos. ................................................................................ 31 6.1.2 Modelo de análisis. .................................................................................... 32 6.1.3 Modelo de Diseño. ..................................................................................... 33
6.1.4 Modelo de Implementación. ...................................................................... 34 6.1.5 Modelo de Pruebas. ................................................................................... 34
6
7. DESARROLLO DEL PROYECTO .................................................................... 35 7.1 MODELADO DEL NEGOCIO ........................................................................ 35 7.1.1 Descripción del negocio y su actividad. .................................................. 35 7.1.2 Actores del negocio…………………………………………………………….35 7.1.3 Casos de uso del negocio ......................................................................... 37 8. ESPECIFICACIÓN DE REQUERIMIENTOS DE SOFTWARE ......................... 39 8.1 REQUERIMIENTOS FUNCIONALES ........................................................... 39 8.2 ESPECIFICACIONES SUPLEMENTARIAS (NO FUNCIONALES) ............... 42
8.3 REQUERIMIENTOS DE INFRAESTRUCTURA ............................................. 42
8.4 DEFINICIÓN DE ACTORES ........................................................................... 43
9. LISTADO DE CASOS DE USO ........................................................................ 44 9.1 MATRIZ DE CASOS DE USO ........................................................................ 45
9.2 DIAGRAMA RELACIONAL DE CASOS DE USO ......................................... 46 9.3 DESCRIPCIÓN O GUIONES DE CASOS DE USO ....................................... 47 10. DIAGRAMA DE CLASES ............................................................................... 54 10.1 DIAGRAMA DE CLASES GENERAL .......................................................... 56
11. DIAGRAMA DE SECUENCIA ...................................................................... 576 12. PATRÓN DE ARQUITECTURA ................................................................... 598 12.1 DIAGRAMA DE DESPLIEGUE MVC ........................................................... 58
7
13. MODELADO DE DATOS................................................................................ 59 14. MODELO RELACIONAL DE DATOS .......................................................... 610 15. IMPLEMENTACIÓN ..................................................................................... 621 15.1 LENGUAJE DE PROGRAMACIÓN ........................................................... 621
15.2 BASE DE DATOS ..................................................................................... 621
15.2.1 Diagrama de componentes. .................................................................. 632 15.3 ARQUITECTURA DE SOFTWARE ........................................................... 643 15.3.1 Diagrama de despliegue……………………………………………………..63 16. PRUEBAS .................................................................................................... 665 17. CONCLUSIONES ........................................................................................... 69
Pág. Cuadro 1. Asignación de peso por criterios ..................................................... 23
Cuadro 2. Matriz de casos de uso ..................................................................... 45
Cuadro 3. Guion registrar equipo ...................................................................... 47 Cuadro 4. Guion registrar hoja de vida ............................................................. 50 Cuadro 5. Prueba funcional – validaciones y verificaciones al caso de uso registrar equipo – Módulo de inventarios. ................................................ 66 Cuadro 6. Diseño de caso de prueba Nombre No. 01 – caso de uso registrar equipo. .................................................................................................. 67
Cuadro 7. Diseño de caso de prueba ubicación No. 09 – caso de uso registrar equipo. .................................................................................................. 67 Cuadro 8. Diseño de caso de prueba función del equipo No. 17 – caso de uso registrar equipo. ..................................................................................... 68 Cuadro 9. Diseño de caso de prueba Aplicación clínica No. 19 – caso de uso registrar equipo. .......................................................................................... 68 Cuadro 10. Diseño de caso de prueba para intervalo IPM No. 29 – caso de uso registrar equipo. ..................................................................................... 69
9
LISTA DE FIGURAS
Pág. Figura 1. Intervalos entre mantenimientos preventivos e inspecciones recomendados por ECRI. ................................................................................... 24
Figura 2. Modelo básico de una orden de trabajo ............................................ 26 Figura 3. Dependencia de los distintos modelos del proceso del software del modelo de requisitos. ................................................................... 31 Figura 4. La estructura del modelo de análisis. ............................................... 33 Figura 5. Organigrama Fundación Clínica Infantil Club Noel. ......................... 36 Figura 6. Actores del negocio ............................................................................ 36 Figura 7. Diagrama de casos de uso del negocio. ........................................... 38 Figura 8. Diagrama relacional de casos de uso. .............................................. 46
Figura 9. Diagrama de clases caso de uso N 2. Registrar equipo .................. 54 Figura 10. Diagrama de clases caso de uso N.10 Registrar hoja de vida. ..... 55 Figura 11. Diagrama de clases general. ............................................................ 56
Figura 12. Diagrama de secuencia caso de uso N.2. Registrar equipo .......... 57 Figura 13. Diagrama de secuencia caso de uso N.10. Registrar hoja de vida ....................................................................................................................... 58 Figura 14. Diagrama de despliegue modelo vista controlador ....................... 59 Figura 15. Modelo entidad relación ................................................................... 60 Figura 16. Modelo relacional de datos .............................................................. 61
10
Figura 17. Diagrama de componentes. ............................................................. 64 Figura 18. Diagrama de despliegue ................................................................... 65
GLOSARIO FONDO DE TIEMPO: es el intervalo o periodo de tiempo que el personal técnico puede dedicar al mantenimiento preventivo, se recomienda planificar alrededor del 35% del fondo de tiempo del personal técnico al mantenimiento preventivo. INDICADORES DE GESTIÓN: Es el mecanismo o forma de evaluar cómo se comporta el proceso de gestión de mantenimiento. INSPECCIÓN DE MANTENIMIENTO PREVENTIVO (IPM): el índice de mantenimiento preventivo corresponde a las intervenciones de mantenimiento que se le deben realizar al equipo médico en un periodo de tiempo de un año. MANTENIMIENTO PREVENTIVO (MP): Describe las diferentes tareas de mantenimiento que se le realizan sobre un equipo, tales como ajustes, comprobaciones, calibraciones, sustituciones de componentes, limpieza, etc. NIVEL DE PRIORIDAD (PI): Corresponde al tipo de clasificación de forma numérica que se le da a un equipo médico, la cual determina si el equipo debe ser incluido en el inventario para mantenimiento o en el inventario de mantenimiento planificado del entorno. ORDEN DE TRABAJO (OT): Es un formulario o documento a través del cual se lleva el control del trabajo de mantenimiento de todos los equipos médicos y hospitalarios. UNIDAD DE CUIDADOS INTENSIVOS (UCI): Es el área hospitalaria que proporciona medicina intensiva.
11
RESUMEN El presente documento muestra el proceso y metodología que se llevó a cabo para desarrollar el proyecto “Sistema automatizado para gestión de mantenimiento de equipos médicos en la Fundación Clínica Infantil Club Noel utilizando herramientas de software libre”. El proyecto se realizó para la empresa de salud Club Noel, teniendo en cuenta todas las necesidades propuestas por la empresa, la más relevante es la falta de presupuesto, debido a estas limitaciones económicas que enfrenta la clínica el componente de software está desarrollado con herramientas de software libre. El software se desarrolló como una aplicación de escritorio por petición del usuario, debido a que todo el proceso de gestión de equipos médicos corre por cuenta de él, registro de equipos médicos en el inventario, las hojas de vida de los equipos médicos y las órdenes de trabajo son diligenciadas únicamente por él. Para dar cumplimiento a la presente pasantía se propone desarrollar un CMMS (Sistema de gestión de mantenimiento computarizado), cuya finalidad es llevar un control organizado de la gestión de mantenimiento de los equipos médicos El CMMS está compuesto por los módulos de plan de mantenimiento preventivo anual, órdenes de trabajo, hojas de vida de equipos médicos, indicadores de gestión, inventarios (físico-funcional, mantenimiento preventivo, mantenimiento entorno y la inspecciones de mantenimiento preventivo (IPM)). Durante el desarrollo se puso en práctica los conocimientos aprendidos durante la carrera, principalmente en las asignaturas de ingeniería de software y base de datos. Palabras Claves: Software, mantenimiento preventivo, mantenimiento correctivo, Indicadores de gestión, equipos médicos
12
INTRODUCCIÓN
El mantenimiento preventivo de los equipos biomédicos se define como el conjunto de acciones técnicas administrativas que se realizan para el cuidado e inspección sistemática de un equipo o instrumento con el propósito de mantenerlo en buen estado de funcionamiento, evitar y detectar fallas menores antes que estas se conviertan en mayores. Debido a la gran cantidad de equipos médicos con los que cuenta la Fundación Clínica Infantil Club Noel y la importancia del buen funcionamiento de estos para la atención y el servicio que ofrece la clínica a sus pacientes, se hace necesario desarrollar una herramienta informática que le permita a la organización llevar un control organizado del inventario de equipos médicos y de la forma en que se debe realizar la gestión de mantenimiento de estos, para así evitar posibles riesgos de paralización prolongada y discontinuidad del servicio. Por estos motivos se debe desarrollar un CMMS (sistema de gestión de mantenimiento computarizado) utilizando herramientas de software libre denominado ManPre (mantenimiento preventivo); que le permita a la organización poder mantener un control organizado sobre la gestión de mantenimiento de equipos médicos; que a su vez le ayude a reducir costos y a mejorar la calidad del servicio. El sistema está realizado con herramientas de software libre por petición del usuario debido a las limitaciones económicas que enfrenta la clínica las cuales no le permiten pagar licencia por software propietario. El sistema está compuesto por los módulos de inventario físico-funcional, inventario para mantenimiento preventivo, inventario de mantenimiento de entorno, hojas de vida, ordenes de trabajo, indicadores de gestión y el plan anual de mantenimiento preventivo los cuales definen una estructura organizada para llevar a cabo un opimo mantenimiento preventivo de los equipos médicos. El sistema permitirá realizar consultas, búsquedas y modificaciones sobre los equipos médicos que se encuentran disponibles en el inventario, también permite saber cuáles se encuentran asignados en el inventario para mantenimiento preventivo y cuáles no, con esta información el sistema asigna los equipos en un
13
plan de mantenimiento preventivo anual, que le permitirá al usuario seleccionar el mes y el día en que se le debe realizar el mantenimiento al equipo.
14
1. PLANTEAMIENTO DEL PROBLEMA Actualmente la fundación clínica infantil Club Noel cuenta con un total de 173 equipos médicos, distribuidos en las siguientes áreas: laboratorio clínico, fisioterapia, terapia, odontología, sala San Roque, sala Mariana, sala Luis H., sala de pensionados, urgencias, rayos X, imagenología, administración quirófano, recuperación quirófano, sala quirófano 1, 2, 3 y 4; cirugía, dermatología, audiología, otorrinolaringología, oftalmología, endocrinología, salas hospitalización y lavandería. Por otro lado, la institución cuenta con un proyecto a corto plazo el cual consiste en la construcción de una UCI (unidad de cuidados intensivos), que a su vez estará conformada por 12 cubículos, en donde estarán ubicadas un total de 8 camas (4 pediátricas y 4 de cuidados intensivos intermedios). En cuanto a la dotación de equipos médicos, la UCI contará con 4 monitores de presión no invasiva, 4 monitores multípara- métricos, 4 ventiladores, 4 bombas de infusión, 4 bombas de alimentación y cada cubículo tendrá su propio suministro de oxígeno, bomba de succión y aire medicinal. Dada la necesidad de automatizar la gestión de mantenimiento preventivo y correctivo de los equipos médicos de diferente clasificación y ubicación (áreas) dentro de la fundación clínica infantil Club Noel; se requiere tener un buen conocimiento de la información actual de los equipos médicos que se encuentra documentada en el inventario técnico funcional; así como las órdenes de trabajo, la frecuencia de mantenimiento y la inspección para el mantenimiento preventivo (procedimientos) que se le hace a cada uno de estos. El mantenimiento preventivo que se realiza a cada uno de estos equipos resulta ser un trabajo muy dispendioso debido a que la hoja de vida y los historiales de cada uno de estos se encuentran almacenados y archivados en papel y dependen de una sola persona; debido a esto el jefe de mantenimiento ha tenido que enfrentar situaciones en las que los equipos fallan por necesidad de mantenimiento y no se cuenta a la mano con las herramientas necesarias para repararlos; esta situación conlleva a que muchos equipos que deben estar funcionando para la óptima atención de los clientes no se estén usando por que se encuentran dañados o no funcionan de la manera correcta, afectando la calidad del servicio del hospital.
15
¿Es posible la construcción de un software para la Fundación Clínica Infantil Club Noel que permita gestionar el mantenimiento de equipos médicos mediante el uso de herramientas de software libre?
16
2. JUSTIFICACIÓN
Un CMMS (Computarized Maintenance Management Systems), puede ser considerado como una herramienta útil para suministrar soporte tecnológico1. En Colombia se puede ver que en este momento la aplicación de software o CMMS presenta algunos inconvenientes tales como que el número de personas relacionadas con la gestión mantenimiento realmente es muy bajo, los costos de adquisición de estos software son elevados y además estos están diseñados para atender medianas y grandes empresas, razón por la cual están dirigidos a ser alimentados y retroalimentados por diferentes personas a diferentes niveles jerárquicos (cuadros operativos, supervisores, jefes de área, planeadores de mantenimiento, jefes ó gerentes de mantenimiento y por cuadros directivos). Teniendo en cuenta que la Fundación Clínica Infantil Club Noel es una institución prestadora de servicios de salud pediátricos, y que el principal soporte para la prestación de los servicios está definido en el buen funcionamiento de los equipos médicos y estos cuentan con una programación de mantenimiento preventivo bajo, se hace necesario el desarrollo de un aplicativo de software (CMMS) utilizando herramientas de software libre que permita sistematizar el proceso de gestión de mantenimiento, reducir las fallas en los equipos y la discontinuidad del servicio. Con la obtención del CMMS desarrollado la clínica mejora un aspecto muy importante y es que la información ya no va a estar centralizada en única persona, sino que toda la información va a estar centralizada en una base de datos, a la cual se puede acceder mediante el uso de la aplicación. Con la implementación de un CMMS también se mejora la forma en que se realiza el mantenimiento de los equipos médicos el cual resulta ser un trabajo dispendioso porque toda la información queda almacenada en medios físicos, tales como, como papel, carpetas y archivadores. Toda esta información queda almacenada en el CMMS, reduciendo los costos de papelería los cuales se ven reflejados en los indicadores de gestión.
1 TFC Gestión Integral del Mantenimiento [en línea]. Pedro Daniel Carrillo Gordillo. Julio de 2008.
Disponible en Internet: http://www.scribd.com/doc/4184016/TFC-Gestion-Integral-del-Mantenimiento.
Además el sistema cuenta con indicadores de gestión que le permiten al usuario observar distintos indicadores tales como indicador de costos hora, costos de mantenimiento y costos de eficiencia que permiten realizar ajustes y mejoras en la realización del mantenimiento
18
3. ANTECEDENTES
El CMMS es una aplicación informática que surge debido a la necesidad empresarial de organizar y controlar las deficiencias que hay en la gestión de mantenimiento. Existen diversas herramientas de software que ayudan a las organizaciones a mejorar la forma en que se realiza la gestión de mantenimiento, pero la gran mayoría son licenciados y se debe pagar por su licencia. La Fundación Clínica Infantil Club Noel no cuenta con los suficientes recursos económicos para la adquisición de software propietario, por esto, se debe desarrollar el aplicativo de software utilizando herramientas de software libre. 3.1 SOFTWARE DE MANTENIMIENTO DE EQUIPOS Dentro de los software más importantes para la gestión de mantenimiento de equipos médicos orientado a riesgos están: 3.1.1 SMACOR®. Su función es automatizar el mantenimiento en una red hospitalaria o en un hospital individual. Dentro de sus características más relevantes esta la capacidad de planificar el mantenimiento preventivo y las inspecciones, de manera anual, mensual, semanal; de llevar el control del inventario de todo el equipamiento, de emitir órdenes de trabajo preventivas y correctivas. Además genera documentos tales como: procedimientos de mantenimientos, pruebas de aceptación, entre otros; además de facilitar los tediosos cálculos de indicadores técnico-económicos y de eficiencia de la gestión2. 3.1.2 MS2000™. MS2000 ™ es un Sistema de Administración de Mantenimiento por Computadora (SAMC) que utiliza términos industriales estándares, estructuras de archivos y componentes que le dan las herramientas necesarias para tener un control completo del mantenimiento en su compañía. MS2000 está específicamente diseñado para ayudarlo a organizar sus actividades de
2 GUTIERREZ SENRA, José Alain y CRISTO BROCHE, Elier. Sistema de Gestión Tecnológica
Hospitalaria V 1.0. [En línea]. La Habana: Centro de Bioingeniería del Instituto superior Politécnico José Antonio Echeverría. [Consultado 24 de Febrero de 2010]. Disponible en Internet: http://www.vision.ime.usp.br/~elier/sgt.pdf
mantenimiento, como son la simplificación de las tareas de administración, y la maximización de la eficiencia y productividad del mantenimiento de su compañía3. 3.1.3 MP. Es un software profesional para control y administración del mantenimiento de que ayuda a documentar y mantener organizada toda la información que requiere el departamento de mantenimiento de su organización. Permite ser implementado en cualquier lugar donde haya equipos médicos, maquinaria e instalaciones sujetas a mantenimiento.
Industrias
Constructoras
Hospitales
Empresas de servicios El MP informa sobre los trabajos de mantenimiento que se deben realizar y una vez que se realizan, el MP reprograma la fecha próxima para cuando deban volver a realizarse, ajustando automáticamente los calendarios de mantenimiento. Beneficios que otorga la utilización de este software:
Reduce paros imprevistos
Evita accidentes
Incrementa la vida útil de los equipos
Reduce costos por mantenimiento preventivo El MP es un software propietario, se comercializa en 3 diferentes versiones, básico, profesional y empresarial, lo que lo hace adaptable a las pequeñas y grandes empresas. Puede trabajar en modo monousuario o en red lo que hace que su precio incremente en el modo red dependiendo de la cantidad de estaciones de trabajo. El precio de este software oscila entre los $1,346 usd para un sistema monousuario versión básico y los $15,180 usd para una red con 50 estaciones de trabajo en la versión profesional4.
3 RANGEL FRÍAS, Raúl. MS2000: Sistema de Administración de Mantenimiento por Computadora
[en línea]. Monterrey: RQ Consultoría Técnica. [Consultado 25 de Febrero de 2010]. Disponible en Internet: www.rqct.com/download/Guia%20Rapida%20MS2000.doc 4 Solución integral para control y administración del mantenimiento. MP [consultado el 11 de
noviembre de 2011]. Disponible en internet: http://www.mpsoftware.com.mx/es/downloads/Informacion%20general.pdf
Las tecnologías de información y comunicación constantemente cambian. El mercado de tecnología CMMS (sistema de gestión de mantenimiento computarizado) es relativamente pequeño tanto a nivel internacional como nacional5. En consecuencia, los cambios ocurren de una forma más lenta. Los sistemas de gestión de mantenimiento computarizados conducen en la actualidad al desarrollo de infraestructura de comunicación inalámbrica en instituciones de cuidado de salud, pero una vez la infraestructura inalámbrica este en su lugar, los Departamentos de Ingeniería Clínica y los vendedores de sistemas de gestión de mantenimiento computarizados serán capaces de obtener la ventaja de ello y ofrecer muchas más aplicaciones portables y avanzadas. Hasta entonces, nuevos desarrollos serán mejorados continuamente en software además de que se apoyarán decisiones innovadoras de herramientas para ayudar a convertir la gran acumulación de datos coleccionada en información útil para la gestión de la tecnología6. 4.1 EL NÚCLEO DEL SISTEMA DE GESTIÓN DE MANTENIMIENTO COMPUTARIZADO (CMMS) El núcleo de un sistema de gestión de mantenimiento de un equipo comprende el inventario del equipo, reparación e historia de mantenimiento, y una orden de control de trabajo. El inventario del equipo es un archivo automatizado de todos los datos sobre el equipo que ha sido incluido en el CMMS. La historia de reparación y mantenimiento es un registro de cada reparación y evento de mantenimiento, independiente de quien inició el evento y quien proporcionó el servicio. La orden de control de trabajo es usada para despachar y para priorizar la solicitud de trabajo, para programar inspecciones periódicas y el mantenimiento preventivo (MP), y para rastrear el estado programado pendiente y órdenes de trabajo no programadas7.
5 TFC Gestión Integral del Mantenimiento, Op. Cit., p.45.
6 Ibíd.
7 DYRO F, Joseph. Clinical Engineering HandBook. 1ª Edición. Estados Unidos: Elsevier Academic
Press, 2004. P. 122.
21
4.2 INVENTARIO DE EQUIPOS En el típico CMMS, cuando nuevos equipos son recibidos un técnico de equipos biomédicos (BMET) se asegura que el orden este completo; inspecciona y prueba el dispositivo de acuerdo con el manual de servicio que es proporcionado como parte de la orden; y basado en el tipo de dispositivo la organización incluye un criterio, y las políticas de la organización de la ingeniería clínica, determina si el dispositivo necesita ser incluido en el programa de gestión de equipos. Si esto se hace, el BMET entonces ingresa el nuevo artículo dentro de la base de datos (o completa un formulario de modo que un dato de entrada empleado puede ser ingresado) así como se completa inspección entrante de orden de trabajo8. 4.3 MANTENIMIENTO PREVENTIVO El mantenimiento preventivo de los equipos biomédicos se debe considerar un proceso, el cual tiene como objetivo principal mantener en buen estado de funcionamiento los equipos o instrumentos, se define también como el conjunto de acciones técnicas administrativas que se realizan para el cuidado e inspección sistemático de un equipo o instrumento con el propósito de mantenerlo en buen estado de funcionamiento, evitar y detectar fallas menores antes que estas se conviertan en mayores. La aplicación del mantenimiento preventivo permite que los equipos puedan ser usados de manera permanente o cuando sea requerido su uso para un procedimiento específico eliminando los posibles riesgos de paralización prolongada, discontinuidad del servicio y la falta de seguridad al paciente en el entorno hospitalario. El programa de mantenimiento preventivo se basa en la ejecución periódicas de actividades tales como inspección semanales, diarias, cambio de accesorios, repuestos, componentes o algún otro tipo de elemento que permita que el equipo funcione eficientemente. 4.4 MANTENIMIENTO PREVENTIVO ORIENTADO A RIESGOS El inventario para el mantenimiento orientado a riesgo se basa en la asignación de prioridad a partir de una evaluación integral de cada equipo.
8 Ibíd., p. 128.
22
Puede haber equipos que por su bajo nivel de riesgo no se incluyen en el inventario para el mantenimiento y son atendidos durante la inspección o mantenimiento programado a su entorno, a solicitud del usuario o en mantenimiento correctivo solamente. La experiencia demuestra que si el inventario no se hace para los equipos significativos, este se hace inmanejable o ineficiente. Se recomienda dar prioridad al mantenimiento del equipo basándose en criterios de riesgo. 4.5 CÁLCULO DEL NIVEL DE PRIORIDAD Los criterios requeridos para asignar el nivel de prioridad a un equipo médico de la clínica u hospital son los siguientes:
Función del equipo (E): El papel del equipo en el cuidado del paciente.
Aplicación clínica (A): Considera los resultados sobre el paciente o usuario ante una falla del equipo; el riesgo físico asociado con la aplicación clínica.
Requisitos del mantenimiento (M): Varían con el tipo de equipo; bien sea por su complejidad, funcionamiento y por la seguridad que este le brinda al paciente.
Incidentes del equipo/ Historia de fallas (F): Se evalúa por los usuarios del equipo, gerentes de la sección y personal del Departamento de Ingeniería Clínica, a partir de una programación a fin de suministrar una base de datos para determinar tendencias y requisitos.
El nivel de prioridad Pi se puede calcular a partir del siguiente cuadro como: Pi = E+ A+M+F
23
Cuadro 1. Asignación de peso por criterios
Por la función del equipo Rango numérico
Soporte de Vida 9 Terapia − Critico 8
Diagnóstico − Critico 7 Terapia − Esencial 6
Diagnostico − Esencial 5 Terapia − Auxiliar 4
Diagnóstico − Auxiliar 3 Terapia − Misceláneas 2
Diagnóstico/Otros − Misceláneas 1 Aplicación Clínica A
Puede producir la muerte al paciente 7 Puede producir daño al paciente u operador 6
Terapia inapropiada o falso diagnóstico 5 Interrumpe el servicio al paciente 4
Riesgo mínimo 3 Sin riesgo significante 1
Requerimientos de Mantenimiento M Extensivo 3 Promedio 2 Mínimo 1
Historia de fallas F 0 - 1 1 2 - 3 2 4 – 5 3 6 – 7 4
8 o más 5 Fuente: RODRÍGUEZ DENIS, Ernesto B. “Ingeniería Clínica” SOCBIO. Ciudad de La Habana, Cuba. 2007. p. 71
Todo equipo con una calificación de 11 o más se incluirá en el inventario de mantenimiento preventivo de equipos médicos. Equipos con una calificación entre 10 y 3 podrán incluirse en el inventario de mantenimiento del entorno de acuerdo a la propia experiencia del Departamento de Ingeniería Clínica9.
9 RODRÍGUEZ DENIS, Ernesto B. “Ingeniería Clínica” SOCBIO. Ciudad de La Habana, Cuba.
2007. p. 75
24
4.6 ÍNDICE DE MANTENIMIENTO PREVENTIVO E INSPECCIONES (IPM). El índice de mantenimiento preventivo corresponde a las intervenciones de mantenimiento que se le deben realizar al equipo médico en un periodo de tiempo de un año10. Figura 1. Intervalos entre mantenimientos preventivos e inspecciones recomendados por ECRI.
Fuente: RODRÍGUEZ DENIS, Ernesto B. “Ingeniería Clínica” SOCBIO. Ciudad de La Habana, Cuba. 2007. p. 73.
10
DYRO F, Op. Cit., p.135.
25
4.7 MANTENIMIENTO CORRECTIVO El mantenimiento correctivo es el trabajo realizado sobre un equipo o parte para restaurar su estado operacional. No es planificado, se lleva a cabo a partir del reporte de orden de trabajo que hace el usuario, operador del equipo o personal que realiza el mantenimiento programado11. 4.8 ORDEN DE TRABAJO Es el documento a través del cual se lleva control del trabajo de mantenimiento que nos permiten: Documentar las actividades de mantenimiento preventivo y correctivo; Llevar un control de las actividades del Departamento de Mantenimiento; Evaluar la eficiencia del Departamento de Mantenimiento; Elaborar informes. Un formato básico de una OT (orden de trabajo) consta de tres partes: la primera recoge la solicitud de servicio, centro de costo, fecha y hora, nombre y ubicación del equipo, problema que presenta y persona que emite la orden. La segunda parte se llena por el técnico encargado y refleja su nombre, la hora en que se comienza atender la solicitud, identifica al equipo con su código y número de inventario y las acciones llevadas a cabo para restablecer el funcionamiento normal del equipo. La tercera parte recoge la fecha y hora de la entrega al servicio del equipo de alta, la persona que lo recibe, la cual puede reflejar cualquier observación que considere pertinente. De esta manera la orden de servicio debe permitir calcular, el tiempo de respuesta, el tiempo de la intervención y el tiempo total de cambio de estado, debe servir además para calcular el costo de servicio y relacionarlo con un centro de costo y reflejar la historia de cada equipo médico. 12
11
Ibíd., p. 129. 12
Ibíd., p. 130.
26
Figura 2. Modelo básico de una orden de trabajo
Fuente: RODRÍGUEZ DENIS, Ernesto B. “Ingeniería Clínica” SOCBIO. Ciudad de La Habana, Cuba. 2007. p. 77.
4.9 ELABORACIÓN DEL PROGRAMA DE MANTENIMIENTO ANUAL La carga para el plan de mantenimiento preventivo, se determina a partir del inventario de mantenimiento y la frecuencia de mantenimiento e inspecciones de cada equipo. Una vez determinado el número de horas a planificar en el año, se compara con el fondo de tiempo que el personal técnico puede dedicar al mantenimiento preventivo. Un criterio práctico, para organizaciones con poca experiencia, es planificar alrededor del 35 % del fondo de tiempo del personal técnico al mantenimiento preventivo. En el caso que el 35 % del fondo de tiempo del personal técnico no sea suficiente para cubrir el plan de mantenimiento preventivo, deben considerarse otras alternativas tales como el contrato de servicios externos, aumentar el personal, el pago de tiempo extra o retirar los equipos de más bajo índice de prioridad del inventario de mantenimiento.
27
Una vez que se logra un balance entre la carga planificada y los recursos humanos y materiales disponibles, se hace la planificación anual. Es recomendable la planificación semanal y organizar el trabajo de manera tal, que las tareas de mantenimiento preventivo se inicien en los primeros días de cada semana, así si se producen órdenes de correctivo con prioridad superior, éstas pueden ser atendidas y después se continúa con el preventivo planificado. No se recomienda iniciar trabajos de preventivos al final de la jornada semanal, si estos pudieran comprometer la disponibilidad del equipo durante el fin de semana13. 4.10 PROCEDIMIENTO PARA LA INSPECCIÓN Y EL MANTENIMIENTO PREVENTIVO. Un procedimiento para la inspección y el mantenimiento preventivo establece y describe las diferentes tareas de mantenimiento que se realizan sobre un equipo, tales como ajustes, comprobaciones, calibraciones, sustituciones de componentes, limpieza, etc. El procedimiento debe incluir adicionalmente la frecuencia entre intervenciones, tiempo estimado de las intervenciones y de igual manera puede diferenciar por tipo de intervenciones (mayor, menor ó prueba de aceptación, etc.) en función de la cantidad y profundidad de las tareas de mantenimiento que se lleven a cabo, pudiendo diferir en tiempos totales de ejecución y frecuencias. Estos procedimientos se pueden obtener a partir del propio fabricante, agencias especializadas (ECRI, AAMI, etc.), a partir de la propia experiencia del hospital o como una combinación de las fuentes mencionadas. 14 4.11 INDICADORES DE GESTIÓN DE MANTENIMIENTO PREVENTIVO 4.11.1 Indicador de disponibilidad. Es la propiedad de un sistema que representa la continuidad del servicio prestado, se define como la probabilidad de que el componente o sistema se encuentre apto o listo para operar en el momento que sea requerido. El indicador se refiere al cumplimiento de la disponibilidad (100 % de la operatividad, se use o no) de la tecnología biomédica instalada, durante la prestación de los servicios de salud programados15.
13
Ibíd., p. 142. 14
Ibíd., p. 145. 15
Ibíd., p. 150.
28
Se considera Buena una disponibilidad superior al 90 %. 4.11.2 Eficacia del mantenimiento correctivo. Este indicador permitirá una evaluación de la eficacia del mantenimiento correctivo y a la red comparar a los distintos Integrantes a fin de perfeccionar el trabajo de cada uno de ellos. Tiempo de respuesta = fecha y hora de solicitud del servicio - fecha y hora reporte del servicio técnico. Tiempo de trabajo o mantenimiento correctivo = fecha y hora de alta del equipo - fecha y hora de reporte técnico Tiempo de cambio de estado = fecha y hora de alta del equipo - fecha y hora de solicitud del servicio; ó Tiempo de cambio de estado = Tiempo de respuesta + Tiempo de correctivo Para la definición de este indicador se tendrán en cuenta la siguiente ecuación:
4.11.3 Indicador de falsas solicitudes. Este indicador es útil para registrar las falsas solicitudes, es decir aquellas llamadas que se producen estando el equipo 100 % operacional, tal es el caso que puede producirse con un equipo desfibrilador/cardioversión, en el que el operador selecciona para desfibrilar cuando el paciente presenta complejo QRS, no es el equipo el que falla, es error del operador. Este registro, mide la necesidad de superación del personal del servicio médico en relación con la tecnología instalada. Para la definición del indicador falsas solicitudes se desarrolló la siguiente ecuación:
29
En este caso se asumió que un porcentaje mayor al 10% indica que hay una necesidad de entrenamiento o capacitación del personal del servicio médico en relación con la tecnología instalada. 4.12 IMPLEMENTACIÓN DE GESTIÓN DE EQUIPOS MÉDICOS El primer paso y uno de los más críticos en la implementación de un sistema de gestión (computarizado o no computarizado) es completar un inventario preciso de todos los equipos que estarán bajo el programa de mantenimiento, incluyendo los dispositivos que prestaran servicio por otras organizaciones pero cuyos servicios necesitan tener un seguimiento. Cada dispositivo que necesita un seguimiento debe tener asignado un control de número por equipo y ser marcado sobre el dispositivo. Sin un sistema de inventario efectivo, es imposible hacer un seguimiento de mantenimiento y reparaciones, alertas y llamados, y precisamente la mayoría de las otras funciones de la gestión de equipos16. 4.13 LA GESTIÓN AUTOMATIZADA DE MANTENIMIENTO PARA LOS EQUIPOS MÉDICO-HOSPITALARIO La Gestión de Mantenimiento es una herramienta para apoyar al personal médico y de ingeniería en el desarrollo, control y dirección de un Programa de Mantenimiento de Equipo Médico garantizando su operación segura a máximas prestaciones y a costo efectivo.17 Los objetivos primordiales de una Gestión Automatizada de Mantenimiento son: Proporcionar un entorno seguro y funcional, mediante el mantenimiento
adecuado de todos los equipos y espacios. Proporcionar la documentación esencial y necesaria de todos los equipos y
espacios. Minimizar la cantidad de tiempo requerido para generar y archivar la
documentación de mantenimiento de todos los equipos y espacios.
16
RANGEL FRÍAS, Op. Cit., p. 23. 17
TFC Gestión Integral del Mantenimiento, Op. Cit., p. 49.
30
5. OBJETIVOS 5.1 OBJETIVO GENERAL Diseñar e implementar un sistema automatizado de gestión de mantenimiento de equipos médicos en la fundación Clínica Infantil Club Noel, utilizando herramientas de software libre.
5.2 OBJETIVOS ESPECÍFICOS
Determinar las características que deberá tener el software de gestión de mantenimiento de equipos médicos.
Realizar el diseño de la base de datos, mediante el modelo entidad relación y el modelo relacional de datos, para posteriormente realizar la construcción de la misma.
Diseñar los módulos de (plan de mantenimiento preventivo anual, órdenes de trabajo, hojas de vida de equipos medicos, indicadores de gestión, inventarios (físico-funcional, mantenimiento preventivo, mantenimiento entorno y la inspecciones de mantenimiento preventivo (IPM)).
Desarrollar el producto del software bajo los parámetros de la metodología RUP (Rational Unified Process).
Ejecutar un plan de pruebas funcionales y de aceptación para verificar la funcionalidad del software partiendo de las necesidades establecidas por el cliente.
31
6. METODOLOGÍA
6.1 PROCESO UNIFICADO RACIONAL (RUP- RATIONAL UNIFIED PROCESS) Es un proceso de desarrollo de software que constituye la metodología estándar más utilizada para el análisis, implementación y documentación de sistemas orientados a objetos. Este cuenta con los siguientes parámetros: 6.1.1 Modelo de requisitos. Este modelo es fundamental en el desarrollo software orientado a objetos, y tiene como objetivos delimitar el sistema y capturar la funcionalidad que ofrecerá desde la perspectiva del usuario, es decir, proyecta lo que el cliente desea según la percepción del desarrollador18. El propósito del modelo de requisitos es comprender en su totalidad el problema y sus implicaciones. Los demás modelos, análisis, diseño implementación y pruebas dependen directa o indirectamente del modelo de requisitos. Asimismo, este modelo sirve de base para el desarrollo de las instrucciones operacionales y los manuales, ya que todo lo que el sistema deba hacer se describe aquí desde la perspectiva del usuario. El modelo de requisitos no es un proceso mecánico, el analista debe interactuar constantemente con el cliente para completar la información faltante, y así resolver ambigüedades e inconsistencias. También debe separar los requisitos verdaderos de las decisiones relacionadas con el diseño e implementación. Se debe indicar cuales aspectos son obligatorios y cuales opcionales para evitar que se limite la flexibilidad de la implementación. Durante el diseño, se debe extender el modelo de requisitos con las especificaciones de rendimiento y los protocolos de interacción para los sistemas externos, al igual que las provisiones sobre la modularidad y futuras extensiones. Incluso, en ciertas ocasiones se pueden incluir aspectos de diseño, como el uso de lenguajes de programación particulares19. Figura 3. Dependencia de los distintos modelos del proceso del software del modelo de requisitos.
18
PRESSMAN, Roger S. Ingeniería del Software: Un enfoque práctico. 5ª Edición. México: McGraw-Hill, 2002. 19
PRESSMAN, Roger S.
32
Fuente: WEITZENFELD, Alfredo. “Ingeniería de Software Orientada a Objetos con UML, Java e Internet” THOMSON. México D.F: 2005. p. 218
6.1.2 Modelo de análisis. Su objetivo es comprender y generar una arquitectura de objetos para el sistema con base en lo especificado en el modelo de requisitos. El modelo de análisis es una representación conceptual, correspondiente al problema y modelo de requisitos, en términos de clase y objetos. Cada una de estas clases contribuye de manera especial a lograr la arquitectura deseada20. Es muy importante definir el tipo de arquitectura para la aplicación, las arquitecturas se distinguen según la organización de los objetos de acuerdo a su funcionalidad. El modelo de análisis debe lograr tres objetivos primarios, (1) describir lo que requiere el cliente, (2) establecer una base para la creación de un diseño de software, y (3) definir un conjunto de requisitos que se pueda validar una vez que se construye el software. Para lograr estos objetivos, el modelo de análisis extraído durante el análisis estructurado toma la forma ilustrada en la Figura 421.
20
WEITZENFELD, A. Ingeniería del Software orientada a objetos con UML, Java e internet. 1ª edición. México: Thomson, 2004. pág. 195-577. 21
Ibíd., p. 224.
33
Figura 4. La estructura del modelo de análisis.
Fuente: ROGER, Pressman. “Ingeniería de Software un Enfoque Práctico” Mc Graw Hill. España: 2002. p. 200
6.1.3 Modelo de Diseño. Este modelo es un refinamiento y formalización del modelo de análisis, donde se toman en cuenta las consecuencias del ambiente de implementación. El resultado del modelo son especificaciones muy detalladas de todos los objetos, incluyendo sus operaciones y atributos. Se requiere un modelo de diseño, ya que el modelo de análisis no es lo suficientemente formal para alcanzar el código fuente. Por tal motivo, se refinan los objetos incluyendo las operaciones y atributos. El sistema real también debe adaptarse al ambiente de implementación. En el análisis se considera un mundo ideal para el sistema, en la realidad se debe adaptar el sistema al ambiente de implementación, algo que cambia durante el ciclo de vida del sistema. Otro objetivo del diseño es validar los resultados de los modelos de requisitos y análisis. Durante el diseño se ve si los resultados anteriores son apropiados para la implementación. Si se descubren aspectos que no están claros en algunos de los modelos anteriores, estos se aclaran, posiblemente regresando a etapas anteriores22.
22
SOMMERVILLE, Ian. Ingeniería De Software: 7ª Edición. Madrid (España): Pearson Education, 2005
34
6.1.4 Modelo de Implementación. Toma el resultado del modelo de diseño para generar el código final, es decir, se adapta el lenguaje de programación y/o base de datos, según la especificación del diseño y las propiedades del lenguaje de implementación y base de datos. Aunque el diseño de objetos es bastante independiente del lenguaje actual, todos los lenguajes tienen sus particularidades, las cuales deben adecuarse durante la implementación final. La elección del lenguaje influye en el diseño, pero éste no debe depender de los detalles de aquel. Si se cambia de lenguaje de programación, no debe requerirse el rediseño del sistema23. 6.1.5 Modelo de Pruebas. Este modelo permite verificar que el comportamiento externo del sistema software satisfaga los requisitos establecidos por los clientes y futuros usuarios del mismo. Existen diversos tipos de pruebas aplicados durante las diferentes actividades del proceso del desarrollo, las cuales requieren de tiempo y presupuesto adicionales, que pueden llegar a significar un alto porcentaje del costo total. Por tal motivo, el modelo de pruebas debe ser planificado con anticipación y de manera integral junto con el desarrollo del sistema. Las pruebas no deben hacerse solo al final del desarrollo, ya que no puede lograrse software de alta calidad solo con pruebas finales y depuraciones. Las mismas deben hacerse simultáneamente con el desarrollo del sistema. Además, las pruebas finales deben tener como objetivo la certificación final de la calidad del producto y no la búsqueda de errores. Detectarlos al final del desarrollo es bastante problemático, dado que ello requiere regresar a etapas anteriores para resolverlos. Se considera que “evitar defectos” es más importante que “removerlos”24.
23
Ibíd., p. 471. 24
Ibíd., p. 473.
35
7. DESARROLLO DEL PROYECTO En este capítulo, se muestra el desarrollo de la aplicación “Sistema automatizado para gestión y mantenimiento de equipos médicos” denominado ManPre (mantenimiento preventivo), que le permitirá a la Fundación Clínica Infantil Club Noel automatizar los procesos de mantenimiento preventivo que se realiza a los equipos médicos. 7.1 MODELADO DEL NEGOCIO El modelado del negocio Muestra la estructura de los recursos, los productos o los servicios, y la información del negocio, incluyendo la estructura organizacional (divisiones, departamentos, secciones, unidades de negocio, etc.). 7.1.1 Descripción del negocio y su actividad. La Fundación Clínica Infantil Club Noel es una institución prestadora de salud de tipo pediátrico sin ánimo de lucro que ha dirigido sus esfuerzos a la implementación de programas y atenciones que cubran las necesidades de salud de los niños, manteniendo el sentido de servicio social. Actualmente la fundación clínica infantil Club Noel cuenta con un total de 173 equipos médicos, distribuidos en las siguientes áreas: laboratorio clínico, fisioterapia, terapia, odontología, sala San Roque, sala Mariana, sala Luis H., sala de pensionados, urgencias, rayos X, imagenología, administración quirófano, recuperación quirófano, sala quirófano 1, 2, 3 y 4; cirugía, dermatología, audiología, otorrinolaringología, oftalmología, endocrinología, salas hospitalización y lavandería. Por otro lado, la institución cuenta con un proyecto a corto plazo el cual consiste en la construcción de una UCI (unidad de cuidados intensivos), que a su vez estará conformada por 12 cubículos, en donde estarán ubicadas un total de 8 camas (4 pediátricas y 4 de cuidados intensivos intermedios). En cuanto a la dotación de equipos médicos, la UCI contará con 4 monitores de presión no invasiva, 4 monitores multípara- métricos, 4 ventiladores, 4 bombas de infusión, 4 bombas de alimentación y cada cubículo tendrá su propio suministro de oxígeno, bomba de succión y aire medicinal.
36
Figura 5. Organigrama Fundación Clínica Infantil Club Noel.
7.1.2 Actores del negocio. A continuación se muestran los actores del negocio:
Figura 6. Actores del negocio
37
7.1.3 Casos de uso del negocio
Presentar informe de falla: Determina el tipo de falla descrita por el personal que manipula el equipo médico, se define específicamente cual es el motivo o la causa del daño.
Generar reporte de falla: Describe el reporte que se le entrega al ingeniero electromecánico con los datos puntales de la falla del equipo médico.
Clasificar falla: determina la forma en que se clasificara la falla para determinar qué tipo de mantenimiento se le debe realizar al equipo médico.
Generar reporte completo de falla: Informe detallado del historial de falla y mantenimientos realizados al equipo.
Generar reporte de orden de trabajo: determina el tipo de mantenimiento que se le realiza al equipo (preventivo o de entorno).
Generar reporte de mantenimiento: especificación detallada del servicio de mantenimiento realizado por el técnico.
38
Figura 7. Diagrama de casos de uso del negocio.
39
8. ESPECIFICACIÓN DE REQUERIMIENTOS DE SOFTWARE A continuación se incluye información detallada sobre requerimientos mínimos que se tuvieron en cuenta para el desarrollo de la aplicación. 8.1 REQUERIMIENTOS FUNCIONALES Los requerimientos funcionales de un sistema describen lo que el sistema debe hacer. Estos requerimientos dependen del tipo de software que se desarrolle, de los posibles usuarios del software y del enfoque general tomado por la organización al redactar requerimientos. Cuando se expresan como requerimientos del usuario, habitualmente se describen de una forma bastante abstracta. Sin embargo. Los requerimientos funcionales del sistema describen con detalle la función de éste, sus entradas y salidas, excepciones, etcétera25. A nivel funcional el sistema debe permitir al usuario:
Acceder al sistema, mediante el ingreso un nombre de usuario y contraseña.
Ingresar un nuevo equipo en el inventario físico-funcional y poder asignarle un código único al equipo, para que este sea usado en todos los formularios.
Realizar una búsqueda de los equipos médicos del inventario físico-funcional por medio del código que los identifique.
Modificar la información de un equipo del inventario físico-funcional y guardar los cambios realizados.
Dar de baja a un equipo que se encuentre almacenado en el inventario físico-funcional.
25
Ibíd. p. 378.
40
Visualizar todos los equipos que se encuentran almacenados en el inventario físico-funcional.
Seleccionar los criterios de evaluación integral y posteriormente el sistema debe calcular el nivel de prioridad (pi), si el nivel de prioridad es alto, debe incluir el equipo en el inventario para mantenimiento, si la prioridad es baja lo debe incluir en el mantenimiento planificado del entorno.
Visualizar todos los equipos que se encuentren almacenados en el inventario para mantenimiento.
Visualizar los protocolos de mantenimiento preventivo de cada equipo médico.
Visualizar e imprimir las listas de comprobación de mantenimiento preventivo de cada equipo, para que el usuario pueda realizar las pruebas cualitativas, pruebas de aceptación, las pruebas de mantenimiento preventivo y las observaciones.
Visualizar los protocolos de mantenimiento del entorno de cada de las áreas del hospital.
Visualizar e imprimir las listas de comprobación de mantenimiento planificado del entorno de cada equipo, para que el usuario pueda realizar las pruebas cualitativas, las pruebas de inspección visual de equipos médicos, las pruebas de mantenimiento del entorno y las observaciones.
Ingresar la información técnica correspondiente a la hoja de vida de un nuevo equipo y guardarla en el sistema.
Eliminar una hoja de vida que se encuentre registrada en el sistema.
Modificar la hoja de vida de un equipo médico.
Realizar una búsqueda de las hojas de vida de los equipos por medio del
41
código que lo identifica.
Registrar las órdenes de trabajo y asignarles un número consecutivo para que no se repitan.
Imprimir las órdenes de trabajo.
Buscar una orden de trabajo que se encuentre almacenada en el sistema a través del código del equipo.
Eliminar una orden de trabajo que se encuentre registrada en el sistema.
Modificar las órdenes de trabajo.
Consultar el indicador de disponibilidad, y mostrar el porcentaje de disponibilidad correspondiente.
Consultar el indicador de eficacia de mantenimiento, y mostrar el porcentaje de eficacia de mantenimiento correspondiente.
Consultar el indicador de falsas solicitudes, y mostrar el porcentaje de falsas solicitudes correspondiente.
El sistema debe generar un plan de mantenimiento preventivo anual, que permita visualizar los equipos que se encuentran asignados y acomodar los equipos de acuerdo al índice de prioridad.
Seleccionar la fecha en que se le realiza el mantenimiento al equipo médico dentro del plan anual.
42
8.2 ESPECIFICACIONES SUPLEMENTARIAS (NO FUNCIONALES) Los requerimientos no funcionales hacen relación a las características del sistema que aplican de manera general como un todo, más que a rasgos particulares del mismo. Estos requerimientos son adicionales a los requerimientos funcionales que debe cumplir el sistema, y corresponden a aspectos tales como la disponibilidad, mantenibilidad, flexibilidad, seguridad, facilidad de uso, etc.26. La descripción de los requerimientos no funcionales para la aplicación es la siguiente:
El sistema debe funcionar sobre cualquier plataforma (multiplataforma), sin importar el sistema operativo que se maneje.
El sistema debe validar que los datos obligatorios sean ingresados correctamente.
El sistema debe permitir actualizar la información en el momento en que se realicen modificaciones en los ingresos.
El sistema debe permitir imprimir los reportes que se generan en formato PDF.
El sistema debe ser de fácil mantenimiento. 8.3 REQUERIMIENTOS DE INFRAESTRUCTURA En el siguiente apartado se describirán las características mínimas que deberá tener el equipo en el que se implemente la aplicación; para un óptimo funcionamiento del sistema.
Procesador 1,4 GHz (X86) o superior.
26
CIFI-INFORMÁTICA – PROCURADURÍA GENERAL DE LA NACIÓN. Requerimientos no funcionales [consultado 18 de septiembre de 2011]. Disponible en Internet: http://www.procuraduria.gov.co/infosim/media/file/VERSIONES_EN_PDF/Etapa4-ReqNoFunc.pdf
Software de java update 5.0 o superior. 8.4 DEFINICIÓN DE ACTORES Los actores del sistema pueden ser (persona o máquinas) que interactuaran o se comunicaran con el sistema de manera directa además de ser entes externos al sistema, dichos actores juegan un papel importante dentro de la aplicación ya que serán los encargados de ejercer las operaciones o funciones que la aplicación desempeña. A continuación se listaran los actores de la aplicación:
Técnico: Este usuario tiene total acceso a toda la información del sistema, podrá realizar ingresos, consultas, eliminaciones y modificaciones de los datos técnicos de los equipos médicos, como también generar los reportes que el software hará, debido a que es el ente que interactúa directamente con la aplicación.
44
9. LISTADO DE CASOS DE USO
Los casos de uso describen la manera en que los actores interactúan con el sistema, un caso de uso es un texto que describe como el actor o actores interactuará con el sistema. Para la aplicación “sistema automatizado para gestión y mantenimiento de equipos médicos” que se realizara para la Fundación Clínica Infantil Club Noel los casos de uso son los siguientes:
Iniciar sesión.
Registrar equipo.
Consultar equipo.
Modificar equipo.
Visualizar todos los equipos del inventario físico-funcional.
Registrar orden de trabajo.
Consultar orden de trabajo.
Eliminar orden de trabajo.
Modificar orden de trabajo.
Registrar hoja de vida.
Consultar hoja de vida.
Modificar hoja de vida.
Eliminar hoja de vida.
Visualizar todos los equipos del inventario para mantenimiento.
Visualizar todos los equipos del inventario de mantenimiento planificado del entorno.
Visualizar todos los equipos del inventario de mantenimiento correctivo.
Consultar (IPM) lista de comprobación de mantenimiento preventivo.
Consultar (IPM) lista de comprobación de mantenimiento planificado del entorno.
Consultar indicador de disponibilidad.
Consultar indicador de eficacia de mantenimiento correctivo.
Consultar indicador de falsas solicitudes.
Consultar plan de mantenimiento preventivo anual.
45
9.1 MATRIZ DE CASOS DE USO La matriz de casos de uso describe la relación entre los casos de uso y los requisitos funcionales del sistema. En el cuadro 1. Se muestra la matriz de casos de uso con su respectiva relación. Cuadro 2. Matriz de casos de uso
NO. NOMBRE CASO DE USO REQUISITOS
CONTEMPLADOS
01 Iniciar sesión. RF1
02 Registrar equipo. RF2
03 Consultar equipo. RF3
04 Eliminar equipo. RF5
05 Visualizar todos los equipos del inventario físico-funcional. RF6
06 Ingresar orden de trabajo. RF17
07 Consultar orden de trabajo. RF19
08 Eliminar orden de trabajo. RF20
09 Modificar orden de trabajo. RF21
10 Registrar hoja de vida RF13
11 Consultar hoja de vida RF16
12 Modificar hoja de vida RF15
13 Eliminar hoja de vida RF14
14 Visualizar todos los equipos del inventario para mantenimiento. RF8
15 Visualizar los protocolos de mantenimiento preventivo. RF9
16 Consultar (IPM) lista de comprobación de mantenimiento preventivo. RF10
17 Visualizar los protocolos de mantenimiento del entorno. RF11
18 Consultar (IPM) lista de comprobación de mantenimiento planificado del entorno. RF12
19 Consultar indicador de disponibilidad RF22
20 Consultar indicador de eficacia de mantenimiento RF23
21 Consultar indicador falsas solicitudes RF24
22 Consultar el plan de mantenimiento preventivo anual RF25
46
9.2 DIAGRAMA RELACIONAL DE CASOS DE USO En el diagrama relacional de casos de uso se mostrara gráficamente a que recursos tendrá acceso el actor del sistema. La figura 8 muestra el diagrama relacional de casos de uso de la aplicación. Figura 8. Diagrama relacional de casos de uso.
47
9.3 DESCRIPCIÓN O GUIONES DE CASOS DE USO La descripción de los casos de uso facilitara la tarea del diseñador ya que le permitirá observar cual es el flujo de eventos que cada caso de uso debe seguir, además de que actor o actores interactúan con cada caso de uso, como también los flujos alternos que corresponden a las validaciones y verificaciones que se deberán hacer en el momento de la implementación de los casos de uso del sistema. En cuadro 3. Se muestra el guion para el caso de uso N.1 iniciar Sesión Cuadro 3. Guion registrar equipo Caso de Uso No 02
Nombre Registrar equipo.
Descripción El sistema despliega en pantalla un formulario que le permite al usuario ingresar todos los datos correspondientes para el registro de un nuevo equipo en el inventario.
Estado Completo
Actores Técnico
Guión
Actor Sistema
1. El usuario selecciona la opción registrar equipo del módulo de inventarios. 3. El usuario ingresa el código, nombre, marca, modelo, serie. 4. El usuario selecciona la ubicación (laboratorio, fisioterapia, terapia, odontología, urgencias, sala san Roque, cirugía, sala mariana, sala pensionados, rayos x, imagenología, administración quirófano, recepción quirófano, recuperación quirófano, electros cirugía, sala de quirófano 1, sala de quirófano 2, sala de quirófano 3, sala de quirófano 4, dermatología, taller, audiología, otorrino, endocrino, oftalmología, esterilización, mantenimiento, lavandería, UCI). 6. El usuario selecciona el nivel de riesgo (clase I, clase IIA, clase IIIA, N/A).
2. El sistema despliega en pantalla un formulario que le permite al usuario ingresar la información correspondiente para registrar un nuevo equipo en el inventario. 5. El sistema carga en el formulario la ubicación del equipo. 7. El sistema carga en el formulario el nivel de riesgo.
48
Cuadro 3. (Continúa) 8. El usuario selecciona los manuales que tenga el equipo (operación, mantenimiento, usuario, técnico, no tiene). 10. El usuario selecciona la forma de adquisición (Directa, N/A). 12. El usuario selecciona los criterios de evaluación integral que corresponden a la función del equipo (soporte de vida, terapia-critico, diagnostico-critico, terapia-esencial, diagnostico-esencial, terapia-auxiliar, diagnostico-auxiliar, terapia-misceláneas), la aplicación clínica (puede producir la muerte al paciente, puede producir daño al paciente u operador, terapia inapropiada o falso diagnóstico, interrumpe el servicio al paciente), los requerimientos de mantenimiento (extensivo, promedio, mínimo) el historial de fallas (0-1, 2-3, 4-5, 6-7, 8 o más). 15. El usuario selecciona el tipo (B, BF, CF) 17. El usuario selecciona la clase(N/A, I, II, alimentado internamente). 19. El usuario selecciona el intervalo IPM veces por año (1, 2, 3, 4). 21. El usuario presiona ingresar el equipo.
9. El sistema carga en el formulario los manuales del equipo. 11. El sistema carga en el formulario la forma de adquisición. 13. EL sistema carga en el formulario la función del equipo, aplicación clínica, requerimientos de mantenimiento y la historia de fallas. 14. El sistema calcula la prioridad (PI) y asigna el equipo en el inventario para mantenimiento. 16. El sistema carga en el formulario el tipo. 18. El sistema carga en el formulario la clase. 20. El sistema carga en el formulario el intervalo IPM. 22. El sistema valida que el código, nombre, marca, modelo, serie no sean nulos y que contengan datos del tipo cadena. 23. El sistema valida que la ubicación se haya seleccionado. 24. El sistema valida que los criterios de evaluación integral se hayan seleccionado. 25. El sistema muestra un mensaje “El registro del equipo ha sido exitoso”. 26. El caso de uso termina.
49
Cuadro 3. (Continúa) Excepciones
1. Campo código, nombre, marca, modelo y serie es nulo o no es válido.
Actor Sistema
2.___________________________________ 27. El sistema muestra uno de los siguientes mensajes como flujo alterno. “ERROR: El campo no puede ser nulo “ERROR: El campo debe contener datos del tipo cadena”. 28. Solicita nuevamente el código, nombre, marca, modelo y serie.
2. La ubicación no se ha seleccionado.
Actor Sistema
3.___________________________________ 29. El sistema muestra un mensaje de error como flujo alterno. “ERROR: Debe seleccionar la ubicación”. 30. Solicita nuevamente la ubicación.
3. Los criterios de evaluación integral no se han seleccionado.
Actor Sistema
4.____________________________________ 31. El sistema muestra un mensaje de error como flujo alterno. “ERROR: Debe seleccionar los criterios de evaluación integral ” 32. Solicita nuevamente los criterios de evaluación integral.
CU relacionados
Ninguno
Pre-condición 01 Iniciar sesión
Post-condición Ninguno
Prototipo (Interfaz de usuario)
50
Cuadro 4. Guion registrar hoja de vida Caso Uso No 10
Nombre Registrar hoja de vida
Descripción Este caso de uso el usuario podrá ingresar los datos específicos correspondientes a la hoja de vida de cada equipo médico.
Estado Completo
Actores Técnico.
Guión
Actor Sistema
1. El usuario selecciona la opción ingresar hoja de vida del módulo de hojas de vida. 2. Ingresa el código del equipo. 3. Presiona ingresar hoja de vida. 8. El usuario ingresa las características técnicas como son tensión, corriente, potencia, resistencia, frecuencia, fuente, batería, fusible externo, fusible interno. 9. El usuario ingresa otros suministros como son agua, aire, 02, vacío. 10. El usuario ingresa otras características como son temperatura, humedad, peso, presión. 11. El usuario ingresa la descripción de accesorios. 12. El usuario ingresa las observaciones de accesorios.
4. El sistema valida que el código no sea nulo y que contenga datos del tipo cadena. 5. El sistema verifica la existencia del código del equipo. 6. El sistema muestra en pantalla un formulario con los campos correspondientes a la hoja de vida de los equipos médicos 7. El sistema carga en el formulario el nombre, marca, modelo, serie, código y ubicación del equipo.
51
Cuadro 4. (Continúa) 13. El usuario selecciona el personal especializado para su operación (enfermero, odontólogo, higienista, circulante, medico, anestesiólogo). 15. El usuario ingresa otras observaciones. 16. El usuario presión ingresar hoja de vida.
14. El sistema carga en pantalla el personal especializado para su operación. 17. El sistema valida que las características técnicas contengan datos del tipo numérico. 18. El Sistema valida que otros suministros contengan datos del tipo numérico. 19. El sistema valida que otras características contengan datos del tipo numérico. 20. El sistema valida que la descripción de accesorios contenga datos del tipo cadena. 21. El sistema valida que las observaciones de accesorios contenga datos del tipo cadena. 22. El sistema valida que otras observaciones contengan datos del tipo cadena. 23. El sistema muestra un mensaje “El ingreso de la hoja de vida ha sido exitoso” 24. El caso de uso termina.
Excepciones
1. El código es nulo o no es válido.
Actor Sistema
2. __________________________________________ 25. El sistema muestra en pantalla uno de los siguientes mensajes como flujo alterno. “ERROR: El código no puede ser nulo” “ERROR: El código debe contener datos del tipo cadena” 26. Vuelve a solicitar el código.
2. El código no se encuentra registrado.
Actor Sistema
3. __________________________________ 27. El sistema muestra un mensaje de error como flujo alterno. “ERROR: El código no se encuentra registrado” 28. Vuelve a solicitar el código.
52
Cuadro 4. (Continúa)
3. Las características técnicas es nulo o no son válidos.
Actor Sistema
4.__________________________________________ 29. El sistema muestra un mensaje de error como flujo alterno. “ERROR: Las características técnicas no pueden ser nulo” “ERROR: las características técnicas deben contener datos del tipo numérico” 30. Vuelve a solicitar las características técnicas del equipo.
4. Los suministros es nulo o no son válidos.
Actor Sistema
5.___________________________________________ 31. El sistema muestra un mensaje de error como flujo alterno. “ERROR: Los suministros no pueden ser nulo” “ERROR: los suministros deben contener datos del tipo numérico” 32. Vuelve a solicitar los suministros.
5. Las otras características es nulo o no son válidos.
Actor Sistema
6.__________________________________________ 33. El sistema muestra un mensaje de error como flujo alterno. “ERROR” las otras características no pueden ser nulo “ERROR: las otras características deben contener datos del tipo numérico” 34. Vuelve a solicitar las otras características.
6. La descripción de accesorios es nulo o no es válida.
Actor Sistema
8. __________________________________________ 37. El sistema muestra un mensaje de error como flujo alterno. “ERROR” La descripción de accesorios no puede ser nulo” “ERROR: La descripción de accesorios debe contener datos del tipo cadena” 38. Vuelve a solicitar la descripción de accesorios.
7. La observación de accesorios es nulo o no es válida.
Actor Sistema
9. ___________________________________ 39. El sistema muestra un mensaje de error como flujo alterno. “ERROR: la observación de accesorios no puede ser nulo” “ERROR: la observación de accesorios debe contener datos del tipo cadena” 40. vuelve a solicitar la observación de accesorios de accesorios.
53
Cuadro 4. (Continúa)
8. Las otras observaciones son nulas o no son válidas.
Actor Sistema
10. _________________________________________ 41. El sistema muestra un mensaje de error como flujo alterno. “ERROR: Las observaciones deben contener datos del tipo cadena” 42. Vuelve a solicitar las observaciones.
CU relacionados
Ninguno
Pre-condición Ingresar equipo
Post-condición Ninguno
Prototipo (Interfaz de usuario)
En el Anexo A se pueden observar los guiones de descripción de cada uno de los casos de uso de los diferentes módulos. (Especificación de requerimientos de software).
54
10. DIAGRAMA DE CLASES
El Diagrama de Clases es el diagrama principal para el análisis y diseño. Un diagrama de clases presenta las clases del sistema con sus relaciones estructurales y de herencia. La definición de clase incluye definiciones para atributos y operaciones. A continuación se muestran los diagramas de clases de los casos de uso listados anteriormente La figura 9. Muestra el diagrama de clase para el caso de uso N. 2. Figura 9. Diagrama de clases caso de uso N 2. Registrar equipo
55
Figura 10. Diagrama de clases caso de uso N. 10 Registrar hoja de vida.
Para cada caso de uso del software se obtuvo un diagrama de clase de la aplicación, los cuales se muestran en el Anexo B. (Diagramas de clase).
56
10.1 DIAGRAMA DE CLASES GENERAL En este tipo de diagrama define la estructura del sistema mostrando la clase, atributo y relaciones entre ellos. Figura 11. Diagrama de clases general.
57
11. DIAGRAMA DE SECUENCIA
Este tipo de diagramas fueron utilizados para conocer el funcionamiento que tendrían los objetos en el sistema a través del tiempo, estos diagramas se deben realizar para cada uno de los casos de uso de la aplicación. La figura 12. Muestra el diagrama de secuencia para el caso de uso N. 2. Figura 12. Diagrama de secuencia caso de uso N. 2. Registrar equipo
58
Figura 13. Diagrama de secuencia caso de uso N. 10. Registrar hoja de vida
Para cada caso de uso del software se obtuvo un diagrama de análisis de la aplicación, los cuales se muestran en el Anexo C. (Diagramas de secuencia).
59
12. PATRÓN DE ARQUITECTURA Para la realización del software se utilizó el patrón de arquitectura basado en MVC (modelo, vista, controlador) debido a que nos brinda una clara separación de los componentes del programa ya que es un patrón de diseño orientado a objetos, es decir la aplicación esta implementada modularmente, además la conexión entre el modelo y sus vistas es dinámico o sea que se produce en tiempo de ejecución, no en tiempo de compilación, por lo tanto el programador no debe preocuparse por que las vistas se actualicen, ya que este proceso es realizado automáticamente por el modelo de la aplicación. Además si se desea hacer una modificación al modelo, como aumentar métodos o datos contenidos, sólo debe modificarse el modelo y las interfaces del mismo con las vistas, no todo el mecanismo de comunicación y de actualización entre modelos. Además si en un futuro el software requiere de modificaciones o adaptaciones, las modificaciones a las vistas no afectan en absoluto a los módulos de la aplicación. El patrón de diseño MVC usa las clases de la aplicación para la división de estas por ejemplo27:
Lógica del negocio: datos persistentes.
Lógica de presentación: como se visualizan los datos.
Flujo de la aplicación: a través del controlador.
12.1 DIAGRAMA DE DESPLIEGUE MVC Figura 14. Diagrama de despliegue modelo vista controlador
27
PAVÓN MESTRAS, juan. El patrón modelo vista controlador (MVC) [en línea]. Madrid: Universidad complutense. [Consultado el 21 de noviembre de 2011]. Disponible en internet: http://www.fdi.ucm.es/profesor/jpavon/poo/2.14.MVC.pdf
Para el almacenamiento de los datos que la aplicación utilizo, se implementó el modelo entidad relación debido a que se realizaran múltiples consultas y la complejidad de los datos y los procesos requeridos para la base de datos no es muy grande. Además porque este modelo permite las operaciones básicas de ingresar, eliminar, modificar y consultar registros dentro de la base de datos. Figura 15. Modelo entidad relación
61
14. MODELO RELACIONAL DE DATOS
Figura 16. Modelo relacional de datos
62
15. IMPLEMENTACIÓN A continuación se presentan las herramientas de desarrollo que se utilizaron para la implementación “sistema automatizado para gestión de mantenimiento de equipos médicos”: 15.1 LENGUAJE DE PROGRAMACIÓN Debido a que la aplicación que se desarrolló para la Fundación Clínica Infantil Club Noel, es un aplicación de escritorio y en la cual no se contaba con una gran cantidad de apoyo económico para la escogencia de herramientas de desarrollo que fueran costosas, se decidió realizarla con herramientas que fueran software libre, esta es una de las razones por la cual se determinó que el lenguaje de programación o la tecnología que se escogería para el desarrollo debería ser java, ya que es una herramienta de uso opensource. Otro de los motivos por los cuales se determinó el uso de Java es debido a que el paradigma de programación que se usaría es el paradigma de la orientación a objetos y este lenguaje es un lenguaje totalmente orientado a objetos, además que la arquitectura sobre la cual se implementaría la aplicación es una arquitectura basada en MVC(modelo vista, controlador) y este lenguaje permite que se pueda implementar de manera óptima este modelo, gracias a Java permite el uso de clases y su empaquetamiento. 15.2 BASE DE DATOS Para la escogencia del motor de la base de datos se analizaron varias opciones ya que existen en el mercado diversos motores que son de licencia gratuita. Se decidió usar como motor de base de datos MySQL, debido a que el volumen de datos en la empresa es considerado pequeño puesto que es una pequeña empresa, y en su futuro crecimiento no se considera un volumen mayor al que pueda cubrir una base de datos MySQL, sumado a esto MySQL es un producto de software libre, en este aspecto favorecería mucho la empresa puesto que aparte de cubrir sus necesidades como negocio no es necesario invertir dinero en la compra de licencias.
63
La otra razón por la que se escogió MySQL, fue gracias a que es una base de datos comercial utilizada en las pequeñas empresas por tal motivo existe una gran documentación acerca de cada una de las versiones de dicho producto. En cuanto a la implementación de la aplicación, se procedió primero a construir la base de datos, instalarla y alimentarla con unos datos de prueba, para luego poder realizar las primeras retroalimentaciones a la aplicación. 15.2.1 Diagrama de componentes. El diagrama de componentes nos permite hacer una representación de cómo está dividido el software, es decir, cuáles son sus componentes y sus dependencias. Para la aplicación se contó con un componente que sería el JDK ver. 7 el cual es indispensable para el funcionamiento del software, este debe ir instalado en el equipo o servidor en el cual se va a ejecutar la aplicación, su función es de servir como puente entre el usuario y la aplicación a través de una interfaz GUI permite el acceso al sistema y a la información. El componente controlador, contiene los componentes de Microsoft.net frameworks 2.0 y Microsoft visual J# 2.0, que son los encargados de recibir y enviar los parámetros, del modelo a la vista, y el componente de modelo, en donde se encuentran aquellos componentes de la conexión a la base de datos, que son los encargados de realizar consultas, agregar datos, etc. Por ultimo tiene los componentes de la base de datos MySQL y las librerías.
64
Figura 17. Diagrama de componentes
15.3 ARQUITECTURA DE SOFTWARE Debido a que en la Fundación Clínica Infantil Club Noel la única persona que va a utilizar el software es el técnico, y en el equipo de él es donde se va a instalar el aplicativo y el motor de base de datos, escogimos la arquitectura cliente servidor, ya que el equipo actuara a la vez como servidor, permitiéndole al técnico acceder a los datos atreves de una interfaz que hace de puente entre él y los datos registrados en el sistema. 15.3.1 Diagrama de Despliegue. Mediante el diagrama de despliegue se puede observar cuáles serán los componentes de hardware que se verán involucrados en la aplicación. En este caso, se tendrá un equipo, que a su vez funciona como servidor donde se instalara la aplicación y la base de datos. El cliente podrá comunicarse con la aplicación a través de la interfaz del programa.
65
Figura 18. Diagrama de despliegue
66
16. PRUEBAS
Para este proyecto se establecieron dos tipos de pruebas, las pruebas funcionales o de caja negra, las cuales se realizan a medida que se iba desarrollando el software, y las otras se desarrollarían cuando el software ya estuviera terminado, que son las pruebas de aceptación y de integración. Las pruebas de caja negra se centran en lo que se espera de un módulo, es decir, intentan encontrar casos en que el módulo no se atiene a su especificación. Por esto se denominan pruebas funcionales, porque nos aseguran que cada una de las entradas que se realicen a la aplicación, tenga su respectiva salida y sea coherente con la petición que se realizó a la aplicación. El caso de uso más crítico es el de registrar equipo, por lo tanto es el caso de uso al que se le aplicaron las pruebas funcionales, y con los resultados obtenidos se retroalimento el caso de uso y se continuo con las demás pruebas en los demás casos de uso Cuadro 5. Prueba funcional – validaciones y verificaciones al caso de uso registrar equipo – Módulo de inventarios.
Entrada Validación y/o verificación
Nombre 1. El campo nombre está vacío. 2. El campo nombre no está vacío
Marca 3. El campo marca está vacío. 4. El campo marca no está vacío.
Modelo 5. El campo modelo está vacío. 6. El campo modelo no está vacío.
Serie 7. El campo serie está vacío. 8. El campo serie no está vacío.
Ubicación 9. No seleccionó una ubicación. 10. Seleccionó una ubicación.
Nivel de riesgo 11. No seleccionó un nivel de riesgo. 12. Seleccionó un nivel de riesgo.
Manual 13. No seleccionó un manual. 14. Seleccionó un manual.
Forma de adquisición
15. No seleccionó una forma de adquisición. 16. Seleccionó una forma de adquisición.
Función del equipo
17. No seleccionó una función del equipo. 18. Seleccionó una función del equipo.
67
Cuadro 5. (Continúa)
Entrada Validación y/o verificación
Aplicación clínica 19. No seleccionó una aplicación clínica. 20. Seleccionó una aplicación clínica.
Requerimiento de mantenimiento
21. No seleccionó un requerimiento de mantenimiento. 22. Seleccionó un requerimiento de mantenimiento.
Historial de fallas 23. No seleccionó un historial de fallas. 24. Seleccionó un historial de fallas.
Tipo 25. No seleccionó un tipo. 26. Seleccionó un tipo.
Clase 27. No seleccionó una clase. 28. Seleccionó una clase.
Intervalo IPM 29. No seleccionó un intervalo IPM. 30. Seleccionó un intervalo IPM.
Definidos cuales son los campos a los cuales se les debe realizar validaciones y/o verificaciones, se procede a realizar el diseño del caso de prueba para aquellos casos en los cuales se considera como críticos. Cuadro 6. Diseño de caso de prueba Nombre No. 01 – caso de uso registrar equipo.
No. Caso Prueba 1
Nombre Entrada Nombre
Nombre Caso de Prueba o Regla asociada
El campo nombre está vacío.
Valor Entrada “” o null Supuesto: El valor de la entrada debe ser alfanumérico o numérico.
Salida Esperada “Debe digitar su nombre del equipo”
Precondición
Poscondición No se podrá agregar el nombre al equipo.
Cuadro 7. Diseño de caso de prueba ubicación No. 09 – caso de uso registrar equipo.
No. Caso Prueba 9
Nombre Entrada Ubicación
Nombre Caso de Prueba o Regla No selecciono una ubicación.
68
asociada
Valor Entrada -Seleccione- Supuesto: La ubicación podría ser “Urgencias”
Salida Esperada “Debe seleccionar cual será la ubicación”
Precondición
Poscondición No se creara código al equipo, no podrá consultar equipos del inventario.
Cuadro 8. Diseño de caso de prueba función del equipo No. 17 – caso de uso registrar equipo.
No. Caso Prueba 17
Nombre Entrada Función del equipo
Nombre Caso de Prueba o Regla asociada
No selecciono una función del equipo.
Valor Entrada -Seleccione- Supuesto: La función podría ser “Soporte de vida”
Salida Esperada “Debe seleccionar cual será la función del equipo”
Precondición Haber seleccionado la clase.
Poscondición No se calculara el nivel de prioridad PI al equipo médico.
Cuadro 9. Diseño de caso de prueba Aplicación clínica No. 19 – caso de uso registrar equipo.
No. Caso Prueba 19
Nombre Entrada Aplicación clínica
Nombre Caso de Prueba o Regla asociada
No selecciono una aplicación clínica.
Valor Entrada -Seleccione- Supuesto: La aplicación clínica podría ser “Falso diagnostico”
Salida Esperada “Debe seleccionar cual será la aplicación clínica”
Precondición Haber seleccionado el manual.
Poscondición No se calculara el nivel de prioridad PI al equipo médico.
69
Cuadro 10. Diseño de caso de prueba para intervalo IPM No. 29 – caso de uso registrar equipo.
No. Caso Prueba 29
Nombre Entrada Intervalo IPM
Nombre Caso de Prueba o Regla asociada
No selecciono un intervalo IPM.
Valor Entrada -Seleccione- Supuesto: La ubicación podría ser “2-3”
Salida Esperada “Debe seleccionar cual será el intervalo IPM”
Precondición Haber seleccionado el tipo
Poscondición No se calculara el nivel de prioridad PI al equipo médico.
70
17. CONCLUSIONES El desarrollo de la aplicación “SISTEMA AUTOMATIZADO DE GESTIÓN DE MANTENIMIENTO DE EQUIPOS MEDICOS” ManPre, permitió integrar todos los conceptos adquiridos en la carrera de ingeniería informática, logrando cumplir con los objetivos y las necesidades propuestas por el cliente, poniendo en práctica todo este conocimiento y complementando la información con estudio independiente e investigación se pudo lograr finalizar el proyecto con total satisfacción. El software, sistema automatizado de gestión de mantenimiento de equipos médicos que se realizó para la Fundación Clínica Infantil club Noel, podrá ser utilizado o manipulado por cualquier persona que cuente con conocimientos básicos en gestión de mantenimiento de equipos médicos, debido a que su interfaz es muy amigable e intuitiva, brindando fácil acceso a cada uno de los diferentes módulos de la aplicación. Se logró generar un aplicativo de bajo costo, completamente funcional, con software gratuito y ampliamente difundido, lo cual posibilita que se puedan adicionar nuevas facilidades sin que sea necesaria una curva de aprendizaje alta. Aunque las aplicaciones de escritorio no tienen demasiada demanda dentro del contexto del software, en contraposición a las aplicaciones web que se han masificado, siguen siendo una excelente solución al momento de crear aplicaciones que serán ejecutadas en una sola máquina y que permitan suplir todos los tipos de necesidades que surgen dentro de las organizaciones actuales.
71
18. RECOMENDACIONES
Se recomienda al técnico diligenciar correctamente los formularios de órdenes de trabajo y las hojas de vida de los equipos médicos ya que el sistema es sensible en cuanto, a datos duplicados, caracteres y campos inválidos. Actualmente la aplicación está diseñada para uso exclusivo del técnico de mantenimiento de equipos médicos ya que es el único actor que interactúa con la aplicación, debido a esto el software contempla la posibilidad de agregar nuevas cuentas de usuario, de tal forma que estos usuarios tengan acceso al sistema y puedan diligenciar la información. Según la proyección que tenga la clínica en cuanto a la adquisición de nuevos equipos médicos como también de sus entornos de trabajo, se recomienda agregar otros indicadores de gestión, tales como indicador de cumplimiento del plan de mantenimiento preventivo, indicador de costos, indicador de eficacia en la utilización del tiempo e indicador de eficacia del mantenimiento correctivo; que le permitan al técnico identificar cuáles son las falencias o puntos críticos de la gestión y así establecer posibles planes de mejoramiento de la misma. Pensando en la escalabilidad del software queda abierta la posibilidad de que en un futuro se puedan crear nuevos módulos en el sistema, que permitan complementar la gestión y el inventario de equipos médicos hospitalarios. Se recomienda al técnico del área de mantenimiento, mantener actualizado el inventario físico funcional para tener un registro de los equipos médicos y hospitalarios que se encuentran instalados en la institución y saber cuáles están en condiciones de operatividad y cuáles no.
72
BIBLIOGRAFÍA CIFI- INFORMÁTICA – PROCURADURÍA GENERAL DE LA NACIÓN. DYRO F, Joseph. Clinical Engineering HandBook. 1ª Edición. Estados Unidos: Elsevier Academic Press, 2004. pág. 122-130. --------. Ingeniería del Software orientada a objetos con UML, Java e internet. 1ª edición. México: Thomson, 2004. pág. 195-577. Generación automática de diagramas de secuencia [consultado el 21 DE NOVIEMBRE de 2011]. Disponible en internet: http://revista.eia.edu.co/articulos10/art7.pdf PAVÓN MESTRAS, juan. El patrón modelo vista controlador (MVC) [en línea]. Madrid: Universidad complutense. [Consultado el 21 de noviembre de 2011]. Disponible en internet: http://www.fdi.ucm.es/profesor/jpavon/poo/2.14.MVC.pdf PRESSMAN, Roger S. Ingeniería del Software: Un enfoque práctico. 5ª Edición. México: McGraw-Hill, 2002. --------. Gestión de Mantenimiento de Equipos Médicos [en línea]. La Habana: II Congreso Latinoamericano de Ingeniería Biomédica. [Consultado 24 de Febrero de 2010]. Disponible en Internet: http://www.hab2001.sld.cu/arrepdf/00187.pdf Requerimientos no funcionales [consultado 18 de septiembre de 2011]. Disponible en Internet: http://www.procuraduria.gov.co/infosim/media/file/VERSIONES_EN_PDF/Etapa4-ReqNoFunc.pdf REVISTA EIA - GENERACIÓN DEL DIAGRAMA DE SECUENCIAS DE UML 2.1.1 DESDE ESQUEMAS PRECONCEPTUALES SOLUCIÓN INTEGRAL PARA CONTROL Y ADMINISTRACIÓN DEL MANTENIMIENTO. MP [consultado el 11 de noviembre de 2011]. Disponible en internet: SOMMERVILLE, Ian. Ingeniería De Software: 7ª Edición. Madrid (España): Pearson Educatión, 2005
TFC Gestión Integral del Mantenimiento. [En Línea] disponible en: Internet: http://www.scribd.com/doc/4184016/TFC-Gestion-Integral-del-Mantenimiento. --------. Sistema de Gestión Tecnológica Hospitalaria V 1.0. [En línea]. La Habana: Centro de Bioingeniería del Instituto superior Politécnico José Antonio Echeverría. [Consultado 24 de Febrero de 2010]. Disponible en Internet: http://www.vision.ime.usp.br/~elier/sgt.pdf --------. Sistema de Administración de Mantenimiento por Computadora [en línea]. Monterrey: RQ Consultoría Técnica. [Consultado 25 de Febrero de 2010]. Disponible en Internet: www.rqct.com/download/Guia%20Rapida%20MS2000.doc
ANEXO A. DIAGRAMAS DE CASOS DE USO Caso de uso 1. Iniciar sesión.
Caso Uso No
01
Nombre Iniciar sesión
Descripción Este caso de uso permitirá que el usuario se identifique y pueda ingresar al sistema, de acuerdo al área a la que éste pertenezca.
Estado Completo
Actores Técnico
Guión
Actor Sistema
1. El usuario ingresa el login de usuario. 2. El usuario ingresa la password. 3. Presiona iniciar sesión.
4. El sistema valida que el nombre no sean nulo y que sean del tipo de dato cadena. 5. El sistema valida la contraseña no sea nula y que sean del tipo de dato cadena. 6. El sistema verifica que el usuario y la contraseña sean válidos. 7. Se ingresa al sistema y muestra en la pantalla “Bienvenido”. 8. El caso de uso termina.
Excepciones
1. El nombre es nulo o no es válido.
Actor Sistema
2. _______________________________________ 9. El sistema muestra uno de los siguientes mensajes como flujo alterno.
75
“ERROR: El campo nombre no puede ser nulo” “ERROR” El nombre debe contener datos del tipo cadena”. 10. Vuelve a solicitar el nombre.
2. La contraseña es nula o no es válida.
Actor Sistema
3. _______________________________________ 11. El sistema muestra uno de los siguientes mensajes como flujo alterno. ERROR: El campo contraseña no puede ser nulo “ “ERROR: La contraseña debe contener datos del tipo cadena”. 12. vuelve a solicitar la contraseña.
3. Nombre de usuario y/o contraseña no se encuentran registrados o están incorrectos.
Actor Sistema
4. _______________________________________ 13. El sistema muestra uno de los siguientes mensajes como flujo alterno. “ERROR: El usuario no se encuentra registrado en el sistema.” “ERROR: La contraseña es incorrecta” 14. vuelve a solicitar el usuario y la contraseña.
CU relacionados
Ninguno
Pre-condición
Ninguno
Post-condición
Ninguno
Prototipo (Interfaz de usuario)
Caso de uso 2. Registrar equipo.
Caso de Uso No
02
Nombre Registrar equipo.
Descripción El sistema despliega en pantalla un formulario que le permite al usuario ingresar todos los datos correspondientes para el registro
76
de un nuevo equipo en el inventario.
Estado Completo
Actores Técnico
Guión
Actor Sistema
1. El usuario selecciona la opción registrar equipo del módulo de inventarios. 3. El usuario ingresa el Código, nombre, marca, modelo, serie. 4. El usuario selecciona la ubicación (laboratorio, fisioterapia, terapia, odontología, urgencias, sala san Roque, cirugía, sala mariana, sala pensionados, rayos x, imagenología, administración quirófano, recepción quirófano, recuperación quirófano, electros cirugía, sala de quirófano 1, sala de quirófano 2, sala de quirófano 3, sala de quirófano 4, dermatología, taller, audiología, otorrino, endocrino, oftalmología, esterilización, mantenimiento, lavandería, UCI). 6. El usuario selecciona el nivel de riesgo (clase I, clase IIA, clase IIIA, N/A). 8. El usuario selecciona los manuales que tenga el equipo (operación, mantenimiento, usuario, técnico, no tiene). 10. El usuario selecciona la forma de adquisición (Directa, N/A).
2. El sistema despliega en pantalla un formulario que le permite al usuario ingresar la información correspondiente para registrar un nuevo equipo en el inventario. 5. El sistema carga en el formulario la ubicación del equipo 7. El sistema carga en el formulario el nivel de riesgo. 9. El sistema carga en el formulario los manuales del equipo. 11. El sistema carga en el formulario la forma de adquisición.
77
12. El usuario selecciona los criterios de evaluación integral que corresponden a la función del equipo (soporte de vida, terapia-critico, diagnostico-critico, terapia-esencial, diagnostico-esencial, terapia-auxiliar, diagnostico-auxiliar, terapia-misceláneas), la aplicación clínica (puede producir la muerte al paciente, puede producir daño al paciente u operador, terapia inapropiada o falso diagnóstico, interrumpe el servicio al paciente), los requerimientos de mantenimiento (extensivo, promedio, mínimo) el historial de fallas (0-1, 2-3, 4-5, 6-7, 8 o más). 15. El usuario selecciona el tipo (B, BF, CF) 17. El usuario selecciona la clase(N/A, I, II, alimentado internamente). 19. El usuario selecciona el intervalo IPM veces por año (1, 2, 3, 4). 21. El usuario presiona ingresar el equipo.
13. EL sistema carga en el formulario la función del equipo, aplicación clínica, requerimientos de mantenimiento y la historia de fallas. 14. El sistema calcula la prioridad (PI) y asigna el equipo en el inventario para mantenimiento. 16. El sistema carga en el formulario el tipo. 18. El sistema carga en el formulario la clase. 20. El sistema carga en el formulario el intervalo IPM. 22. El sistema valida que el Código, nombre, marca, modelo, serie no sean nulos y que contengan datos del tipo cadena. 23. El sistema valida que la ubicación se haya seleccionado. 24. El sistema valida que los criterios de evaluación integral se hayan seleccionado. 25. El sistema muestra un mensaje “El registro del equipo ha sido exitoso”. 26. El caso de uso termina.
78
Excepciones
4. Campo código, nombre, marca, modelo y serie es nulo o no es válido.
Actor Sistema
2.______________________________ 27. El sistema muestra uno de los siguientes mensajes como flujo alterno. “ERROR: El campo no puede ser nulo “ERROR: El campo debe contener datos del tipo cadena”. 28. Solicita nuevamente el Código, nombre, marca, modelo y serie.
5. La ubicación no se ha seleccionado.
Actor Sistema
3.______________________________ 29. El sistema muestra un mensaje de error como flujo alterno. “ERROR: Debe seleccionar la ubicación”. 30. Solicita nuevamente la ubicación.
6. Los criterios de evaluación integral no se han seleccionado.
Actor Sistema
4._____________________________ 31. El sistema muestra un mensaje de error como flujo alterno. “ERROR: Debe seleccionar los criterios de evaluación integral ” 32. Solicita nuevamente los criterios de evaluación integral.
CU relacionados Ninguno
Pre-condición 01 Iniciar sesión
Post-condición Ninguno
Prototipo (Interfaz de usuario)
79
Caso de uso 3. Consultar equipo.
Caso Uso No
03
Nombre Consultar equipo
Descripción Este caso de uso el usuario podrá consultar un equipo que se encuentre almacenado en el inventario físico-funcional.
Estado Completo
Actores Técnico.
Guión
Actor Sistema
1. El usuario selecciona la opción consultar equipo del módulo de inventarios. 2. ingresa el código del equipo. 3. Presiona consultar equipo.
4. El sistema valida que el código del equipo no sea nulo y que contenga datos del tipo cadena. 5. El sistema verifica la existencia del código en el equipo. 6. El sistema muestra en pantalla los datos técnicos del equipo correspondientes al inventario físico-funcional como son el nombre, marca, modelo, serie, ubicación, nivel de riesgo, manuales, forma de adquisición , PI, el tipo, la clase, el intervalo IPM. 7. El caso de uso termina.
Excepciones
1. El código es nulo o no es válido.
Actor Sistema
2.___________________________________________ 8. El sistema muestra uno de los siguientes mensajes como flujo alterno. “ERROR: El campo código no puede ser nulo “ “ERROR: El código debe contener datos del tipo cadena”. 9. Solicita nuevamente el código.
80
2. El código no se encuentra registrado.
Actor Sistema
3. __________________________________________ 10. El sistema muestra un mensaje de error como flujo alterno. “ERROR: El código no se encuentra registrado en el sistema.” 11. Solicita nuevamente el código.
CU relacionados
Ninguno
Pre-condición
Iniciar Sesión
Post-condición
Ninguno
Prototipo (Interfaz de usuario)
Caso de uso 4. Modificar equipo
Caso Uso No 04
Nombre Modificar equipo
Descripción Este caso de uso el usuario podrá modificar los datos técnicos de un equipo que se encuentre registrado en el inventario físico-funcional.
Estado Completo
Actores Técnico.
Guión
Actor Sistema
1. El usuario selecciona la opción modificar equipo del módulo de inventarios. 2. Ingresa el código del equipo. 3. Solicita al sistema la modificación de los datos técnicos del equipo mediante el botón modificar.
4. El sistema valida que el código del equipo no se nulo y que contenga datos del tipo cadena. 5. El sistema verifica la existencia del código del equipo.
81
7. El usuario podrá modificar los campos necesarios. 8. El usuario presiona modificar. 12. El usuario confirma la modificación de los cambios en la información.
6. El sistema despliega en pantalla un formulario con los datos técnicos del equipo correspondientes al inventario físico-funcional los cuales son:
nombre
marca
modelo
serie
código
ubicación
nivel de riesgo
manuales
forma de adquisición
criterios de evaluación integral(función dele quipo, aplicación clínica, requerimientos de mantenimiento, historial de fallas)
tipo
clase
intervalo IPM 9. El sistema carga en el formulario los datos seleccionados. 10. El sistema valida que el o los datos modificados no sean nulos y que estén correctos de acuerdo al tipo de variable correspondiente de cada uno. 11. El sistema muestra un mensaje de confirmación “Se van a realizar cambios en la información del equipo, realmente desea guardarlos”. 13. El sistema muestra un mensaje “cambios realizados satisfactoriamente” 14. El caso de uso termina.
82
Excepciones
1. El código no se encuentra registrado.
Actor Sistema
2. ________________________________ 15. El sistema muestra un mensaje de error como flujo alterno. “ERROR: El código no se encuentra registrado”. 16. Vuelve a solicitar el código.
2. El código es nulo o no es válido.
Actor Sistema
3.________________________________ 17. El sistema muestra uno de los siguientes mensajes como flujo alterno. “ERROR: El campo código no puede ser nulo” “ERROR: El código debe contener datos del tipo cadena” 18. Vuelve a solicitar el código.
3. El dato o campo modificado es nulo o no es válido.
Actor Sistema
4.________________________________ 19. Para cada uno de los datos modificados el sistema muestra en pantalla que el dato es erróneo y espera su corrección mostrando unos de los siguientes mensajes como flujo alterno: “ERROR: El campo no puede ser nulo” “ERROR: El campo debe contener datos del tipo correcto”. 20. Vuelve a solicitar la modificación del campo erróneo.
CU relacionados
Ninguno
Pre-condición Iniciar Sesión
Post-condición
Ninguno
Prototipo (Interfaz de usuario)
83
Caso de uso 5. Visualizar todos los equipos del inventario físico-funcional.
Caso Uso No 05
Nombre Visualizar todos los equipos del inventario físico-funcional.
Descripción Este caso de uso el usuario podrá visualizar todos los equipos que se encuentren en el inventario físico-funcional.
Estado Completo
Actores Técnico.
Guión
Actor Sistema
1. El usuario ingresa a la opción de inventario físico-funcional. 2. El usuario selecciona la opción ver todos los equipos. 4. El usuario presiona volver.
3. El sistema muestra en pantalla una tabla con la información de todos los equipos que se encuentran registrados en el inventario físico-funcional, con sus respectivos campos que son nombre, marca, modelo, serie, código, ubicación, responsable mantenimiento, nivel de riego, manuales, forma de adquisición. 5. El caso de uso termina.
Excepciones
CU relacionados
Ninguno
Pre-condición Iniciar Sesión
Post-condición Ninguno
Prototipo (Interfaz de usuario)
Caso de uso 6. Registrar orden de trabajo.
Caso Uso No
06
Nombre Registrar orden de trabajo
Descripción Se despliega en pantalla un formulario que le permite al usuario ingresar todos los datos correspondientes para poder registrar una nueva orden de trabajo en el sistema.
84
Estado Completo
Actores Técnico.
Guión
Actor Sistema
1. Selecciona la opción registrar orden de trabajo. 2. Ingresa el código del equipo. 3. Presiona Registrar. 7. El usuario selecciona la fecha y la hora de la solicitud (año, mes, día, am, pm). 9. El usuario selecciona Falsa solicitud (si, no). 11. El usuario selecciona Equipo fuera de servicio (si, no).
4. El sistema valida que el código del equipo no sea nulo y que contenga datos del tipo cadena. 5. El sistema verifica la existencia del código en el equipo. 6. El sistema muestra en pantalla el formulario y carga los datos del equipo código, nombre, marca, modelo, serie y ubicación. 8. El sistema carga en pantalla la fecha y la hora de solicitud. 10. El sistema carga en pantalla la falsa solicitud. 12. El sistema carga en pantalla Equipo fuera de servicio. 14. El sistema carga en pantalla la fecha y la hora del reporte de servicio técnico.
85
13. El usuario selecciona la fecha y la hora del reporte de servicio técnico (año, mes, día, am, pm). 15. EL usuario selecciona el cargo de la persona que solicita el servicio. 17. El usuario selecciona el tipo de mantenimiento (preventivo, correctivo). 19. El usuario ingresa el nombre de la persona que solicita el servicio. 20. El usuario ingresa la descripción detallada de la solicitud del servicio. 21. El usuario ingresa las especificaciones del servicio. 22. El usuario ingresa la descripción de los materiales 23. El usuario ingresa la cantidad de materiales. 24. El usuario ingresa el costo de los materiales. 25. El usuario ingresa el costo total de los materiales.
16. El sistema carga en pantalla el cargo de la persona que solicita el servicio. 18. El sistema carga en pantalla el tipo de mantenimiento. 28. El sistema carga en pantalla la fecha y la hora de alta del equipo. 30. El sistema valida que el nombre de la persona que solicita el servicio no sea nulo y que contenga datos del tipo cadena.
86
26. El usuario ingresa las observaciones. 27. El usuario selecciona la fecha y la hora de alta del equipo (año, mes, día, am. pm). 29. El usuario presiona Registrar orden de trabajo.
31. El sistema valida que la descripción de los materiales no sea nula y que contenga datos del tipo cadena. 32. El sistema valida que la cantidad de materiales no sea nula y que contenga datos del tipo numérico. 33. El sistema valida que los costos de los materiales no sean nulos y que contengan datos del tipo numérico. 34. El sistema valida que el costo total de los materiales no sea nulo y que contenga datos del tipo numérico. 35. El sistema registra la orden de trabajo en el sistema y le genera un número consecutivo de 5 dígitos que no se repite. 36. El caso de uso termina.
Excepciones
1. El código es nulo o no es válido.
Actor Software
2.___________________________________________ 37. El sistema muestra uno de los siguientes mensajes como flujo alterno: “ERROR: El campo código no puede ser nulo” “ERROR: El campo código debe contener datos del tipo cadena” 38. Solicita nuevamente el código.
2. El código no se encuentra registrado.
Actor Software
3. __________________________________________ 39. El sistema muestra un mensaje de error como flujo alterno. “ERROR: El código no se encuentra registrado en el sistema.” 40. Solicita nuevamente el código.
3. El nombre de la persona que solicita el servicio es nulo o no es válido.
Actor Software
4.__________________________________________
87
41. El sistema muestra uno de los siguientes mensajes como flujo alterno: “ERROR: El nombre de la persona que solicita el servicio no puede ser nulo” “ERROR: El nombre de la persona que solicita el servicio debe contener datos del tipo cadena” 42. vuelve a solicitar el nombre de la persona que solicita el servicio.
4. La descripción de los materiales es nulo o no es válido.
Actor Software
5.___________________________________________ 43. El sistema muestra uno de los siguientes mensajes como flujo alterno: “ERROR: La descripción de los materiales no puede ser nulo” “ERROR: la descripción de los materiales debe contener datos del tipo cadena” 44. Vuelve a solicitar la descripción de los materiales.
5. La cantidad de materiales es nula o no es válido.
Actor software
6.__________________________________________ 45. El sistema muestra uno de los siguientes mensajes como flujo alterno: “ERROR: La cantidad de materiales no puede ser nulo” “ERROR: La cantidad de materiales debe contener solo caracteres numéricos” 46. Vuelve a solicitar la cantidad de materiales.
6. El costo de los materiales es nulo o no es válido.
Actor Software
7. __________________________________________ 47. El sistema muestra uno de los siguientes mensajes como flujo alterno: “ERROR: El costo de los materiales no puede ser nulo” “ERROR: El costo de los materiales debe contener solo caracteres numéricos” 48. Vuelve a solicitar la cantidad de materiales.
7. El costo total de los materiales es nulo o no es válido.
Actor Software
49. El sistema muestra uno de los siguientes mensajes como flujo alterno:
88
“ERROR: El costo total de los materiales no puede ser nulo” “ERROR: El costo total de los materiales debe contener solo caracteres numéricos ” 50. Vuelve a solicitar el costo total.
CU relacionados
Ninguno
Pre-condición
Iniciar Sesión
Post-condición
Ninguno
Prototipo (Interfaz de usuario)
Caso de uso 7. Consultar orden de trabajo.
Caso Uso No 07
Nombre Consultar orden de trabajo.
Descripción Este caso de uso el usuario podrá consultar las órdenes de trabajo que se encuentren registradas en el sistema.
Estado Completo
Actores Técnico.
Guión
Actor Sistema
1. El usuario ingresa a la opción de órdenes de trabajo. 2. Selecciona la opción consultar orden de trabajo. 3. El usuario ingresa el código del equipo. 4. Presiona consultar
5. El sistema valida que el código no sea nulo y que contenga datos del tipo cadena. 6. El sistema verifica la existencia del código del equipo en el sistema. 7. El sistema muestra en pantalla un listado de todas las ordenes de trabajo asociadas al equipo 8. El caso de uso termina.
89
Excepciones
1. El código es nulo o no es válido.
Actor Sistema
2. __________________________________ 9. El sistema muestra uno de los siguientes mensajes como flujo alterno: “ERROR: El código no puede ser nulo” “ERROR: El código debe contener datos del tipo cadena” 10. vuelve a solicitar el código.
2. El equipo no se encuentra registrado en el sistema.
Actor Sistema
3. __________________________________ 11. El sistema muestra un mensaje de error como flujo alterno. “ERROR: El equipo no se encuentra registrado” 12. vuelve a solicitar el código.
CU relacionados
Ninguno
Pre-condición Iniciar Sesión
Post-condición
Ninguno
Prototipo (Interfaz de usuario)
Caso de uso 8. Eliminar orden de trabajo
Caso Uso No 08
Nombre Eliminar orden de trabajo.
Descripción Este caso de uso el usuario podrá eliminar una orden de trabajo que se encuentre almacenada en el sistema.
Estado Completo
Actores Técnico.
Guión
Actor Sistema
90
1. El usuario ingresa al módulo de órdenes de trabajo. 2. Selecciona la opción eliminar orden de trabajo. 3. Ingresa el código del equipo. 7. El usuario selecciona la orden de trabajo que desea eliminar. 8. Presiona eliminar. 10. El usuario confirma la eliminación de la orden de trabajo.
4. El sistema valida que el código no sea nulo y que contenga datos del tipo cadena. 5. El sistema verifica la existencia del código del equipo. 6. El sistema muestra en pantalla un listado de todas las ordenes de trabajo asociadas al equipo 9. El sistema solicita al usuario confirmar la eliminación de la orden de trabajo. 11. El sistema elimina la orden de trabajo del sistema. 12. El caso de uso termina.
Excepciones
1. El código es nulo o no es válido.
Actor Sistema
2. ________________________________ 13. El sistema muestra uno de los siguientes mensajes como flujo alterno: “ERROR: El código no puede ser nulo” “ERROR: El código debe contener datos del tipo cadena” 8. vuelve a solicitar el código.
2. El código no se encuentra registrado.
Actor Sistema
3. __________________________________ 14. El sistema muestra un mensaje de error como flujo alterno. “ERROR: El código no se encuentra
91
registrado” 15. vuelve a solicitar el código.
3. Confirmación de eliminación de orden de trabajo.
Actor Sistema
4. ___________________________________ 16. El software muestra un mensaje de confirmación “Está seguro que desea eliminar la orden de trabajo” 17. Si el usuario selecciona no, vuelve a solicitar que seleccione una nueva orden de trabajo.
CU relacionados
Ninguno
Pre-condición Iniciar Sesión
Post-condición
Ninguno
Prototipo (Interfaz de usuario)
Caso de uso 9. Modificar orden de trabajo.
Caso Uso No 09
Nombre Modificar orden de trabajo.
Descripción Este caso de uso el usuario podrá modificar una orden de trabajo que se encuentre almacenada en el sistema.
Estado Completo
Actores Técnico.
Guión
Actor Sistema
92
1. El usuario selecciona la opción modificar orden de trabajo del módulo de órdenes de trabajo. 2. Ingresa el código del equipo. 3. Solicita al sistema la modificación de la orden de trabajo mediante el botón modificar. 7. El usuario selecciona la orden de trabajo que desea modificar.
4. El sistema valida que el código no sea nulo y que contenga datos del tipo cadena. 5. El sistema verifica la existencia del código del equipo. 6. El sistema muestra en pantalla un listado de todas las ordenes de trabajo asociadas al equipo 8. El sistema muestra en pantalla un formulario con los datos que contiene la orden de trabajo los cuales son:
código
nombre
marca
modelo
serie
ubicación
fecha de solicitud
hora de solicitud
falsa solicitud
equipo fuera de servicio
fecha de reporte de servicio técnico
93
9. El usuario podrá modificar los campos necesarios. 10. El usuario presiona modificar. 14. El usuario confirma la modificación de la orden de trabajo.
hora de reporte de servicio técnico
persona que solicita el servicio
cargo
descripción detallada de solicitud de servicio
el tipo de mantenimiento(preventivo, correctivo)
las especificaciones del servicio
cantidad de materiales y repuestos
descripción de materiales y repuestos
costos de materiales y repuestos
costos totales
observaciones
fecha de alta del equipo
hora de alta del equipo. 11. El sistema carga en el formulario los datos seleccionados. 12. El sistema valida que el o los datos modificados no sean nulos y que estén correctos de acuerdo al tipo de variable correspondiente de cada uno. 13. El sistema muestra un mensaje de confirmación “Se van a realizar cambios en la orden de trabajo, realmente desea guardarlos”. 15. El sistema modifica la orden de trabajo y la registra en la base de datos del sistema. 16. El caso de uso termina.
Excepciones
1. El código es nulo o no es válido.
Actor Sistema
2. __________________________________ 17. El sistema muestra uno de los siguientes mensajes como flujo alterno. “ERROR: El código no puede ser nulo” “ERROR: El código debe contener datos del tipo cadena”
94
18. vuelve a solicitar el código.
2. El código no se encuentra registrado.
Actor Sistema
3. __________________________________ 19. El sistema muestra un mensaje de error como flujo alterno. “ERROR: El código no se encuentra registrado” 20. vuelve a solicitar el código.
3. El dato o campo modificado es nulo o no es válido.
Actor Sistema
4. __________________________________________ 21. Para cada uno de los datos modificados el sistema muestra en pantalla que el dato es erróneo y espera su corrección mostrando unos de los siguientes mensajes como flujo alterno: “ERROR: El campo no puede ser nulo” “ERROR: El campo debe contener datos del tipo correcto” 22. vuelve a solicitar la modificación del campo erróneo
CU relacionados
Ninguno
Pre-condición
Iniciar Sesión
Post-condición
Ninguno
Prototipo (Interfaz de usuario)
Caso de uso 10. Registrar hoja de vida.
Caso Uso No
10
Nombre Registrar hoja de vida
Descripción Este caso de uso el usuario podrá ingresar los datos específicos correspondientes a la hoja de vida de cada equipo médico.
Estado Completo
Actores Técnico.
Guión
Actor Sistema
95
1. El usuario selecciona la opción ingresar hoja de vida del módulo de hojas de vida. 2. Ingresa el código del equipo. 3. Presiona ingresar hoja de vida. 8. El usuario ingresa las características técnicas como son tensión, corriente, potencia, resistencia, frecuencia, fuente, batería, fusible externo, fusible interno. 9. El usuario ingresa otros suministros como son agua, aire, 02, vacío. 10. El usuario ingresa otras características como son temperatura, humedad, peso, presión. 11. El usuario ingresa la descripción de accesorios. 12. El usuario ingresa
4. El sistema valida que el código no sea nulo y que contenga datos del tipo cadena. 5. El sistema verifica la existencia del código del equipo. 6. El sistema muestra en pantalla un formulario con los campos correspondientes a la hoja de vida de los equipos médicos 7. El sistema carga en el formulario el nombre, marca, modelo, serie, código y ubicación del equipo. 14. El sistema carga en pantalla el personal especializado para su operación.
96
las observaciones de accesorios. 13. El usuario selecciona el personal especializado para su operación (enfermero, odontólogo, higienista, circulante, medico, anestesiólogo). 15. El usuario ingresa otras observaciones. 16. El usuario presión ingresar hoja de vida.
17. El sistema valida que las características técnicas contengan datos del tipo numérico. 18. El Sistema valida que otros suministros contengan datos del tipo numérico. 19. El sistema valida que otras características contengan datos del tipo numérico. 20. El sistema valida que la descripción de accesorios contenga datos del tipo cadena. 21. El sistema valida que las observaciones de accesorios contenga datos del tipo cadena. 22. El sistema valida que otras observaciones contengan datos del tipo cadena. 23. El sistema muestra un mensaje “El ingreso de la hoja de vida ha sido exitoso” 24. El caso de uso termina.
Excepciones
9. El código es nulo o no es válido.
Actor Sistema
2. __________________________________________ 25. El sistema muestra en pantalla uno de los siguientes mensajes como flujo alterno. “ERROR: El código no puede ser nulo” “ERROR: El código debe contener datos del tipo cadena” 26. Vuelve a solicitar el código.
10. El código no se encuentra registrado.
Actor Sistema
3. __________________________________ 27. El sistema muestra un mensaje de error como flujo
97
alterno. “ERROR: El código no se encuentra registrado” 28. Vuelve a solicitar el código.
11. Las características técnicas es nulo o no son válidos.
Actor Sistema
4.__________________________________________ 29. El sistema muestra un mensaje de error como flujo alterno. “ERROR: Las características técnicas no pueden ser nulo” “ERROR: las características técnicas deben contener datos del tipo numérico” 30. Vuelve a solicitar las características técnicas del equipo.
12. Los suministros es nulo o no son válidos.
Actor Sistema
5.___________________________________________ 31. El sistema muestra un mensaje de error como flujo alterno. “ERROR: Los suministros no pueden ser nulo” “ERROR: los suministros deben contener datos del tipo numérico” 32. Vuelve a solicitar los suministros.
13. Las otras características es nulo o no son válidos.
Actor Sistema
6.__________________________________________ 33. El sistema muestra un mensaje de error como flujo alterno. “ERROR” las otras características no pueden ser nulo “ERROR: las otras características deben contener datos del tipo numérico” 34. Vuelve a solicitar las otras características.
14. La descripción de accesorios es nulo o no es válida.
Actor Sistema
8. __________________________________________ 37. El sistema muestra un mensaje de error como flujo alterno. “ERROR” La descripción de accesorios no puede ser nulo” “ERROR: La descripción de accesorios debe contener datos del tipo cadena” 38. Vuelve a solicitar la descripción de accesorios.
15. La observación de accesorios es nulo o no es válida.
Actor Sistema
98
9. ___________________________________ 39. El sistema muestra un mensaje de error como flujo alterno. “ERROR: la observación de accesorios no puede ser nulo” “ERROR: la observación de accesorios debe contener datos del tipo cadena” 40. vuelve a solicitar la observación de accesorios de accesorios.
16. Las otras observaciones son nulas o no son válidas.
Actor Sistema
10. _________________________________________ 41. El sistema muestra un mensaje de error como flujo alterno. “ERROR: Las observaciones deben contener datos del tipo cadena” 42. Vuelve a solicitar las observaciones.
CU relacionados
Ninguno
Pre-condición
Iniciar Sesión
Post-condición
Ninguno
Prototipo (Interfaz de usuario)
Caso de uso 11. Consultar hoja de vida
Caso Uso No 11
Nombre Consultar hoja de vida
Descripción Este caso de uso el usuario podrá consultar la hoja de vida de un equipo médico en particular.
Estado Completo
Actores Técnico.
Guión
Actor Sistema
1. El usuario selecciona la opción consultar hoja de vida del módulo de hojas de vida.
99
2. ingresa el código del equipo. 3. Presiona consultar equipo. 7. Presiona salir.
4. El sistema valida que el código del equipo no sea nulo y que contenga datos del tipo cadena. 5. El sistema verifica la existencia del código en el equipo. 6. El sistema muestra en pantalla un formulario de la hoja de vida del equipo con los datos específicos los cuales son: (nombre, marca, modelo, serie, ubicación código), las características técnicas (tensión, corriente, potencia, resistencia, frecuencia, nro. De fases, fuente, batería, fisible externo, fusible interno), los suministros (agua, aire, O2, vacío), otras características (temperatura, humedad, peso, presión), descripción de accesorios, observaciones de accesorios, personal especializado para su operación, personal responsable para el mantenimiento, otras observaciones, elaboro, aprobó. 8. El caso de uso termina.
Excepciones
1. El código es nulo o no es válido.
Actor Sistema
2.___________________________________________ 9. El sistema muestra en pantalla uno de los siguientes mensajes como flujo alterno. “ERROR: El campo código no puede ser nulo “ “ERROR: El código debe contener datos del tipo cadena”. 10. Solicita nuevamente el código.
2. El código no se encuentra registrado.
Actor Software
3. __________________________________________ 11. El sistema muestra un mensaje de error como flujo alterno. “ERROR: El código no se encuentra registrado en el sistema.” 12. Solicita nuevamente el código.
100
CU relacionados
Ninguno
Pre-condición
Iniciar Sesión
Post-condición
Ninguno
Prototipo (Interfaz de usuario)
Caso de uso 12. Modificar hoja de vida.
Caso Uso No 12
Nombre Modificar hoja de vida
Descripción Este caso de uso el usuario modificar los datos específicos correspondientes a la hoja de vida de cada equipo médicos.
Estado Completo
Actores Técnico.
Guión
Actor Sistema
1. El usuario selecciona la opción modificar hoja de vida del módulo de hojas de vida. 2. Ingresa el código del equipo. 3. Solicita al sistema la modificación de la hoja de vida mediante el botón modificar.
4. El sistema valida que el código no sea nulo y que contenga datos del tipo cadena. 5. El sistema verifica la existencia del código del equipo. 6. El sistema despliega en pantalla un formulario con los datos que contiene la hoja de vida los cuales son:
nombre
marca
modelo
serie
código
ubicación
características técnicas (tensión, corriente,
101
7. El usuario podrá modificar los campos necesarios. 9. El usuario presiona modificar hoja de vida. 12. El usuario confirma la modificación de la hoja de vida.
otras características (temperatura, humedad, peso, presión)
descripción de accesorios
observaciones de accesorios
personal especializado para su operación
otras observaciones 8. El sistema carga en pantalla el personal especializado para su operación. 10. El sistema valida que el o los datos modificados sean correctos de acuerdo al tipo de variable correspondiente de cada uno. 11. El sistema solicita al usuario confirmar los cambios realizados en la hoja de vida. 13. El sistema muestra un mensaje “las modificaciones se han realizado satisfactoriamente” 14. El sistema modifica la hoja de vida con los cambios realizados y la guarda. 15. El caso de uso termina.
Excepciones
1. El código es nulo o no es válido.
Actor Sistema
2. ________________________________________ 16. El sistema muestra uno de los siguientes mensajes como flujo alterno “ERROR: El código no puede ser nulo” “ERROR: El código debe contener datos del tipo cadena” 17. Vuelve a solicitar el código.
2. El código no se encuentra registrado.
Actor Sistema
3. __________________________________ 18. El sistema muestra un mensaje de error como flujo alterno. “ERROR: El código no se encuentra registrado”
102
19. Vuelve a solicitar el código.
3. El dato o campo modificado es nulo o no es válido.
Actor Sistema
4. ______________________________________ 20. Para cada uno de los datos modificados el sistema muestra en pantalla que el dato es erróneo y espera su corrección mostrando unos de los siguientes mensajes como flujo alterno. “ERROR: El campo no puede ser nulo” “ERROR: El campo debe contener datos del tipo correctos” 21. vuelve a solicitar la modificación del campo erróneo
CU relacionados
Ninguno
Pre-condición
Iniciar Sesión
Post-condición
Ninguno
Prototipo (Interfaz de usuario)
Caso de uso 13. Eliminar hoja de vida
Caso Uso No 13
Nombre Eliminar hoja de vida.
Descripción Este caso de uso el usuario podrá eliminar una hoja de vida que se encuentre almacenada en el sistema.
Estado Completo
Actores Técnico.
Guión
Actor Sistema
1. El usuario selecciona eliminar hoja de vida del módulo de hojas de vida 2. Ingresa el código del equipo. 3. Presiona Eliminar hoja de vida.
4. El sistema valida que el código no sea nulo y que contenga datos del tipo cadena. 5. El sistema verifica la existencia del código del equipo.
103
7. El usuario presiona eliminar. 9. El usuario confirma la eliminación de la hoja de vida.
6. El sistema muestra en pantalla la hoja de vida asociada al código del equipo. 8. El sistema solicita al usuario confirmar la eliminación de la hoja de vida ” Esta seguro que desea eliminar la hoja de vida y el equipo del inventario”. 10. El sistema elimina la hoja de vida del sistema y elimina el equipo del inventario físico funcional. 11. El caso de uso termina.
Excepciones
1. El código es nulo o no es válido.
Actor Sistema
2. __________________________________ 13. El sistema muestra uno de los siguientes mensajes como flujo alterno “ERROR: El código no puede ser nulo” “ERROR: El código debe contener datos del tipo cadena” 8. Vuelve a solicitar el código.
2. El código no se encuentra registrado.
Actor Sistema
3. __________________________________ 14. El sistema muestra un mensaje de error como flujo alterno. “ERROR: El código no se encuentra registrado” 15. Vuelve a solicitar el código.
3. Confirmación de eliminación de la hoja de vida.
Actor Software
4. ___________________________________ 16. El software muestra un mensaje de confirmación “Está seguro que desea eliminar la hoja de vida” 17. Si el usuario selecciona no vuelve a solicitar que seleccione una nueva hoja de vida.
CU Ninguno
104
relacionados
Pre-condición Iniciar Sesión
Post-condición Ninguno
Prototipo (Interfaz de usuario)
Caso de uso 14. Visualizar todos los equipos del inventario para mantenimiento.
Caso Uso No 14
Nombre Visualizar todos los equipos del inventario para mantenimiento.
Descripción Este caso de uso el usuario podrá visualizar todos los equipos que se encuentren en el inventario para mantenimiento.
Estado Completo
Actores Técnico.
Guión
Actor Sistema
1. El usuario ingresa al modulo de inventarios. 2. El usuario selecciona la opción de inventario para mantenimiento. 3. Presiona la opción ver quipos. 5. El usuario presiona volver.
4. El sistema despliega en pantalla una tabla con la información de todos los equipos que se encuentran registrados en el inventario para mantenimiento, con sus respectivos campos los cuales son:
nombre
código
ubicación
intervalo IPM(veces/año)
tipo
clase
prioridad(PI) 6. El caso de uso termina.
Excepciones
105
CU relacionados
Ninguno
Pre-condición Iniciar Sesión
Post-condición Ninguno
Prototipo (Interfaz de usuario)
Caso de uso 15. Visualizar todos los equipos del inventario de mantenimiento planificado del entorno.
Caso Uso No 15
Nombre Visualizar todos los equipos del inventario de mantenimiento planificado del entorno.
Descripción Este caso de uso el usuario podrá visualizar todos los equipos que se encuentren en el inventario de mantenimiento planificado del entorno.
Estado Completo
Actores Técnico.
Guión
Actor Sistema
1. El usuario ingresa al modulo de inventarios. 2. Selecciona la opción de inventario de mantenimiento planificado del entorno.
3. El sistema le pide al usuario que seleccione el área que desea consultar las cuales son:
hospitalización
urgencias
otorrino
oftalmología
lavandería
mantenimiento
terapia
odontología
quirófano
106
4. El usuario selecciona el área. 4. El usuario presiona volver.
esterilización
fisioterapia
5. Para cada uno de los áreas o entornos el sistema despliega en pantalla una tabla con la información de todos los equipos que se encuentran registrados en el entorno, con sus respectivos campos los cuales son:
Nombre
Código
Tipo
clase
frecuencia de mantenimiento
PI 5. El caso de uso termina.
Excepciones
CU relacionados
Ninguno
Pre-condición Iniciar Sesión
Post-condición Ninguno
Prototipo (Interfaz de usuario)
Caso de uso 16. Visualizar todos los equipos del inventario para mantenimiento
correctivo.
Caso Uso No 16
Nombre Visualizar todos los equipos del inventario para mantenimiento correctivo.
Descripción Este caso de uso el usuario podrá visualizar todos los equipos que se encuentren en el inventario de mantenimiento correctivo.
Estado Completo
Actores Técnico.
Guión
Actor Software
107
1. El usuario ingresa al modulo de inventarios. 2. El usuario selecciona la opción inventario para mantenimiento correctivo. 3. El usuario selecciona ver equipos. 5. El usuario presiona volver.
4. El sistema despliega en pantalla una tabla con la información de todos los equipos que se encuentran registrados en el inventario para mantenimiento correctivo, con sus respectivos campos los cuales son:
nombre
código
tipo
clase
PI 6. El caso de uso termina.
Excepciones
CU relacionados
Ninguno
Pre-condición Iniciar Sesión
Post-condición Ninguno
Prototipo (Interfaz de usuario)
Caso de uso 17. Consultar lista de comprobación de mantenimiento preventivo.
Caso Uso No 17
Nombre Consultar lista de comprobación de mantenimiento preventivo.
Descripción Este caso de uso el usuario podrá registrar una lista de comprobación de mantenimiento preventivo.
Estado Completo
Actores Técnico.
Guión
Actor Sistema
108
1. El usuario selecciona la opción lista de comprobación de mantenimiento preventivo del módulo de protocolos. 2. El usuario ingresa el código del equipo. 3. Presiona consultar. 7. El usuario presiona imprimir
4. El sistema valida que el código no sea nulo y que contenga datos del tipo cadena. 5. El sistema verifica la existencia del código del equipo en el inventario para mantenimiento. 6. El sistema muestra en pantalla un documento en formato .doc de la lista de comprobación de mantenimiento preventivo. 8. El sistema manda imprimir el documento. 9. El caso de uso termina.
Excepciones
1. El código es nulo o no es válido.
Actor Sistema
2. ___________________________________ 11. El sistema muestra uno de los siguientes mensajes como flujo alterno. “ERROR: El código no puede ser nulo” “ERROR: El código debe contener datos del tipo cadena” 12. Vuelve a solicitar el código.
2. El código no se encuentra registrado.
Actor Sistema
3._____________________________________ 13. El sistema muestra un mensaje de error como flujo alterno. “ERROR: El código no se encuentra registrado en el inventario para mantenimiento” 14. Vuelve a solicitar el código.
CU relacionados
Ninguno
Pre-condición Iniciar Sesión
Post-condición
Ninguno
109
Prototipo (Interfaz de usuario)
Caso de uso 18. Consultar lista de comprobación de mantenimiento planificado del
entorno.
Caso Uso No 18
Nombre Consultar lista de comprobación de mantenimiento planificado del entorno.
Descripción Este caso de uso el usuario podrá registrar una lista de comprobación de mantenimiento planificado del entorno.
Estado Completo
Actores Técnico.
Guión
Actor Sistema
1. El usuario selecciona la opción lista de comprobación de mantenimiento planificado del entorno del módulo de protocolos. 2. El usuario selecciona el entorno (hospitalización, urgencias, otorrino, oftalmología, lavandería, mantenimiento, terapia, odontología, quirófano, esterilización, fisioterapia). 4. El usuario selecciona imprimir lista de comprobación de mantenimiento planificado del entorno.
3. El software muestra en pantalla un documento en formato .doc de la lista de comprobación de mantenimiento planificado del entrono correspondiente. 5. El sistema manda a imprimir el documento 6. El caso de uso termina.
Excepciones
1. El entorno no se ha seleccionado.
Actor Sistema
2.___________________________________ 29. El sistema muestra un mensaje de error como flujo alterno. “ERROR: Debe seleccionar el entorno”. 30. Solicita nuevamente el entorno.
CU relacionados
Ninguno
Pre-condición Iniciar Sesión
Post- Ninguno
110
condición
Prototipo (Interfaz de usuario)
Caso de uso 19. Consultar indicador de disponibilidad.
Caso Uso No 19
Nombre Consultar indicador de disponibilidad.
Descripción Este caso de uso el usuario podrá consultar el porcentaje de disponibilidad de los equipos médicos.
Estado Completo
Actores Técnico.
Guión
Actor Sistema
1. El usuario selecciona la opción indicador de disponibilidad del módulo de indicadores de gestión. 2. Presiona consultar. 4. Presiona salir.
3. El sistema calcula el valor y muestra en pantalla en porcentaje (%) que corresponde al indicador de disponibilidad. 5. El caso de uso termina.
Excepciones
CU relacionados
Ninguno
Pre-condición Iniciar Sesión
Post-condición Ninguno
Prototipo (Interfaz de usuario)
111
Caso de uso 20. Consultar indicador de eficacia de mantenimiento correctivo.
Caso Uso No 20
Nombre Consultar indicador de eficacia de mantenimiento correctivo.
Descripción Este caso de uso el usuario podrá consultar el porcentaje de eficacia de mantenimiento correctivo.
Estado Completo
Actores Técnico.
Guión
Actor Sistema
1. El usuario selecciona la opción indicador de eficacia de mantenimiento correctivo del módulo de indicadores de gestión. 2. Presiona consultar. 4. Presiona salir.
3. El sistema calcula el valor y muestra en pantalla el porcentaje (%) que corresponde al indicador de eficacia de mantenimiento correctivo. 5. El caso de uso termina.
Excepciones
CU relacionados
Ninguno
Pre-condición Iniciar Sesión
Post-condición Ninguno
Prototipo (Interfaz de usuario)
Caso de uso 21. Consultar indicador de falsas solicitudes.
112
Caso Uso No 21
Nombre Consultar indicador de falsas solicitudes.
Descripción Este caso de uso el usuario podrá consultar el porcentaje de falsas solicitudes.
Estado Completo
Actores Técnico.
Guión
Actor Sistema
1. El usuario selecciona la opción indicador de falsas solicitudes del módulo de indicadores de gestión. 2. Presiona consultar. 4. Presiona salir.
3. El sistema calcula el valor y muestra en pantalla el porcentaje (%) que corresponde al indicador de falsas solicitudes. 10. El caso de uso termina.
Excepciones
CU relacionados
Ninguno
Pre-condición Iniciar Sesión
Post-condición Ninguno
Prototipo (Interfaz de usuario)
Caso de uso 22. Consultar el plan de mantenimiento preventivo anual.
Caso Uso No 22
Nombre Consultar el plan de mantenimiento preventivo anual.
Descripción En este caso de uso el usuario podrá consultar el plan de mantenimiento preventivo anual, el cual le permite seleccionar el día exacto en que debe realizar el mantenimiento a cada equipo médico específicamente.
Estado Completo
Actores Técnico.
Guión
Actor Sistema
113
1. El usuario ingresa al módulo de plan de mantenimiento. 2. Presiona la opción ver plan de mantenimiento preventivo anual. 4. El usuario presiona volver.
3. El sistema despliega en pantalla una tabla compuesta por el nombre de los equipos, código y la ubicación, incluidos en el plan de mantenimiento preventivo anual y una tabla con el nombre de fecha de mantenimiento en la cual el usuario podrá seleccionar la fecha en que se le realiza el mantenimiento al equipo médico. 5. El caso de uso termina
Excepciones
CU relacionados
Ninguno
Pre-condición Iniciar Sesión
Post-condición Ninguno
Prototipo (Interfaz de usuario)
114
ANEXO B: DIAGRAMAS DE CLASE. Diagrama de clase 1. Iniciar sesión.
Diagrama de clase 2. Registrar equipo.
115
Diagrama de clase 3. Consultar equipo.
116
Diagrama de clase 4. Modificar equipo.
117
Diagrama de clase 5. Visualizar equipos inventario físico-funcional.
118
Diagrama de clase 6. Registrar orden de trabajo.
119
120
Diagrama de clase 7. Consultar orden de trabajo.
121
Diagrama de clase 8. Eliminar orden de trabajo.
122
Diagrama de clase 9. Modificar orden de trabajo.
123
Diagrama de clase 10. Registrar hoja de vida.
124
Diagrama de clase 11. Consultar hoja de vida.
125
Diagrama de clase 12. Modificar hoja de vida.
126
Diagrama de clase 13. Eliminar hoja de vida.
127
Diagrama de clase 14. Visualizar equipos inventario mantenimiento.
Diagrama de clase 15. Visualizar equipos inventario mantenimiento planificado del entorno.
128
Diagrama de clase 16. Visualizar equipos inventario mantenimiento correctivo.
Diagrama de clase 19. Consultar indicador disponibilidad.
129
Diagrama de clase 20. Consultar indicador eficacia mantenimiento correctivo.
Diagrama de clase 21. Consultar indicador falsas solicitudes.
130
Diagrama de clase 22. Consultar plan anual.
131
ANEXO C: Diagramas de secuencia Caso de uso 1. Iniciar sesión.
132
Caso de uso 2. Registrar equipo.
133
Caso de uso 3. Consultar equipo.
134
Caso de uso 4. Modificar equipo.
135
Caso de uso 5. Visualizar equipos inventario físico-funcional.
136
Caso de uso 6. Registrar orden de trabajo.
137
Caso de uso 7. Consultar orden de trabajo.
138
Caso de uso 8. Eliminar orden de trabajo.
139
Caso de uso 9. Modificar orden de trabajo.
140
Caso de uso 10. Registrar Hoja de vida.
141
Caso de uso 11. Consultar Hoja de vida.
142
Caso de uso 12. Modificar Hoja de vida.
143
Caso de uso 13. Eliminar Hoja de vida.
144
Caso de uso 14. Visualizar equipos inventario para mantenimiento.
145
Caso de uso 15. Visualizar equipos inventario para mantenimiento entorno.
146
Caso de uso 16. Visualizar equipos inventario para mantenimiento correctivo.
147
Caso de uso 17. Consultar lista de comprobación mantenimiento preventivo.
148
Caso de uso 18. Consultar lista de comprobación mantenimiento del entorno.
149
Caso de uso 19. Consultar indicador disponibilidad.
150
Caso de uso 20. Consultar indicador eficacia de mantenimiento correctivo.
151
Caso de uso 21. Consultar indicador falsas solicitudes.
152
Caso de uso 22. Consultar plan anual.
153
ANEXO D: Pruebas funcionales o caja negra
Prueba funcional: Iniciar sesión.
Entrada Validación y/o verificación
Login 1. El campo login está vacío. 2. El campo login no está vacío 3. El login existe. 4. El login no existe.
password 5. El password coincide con el login. 6. El password no coincide con el login.
Diseño de pruebas relevantes: iniciar sesión.
No. Caso Prueba 1 Nombre Entrada login Nombre Caso de Prueba o Regla asociada El campo login está vacío. Valor Entrada “” o null
Supuesto: El valor de la entrada debe ser alfanumérico o numérico.
Salida Esperada “Debe digitar su nombre de usuario” Precondición Poscondición No podrá acceder al sistema.
No. Caso Prueba 4 Nombre Entrada login Nombre Caso de Prueba o Regla asociada El login no existe. Valor Entrada “usuario beta”
Supuesto: El valor de la entrada debe ser alfanumérico o numérico.
Salida Esperada “nombre de usuario o password incorrectos”
Precondición Poscondición No podrá acceder al sistema.
No. Caso Prueba 6 Nombre Entrada Password Nombre Caso de Prueba o Regla asociada El password no coincide con el login. Valor Entrada ********
Supuesto: El valor de la entrada debe
154
ser alfanumérico o numérico, tipo password.
Salida Esperada “nombre de usuario o password incorrectos”
Precondición Poscondición No podrá acceder al sistema.
Prueba funcional: Registrar equipo.
Entrada Validación y/o verificación
Nombre 1. El campo nombre está vacío. 2. El campo nombre no está vacío
Marca 2. El campo marca está vacío. 3. El campo marca no está vacío.
Modelo 4. El campo modelo está vacío. 5. El campo modelo no está vacío.
Serie 6. El campo serie está vacío.
7. El campo serie no está vacío.
Ubicación 8. No seleccionó una ubicación. 9. Seleccionó una ubicación.
Nivel de riesgo 10. No seleccionó un nivel de riesgo. 11. Seleccionó un nivel de riesgo.
Manual 12. No seleccionó un manual.
13. Seleccionó un manual.
Forma de adquisición
14. No seleccionó una forma de adquisición.
15. Seleccionó una forma de adquisición.
Función del equipo
16. No seleccionó una función del equipo.
17. Seleccionó una función del equipo.
Aplicación clínica 18. No seleccionó una aplicación clínica.
19. Seleccionó una aplicación clínica.
Requerimiento de mantenimiento
20. No seleccionó un requerimiento de mantenimiento.
21. Seleccionó un requerimiento de mantenimiento.
Historial de fallas 22. No seleccionó un historial de fallas.
23. Seleccionó un historial de fallas.
Tipo 24. No seleccionó un tipo.
25. Seleccionó un tipo.
155
Clase 26. No seleccionó una clase.
27. Seleccionó una clase.
Intervalo IPM 28. No seleccionó un intervalo IPM.
29. Seleccionó un intervalo IPM.
Diseño de pruebas relevantes: Registrar equipo.
No. Caso Prueba 1 Nombre Entrada Nombre Nombre Caso de Prueba o Regla asociada El campo nombre está vacío. Valor Entrada “” o null
Supuesto: El valor de la entrada debe ser alfanumérico o numérico.
Salida Esperada “Debe digitar su nombre del equipo” Precondición Poscondición No se podrá agregar el nombre al
equipo.
No. Caso Prueba 9 Nombre Entrada Ubicación Nombre Caso de Prueba o Regla asociada No selecciono una ubicación. Valor Entrada -Seleccione-
Supuesto: La ubicación podría ser “Urgencias”
Salida Esperada “Debe seleccionar cual será la ubicación”
Precondición Poscondición No se creara código al equipo, no podrá
consultar equipos del inventario.
No. Caso Prueba 17 Nombre Entrada Función del equipo Nombre Caso de Prueba o Regla asociada No selecciono una función del equipo. Valor Entrada -Seleccione-
Supuesto: La función podría ser “Soporte de vida”
Salida Esperada “Debe seleccionar cual será la función del equipo”
156
Precondición Haber seleccionado la clase. Poscondición No se calculara el nivel de prioridad PI
al equipo médico.
No. Caso Prueba 19 Nombre Entrada Aplicación clínica Nombre Caso de Prueba o Regla asociada No selecciono una aplicación clínica. Valor Entrada -Seleccione-
Supuesto: La aplicación clinica podría ser “Falso diagnostico”
Salida Esperada “Debe seleccionar cual será la aplicación clinica”
Precondición Haber seleccionado el manual. Poscondición No se calculara el nivel de prioridad PI
al equipo médico.
No. Caso Prueba 29 Nombre Entrada Intervalo IPM Nombre Caso de Prueba o Regla asociada No selecciono un intervalo IPM. Valor Entrada -Seleccione-
Supuesto: La ubicación podría ser “2-3”
Salida Esperada “Debe seleccionar cual será el intervalo IPM”
Precondición Haber seleccionado el tipo Poscondición No se calculara el nivel de prioridad PI
al equipo médico.
Prueba funcional: Consultar equipo.
Entrada Validación y/o verificación
Código 1. El campo código esta vacío. 2. El campo código no está vacío. 3. El campo código existe. 4. El campo código no existe.
Diseño de pruebas relevantes consultar equipo.
No. Caso Prueba 1 Nombre Entrada código Nombre Caso de Prueba o Regla asociada El campo código está vacío.
157
Valor Entrada “” o null Supuesto: El valor de la entrada debe ser alfanumérico o numérico.
Salida Esperada “Debe digitar el código del equipo para realizar la búsqueda”
Precondición Se deben haber almacenado equipos Poscondición No podrá ver la información dele quipo
No. Caso Prueba 4 Nombre Entrada Código Nombre Caso de Prueba o Regla asociada El campo código no existe. Valor Entrada “codigo1”
Supuesto: El valor de la entrada debe ser alfanumérico o numérico.
Salida Esperada “no hay información relacionada a ese código”
Precondición Se deben haber almacenado equipos Poscondición No podrá acceder al sistema.
Prueba funcional: Modificar equipo.
Entrada Validación y/o verificación
Código 1. El campo código está vacío. 2. El campo código no está vacío. 3. El campo código existe. 4. El campo código no existe.
Nombre 5. El campo nombre está vacío. 6. El campo nombre no está vacío
Marca 7. El campo marca está vacío. 8. El campo marca no está vacío.
Modelo 9. El campo modelo está vacío. 10. El campo modelo no está vacío.
Serie 11. El campo serie está vacío.
12. El campo serie no está vacío.
Ubicación 13. No seleccionó una ubicación. 14. Seleccionó una ubicación.
Nivel de riesgo 15. No seleccionó un nivel de riesgo. 16. Seleccionó un nivel de riesgo.
Manual 17. No seleccionó un manual.
18. Seleccionó un manual.
158
Forma de adquisición
19. No seleccionó una forma de adquisición.
20. Seleccionó una forma de adquisición.
Función del equipo
21. No seleccionó una función del equipo.
22. Seleccionó una función del equipo.
Aplicación clínica 23. No seleccionó una aplicación clínica.
24. Seleccionó una aplicación clínica.
Requerimiento de mantenimiento
25. No seleccionó un requerimiento de mantenimiento.
26. Seleccionó un requerimiento de mantenimiento.
Historial de fallas 27. No seleccionó un historial de fallas.
28. Seleccionó un historial de fallas.
Tipo 29. No seleccionó un tipo.
30. Seleccionó un tipo.
Clase 31. No seleccionó una clase.
32. Seleccionó una clase.
Intervalo IPM 33. No seleccionó un intervalo IPM.
34. Seleccionó un intervalo IPM.
Diseño de pruebas relevantes modificar equipo.
No. Caso Prueba 1 Nombre Entrada código Nombre Caso de Prueba o Regla asociada El campo código está vacío. Valor Entrada “” o null
Supuesto: El valor de la entrada debe ser alfanumérico o numérico.
Salida Esperada “Debe digitar el código del equipo para realizar la búsqueda”
Precondición Se deben haber almacenado equipos Poscondición No podrá modificar el equipo.
No. Caso Prueba 4 Nombre Entrada Código Nombre Caso de Prueba o Regla asociada El campo código no existe. Valor Entrada “codigo1”
Supuesto: El valor de la entrada debe ser alfanumérico o numérico.
Salida Esperada “no hay información relacionada a ese código”
Precondición Se deben haber almacenado equipos Poscondición No podrá modificar el equipo.
159
No. Caso Prueba 5 Nombre Entrada Nombre Nombre Caso de Prueba o Regla asociada El campo nombre está vacío. Valor Entrada “” o null
Supuesto: El valor de la entrada debe ser alfanumérico o numérico.
Salida Esperada “Debe digitar su nombre del equipo” Precondición Poscondición No podrá modificar el equipo.
No. Caso Prueba 13 Nombre Entrada Ubicación Nombre Caso de Prueba o Regla asociada No selecciono una ubicación. Valor Entrada -Seleccione-
Supuesto: La ubicación podría ser “Urgencias”
Salida Esperada “Debe seleccionar cual será la ubicación”
Precondición Poscondición No podrá modificar el equipo.
No. Caso Prueba 21 Nombre Entrada Función del equipo Nombre Caso de Prueba o Regla asociada No selecciono una función del equipo. Valor Entrada -Seleccione-
Supuesto: La función podría ser “Soporte de vida”
Salida Esperada “Debe seleccionar cual será la función del equipo”
Precondición Haber seleccionado la clase. Poscondición No podrá modificar el equipo.
No. Caso Prueba 23 Nombre Entrada Aplicación clínica Nombre Caso de Prueba o Regla asociada No selecciono una aplicación clínica. Valor Entrada -Seleccione-
Supuesto: La aplicación clinica podría ser “Falso diagnostico”
Salida Esperada “Debe seleccionar cual será la
160
aplicación clinica” Precondición Haber seleccionado el manual. Poscondición No podrá modificar el equipo.
No. Caso Prueba 33 Nombre Entrada Intervalo IPM Nombre Caso de Prueba o Regla asociada No selecciono un intervalo IPM. Valor Entrada -Seleccione-
Supuesto: La ubicación podría ser “2-3”
Salida Esperada “Debe seleccionar cual será el intervalo IPM”
Precondición Haber seleccionado el tipo Poscondición No podrá modificar el equipo.
Prueba funcional: Registrar orden de trabajo.
Entrada Validación y/o verificación
Código 1. El campo código está vacío. 2. El campo código no está vacío. 3. El campo código existe. 4. El campo código no existe.
Fecha de solicitud 5. No se seleccionó fecha de solicitud. 6. Selecciono fecha de solicitud.
Hora de solicitud 7. No selecciono hora de solicitud.