SISTEMA AUTOMATIZADO PARA GESTIÓN DE MANTENIMIENTO DE …

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 _________________________________

Jurado Santiago de Cali, 24 de Noviembre de 2011

4

CONTENIDO

Pág.

GLOSARIO ........................................................................................................... 10 RESUMEN ............................................................................................................ 11

INTRODUCCIÓN .................................................................................................. 12

1. PLANTEAMIENTO DEL PROBLEMA ............................................................. 14

2. JUSTIFICACIÓN .............................................................................................. 16

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

18. RECOMENDACIONES ................................................................................. 710

BIBLIOGRAFÍA .................................................................................................. 721

ANEXOS ............................................................................................................. 743

8

LISTA DE CUADROS

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.

http://www.scribd.com/doc/4184016/TFC-Gestion-Integral-del-Mantenimiento


17

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

http://www.vision.ime.usp.br/~elier/sgt.pdf

19

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

http://www.rqct.com/download/Guia%20Rapida%20MS2000.doc

http://www.mpsoftware.com.mx/es/downloads/Informacion%20general.pdf

20

4. MARCO TEÓRICO

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

http://www.procuraduria.gov.co/infosim/media/file/VERSIONES_EN_PDF/Etapa4-ReqNoFunc.pdf

43

Memoria RAM SDRAM 256MB o superior.

Disco duro de 20GB o superior.

Cache 256KB o superior.

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


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



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

http://www.fdi.ucm.es/profesor/jpavon/poo/2.14.MVC.pdf

60

13. MODELADO DE DATOS

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



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


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


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.


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


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


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

http://revista.eia.edu.co/articulos10/art7.pdf

http://www.fdi.ucm.es/profesor/jpavon/poo/2.14.MVC.pdf

http://www.hab2001.sld.cu/arrepdf/00187.pdf



73

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


http://www.vision.ime.usp.br/~elier/sgt.pdf

http://www.rqct.com/download/Guia%20Rapida%20MS2000.doc

74

ANEXOS

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


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



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


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


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


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


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.


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


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




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


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.


Actor Software


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


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


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


Post-condición

Ninguno


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


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.


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


Post-condición

Ninguno


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


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.


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.


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


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


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.


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


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


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.


Actor Software


100

CU relacionados

Ninguno

Pre-condición

Iniciar Sesión

Post-condición

Ninguno


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.

potencia, resistencia, frecuencia, frecuencia, fuente, batería, fusible externo, fusible interno)

otros 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

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


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.


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.


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


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


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.


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




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




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




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




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


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.


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


Post-condición

Ninguno

109


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


Post- Ninguno

110

condición


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




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




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




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




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.

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.


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”


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.





Serie 6. El campo serie está vacío.

7. El campo serie no está vacío.



Manual 12. No seleccionó un manual.

13. Seleccionó un manual.


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.


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


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”


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”


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”


Precondición Haber seleccionado el tipo Poscondición No se calculara el nivel de prioridad PI

al equipo médico.

Prueba funcional: Consultar equipo.


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”


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.


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.




Serie 11. El campo serie está vacío.

12. El campo serie no está vacío.



Manual 17. No seleccionó un manual.

18. Seleccionó un manual.

158


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.


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



Precondición Se deben haber almacenado equipos Poscondición No podrá modificar el equipo.




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


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”


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”


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”


Precondición Haber seleccionado el tipo Poscondición No podrá modificar el equipo.

Prueba funcional: Registrar orden de trabajo.



Fecha de solicitud 5. No se seleccionó fecha de solicitud. 6. Selecciono fecha de solicitud.

Hora de solicitud 7. No selecciono hora de solicitud.

8. Selecciono hora de solicitud.

Falsa solicitud 9. No selecciono falsa solicitud. 10. Selecciono falsa solicitud.

Fecha de reporte de servicio técnico

11. No selecciono fecha de reporte de servicio técnico. 12. Selecciono fecha de reporte de servicio técnico.

Hora de reporte de servicio técnico

13. No selecciono hora de reporte de servicio técnico. 14. Selecciono hora de reporte de servicio técnico.

Cargo de persona que solicita el servicio

15. No selecciono cargo de la persona que solicita el servicio.

16. Selecciono cargo de la persona que solicita el servicio.

Nombre de persona que solicita el servicio

17. El campo nombre de persona que solicita el servicio está vacío.

18. El campo nombre de la persona que solicita el

161

servicio no está vacío.

Descripción detallada de la solicitud de servicio

19. El campo descripción detallada de la solicitud del servicio está vacío.

20. El campo descripción detallada de la solicitud del servicio no está vacío.

Especificaciones de servicio

21. El campo especificaciones de servicio está vacío. 22. El campo especificaciones de servicio no está vacío.

Descripción de los materiales

23. El campo descripción de los materiales está vacío. 24. El campo descripción de los materiales no está vacío.

Cantidad de materiales

25. El campo cantidad de materiales está vacío. 26. El campo cantidad de materiales no está vacío.

Costo de materiales

27. El campo costo de los materiales está vacío. 28. El campo costo de los materiales no está vacío.

Costo total de materiales

29. El campo costo total de materiales está vacío. 30. El campo costo total de materiales no está vacío.

observaciones 31. El campo observaciones está vacío. 32. El campo observaciones no está vacío.

Fecha de alta del equipo

33. No selecciono la fecha de alta del equipo. 34. Selecciono la fecha de alta dele quipo.

Hora de alta del equipo

35. No selecciono la hora de alta del equipo.

36. Selecciono la hora de alta del equipo.

Diseño de pruebas relevantes Registrar orden de trabajo.




Precondición Se deben haber almacenado equipos Poscondición No podrá registrar orden de trabajo.

No. Caso Prueba 9 Nombre Entrada Falsa solicitud Nombre Caso de Prueba o Regla asociada No selecciono falsa solicitud Valor Entrada -seleccione-

Supuesto: la falsa solicitud podría ser “Si”

Salida Esperada Precondición Debe seleccionar cual será la falsa

162

solicitud. Poscondición No podrá registrar orden de trabajo.

No. Caso Prueba 15 Nombre Entrada Cargo de persona que solicita el

servicio. Nombre Caso de Prueba o Regla asociada No selecciono el cargo de la persona

que solicita el servicio. Valor Entrada -Seleccione-

Supuesto: el cargo de la persona que solicita el servicio podría ser “Medico”

Salida Esperada Precondición Debe seleccionar cual será el cargo de

la persona que solicita el servicio. Poscondición No podrá registrar orden de trabajo.

No. Caso Prueba 21 Nombre Entrada Especificaciones de servicio. Nombre Caso de Prueba o Regla asociada El campo especificaciones de servicio

está vacío. Valor Entrada “” o null

Supuesto: El valor de la entrada debe ser de tipo cadena.

Salida Esperada Precondición Se deben haber almacenado equipos Poscondición No podrá agregar las especificaciones

de servicio.

No. Caso Prueba 29 Nombre Entrada Costo total de materiales Nombre Caso de Prueba o Regla asociada El campo costo total de materiales está

vacío. Valor Entrada “” o null

Supuesto: El valor de la entrada debe ser numérico.

Salida Esperada “debe ingresar el costo unitario de los materiales”

Precondición Se deben haber almacenado equipos Poscondición No podrá calcular el costo total de los

materiales. No. Caso Prueba 35 Nombre Entrada Hora de alta del equipo Nombre Caso de Prueba o Regla asociada No se seleccionó la hora de alta del

163

equipo. Valor Entrada -Seleccione-

Supuesto: la hora de alta del equipo podría ser “13:00”

Salida Esperada “debe seleccionar la fecha del alta del equipo”

Precondición Se deben haber almacenado equipos Poscondición No podrá agregar la hora de alta del

equipo.

Prueba funcional: Consultar orden de trabajo.



Diseño de pruebas relevantes Consultar orden de trabajo




Precondición Se deben haber almacenado equipos Poscondición No podrá ver la información de la orden

de trabajo




Precondición Se deben haber almacenado equipos Poscondición No podrá acceder al formulario de

orden de trabajo.

164

Prueba funcional: Eliminar orden de trabajo.



Diseño de pruebas relevantes Eliminar orden de trabajo




Precondición Se deben haber almacenado equipos Poscondición No podrá eliminar la orden de trabajo




Precondición Se deben haber almacenado equipos Poscondición No podrá eliminar la orden de trabajo

Prueba funcional: Modificar orden de trabajo.



165

Fecha de solicitud 5. No se seleccionó fecha de solicitud. 6. Selecciono fecha de solicitud.

Hora de solicitud 7. No selecciono hora de solicitud.

8. Selecciono hora de solicitud.

Falsa solicitud 9. No selecciono falsa solicitud. 10. Selecciono falsa solicitud.

Fecha de reporte de servicio técnico

11. No selecciono fecha de reporte de servicio técnico. 12. Selecciono fecha de reporte de servicio técnico.

Hora de reporte de servicio técnico

13. No selecciono hora de reporte de servicio técnico. 14. Selecciono hora de reporte de servicio técnico.

Cargo de persona que solicita el servicio

15. No selecciono cargo de la persona que solicita el servicio.

16. Selecciono cargo de la persona que solicita el servicio.

Nombre de persona que solicita el servicio

17. El campo nombre de persona que solicita el servicio está vacío.

18. El campo nombre de la persona que solicita el servicio no está vacío.

Descripción detallada de la solicitud de servicio

19. El campo descripción detallada de la solicitud del servicio está vacío.

20. El campo descripción detallada de la solicitud del servicio no está vacío.

Especificaciones de servicio

21. El campo especificaciones de servicio está vacío. 22. El campo especificaciones de servicio no está vacío.

Descripción de los materiales

23. El campo descripción de los materiales está vacío. 24. El campo descripción de los materiales no está vacío.

Cantidad de materiales

25. El campo cantidad de materiales está vacío. 26. El campo cantidad de materiales no está vacío.

Costo de materiales

27. El campo costo de los materiales está vacío. 28. El campo costo de los materiales no está vacío.

Costo total de materiales

29. El campo costo total de materiales está vacío. 30. El campo costo total de materiales no está vacío.

observaciones 31. El campo observaciones está vacío. 32. El campo observaciones no está vacío.

Fecha de alta del equipo

33. No selecciono la fecha de alta del equipo. 34. Selecciono la fecha de alta dele quipo.

Hora de alta del equipo

35. No selecciono la hora de alta del equipo.

36. Selecciono la hora de alta del equipo.

Diseño de pruebas relevantes Modificar orden de trabajo.

166




Precondición Se deben haber almacenado equipos Poscondición No podrá modificar orden de trabajo.

No. Caso Prueba 9 Nombre Entrada Falsa solicitud Nombre Caso de Prueba o Regla asociada No selecciono falsa solicitud Valor Entrada -seleccione-

Supuesto: la falsa solicitud podría ser “Si”

Salida Esperada Precondición Debe seleccionar cual será la falsa

solicitud. Poscondición No podrá modificar orden de trabajo.

No. Caso Prueba 15 Nombre Entrada Cargo de persona que solicita el

servicio. Nombre Caso de Prueba o Regla asociada No selecciono el cargo de la persona

que solicita el servicio. Valor Entrada -Seleccione-

Supuesto: el cargo de la persona que solicita el servicio podría ser “Medico”

Salida Esperada Precondición Debe seleccionar cual será el cargo de

la persona que solicita el servicio. Poscondición No podrá actualizar el cargo de la

persona que solicita el servicio a la orden de trabajo.

No. Caso Prueba 21 Nombre Entrada Especificaciones de servicio. Nombre Caso de Prueba o Regla asociada El campo especificaciones de servicio

está vacío. Valor Entrada “” o null

Supuesto: El valor de la entrada debe ser de tipo cadena.

167

Salida Esperada Precondición Se deben haber almacenado equipos Poscondición No podrá agregar las especificaciones

de servicio.

No. Caso Prueba 29 Nombre Entrada Costo total de materiales Nombre Caso de Prueba o Regla asociada El campo costo total de materiales está

vacío. Valor Entrada “” o null


Salida Esperada “debe ingresar el costo unitario de los materiales”

Precondición Se deben haber almacenado equipos Poscondición No podrá calcular el costo total de los

materiales.

No. Caso Prueba 35 Nombre Entrada Hora de alta del equipo Nombre Caso de Prueba o Regla asociada No se seleccionó la hora de alta del

equipo. Valor Entrada -Seleccione-

Supuesto: la hora de alta del equipo podría ser “13:00”

Salida Esperada “debe seleccionar la fecha del alta del equipo”

Precondición Se deben haber almacenado equipos Poscondición No podrá actualizar la hora de alta del

equipo.

Prueba funcional: Registrar hoja de vida.



Tensión 5. El campo tensión está vacío. 6. El campo tensión no está vacío.

Corriente 7. El campo corriente está vacío.

168

8. El campo corriente no está vacío.

Potencia 9. El campo potencia está vacío. 10. El campo potencia no está vacío.

Resistencia 11. El campo resistencia está vacío. 12. El campo resistencia no está vacío.

Frecuencia 13. El campo frecuencia está vacío. 14. El campo frecuencia no está vacío.

Fuente 15. El campo fuente está vacío. 16. El campo fuente no está vacío.

Batería 17. El campo batería está vacío. 18. El campo batería no está vacío.

Fusible externo 19. El campo fusible externo está vacío. 20. El campo fusible externo no está vacío.

Fusible interno 21. El campo fusible interno está vacío. 22. El campo fusible interno no está vacío.

Agua 23. El campo agua está vacío. 24. El campo agua no está vacío.

Aire 25. El campo aire está vacío. 26. El campo aire no está vacío.

Oxigeno 27. El campo oxigeno está vacío. 28. El campo oxigeno no está vacío.

Vacío 29. El campo vacío está vacío. 30. El campo vacío no está vacío.

Temperatura 31. El campo temperatura está vacío. 32. El campo temperatura no está vacío.

Humedad 33. El campo humedad está vacío. 34. El campo humedad no está vacío.

Peso 35. El campo peso está vacío. 36. El campo peso no está vacío.

Presión 37. El campo presión está vacío. 38. El campo presión no está vacío.

Descripción de accesorios

39. El campo descripción de accesorios está vacío. 40. El campo descripción de accesorios no está vacío.

Observación de accesorios

41. El campo observación de accesorios está vacío. 42. El campo observación de accesorios no está vacío.

Personal especializado para su operación

43. No selecciono el personal especializado para su

operación.

44. Selecciono el personal especializado para su

169

operación.

Otras observaciones

45. El campo otras observaciones está vacío. 46. El campo otras observaciones no está vacío.

Diseño de pruebas relevantes Registrar hoja de vida.




Precondición Se deben haber almacenado equipos Poscondición No podrá registrar hoja de vida.

No. Caso Prueba 11 Nombre Entrada Resistencia Nombre Caso de Prueba o Regla asociada El campo resistencia esta vacío Valor Entrada “” o null

Supuesto: el valor de la resistencia debe ser numérico.

Salida Esperada Precondición Debe haber almacenado equipos Poscondición No podrá agregar la resistencia.

No. Caso Prueba 19 Nombre Entrada Fusible externo Nombre Caso de Prueba o Regla asociada El campo fusible externo esta vacío Valor Entrada “” o null

Supuesto: El fusible externo podría ser “Si”

Salida Esperada Precondición Debe haber almacenado equipos Poscondición No podrá agregar el fusible externo

No. Caso Prueba 25

170

Nombre Entrada Aire Nombre Caso de Prueba o Regla asociada El campo aire esta vacio Valor Entrada “” o null

Supuesto: El valor de la entrada debe ser de tipo numerico

Salida Esperada Precondición Se deben haber almacenado equipos Poscondición No podrá actualizar el aire

No. Caso Prueba 31 Nombre Entrada Temperatura Nombre Caso de Prueba o Regla asociada El campo temperatura está vacío. Valor Entrada “” o null


Salida Esperada “debe ingresar las características tecnicas”

Precondición Se deben haber almacenado equipos Poscondición No podrá agregar la temperatura

No. Caso Prueba 39 Nombre Entrada Descripción de accesorios Nombre Caso de Prueba o Regla asociada El campo descripción de accesorios

está vacío Valor Entrada “” o null

Supuesto: la descripción de accesorios podría ser “funda de plastico”

Salida Esperada “debe seleccionar accesorios del equipo”

Precondición Se deben haber almacenado equipos Poscondición No podrá agregar la descripción de

accesorios

No. Caso Prueba 45 Nombre Entrada Otras observaciones Nombre Caso de Prueba o Regla asociada El campo otras observaciones esta

vacio Valor Entrada “” o null

Supuesto: la descripción de otras observaciones podría ser “cable pelado”

Salida Esperada “debe haber seleccionado observaciones adicionales”

171

Precondición Se deben haber almacenado equipos Poscondición No podrá agregar las otras

observaciones

Prueba funcional: Consultar hoja de vida.



Diseño de pruebas relevantes Consultar hoja de vida




Precondición Se deben haber almacenado equipos Poscondición No podrá ver la información de la hoja

de vida




Precondición Se deben haber almacenado equipos Poscondición No podrá acceder al formulario de hoja

de vida.

Caso de uso 12 Modificar hoja de vida.

172



Tensión 5. El campo tensión está vacío. 6. El campo tensión no está vacío.

Corriente 7. El campo corriente está vacío. 8. El campo corriente no está vacío.

Potencia 9. El campo potencia está vacío. 10. El campo potencia no está vacío.

Resistencia 11. El campo resistencia está vacío. 12. El campo resistencia no está vacío.

Frecuencia 13. El campo frecuencia está vacío. 14. El campo frecuencia no está vacío.

Fuente 15. El campo fuente está vacío. 16. El campo fuente no está vacío.

Batería 17. El campo batería está vacío. 18. El campo batería no está vacío.

Fusible externo 19. El campo fusible externo está vacío. 20. El campo fusible externo no está vacío.

Fusible interno 21. El campo fusible interno está vacío. 22. El campo fusible interno no está vacío.

Agua 23. El campo agua está vacío. 24. El campo agua no está vacío.

Aire 25. El campo aire está vacío. 26. El campo aire no está vacío.

Oxigeno 27. El campo oxigeno está vacío. 28. El campo oxigeno no está vacío.

Vacío 29. El campo vacío está vacío. 30. El campo vacío no está vacío.

Temperatura 31. El campo temperatura está vacío. 32. El campo temperatura no está vacío.

Humedad 33. El campo humedad está vacío. 34. El campo humedad no está vacío.

Peso 35. El campo peso está vacío. 36. El campo peso no está vacío.

Presión 37. El campo presión está vacío. 38. El campo presión no está vacío.

173

Descripción de accesorios

39. El campo descripción de accesorios está vacío. 40. El campo descripción de accesorios no está vacío.

Observación de accesorios

41. El campo observación de accesorios está vacío. 42. El campo observación de accesorios no está vacío.

Personal especializado para su operación

43. No selecciono el personal especializado para su

operación.

44. Selecciono el personal especializado para su

operación.

Otras observaciones

45. El campo otras observaciones está vacío. 46. El campo otras observaciones no está vacío.

Diseño de pruebas relevantes Modificar hoja de vida.




Precondición Se deben haber almacenado equipos Poscondición No podrá modificar hoja de vida

No. Caso Prueba 11 Nombre Entrada Resistencia Nombre Caso de Prueba o Regla asociada El campo resistencia esta vacío Valor Entrada “” o null

Supuesto: el valor de la resistencia debe ser numérico.

Salida Esperada Precondición Debe haber almacenado equipos Poscondición No podrá actualizar la resistencia.

No. Caso Prueba 19 Nombre Entrada Fusible externo Nombre Caso de Prueba o Regla asociada El campo fusible externo esta vacío Valor Entrada “” o null

Supuesto: El fusible externo podría ser “Si”

174

Salida Esperada Precondición Debe haber almacenado equipos Poscondición No podrá actualizar el fusible externo

No. Caso Prueba 25 Nombre Entrada Aire Nombre Caso de Prueba o Regla asociada El campo aire esta vacio Valor Entrada “” o null

Supuesto: El valor de la entrada debe ser de tipo numerico

Salida Esperada Precondición Se deben haber almacenado equipos Poscondición No podrá actualizar el aire

No. Caso Prueba 31 Nombre Entrada Temperatura Nombre Caso de Prueba o Regla asociada El campo temperatura está vacío. Valor Entrada “” o null


Salida Esperada “debe ingresar las características tecnicas”

Precondición Se deben haber almacenado equipos Poscondición No podrá actualizar la temperatura

No. Caso Prueba 39 Nombre Entrada Descripción Nombre Caso de Prueba o Regla asociada El campo descripción de accesorios

está vacío Valor Entrada “” o null

Supuesto: la descripción de accesorios podría ser “funda de plastico”

Salida Esperada “debe seleccionar accesorios del equipo”

Precondición Se deben haber almacenado equipos Poscondición No podrá actualizar la descripción de

accesorios

No. Caso Prueba 45 Nombre Entrada Otras observaciones Nombre Caso de Prueba o Regla asociada El campo otras observaciones esta

vacio Valor Entrada “” o null

175

Supuesto: la descripción de otras observaciones podría ser “cable pelado”

Salida Esperada “debe haber seleccionado observaciones adicionales”

Precondición Se deben haber almacenado equipos Poscondición No podrá actualizar las otras

observaciones

Prueba funcional: Eliminar hoja de vida.



Diseño de pruebas relevantes Eliminar hoja de vida




Precondición Se deben haber almacenado equipos Poscondición No podrá eliminar la hoja de vida




Precondición Se deben haber almacenado equipos Poscondición No podrá eliminar la hoja de vida

176

Prueba funcional: Consultar lista de comprobación de mantenimiento

preventivo.



Diseño de pruebas relevantes consultar lista de comprobación de

mantenimiento preventivo.




Precondición Se deben haber almacenado equipos en el inventario

Poscondición No podrá eliminar consultar la lista de comprobación de mantenimiento preventivo.




Precondición Se deben haber almacenado equipos Poscondición No podrá consultar la lista de

comprobación de mantenimiento preventivo.

SISTEMA AUTOMATIZADO PARA GESTIÓN DE MANTENIMIENTO DE …

Documents

Transcript of SISTEMA AUTOMATIZADO PARA GESTIÓN DE MANTENIMIENTO DE …