Diseño de una plataforma informática para ampliar la gestión del Servicio de Dosimetría Externa del Centro de Protección e Higiene de las Radiaciones.

Tamaño: px
Comenzar la demostración a partir de la página:

Download "Diseño de una plataforma informática para ampliar la gestión del Servicio de Dosimetría Externa del Centro de Protección e Higiene de las Radiaciones."

Transcripción

1 INSTITUTO DE CIBERNÉTICA, MATEMÁTICA Y FÍSICA Diseño de una plataforma informática para ampliar la gestión del Servicio de Dosimetría Externa del Centro de Protección e Higiene de las Radiaciones. Tesis presentada en opción al título de Máster en Cibernética Aplicada. Mención: Minería de Datos AUTOR: Ing. José Francisco Manzano de Armas TUTOR: Dr. C. Armando Plasencia Salgueiro La Habana Septiembre, 2014

2 Resumen En nuestro país la vigilancia radiológica individual de la exposición ocupacional a fuentes de radiación externa es realizada por el Centro de Protección e Higiene de las Radiaciones (CPHR). El CPHR es una institución científica perteneciente al Ministerio de Ciencia, Tecnología y Medio Ambiente (CITMA). Tiene la misión de realizar proyectos y servicios competitivos en el campo de la seguridad radiológica y la aplicación de tecnologías que contribuyan a la protección de las personas, el medio ambiente y el desarrollo sostenible del país En el presente trabajo se propone el diseño de una plataforma informática que amplíe la gestión del Laboratorio de Dosimetría Externa perteneciente al CPHR. Esto permitirá agilizar el intercambio de información con los clientes y facilitar el proceso de toma de decisiones. En el trabajo se presentan los aspectos teóricos relacionados con la plataforma informática propuesta y que abarcan temas como las aplicaciones cliente servidor, las aplicaciones web, los Data Mart como soporte a las herramientas para la toma de decisiones y la utilización de la minería de datos. Se realiza el análisis y diseño del sistema de gestión de la información cliente servidor y de la aplicación web haciendo uso de la metodología para la planificación, desarrollo y mantenimiento de sistemas de gestión METRICA 3. Finalmente, se utiliza la metodología HEFESTO para la construcción de un Data Mart para el LDE. Palabras claves: Data Mart, Minería de Datos, Dosimetría Externa 2

3 Contenido. Introducción... 7 Capítulo 1. Fundamentación teórica Caracterización fenomenológica del objeto de la investigación Laboratorio de dosimetría externa (LDE) Situación actual de la automatización de los servicios dosimétricos del CPHR Experiencias internacionales en el uso de sistemas de gestión de datos para los servicios dosimétricos Propuesta de plataforma informática Aplicación de gestión de la información cliente servidor Aplicación web Almacenes de Datos y Data Mart Aplicaciones de minería de datos Conclusiones del capítulo Capítulo 2. Desarrollo del sistema de gestión de la información cliente servidor y de la aplicación web Estudio de viabilidad del sistema (EVS) Establecimiento del alcance del sistema (EVS 1) Estudio de la situación actual (EVS 2) Definición de requisitos del sistema (EVS 3) Estudio de alternativas de solución (EVS 4) Valoración de las alternativas (EVS 5) Análisis del sistema de información (ASI) Definición del Sistema (ASI 1) Establecimiento de Requisitos (ASI 2) Análisis de Casos de Uso (ASI 4) Análisis de Clases (ASI 5) Definición de Interfaz de Usuario (ASI 8) Análisis de Consistencia (ASI 9) Aprobación del Análisis del Sistema de Información (ASI 11)

4 2. 3 Diseño del sistema de información (DSI) Definición de la Arquitectura del Sistema (DSI 1) Diseño físico de datos (DSI 6) Verificación y aceptación de la arquitectura (DSI 7) Generación de especificación de construcción (DSI 8) Especificación técnica de Plan de Pruebas (DSI 10) Establecimiento de requisitos de implantación (DSI 11) Construcción del sistema de información (CSI): Preparación del entorno de generación y construcción (CSI 1) Generación del código de los componentes y procedimientos (CSI 2) Ejecución de las Pruebas Unitarias (CSI 3) Ejecución de las Pruebas de Integración (CSI 4) Ejecución de las Pruebas del Sistema (CSI 5) Elaboración de los Manuales de Usuario (CSI 6) Definición de la formación de Usuarios Finales (CSI 7) Construcción de componentes y procedimientos de Migración y Carga Inicial (CSI 8) Aprobación del Sistema de Información (CSI 1) Conclusiones del capítulo Capítulo 3. Diseño del Data Mart del Laboratorio de Dosimetría Externa Análisis de requerimientos Identificar preguntas Identificar hechos y dimensiones Modelo conceptual Análisis de los sistemas OLTP Conformar hechos Establecimiento de correspondencias Nivel de granularidad Modelo conceptual ampliado Modelo lógico del almacén de datos Integración de datos Carga inicial de datos Creación de Cubos Multidimensionales

5 3.6 Conclusiones del capítulo Conclusiones Referencias bibliográficas Anexo 1. Diagrama IDEFO del servicio de dosimetría externa del CPHR Anexo 2. Gestión de proyectos Anexo 3 Casos de uso del sistema de gestión cliente servidor Anexo 4. Diagramas de secuencia para los casos de uso del sistema de gestión cliente servidor Anexo 6. Diagramas de Actividad Anexo 7. Diseño físico de los datos Anexo 8. Entorno de generación y construcción Anexo 9. Vistas del sistema de gestión de la información cliente servidor Anexo 10. Vistas de la aplicación web Anexo 11. Modelo conceptual Anexo 12. Modelo conceptual ampliado Anexo 13. Modelo lógico del almacén de datos Anexo 14. Resultados de consultas realizadas al Data Mart Glosario técnico

6 Figuras. Figura 1. Lector termoluminiscente y dosímetros utilizados por el Servicio de Dosimetría Externa Figura 2. Infraestructura tecnológica actual del Laboratorio de Dosimetría Externa Figura 3. Aplicación de dos capas (Cliente-Servidor) Figura 4. Funcionamiento de una aplicación de tres capas Figura 5. Aplicación web para una Base de Datos bibliográfica Figura 6. Diagrama de un sistema de almacén de datos Figura 7. Fases de un proyecto de minería de datos Figura 8. Organigrama del Centro de Protección e Higiene de las Radiaciones Figura 9. Modelo de Caso de Uso del sistema de gestión cliente servidor Figura 10. Modelo de Caso de Uso de la aplicación web Figura 11. Diagrama de despliegue del sistema Figura 12. Diagrama de clases persistentes Figura 13. Arquitectura del Sistema Figura 14. Subsistema de diseño Figura 15. Representación gráfica de un Cubo Multidimensional Figura 16. Herramienta Mondrian Schema Workbench Figura 17. Diseño de los Cubos Multidimensionales del Data Mart del LDE Figura 18. Herramienta ROLAP Saiku-Server Figura 19. Representación gráfica de los resultados obtenidos Figura 20. Consulta MDX Tablas. Tabla 1. Diferencia entre un almacén de datos y un Data Mart Tabla 2. Listado inicial de requisitos del sistema Tabla 3. Usuarios del sistema de gestión cliente servidor Tabla 4. Usuarios de la aplicación web Tabla 5. Listado de Casos de Usos del Sistema Cliente Servidor Tabla 6. Especificaciones del entorno tecnológico de desarrollo Tabla 7. Entorno tecnológico de pruebas Tabla 8. Conformación de los indicadores

7 Introducción La exposición ocupacional a las radiaciones ionizantes puede producirse como consecuencia de diversas actividades llevadas a cabo por el hombre, incluido el trabajo asociado a las diferentes etapas del ciclo de combustible nuclear, el uso de fuentes radiactivas y equipos de rayos X en medicina, la investigación científica, la educación, la agricultura, la industria y las ocupaciones que implican el manejo de materiales que contienen concentraciones elevadas de radionúclidos de origen natural [1]. Para controlar esta exposición se establecen programas de vigilancia radiológica ocupacional. El objetivo general de los programas de vigilancia radiológica ocupacional es la evaluación de las condiciones del lugar de trabajo y de las exposiciones individuales. La evaluación de las dosis a los trabajadores con exposición rutinaria o potencial a fuentes externas de radiación constituye una parte integrante de cualquier programa de protección radiológica y contribuye a asegurar condiciones radiológicas satisfactorias y aceptablemente seguras en el lugar de trabajo [2]. El Centro Nacional de Seguridad Nuclear (CNSN) verifica, mediante las inspecciones reguladoras a las diferentes prácticas, el aseguramiento de estas condiciones radiológicas en el puesto de trabajo. El CNSN es la autoridad que regula y controla el uso seguro de las radiaciones ionizantes reguladora en nuestro país. La vigilancia radiológica es una herramienta que contribuye a que no se superen los límites de dosis y que se reduzcan las exposiciones a las radiaciones ionizantes. Entre los beneficios adicionales de la vigilancia radiológica se encuentra la compilación de datos para realizar estudios epidemiológicos; determinación de responsabilidades en caso de efectos adversos a la salud de los trabajadores; confirmación de la clasificación de zonas; determinación de fluctuaciones de las condiciones de trabajo y obtención de datos para la revisión de los programas de optimización. La optimización de la protección se aplica con el propósito de mantener bajo control los niveles de exposición para garantizar que sean lo más bajo que pueda razonablemente alcanzarse. 7

8 Un aspecto importante de los programas de vigilancia radiológica es el mantenimiento de los registros individuales de dosis de los trabajadores ocupacionalmente expuestos a las radiaciones ionizantes (TOE). Los registros son necesarios para supervisar el cumplimiento de los reglamentos de protección contra las radiaciones; tienen uso médico y legal; permite evaluar las dosis individuales y colectivas recibidas por los trabajadores y posibilitan realizar estudios epidemiológicos y de los efectos sobre la salud. Los servicios de vigilancia radiológica modernos cuentan con un alto grado de automatización, utilizando sistemas integrados que vinculan el mantenimiento de los registros de dosis con el etiquetado, la emisión de dosímetros y su posterior evaluación de dosis. En nuestro país la vigilancia radiológica individual de la exposición ocupacional a fuentes de radiación externa es realizada por el Centro de Protección e Higiene de las Radiaciones (CPHR). El CPHR es una institución científica perteneciente al Ministerio de Ciencia, Tecnología y Medio Ambiente (CITMA). Tiene la misión de realizar proyectos y servicios competitivos en el campo de la seguridad radiológica y la aplicación de tecnologías que contribuyan a la protección de las personas, el medio ambiente y el desarrollo sostenible del país [3]. Entre sus funciones se encuentra la de desarrollar, asimilar e implantar técnicas y procedimientos que permitan la evaluación de las dosis de irradiación externa o por contaminación interna que en situaciones normales o accidentales reciben los TOE del país. Para garantizar el cumplimiento de estas funciones, el CPHR cuenta con un laboratorio provisto del personal calificado y el equipamiento necesario para ofrecer los servicios de control dosimétrico. El Laboratorio de Dosimetría Externa (LDE) atiende todo el servicio de dosimetría personal externa del país y cuenta con dosímetros termoluminiscentes y equipamiento para evaluar las dosis producto de la radiación fotónica [4]. El objetivo de este servicio es garantizar que todo el personal expuesto en el país en las prácticas con fuentes selladas, no selladas y equipos emisores de radiación gamma, rayos x y beta cuente con una vigilancia radiológica individual externa acorde a estándares internacionales. A partir del año 2002 el servicio de dosimetría externa ejecutado por el LDE se convierte en el único a nivel nacional y pasa a cubrir la vigilancia de todos los TOE del país. Sus servicios 8

9 son brindados a más de 11 mil TOE que laboran en diferentes prácticas ocupacionales y tiene la responsabilidad de elaborar y conservar los registros individuales de dosis de estos trabajadores. El LDE gestiona un elevado volumen de datos pertenecientes a las entidades usuarias del servicio, los TOE, los resultados de la evaluación de las dosis y los resultados de la evaluación de los dosímetros de los diferentes servicios dosimétricos en cada uno de los períodos de control establecidos. Además, para el procesamiento de los dosímetros se utilizan lectores termoluminiscentes conectados a computadoras personales, los cuales cuentan con su propia base de datos desarrollada por el fabricante para almacenar el resultado de las mediciones. Estas mediciones son enviadas a la base de datos de dosimetría externa a través de una aplicación informática que sirve de interfaz entre estas dos bases de datos. Desde la creación del LDE se utilizaba una base de datos programada en FoxPro, esta aplicación fue de mucha utilidad permitiendo un paso de avance inicial en la automatización de los servicios; pero debido a los cambios tecnológicos y organizativos fue necesario remplazarla. A partir del año 2000 se desarrolló un nuevo sistema para la gestión automatizada de la información, el cual se viene utilizando hasta la actualidad. Este sistema de gestión está instalado en cada una de las computadoras del LDE y permite el acceso a una base de datos Microsoft Access almacenado en un servidor de ficheros [5]. Aunque el LDE dispone de un conjunto de herramientas para la gestión automatizada de la información existen un grupo de aspectos que limitan el alcance de esta herramienta. Desde hace varios años el CPHR asumió el control dosimétrico de los TOE que trabajan en prácticas de radiodiagnóstico médico del Ministerio de Salud Pública (MINSAP). A este incremento de la solicitud de servicios dosimétricos también se le adicionan los servicios que se comenzaron a brindar a los cooperantes cubanos de la salud que cumplen misión en Venezuela, Bolivia y Haití. Además se han establecido compromisos asumidos con proyectos de cooperación internacional en el marco del ALBA, lo que implicó prestarles servicios a más de 2000 TOE pertenecientes al sector de la salud pública de la República Bolivariana de 9

10 Venezuela. Existe la posibilidad de que esta cooperación se extienda a otros países de la región. La base de datos de Microsoft Access utilizada para almacenar los datos del LDE no cuenta con las potencialidades ni la seguridad que nos ofrecen los entornos basados en servidores de bases de datos SQL. El trabajo con ficheros ACCES tiene asociado riesgos para la seguridad de los datos. Estos deben ser almacenados en una carpeta compartida en la red para que todos los miembros del servicio tengan acceso a los mismos. Aunque se pueden tomar medidas para evitar los accesos no autorizados, se corre el riesgo que los datos se pierdan a causa de un borrado accidental del fichero, por la acción de los virus o la mala fe de un usuario del sistema. La tecnología utilizada para el intercambio de datos entre la aplicación utilizada en las computadoras de los clientes y la base de datos compartida es obsoleta, lenta y poco eficiente. Es necesario que periódicamente se libere información de años anteriores en la base de datos para hacerla más ligera. Se requieren aplicaciones que gestionen mayor cantidad de datos dosimétricos y que devuelva consultas y reportes de mayor complejidad. También es necesario que este elevado volumen de información se almacene de forma segura y durante largos períodos de tiempo. Actualmente no se utilizan servidores de bases de datos SQL, que a diferencia de la aplicación Microsoft ACCES, si están especializados en proveer servicios de bases de datos a clientes remotos. Son capases de manejar grandes y complejos volúmenes de datos y compartir información con un conjunto de clientes (personas, equipos y aplicaciones). Estos sistemas tienen un funcionamiento más estable y seguro, soportando una mayor cantidad de usuarios trabajando de forma concurrente y son muy rápidos a la hora de procesar consultas que involucren elevados volúmenes de datos. El sistema automatizado que está actualmente vigente para el control de la información del LDE no tiene implementado apropiadamente todos los requerimientos e información dosimétrica presentes en las recomendaciones nacionales e internacionales y en 10

11 correspondencia con ello no disponen de toda la información que puede ser relevante para el control de la seguridad de las diferentes prácticas ocupacionales. No cuenta con un sistema de alerta para avisar a las autoridades competentes cuando los dosímetros evaluados sobrepasen los límites de investigación establecidos por el Centro Nacional de Seguridad Nuclear. En aquellos casos en que los TOE trabajan en más de una práctica con radiaciones ionizantes o en varias entidades es necesario relacionar las dosis recibidas por los diferentes servicios que estos reciben para el control de la exposición externa; pero esto no es posible hacerlo con el sistema utilizado en la actualidad. Otro aspecto a tener en cuenta es que para la verificación del cumplimiento de los límites de dosis se requiere obtener reportes sobre las dosis en un período de cinco años anteriores al período de control. Con el sistema actual sólo se pueden obtener reportes de dosis del período de control y la acumulada durante el año en curso. También se han realizado cambios organizativos en la gestión del LDE que no están implementados en el sistema de gestión utilizado en la actualidad. El sistema de gestión utilizado en la actualidad solo es utilizado por el LDE y no posibilita que los resultados de las evaluaciones de las dosis estén al alcance de forma permanente para los usuarios del servicio. Un nuevo sistema permitiría que los Responsables de Protección Radiológica de cada entidad puedan solicitar nuevos servicios sin tener que realizar los trámites directamente en la oficina comercial, modificar los datos de los TOE bajo su responsabilidad, conocer el estado de procesamiento de los dosímetros en tiempo real y recibir los reportes en el momento en que se evalúen las dosis. La información con los resultados de los controles dosimétricos de años anteriores está dispersa en diferentes ficheros para no sobrecargar el sistema de gestión actual. A causa de esto se dificulta la ejecución de estudios epidemiológicos y de optimización de la protección que tengan en cuenta los datos de todos los años de servicio. Se requiere agrupar toda esta información en una sola base de datos y que el LDE y los TOE tengan acceso a ella de forma permanente. La dispersión de los datos trae como consecuencia que no se utilicen 11

12 herramientas de apoyo a la toma de decisiones ni se aplican las técnicas de Minería de Datos para la obtención de conocimiento a partir de los datos existentes. Existen un conjunto de estrategias y herramientas enfocadas a la administración y creación de conocimiento mediante el análisis de datos existentes en los almacenes de datos y Data Marts. Estas técnicas reciben el nombre de inteligencia empresarial o inteligencia de negocios. Entre las facilidades que brindan están la comprensión del desempeño de las organizaciones en el pasado, el monitoreo de las actividades actuales para responder rápidamente a los cambios, optimizar los procesos de negocios, manejar los riesgos y pronosticar nuevas posibilidades de negocios. Teniendo en cuenta los aspectos anteriores se puede determinar la siguiente situación problémica: El sistema de gestión utilizado en la actualidad por el LDE tiene un alcance limitado y no cumple con los requerimientos de información dosimétrica presentes en las recomendaciones nacionales e internacionales; no facilita el intercambio de información con los clientes ni puede ser utilizada como herramienta para la toma de decisiones ante los problemas que puede enfrentar el laboratorio. A partir de la situación problemática expuesta podemos decir que el problema a resolver es el siguiente: Cómo realizar el diseño de una plataforma informática que amplíe la gestión del servicio de dosimetría externa del CPHR para agilizar el intercambio de información con los clientes y facilitar el proceso de toma de decisiones? Para dar solución al problema anterior se plantea las siguientes preguntas científicas: 1. Cuáles son las aplicaciones propuestas para formar parte de la plataforma informática? 12

13 2. Cómo desarrollar un sistema de gestión de la información y una aplicación web que posibilite ampliar la gestión del servicio de dosimetría externa? 3. Cuáles son los indicadores a tener en cuenta para el diseño de un Data Mart departamental empleado por el LDE como apoyo a la toma de decisiones? El objeto de investigación de este trabajo es el servicio de dosimetría externa del Centro de Protección e Higiene de las Radiaciones y el campo de acción es la automatización de la gestión de la información de este servicio. Como objetivo principal nos hemos trazado el diseño de una plataforma informática que amplíe la gestión del LDE para agilizar el intercambio de información con los clientes y facilitar el proceso de toma de decisiones. Los objetivos específicos que se desean obtener son los siguientes: 1. Desarrollar un sistema de gestión de la información cliente servidor para la automatización de las diferentes etapas del Servicio de Dosimetría Externa. 2. Desarrollar una aplicación web para agilizar el intercambio de información entre el Servicio de Dosimetría Externa y los clientes. 3. Diseñar un Data Mart para el almacenamiento y análisis de los datos como apoyo a la toma de decisiones a partir de la información generada por el Servicio de Dosimetría Externa. Con el fin de alcanzar los objetivos planteados se llevarán a cabo las siguientes tareas de investigación: 1. Estudio bibliográfico para conocer de los sistemas de gestión de la información utilizados por los servicios de dosimetría en otros países. 2. Análisis del sistema de gestión cliente servidor y una aplicación web para la gestión de los procesos del servicio de dosimetría externa. 3. Programación del sistema de gestión cliente servidor y una aplicación web para la gestión de los procesos del servicio de dosimetría externa. 13

14 4. Diseño del Data Mart departamental como apoyo a la toma de decisiones. La importancia de este trabajo radica en que se incrementarán considerablemente los niveles de gestión de los servicios del Laboratorio de Dosimetría Externa del CPHR y el intercambio de información con los clientes. De esta manera se repercute positivamente en la calidad de los servicios dosimétricos que reciben los TOE en nuestro país. Además, se dispondrá de una plataforma informática que gestionará información relevante para la seguridad de las prácticas asociadas al empleo de las radiaciones ionizantes, teniendo en cuenta los requerimientos presentes en las normas nacionales e internacionales. La plataforma informática diseñada entregará al LDE las herramientas necesarias para incrementar sus niveles de gestión de la información, intercambio con sus clientes y apoyo a la toma de decisiones mediante la implantación de las siguientes tecnologías: Aplicación de gestión de la información cliente servidor: Esta arquitectura se caracteriza por la descomposición funcional de sus aplicaciones y servicios. Su modelo distribuido provee considerables mejoras en la escalabilidad, disponibilidad, gestión y utilización de los recursos. Se diseñará un sistema de gestión de la información dosimétrica que sustituirá al utilizado en la actualidad y que cumpla con los requerimientos actuales del servicio y las recomendaciones internacionales. Aplicación web para el acceso en línea de los resultados dosimétricos: Se diseñará una aplicación web que les permita a los clientes del servicio acceder a la información en tiempo real de los resultados dosimétricos. Mediante la misma, los responsables de protección radiológica de las entidades usuarias podrían gestionar directamente la información dosimétrica de los trabajadores bajo su responsabilidad. A diferencia de las aplicaciones tradicionales donde el objetivo principal es el de procesar datos, una aplicación web tiene el objetivo de ofrecer un servicio a cada usuario que se conecte. Data Mart: Estos son almacenes de datos pequeños que están centrados en un tema y responden a los intereses de determinada áreas de negocio dentro de una organización. Se caracteriza por disponer de la estructura óptima de datos para analizar la información al 14

15 detalle desde todas las perspectivas que afecten a los procesos de dichas áreas de negocio. Los datos almacenados en ellos pueden ser agrupados, explorados y distribuidos para que un grupo de usuarios realice la explotación de los mismos y los ayude en la toma de decisiones. Son sistemas orientados a las consultas, donde la frecuencia de cargas de datos es baja y conocida. A partir de ellos se puede hacer uso de herramientas de Procesamiento Analítico en Línea (OLAP). Aplicaciones de minería de datos: Es el proceso de extracción de información válida, previamente desconocida, comprensible y útil a partir del procesamiento de grandes volúmenes de datos, con el objetivo de utilizar el conocimiento obtenido para la toma de decisiones. Esto implica actuar sobre bases de datos de gran tamaño y complejidad, para extraer el conocimiento que no es evidente o imposible de obtener mediante la utilización de las herramientas de recuperación tradicionales. Debido al elevado volumen de trabajo requerido para el desarrollo de la plataforma informática necesaria para la gestión de los servicios dosimétricos del CPHR, se establece como límite de la investigación el desarrollo del sistema de gestión de la información y la aplicación web hasta la fase de pruebas y el diseño del Data Mart. Como parte del proceso de investigación en este trabajo se utilizó el análisis documental clásico para el estudio, análisis y valoración de la bibliografía encontrada con el fin de extraer la información relacionada con la temática a investigar. También se hizo uso del método sistémico para presentar el objeto de investigación en su integridad, reflejando sus componentes y los nexos de funcionalidad existente entre ellos y el método de modelación y síntesis para la concepción de la plataforma informática. Este trabajo de tesis está estructurado en los capítulos siguientes: Capítulo 1: Se realiza una caracterización fenomenológica del objeto de la investigación, explicándose el funcionamiento y el nivel actual de automatización del Laboratorio de Dosimetría Externa del Centro de Protección e Higiene de las Radiaciones. Se describen 15

16 diferentes aplicaciones implementadas en otros países para la gestión de los servicios dosimétricos. También se describe las características de la plataforma informática propuesta para la ampliación de la gestión del Servicio de Dosimetría Externa. Capítulo 2: Se realiza el análisis y diseño del sistema de gestión de la información cliente servidor y aplicación web utilizando la metodología para la planificación, desarrollo y mantenimiento de sistemas de gestión METRICA 3. Capítulo 3: Se definen los indicadores a tener en cuenta para el diseño del Data Mart que será utilizado por el Laboratorio de Dosimetría Externa para el empleo de herramientas de apoyo a la toma de decisiones y la minería de datos. Se desarrollan las diferentes fases para el diseño de un Data Mart departamental utilizando la metodología HEFESTO. En la exposición de las conclusiones se hace un resumen de los aspectos importantes del trabajo, se discuten los resultados obtenidos y se mencionan las recomendaciones para continuar desarrollando este trabajo y mejorar la gestión de un Servicio de Dosimetría Externa. Posteriormente se muestran las referencias bibliográficas y los siguientes anexos que apoyan el trabajo realizado: Anexo 1: Diagrama de proceso del servicio de dosimetría externa del CPHR. Anexo 2. Gestión de proyectos. Anexo 3: Casos de uso del sistema de gestión cliente servidor. Anexo 4: Diagramas de secuencia para los casos de uso del sistema de gestión cliente servidor. Anexo 5: Diagramas de clases de diseño del sistema de gestión cliente servidor. Anexo 6. Diagramas de Actividad. Anexo 7. Diseño físico de los datos. Anexo 8. Entorno de generación y construcción. Anexo 9. Vistas del sistema de gestión de la información cliente servidor. Anexo 10. Vistas de la aplicación web. Anexo 11. Modelo conceptual 16

17 Anexo 12. Modelo conceptual ampliado Anexo 13. Modelo lógico del almacén de datos. Anexo 14. Resultados de consultas realizadas al Data Mart. El trabajo concluye con un glosario técnico de términos de protección radiológica que se emplean en la tesis. 17

18 Capítulo 1. Fundamentación teórica 1.1 Caracterización fenomenológica del objeto de la investigación Laboratorio de dosimetría externa (LDE) El LDE del CPHR tiene la función de evaluar las dosis por exposición externa que reciben los trabajadores ocupacionalmente expuestos a las radiaciones ionizantes. Se basa en el empleo de dosímetros personales termoluminiscentes para la evaluación de la dosis personal recibida durante el trabajo. La termoluminiscencia es una técnica muy empleada en dosimetría que se basa en la propiedad que tienen algunos materiales cristalinos de almacenar parte de la energía que absorben al ser expuestos a las radiaciones ionizantes. Posteriormente, al ser calentados emiten dicha energía en forma de luz que puede medirse con un fotomultiplicador. En la Figura 1 se muestra uno de los lectores y los dosímetros empleados por el LDE. Figura 1. Lector termoluminiscente y dosímetros utilizados por el Servicio de Dosimetría Externa. El laboratorio cuenta con todo un sistema de dosimetría Termoluminiscente (TLD cuyos principales componentes son: Dosímetros: Se cuenta con tres tipos de dosímetros, dos para la evaluación de la dosis en cuerpo entero y uno para la dosis en extremidades. Ambos tipos de dosímetros son 18

19 capaces de medir la radiación fotónica con energía entre 15 kev y 2 MeV en un rango de dosis de 0.1 msv a 10 Sv y con un error relativo inferior al 20%. 1. TLD-01: El dosímetro está compuesto por la caseta TLD-01 conteniendo 2 detectores de LiF:Mg,Ti (modelo JR1152C) de 3x3x0.9 mm. La caseta TLD-01 consta de dos piezas de polipropileno. La parte posterior tiene 5 mm de espesor e incluye dos depresiones (5 mm de diámetro y 1 mm de profundidad) para colocar los detectores y la parte anterior tiene un espesor de 4 mm e incluye una ventana para la estimación de la dosis superficial. Esta caseta es colocado en un portadosímetro de polietileno, donde es sellado junto a la etiqueta de identificación y que posee una presilla para su sujeción. 2. RADOS: El dosímetro consiste básicamente en una unidad plástica de dos partes. Una parte es una placa que contiene 4 cavidades para colocar los detectores y un código de huecos para su identificación. La segunda parte es una caseta con tres posiciones con filtros de 1 mm de espesor y una posición con ventana. En la placa se colocan dos detectores de LiF:Mg,Cu,P (modelo GR-200) de 4.5mmx0.8mm. Este conjunto es colocado dentro de una caja plástica para su protección y utilización. La identificación se logra con una etiqueta. 3. Anillo: El dosímetro consiste en un anillo metálico con un orificio circular donde se coloca un detector de LiF:Mg,Ti (modelo JR1152A) de 5x5x0.9 mm cubierto por una capa fina de polietileno. La capa de polietileno es una manguera que se ajusta al dosímetro cuando éste es calentado ligeramente durante unos minutos. La identificación se logra a través de un número de cuatro dígitos que posee el anillo. Lectores RADOS-DOSACUS: El sistema de lectura RADOS-DOSACUS está basado en el calentamiento de los detectores TL a través de un flujo de nitrógeno caliente. Los dosímetros son colocados en bandejas especiales que posee el sistema, que pueden contener hasta 20. El equipo extrae automáticamente las placas desde dentro de las casetas y realiza la medición de los detectores termoluminiscentes. Equipamiento auxiliar: Se utilizan irradiadores para realizar las irradiaciones de caracterización y calibración del sistema. Estos irradiadores son trazables al Laboratorio 19

20 Secundario de Calibración Dosimétrica del CPHR. También se emplean muflas para realizar el tratamiento térmico de los dosímetros. La ejecución de los servicios incluye varias etapas que se realizan en las instalaciones del LDE. A continuación se describen brevemente las principales etapas: Preparación de los dosímetros: Los detectores TL son sometidos a un tratamiento térmico para el borrado según lo establecido. Posteriormente se ensamblan los dosímetros, colocando los detectores en su portador. Se elaboran los listados del personal perteneciente a cada entidad usuaria y se le asigna el dosímetro correspondiente para ese período de control. Finalmente se colocan los dosímetros preparados y el listado de los clientes en un sobre debidamente identificado. Envío de los dosímetros al cliente: El envío o entrega de los dosímetros a los clientes puede realizarse de dos formas teniendo en cuenta los intereses de ellos: envío por correo y recogida en la Oficina Comercial del CPHR. En todos los casos deben ser entregados o enviados al cliente de forma tal que los reciba antes de que comience el período para el cual están destinados. Utilización de los dosímetros: Los dosímetros son utilizados por los clientes durante el período establecido. Cada persona empleará el dosímetro que le ha sido asignado, el cual es personal e intransferible. El dosímetro debe ser empleado siempre que se realicen trabajos con radiaciones ionizantes y se almacenarán en lugares alejados de las fuentes radiactivas. Devolución de los dosímetros: Al concluir el período de utilización los dosímetros son devueltos al Laboratorio, junto con el listado donde se anotan las incidencias en su utilización. Se pueden emplear las mismas vías que para la entrega de los dosímetros. Recepción de los dosímetros: Al recibirse los dosímetros son recepcionados por el personal del LDE a través del código de barras a ellos asociados. Lectura de los dosímetros: Los dosímetros son medidos utilizando los lectores termoluminiscentes y empleando dosímetros de control irradiado para calibración y no irradiado para el control del fondo medioambiental. 20

21 Evaluación y reporte de los resultados: Los resultados de las lecturas se introducen en una Base de Datos, que se encarga del cálculo y procesamiento de las dosis. Ella asigna a cada trabajador la dosis que le corresponde y calcula la dosis acumulada durante el año. Asimismo, genera el Reporte de Dosis que constituye el Certificado que se le entrega al cliente, que incluye la dosis recibida en el período y la acumulada en el año. Dicho Certificado debe ser entregado o enviado al cliente como máximo a los 45 días posteriores de recibirse los dosímetros en el CPHR. El servicio tiene establecido como nivel de registro un valor de dosis de 0,1 msv, cualquier valor inferior es reportado como cero, también se asigna cero cuando el dosímetro no es devuelto o presenta algún daño físico que imposibilita su medición [6]. El LDE cuenta con un sistema de aseguramiento de la calidad diseñado según los requisitos de la norma ISO/IEC "Requisitos Generales para la Competencia de los Laboratorios de Ensayo y Calibración". Este sistema se encuentra en proceso de acreditación por parte del Órgano Nacional de Acreditación (ONARC) Situación actual de la automatización de los servicios dosimétricos del CPHR A partir del año 2000 se desarrolló un sistema para la gestión automatizada de la información, el cual se viene utilizando hasta la actualidad. Entre las ventajas que nos reporta este sistema están las de poder automatizar las diferentes etapas que conforman los servicios ofertados por el laboratorio, que van desde la entrega de los dosímetros, pasando por la recepción de los mismos hasta el cálculo de dosis y emisión de los reportes. Para facilitar este proceso, el sistema genera un código de barras único para cada dosímetro entregado. Como se puede ver en la Figura 2 todo el trabajo del sistema está soportado sobre la red de área local instalada en el CPHR. El sistema de gestión está instalado en cada una de las computadoras del Laboratorio que acceden a la base de datos de dosimetría, consistente en un archivo Microsoft Access almacenado en un servidor de ficheros. El procesamiento de los dosímetros se realiza en lectores termoluminiscentes conectados a computadoras personales. 21

22 Ellos cuentan con su propia base de datos desarrollada por el fabricante para almacenar el resultado de las mediciones. Estas son procesadas y enviadas a la base de datos de dosimetría a través de una aplicación informática que sirve de interfaz entre estas dos bases de datos. Figura 2. Infraestructura tecnológica actual del Laboratorio de Dosimetría Externa Recientemente se sustituyó el equipamiento utilizado por el personal técnico del laboratorio por un grupo de clientes ligeros, los cuales tienen muy buenas prestaciones para el trabajo que se realiza en el mismo. Cada uno de ellos está equipado con un lector de código de barra que permite mayor velocidad y seguridad a la hora de recepcionar los dosímetros recibidos de las entidades usuarias para su procesamiento. El Sistema de Gestión de Datos en Dosimetría Personal Dosis está compuesto por varios módulos, entre los que se encuentran el registro de los datos de las entidades usuarias, registro de los trabajadores ocupacionalmente expuestos, registro de los dosímetros entregados a los trabajadores ocupacionalmente expuestos, registros de las mediciones realizadas, ya sean de dosimetría externa como interna, también permite la búsqueda de información y la emisión de varios tipos de reportes. 22

23 1.1.3 Experiencias internacionales en el uso de sistemas de gestión de datos para los servicios dosimétricos Durante el proceso investigativo se realizó una búsqueda bibliográfica que tenía como objetivo investigar sobre las tendencias actuales en el uso de sistemas automatizados de gestión de la información aplicados a los servicios dosimétricos. Se han encontrado varias soluciones interesantes, que van desde grandes bases de datos de alcance nacional y con posibilidades de accederse a través de internet, hasta pequeñas aplicaciones que no salen del ámbito de los laboratorios que las utilizan. Hay que destacar la ausencia de soluciones comerciales que persigan como objetivo la automatización de los servicios dosimétricos. La causa de esto puede estar dada por las particularidades de cada servicio prestado por los diferentes laboratorios, lo que hace muy difícil diseñar una herramienta que se ajuste a las necesidades todos los laboratorios. A continuación se presentan algunos de las soluciones de automatización de los servicios dosimétricos más interesante encontradas. Sistema de información SISERI Este sistema fue desarrollado para centralizar, verificar y preservar los datos dosimétricos de todos los trabajadores ocupacionalmente expuestos a las radiaciones ionizantes de Francia. Los principales usuarios de este sistema son los propios trabajadores expuestos, los médicos ocupacionales y los expertos en protección radiológica. También tienen acceso a los mismos los inspectores laborales y los inspectores de radioprotección [7]. El acceso a los datos se realiza a través de internet, garantizando en todo momento la seguridad y confidencialidad de los mismos, y respetando los límites establecidos por las regulaciones relacionadas con la protección de los datos personales. Este sistema permite monitorear los niveles de exposición a las radiaciones ionizantes recibidas por los trabajadores y chequear que los límites de dosis acumulados por los mismos se mantengan dentro de lo regulado. El sistema también es utilizado como ayuda para realizar estudios de optimización de la radioprotección en los trabajadores y en investigaciones epidemiológicas. 23

24 Anualmente en Francia son monitoreados más de 290 mil personas quienes están expuestas a las radiaciones ionizantes debido al trabajo que realizan. Cada uno de estos trabajadores es monitoreado a través de la dosimetría externa utilizando uno o más dosímetros en dependencia del tipo de radiaciones a que están expuestos. Este monitoreo puede tener una frecuencia quincenal o anual. También se registra la información proveniente de los controles de dosimetría interna. La información dosimétrica es enviada al sistema por los diferentes servicios dosimétricos autorizados a operar en el país, utilizando para ello una conexión segura a internet y un protocolo de comunicación establecido. Los datos enviados son enlazados a los trabajadores a través de un identificador único. Cada registro de información dosimétrica incluye además el valor de la dosis, información relacionada con su situación laboral e información relacionada con el especialista en medicina ocupacional y el experto en protección radiológica responsable de ese trabajador. Estos especialistas tienen acceso solamente a la información de los trabajadores que están bajo su responsabilidad. CERN (Organización Europea para la Investigación Nuclear) El CERN es uno de los centros de investigación científica más importante del mundo, fue fundado en 1954 por 12 países europeos. Cuenta en la actualidad con 20 países miembros que comparten la toma de decisiones y 28 países no miembros con científicos de 220 institutos y universidades participando en proyectos de investigación. Sus instalaciones se encuentran ubicadas entre las fronteras de Francia y Suiza. Cuentan con un Grupo de Protección Radiológica encargado de brindarles servicios dosimétricos a más de 5 mil personas al año. Para el control dosimétrico utilizan un tipo de dosímetros equipados con una cámara de ionización y una memoria electrónica. Esto permite que se pueda almacenar la dosis acumulada por el trabajador y tener acceso a ella en cualquier momento. Esta lectura se realiza en más de 40 lectores distribuidos por toda la instalación y conectado a una red de computadoras. 24

25 La información procesada por los lectores de dosímetros es enviada a la base de datos que gestiona el funcionamiento de los mismos, posteriormente es conciliada y enviada a la base de datos dosimétrica. Esta base de datos interactúa con la base de datos que contienen la información del personal que trabaja en el CERN y la de los servicios médicos. También envía la información al sistema SISERI del Instituto de Radio Protección y Seguridad Nuclear (IRSN) en Francia y la base de datos de la Oficina Federal de Salud Pública (OFSP) de Suiza. La lectura debe ser realizada por los propios trabajadores utilizando los lectores habilitados en la instalación al menos una vez al mes. Si esta medición no se realiza en tiempo, entonces el sistema le envía hasta tres alertas vía correo electrónico pidiéndole a la persona que efectué la medición del dosímetro. En caso de que en la última alerta aún no se haya realizado la medición del dosímetro, el sistema bloqueará el acceso al área controlada y solicitará la devolución del dosímetro. El personal tiene acceso a sus reportes dosimétricos a través de una aplicación web accesible desde internet. Mirion Technologies Mirion Technologies es una compañía privada norteamericana con varios años de experiencia brindando servicios de protección radiológica y dosimetría. Cuenta con instalaciones en siete países y más de 700 empleados. Dispone de una División de Servicios Dosimétricos que ofrece una gran variedad de productos para la medición de las radiaciones ionizantes. Entre los clientes más importantes de esta compañía se encuentran centrales de energía nuclear, instituciones de la defensa, hospitales, universidades y laboratorios nacionales [8]. Como soporte a los servicios dosimétricos ofrecidos cuenta con tres soluciones informáticas que posibilitan una mejor interacción con los clientes de estos servicios. 1. GDS Online 2.0: Es una aplicación web que permite el acceso a través de internet de la información relacionada con los servicios dosimétricos recibidos por los clientes del servicio. Mediante la misma es posible recibir notificación vía correo electrónica de la disponibilidad de nuevos reportes de dosis en el sistema, para posteriormente descargarlos 25

26 en formato electrónico. Los clientes pueden realizar consultas en líneas para revisar los registros históricos de las dosis acumuladas por sus trabajadores. También pueden editar la información relacionada con sus trabajadores y de los dosímetros entregados para el monitoreo individual. 2. MDR (My dose record): Esta aplicación web le permite a los trabajadores ocupacionalmente expuestos obtener información en línea sobre los valores de dosis históricos recibidos. Esto le permite a cada trabajador tener acceso a sus datos dosimétricos desde cualquier lugar y en cualquier momento. Cuando son adicionados a la base de datos nuevos valores de dosis, ellos reciben una notificación vía correo electrónica. 3. Badgetrak: Es una aplicación de escritorio que le posibilita a los responsables de protección radiológica tener un control efectivo de los dosímetros enviados desde la División de Servicios Dosimétricos. Cada envío de dosímetros es notificado a través de un correo electrónico que contiene un fichero adjunto. Este fichero contiene información de los ficheros enviados y de los procesados en envíos anteriores. El sistema lee el fichero adjunto y actualiza su propia base de datos. Complejo Hospitalario Carlos Haya El Complejo Hospitalario Carlos Haya es un centro de tercer nivel del Servicio Andaluz de Salud. Está constituido por tres hospitales y un centro de consultas de especialidades, distribuidos en distintos puntos de Málaga [9]. Han desarrollado una aplicación web, mediante la cual sus trabajadores ocupacionalmente expuestos a las radiaciones ionizantes podrán acceder a la información actualizada de las dosis recibidas durante el trabajo realizado. Cada trabajador accede a esta aplicación mediante su número de identificación y su clave personal, dándole acceso en cualquier momento a la información de la última lectura del dosímetro personal, al historial dosimétrico y a información enviada por el servicio de protección radiológica. También es posible modificar sus datos personales y comunicar cualquier incidencia radiológica ocurrida durante el trabajo. 26

27 También han desarrollado una plataforma de mensajería mediante la cual es enviada al teléfono móvil de cada trabajador información personalizada sobre el servicio dosimétrico recibido durante el último periodo de control. Otros sistemas de gestión El Servicio de Monitoreo Individual para la Radiación Externa del Instituto de Tecnología Nuclear de Portugal utiliza una base Microsoft Acces para el monitoreo de 9500 TOE en 970 instalaciones de todo el país. Inicialmente contaban con una base de datos para el servicio de dosimetría fílmica y otra para el servicio de dosimetría termoluminiscentes, posteriormente unieron estas dos base de datos en una sola. La unión de estas dos bases de datos fue realizada con el propósito de realizar estudios estadísticos de la dosis anual evaluada de los TOE y por requerimientos de Registro Nacional de Dosis implementado en el país [10]. Canadá cuenta con un Registro Nacional de Dosis que es un sistema centralizado para almacenar la dosis de radiaciones recibida por sus TOE. Incluye todos los registros disponibles del monitoreo de los trabajadores desde el año 1951 hasta la actualidad de más de 300 mil trabajadores [11]. En España el Consejo de Seguridad Nuclear (CSN) cuenta con el Registro Nacional de Dosis, es una base de datos con información de las dosis recibidas por las exposiciones a las radiaciones de los trabajadores del país. Los registros incluyen información relacionada con las prácticas ocupacionales de los trabajadores. La información dosimétrica y los análisis estadísticos son una herramienta de gran utilidad para la protección operacional de los TOE y sirve de soporte al CSN para el desarrollo y aplicación del principio ALARA [12]. 1.2 Propuesta de plataforma informática Se entiende como plataforma informática al conjunto de bienes y servicios utilizados para la integración y convergencia de la computación, las tecnologías y las técnicas para procesamiento de datos en apoyo a las actividades del hombre, sus principales componentes son: el factor humano, el software, el hardware, tipo y topología de red y los mecanismos de 27

28 interconexión y transmisión de información. Se propone el diseño de una plataforma tecnológica que solucione el problema de investigación planteado en este trabajo. Esta plataforma dotará al Laboratorio de Dosimetría Externa de la tecnología necesaria para incrementar sus niveles de gestión, intercambio de información con sus clientes y herramientas de apoyo para la toma de decisiones y obtención de conocimiento. La misma estará compuesta por las siguientes tecnologías: Aplicación de gestión de la información cliente servidor. Aplicación web Data Mart Aplicaciones de minería de datos Aplicación de gestión de la información cliente servidor Uno de los modelos de aplicaciones distribuidas tradicionales son los sistemas clienteservidor, los cuales están compuestos por dos capas. En una de ellas está en funcionamiento un servidor para la gestión de las bases de datos. Estas contienen tablas, índices, disparadores y otros objetos para almacenar los datos y reglas de negocio. Por su parte, la otra capa está formada por una o más aplicaciones que contienen la interfaz de usuario, el código y las librerías necesarias para acceder y procesar los datos. En la Figura 3 se puede ver un ejemplo de este tipo de aplicaciones. Entre las ventajas de la arquitectura cliente-servidor se encuentran la posibilidad de almacenar los datos en un lugar de acceso común a los diferentes clientes del sistema, la facilidad de configuración, el aumento del procesamiento de carga de los datos al ser posible adicionar varios servidores. Por otra parte, los costos de implementar este tipo de solución son más bajos debido a la simplicidad de su arquitectura. Sin embargo, estas aplicaciones requieren de grandes esfuerzos por parte de los administradores del sistema para su implementación y mantenimiento. Un cambio en la aplicación cliente implica tener que configurar correctamente cada una de las estaciones de trabajo. 28

29 Figura 3. Aplicación de dos capas (Cliente-Servidor). Para darle solución a las limitaciones inherentes a las aplicaciones cliente-servidor, es que surge la arquitectura de aplicaciones multicapas (n-tier). Esta arquitectura se caracteriza por la descomposición funcional de sus aplicaciones y servicios. Su modelo distribuido provee considerables mejoras en la escalabilidad, disponibilidad, gestión y utilización de los recursos [13]. Un ejemplo práctico de lo anterior son los sistemas de gestión de información de tres capas, los cuales son aplicaciones de bases de datos cliente-servidor que se encuentran divididas en unidades lógicas o capas, que pueden ser ejecutas en diferentes equipos: Capa de presentación: Es la encargada de mostrar la interfaz gráfica de la aplicación y tiene la función de realizar las solicitudes de información requeridas por los usuarios del sistema. Reside y se ejecuta desde las máquinas de los clientes. Capa de lógica de negocio: Reside en un servidor de aplicaciones y es la encargada de coordinar y procesar las peticiones y actualizaciones de múltiples clientes. Este servidor maneja todos los detalles de las solicitudes, define el conjunto de datos e interactúa directamente con el servidor de base de datos enviando los resultados a los clientes. 29

30 Capa de datos: Se trata del servidor donde está instalado el motor de bases de datos. La información es almacenada y recuperada desde la base de datos y enviada a la capa superior para ser procesada y enviada a los clientes. Como se puede ver en la Figura 4, en un sistema de tres capas los clientes sólo pueden comunicarse con el servidor de aplicaciones y en ningún caso directamente con el motor de bases de datos, como ocurre en una aplicación cliente/servidor tradicional. Figura 4. Funcionamiento de una aplicación de tres capas. Esta arquitectura se puede ampliar, agregándosele n cantidad de capas, y resulta provechosa cuando es de interés distribuir la carga de trabajo entre varias computadoras. Entre las ventajas de este tipo de aplicaciones (tres o más capas) se encuentran las siguientes: Encapsulación de lógica de negocio. Diferentes clientes de la aplicación pueden acceder al mismo servidor intermedio. Esto permite evitar la redundancia y los costos de mantenimiento de duplicar las reglas de negocio para cada aplicación cliente por separado. Aplicaciones clientes pequeñas. Al delegar las tareas más pesadas en la capa media las aplicaciones clientes consumen menos recursos de procesador y memoria, permitiendo 30

31 instalarse en máquinas de bajo rendimiento. Esto trae la ventaja de que por muchos clientes que accedan a la aplicación, el motor de bases de datos sólo tiene una conexión, que va directamente al servidor de aplicaciones, evitando así problemas de concurrencia o latencia de datos entre distintas aplicaciones cliente. Se reduce el tráfico de datos por la red pues la capa intermedia solo transmite los datos imprescindibles para las tareas de la aplicación. Estas aplicaciones son idóneas para funcionar a través de Internet ya que su consumo de ancho de banda es mínimo, al contrario de conectar directamente con el motor de bases de datos. Incrementa la seguridad. Podemos aislar la funcionalidad en las capas dando restricciones de seguridad. Esto proporciona unos niveles de seguridad configurables y flexibles. Las capas intermedias pueden limitar los puntos de entrada a material protegido, permitiendo controlar el control de acceso más fácilmente. Si usamos HTTP o COM+, podemos utilizar los modelos de seguridad que soportan. Para lograr la transferencia de los datos entre las diferentes capas de la arquitectura se requieren de la implementación de una serie de protocolos y especificaciones. Entre los más utilizados podemos encontrar los siguientes: CORBA (Common Object Request Broker Architecture): Es un estándar desarrollado por el Object Management Group (OMG), el cual establece una plataforma de desarrollo de sistemas distribuidos que facilitan la invocación de métodos remotos. Mediante su implementación es posible que aplicaciones desarrolladas por diferentes fabricantes, de diferentes lenguajes o ejecutándose en diferentes plataformas puedan interactuar entre sí. Java RMI (Java Remote Method Invocation): Posibilita crear aplicaciones distribuidas basadas exclusivamente en Java, donde un método presente en una máquina virtual puede ser invocado desde otra máquina virtual. Por medio de RMI un programa java puede ser accedido a través de la red donde queda a la espera de un cliente que se conecte e invoque sus métodos..net Remoting: Es una tecnología desarrollada por la empresa Microsoft y fue diseñado para permitir las comunicaciones en un ambiente de aplicaciones distribuidas. Mediante la 31

32 misma se pueden crear aplicaciones cliente que utilicen objetos en otros procesos del mismo equipo o en cualquier otro equipo disponible en la red. SOAP (Simple Object Access Protocol): Es un protocolo creado para intercambiar información estructurada en un ambiente de aplicaciones distribuidas. Posibilita que dos objetos en diferentes procesos puedan comunicarse mediante el intercambio de datos en formato XML. Permite la interacción entre varios dispositivos y tiene la capacidad de transmitir información compleja a través de HTTP, SMTP, etc. Otros de los mecanismos que tienen estas aplicaciones para intercambiar información entre sus procesos son los servicios web. Según define la W3C (World Wide Web Consortium), los servicios web son un conjunto de aplicaciones o de tecnologías con capacidad para interoperar en la Web. Estas aplicaciones o tecnologías intercambian datos entre sí con el objetivo de ofrecer unos servicios. Los proveedores ofrecen sus servicios como procedimientos remotos y los usuarios solicitan un servicio llamando a estos procedimientos a través de la Web [14] Aplicación web Cuando hablamos de aplicaciones web, nos referimos a aplicaciones basadas en el modelo Cliente/Servidor que gestionan datos almacenados en un servidor web, y que utilizan como interfaz páginas en formato HTML, conteniendo datos hipermedia. El usuario se comunica con la aplicación desde cualquier cliente conectado a la red [15]. A diferencia de las aplicaciones tradicionales donde el objetivo principal es el de procesar datos, una aplicación web tiene el objetivo de ofrecer un servicio a cada usuario que se conecte. La utilización de este tipo de aplicaciones tiene como ventajas que: Se pueden utilizar sin la necesidad de instalar ningún programa en la computadora y consumen pocos recursos en la computadora de los clientes ya que muchas de las tareas se realizan en el servidor. Son fáciles de mantener y actualizar ya que no es necesario distribuir copias de la aplicación entre los usuarios que la utilizan. Como el sistema lo gestiona el desarrollador, cuando el usuario lo utiliza siempre tiene la última versión a su disposición. 32

33 No presentan problemas de compatibilidad con el hardware utilizado, solamente es necesario contar con un navegador web actualizado, y no ocupan espacio en el disco duro de los clientes. Se pueden utilizar desde cualquier sistema operativo utilizado por los clientes y es independiente del tipo de dispositivo que se utilice para acceder a la misma. Varias tecnologías incluyendo XHTML, PHP, AJAX, JavaScript y Flash, permiten un desarrollo efectivo de programas soportando todos los sistemas operativos principales. Pueden ser utilizadas por múltiples usuarios al mismo tiempo. Posibilitan la colaboración entre clientes que se encuentran en localizaciones geográficas distantes entre sí. Estas aplicaciones, tal y como se muestra en la Figura 5, mantienen las características de una página web convencional ya que presenta enlaces a otras páginas y está diseñada de forma estructural para facilitar su navegación. Los tipos de aplicaciones web más comunes son bases de datos en línea, aplicaciones de comercio electrónico, cursos virtuales, correo electrónico, entre otras. Figura 5. Aplicación web para una Base de Datos bibliográfica. 33

34 Son varias las tecnologías involucradas en el desarrollo de aplicaciones web, algunas se ejecutan del lado del cliente y otras en el servidor web, entre las más utilizadas tenemos las siguientes: JavaScript: Es un leguaje de script basado en objetos que se ejecutan en la computadora del cliente. Mejora considerablemente la interfaz gráfica de las aplicaciones web y permite la ejecución de códigos asociados a eventos, como pulsar un botón o seleccionar una casilla de verificación. Su aplicación más habitual es la validación de datos de un formulario antes de enviarlos al servidor. Applets Java: Es una aplicación escrita en Java que se lanza desde una página web y que es enviada por el servidor para su ejecución en el cliente. Se ejecutan en el navegador utilizando la máquina virtual de java. Los applets son más difíciles de programar que los scripts en JavaScript y requerirán unos conocimientos básicos o medios del lenguaje Java; pero son independientes del navegador y del sistema operativo donde se ejecutan. ActiveX: Es un estándar desarrollado por Microsoft que permite la ejecución de programas en el cliente. Se pueden incluir dentro de páginas web y realizan diferentes acciones. Representa un riesgo grande de seguridad ya que pueden otorgarse permisos y realizar acciones no deseadas en el cliente. Funcionan solamente en el navegador Internet Explorer. CSS (Cascading Style Sheets): En español se traducirían como hojas de estilo en cascada, se trata de un conjunto de instrucciones escritas que definen las apariencias de una página web con el objetivo de que sus estilos se parezcan. Tienen la función de separar el diseño de la página del contenido y posibilita realizar cambios en la imagen de un sitio completo con solo modificar el fichero que contiene las especificaciones CSS. AJAX (Asynchronous JavaScript And XML): Es una técnica de desarrollo que agrupa una serie de tecnologías web para crear aplicaciones con un alto nivel de interactividad y velocidad. Permite mejorar completamente la interacción del usuario con la aplicación, evitando las recargas constantes de la página, ya que el intercambio de información con el servidor se produce en un segundo plano. CGI (Common Gateway Interface): Fue uno de los primeros mecanismos diseñados para crear aplicaciones web y consiste en pequeñas aplicaciones programadas en Perl, 34

35 C++, Java o Visual Studio que se ejecutan en un servidor web. En la actualidad ha sido sustituida por tecnologías más seguras. ASP (Active Server Pages): Es una tecnología desarrollada por Microsoft que permite el uso de diferentes scripts y componentes en conjunto con el tradicional HTML para mostrar páginas generadas dinámicamente. Esta tecnología funciona del lado del servidor, las instrucciones de programación dentro del script son ejecutadas para enviar al navegador únicamente el código HTML resultante. PHP: Es un lenguaje interpretado de propósito general soportado por HTML, muy popular en el desarrollo de aplicaciones web. La sintaxis está heredada de C, Java y Perl. El código creado se ejecuta del lado del servidor. Para el diseño y programación de las aplicaciones web existen una serie de herramientas que nos facilitan el trabajo, algunas son comerciales como Adobe Dreamweaver y otras son de libre uso como Aptana y Amaya. No obstante, una de las vías más populares de desarrollo de aplicaciones web es a través del uso de diferentes framework, los cuales agilizan el proceso de creación de este tipo de aplicaciones y pueden ser utilizados libremente por cualquier desarrollador. Un framework para aplicaciones web es una estructura de software bien definida y documentada, la cual ha sido diseñada para facilitar el desarrollo de este tipo de aplicaciones. Les brinda a los diseñadores y programadores una mejor organización y estructura de sus proyectos, lo que repercute en la aceleración del proceso de desarrollo mediante la reutilización de código ya existente. Mediante el uso de un framework se intenta aliviar el exceso de carga asociado con actividades comunes usadas en desarrollos web. Entre los framework más utilizados por la comunidad de desarrolladores de aplicaciones web se encuentran los siguientes: Synfony Con un millón de descargas mensuales y más de 150 mil desarrolladores es considerado el líder de los framework PHP para la creación de sitios web y aplicaciones web. Según sus creadores Symfony es un conjunto de componentes PHP, un framework de aplicaciones web, una filosofía y una comunidad; trabajando unidos en armonía [16]. Está diseñado para 35

36 construir aplicaciones empresariales robustas y le da a los desarrolladores un control total sobre su configuración. Symfony2 ha sido ideado para exprimir al límite todas las nuevas características de PHP 5.3 y por eso es uno de los frameworks PHP con mejor rendimiento. Su arquitectura interna está completamente desacoplada, lo que permite reemplazar o eliminar fácilmente aquellas partes que no encajan en un proyecto [17]. La primera versión de Symfony fue lanzada en octubre de 2005, por Fabien Potencier, es patrocinada por Sensio Labs [18], una compañía francesa que provee consultoría, servicios, formación sobre tecnologías open source. Symfony fue diseñado para ajustarse a los siguientes requisitos: Es fácil de instalar y configurar en la mayoría de plataformas. Es Independiente del sistema gestor de bases de datos utilizado por la aplicación web a desarrollar. Es preferible utilizarla en el desarrollo de grandes aplicaciones web, principalmente aplicaciones empresariales, adaptándose a las políticas y arquitecturas propias de cada empresa. Es fácil de extender, lo que permite su integración con las bibliotecas de otros fabricantes. Tiene su propia implementación MVC (Modelo Vista Controlador), siguiendo la mayoría de mejores prácticas y patrones de diseño para la web. Laravel En estos momentos es el más popular de los framework PHP, se caracteriza por su poder y elegancia a la hora de programar una aplicación web. Laravel reutiliza y ensambla componentes existentes en una capa única sobre la que se construyen las aplicaciones web. Está inspirado en los más populares framework PHP y ofrece un conjunto de herramientas robustas para la construcción de aplicaciones web [19]. Cuenta con una amplia comunidad de desarrolladores a nivel mundial que socializan el conocimiento a través de diversas plataformas. 36

37 Laravel tiene como objetivo ser un framework que permita el uso de una sintaxis elegante y expresiva para crear código de forma sencilla y permitiendo multitud de funcionalidades. Intenta aprovechar lo mejor de otros frameworks y aprovechar las características de las últimas versiones de PHP [20]. Gran parte de Laravel está formado por dependencias de Symfony, esto implica que el desarrollo de Laravel dependa también del desarrollo de sus dependencias. Entre las principales características de este framework de desarrollo web se encuentran: Incluye un sistema de mapeo de datos relacional llamado Eloquent ORM que facilita la creación de modelos. Dispone de un sistema de procesamiento de plantillas llamado Blade. Utiliza el patrón de arquitectura de software Modelo Vista Controlador (MVC) Implementa un sistema de ruteo para realizar el llamado de los diferentes recursos de la aplicación web. Utiliza Composer para el manejo de las diferentes dependencias de los módulos utilizados en el framework. Dispone de una herramienta de comandos llamada Artisan para realizar una serie de tareas de forma automatizada. Apache Struts Framework desarrollado para ser utilizados en aplicaciones web que utilicen la plataforma de la edición empresarial de Java (J2EE). Se le han introducido algunas mejoras que simplifican las tareas más comunes del desarrollo de aplicaciones web y mejoran su integración con AJAX. Struts se desarrollaba como parte del proyecto Jakarta de la Apache Software Foundation; pero actualmente es un proyecto independiente conocido como Apache Struts. Se basa en el patrón de arquitectura de software Modelo-Vista-Controlador (MVC) el cual se utiliza ampliamente y es considerado de gran solidez. Reduce considerablemente el tiempo de desarrollo de una aplicación web y u compatibilidad con todas las plataformas en las que Java Entreprise esté disponible lo convierten en una herramienta altamente disponible. 37

38 Ruby on Rails Es un framework escrito en el lenguaje de programación Ruby. Permite desarrollar aplicaciones web con menos código que otros framework y con un mínimo de configuraciones. El lenguaje de programación Ruby permite la metaprogramación, de la cual Rails hace uso, lo que resulta en una sintaxis que muchos de sus usuarios encuentran muy legible. Rails se distribuye a través de RubyGems, que es el formato oficial de paquete y canal de distribución de bibliotecas y aplicaciones Ruby. Rails incluye el framework de Javascript jquery y script.aculo.us, una biblioteca en Javascript con mejoras en la interfaz de usuario. WebApp.Net (Mobile Web Application Framework) Es un ligero y a la vez poderoso framework para desarrollar aplicaciones web móviles utilizando JavaScript. Aprovecha ampliamente las ventajas de la tecnología Ajax. Cuenta con una gran variedad de componentes para darle una apariencia gráfica atractiva a las aplicaciones desarrolladas, las cuales soportan los dispositivos móviles de última generación Almacenes de Datos y Data Mart El término Data Warehouse, que traducido al español sería almacén de datos, fue definido por William Inmon como una colección de bases de datos integradas y orientadas a un tema, diseñada para el soporte de la toma de decisiones, donde cada unidad de datos es relevante para determinado momento en el tiempo [21]. El concepto de almacén de datos surge debido a las dificultades de los sistemas tradicionales de almacenamiento de datos en satisfacer las necesidades informacionales globales de las organizaciones. Aunque las bases de datos operacionales y los almacenes de datos tienen en común el hecho de estar formadas por tablas con datos, índices, llaves, vistas y consultas, estas tienen diferencias significativas. Las bases de datos operacionales están diseñadas y optimizadas para registrar datos, son sistemas de Procesamiento de Transacciones en Línea (OLTP, On- Line Transaction Processing), donde cada transacción debe ser registrada lo más rápidamente posible. Sin embargo, los almacenes de datos están diseñados y optimizados para facilitar la consulta y el análisis de los datos para el soporte en la toma de decisiones. Son sistemas de 38

39 Procesamiento Analítico en Línea (OLAP, On-Line Analytical Processing) que contienen datos que no se modifican y que pueden ser consultados y analizados más eficientemente que las bases de datos operacionales. La principal ventaja de los almacenes de datos está dada por la estructura de la información que contienen. Se trata del almacenamiento de información homogénea y fiable, en una estructura basada en la consulta y el tratamiento jerarquizado de la misma, y se encuentran en un entorno diferente al de los sistemas operacionales. En la Figura 6 se puede ver el diagrama de un sistema de almacén de datos típico con los elementos que lo componen y los posibles usos que puede hacer una organización de esta tecnología. Figura 6. Diagrama de un sistema de almacén de datos. Las fuentes internas de las que se nutre el almacén de datos provienen de las diferentes bases de datos transaccionales con que cuenta una organización. Por su parte las fuentes externas de datos están formadas por ficheros donde los datos pueden están almacenados con diferentes formatos (ficheros Excel, texto, HTML, etc.). Todos estos datos son copiados en el almacén de datos periódicamente y de forma organizada. Los datos de los sistemas de la fuente son 39

40 examinados por un perfilador el cual determina las características de los mismos, por ejemplo cuántas filas hay en cada tabla o cuántas tienen valores nulos. El sistema ETL (Extract, Transform and Load) tiene la función de conectarse a las diferentes fuentes de datos para leerlos, transformarlos y cargarlos en el sistema de destino, que no tiene que ser necesariamente el almacén de datos. Este sistema se encarga de la limpieza y transformación de los datos. De esta forma se trata de evitar el envió al destino de datos redundantes e inconsistentes. Además también tiene la función de estandarizar medidas, formatos, fechas y tratar valores nulos. Las reglas de calidad de los datos se encargan de realizar los chequeos de calidad a las bases de datos. Los datos con problemas son almacenados en una base de datos para ser reportados y corregidos en los sistemas fuentes. El sistema de control tiene la función de dirigir y administrar el sistema ETL de acuerdo con la secuencia, las reglas y la lógica almacenada en los metadatos. Por su parte, los metadatos es una base de datos que contiene información acerca de la estructura, el significado, el empleo, las reglas de calidad y otra información sobre los datos. El sistema auditor registra las operaciones de usos del sistema y las almacena dentro de la base de datos de los metadatos. Monitorea las actividades de los procesos ETL y registra sus estadísticas operacionales. Se utiliza para comprender qué sucede durante los procesos ETL. Finalmente, cuando los datos han sido procesados satisfactoriamente son enviados a una base de datos multidimensional, la cual es definida como una variación del modelo relacional que utiliza estructuras multidimensionales para organizar los datos y expresar relaciones entre ellos [22]. Conceptualmente, una base de datos multidimensional utiliza la idea de un cubo, donde los datos se almacenan en celdas y la posición de cada celda es definida por un número de variables que reciben el nombre de dimensiones. Este tipo de base de datos está optimizada para cumplir con las funciones de almacén de datos y para ser utilizadas por aplicaciones de procesamiento y análisis en línea (OLAP). 40

41 Sobre estas bases de datos se pueden construir Sistemas de Información para Directivos (EIS) y Sistemas de Ayuda a la toma de Decisiones (DSS). Las primeras son aplicaciones de alto nivel que pretenden, mediante el acceso a las diferentes bases de datos de una empresa, ofrecer a sus directivos los elementos clave para que puedan tomar decisiones sobre la marcha de la organización. Por su parte, los DDS permiten realizar el análisis de las diferentes variables de negocio. Su principal característica es la capacidad de análisis multidimensional que permite profundizar en la información hasta llegar a un alto nivel de detalle. También se puede utilizar la minería de datos para extraer información valida y previamente desconocida, que aporten nuevos conocimientos a la organización a partir del procesamiento de grandes volúmenes de datos. Una alternativa viable para pequeñas y medianas organizaciones, donde la cantidad de datos almacenados no es muy elevado, está en la implementación de un Data Mart. Estos son almacenes de datos pequeños que están centrados en un tema y responden a los intereses de determinada áreas de negocio dentro de una organización. Se caracteriza por disponer de la estructura óptima de datos para analizar la información al detalle desde todas las perspectivas que afecten a los procesos de dichas áreas de negocio. Los datos almacenados en ellos pueden ser agrupados, explorados y distribuidos para que un grupo de usuarios realice la explotación de los mismos y los ayude en la toma de decisiones. Son sistemas orientados a las consultas, donde la frecuencia de cargas de datos es baja y conocida. A partir de ellos se puede hacer uso de herramientas de Procesamiento Analítico en Línea (OLAP). Según refiere William Inmon, existen dos tipos de Data Mart, los dependientes y los independientes. Un Data Mart dependiente es aquel cuya fuente es el almacén de datos. Un Data Mart independiente es uno cuya fuente son las aplicaciones utilizadas en el medio donde se desarrolla. Todos los Data Marts dependientes son alimentados por la misma fuente, el almacén de datos. Cada Data Mart independiente es alimentado excepcionalmente y por separado de las aplicaciones utilizadas en el medio [23]. Este autor es del criterio que los Data Mart se deben construir después de haber terminado la construcción del almacén de datos de la organización. 41

42 Por su parte, Ralph Kimball defiende la idea de que un almacén de datos está compuesto por la unión de los diferentes Data Mart construidos en una organización. El plantea que cuando los diferentes Data Mart entran en línea, ellos se unen como las piezas de un rompecabezas. En este momento, estos Data Mart cumplen con la función de un almacén de datos empresarial integrado. El almacén de datos inevitablemente consistirá en diferentes maquinas con sus propios sistemas operativos y sistemas de gestión de bases de datos. Si se diseñan coherentemente, podrán compartir una arquitectura uniforme de dimensiones y hechos conformados que les permitirá ser fundido en un todo integrado [24]. En la Tabla 1 se pueden ver algunas de las diferencias que tienen entre sí los almacenes de datos y los Data Mart. Tabla 1. Diferencia entre un almacén de datos y un Data Mart. Almacén de datos Corporativos. Bajo nivel de granularidad. Estructura normalizada. Gran cantidad de datos históricos. Tecnología óptima para el almacenamiento y gestión de un gran volumen de datos. La estructura es global para toda la organización. Ligeramente indexado. Data Mart Departamentales Alto nivel de granularidad. Estructura en estrella. Modesta cantidad de datos históricos. Tecnología óptima para el acceso y el análisis. Cada departamento tiene una estructura diferente. Excesivamente indexados. La implementación de un Data Mart es muy similar a la de los almacenes de datos, ya que debe proporcionar las mismas funcionalidades. La ventaja de su utilización radica en que: Permiten un fácil acceso a los datos que se necesitan frecuentemente. Mejora el tiempo de respuesta del usuario final ya que las consultas son más rápidas. Permite crear vistas colectivas para grupos de usuarios. Son menos costosos que desarrollar un almacén de datos. Mejorar la calidad de la gestión a partir de información relevante y con un significado homogéneo. 42

43 Permitir una visión global de la información en base a los conceptos de negocio que tratan los usuarios. Posibilita establecer una base única del modelo de información de las empresas y organizaciones. Existen soluciones económicas y probadas satisfactoriamente en la implantación de almacenes de datos y Data Mart. Ejemplo de ésto es MySQL, un popular gestor de base de datos de uso libre, empleado por muchas empresas para la gestión de sus datos y como soporte a herramientas de inteligencia empresarial. Ha sido probada en aplicaciones que requieren de una alta demanda de transacciones y como almacén de datos con volúmenes de almacenamiento del orden de los terabyte. A continuación se exponen algunas de las características que hacen de MySQL una opción válida para este tipo de aplicaciones [25] : Partición de datos e índices, soporta rangos, llaves, listas y particiones compuestas. Elevada capacidad de almacenamiento (110 TB). Gestión automática del proceso de almacenamiento. Soporta ANSI-SQL para todos los tipos de datos, incluso BLOB y XML. Opciones de replicación fáciles de configurar. Tablas en la memoria principal, mantiene los datos en la RAM lo que es ideal para tablas dimensionales. Soporte para variedad de índices: B-Tree, Texto completo, HASH, GIS Caché de datos múltiples y configurables. Precarga de los índices de los datos en el caché de índices. Un caché único de consultas, trae como resultado respuestas rápidas a consultas repetidas como las que se utilizan en los almacenes de datos. Carga paralela de datos. Compresión de datos. Posibilidad de crear tablas de solo lectura para proteger datos sensibles. Encriptación de los datos para mayor seguridad. Multiplataforma, puede funcionar en diferentes sistemas operativos. No requiere de un hardware especial para su funcionamiento. 43

44 Existen un conjunto de estrategias y herramientas enfocadas a la administración y creación de conocimiento mediante el análisis de datos existentes en los almacenes de datos y Data Marts. Estas técnicas reciben el nombre de inteligencia empresarial o inteligencia de negocios (BI, Business Intelligence) y le permiten a las organizaciones obtener el máximo valor de sus activos de información. Entre las facilidades que brindan están la comprensión del desempeño de las organizaciones en el pasado, el monitoreo de las actividades actuales para responder rápidamente a los cambios, optimizan los procesos de negocios, manejan los riesgos y pronostican nuevas posibilidades de negocios [26]. Muchas compañías como Microsoft, IBM, Oracle y SAP ofrecen al mercado soluciones comerciales para la implementación y explotación de los almacenes de datos y la inteligencia empresarial. Este tipo de herramientas son muy costosas y no están al alcance de nuestro país. No obstante, es posible implementar soluciones empresariales mediante el uso de herramientas libres, algunas de estas herramientas se describen brevemente a continuación: Pentaho Edición Comunitaria Es una suite desarrollada para implementar soluciones de inteligencia de negocios. Incluye una herramienta ETL para la extracción y tratamiento de los datos. También cuenta con herramientas OLAP para el análisis de los datos, minería de datos, reportes, tableros de mando y una plataforma que nos permite crear soluciones para los problemas de negocios. La comunidad de Pentaho está formada por miles de personas que están dedicadas al desarrollo de esta herramienta. Existe abundante documentación sobre la utilización e implementación de soluciones con esta suite. Palo Suite En esta suite se combinan tres de las aplicaciones desarrolladas por la compañía Jedox. Está formada por un servidor OLAP de gran estabilidad y desempeño. Cuenta con una interfaz web que permite crear y administrar reportes basados en la web, también permite configurar las 44

45 demás herramientas de la suite por esta vía. Finalmente cuenta con un servidor ETL que permite extraer, transformar y cargar los datos desde diferentes fuentes. SpagoBI Es una plataforma de inteligencia de negocios que ofrece soluciones para los requerimientos de análisis de datos de una organización. Cuenta con soluciones para reportes en línea, análisis de datos multidimensionales, minería de datos, monitoreo y tableros de mando en tiempo real. Tiene soporte para procesos ETL y permite análisis gráfico y geográfico. Es una plataforma ya que cubre y satisface todos los requisitos de la Inteligencia de Negocios, tanto en términos de análisis y de gestión de datos, administración y seguridad. DecisionStudio Professional Es una plataforma de inteligencia empresarial que contiene las herramientas necesarias para el análisis de datos. Utiliza MySQL como plataforma para el almacén de datos. Cuenta con herramientas para el modelado, generación de reportes, análisis de datos y minería de datos. Cuenta con una interfaz gráfica para el desarrollo de aplicaciones de análisis utilizando Pyton. OpenI Es una aplicación web de inteligencia empresarial. Permite la visualización de forma simple y clara de los datos desde un servidor OLAP. Los usuarios pueden construir diferentes tipos de reportes, realizar análisis de los datos y utilizar tableros de mando. JasperServer Es un servidor de inteligencia de negocios que puede funcionar por sí mismo o integrado en otras aplicaciones. Cuenta con una herramienta de análisis OLAP que permite realizar diferentes operaciones sobre los datos. Funciona con una base de datos MySQL y servidor web Apache. Genera diferentes tipos de reportes y gráficos con posibilidades de exportarlos a diferentes formatos. 45

46 1.2.4 Aplicaciones de minería de datos En la actualidad, toda la actividad realizada por el hombre genera gran cantidad de información que puede ser almacenada en formato electrónico, ya sea organizada en bases de datos o no. Mucha de esta información es generada con un fin determinado; pero posteriormente no se analiza ni se integra con el resto de la información existente. Esto se debe al desconocimiento de las técnicas utilizadas para realizarlo y al no contar con las herramientas y el personal capacitado. A partir de los años 90 comienza a tener auge entre las organizaciones el término minería de datos. Esto ha sido motivado por el desarrollo alcanzado en los sistemas de bases de datos que posibilitan la automatización de los procesos de almacenamiento, organización y recuperación de la información a menor costo y mayor velocidad. Otros de los factores han sido el incremento de intercambio de datos, en los más diversos formatos, a través de Internet y el aumento de las capacidades de almacenamiento junto a la disminución de los costos del equipamiento asociado. La minería de datos es el proceso de extracción de información valida, previamente desconocida, comprensible y útil a partir del procesamiento de grandes volúmenes de datos, con el objetivo de utilizar el conocimiento obtenido para la toma de decisiones. Esto implica actuar sobre bases de datos de gran tamaño y complejidad, para extraer el conocimiento que no es evidente o imposible de obtener mediante la utilización de las herramientas de recuperación tradicionales. En la bibliografía consultada podemos encontrar algunas definiciones que ilustran mejor esta tecnología: La minería de datos es el análisis de un conjunto de datos (a menudo grande) producto de la observación, para encontrar relaciones insospechadas y resumir la información de forma novedosa para que sea comprensible y útil al propietario de los datos [27]. 46

47 La minería de datos es un campo interdisciplinario que agrupa técnicas de aprendizaje por computadora, el reconocimiento de patrones, procesamiento estadístico, bases de datos, y visualización, dirigido a extraer información de bases de datos de gran tamaño [28]. La tecnología de la Minería de Datos es el resultado de un largo proceso de investigación y desarrollo, siendo en sus inicios de uso exclusivo de grandes corporaciones, instituciones gubernamentales y bancos. Sin embargo, en la actualidad ha sido posible extender esta tecnología a las pequeñas y medianas organizaciones. La causa de esto radica en el desarrollo alcanzado por las tecnologías informáticas, a la aparición de motores de bases de datos relacionales de alto desempeño, a la madurez alcanzada por las técnicas de inteligencia artificial y aprendizaje de máquinas y la aparición de herramientas de minería de datos más fáciles de utilizar. La minería de datos no se limita a ser utilizada solamente en aplicaciones empresariales. Su uso es cada vez mayor en las instituciones científicas como soporte a la investigación científico-técnica. Es ampliamente utilizada como herramienta de análisis y descubrimiento de conocimiento a partir de datos de observación o de resultados de experimentos. Su campo de acción abarca desde el análisis de datos científicos, la biomedicina, la ingeniería, el control automático, el desarrollo de la robótica hasta la gestión y administración de proyectos. Podemos decir que el uso de la Minería de Datos contribuye a la toma de decisiones tácticas y estratégicas proporcionando un sentido automatizado para identificar información clave desde volúmenes de datos generados por procesos tradicionales. Las aplicaciones de minería de datos tienen el fin de extraer patrones, de describir tendencias y regularidades, de predecir comportamientos y, en general, de sacar partido a la información computarizada que nos rodea hoy en día, generalmente heterogénea y en grandes cantidades, permite a los individuos y a las organizaciones comprender y modelar de una manera más eficiente y precisa el contexto en el que deben actuar y tomar decisiones [29]. 47

48 Como se puede ver en la Figura 7, la creación de un proyecto de Minería de Datos pasa por diferentes fases, estas varían de autor en autor y también dependen de dónde se vaya a implantar dicho proyecto [30]. Figura 7. Fases de un proyecto de minería de datos 1. Identificar el problema y formular la hipótesis: En esta fase es necesario tener una idea clara de cuál es el problema que se quiere resolver mediante la aplicación de la minería de datos. Se especifican un conjunto de variables que puedan tener alguna dependencia desconocida y se puede formular alguna hipótesis inicial. 2. Seleccionar los datos: En esta fase se seleccionan los datos necesarios para el procesamiento. En la mayoría de los casos estos datos se obtienen de la fuente de forma aleatoria. Es importante tener en cuenta que tanto los datos utilizados para obtener un modelo como los utilizados para validarlo deben provenir de la misma muestra seleccionada. 3. Preprocesado de los datos: En la mayoría de las veces el formato de los datos contenidos en la fuente de datos no es el idóneo, lo que hace imposible utilizar alguno de los algoritmos. Mediante el preprocesado, se filtran los datos eliminándose valores incorrectos, no válidos o desconocidos. Se obtienen muestras de los mismos o se reducen el número de valores posibles mediante redondeo, agrupamiento, etc. 4. Selección de variables: Aún después de haber sido preprocesados, se sigue teniendo una cantidad considerable de datos. La selección de características reduce el tamaño de los datos, eligiéndose las variables más influyentes en el problema, sin sacrificar la calidad del modelo de conocimiento obtenido del proceso de minería. Los métodos para la selección de características son dos: Los basados en la elección de los mejores atributos del problema. 48

49 Los que buscan variables independientes mediante test de sensibilidad, algoritmos de distancia o heurísticos. 5. Extracción de Conocimiento: Mediante una técnica se obtiene un modelo de conocimiento, que representa patrones de comportamiento observados en los valores de las variables del problema o relaciones de asociación entre dichas variables. También pueden usarse varias técnicas a la vez para generar distintos modelos. 6. Interpretación y evaluación: Finalmente se procede a su validación, comprobando que las conclusiones son válidas y satisfactorias. En el caso de haber obtenido varios modelos mediante el uso de distintas técnicas, se deben comparar los modelos en busca de aquel que se ajuste mejor al problema. Si ninguno de los modelos alcanza los resultados esperados, se alterará alguno de los procesos anteriores en busca de nuevos modelos. En minería de datos se utilizan varios algoritmos, los cuales se clasifican en dos grupos: los algoritmos supervisados o predictivos y los algoritmos no supervisados o de descubrimientos del conocimiento. Los algoritmos supervisados o predictivos trabajan sobre el conjunto de datos prediciendo el valor de un atributo a partir del conocimiento de otros. Es decir, a partir del valor de los atributos conocidos se induce una relación entre esos datos y otra serie de atributos para realizar la predicción en datos cuya etiqueta es desconocida. Esta forma de trabajar se conoce como aprendizaje supervisado y se desarrolla en dos fases: 1. Entrenamiento: Consiste en construir un modelo utilizando una gran muestra de datos históricos, llamada conjunto de entrenamiento 2. Prueba: Comprobación del modelo utilizando datos nuevos. Por otra parte, los algoritmos no supervisados o de descubrimiento del conocimiento se utilizan cuando no se cuenta con la suficiente cantidad de datos históricos y se hace necesario recurrir a los métodos que descubren patrones y tendencias en los datos actuales. 49

50 Existen otras técnicas de Minería de Datos para extraer conocimientos de las bases de datos entre las que se encuentran el modelado predictivo, segmentación, análisis de enlaces y detección de desviaciones. El modelado predictivo utiliza observaciones para formar un modelo de las características más importantes de algún tipo de fenómeno; en base a generalizaciones encaja nuevos datos dentro de un marco general. Las técnicas de segmentación particionan una base de datos en un número desconocido de segmentos, clústeres o grupos de registros similares, los cuales comparten una serie de propiedades y que por ello se consideran homogéneos. El análisis de enlaces trata de establecer vínculos o asociaciones entre los registros individuales o entre los conjuntos de registros de una base de datos. La detección de desviaciones permite identificar las excepciones que expresan una desviación con respecto a una cierta expectativa o a una norma previamente conocida. Pueden utilizarse mediante técnicas de visualización y estadísticas. Las aplicaciones de esta tecnología se desarrollan bajo lenguajes de última generación basados en la inteligencia artificial y utilizan modelos matemáticos como: Redes neuronales artificiales: Grupo de unidades interconectadas y organizadas por capas que aprenden a través del entrenamiento y semejan la estructura de una red neuronal biológica. Arboles de decisión: Estructuras en forma de árbol que representan conjuntos de decisiones, las cuales generan reglas para la clasificación de un conjunto de datos. Algoritmos genéticos: Técnicas de optimización que usan procesos tales como combinaciones genéticas, mutaciones y selección natural en un diseño basado en los conceptos de evolución. Estos algoritmos proporcionan programas y optimizaciones que pueden ser utilizados en la construcción y entrenamiento de otras estructuras como las redes neuronales. Método del vecino más cercano: Un procedimiento para clasificar a los registros de un archivo mediante la identificación de grupos (clúster), decidiendo a cuál grupo pertenece cada uno de los registros. 50

51 Reconocimiento de patrones: Se trata de un grupo de técnicas orientadas a evaluar la similitud y las diferencias entre señales. Se involucran en esto a varios tipos de preprocesamiento tales como la transformada de Fourier. Mapas característicos de Kohonen: Es una red neuronal donde los datos son mostrados a la estructura y esta se sensibiliza a los patrones presentes. Una vez entrenada es capaz de identificar tales patrones en nuevos datos. Las herramientas de Minería de Datos pueden responder a preguntas que tradicionalmente consumen demasiado tiempo para poder ser resueltas y a los cuales los usuarios de esta información casi no están dispuestos a aceptar. Estas herramientas exploran las bases de datos en busca de patrones ocultos, encontrando información predecible que un experto no puede llegar a encontrar porque se encuentra fuera de sus expectativas. Dan la posibilidad de explorar automáticamente, visualizar y comprender los datos e identificar patrones, relaciones y dependencias que impactan en los resultados finales de un proyecto o servicio. Entre las herramientas de minerías de datos más utilizadas por la comunidad científica se encuentra WEKA, el cual es un conocido software para aprendizaje automático y minería de datos desarrollado en la de la Universidad de Waikato, Nueva Zelanda. Entre sus ventajas esta la portabilidad, ya que al ser implementado en java puede funcionar en casi cualquier plataforma informática. Por otra parte se encuentra disponible libremente para su utilización bajo los términos de la licencia pública general de GNU. El proyecto WEKA se propone proveer a los investigadores de una completa colección de algoritmos de aprendizaje por computadoras y herramientas para el preprocesamiento de datos. Les permite a los usuarios de forma muy rápida probar y comparar diferentes métodos de aprendizaje en nuevos conjuntos de datos [31]. Contiene una colección de herramientas de visualización y algoritmos para análisis de datos y modelado predictivo, unidos a una interfaz gráfica de usuario para acceder fácilmente a sus funcionalidades. WEKA soporta varias tareas estándar de minería de datos como: preprocesamiento de datos, clustering, clasificación, regresión, visualización y selección. 51

52 WEKA también proporciona acceso a bases de datos vía SQL gracias a la conexión JDBC (Java Database Connectivity) y puede procesar el resultado devuelto por una consulta realizada a la base de datos. No puede realizar minería de datos multi-relacional; pero existen aplicaciones que pueden convertir una colección de tablas relacionadas de una base de datos en una única tabla para que pueda ser procesada por la aplicación. Otra de las aplicaciones ampliamente utilizadas es RapidMinder, el cual es un programa informático para el análisis y minería de datos. Permite el desarrollo de procesos de análisis de datos mediante el encadenamiento de operadores a través de un entorno gráfico. Se usa en la investigación y en aplicaciones empresariales. La versión inicial fue desarrollada por el departamento de inteligencia artificial de la Universidad de Dortmund en Se distribuye bajo licencia GPL y está hospedado en el repositorio de software libre SourceForge desde el RapidMiner proporciona más de 500 operadores orientados al análisis de datos, incluyendo los necesarios para realizar operaciones de entrada y salida, preprocesamiento de datos y visualización. También permite utilizar los algoritmos incluidos en WEKA. Tiene las características de ser una aplicación multiplataforma, desarrollada con el lenguaje de programación Java. Utiliza ficheros XML para la representación interna de los procesos de análisis de datos. Es posible el desarrollo de programas con esta aplicación mediante la utilización de un lenguaje de script. Se puede utilizar a través de una interfaz de usuario, mediante línea de comandos, utilizando el procesamiento de ficheros en lotes o a través de otros programas mediante llamadas a su biblioteca. Incluyen gráficos y herramientas de visualización de datos. 1.3 Conclusiones del capítulo En este capítulo se realizó una descripción del Laboratorio de Dosimetría Externa del CPHR y de las características del servicio de dosimetría externa brindado a las diferentes entidades del país que cuentan con trabajadores expuestos a las radiaciones ionizantes. Se realizó un estudio sobre diferentes de sistemas automatizados de gestión de la información aplicados a los 52

53 servicios dosimétricos de otros países para buscar una solución tecnológica que se adapte a nuestras necesidades. Además, se han presentado los aspectos teóricos relacionados con la plataforma informática propuesta para el LDE y que abarcan temas como las aplicaciones cliente servidor, las aplicaciones web, los Data Mart como soporte a las herramientas para la toma de decisiones y la utilización de la minería de datos para la obtención de nuevo conocimiento a partir de datos almacenados. 53

54 Capítulo 2. Desarrollo del sistema de gestión de la información cliente servidor y de la aplicación web Para realizar el análisis y diseño del sistema de gestión de la información cliente servidor y de la aplicación web se hará uso de la metodología para la planificación, desarrollo y mantenimiento de sistemas de gestión METRICA 3 [32]. Esta metodología es promovida por el Ministerio de Administraciones Públicas del Gobierno de España, con el objetivo de sistematizar las actividades de ciclo de vida de los proyectos de sistemas informáticos utilizados por las administraciones públicas. Se basa en las Normas ISO/IEC (Information Technology - Software Life Cycle Processes) e ISO/IEC SPICE (Software Process Improvement and Assurance Standards Capability Determination) Esta metodología es un instrumento de gran utilidad para la organización de las actividades que dan soporte al ciclo de vida del desarrollo de un sistema de gestión de la información. Cubre aspectos de gestión que aseguran el cumplimiento de sus objetivos en términos de calidad, costos y plazos de ejecución. Esta metodología tiene un enfoque orientado al proceso y ha sido concebida para abarcar el desarrollo de sistemas de información de gran amplitud y complejidad. Se debe aplicar adaptada a las características particulares de cada proceso. La metodología descompone cada uno de los procesos en actividades, y éstas a su vez en tareas. Los procesos que forman la estructura principal de métrica son los siguientes. 1. Estudio de viabilidad del sistema (EVS): Se analizan un grupo de necesidades concretas que se basan en aspectos económicos, técnicos, legales y operativos, con la idea de proponer una solución a corto plazo. Los resultados obtenidos durante este proceso constituirán la base para tomar la decisión de seguir adelante o abandonar el proyecto. 2. Análisis del sistema de información (ASI): Este proceso tiene el objetivo de identificar las especificaciones del sistema a partir de los requisitos necesarios para su funcionamiento y de una serie de modelos que cubran las necesidades de información de los usuarios para los que se desarrollará el sistema de información. 3. Diseño del sistema de información (DSI): En este proceso se define la arquitectura del sistema y del entorno tecnológico que le va a dar soporte. Se generan todas las 54

55 especificaciones de construcción relativas al propio sistema, así como la especificación técnica del plan de pruebas, la definición de los requisitos de implantación y el diseño de los procedimientos de migración y carga inicial si proceden. 4. Construcción del sistema de información (CSI): En este proceso se lleva a cabo la programación y prueba de los distintos componentes del sistema de información, a partir del conjunto de especificaciones lógicas y físicas del mismo. Se genera el código de cada uno de los componentes del sistema de información y se van realizando las pruebas unitarias de cada uno de ellos y las de integración entre subsistemas. Se desarrollan los procedimientos de operación y seguridad y se elaboran los manuales de usuario final y de explotación. 5. Implantación y aceptación del sistema (IAS): Este proceso tiene como objetivo principal, la entrega y aceptación del sistema en su totalidad por parte de los usuarios finales. Para esto se somete al sistema a las pruebas de implantación con la participación de los usuarios, los que comprobarán el funcionamiento del mismo bajo las condiciones más extremas. En este proceso se elabora el plan de mantenimiento del sistema para que el responsable del mantenimiento conozca el sistema antes de que éste pase a producción. 2.1 Estudio de viabilidad del sistema (EVS) El objetivo principal de este proceso es el de identificar los requisitos generales del sistema y su alcance. La misma debe tener en cuenta restricciones económicas, técnicas, legales y operativas del objeto de estudio que se quiere automatizar. Esta etapa sirve de punto de partida al Análisis del Sistema de Información. En esta etapa, se realizan las siguientes actividades: 1. Establecimiento del alcance del sistema (EVS 1) 2. Estudio de la situación actual (EVS 2) 3. Definición de requisitos del sistema (EVS 3) 4. Estudio de alternativas de solución (EVS 4) 5. Valoración de las alternativas (EVS 5) 55

56 2.1.1 Establecimiento del alcance del sistema (EVS 1) Para establecer el alcance del sistema de automatización que se quiere desarrollar se realizaron encuentros de trabajos con los especialistas del LDE del CPHR donde se identificaron las siguientes necesidades de los usuarios: Contar con una herramienta más potente para la gestión y procesamiento de los datos generados por el servicio de dosimetría externa. La tecnología utilizada actualmente por el Laboratorio para el intercambio de datos entre la aplicación cliente y la base de datos es obsoleta, lenta y poco eficiente. Se requiere agrupar la información de años anteriores en una sola base de datos. Implementar apropiadamente todos los requerimientos de información dosimétrica presentes en las normas nacionales e internacionales. Lograr un ahorro de recursos materiales y tiempo de trabajo en la gestión de la información e impresión de los diferentes reportes emitidos por el Laboratorio. Permitir que los Responsables de Protección Radiológica (RPR) y los Trabajadores Ocupacionalmente Expuestos a las Radiaciones Ionizantes (TOE) accedan de forma remota a la información dosimétrica. Obtener una aplicación que gestionen mayor cantidad de datos dosimétricos y que devuelva consultas y reportes de mayor complejidad. También es necesario que este elevado volumen de información se almacene de forma segura y durante largos períodos de tiempo. Garantizar la seguridad de los datos y que el acceso a los mismos esté restringido a las funciones de trabajo de los miembros del Laboratorio Estudio de la situación actual (EVS 2) El laboratorio de Dosimetría Externa forma parte de la Dirección de Servicios Especializados del Centro de Protección e Higiene de las Radiaciones (CPHR). En la Figura 8 se puede ver la posición que ocupa este laboratorio dentro de la estructura organizativa del CPHR. Este laboratorio tiene la función de evaluar las dosis por exposición externa que reciben los trabajadores ocupacionalmente expuestos a las radiaciones ionizantes en el país. Este servicio especializado recibe el nombre de Servicio de Dosimetría Externa y se basa en el empleo de 56

57 dosímetros personales termoluminiscentes para la evaluación de la dosis personal recibida durante el trabajo con fuentes de radiaciones ionizantes. Para comprender mejor el funcionamiento del Servicio de Dosimetría Externa se utilizaron diagramas IDEFO. Como se pueden ver en el Anexo 1, esta herramienta nos permite representar y entender los diferentes procesos del Servicio, determinar el impacto de los diferentes sucesos y definir cómo los procesos interactúan unos con otros mediante flujos de información. De esta forma se reduce la complejidad del sistema que se encuentra bajo estudio y se facilita la comprensión del negocio que se quiere automatizar. Dirección General CPHR Dirección Serv. Especializados Dirección I+D+I Dirección Comercial Dirección Capital Humano Dirección Economía Dirección Servicios Internos Laboratorio Dosimetría Externa RNVRA Oficina Comercial Recursos Humanos Cocina Comedor LSCD Servicios Medioambientales Informática y Redes Transporte GESR Docencia Brigada de Mantenimiento LVRA Laboratorio Dosimetría Interna Servicios Productivos Laboratorio Radiobiología Figura 8. Organigrama del Centro de Protección e Higiene de las Radiaciones. 57

58 2.1.3 Definición de requisitos del sistema (EVS 3) Para la definición de los requisitos generales del sistema de gestión de la información cliente servidor y de la aplicación web que se muestran en la Tabla 2 se realizaron sesiones de trabajo entre los analistas y los especialistas del Laboratorio de Dosimetría Externa. Estos requisitos están agrupados por los siguientes aspectos: Políticas técnicas (PT) Política de Seguridad (PS) Directrices de Planificación (DP) Directrices de Gestión de Cambios (DGCA) Directrices de Gestión de Calidad (DGCL) Tabla 2. Listado inicial de requisitos del sistema. ID Requisito Descripción PT1 Metodología de desarrollo. Se aplicaran los lineamientos metodológicos definidos en Métrica 3 para todo el desarrollo del ciclo de vida del sistema. PT2 Aplicación de normas técnicas. Cumplir con las regulaciones del Organismo Internacional de Energía Atómica (OIEA) y los estándares internacionales para la gestión de la información dosimétrica. PT3 Lenguaje de programación. Se utilizará un lenguaje de programación que garantice el desarrollo del sistema en el menor tiempo posible y que sea del conocimiento del equipo de desarrollo. Debe soportar las técnicas más actualizadas en el desarrollo de sistemas informáticos. PT4 Arquitectura del sistema. Sistema distribuido, con posibilidad de acceso remoto a través de la red nacional de datos. PT5 Costo, disponibilidad y Distribución. Sistema económico, hacer uso de aplicaciones de código fuente abierta. Aplicación cliente ligera y que garantice una alta disponibilidad y facilidad de distribución de las versiones. PT6 Facilidad de uso. El sistema debe ser fácil de utilizar por usuarios de diferentes niveles técnicos y con una interfaz amigable. PS1 Control de acceso El acceso a los datos debe ser restringido a los usuarios del sistema. Se tendrá acceso a los datos teniendo en cuenta las responsabilidades específicas de cada usuario. 58

59 ID Requisito Descripción PS2 Cifrado de los datos. Valorar la posibilidad de que el intercambio de información entre los usuarios remotos que utilizan la red nacional de datos y el Laboratorio debe ser cifrado. PS3 Integridad y disponibilidad de los datos. Se debe garantizar la integridad de los datos almacenados. Los datos deben estar disponibles las 24 horas del día para los usuarios remotos. Se realizarán copias de seguridad automatizada de los datos. DP1 Plan de trabajo. Cada uno de los miembros del equipo de desarrollo contará con un detallado plan de trabajo donde se describen sus tareas y los plazos de ejecución. PP2 Gestión de proyecto. Se aplicarán las técnicas definidas en la Interfaz de Gestión de Proyecto de Métrica 3. DGCA1 Gestión de configuración de software. A partir de la primer entrega del código para su implementación se numerarán las versiones desde 1.0 en adelante, según cambios solicitados por los clientes. DGCA2 Control de versiones. Se implementará un sistema de control de versiones para facilitar el trabajo del equipo de desarrollo y controlar los cambios realizados al sistema. DGCA3 Gestión de configuración de productos. Cada producto generado en el marco del presente trabajo debe ser registrado con el control de versiones correspondiente para el seguimiento de las mismas. DGCL1 Documentación de usuario. Todas las soluciones desarrolladas deben contar con su correspondiente manual de usuario. DGCL2 Pruebas a los sistemas. Todas las soluciones desarrolladas deben someterse a un conjunto de pruebas que garanticen su correcto funcionamiento. Estas pruebas se realizarán por personal que no haya participado en la programación del sistema Estudio de alternativas de solución (EVS 4) Tomando como base las necesidades planteadas por los especialistas del Laboratorio de Dosimetría Externa, en la Figura 9 se muestra el Modelo de Casos de Uso del sistema de gestión de la información cliente servidor propuesto. 59

60 Especialista Jefe de Laboratorio Utilizar Sistema de Gestión de Datos de Dosimetría Externa Operador RADOS <<extender>> <<extender>> Técnico del Laboratorio Comercial Administrador BD Figura 9. Modelo de Caso de Uso del sistema de gestión cliente servidor. En el Análisis del sistema se realizará el modelado detallado de casos de uso de negocio. En cuanto a los usuarios que hacen uso del sistema de gestión de la información cliente servidor, en la Tabla 3 se describen cada uno de ellos. Tabla 3. Usuarios del sistema de gestión cliente servidor. ID Usuario Descripción 1 Comercial Personal de la Oficina Comercial, tiene la función de recibir las nuevas solicitudes de servicios dosimétricos y las solicitudes de modificación de datos. 2 Jefe de Laboratorio Tiene la función de aprobar las nuevas solicitudes de servicios dosimétricos en función de las capacidades del Laboratorio. 3 Técnico de Laboratorio. 4 Especialista del Laboratorio. Tiene la función de preparar los dosímetros que serán utilizados periódicamente por los TOE de las diferentes entidades usuarias. También recepciona y prepara para su procesamiento a los dosímetros utilizados por los TOE. Tiene la función de evaluar los dosímetros utilizados por los TOE, preparar los reportes de dosis y enviarlos a las diferentes Entidades Usuarias. 60

61 ID Usuario Descripción 5 RADOS Sistema automatizado acoplado al lector TLD, envía información del procesamiento de los dosímetros. 6 Administrador BD Es el encargado de administrar la base de datos, dar alta a los usuarios del sistema, revisar los registros de utilización y actualizar los clasificadores. Para la Aplicación Web el Modelo de caso de Uso se puede apreciar en la Figura 10. Utilizar Aplicación Web Responsable de Protección Radiológica Jefe de Grupo Administrador BD Figura 10. Modelo de Caso de Uso de la aplicación web. En cuanto a los usuarios que hacen uso Aplicación Web, en la Tabla 4 se describen cada uno de ellos. Tabla 4. Usuarios de la aplicación web ID Usuario Descripción 1 Responsable de Tiene acceso a los datos dosimétricos de los TOE que tiene Protección Radiológica bajo su responsabilidad. 2 Jefe de Grupo Tiene acceso a los datos dosimétricos del grupo de entidades que tiene bajo su responsabilidad. 3 Administrador Tiene la función de asignar los permisos de acceso de los diferentes usuarios del sistema. En la Figura 11 se presenta el diagrama de despliegue, este modelo representa la solución a desarrollar en términos funcionales y de arquitectura de aplicación. Para la gestión de los 61

62 datos por parte de los miembros del Laboratorio de Dosimetría Externa se propone la arquitectura de aplicaciones cliente servidor. Para el acceso a los datos de los clientes remoto se propone el desarrollo de una aplicación web, la cual puede ser accedida a través de un navegador. Figura 11. Diagrama de despliegue del sistema Valoración de las alternativas (EVS 5) La alternativa propuesta como solución tiene los riesgos inherentes a todo proyecto nuevo, estos serán minimizados y controlados gracias a una planificación adecuada y a la aplicación de técnicas de gestión de proyectos. Como aspecto positivo está el interés de la dirección de CPHR de financiar la ejecución del proyecto debido al gran impacto que tendrá su aplicación para el desarrollo de la organización. También se cuenta con el personal técnico apropiado para la ejecución de las diferentes tareas planificadas. Como parte de esta tarea se realizó la gestión de proyectos qué tiene como finalidad principal la planificación, el seguimiento, la identificación y control de las actividades y de los recursos humanos y materiales que intervienen en el desarrollo de un Sistema de Información. En el Anexo 2 se pueden ver los resultados. 62

63 2.2 Análisis del sistema de información (ASI) El objetivo principal del proceso es el de obtener las especificaciones detalladas del sistema de gestión cliente servidor y de la aplicación web que se corresponda con los requerimientos de los usuarios y sirve de punto de partida a la etapa de diseño del sistema. En esta etapa, se realizan las siguientes actividades: Definición del Sistema (ASI 1) Establecimiento de Requisitos (ASI 2) Análisis de Casos de Uso (ASI 4) Análisis de Clases (ASI 5) Definición de Interfaz de Usuario (ASI 8) Análisis de Consistencia (ASI 9) Aprobación del Análisis del Sistema de Información (ASI 11) Definición del Sistema (ASI 1) El objetivo del sistema objeto de análisis es el de automatizar los diferentes procesos que forman parte del servicio de dosimetría Externa del CPHR. Se requiere un sistema que almacene la información de las entidades usuarias del servicio de dosimetría externa, con la particularidad de que en una entidad pueden existir varios departamentos a los cuales se les distribuyen los dosímetros de forma independiente y que cuentan con su propio oficial de protección radiológica. También se almacenará la información de los trabajadores ocupacionalmente expuesto a las radiaciones ionizantes los cuales pueden trabajar en varias entidades de forma simultánea y en cada uno de ellas contará con un servicio de dosimetría diferente. No obstante, el sistema debe ser capaz de identificar y agrupar la dosis obtenida por el trabajador independientemente de la entidad en donde trabaje. Los dosímetros se generarán de forma automática y se imprimirá una etiqueta con un código de barra que identifique al propietario del dosímetro y le fecha de utilización del mismo. La recepción de los dosímetros utilizados por los trabajadores al finalizar el período de control también se realizará de forma automatizada empleando este mismo código de barra, de esta forma se evitarán errores a la hora de la captación de los datos. El sistema debe ser capaz de 63

64 trabajar tanto desde una red local de datos como de la red nacional de datos para el intercambio de información con usuarios externos al laboratorio. Se utilizarán computadoras dedicadas como servidores de aplicaciones, web y de datos. La aplicación utilizada como servidor de base de datos es el MySQL, la cual presenta una gran estabilidad en su funcionamiento, seguridad y altas prestaciones en la manipulación de los datos, además esta aplicación es de libre uso y funciona sobre los sistemas operativos Windows y Linux. Los usuarios accederán a los datos a través de una aplicación cliente y de un navegador web, la lógica de negocio funcionará desde un servidor de aplicaciones y el acceso a los clientes remotos se facilitará a través de un servidor web Establecimiento de Requisitos (ASI 2) A continuación se mencionan los requisitos específicos del sistema, incluyendo los mencionados en el Catálogo de Requisitos Generales del capítulo de Estudio de Viabilidad del Sistema. 1. Requisitos metodológicos: En todo el ciclo de vida del sistema se deben aplicar los lineamientos metodológicos definidos en Métrica 3, los cuales servirán de base para la definición de los elementos de información que manipulará el sistema de gestión cliente servidor y la aplicación web. 2. Requisitos de costo, disponibilidad y distribución: El sistema debe ser económico, utilizando en donde sea posible aplicación de código fuente abierta. El acceso de los usuarios se realizará mediante una aplicación ligera y un navegador web. El sistema debe estar disponible las 24 horas del día para los usuarios que requieran de su utilización. 3. Requisitos de facilidad de uso: El sistema de gestión de la información cliente servidor y la aplicación web debe ser fácil de utilizar por usuarios con diferentes niveles de preparación. Debe contar con una interfaz amigable y que elimine las posibilidades de cometer errores en el momento de manipular los datos. Las tareas se deben realizar de la 64

65 forma más óptima posible, evitando uso excesivo de formularios y opciones innecesarias que provoquen una sobrecarga del sistema. 4. Requisitos de seguridad: Para acceder al sistema cliente servidor y a la aplicación web es necesario contar con una cuenta de usuario y contraseña. Los usuarios solamente tendrán acceso a aquellas opciones que previamente fueron autorizados a utilizar. La contraseña debe ser personal, segura y almacenada utilizando técnicas de encriptación. Se debe garantizar la integridad y seguridad de los datos almacenados en el servidor. Sólo el personal autorizado debe acceder a los mismos y siempre desde las aplicaciones diseñadas. Sólo el administrador del sistema tendrá acceso a los datos a través de herramientas de gestión. Se debe garantizar la disponibilidad y el acceso de los datos las 24 horas del día. Se guardará un registro de las acciones realizadas por los usuarios en el sistema y se crearán las condiciones para el monitoreo de las mismas. Se realizarán copias de seguridad automatizada de los datos. El servidor de datos utilizado por el laboratorio no será el mismo que utilice la aplicación web, se crearán mecanismos de sincronización de datos entre ellos. 5. Requisitos de gestión de configuración de productos: Cada producto generado debe ser registrado en una aplicación de control de versiones para que los programadores del sistema puedan darle seguimiento a los mismos. A partir de la primera entrega del código para su implementación se numerarán las versiones desde 1.0 en adelante, según cambios solicitados por los clientes. 6. Requisitos de documentación de usuario: Se elaborará un manual de usuario que explique de forma clara y sencilla las diferentes opciones del sistema. También se elaboraron un grupo de procedimientos de trabajo los cuales responderán a los requerimientos del sistema de calidad establecido en el laboratorio. 65

66 7. Requisitos funcionales: Los requisitos funcionales de la aplicación se describirán a continuación mediante el recurso de modelado de Casos de Uso Análisis de Casos de Uso (ASI 4) En sesiones de trabajo se identificaron las principales funciones del sistema y la forma en que interactúan con los diferentes usuarios, para representarlas se utilizó la técnica de presentación mediante casos de usos. Hamilton expresa que los casos de uso son un excelente punto de partida para todas las facetas del desarrollo, diseño, prueba y documentación de los sistemas orientado a objeto. Ellos describen los requerimientos del sistema desde un punto de vista externo [33]. En la Tabla 5 se presenta el listado completo de casos de uso que cubren el alcance funcional de la herramienta. Tabla 5. Listado de Casos de Usos del Sistema Cliente Servidor. ID CU.01 CU.02 CU.03 CU.04 CU.05 CU.06 CU.07 CU.08 CU.09 CU.10 CU.11 CU.12 CU.13 CU.14 CU.15 CU.16 Casos de Usos del Sistema Manejar usuarios del sistema y cambios de contraseña. Manejar clasificadores del sistema. Exportar información al banco dosimétrico. Exportar información al sistema dosis MINFAR Exportar información al sistema GESCOM Registrar entidades usuarias Importar datos de entidades usuarias. Registrar departamentos con servicios dosimétricos. Registrar Trabajadores Ocupacionalmente Expuestos y solicitudes de servicios. Preparar y entregar dosímetros. Enlazar el código del dosímetro con el código de la tarjeta. Recepcionar dosímetros y organizar bandejas para la lectura. Recolectar y enviar información de dosímetros preparados. Recolectar y obtener información de dosímetros recepcionados. Importar valores de dosis de dosímetros evaluados. Recolectar y enviar valores de dosis. 66

67 ID CU.17 CU.18 Casos de Usos del Sistema Recolectar y obtener información estadística. Registrar acciones realizadas con el sistema. En el Anexo 3 se representan los casos de uso y su interacción con los diferentes actores dentro del contexto del sistema cliente servidor. También se puede ver una descripción más detallada de los casos Análisis de Clases (ASI 5) En esta etapa se describe las responsabilidades, atributos y relaciones de cooperación entre las clases definidas en los casos de uso identificados anteriormente. Para representar esta información, se usan diagramas de interacción que contienen instancias de los actores participantes, objetos, y la secuencia de mensajes intercambiados entre ellos. Estos diagramas pueden ser tanto de secuencia como de colaboración. También se describen las clases de entidad que se utilizan para modelar información que posee una larga vida y que son a menudo persistentes, así como las clases de interfaz que se utilizan para modelar la interacción entre el sistema y sus actores. Se elaboraron los diagramas de secuencia según la notación UML para representar la interacción entre los actores y los eventos que generan [34]. Un diagrama de secuencia muestra los eventos que genera cada actor externo, su secuencia temporal y los mensajes generados entre los sistemas. En el Anexo 4 se presentan los diagramas de secuencia para los casos de uso del sistema cliente servidor y de la aplicación web. En la Figura 12 se representa el diagrama de clases persistentes, el cual representa aquellas clases que modelan la información permanente del sistema. Según describe González las clases persistentes por lo general tienen como origen las clases clasificadas como entidad porque ellas modelan la información y el comportamiento asociado de algún fenómeno o concepto, como una persona, un objeto del mundo real o un suceso [35]. Como puede observarse al sistema cliente servidor y a la aplicación web tendrán acceso un grupo de usuarios con un determinado nivel de responsabilidad para realizar acciones. En una 67

68 misma institución pueden existir varios departamentos a los cuales se les suministra el servicio de la dosimetría de forma independiente a sus trabajadores. Estos trabajadores pueden realizar el trabajo en diferentes instituciones o departamentos, por lo que es necesario que se realice una solicitud de servicio para cada uno de ellos teniendo en cuenta esta característica. <<Entidad>> Contrato -NoContrato -FechaFirma -Duracion -Estado +Adicionar() +Modificar() +Eliminar() +Listar() <<Entidad>> Usuario -ID -Nombre -Login -Pasword -Nivel +Adicionar() +Modificar() +Eliminar() +Listar() 1..* 1 <<Entidad>> Laboratorio -Nombre -Direccion -Telefono -Responsable -Fax - -Web +Modificar() +Eliminar() +Listar() -pertenecen -compuesto por 1..* -es firmado -legaliza 1 1 -firma <<Entidad>> Institucion -CodInst -NombreInst -Director -Ministerio -Provincia -Municipioi -Direccion -telefono - +Adicionar() +Modificar() +Eliminar() +Listar() <<Entidad>> Control -CodDomimetro -Inicio -Fin -FechaEntrega -FechaRecep -Enntregado -Recibido -Dosis -Observaciones -Operador -FechaLectura -Lector -FechaImport +Adicionar() +Modificar() +Eliminar() +Listar() -tiene -pertenece 1 * -recibe -pertenece 1 * -es legalizado * <<Entidad>> Departamento -CodDpto -NombreDpto -Responsable -TelefonoDpto -FaxDpto -Esfera +Adicionar() +Modificar() +Eliminar() +Listar() <<Entidad>> Solicitud -Servicio -FechaAlta -FechaBaja -Estado +Adicionar() +Modificar() +Eliminar() +Listar() 1 1 <<Entidad>> Servicio -CodServicio -NombreServ -Responsable -Estado -Formato -Magnitud -Incertidumbre -LimiteD -LimiteInv -LimiteAnu +Adicionar() +Modificar() +Eliminar() +Listar() -pertenece -recibe -tienen 1 -pertenecen 1..* <<Entidad>> Trabajador -CodTOE -Nombre -Apellidos -CIdentidad -Sexo -Cargo -FechaNac -NivelEscolar +Adicionar() +Modificar() +Eliminar() +Listar() 1 * -realiza <<Entidad>> Practicas -CodPractica -NombrePractica +Adicionar() +Modificar() +Eliminar() +Listar() 1 1 <<Entidad>> Esfera -CodEsfera -NombreEsfera +Adicionar() +Modificar() +Eliminar() +Listar() -es realizada -pertenece -pertenece Figura 12. Diagrama de clases persistentes. Cada solicitud de servicio tiene asociado varios controles dosimétricos, donde se le da seguimiento al servicio dosimétrico recibido en determinado período por un trabajador. En Anexo 5 se muestran los diagramas de clases de diseño, indicando de forma detallada las asociaciones y agregaciones entre ellas. 68

69 También se elaboraron los diagramas de actividad, utilizados para modelar una secuencia de acciones y condiciones tomadas dentro de un proceso. La especificación del Lenguaje de Modelado Unificado UML define un diagrama de actividad como una variación de una máquina estados, lo cual los estados representan el rendimiento de las acciones o subactividades y las transiciones se provocan por la ejecución de estos. En el Anexo 6 se pueden ver los diagramas elaborados Definición de Interfaz de Usuario (ASI 8) El objetivo de esta actividad es el de conseguir el modelo que satisfaga los requerimientos establecidos en cuanto a la interfaz entre el sistema y el usuario. Según plantea Gunderloy, un software es como una conversación entre el desarrollador y el usuario. El usuario inicia la conversación cuando ejecuta la aplicación. El desarrollador responde con una estrategia inicial donde se listan todos los aspectos que intervienen en la conversación. El usuario selecciona uno y el desarrollador, a través de su sistema, responde. El intercambio continua a través de la vida de la aplicación [36]. Es por esto que el diseño de interfaz de usuario juega un papel tan importante en el ciclo de vida de desarrollo de una aplicación. Podemos decir que es la parte visible del sistema con la cual el usuario interactúa. Es el mecanismo de solicitar y recibir información, navegar, localizar contenidos, ingresar y obtener información asociada a la operación requerida; y en general, todos aquellos elementos que componen la relación del usuario con el sistema. Los criterios ergonómicos que se toman en cuenta en el diseño de las interfaces del sistema fueron los siguientes: Funcionalidad: Capacidad de realizar tareas y transacciones de la forma más eficiente. Cuando sea posible, la interfaz de usuario debe dejar la iniciativa al usuario y proveerle la mayor libertad y control sobre la aplicación. Tiempo de asimilación: Grado de rapidez en la que el usuario alcanza a utilizar de forma experta el sistema. 69

70 Estética: Diseño gráfico de pantallas del sistema y distribución de imágenes, textos y controles. La apariencia de la interfaz de usuario deberá ser consistente y uniforme. La interfaz debe ser tan simple como sea posible Análisis de Consistencia (ASI 9) El objetivo de esta actividad es garantizar la calidad de los distintos modelos generados en el proceso de Análisis del Sistema de Información y asegurar que todas las partes involucradas en el desarrollo tengan el mismo concepto del sistema. Se verificó la calidad de los distintos modelos de forma separada con el propósito de garantizar su adecuación al problema a resolver y su seguimiento respecto de las técnicas de análisis seleccionadas. Como resultado de la verificación, se efectuaron correcciones a los diferentes modelos Aprobación del Análisis del Sistema de Información (ASI 11) En reunión efectuada con la participación del equipo de desarrollo y los usuarios se dio por aprobada la fase de Análisis del Sistema de Información Diseño del sistema de información (DSI) El proceso siguiente tiene el objetivo de definir la arquitectura del sistema y el entorno tecnológico que le va a dar soporte al sistema de información diseñado. Tomando como punto de partida la información obtenida en la etapa se generaron todas las especificaciones de construcción relativas al propio sistema, así como la descripción técnica del plan de pruebas, la definición de los requisitos de implantación y el diseño de los procedimientos de migración y carga inicial cuando proceda. Para el desarrollo del diseño del sistema cliente servidor y de la aplicación web se realizan las siguientes actividades: Definición de la Arquitectura del Sistema (DSI 1) Diseño físico de datos (DSI 6) Verificación y aceptación de la arquitectura (DSI 7) Generación de especificación de construcción (DSI 8) Especificación técnica de Plan de Pruebas (DSI 10) Establecimiento de requisitos de implantación (DSI 11) 70

71 2.3.1 Definición de la Arquitectura del Sistema (DSI 1) En la Figura 13 se muestra una representación esquemática de la aplicación en función de la estructura lógica de componentes de software y la infraestructura tecnológica que le ofrece soporte. La arquitectura de aplicación de gestión de la información consta de dos capas, la primera donde se agrupan los elementos de Presentación y de Lógica de Negocios y la segunda de Datos. Por su parte la aplicación web consta la capa de presentación, la capa de lógica de negocio y la de datos. Figura 13. Arquitectura del Sistema. En la Figura 14 se puede ver cómo el diseño de la aplicación separa por un lado, las clases que dan soporte al acceso de datos persistentes en la base de datos; y por otra parte, la clase que da soporte al comportamiento de la navegación y las reglas de lógica de negocios. El Subsistema Pantalla agrupa al conjunto de formularios que forman parte de la aplicación que es utilizada por los clientes, estas realizan llamadas al Subsistema de Lógica y reciben respuesta del mismo. Por su parte, el Subsistema Lógica se encuentra encapsulado en un único componente, responde a las necesidades de generación dinámica de contenido y el 71

72 encapsulamiento de las reglas de negocio en un contenedor diferente al de la capa de presentación. Esta clase se ocupa de recibir las solicitudes desde el navegador, interpretando la información recibida y generando nuevas pantallas o impactando en la base de datos a través del subsistema de Datos. Una vez que la clase cumple su cometido, envía al cliente el resultado esperado. Subsistema Pantalla Subsistema Lógica Subsistema Acceso a Datos Subsistema BBDD Figura 14. Subsistema de diseño El Subsistema de Acceso a Datos lo componen un conjunto de clases que ofrecen soporte a la conexión con la base de datos y el acceso a las tablas del esquema; organizados en un paquete dentro de la aplicación. El componente DataSource corresponde a la instancia de datos a la que se conecta la aplicación. Finalmente, el Subsistema BBDD representa al repositorio físico de datos resuelto en un esquema de base de datos correspondiente al motor MySQL. Es una base de datos relacional que contiene una tabla por cada una de las entidades planteadas en el Modelo de Dominio. El equipamiento necesario para la operación del sistema es estándar y tanto los servidores como el equipamiento necesario para los clientes están disponibles en la institución y no se requiere ejecutar ninguna inversión monetaria para su disponibilidad. Se tienen prevista las siguientes configuraciones mínimas: Para los servidores: Procesador Pentium IV 512 Mb de RAM. 160 GB en capacidad de disco. Tarjeta de Red. Para los clientes: Procesador Pentium II o superior. 256 Mb de RAM, 20 GB en capacidad de disco. Tarjeta de Red. 72

73 2.3.2 Diseño físico de datos (DSI 6) Para la definición física de las tablas que componen el modelo de datos de la aplicación se analizaron las características principales del motor de base de datos MySQL. En el Anexo 7 se representa el diseño físico de los datos obtenido en esta etapa de trabajo y se describen cada una de las tablas obtenidas Verificación y aceptación de la arquitectura (DSI 7) El objetivo de este proceso es el de corroborar la corrección del modelo de diseño formulado para avanzar en la especificación necesaria para la construcción del sistema cliente servidor y de la aplicación web. Se realizaron las siguientes tareas: Verificación de la calidad técnica de cada modelo o especificación Aseguramiento de la coherencia entre los distintos modelos Aceptación del diseño de la arquitectura Generación de especificación de construcción (DSI 8) En este proceso se describen las diferentes especificaciones para la construcción del sistema cliente servidor y de la aplicación web a partir del diseño realizado. También se generan las especificaciones necesarias para la creación de las estructuras de datos en los gestores de bases de datos o sistemas de ficheros. En Tabla 6 se describen las especificaciones del entorno tecnológico para el desarrollo de las soluciones informáticas: Tabla 6. Especificaciones del entorno tecnológico de desarrollo. Concepto Entorno tecnológico: Hardware, software y comunicaciones Definición Los equipos para el desarrollo de la aplicación serán tres computadoras con procesadores Core 2 Duo, disco duro 160 Gb, memoria RAM 1 G. Red de datos para el intercambio de información entre los desarrolladores y mantenimiento de versiones. 73

74 Concepto Definición Una de las computadoras tiene instalado el servidor de aplicaciones y el de bases de datos. Utilizar una aplicación para la gestión de las versiones del código fuente. Herramientas de construcción, generadores de código, compiladores, etc. CodeGear RAD Studio 2009 Framework Laravel y editor de texto SublimeText 2. Apache 2, PHP y Myseql Restricciones técnicas del entorno. No se requieren Planificación de capacidades previstas. Servidor de datos y capacidades de conectividad. Requisitos de operación y seguridad del entorno de construcción. Mantener copias de seguridad del código fuente. El entorno de desarrollo seleccionado para ser utilizado en la programación del sistema multicapa es Delphi Studio 2009 Architect, esta herramienta es utilizada por una amplia comunidad de desarrolladores. Según plantea Marco Cantu, Delphi tiene una extensa y gloriosa historia de éxitos en el desarrollo de aplicaciones clientes servidor. Con millones de aplicaciones escritas en el lenguaje Object Pascal, Delphi generó un ecosistema repleto de componentes, herramientas, revistas, libros y recursos en línea [37] Especificación técnica de Plan de Pruebas (DSI 10) En esta actividad se define el entorno necesario para realizar las pruebas del sistema las cuales se clasificaran en pruebas unitarias, de integración, de implantación y aceptación. El personal involucrado en esta etapa de trabajo es diferente al empleado en la programación del sistema. Estas pruebas se realizan en un equipamiento con características similares a los del usuario final del sistema. En Tabla 7 se puede observar las características del entorno tecnológico de pruebas. 74

75 Tabla 7. Entorno tecnológico de pruebas Nodo Hardware Software Estación de prueba PC Pentium 4, 500 Mb memoria RAM, HD 80 GB, Ethernet 100 Mbps Windows XP SP3 Internet Explorer 7 Mozilla Firefox 3.6 pgadmin3 Servidor web Core 2 Duo, disco duro 160 Gb, memoria RAM 1 G, Apache versión 2 HTTP/1.1 PHP 5 Servidor de datos Ethernet 100 Mbps MySQL Las pruebas unitarias tienen como objetivo verificar la funcionalidad y estructura de cada componente individualmente una vez que ha sido codificado. Estas constituyen las pruebas iniciales del funcionamiento del sistema y las demás pruebas realizadas deben apoyarse en estas. Las pruebas unitarias se clasifican en: Caja blanca: Se verifica la estructura interna del componente con independencia de la funcionalidad establecida para el mismo. Caja negra: Se comprueba el correcto funcionamiento de los componentes del sistema de información, analizando las entradas y salidas y verificando que los resultados sean los esperados. Las pruebas de integración tienen el objetivo de verificar el correcto ensamblaje entre los distintos componentes una vez realizada las pruebas unitarias. Este tipo de prueba examinan las interfaces entre grupos de componentes o subsistemas para asegurar que son llamados cuando se requieren y que los datos o mensajes que se transmiten son los correctos. Las pruebas de integración permiten probar el sistema en su conjunto para verificar que las especificaciones funcionales y técnicas se cumplen. Las pruebas de implantación tienen el objetivo de comprobar el funcionamiento correcto del sistema integrado de hardware y software en el entorno de operación. Debe comprobarse que el sistema responde satisfactoriamente a los requisitos de rendimiento, seguridad, operación y coexistencia con el resto de los sistemas de la instalación para conseguir la aceptación del usuario de operación. 75

76 Las pruebas de aceptación son definidas por el usuario del sistema y preparadas por el equipo de desarrollo, aunque la ejecución y aprobación final corresponden al usuario Establecimiento de requisitos de implantación (DSI 11) En reunión efectuada con la participación del equipo de desarrollo y los usuarios se dio por aprobada la fase de Diseño del Sistema de Información. 2.4 Construcción del sistema de información (CSI): El siguiente proceso tiene el objetivo de generar el código fuente del software, ejecutar las pruebas de aceptación y la elaboración de manuales operativos que aseguren el éxito del sistema. Para la construcción de la herramienta, según la metodología, se realizan las siguientes actividades: Preparación del entorno de generación y construcción (CSI 1) Generación del código de los componentes y procedimientos (CSI 2) Ejecución de las Pruebas Unitarias (CSI 3) Ejecución de las Pruebas de Integración (CSI 4) Ejecución de las Pruebas del Sistema (CSI 5) Elaboración de los Manuales de Usuario (CSI 6) Definición de la formación de Usuarios Finales (CSI 7) Construcción de componentes y procedimientos de Migración y Carga Inicial (CSI 8) Aprobación del Sistema de Información (CSI 1) Preparación del entorno de generación y construcción (CSI 1) Para la programación del sistema cliente servidor y a la aplicación web se instalaron y configuraron las herramientas de desarrollo siguiendo las especificaciones de construcción del diseño. Se instala y configura el entorno de construcción formado por las siguientes herramientas: CodeGear RAD Studio 2009, herramienta de desarrollo rápido de aplicaciones (RAD) basada en el lenguaje de programación Object Pascal. 76

77 Servidor de base de datos MySQL Servidor web Apache 2 PHP 5 Framework PHP Laravel 4 Framework CSS Twitter Bootstrap Editor de Texto Sublime Text 2 Navegadores web Firefox y Chrome Como parte de esta actividad se realizó la implantación de la base de datos física con los datos necesarios para ejecutar las diferentes pruebas de funcionamiento del sistema programado. En el Anexo 8 se muestran vistas de los entornos de generación y construcción de cada una de las aplicaciones Generación del código de los componentes y procedimientos (CSI 2) A partir de los diseños definidos en la etapa de diseño se procede al desarrollo del código fuente del Sistema de Información Cliente Servidor y de la Aplicación Web. En el Anexo 9 se muestran las vistas de los diferentes formularios obtenidos a partir del código fuente generado en el proceso Ejecución de las Pruebas Unitarias (CSI 3) La ejecución de Pruebas Unitarias es una actividad que se realiza en forma continua y paralela al desarrollo del Sistema de Información Cliente Servidor y de la Aplicación Web Ejecución de las Pruebas de Integración (CSI 4) Las pruebas de integración tienen el objetivo de probar el funcionamiento entre los distintos componentes que forman parte del Sistema de Información Cliente Servidor y de la Aplicación Web Ejecución de las Pruebas del Sistema (CSI 5) Las pruebas del Sistema tienen como objetivo verificar el funcionamiento global del sistema y comprobar la cobertura funcional del mismo. 77

78 Del resultado de las pruebas realizadas hasta el momento se desprende que el proceso de construcción de los componentes de las diferentes capas de la aplicación avanza de manera satisfactoria Elaboración de los Manuales de Usuario (CSI 6) Se elaboraran los manuales de usuarios necesarios para garantizar el adecuado uso del sistema cliente servidor y de la aplicación web por parte de los diferentes actores que interactúan con el sistema. En esta actividad se genera la documentación necesaria para que el usuario se capacite en el uso de las herramientas y como fuente de consulta continua. Como parte del sistema de gestión de la calidad implementado en el LDE se crearán los procedimientos necesarios para garantizar el correcto funcionamiento de todas las etapas del servicio Definición de la formación de Usuarios Finales (CSI 7) Para la presente Tesis no se considerará la actividad de referencia, dado que no aplica a los fines de la misma. Las tareas que forman parte de esta actividad son las siguientes: Definición del esquema de Formación Especificación de Recursos y Entornos de Formación Construcción de componentes y procedimientos de Migración y Carga Inicial (CSI 8) A partir de la planificación de la migración de datos y carga inicial, se ejecutan las tareas que se mencionan a continuación: Preparación del entorno de migración y carga inicial de los datos Generación del código de los componentes y procedimientos de migración y carga inicial de los datos Realización y evaluación de pruebas de migración y carga inicial de los datos 2.4.9Aprobación del Sistema de Información (CSI 1) Para la presente Tesis no se considerará la actividad de referencia, dado que no aplica a los fines de la misma. 78

79 2.5 Conclusiones del capítulo En este capítulo se realiza el análisis y diseño del sistema de gestión de la información cliente servidor y de la aplicación web se hará uso de la metodología para la planificación, desarrollo y mantenimiento de sistemas de gestión METRICA 3. Se identificaron los requisitos generales del sistema y su alcance; se elaboraron los diagramas IDEFO para representar y entender los procesos que forman parte del Servicio de Dosimetría Externa. Se obtuvieron las especificaciones detalladas del sistema de gestión cliente servidor y de la aplicación web correspondiéndose con los requerimientos de los usuarios para servir como punto de partida a la etapa de diseño del sistema. Se creó el diseño físico de los datos y se describieron las tablas obtenidas. Se definió el entorno de generación y construcción del sistema de gestión cliente servidor y de la aplicación web y se desarrolló el código fuente de ambas aplicaciones. 79

80 Capítulo 3. Diseño del Data Mart del Laboratorio de Dosimetría Externa Aunque las bases de datos operacionales y los almacenes de datos tienen en común el hecho de estar formadas por tablas con datos, índices, llaves, vistas y consultas, estas tienen diferencias significativas. Las bases de datos operacionales están diseñadas y optimizadas para registrar datos, son sistemas de Procesamiento de Transacciones en Línea (OLTP, On- Line Transaction Processing), donde cada transacción debe ser registrada lo más rápidamente posible. Sin embargo, los almacenes de datos están diseñados y optimizados para facilitar la consulta y el análisis de los datos para el soporte en la toma de decisiones. Son sistemas de Procesamiento Analítico en Línea (OLAP, On-Line Analytical Processing) que contienen datos que no se modifican y que pueden ser consultados y analizados más eficientemente que las bases de datos operacionales. La principal ventaja de los almacenes de datos está dada por la estructura de la información que contienen. Se trata del almacenamiento de información homogénea y fiable, en una estructura basada en la consulta y el tratamiento jerarquizado de la misma, y se encuentran en un entorno diferente al de los sistemas operacionales. Una alternativa viable para pequeñas y medianas organizaciones, donde la cantidad de datos almacenados no es muy elevado, está en la implementación de un Data Mart. Estos son almacenes de datos pequeños que están centrados en un tema y responden a los intereses de determinada áreas de negocio dentro de una organización. En nuestro caso se trata de la información histórica del servicio de dosimetría externa, la cual es gestionada por el LDE del CPHR. Los Data Mart se caracterizan por disponer de la estructura óptima de datos para analizar la información al detalle desde todas las perspectivas que afecten a los procesos de dichas áreas de negocio. Los datos almacenados en ellos pueden ser agrupados, explorados y distribuidos para que un grupo de usuarios realice la explotación de los mismos y los ayude en la toma de decisiones. Son sistemas orientados a las consultas, donde la frecuencia de cargas de datos es 80

81 baja y conocida. A partir de ellos se puede hacer uso de herramientas de Procesamiento Analítico en Línea (OLAP). La metodología utilizada para la construcción e implementación del Data Mart se nombra HEFESTO, la cual puede adaptarse a cualquier ciclo de vida de desarrollo de un sistema. Tiene como objetivo entregar una primera implementación del Data Mart que satisfaga parte de las necesidades y expectativas de los usuarios. Además, se evitan fases de desarrollo muy largas, propias de otras metodologías que den al traste con proyectos de este tipo. La metodología se caracteriza por la facilidad en que se distinguen los objetivos y resultados esperados en cada fase. Está basada en los requerimientos del usuario y es capaz de adaptarse rápidamente y con facilidad a cualquier cambio en el negocio. Por otra parte, al estar el usuario final involucrado en cada etapa del desarrollo, reduce la resistencia al cambio. Se distingue por utilizar modelos conceptuales lógicos sencillos de interpretar y analizar. Además, es independiente del tipo de ciclo de vida de desarrollo de un sistema, de las herramientas utilizadas para su implementación y de las estructuras físicas que contenga el almacén de datos. Puede aplicarse tanto para el desarrollo de un almacén de datos como para un Data Mart. La metodología está orientada a la construcción de almacenes de datos Dimensional (OLAP) y está formada por las siguientes fases: para Análisis Análisis de requerimientos. Análisis de los sistemas OLTP. Modelo lógico del almacén de datos. Procesos ETL 3.1 Análisis de requerimientos. El modelo dimensional de un proceso de negocios está formado por dos componentes, las mediciones y su contexto. Conocidos como hechos y dimensiones, estos componentes son 81

82 organizados en una base de datos diseñada para facilitar una amplia variedad de análisis de sus datos [38]. Siguiendo los pasos de la metodología HEFESTO se identificaron los requerimientos del usuario a través de una serie de preguntas que explican los objetivos de la organización o área de negocio donde se implementará el almacén de datos. Las preguntas incluyen variables de análisis que se consideren relevantes ya que permitirán el estudio de la información desde diferentes perspectivas. Posteriormente se analizaron estas preguntas con el objetivo de identificar los indicadores y perspectivas que se tomarán en cuenta para la construcción del almacén de datos. Finalmente se confeccionó un modelo conceptual donde se podrá visualizar los resultados obtenidos en este paso de la metodología Identificar preguntas En esta etapa de obtuvieron e identificaron las necesidades de información requerida por los especialistas del LDE para obtener una herramienta que de forma eficiente contribuya a la toma de decisiones. Se formularon preguntas complejas sobre el negocio donde se incluyeron variables de análisis que se consideraron relevantes para poder estudiar la información desde diferentes dimensiones. Las preguntas de negocio obtenidas fueron las siguientes: 1. Cuál es la dosis media, mínima, máxima y colectiva por servicio y práctica ocupacional para cada institución, ubicación geográfica u organismo central en un período de tiempo determinado? 2. Cuál es la dosis media, mínima, máxima y colectiva por servicio y calificación técnica para cada institución, ubicación geográfica u organismo central en un período de tiempo determinado? 3. Cuántos trabajadores han sobrepasado los límites de dosis por servicio y práctica ocupacional para cada institución, ubicación geográfica u organismo central en un período de tiempo determinado? 82

83 4. Cuántos trabajadores han sobrepasado los límites de dosis por servicio y calificación técnica para cada institución, ubicación geográfica u organismo central en un período de tiempo determinado? 5. Cuál es la cantidad de hombres y mujeres que recibieron controles dosimétricos por servicio y práctica ocupacional para cada institución, ubicación geográfica u organismo central en un período de tiempo determinado? 6. Cuál es la cantidad de hombres y mujeres que recibieron controles dosimétricos por servicio y calificación técnica para cada institución, ubicación geográfica u organismo central en un período de tiempo determinado? 7. Cuántos dosímetros fueron entregados, recibidos, no recibidos, no utilizados o dañados por servicio para cada institución, ubicación geográfica u organismo central en un período de tiempo determinado? 8. Cuál es el tiempo promedio de demora en la recepción y procesamiento de dosímetros por servicios para cada institución, ubicación geográfica u organismo central en un período de tiempo determinado? 9. Cuál es la cantidad de dosímetros que han sido procesados por los lectores por servicios en un período de tiempo determinado? Identificar hechos y dimensiones En esta etapa se procedió a la descomposición de las preguntas de negocio para descubrir los hechos que se utilizarán y las dimensiones de análisis. Según Bernabeu, para ello se debe tener en cuenta que los hechos, para que sean realmente efectivos son en general, valores numéricos y representan lo que se desea analizar concretamente, por ejemplo: saldos, promedios, cantidades, sumatorias, fórmulas, etc. [39] Los hechos obtenidos fueron: Dosis media. Dosis máxima. Dosis mínima. Dosis colectiva. Cantidad de trabajadores que sobrepasan los límites de dosis. 83

84 Cantidad de hombres y mujeres que reciben controles dosimétricos. Cantidad de dosímetros entregados. Cantidad de dosímetros recibidos. Cantidad de dosímetros no recibidos. Cantidad de dosímetros no utilizados. Cantidad de dosímetros dañados. Tiempo promedio de demora en la recepción de los dosímetros Tiempo promedio de demora en el procesamiento de los dosímetros. Cantidad de dosímetros procesados. Las dimensiones se utilizan para examinar los hechos con el objetivo de darle respuestas a las preguntas planteadas anteriormente, en nuestro caso se identificaron las siguientes dimensiones: Servicio. Práctica. Institución. Tiempo Trabajador Dosímetro Modelo conceptual A partir de los hechos y dimensiones obtenidas en el paso anterior se procedió a construir el modelo conceptual. Este modelo permite observar cuál es el alcance del proyecto para posteriormente utilizarlo como base del trabajo. Como se puede observar el Anexo 10, a la izquierda se colocan las dimensiones obtenidas las cuales van unidas a un óvalo que representa las relaciones entre ellas. De esta relación se desprenden los hechos que se encuentran colocados a la derecha. Este modelo permite identificar cuáles serán los resultados que se obtendrán, las variables que se utilizarán para analizarlos y la relación que existe entre ellos. 84

85 3.2 Análisis de los sistemas OLTP. En esta etapa se procedió a examinar los sistemas OLTP disponibles los cuales contienen la información requerida para el diseño del almacén de datos. Se identificaron sus características para que se puedan determinar las correspondencias entre el modelo conceptual confeccionado en la etapa anterior y las fuentes de datos. También se determinaron los indicadores y las fórmulas necesarias para calcularlos. Posteriormente se examinaron y seleccionaron los campos que contendrá cada perspectiva, ya que será a través de éstos por los que se manipularán y filtrarán los indicadores. Finalmente se ampliará el modelo conceptual con los campos o atributos seleccionados Conformar hechos En la Tabla 8 se muestra la forma en que se calculan los hechos a partir de la función que se utilizará para su agregación. Tabla 8. Conformación de los indicadores Indicador Nombre Hecho Función Dosis media. DosisMed Control_Dosimet= > Dosis Avg( ) Dosis máxima DosisMax Control_Dosimet= > Dosis Max( ) Dosis mínima DosisMin Control_Dosimet= > Dosis Min( ) Dosis colectiva DosisColect Control_Dosimet= > Dosis Sum( ) Cantidad de trabajadores que sobrepasan los límites de dosis Cantidad de hombres y mujeres que reciben controles dosimétricos CantTOE_LimD Control_Dosimet= > Dosis Count( ) CantTOE_Sex Control_Dosimet= > IdTOE Count( ) Cantidad de dosímetros entregados CantDosEnt Control_Dosimet= > entregado=1 Count( ) 85

86 Indicador Nombre Hecho Función Cantidad de dosímetros recibidos CantDosRec Control_Dosimet= > Count( ) recibidos=1 Cantidad de dosímetros no recibidos. Cantidad de dosímetros no utilizados. CantDosNoRec Control_Dosimet= > recibidos=0 CantDosNU Control_Dosimet= > observ=nu Count( ) Count( ) Cantidad de dosímetros dañados. CantDosD Control_Dosimet= > observ=d Count( ) Tiempo promedio de demora en la recepción de los dosímetros. TDemRecep Control_Dosimet= > TiempoRecep Avg( ) Tiempo promedio de demora en el TDemProc Control_Dosimet= > Avg( ) procesamiento de los dosímetros TiempoProcesado Cantidad de dosímetros procesados CantDosProc Control_Dosimet= >Lectura Count( ) Establecimiento de correspondencias En este caso se examina el OLTP utilizado por el LDE para la gestión del servicio con el objetivo de identificar las correspondencias entre el modelo conceptual obtenido anteriormente y la fuente de datos. Las relaciones identificadas fueron las siguientes: La tabla Servicio se relaciona con la dimensión Servicio. La tabla Práctica se relaciona con la dimensión Práctica. La tabla Entidad se relaciona con la dimensión Institución. El campo FechaFin de la tabla Dosímetro se relaciona con la dimensión Tiempo. La tabla TOE se relaciona con la dimensión Trabajador. La tabla Dosímetro se relaciona con la dimensión Dosímetro. El campo Dosis de la tabla Dosímetro se relaciona con el hecho Dosis media. El campo Dosis de la tabla Dosímetro se relaciona con el hecho Dosis máxima. El campo Dosis de la tabla Dosímetro se relaciona con el hecho Dosis mínima. El campo Dosis de la tabla Dosímetro se relaciona con el hecho Dosis Colectiva. El campo Dosis de la tabla Dosímetro se relaciona con el hecho Cantidad de trabajadores que sobrepasan los límites de dosis. 86

87 El campo Sexo de la tabla TOE se relaciona con el hecho Cantidad de hombres y mujeres que reciben controles dosimétricos. El campo Entregados de la tabla Dosímetro se relaciona con el hecho Cantidad de dosímetros entregados. El campo Recibidos de la tabla Dosímetro se relaciona con el hecho Cantidad de dosímetros recibidos. El campo Recibidos de la tabla Dosímetro se relaciona con el hecho Cantidad de dosímetros no recibidos. El campo Observaciones de la tabla Dosímetro se relaciona con el hecho Cantidad de dosímetros no utilizados. El campo Observaciones de la tabla Dosímetro se relaciona con el hecho Cantidad de dosímetros dañados. El campo FechaRecep de la tabla Dosímetro se relaciona con el hecho Tiempo promedio de demora en la recepción de los dosímetros. El campo FechaLectura de la tabla Dosímetro se relaciona con el hecho Tiempo promedio de demora en el procesamiento de los dosímetros. El campo Lectura de la tabla Dosímetro se relaciona con el hecho Cantidad de dosímetros procesados Nivel de granularidad Uno de los aspectos más importantes en el diseño de un almacén de datos es el tema de la granularidad. Es más, el tema de la granularidad se evidencia en toda la arquitectura que rodea el entorno del almacén de datos. La granularidad se refiere al nivel de detalle o sumarizaciones de los la unidades de datos en un almacén de datos [21]. En esta etapa se seleccionaron los campos que contienen cada dimensión, es a través de estos que se examinarán y filtrarán los hechos. Los resultados obtenidos fueron los siguientes: Dimensión Servicio. o idservicio de la tabla Servicio. o NomServicio de la tabla Servicio. o LimInvest de la tabla Servicio. 87

88 o LimAnualRecomend de la tabla Servicio. o LimInterven de la tabla Servicio. Dimensión Práctica. o idpractica de la tabla Práctica. o NombPrac de la tabla Práctica. o NomEsfera de la tabla Esfera. Dimensión Institución. o identidad de la tabla Entidad. o NombreC de la tabla Entidad. o NombreMunicip de la tabla Municipio. o NombreProv de la tabla Provincia. o NombMinist de la tabla Ministerio. Dimensión Tiempo o FechaFin de la tabla Dosímetro. o Mes o Trimestre o Semestre o Año Dimensión Trabajador o IdTOE de la tabla TOE o Apellidos + Nombres de la tabla TOE o Sexo de la tabla TOE o NomCalif de la tabla Calific Dimensión Dosímetro o IdDosim de la tabla Dosímetro o NomLector de la tabla Lector o Bandeja de la tabla Dosímetro 88

89 o Position de la tabla Dosímetro Modelo conceptual ampliado La ampliación del modelo conceptual tiene el objetivo de graficar los resultados obtenidos en pasos anteriores. Para lograr esto se coloca bajo cada dimensión los campos seleccionados y bajo cada hecho su respectiva fórmula de cálculo. En el Anexo 11 se puede ver el modelo obtenido. 3.3 Modelo lógico del almacén de datos. En esta etapa se confeccionó el modelo lógico de la estructura del Data Mart, teniendo como base el modelo conceptual que ya ha sido creado anteriormente. Se selecciona el esquema que se utilizará para contener la estructura del almacén de datos, que mejor se adapta a los requerimientos y necesidades de usuario. Se diseñaron las tablas de dimensiones que formarán parte del almacén de datos a partir de las dimensiones definidas en el modelo conceptual. También se definieron las tablas que contienen los hechos, a través de los cuales se constituyen los indicadores de estudio. Finalmente se realizarán las uniones correspondientes entre las tablas de dimensiones y las tablas de hechos. El modelo lógico seleccionado fue el de estrella. Este modelo se caracteriza por una tabla central de hechos con los datos necesarios para el análisis que se encuentra rodeada de las tablas de las dimensiones. Las tablas de dimensiones tendrán siempre una clave primaria simple, mientras que en la tabla de hechos, la clave principal estará compuesta por las claves principales de las tablas dimensionales. En el Anexo 12 se puede apreciar el modelo lógico obtenido. 3.4 Integración de datos Como se plantea en la introducción de este trabajo, se establece como límite de la investigación el desarrollo del sistema de gestión de la información y la aplicación web hasta la fase de pruebas y el diseño del Data Mart departamental. No está contemplado en estos 89

90 momentos cargar el Data Mart con los datos reales del sistema OLTP del LDE. No obstante se exponen algunas consideraciones a tener en cuenta para en un futuro realizar este proceso. En esta etapa se debe realizar el análisis, la definición y el desarrollo de los procesos necesarios para la extracción, transformación y carga de los datos desde los sistemas de origen hasta el almacén de datos. La metodología tiene en cuenta que existen varios software que facilitan esta tarea, por lo que se concentra en el diseño de las sentencias SQL que contendrán los datos que serán de interés. Se deber realizar una limpieza de los datos para evitar valores faltantes y anómalos, también se debe tener en cuenta cual es la información que se desea almacenar estableciendo condiciones adicionales y restricciones. Cuando se haya cargado en su totalidad el almacén de datos, se deben establecer las políticas de actualización y la frecuencia de carga de los mismos Carga inicial de datos Con el objetivo de diseñar y probar los cubos de datos que darán respuesta a las necesidades de información identificadas por los especialistas del LDE se realizó una carga inicial con datos ficticios. Estos datos serán utilizados como fines demostrativos de las potencialidades del Data Mart y no como resultado del procesamiento de los datos reales contenidos en el OLTP del LDE. 3.5 Creación de Cubos Multidimensionales Los Cubos Multidimensionales tienen la función de representar los datos planos que se encuentran almacenados en filas y columnas, en una matriz de N dimensiones. Mediante la creación y consulta de los mismos se puede tener acceso a los datos almacenados en el Data Mart para explorarlos, analizar las relaciones existentes entre ellos y obtener resultados. En la Figura 15 se muestra una representación grafica de un Cubo Multidimensional con sus atributos e indicadores. 90

91 Figura 15. Representación gráfica de un Cubo Multidimensional. Entre los objetos que se pueden encontrar en un Cubo Multidimensional están los siguientes: Atributos: Son los campos o criterios de análisis pertenecientes a las tablas de dimensiones, dentro de un Cubo Multidimensional son los ejes del mismo. Indicadores: Los indicadores son sumarizaciones efectuadas sobre algún hecho o expresiones pertenecientes a una tabla de hechos. El valor que estos tomen estará condicionado por los atributos o jerarquías que se utilicen para analizarlos. Jerarquías: Representa una relación lógica entre dos o más atributos pertenecientes a un Cubo Multidimensional. Mediante ellas se pueden analizar los datos desde su nivel más general al más detallado y viceversa, al desplazarse por los diferentes niveles. Las consultas ejecutadas sobre algún Cubo Multidimensional previamente definido son respondidas con gran eficiencia, minimizando al máximo el tiempo que se hubiese incurrido en realizar dicha consulta sobre una base de datos transaccional. Para el diseño de los Cubos Multidimensionales se utilizó la herramienta Mondrian Schema Workbench, la cual forma parte de la suite de inteligencia de negocios Pentaho CE. Mediante esta herramienta es posible construir un esquema que define a una base de datos multidimensional. Este esquema contiene un modelo lógico consistente en cubos con sus 91

92 atributos, indicadores y jerarquias y es un mapa del modelo físico del Data Mart obtenido. El esquema se representa en un fichero XML y contiene los elementos necesarios para construir consultas con el lenguaje MDX. En la Figura 16 se puede ver un ejemplo del diseño de un Cubo Multidimensional. Figura 16. Herramienta Mondrian Schema Workbench Los Cubos Multidimensionales diseñados con el objetivo de explorar y analizar los datos contenidos en el Data Mart fueron los siguientes: Cubo Multidimensional Dosis. Cubo Multidimensional Control Dosimétrico. Cubo Multidimensional Trabajadores. 92

93 El Cubo Multidimensional Dosis posibilita analizar la información relacionada con las dosis recibidas por los TOE. Como indicadores se definen las dosis máxima, mínima, media y colectiva. El Cubo Multidimensional Control Dosimétrico analiza la información relacionada con el desempeño de los servicios dosimétricos realizados por el LDE. Como indicadores se definen la cantidad de dosímetros entregados, recibidos y procesados. Además, el tiempo de recepción y procesamiento de los dosímetros. En el caso del Cubo Multidimensional Trabajadores se analiza la información relacionada con el volumen de trabajadores que reciben los servicios dosimétricos. Como indicadores se define la cantidad de TOE. Los atributos definidos para estos Cubos Multidimensionales son el tiempo, las instituciones, los servicios dosimétricos, prácticas ocupacionales, los trabajadores y los dosímetros utilizados. Se definieron diferentes jerarquías para cada uno de los atributos, por ejemplo el indicador Tiempo se define la jerarquía Año, Semestre, Trimestre y Mes. En la Figura 17 se pueden ver los Cubos Multidimensionales diseñados con la ayuda de la herramienta Mondrian Schema Workbench. Figura 17. Diseño de los Cubos Multidimensionales del Data Mart del LDE. 93

94 Con el objetivo de obtener información del Data Mart diseñado para el LDE se utilizó la herramienta Saiku-Server. Se trata de una herramienta ROLAP (Relational On Line Analytic Processing), se caracterizan por implementar la organización física de los datos sobre tecnología relacional y disponen de facilidades para mejorar el rendimiento de las consultas. Los Cubos Multidimensionales se generan dinámicamente en el momento en que se realizan las diferentes consultas, haciendo que su manejo sea transparente para el usuario final. Para este proceso el usuario selecciona los indicadores, atributos y jerarquías y de forma dinámica se crea y calcula el Cubo Multidimensional que dará respuesta a la consulta ejecutada. En la Figura 18 se muestra el diseño y resultado de una consulta realizada al Data Mart con esta herramienta. Figura 18. Herramienta ROLAP Saiku-Server. 94

95 La visualización de los resultados a través de un navegador web y permite que un usuario sin conocimientos de lenguaje MDX pueda diseñar las consultas de forma visual. Los resultados pueden obtenerse en forma de tablas o mediantes diferentes tipos de gráficos, tal y como se muestra en la Figura 19. Por otra parte en la Figura 20 se muestra la consulta MDX que permite obtener los resultados anteriores. Figura 19. Representación gráfica de los resultados obtenidos Figura 20. Consulta MDX 95

96 Finalmente, a partir de una serie de consultas diseñadas con la herramienta Saiku-Server se les da respuesta a las preguntas obtenidas en la etapa de diseño del Data Mart. En el Anexo 14 se muestran los resultados obtenidos, demostrándose que el diseño del Data Mart y las herramientas implementadas para su consulta son de gran utilidad como apoyo a la toma de decisión ante las diferentes situaciones afrontadas por el LDE. 3.6 Conclusiones del capítulo En este capítulo se realizó una comparación entre los Sistemas de Procesamiento de Transacciones en Línea (OLTP) y los Sistemas de Procesamientos Analítico en Línea (OLAP). Se describen las características de los Almacenes de Datos y de una alternativa viable para pequeñas y medianas organizaciones que es la implementación de un Data Mart. Se utilizó la metodología HEFESTO para la construcción de un Data Mart que satisfaga las necesidades de información del LDE y se cargaron datos para realizar diferentes consultas mediantes los Cubos Multidimensionales diseñados. Se obtuvieron resultados satisfactorios en las consultas realizadas a partir de un conjunto de datos de pruebas cargados en el Data Mart. Tanta para el diseño como para la implantación del Data Mart se utilizaron herramientas libres, lo que abarata considerablemente la implementación de este tipo de tecnología en las organizaciones. 96

97 Conclusiones Se cumplieron satisfactoriamente los objetivos propuestos en esta Tesis de Maestría debido a que se logró diseñar una plataforma informática que amplíe la gestión del Laboratorio de Dosimetría Externa del Centro de Protección e Higiene de las Radiaciones. Esto va a permitir agilizar el intercambio de información de los clientes con el Laboratorio y ayudará a sus especialistas el proceso de toma de decisiones. Con el trabajo realizado se logró el diseño y programación de una aplicación de gestión de la información cliente servidor para gestionar las diferentes etapas de los servicios que brindan a las instituciones del país. Se desarrolló una aplicación web utilizando un moderno Framework PHP con el fin de agilizar el intercambio de información entre el Servicio y los clientes. También fue posible el diseño de un Data Mart Corporativo para el almacenamiento y análisis de los datos como apoyo a la toma de decisiones a partir de la información generada por el LDE. Se identificaron y probaron un grupo de aplicaciones de código libre que contribuirán a disminuir los costos de la implementación de la infraestructura tecnológica propuesta en este trabajo. Los resultados obtenidos en el análisis de los datos de prueba suministrados al Data Mart diseñado fueron satisfactorios y dan respuesta a las preguntas identificadas por los especialistas en la etapa de diseño del mismo. Se sentaron las bases para aplicar técnicas de minerías de datos con el fin de obtener conocimiento del elevado volumen de datos históricos con que cuenta el Servicio de Dosimetría Externa. La implementación de la plataforma diseñada permitirá la evaluación de la tasa de dosis recibida y su posible evolución en el tiempo. Esto constituye un aspecto fundamental de los programas de vigilancia radiológica individual de las prácticas y apoya los objetivos generales de la vigilancia radiológica ocupacional. Todo lo anterior contribuirá al incremento de la 97

98 seguridad radiológica de las diferentes prácticas que utilizan las radiaciones ionizantes en el país y del control dosimétrico de los TOE. Desde el punto de vista económico se contará con una herramienta que puede ser generalizada por otros servicios de dosimetría externa que en un futuro se establezcan en el país y es una solución que puede ser exportada a otros países de la región que cuenten con servicios similares. Es recomendable concluir la carga de datos reales a partir de la información histórica de los servicios dosimétricos y realizar todas las pruebas necesarias para garantizar la seguridad y estabilidad de la aplicación cliente servidor y de la aplicación web. 98

99 Referencias bibliográficas [1] Organismo Internacional de Energía Atómica, «Protección Radiológica Ocupacional. Guia de Seguridad No. RS-G-1.1,» OIEA, Viena, [2] Organismo Internacional de Energía Atomica, «Evaluación de la exposición ocupacional debida a fuentes externas de radiación. Guía de Seguridad No RS-G-1.3,» OIEA, Viena, [3] «Centro de Protección e Higiene de las Radiaciones,» 10 diciembre [En línea]. Available: [Último acceso: 10 enero 2014]. [4] R. Pernas Salomón y D. Molina Perez, «Pruebas tipo al sistema automático de dosimetría termoluminiscente del CPHR,» Nucleus, nº 37, pp , [5] J. F. Manzano de Armas, E. Diaz Bernal y E. Capote Ferrera, «Sistema de gestión de datos en dosimetría personal Dosis,» de Memorias del V Congreso Regional de Seguridad y Protección Radiológica, Recife, Brasil, [6] D. Molina Perez, A. Castro Soler, M. Verdecia, Y. Farradas y J. F. Manzano de Armas, «Resultados de la vigilancia radiológica individual de la exposición externa en Cuba en el período ,» Nucleus, nº 49, pp , [7] «Sistema de información SISERI,» [En línea]. Available: [Último acceso: 18 Enero 2010]. [8] «Mirion Technologies,» [En línea]. Available: [Último acceso: 18 Enero 2010]. [9] «Hospital Regional Universitario Carlos Haya,» [En línea]. Available: [Último acceso: 18 Enero 2010]. [10] J. G. Alvez, M. B. Martins, A. R. Roda y J. N. Abrantes, «Database in use at the Individual Monitoring Service of ITN-DPRSN,» Radiation Protection Dosimetry, vol. III, nº 1, pp , [11] J. P. Ashmore y D. Grogan, «Tha National Dose Registry for Radiation Workers in Canada,» Radiation Protection Dosimetry, vol. II, pp , [12] A. Hernández, A. Martín, I. Amor y J. L. Butragueño, «Tha Spanish National Dose Registry and Spanish Radiation Passbooks,» Radiation Protection Dosimetry, vol. 96, nº 99

100 1-3, pp , [13] «Scaling the N-Tier Architecture,» Sun Microsystems, 8 Febrero [En línea]. Available: [Último acceso: 18 Junio 2012]. [14] «Guía Breve de Servicios Web,» W3C, 2 Agosto [En línea]. Available: [Último acceso: 18 Junio 2012]. [15] P. C. Morales, «Desarrollo de Aplicaciones Distribuidas basadas en Tecnologías Web,» 2 Noviembre [En línea]. Available: [16] «Symfony,» SencioLabs, 10 Junio [En línea]. Available: [Último acceso: 10 junio 2014]. [17] J. Eguiluz, Desarrollo web ágil con Symfony 2, [18] «SensioLabs,» [En línea]. Available: https://insight.sensiolabs.com/. [Último acceso: 12 Junio 2014]. [19] R. Saunier, Getting Started with Laravel 4, Birmingham: Packt Publishing, [20] Desarrolladores de Laravel, «Introduccion - Documentation Laravel PHP Framework,» [En línea]. Available: [Último acceso: 22 Octubre 2013]. [21] W. H. Inmon, Building the Data Warehouse:, New York: John Wiley & Sons, [22] J. A. O'Brien y G. M. Marakas, Management information Systems, Boston: McGraw- Hill/Irwin, [23] W. H. Inmon, «Data Mart Does Not Equal Data Warehouse,» DM Review, [24] R. Kimball, The Data Warehouse Toolkit. Second Edition, New York: Jhon Wiley & Sons, [25] MySQL, «Enterprise Data Warehousing with MySQL,» MySQL Business White Paper, [26] Wikipedia, la enciclopedia libre, «Inteligencia Empresarial,» [En línea]. Available: [Último acceso: 16 Septiembre 100

101 2013]. [27] D. Hand, H. Mannila y P. Smyth, Principles of Data Mining, Cambridge: MIT Press, [28] P. Cabena, P. Hadjinian, R. Stadler, J. Verhees y A. Zanasi, Discovering Data Mining: From Concept to Implementation, Upper Saddle, NJ: Prentice Hall, [29] J. H. Orallo, J. R. Quintana y C. F. Ramirez, Introducción a la Minería de Datos, Madrid: Pearson Educación SA, [30] M. Kantardzic, Data Mining: Concepts, Models, Methods, and Algorithms, John Wiley & Sons, [31] F. Eibe, B. Pfahringer, G. Holmes, P. Reutemann y I. H. Witten, «The WEKA Data Mining Software: An Update,» SIGKDD Explorations, vol. 11, nº 1, pp , [32] Ministerio de Administraciones Públicas, «Metrica 3,» [En línea]. Available: [Último acceso: 1 Abril 2010]. [33] K. Hamilton y R. Miles, Learning UML 2.0, Sebastopol, CA: O'Reilly, [34] C. Larman, UML y Patrones, Una introducción al análisis y diseño orientado a objetos y al Proceso Unificado, Segunda Edición, Madrid: Pearson-Prentice Hall, [35] A. H. Gonzales, «Un método para el diseño de la Base de Datos a partir del Modelo Orientado a Objeto,» Computación y Sistemas, vol. 7, pp , [36] M. Gunderloy, Developer to Designer: GUI Design for the Busy Developer, Alameda, CA: SYBEX, [37] M. Cantu, Delphi 2009 Handbook., Piacenza, Italy: Wintech Italia Srl, [38] C. Adamson, Star Chema, Complete Reference, New York: McGraw-Hill, [39] R. D. Bernabeu, HEFESTO: Metodología para la Construcción de un Data Warehouse, Cordoba, [40] K. Hamilton y R. Miles, Learning UML 2.0, Sebastapol, CA: O'Reilly,

102 Anexo 1. Diagrama IDEFO del servicio de dosimetría externa del CPHR. 102

103 103

104 104

105 105

106 106

107 107

108 108

109 109

110 110

111 111

112 Anexo 2. Gestión de proyectos. La Gestión de Proyectos tiene como finalidad principal la planificación, el seguimiento y control de las actividades y de los recursos humanos y materiales que intervienen en el desarrollo de un Sistema de Información. Una de las primeras tareas a acometer es la estimación de esfuerzo, la cual tiene como objetivo estimar el tamaño aproximado del sistema a desarrollar y establecer los costos, la duración y los recursos necesarios para poder desarrollarlo. Es muy difícil realizar este cálculo con precisión ya que intervienen muchos factores en su realización. Para este análisis se utiliza el método MARKII descrito en METRICA 3. Los componentes identificados para la presente estimación se definen en términos de Casos de Uso, considerando dentro de su estructura los siguientes: Tipos de Datos de entrada (IN) Tipos de Datos de salida (OUT) Entidades (ENT) ID Caso de uso ENT IN OUT CU.01 Manejar usuarios del sistema y cambios de contraseña CU.02 Manejar clasificadores del sistema CU.03 Exportar información al banco dosimétrico CU.04 Exportar información al sistema dosis MINFAR CU.05 Exportar información al sistema GESCOM CU.06 Registrar entidades usuarias CU.07 Importar datos de entidades usuarias CU.08 Registrar departamentos con servicios dosimétricos CU.09 Registrar Trabajadores Ocupacionalmente Expuestos y solicitudes de servicios. CU.10 Preparar y entregar dosímetros CU.11 Enlazar el código del dosímetro con el código de la tarjeta

113 ID Caso de uso ENT IN OUT CU.12 Recepcionar dosímetros y organizar bandejas para la lectura. CU.13 Recolectar y enviar información de dosímetros preparados. CU.14 Recolectar y obtener información de dosímetros recepcionados. CU.15 Importar valores de dosis de dosímetros evaluados CU.16 Recolectar y enviar valores de dosis CU.17 Recolectar y obtener información estadística CU.18 Registrar acciones realizadas con el sistema La siguiente tabla permite la valoración en Puntos Función no ajustados (PFNA) de todas las funciones que intervienen en el Sistema. Los pesos empleados para la ponderación de las entidades, tipos de datos de entrada y tipos de datos de salida han sido obtenidos por el autor del Método a partir de su experiencia y están basados en la media de la industria informática. ID Caso de uso ENT IN OUT PFNA CU.01 Manejar usuarios del sistema y cambios de 1* * * contraseña. CU.02 Manejar clasificadores del sistema. 5* * * CU.03 Exportar información al banco dosimétrico. 8* * 6* CU.04 Exportar información al sistema dosis 1* * * MINFAR CU.05 Exportar información al sistema GESCOM 4* * * CU.06 Registrar entidades usuarias 4* * * CU.07 Importar datos de entidades usuarias. 5* * * CU.08 Registrar departamentos con servicios 5* * * dosimétricos. CU.09 Registrar Trabajadores Ocupacionalmente 4* * * Expuestos y solicitudes de servicios. CU.10 Preparar y entregar dosímetros. 4* * 8* CU.11 Enlazar el código del dosímetro con el 4* * * código de la tarjeta. CU.12 Recepcionar dosímetros y organizar 5* * * bandejas para la lectura. CU.13 Recolectar y enviar información de dosímetros preparados. 16* * *

114 ID Caso de uso ENT IN OUT PFNA CU.14 Recolectar y obtener información de 1* * * dosímetros recepcionados. CU.15 Importar valores de dosis de dosímetros 6* * * evaluados. CU.16 Recolectar y enviar valores de dosis. 14* * 15* CU.17 Recolectar y obtener información 6* * 16* estadística CU.18 Registrar acciones realizadas con el sistema. 8* * * El valor del indicador de punto de función no ajustado (PFNA) es de A continuación se presenta la evaluación realizada para determinar la valoración de grados de influencia según la definición de los siguientes valores: Sin influencia (0). El sistema no contempla este atributo. Influencia mínima (1). La influencia de este atributo es muy poco significativa. Influencia moderada (2). El sistema contempla este atributo y su influencia, aunque pequeña, ha de ser considerada. Influencia apreciable (3). La importancia de este atributo debe ser tenida en cuenta, aunque no es fundamental. Influencia significativa (4). Este atributo tiene una gran importancia para el Sistema. Influencia muy fuerte (5). Este atributo es esencial para el Sistema y ha de ser tenido en cuenta a la hora del diseño. Atributos Influencia Comunicación de datos 5 Funciones distribuidas 4 Prestaciones 3 Gran uso de la configuración 5 Velocidad de las transacciones 4 Entrada de datos en línea 5 Diseño para la eficiencia del usuario final 5 Actualización de datos En línea 5 Complejidad del proceso lógico interno de la 3 aplicación 114

115 Reusabilidad del código por otras aplicaciones. 4 Facilidad de instalación 4 Facilidad de operación 4 Localizaciones múltiples 4 Facilidad de cambios 3 Requerimientos de otras aplicaciones. 5 Seguridad, privacidad, auditabilidad. 5 Necesidades de formación o capacitación de usuarios. 3 Utilización directa por terceras partes. 5 Documentación. 5 TOTAL 81 El valor de los grados de influencia es 81. A partir de este valor se obtuvo el factor de ajuste, según la fórmula: ACT = 0,65 + 0,005 * TGI ACT = * 81 = Siendo: ACT: Ajuste por Complejidad Técnica. TGI: Total Grados de Influencia. A continuación se realizó el cálculo para estimar el tamaño total del sistema en puntos de función mediante la fórmula: PFA = PFNA * ACT PFA = * = Donde: PFA: Puntos de Función Ajustados PFNA: Puntos de Función No Ajustados Para el cálculo de la productividad estimada, es necesario aplicar la siguiente fórmula: 115

116 P = A P = 1.6 P = 1.6 P = 1.6 = 0.19 Donde: P: Productividad A: Media de la Industria informática: A= 1,0 para lenguajes de 3ra generación A= 1,6 para lenguajes de 4ta generación S: Tamaño del Sistema en PFA Al conocer que la productividad estimada en puntos de función por hora de trabajo es de 0.19 se procede a estimar el esfuerzo en horas de trabajo por la fórmula siguiente: W = W = = Donde: W: Esfuerzo en horas de trabajo B: Factor de complejidad (1 si es en línea) El valor estimado de horas necesarias para desarrollar el sistema es de Para estimar el valor del plazo de entrega del sistema primeramente hay que calcular el factor a aplicar, el cual relacionado con el tamaño del sistema y cuyo valor se obtiene mediante la aplicación de la siguiente fórmula: 116

117 = 0.45 * = 8.14 Donde: E: Puntos Función / semana S: Tamaño del Sistema en PFA A continuación, se obtiene el tiempo estimado total para la entrega del Sistema, para lo que se aplica la fórmula que aparece a continuación: = = Donde: PE: Plazo de entrega, en semanas S: Tamaño del Sistema en PFA E: Puntos Función / semana Según estas estimaciones el sistema debe ser entregado después de semanas de trabajo, esto teniendo en cuenta que el personal solamente se dedica a estas funciones; pero en la vida real hay otros factores que influyen en los tiempos de entregas y son muy difíciles de calcular. Una vez estimados estos valores se procedió a elaborar un plan de trabajo detallado en fases, las cuales corresponden con los procesos propuestos por la metodología y la escala temporal utilizada es en semanas y meses. Para esto se utilizó el sistema Microsoft Project, el cual es una herramienta que nos posibilita gestionar todos los recursos involucrados en el desarrollo del sistema de información. 117

118 Anexo 3 Casos de uso del sistema de gestión cliente servidor. Sistema Gestión Dosimetría CU.06 Registrar entidades usuarias. «extends» CU.07 Importar datos de entidades usuarias. «uses» <<include>> «uses» CU.08 Registrar departamentos con servicios dosimétricos. <<include>> CU.15 Importar valores de dosis de dosímetros evaluados. «uses» «uses» <<include>> <<include>> «uses» RADOS operador CU.09 Registrar Trabajadores Ocupacionalmente Expuestos y solicitudes de servicios. <<include>> CU.18 Registrar acciones realizadas con el sistema. CU.16 Recolectar y enviar valores de dosis. CU.17 Recolectar y obtener información estadística. «uses» «uses» «uses» <<include>> CU.10 Preparar y entregar dosímetros. <<include>> <<include>> <<include>> CU.01 Manejar usuarios del sistema y cambios de contraseña. Especialista «uses» Comercial Técnico «uses» «uses» «uses» CU.11 Recepcionar dosímetros. CU.11 Enlazar el código del dosímetro con el código de la tarjeta. <<include>> <<include>> <<include>> <<include>> CU.02 Manejar clasificadores del sistema. CU.03 Exportar información al banco dosimétrico. «uses» «uses» «uses» «uses» CU.13 Recolectar y enviar información de dosímetros preparados. CU.04 Exportar información al sistema dosis MINFAR «uses» Administrador <<include>> CU.14 Recolectar y obtener información de dosímetros recepcionados. CU.05 Exportar información al sistema GESCOM 118

119 Caso de Uso Propósito Resumen Actores CU.01 Manejar usuarios del sistema y cambios de contraseña. Llevar el control de los usuarios con acceso al sistema, sus niveles de acceso y contraseñas. Para trabajar con el sistema es necesario contar con una clave de acceso para evitar que personal no autorizado por el servicio acceda y trabaje con los datos. El administrador del sistema les proporciona a los usuarios autorizados un identificador, una contraseña y un nivel de acceso. También se configura el tiempo de caducidad de la contraseña. Administrador Precondición El usuario debe autentificarse y tener privilegios de administrador del sistema. Secuencia Normal Paso Acción 1 El administrador introduce los datos personales del usuario que utilizará el sistema. 2 El sistema genera una contraseña con alto nivel de complejidad que puede ser cambiada por el administrador. 3 El administrador define el nivel de acceso del usuario que por defecto es el menor. 4 El administrador define el tiempo de caducidad de la contraseña. 5 El sistema pone el estado del trabajador en alta. 6 El sistema verifica que los datos sean los correctos y estén completos. 7 El administrador guarda los cambios en la base de datos. 8 El sistema registra en la bitácora el nombre del administrador, el nuevo usuario y la fecha y hora que se le dio alta. Postcondición El usuario registrado ya puede trabajar con el sistema teniendo en cuenta su nivel de acceso. La contraseña se almacena encriptada en la base de datos. Secuencia Alternativa Paso Acción 1 Si un usuario va a ser dado de baja el sistema cambia el estado a baja. Puntos de extensión: 1 Si un usuario va a ser eliminado definitivamente el sistema se verifica que no tenga historial en la bitácora, de lo contrario no se puede eliminar de la base de datos y se alerta al administrador. 2 Si la contraseña introducida por el administrador no cumple con los requisitos de complejidad el sistema lanza una alerta y no permite guardar los datos. 1, 2, 3, 4, 5 Si el administrador desea abortar la operación de actualización, modificación o eliminación el sistema regresa al estado de precondición sin actualizar la bitácora. 6 Si los datos no están correctos o faltan el sistema lanza una alerta y no permite guardarlos en la base de datos, manteniendo activa la ventana con los datos del usuario. CU.15 Registrar acciones realizadas con el sistema. 119

120 Caso de Uso Propósito Resumen Actores CU.02 Manejar clasificadores del sistema. Gestionar los datos de los diferentes clasificadores utilizados en el sistema. El sistema gestiona un grupo de clasificadores que son utilizados por las diferentes tablas de la base de datos. El administrador es el encargado de adicionar, modificar o eliminar estos clasificadores. Hay que tener en cuenta que un clasificador no puede ser eliminado si está siendo utilizado por alguna de las tablas de la base de datos. Administrador Precondición El usuario debe autentificarse y tener privilegios de administrador del sistema. Secuencia Normal Paso Acción 1 El administrador selecciona el clasificador con el que desea trabajar. Postcondición 2 El administrador Introduce los datos del clasificador nuevo o modifica el existente. 3 El sistema verifica que los datos sean los correctos y estén completos. 4 El administrador guarda los cambios en la base de datos. 5 El sistema registra en la bitácora el nombre del clasificador y la fecha y hora que se le dio alta o modificó. Se crean los clasificadores que serán utilizados por las diferentes tablas de la base de datos del sistema. Secuencia Alternativa Paso Acción 1 Si un registro del clasificador va a ser eliminado definitivamente el sistema verifica que no sea utilizado por las tablas relacionadas, de lo contrario no se puede eliminar de la base de datos y se alerta al administrador. Puntos de extensión: 1, 2, 3, 4, Si el administrador desea abortar la operación de actualización, modificación o eliminación el sistema regresa al estado de precondición sin actualizar la bitácora. 3 Si los datos no están correctos o faltan el sistema lanza una alerta y no permite guardarlos en la base de datos. CU.15 Registrar acciones realizadas con el sistema. 120

121 Caso de Uso Propósito Resumen CU.03 Exportar información al banco dosimétrico. Exportar las dosis recibida por los TOE al Banco Dosimétrico Nacional El Banco Dosimétrico Nacional es un registro legal de la información dosimétrica de los trabajadores ocupacionalmente expuesto a las radiaciones en el país. Actores Precondición Administrador El usuario debe autentificarse y tener privilegios de administrador del sistema. Secuencia Normal Paso Acción 1 El administrador selecciona la opción de exportar la información al Banco Dosimétrico Nacional 2 El sistema le solicita al administrador la ruta donde se almacenará la información recopilada. 3 El administrador selecciona la carpeta donde se almacenarán los datos que se exportarán. 4 El sistema recopila información que no esté marcada como entregada al banco. 5 El sistema guarda la información en formato XML y encriptada en la carpeta definida por el administrador. 6 El sistema registra en la bitácora la fecha y hora de la exportación de los datos. Postcondición La información exportada es enviada al administrador del Banco Nacional Dosimétrico. Secuencia Alternativa Paso Acción 1 Si no se encuentra la información solicitada el sistema lanza una alerta y regresa al estado de precondición sin actualizar la bitácora. Puntos de extensión: CU.15 Registrar acciones realizadas con el sistema. Caso de Uso CU.04 Exportar información al sistema dosis MINFAR Propósito Resumen Actores Precondición Exportar las dosis recibida por los TOE pertenecientes a las instituciones militares hacia la base de datos Dosis del MINFAR. El MINFAR tiene una copia de la base de datos del CPHR; pero sólo con la información de las entidades que están bajo su cargo. Esta información es enviada periódicamente utilizando soporte electrónico. Administrador El usuario debe autentificarse y tener privilegios de administrador del sistema. Secuencia Normal Paso Acción 1 El administrador selecciona la opción de exportar datos hacia el sistema dosis del MINFAR 121

122 2 El sistema le solicita al administrador la ruta donde se almacenará la información recopilada. 3 El administrador selecciona la carpeta donde se almacenarán los datos que se exportarán. 4 El sistema recopila información de las instituciones del MINFAR, los trabajadores y los resultados de las mediciones. 5 El sistema guarda la información en formato XML y encriptada en la carpeta definida por el administrador. 6 El sistema registra en la bitácora la fecha y hora de la exportación de los datos. Postcondición La información de las instituciones del MINFAR está guardada en formato XML y encriptada. Secuencia Alternativa Paso Acción 4 Si no se encuentra la información solicitada el sistema lanza una alerta y regresa al estado de precondición sin actualizar la bitácora. Puntos de extensión: CU.15 Registrar acciones realizadas con el sistema. Caso de Uso Propósito CU.05 Exportar información al sistema GESCOM Exportar datos del sistema hacia la base de datos GESCOM Resumen El sistema GESCOM es utilizado por la Oficina Comercial del CPHR para la gestión de los clientes, las solicitudes de servicios y la automatización del proceso de contratación. Actores Administrador Precondición El usuario debe autentificarse y tener privilegios de administrador del sistema. Secuencia Normal Paso Acción 1 El administrador selecciona la opción de exportar datos hacia el sistema GESCOM 2 El sistema le solicita al administrador la ruta donde se almacenará la información recopilada. 3 El administrador selecciona la carpeta donde se almacenarán los datos que se exportarán. 4 El sistema recopila información de los trabajadores y los resultados de las mediciones. 5 El sistema guarda la información en formato XML y encriptada en la carpeta definida por el administrador. Postcondición 6 El sistema registra en la bitácora la fecha y hora de la exportación de los datos. La información es guardada y enviada a la Oficina Comercial. Secuencia Alternativa Paso Acción 4 Si no se encuentra la información solicitada el sistema lanza una alerta y regresa al estado de precondición sin actualizar la bitácora. 122

123 Puntos de extensión: CU.15 Registrar acciones realizadas con el sistema. Caso de Uso Propósito Resumen Actores Precondición CU.06 Registrar entidades usuarias. Gestionar los datos de las entidades del país que reciben servicio de dosimetría externa. Se actualizan, modifican y eliminan los datos de las entidades que reciben el servicio de dosimetría externa por parte del laboratorio. Cada entidad pertenece a determinada esfera de aplicación de las técnicas nucleares (medicina, industria, investigación, etc.) y está formada por varios departamentos con trabajadores ocupacionalmente expuesto a las radiaciones ionizantes (TOE) Operador El usuario debe autentificarse y tener privilegios para gestionar los datos de las entidades usuarias. Deben estar actualizado los clasificadores. Secuencia Normal Paso Acción 1 El operador introduce el código REUP de la nueva entidad. 2 El sistema comprueba que el código REUP de la entidad no esté registrado con anterioridad en la base de datos. 3 El operador introduce el resto de los datos de la entidad. Postcondición 4 El sistema verifica que los datos sean los correctos y estén completos. 5 El operador guarda la información actualizada en la base de datos. 6 El sistema registra en la bitácora el nombre del operador, el nuevo usuario y la fecha y hora que se le dio alta. Está almacenada en la base de datos la información de la nueva entidad. Secuencia Alternativa Paso Acción 2 Si el código REUP existe el sistema lanza una alerta y muestra en pantalla los datos de la entidad dándole la posibilidad al operador de modificar los mismos de ser necesario. 1, 2, 3, 4 Si el operador desea abortar la operación de actualización, modificación o eliminación el sistema regresa al estado de precondición sin actualizar la bitácora. Puntos de extensión: 4 Si los datos no están correctos o faltan el sistema lanza una alerta y no permite guardarlos en la base de datos. 1 Los datos de las entidades pueden ser cargados a través de un fichero Excel enviado por las entidades a la oficina comercial. 1 El sistema verifica que los datos estén correctos y completos, enviando una alerta en caso de problema y registrándolo en la bitácora. 1 Si una entidad va a ser eliminada, el sistema verifica que su código no sea utilizado por las tablas relacionadas, de lo contrario no se puede eliminar de la base de datos y se alerta al operador. CU.15 Registrar acciones realizadas con el sistema. CU.07 Importar datos de entidades usuarias. 123

124 Caso de Uso Propósito Resumen Actores CU.07 Importar datos de entidades usuarias. Importar datos de las entidades suministrado por el sistema GESCOM de la oficina comercial. En la oficina comercial se le da alta a las entidades usuarias que vienen a solicitar los servicios del Centro. El sistema GESCOM tiene una opción que envía un fichero XML a través del correo electrónico con información de los clientes de los servicios dosimétricos. Esta información es cargada por el sistema para automatizar la actualización de nuevas entidades. Operador Precondición El usuario debe autentificarse y tener privilegios para importar los datos de las entidades usuarias. Deben estar actualizado los clasificadores. Secuencia Normal Paso Acción 1 El operador selecciona la ruta donde se encuentra el fichero con la actualización de las nuevas entidades usuarias. Postcondición 2 El sistema lee el fichero y actualiza la información de las entidades en la base de datos, verificando siempre que los datos estén correctos. 3 El sistema lanza un aviso de que la actualización se realizó satisfactoriamente. 4 El sistema registra en la bitácora el nombre del operador, el nombre del fichero y la fecha y hora que se realizó la importación de los datos. Está almacenada en la base de datos la información de las nuevas entidades. Secuencia Alternativa Paso Acción 1 Si el operador desea abortar la operación de importación de datos el sistema regresa al estado de precondición sin actualizar la bitácora. 2 Si durante el proceso de importación algunos de los registros presentan problemas con la importación de los datos, envía esta información a la bitácora y continúa procesando el siguiente registro. 2 Al finalizar la importación el sistema lanza una alerta mostrándole al operador los registros que han presentado problemas. Puntos de extensión: CU.15 Registrar acciones realizadas con el sistema. 124

125 Caso de Uso Propósito Resumen Actores CU.08 Registrar departamentos con servicios dosimétricos. Gestionar los datos de los departamentos que forman parte de las entidades del país que reciben servicio de dosimetría externa. Se actualizan, modifican y eliminan los datos de los diferentes departamentos de las entidades usuarias. Es en los departamentos donde laboran los diferentes TOE. Se puede dar el caso que un TOE pertenezca a varios departamentos por lo que reciben los servicios dosimétricos por diferentes vías. Operador Precondición El usuario debe autentificarse y tener privilegios para actualizar los datos de los departamentos. Deben estar actualizado los clasificadores. Deben estar actualizadas las entidades usuarias. Secuencia Normal Paso Acción 1 El operador selecciona la entidad a la cual le quiere adicionar los departamentos. 2 El operador actualiza los datos del departamento. 3 El sistema verifica que los datos sean los correctos y estén completos. 4 El operador guarda la información actualizada en la base de datos. 5 El sistema registra en la bitácora el nombre del operador, el nombre del departamento y la fecha y hora que se le dio alta. Postcondición Está almacenada en la base de datos la información de los departamentos. Secuencia Alternativa Paso Acción 1, 2, 3, 4 Si el operador desea abortar la operación de actualización, modificación o eliminación el sistema regresa al estado de precondición sin actualizar la bitácora. 3 Si los datos no están correctos o faltan el sistema lanza una alerta y no permite guardarlos en la base de datos. Puntos de extensión: 1 El sistema verifica que los datos estén correctos y completos, enviando una alerta en caso de problema y registrándolo en la bitácora. 1 Si un departamento va a ser eliminado, el sistema verifica que su código no sea utilizado por las tablas relacionadas, de lo contrario no se puede eliminar de la base de datos y se alerta al operador. CU.15 Registrar acciones realizadas con el sistema. 125

126 Caso de Uso CU.09 Registrar Trabajadores Ocupacionalmente Expuestos y solicitudes de servicios. Propósito Actualizar, modificar y eliminar los datos de los TOE y las solicitudes de servicios dosimétricos. Resumen Cada entidad solicita servicios dosimétricos para los TOE de sus diferentes departamentos. Un TOE puede solicitar diferentes tipos de servicio (cuerpo entero, extremidades, cristalino) y trabajar en varias entidades y varios departamentos. Actores Operador Precondición El usuario debe autentificarse y tener privilegios para actualizar los datos de los TOE y solicitudes de servicios. Deben estar actualizado los clasificadores. Deben estar actualizadas las entidades usuarias y los departamentos. Secuencia Normal Paso Acción 1 El operador introduce el carnet de identidad del nuevo TOE. 2 El sistema verifica que no se encuentre en la base de datos. 3 El operador introduce los datos personales del TOE. 4 El sistema verifica que los datos sean los correctos y estén completos. 5 El operador guarda la información actualizada en la base de datos. Postcondición 6 El operador actualiza los datos de la solicitud de servicio, que incluye la entidad y el departamento del trabajador 7 El sistema verifica que la solicitud activa no exista para el TOE para ese servicio, entidad y departamento. 8 El sistema verifica que los datos sean los correctos y estén completos. 9 El operador guarda la información actualizada en la base de datos. 10 El sistema registra en la bitácora el nombre del operador, los datos de la solicitud y la fecha y hora que se le dio alta. Está almacenada en la base de datos la información del TOE y la solicitud de servicio. Secuencia Alternativa Paso Acción 1 Si la búsqueda del Carnet de Identidad da resultados positivos el sistema lanza una alerta y muestra los datos del TOE 4 Si los datos no están correctos o faltan el sistema lanza una alerta y no permite guardarlos en la base de datos. Si el operador desea abortar la operación de actualización, modificación o eliminación el sistema regresa al estado de precondición sin actualizar la bitácora. 1, 2, 3, 4, 5 7 Si al solicitud de servicio existe y esta activa el sistema lanza una alerta y no permite guardar los datos. 8 Si los datos no están correctos o faltan el sistema lanza una alerta y no permite guardarlos en la base de datos. 1, 6 Si un TOE o una solicitud van a ser eliminadas, el sistema verifica que su código no sea utilizado por las tablas relacionadas, de lo contrario no se puede eliminar de la base de datos y se alerta al 126

127 operador. Puntos de extensión: CU.15 Registrar acciones realizadas con el sistema. Caso de Uso CU.10 Preparar y entregar dosímetros. Propósito Generar los dosímetros que serán utilizados por los TOE para el control dosimétrico durante determinado periodo de tiempo. Resumen Se generan los dosímetros de las solicitudes de servicios que están activas. Cada TOE tiene un dosímetros para registrar la dosis recibida durante el trabajo con fuentes radiactivas. Los dosímetros son preparados y embalados para ser enviados a las entidades usuarias, cada dosímetro tienen un código único. Actores Técnico Precondición El usuario debe autentificarse y tener privilegios para preparar y entregar dosímetros. Deben estar actualizado los clasificadores. Deben estar actualizadas las entidades usuaria, los departamentos, los TOE y solicitudes de servicios. Secuencia Normal Paso Acción 1 El operador selecciona el servicio y las fechas del control dosimétrico. 2 El sistema busca todas las solicitudes de servicio activas. 3 El sistema chequea que cada uno de las solicitudes no tenga dosímetros preparados con anterioridad para las fechas seleccionadas por el técnico. 4 El sistema completa los datos de los dosímetros preparados y los guarda en la base de datos. 5 El técnico imprime las etiquetas con los códigos de barra y los datos identificativos del dosímetro. 6 El técnico imprime las constancias de entrega de los dosímetros preparados. 7 El sistema registra en la bitácora el nombre del operador, los datos de los dosímetros preparados y la fecha y hora que se generaron. Postcondición Los datos de los dosímetros generados están almacenados en la base de datos. Están impresa las etiquetas de los dosímetros y las constancias de entrega. Secuencia Alternativa Paso Acción 1 Si el técnico desea abortar la operación de preparación y entrega de dosímetros el sistema regresa al estado de precondición sin actualizar la bitácora. 2 Si el sistema encuentra que no hay solicitudes activas el sistema lanza una alerta regresa al estado de precondición sin actualizar la bitácora. 4 Si el sistema encuentra algún dosímetro preparado para la fecha seleccionada el sistema muestra sus datos al final del paso. 127

128 Puntos de extensión: Caso de Uso CU.15 Registrar acciones realizadas con el sistema. CU.11 Enlazar el código del dosímetro con el código de la tarjeta. Propósito Asignarle al dosímetro preparado el código de la tarjeta que contiene los detectores termoluminiscentes. Resumen El dosímetro está formado por una caseta protectora y una tarjeta con los detectores. Cada elemento tiene su propio código de barra. El sistema de lectura utiliza el código de la tarjeta para dar los resultados de la lectura. El sistema utiliza este dato para poder realizar la importación de las dosis evaluadas. Actores Técnico Precondición El usuario debe autentificarse y tener privilegios para preparar y entregar dosímetros. Deben tenerse la etiqueta del dosímetro, la caseta y la tarjeta con los detectores. Secuencia Normal Paso Acción 1 El operador introduce el código del dosímetro. 2 El sistema verifica el código del dosímetro. 3 El sistema busca el dosímetro preparado y muestra los datos. 4 El operador introduce el código de la tarjeta. 5 El sistema verifica el código de la tarjeta. 6 El sistema guarda el código de la tarjeta y cambia su estado a ocupado. 7 El sistema registra en la bitácora el nombre del operador, los datos de los dosímetros y tarjetas enlazadas, la fecha y hora de la operación. 8 El operador ensambla el dosímetro con todos sus elementos y lo almacena en el bulto correspondiente a la entidad. Postcondición El dosímetro está listo para ser enviado a las entidades. Secuencia Alternativa Paso Acción 1 Si el técnico desea abortar la operación de preparación y entrega de dosímetros el sistema regresa al estado de precondición sin actualizar la bitácora. 2 Si el sistema encuentra que no hay solicitudes activas el sistema lanza una alerta regresa al estado de precondición sin actualizar la bitácora. 4 Si el sistema encuentra algún dosímetro preparado para la fecha seleccionada el sistema muestra sus datos al final del paso. Puntos de extensión: CU.15 Registrar acciones realizadas con el sistema. 128

129 Caso de Uso Propósito CU.12 Recepcionar dosímetros y organizar bandejas para la lectura. Dar entrada a los dosímetros que serán evaluados por el servicio. Resumen Al finalizar el período de uso de los dosímetros por parte de los TOE, son enviados al laboratorio para ser evaluados. Una vez recepcionado, las tarjetas son colocadas en las bandejas donde serán leídos y procesados por el sistema RADOS. Actores Técnico Precondición El usuario debe autentificarse y tener privilegios para recepcionar los dosímetros. Deben tenerse los dosímetros enviados por las entidades para ser evaluados por el Laboratorio. Secuencia Normal Paso Acción 1 El técnico introduce el identificador de la bandeja que será utilizada para leer los dosímetros. 2 El sistema chequea el identificador de la bandeja. 3 El técnico lee el código de barra de los dosímetros que se van a recepcionar por el servicio para ser leídos. 4 El sistema localiza el dosímetro y muestras los datos en pantalla. Postcondición 5 El sistema guarda los datos de la recepción del dosímetro. 7 El operador imprime el acta de recepción. 8 El sistema registra en la bitácora el nombre del operador y los datos de los dosímetro recepcionados Los dosímetros están recepcionados y organizados en las bandejas donde serán leídos. Secuencia Alternativa Paso Acción 1 Si el técnico desea abortar la operación de recepción de dosímetros el sistema regresa al estado de precondición sin actualizar la bitácora. Puntos de extensión: 5 Si el identificador de la bandeja y el código de barra del dosímetro son incorrectos el sistema lanza una alerta y regresa al paso anterior. 3 Si el dosímetro ya fue recepcionado el sistema lanza una alerta y regresa al paso anterior. 3 Si el dosímetro no existe en la base de datos el sistema lanza una alerta y regresa al paso anterior. 3 Si el dosímetro no tiene asignado el código de la tarjeta el sistema lanza una alerta y solicita este dato, guardándolo en la base de datos y modificando el estado de la caseta a ocupado. CU.15 Registrar acciones realizadas con el sistema. 129

130 Caso de Uso CU.13 Recolectar y enviar información de dosímetros preparados. Propósito Obtener información de los dosímetros que serán enviados a las entidades usuarias. Resumen El Laboratorio prepara los dosímetros que serán enviados a los TOE de las diferentes entidades del país para ser utilizados durante el período de control. Con estos dosímetros se envía un listado de los dosímetros preparados e información consolidada de los mismos. Actores Técnico Precondición El usuario debe autentificarse y tener privilegios de recolectar información del sistema. Deben haberse generado los dosímetros que serán entregados a las entidades usuarias. Secuencia Normal Paso Acción 1 El técnico selecciona la fecha en que se generaron los dosímetros. 2 El sistema busca los dosímetros generados en esa fecha. 3 El sistema genera el reporte a partir de los datos obtenidos. 4 El técnico imprime el reporte. Postcondición Se obtiene la información de los dosímetros preparados. Secuencia Alternativa Paso Acción 1, 2, Si el técnico desea abortar la operación de recolección de 3, 4 información el sistema regresa al estado de precondición. Puntos de extensión: 1 El técnico también puede seleccionar la fecha de control o una entidad en específico. 2 El sistema no encuentra la información solicitada y envía alerta al especialista. 4 El técnico puede guardar el reporte en formato PDF o enviarlo por correo electrónico. Caso de Uso CU.14 Recolectar y obtener información de dosímetros recepcionados. Propósito Obtener información de los dosímetros que serán recepcionados por el servicio para ser evaluados. Resumen El Laboratorio recepciona los dosímetros que fueron enviados por las diferentes entidades del país para ser evaluados por el Laboratorio. Esta información es utilizada para organizar el proceso de lectura. Actores Técnico Precondición El usuario debe autentificarse y tener privilegios de recolectar información del sistema. Deben haberse recepcionado los dosímetros que serán procesados por el Laboratorio. Secuencia Normal Paso Acción 130

131 Postcondición 1 El técnico selecciona la fecha en que se recepcionaron los dosímetros. 2 El sistema busca los dosímetros recepcionados en esa fecha. 3 El sistema genera el reporte a partir de los datos obtenidos. 4 El técnico imprime el reporte. Se obtiene la información de los dosímetros preparados. Secuencia Alternativa Paso Acción 1, 2, Si el técnico desea abortar la operación de recolección de 3, 4 información el sistema regresa al estado de precondición. Puntos de extensión: 1 El técnico también puede seleccionar la fecha de control o una entidad en específico. 2 El sistema no encuentra la información solicitada y envía alerta al especialista. 4 El técnico puede guardar el reporte en formato PDF o enviarlo por correo electrónico. Caso de Uso Propósito Resumen CU.15 Importar valores de dosis de dosímetros evaluados. Importar las dosis de los dosímetros evaluados con el lector TLD desde la base de datos del sistema RADOS En la base de datos del sistema RADOS se almacenan los resultados de los dosímetros evaluados. El sistema debe importar estos valores utilizando el código de la tarjeta que previamente fue enlazado con el código del dosímetro. Actores Especialista, RADOS Precondición El usuario debe autentificarse y tener privilegios de administrador del sistema. Los dosímetros deben estar evaluados por el sistema RADOS Secuencia Normal Paso Acción 1 El especialista selecciona la fecha de recepción de los dosímetros. 2 El sistema busca los dosímetros que fueron enviados a lectura con esa fecha. 3 El sistema le solicita a RADOS las tarjetas que fueron leídas a partir de esa fecha 4 El sistema mediante el código de la tarjeta de los dosímetros enviados a lectura busca el resultado de la medición contenida en el sistema RADOS 5 El sistema convierte el resultado de las mediciones a msv y le resta el fondo 6 El sistema almacena la información de los resultados de la medición y cambia el estado de los dosímetros a leído. 7 El sistema cambia el estado de la tarjeta a libre para que pueda ser utilizado en otro dosímetro. 131

132 Postcondición 8 El sistema registra en la bitácora el nombre del operador y los datos de los resultados importados. Los dosímetros tienen los resultados de las mediciones. Secuencia Alternativa Paso Acción 1 Si el especialista desea abortar la operación el sistema regresa al estado de precondición. 2 Si el sistema no encuentra dosímetros envía una alerta al especialista y regresa al estado de precondición. 3 Si el sistema no encuentra tarjetas leídas en RADOS envía una alerta al especialista y regresa al estado de precondición. 4 Si el sistema no encuentra el código de la tarjeta en RADOS envía una alerta al especialista y no realiza los cambios en el dosímetro. Continúa el proceso hasta terminar con todos los dosímetros. 5 Si la dosis evaluada supera los valores limites envía una alerta al especialista y registra el suceso en la bitácora. Puntos de extensión: CU.15 Registrar acciones realizadas con el sistema. Caso de Uso Propósito CU.16 Recolectar y enviar valores de dosis. Obtener información de los valores de dosis recibida por los TOE Resumen Al finalizar el procesamiento de los dosímetros se envían a las entidades los reportes con las dosis recibidas por sus trabajadores en el período de control. En este reporte también la dosis acumulada durante el año de control y la acumulada durante los cinco años anteriores. Actores Especialista Precondición El usuario debe autentificarse y tener privilegios de recolectar información del sistema. Los dosímetros deben haber sido evaluados por el Laboratorio. Secuencia Normal Paso Acción 1 El especialista selecciona la fecha en que se recepcionaron los dosímetros. 2 El sistema busca los dosímetros recepcionados en esa fecha y que fueron evaluados por el Laboratorio. 3 El sistema genera el reporte a partir de los datos obtenidos. 4 El especialista imprime el reporte. Postcondición El reporte de dosis está listo para ser enviado a las entidades usuarias. Secuencia Alternativa Paso Acción 1, 2, Si el especialista desea abortar la operación de recolección de 3, 4 información el sistema regresa al estado de precondición. 132

133 1 El especialista también puede seleccionar la fecha de control o una entidad en específico. 2 El sistema no encuentra la información solicitada y envía alerta al especialista. 4 El especialista puede guardar el reporte en formato PDF o enviarlo por correo electrónico. Puntos de extensión: Caso de Uso CU.17 Recolectar y obtener información estadística. Propósito Obtener información estadística sobre el funcionamiento del servicio, las dosis recibidas y otros indicadores de interés para el Laboratorio. Resumen El sistema suministra una serie de reportes consistentes en tablas y gráficos con información relevante para el Laboratorio. Actores Especialista Precondición El usuario debe autentificarse y tener privilegios de recolectar información del sistema. Secuencia Normal Paso Acción 1 El especialista selecciona el reporte estadístico a imprimir e introduce los parámetros necesarios. 2 El sistema busca la información solicitada. Postcondición 3 El sistema genera el reporte a partir de los datos obtenidos. 4 El especialista imprime el reporte. Obtención de la información solicitada. Secuencia Alternativa Paso Acción 1, 2, Si el especialista desea abortar la operación de recolección de 3, 4 información el sistema regresa al estado de precondición. Puntos de extensión: 2 El sistema no encuentra la información solicitada y envía alerta al especialista. 4 El especialista puede guardar el reporte en formato PDF o enviarlo por correo electrónico. Caso de Uso CU.18 Registrar acciones realizadas con el sistema. Propósito Resumen Registrar en una bitácora las acciones realizadas por los usuarios del sistema. Con esta opción se pretende dar seguimiento a todas las acciones realizadas 133

134 con el sistema. También queda como evidencia para los registros del sistema de calidad del laboratorio. Actores Administrador, Operador, Especialista, RADOS Precondición El usuario debe y tener acceso al sistema. Secuencia Normal Paso Acción 1 El sistema almacena los datos de los usuarios, la fecha, la hora y la descripción de las acciones realizadas. Postcondición Registrada las acciones realizadas en el sistema Secuencia Alternativa Paso Acción Puntos de extensión: 134

135 Anexo 4. Diagramas de secuencia para los casos de uso del sistema de gestión cliente servidor. 135

136 136

137 137

138 138

139 139

140 140

141 141

142 142

143 143

144 Anexo 5. Diagramas de clases de diseño del sistema de gestión cliente servidor. <<TForm>> FormAcceso -ED_login: TEdit -ED_Password:TEdit -BT_Entrar:TBooton -BT_Salir:TBooton +IngresarDatos() +ValidadDatos() +CompruebaAcceso() +RegistraAcceso() +RegistraIntruso() <<TForm>> FormPrincipal +AsignaNivel() +SelecOpcion() +IngresoSistema() 1 * <<TMenu>> MenúSistema +MenuItemClic() <<TNegocio>> GestionInst -BInstituc:TTable -SInsttuc:SDataSource +AdicionInst() +ModifInst() +MostrarForm() +EliminaInst() +FiltrarInst() -ProbarIntegridad() -ValidarDatos() -MostrarError() <<TForm>> ListaInstitucion -LT_Insti: TGrid -BT_AdicionInst:TBtn -BT_ModifInst:TBtn -BT_EliminaInst:TBtn -BT_FiltraInst:TBtn -BT_Cerrar:TBtn +OnClick_AdicionInst() +OnClic_ModifInst() +OnClic_EliminaInst() +OnClic_FiltraInst() +OnClic_Cerrar() <<TForm>> FormInstitucion -ED_Codigo:TEdit -ED_Nombre:TEdit -ED_Director:TEdit -ED_Telefono:TEDit -ED_Fax:TEdit -ED_ TEdit -ED_Direccion:TEdit -CB_Provincia: TComboBox -CB_Municipio:TComboBox -CB_Ministerio:TComboBox -CB_Esfera:TComboBox -LT_Depart:TGrid -LT_Contrato:TGrid -BT_AgregaDepart:TBtn -BT_ModificaDepart:TBtn -BT_EliminaDepart:TBtn -BT_AgregaContrato:TBtn -BT_ModificaBtn:TBtn -BT_EliminaBtn:TBtn -BT_Aceptar:TBtn -BT_Cancelar:TBtn +OnClic_AgregarDepart() +OnClic_ModificarDepart() +OnClic_EliminarDepart() +OnClic_AgregarContrato() +OnClic_ModificarContrato() +OnClic_EliminarContrato() +OnClic_Cerrar() <<TForm>> ListaPersonal -LT_Persoi: TGrid -BT_AdicionPerso:TBtn -BT_ModifPerso:TBtn -BT_EliminaPerso:TBtn -BT_FiltraPerso:TBtn -BT_Cerrar:TBtn +OnClic_AdicionPers() +OnClic_ModifPers() +OnClic_EliminaPers() +OnClic_FiltraPers() +OnClic_Cerrar() <<TNegocio>> GestPersonal -BPerso:TTable -SPerso:SDataSource +AdicionPers() +ModifPers() +EliminaPers() +FiltraPers() -ProbarIntegridad() -ValidarDatos() <<TForm>> FormPersonal -ED_CodigoTOE:TEdit -ED_NombreTOE:TEdit -ED_Cident:TEdit -ED_Sexo:TEDit -DT_FechaNac:TDate -CB_Cargo:TComboBox -LT_Control:TGrid -BT_AgregaControl:TBtn -BT_ModificaControl:TBtn -BT_EliminaControl:TBtn -BT_Aceptar:TBtn -BT_Cancelar:TBtn +OnClic_AgregarControl() +OnClic_ModificarControl() +OnClic_EliminarControl() +OnClic_Cerrar() <<TNegocio>> GestSolicit -BPerso:TTable -SPerso:SDataSource +AdicionPers() +ModifPers() +EliminaPers() +FiltraPers() -ValidarDatos() +ProbarIntegridad() <<TForm>> ListaImportD -LT_FechaMed: TGrid -LT_DImport:TGrid -BT_Importar:TBtn -BT_Cerrar:TBtn +Importar() +Cerrar() <<TForm>> Solicit -CB_Entidad:TComboBox -CB_Depart:TComboBox -CB_Servicio:TComboBox -DT_FechaAlta:TDate -DT_FechaBaja:TDate -CB_EstTOE:TComboBox +Aceptar() +Cancelar() <<TForm>> ListaDosim -LT_Entidad: TGrid -BT_FiltraDosim:TBtn -LT_Dosimetro:TGrid -LT_Depart:TGrid -LT_TOE:TGrid -BT_EliminaPerso:TBtn -BT_GenDosim:TBtn -BT_BusDosim:TBtn -BT_RecDosim:TBtn +OnClic_GenerarDosim() +OnClic_RecepcionarDosim() +OnClic_BuscarDosim() +OnClic_FiltrarDosim() +OnClic_Cerrar() <<TNegocio>> GestDosim -BDosim:TTable -SDosim:SDataSource +GenerarDosim() +LeerCodBarra() +BuscarInfoTOE() +RecepcionarDosim() +BuscarDosim() +FiltrarDosim() -ValidarDatos() -ProbarIntegridad() +CambiarEstado() +MostrarFormGenDos() +MostrarFormRecep() +MostrarFormDosim() <<TForm>> FormDosimetro -ED_NoDosim:TEdit -ED_NoTLD:TEdit -DT_InicCont:TEdit -DT_FinCont:TEdit -DT_FechaEntrega:TDate -DT_FechaRecep:TDate -CB_Cargo:TComboBox -ED_Dosis:TEdit -ED_Obser:TEdit -BT_Aceptar:TBtn -BT_Cancelar:TBtn +Aceptar() +Cancelar() <<TNegocio>> GestDepart -BDepart:TTable -SDepart:SDataSource +AgregarDepart() +ModificarDepart() +EliminarDepart() -ValidarDatos() <<TForm>> FormDepart -ED_Departamento:TEdit -ED_JefeDepart:TEdit -ED_RPR:TEdit -ED_TelefDepart:TEdit -ED_FaxDepart:TEdit -ED_MailDpart:TEdit -BT_Aceptar:TBtn -BT_Cancelar:TBtn +Aceptar() +Cancelar() <<TNegocio>> GestContrat -BContra:TTable -SContra:SDataSource +AgregarContrato() +ModificarContrato() +EliminarContrato() -ValidarDatos() <<TForm>> FormContrato -ED_NoContrato:TEdit -CB_Servicio:TComboBox -CB_Frecuencia:TComboBox -DT_FechaInic:TDate -DT_FechaFin:TDate -ED_Duracion:TEdit -CB_Status:TComboBox +Aceptar() +Cancelar() 144

145 145 +IngresarDatos() +ValidadDatos() +CompruebaAcceso() +RegistraAcceso() +RegistraIntruso() -ED_login: TEdit -ED_Password:TEdit -BT_Entrar:TBooton -BT_Salir:TBooton <<TForm>> FormaAcceso +AsignaNivel() +SelecOpcion() +IngresoSistema() <<TForm>> FormPrincipal +MenuItemClic() <<TMenu>> MenúSistema 1 * +OnClic_Adicionar() +OnClic_Modificar() +OnClic_Eliminar() #ValidaDatos() -SelecClasif() -LT_ClaMinist:TGrid -LT_ClaEsfera: TGrid -LT_ClaPractica:TGrid -LT_ClaCargo:TGrid -LT_ClaEstado:TGrid -LT_ClaCiudad:TGrid -LT_ClaMunic:TGrid -LT_ClaServicio:TGrid -BT_Parametros:TBtn -BT_Cerrar:TBtn -BT_Adicionar:TBtn -BT_Modificar:TBtn -BT_Eliminar:TBtn <<TForm>> FormAministra +Imprimir() +Cerrar() -BT_RepServicio:TBtn -BT_RepGeneral:TBtn -BT_RepEstadist:TBtn -BT_Imprimir:TBtn -BT_Cerrar:TBtn <<TForm>> FormReportes +Salvar() +Cerrar() -ED_server:TEdit -ED_Port:TEdit -ED_DataBase:TEdit -ED_User:TEdit -ED_PW:TEdit -BT_Salvar:TBtn -BT_Cerrar:TBtn <<TForm>> Parametro +Imprimir() + () +Exportar() +Cerrar() <<TForm>> PreView +Adicionar() +Modificar() +Eliminar() -ValidarDatos() -SelecClasif() -BMinist:TTable -BEsfera: TTTable -BPráctica:TTable -BCargo:TTable -BEstado:TTable -BCiudad:TTable -BMunic:TTable -BServicio:TTable -SMinist:TDataSource -SEsfera:TDataSource -SPráctica:TDataSource -SCargo:TDataSource -SEstado:TDataSource -SCiudad:TDataSource -SMunic:TDataSource -SServicio:TDataSource <<TNegocio>> Administrar +Aceptar() +Cancelar() -ED_Codr:TEdit -ED_Descrip:TEdit -BT_Aceptar:TBtn -BT_Cancelar:TBtn <<TForm>> Ministerio +Aceptar() +Cancelar() -ED_Codr:TEdit -ED_Descrip:TEdit -BT_Aceptar:TBtn -BT_Cancelar:TBtn <<TForm>> Esfera +Aceptar() +Cancelar() -ED_Codr:TEdit -ED_Descrip:TEdit -BT_Aceptar:TBtn -BT_Cancelar:TBtn <<TForm>> Práctica +Aceptar() +Cancelar() -ED_Codr:TEdit -ED_Descrip:TEdit -BT_Aceptar:TBtn -BT_Cancelar:TBtn <<TForm>> Cargo +Aceptar() +Cancelar() -ED_Codr:TEdit -ED_Descrip:TEdit -BT_Aceptar:TBtn -BT_Cancelar:TBtn <<TForm>> Ciudad +Aceptar() +Cancelar() -ED_Codr:TEdit -ED_Descrip:TEdit -BT_Aceptar:TBtn -BT_Cancelar:TBtn <<TForm>> Municipio +Aceptar() +Cancelar() -ED_Codr:TEdit -ED_Descrip:TEdit -BT_Aceptar:TBtn -BT_Cancelar:TBtn <<TForm>> Servicio +Aceptar() +Cancelar() -ED_Codr:TEdit -ED_Descrip:TEdit -BT_Aceptar:TBtn -BT_Cancelar:TBtn <<TForm>> Estado

146 Anexo 6. Diagramas de Actividad. 146

147 147

148 148

149 149

150 150

151 151

152 152

153 153

154 154

155 155

156 156

157 157

158 158

159 159

160 160

161 161

162 Anexo 7. Diseño físico de los datos. 162

163 163

164 Tabla: Entidad Descripción: Contiene los datos de las entidades usuaria del servicio de dosimetría externa. Nombre de la Columna Tipo Descripción Observaciones IDEntidad Entero Identificador único de la entidad usuaria. NombreEnt Texto (80) Nombre de la entidad usuaria. NombreC Texto (20) Nombre corto o sigla de la entidad usuaria. Utilizado en reportes y etiquetas. DirPostal Texto (100) Dirección postal de la entidad usuaria. NombreDir Texto (50) Nombre del director de la entidad usuaria. Telef Dir Texto (15) Teléfono del director de la entidad usuaria. FaxDir Texto (15) Fax del director de la entidad usuaria. Dir Texto (45) Correo electrónico del director de la entidad usuaria. NombreRPR Texto (50) Nombre del Responsable de Protección Radiológica de la entidad usuaria. TelefRPR Texto (15) Teléfono del Responsable de Protección Radiológica de la entidad usuaria. FaxRPR Texto (45) Fax del Responsable de Protección Radiológica de la entidad usuaria. RPR Texto (50) Correo electrónico del Responsable de Protección Radiológica de la entidad usuaria. CodProv Entero Código de la provincia donde Tomado de la tabla 164

165 radica la entidad usuaria. CodMunicip Entero Código del municipio donde radica la entidad usuaria. CodMinisterio Entero Código del ministerio al que pertenece la entidad usuaria. CodGrupo Entero Código del grupo en que está organizada la entidad usuaria. CodEsfera Entero Código de la esfera de aplicación de las técnicas nucleares utilizada por la entidad usuaria. Provincia Tomado de la tabla Municipio Tomado de la tabla Ministerio Tomado de la tabla Grupo Tomado de la tabla Esfera Tabla: Provincia Descripción: Clasificador de las provincias del país. Nombre de la Columna Tipo Descripción Observaciones IdProvincia Entero Identificador único de la provincia NombreProv Texto (45) Nombre de la provincia. Tabla: Municipio Descripción: Clasificador de los municipios del país. Nombre de la Columna Tipo Descripción Observaciones IdMunicipio Entero Identificador único del municipio NombreMunicip Texto (45) Nombre del municipio. CodProv Entero Código de la provincia a la que pertenece el municipio Tomado de la tabla Provincia. 165

166 Tabla: Ministerio Descripción: Clasificador de ministerios a los que pertenecen las diferentes entidades usuarias. Nombre de la Columna Tipo Descripción Observaciones IdMinisterio Entero Identificador único del ministerio NomMinist Texto (45) Nombre del Ministerio. Tabla: Grupo Descripción: Clasificador de grupo a los que pertenecen las diferentes entidades usuarias. Es utilizado para fines organizativos del trabajo en el Laboratorio. Nombre de la Columna Tipo Descripción Observaciones IdGrupo Entero Identificador único del grupo NomGrupo Texto (45) Nombre del grupo. Tabla: Esfera Descripción: Clasificador de esfera de aplicación de las técnicas nucleares. Nombre de la Columna Tipo Descripción Observaciones IdEsfera Entero Identificador único de la esfera. NomEsfera Texto (45) Nombre de la esfera. Tabla: Practica Descripción: Clasificador de la práctica ocupacional, está relacionado con la esfera de aplicación. Nombre de la Columna Tipo Descripción Observaciones 166

167 IdPractica Entero Identificador único de la práctica ocupacional. NomPract Texto (45) Nombre de la práctica ocupacional. CodEsfera Entero Código de la esfera de aplicación Tomado de la tabla Esfera Tabla: Departamento Descripción: Contiene datos de los diferentes departamentos que forman parte de una entidad usuaria. Nombre de la Columna Tipo Descripción Observaciones IdDpto Entero Identificador único del departamento NomDpto Texto (45) Nombre del departamento. CodEnt Entero Código de la entidad usuaria de la cual forma parte el departamento Tomado de la tabla Entidad Tabla: Solicitud Descripción: Contiene los datos de las solicitudes de servicios dosimétricos para cada uno de los trabajadores ocupacionalmente expuesto a las radiaciones ionizantes. Nombre de la Columna Tipo Descripción Observaciones IdSolicitud Entero Identificador único de la solicitud de servicio CodEnt Entero Código de la entidad usuaria que realiza la solicitud Tomado de la tabla Entidad CodDpto Entero Código del departamento Tomado de la tabla Departamento CodTOE Entero Código del trabajador ocupacionalmente expuesto a las radiaciones ionizantes Tomado de la tabla TOE FechaSolic Fecha Fecha de solicitud del servicio 167

168 CodPractica Entero Código de la práctica ocupacional del TOE CodEstadoSol Entero Código del estado en que se encuentra la solicitud Tomado de la tabla Practica Tomado de la tabla EstadoSol FechaBaja Fecha Fecha de baja de la solicitud CodServicio Entero Código del servicio dosimétrico solicitado. Tomado de la tabla Servicio Tabla: TOE Descripción: Contiene datos de los trabajadores ocupacionalmente expuestos a las radiaciones ionizantes. Nombre de la Columna Tipo Descripción Observaciones IdTOE Entero Identificador único del TOE Nombre Texto (50) Nombre del TOE. Apellidos Texto (80) Apellidos del TOE NoCI Texto (11) Número del carnet de identidad. Sexo Texto (1) Sexo del TOE FechaNac Fecha Fecha de nacimiento CodCalificacion Entero Calificación técnica del TOE Tomado de la tabla Calific. Tabla: Calific Descripción: Clasificador de las calificaciones técnica de los TOE. Nombre de la Columna Tipo Descripción Observaciones IdCalific Entero Identificador único de la calificación NomCalific Texto (45) Nombre de la calificación técnica. 168

169 Tabla: EstadoSol Descripción: Clasificador de los diferentes estados que puede tomar una solicitud de servicio. Nombre de la Columna Tipo Descripción Observaciones IdEstadoSol Entero Identificador único del estado de la solicitud NomEst Texto (45) Nombre del estado que toma la solicitud. Tabla: Servicio Descripción: Contiene datos de los servicios dosimétricos que pueden recibir los TOE Nombre de la Columna Tipo Descripción Observaciones IdServicio Entero Identificador único del servicio dosimétrico NomServicio Texto (45) Nombre del servicio dosimétrico. Responsable Texto (45) Nombre de la persona responsabilizada con el servicio. Magnitud Testo (5) Magnitud empleada en los resultados del servicio. Incertidumbre Decimal Incertidumbre de los resultados del servicio. LimDetec Decimal Límite de detección de dosis del servicio. LimInvest Decimal Límite de investigación. LimAnualRecomend Decimal Límite de dosis anual recomendado. LimIntervencionn Decimal Límite de intervención. Norma Texto (80) Nombre de la norma técnica empleada por el servicio. 169

170 Tabla: Dosímetro Descripción: Contiene datos de los dosímetro utilizado por los TOE en las diferentes solicitudes de servicios dosimétricos Nombre de la Columna Tipo Descripción Observaciones IdDosim Entero Identificador único del dosímetro utilizado en el servicio dosimétrico por un TOE CodSolicitud Entero Código de la solicitud de servicio dosimétrico Tomado de la tabla solicitud FechaPreparac Date Fecha en que se preparó el dosímetro. FechaInic Date Fecha inicial del control dosimétrico. FechaFin Date Fecha final del control dosimétrico. Entregado Boolean Indica si el dosímetro fue entregado o no. Recibido Boolean Indica si el dosímetro fue recibido para ser evaluado. CodSlide Texto (10) Código de la tarjeta que contiene los detectores termoluminiscentes. EstadoSlide Texto (1) Estado en que se encuentra la tarjeta que contiene los detectores termoluminiscentes. CodLector Entero Código del lector donde se evaluó el dosímetro. Tomado de la tabla Lector Bandeja Entero Identificador de la bandeja donde se coloca la tarjeta con los dosímetros. Position Entero Posición que ocupa la tarjeta dentro de la bandeja. Lectura Decimal Valor de la lectura del dosímetro Dosis Decimal Valor de la dosis evaluada. 170

171 Observaciones Texto (2) Observaciones asociadas al dosímetro. FechaLectura Date Fecha de lectura de la tarjeta. FechaExport Date Fecha de exportación de los valores de lectura y dosis Comentario Texto (45) Comentario opcional que se requiera acerca del dosímetro. Tabla: Lector Descripción: Contiene información de los lectores termoluminiscente utilizado por el servicio. Nombre de la Columna Tipo Descripción Observaciones IdLector Entero Identificador único del lector termoluminiscente. NomLector Texto (45) Nombre del lector termoluminiscente. Modelo Texto (45) Modelo del lector Estado Texto (2) Estado en que se encuentra el lector. Tabla: Acciones Descripción: Contiene información de las acciones realizadas sobre el dosímetro. Nombre de la Columna Tipo Descripción Observaciones IdAcciones Entero Identificador único de la acción realizada sobre el dosímetro. CodDosim Entero Código del dosímetro. Tomado de la tabla Dosímetro. Fecha DateTime Fecha y hora de la acción. CodOperador Entero Código del operador del sistema Tomado de la tabla Operador. 171

172 CodActividad Entero Código de la actividad realizada. Tomado de la tabla Actividad. Tabla: Actividad Descripción: Clasificación de las actividades realizadas sobre el dosímetro. Nombre de la Columna Tipo Descripción Observaciones IdActividad Entero Identificador único de la actividad realizada sobre el dosímetro. NomActividad Texto (25) Nombre de la actividad. Tabla: Operador Descripción: Contiene información del personal que tiene acceso al sistema Nombre de la Columna Tipo Descripción Observaciones IdOperador Entero Identificador único del personal con acceso al sistema NomOperador Texto (45) Nombre del personal. Login Texto (15) Identificador para acceder al sistema. Password Texto (12) Contraseña de acceso. Activo Boolean Indica si el personal está activo o no. Nivel Entero Nivel de acceso al sistema. 172

173 Anexo 8. Entorno de generación y construcción 173

174 174

175 175

176 Anexo 9. Vistas del sistema de gestión de la información cliente servidor. 176

177 177

178 178

179 179

180 180

181 181

182 182

183 183

184 184

185 185

186 Anexo 10. Vistas de la aplicación web. 186

187 187

188 188

189 189

190 Anexo 11. Modelo conceptual Dosis media Dosis máxima Dosis mínima Servicio Dosis colectiva Práctica Cantidad de trabajadores que sobrepasan los límites de dosis Cantidad de hombres y mujeres que reciben controles dosimétricos Institución Cantidad de dosímetros entregados Control Dosimétrico Tiempo Cantidad de dosímetros recibidos Cantidad de dosímetros no recibidos Trabajador Cantidad de dosímetros no utilizados Dosímetro Cantidad de dosímetros dañados Tiempo promedio de demora en la recepción de los dosímetros Tiempo promedio de demora en el procesamiento de los dosímetros Cantidad de dosímetros procesados 190

191 191 Anexo 12. Modelo conceptual ampliado Control Dosimétrico Servicio idservicio NomServicio LimInvest LimAnualRecomend LimInterven Práctica idpractica NombPrac NomEsfera Institución identidad NombreC NombMinist NombreProv NombreMunicip Tiempo FechaFin Año Semestre Trimestre Mes Trabajador IdTOE Sexo NomCalif Dosímetro IdDosim NomLector Bandeja Position DosisMed Avg(Dosis) DosisMax Max(Dosis) DosisMin Min(Dosis) DosisColect Sum(Dosis) CantTOE_LimD Count(Dosis >Limites) CantTOE_Sex Count(Trabajador.Sexo) CantDosEnt Count(Entregado=1) CantDosRec Count(Recibido=1) CantDosNoRec Count(Recibido=0) CantDosNU Count(Observ=NU) CantDosD Count(Observ=D) TDemRecep Avg(TiempoRecep) TDemProc Avg(TiempoProcesado) CantDosProc Count(Lectura>0)

192 Anexo 13. Modelo lógico del almacén de datos. D_Servicio D_Dosimetro CP IdServicio_D CP IdDosimetro_D NomServicio Tarjeta LimInvest Lector LimAnualRecomend Control_Dosimet Bandeja LimInterven CP IdDosimetro Posicion D_Institucion CP IdInstitucion_D NombreInst NombreMinist NombreProb NombreMunicip D_Practica CP IdPractica_D NombrePractica NombreEsfera CP CP CP CP CP IdTOE IdServicio IdInstitucion IdPractica IdTiempo Lectura Dosis Entregado Recibido TiempoRecep TiempoProcesado D_TEO CP IdTOE_D Sexo Calificacion D_Tiempo CP IdTiempo_D FechaFin Anno Semestre Trimestre Mes 192

IMPLEMENTACIÓN DE UN DATA MART PARA UN SERVICIO DE DOSIMETRÍA EXTERNA.

IMPLEMENTACIÓN DE UN DATA MART PARA UN SERVICIO DE DOSIMETRÍA EXTERNA. X Congreso Regional Latinoamericano IRPA de Protección y Seguridad Radiológica Radioprotección: Nuevos Desafíos para un Mundo en Evolución Buenos Aires, 12 al 17 de abril, 2015 SOCIEDAD ARGENTINA DE RADIOPROTECCIÓN

Más detalles

Diseño del Sistema de Información

Diseño del Sistema de Información Diseño del Sistema de Información ÍNDICE DESCRIPCIÓN Y OBJETIVOS...2 ACTIVIDAD DSI 1: DEFINICIÓN DE LA ARQUITECTURA DEL SISTEMA...7 Tarea DSI 1.1: Definición de Niveles de Arquitectura...9 Tarea DSI 1.2:

Más detalles

Diseño del Sistema de Información

Diseño del Sistema de Información Diseño del Sistema de Información ÍNDICE DESCRIPCIÓN Y OBJETIVOS... 2 ACTIVIDAD DSI 1: DEFINICIÓN DE LA ARQUITECTURA DEL SISTEMA... 7 Tarea DSI 1.1: Definición de Niveles de Arquitectura... 9 Tarea DSI

Más detalles

Capítulo 5. Cliente-Servidor.

Capítulo 5. Cliente-Servidor. Capítulo 5. Cliente-Servidor. 5.1 Introducción En este capítulo hablaremos acerca de la arquitectura Cliente-Servidor, ya que para nuestra aplicación utilizamos ésta arquitectura al convertir en un servidor

Más detalles

ASUNTO: AUTORIZACIÓN DE LA UNIDAD TÉCNICA DE PROTECCIÓN RADIOLÓGICA DE LA UNIVERSIDAD DE BARCELONA.

ASUNTO: AUTORIZACIÓN DE LA UNIDAD TÉCNICA DE PROTECCIÓN RADIOLÓGICA DE LA UNIVERSIDAD DE BARCELONA. Madrid, 24 de julio de 2008 UNIVERSIDAD DE BARCELONA Unidad Técnica de protección radiológica C/... 08007 Barcelona Atn: Vicerrector de Investigación ASUNTO: AUTORIZACIÓN DE LA UNIDAD TÉCNICA DE PROTECCIÓN

Más detalles

TEMA 37: Arquitecturas Cliente / Servidor. Tipos de cliente. Tipos de Servidor. Clasificación del software.

TEMA 37: Arquitecturas Cliente / Servidor. Tipos de cliente. Tipos de Servidor. Clasificación del software. . TEMA 37: Arquitecturas Cliente / Servidor. Tipos de cliente. Tipos de Servidor. Clasificación del software. Índice 1 INTRODUCCIÓN 2 2 CARACTERÍSTICAS 2 2.1 Características del cliente...2 2.2 Características

Más detalles

XXVI REUNION DE SISTEMATIZACION DE BANCOS CENTRALES AMERICANOS E IBERICOS. La Habana, Cuba, 26 al 30 de octubre de 1998

XXVI REUNION DE SISTEMATIZACION DE BANCOS CENTRALES AMERICANOS E IBERICOS. La Habana, Cuba, 26 al 30 de octubre de 1998 XXVI REUNION DE SISTEMATIZACION DE BANCOS CENTRALES AMERICANOS E IBERICOS La Habana, Cuba, 26 al 30 de octubre de 1998 CONTENIDO PROYECTO DE SISTEMA INFORMATIVO PARA EL BANCO CENTRAL DE CUBA Autor: Ing.

Más detalles

Implantación y Aceptación del Sistema

Implantación y Aceptación del Sistema y Aceptación del Sistema 1 y Aceptación del Sistema ÍNDICE DESCRIPCIÓN Y OBJETIVOS... 2 ACTIVIDAD IAS 1: ESTABLECIMIENTO DEL PLAN DE IMPLANTACIÓN...5 Tarea IAS 1.1: De finición del Plan de... 5 Tarea IAS

Más detalles

Máster en Instalación, Gestión y Mantenimiento de CRM: Gestión de Relaciones con Clientes

Máster en Instalación, Gestión y Mantenimiento de CRM: Gestión de Relaciones con Clientes Máster en Instalación, Gestión y Mantenimiento de CRM: Gestión de Relaciones con Clientes Titulación certificada por EUROINNOVA BUSINESS SCHOOL Máster en Instalación, Gestión y Mantenimiento de CRM: Gestión

Más detalles

Spectrum Power TG - Descripción General

Spectrum Power TG - Descripción General El Spectrum Power TG ha sido diseñado teniendo en consideración las necesidades específicas de la industria eléctrica. Este sistema puede operar tanto bajo ambiente Windows y Linux. Arquitectura del Sistema

Más detalles

PLAN DE PRUEBAS SISTEMA DE GESTIÓN HOSPITALARIA. Plan de Pruebas. File: 20130211-QA-INF-V2-PLAN DE PRUEBAS.odt STD-INF-GENERAL Versión: 1.

PLAN DE PRUEBAS SISTEMA DE GESTIÓN HOSPITALARIA. Plan de Pruebas. File: 20130211-QA-INF-V2-PLAN DE PRUEBAS.odt STD-INF-GENERAL Versión: 1. Cliente: FCM-UNA Página 1 de 14 PLAN DE PRUEBAS SISTEMA DE GESTIÓN HOSPITALARIA Cliente: FCM-UNA Página 2 de 14 Tabla de contenido 1. INTRODUCCIÓN 1.1. PROPÓSITO 1.2. ALCANCE 1.3. DEFINICIONES, ACRÓNIMOS

Más detalles

Resumen General del Manual de Organización y Funciones

Resumen General del Manual de Organización y Funciones Gerencia de Tecnologías de Información Resumen General del Manual de Organización y Funciones (El Manual de Organización y Funciones fue aprobado por Resolución Administrativa SBS N 354-2011, del 17 de

Más detalles

Metodología de Ingeniería del Software para el desarrollo y mantenimiento de sistemas de información del Gobierno de Extremadura

Metodología de Ingeniería del Software para el desarrollo y mantenimiento de sistemas de información del Gobierno de Extremadura Metodología de Ingeniería del Software para el desarrollo y mantenimiento de sistemas de información del Gobierno de Extremadura Página 1 de 23 Índice del Documento 1.- Introducción... Página 4 2.- Propuesta

Más detalles

FICHAS DE DESCRIPCIÓN DE FUNCIONES Y COMPETENCIAS LABORALES

FICHAS DE DESCRIPCIÓN DE FUNCIONES Y COMPETENCIAS LABORALES Página 1 de 11 I. IDENTIFICACIÓN DENOMINACIÓN DEL CARGO: PROGRAMADOR DE COMPUTADOR SIGLA:PC CLASE: V GRADO: 12-14-16 NIVEL: ADMINISTRATIVO NÚMERO DE CARGOS: ÁREA: 5 JEFE INMEDIATO: 1. OFICINA DE INFORMÀTICA

Más detalles

SEGURIDAD Y SALVAGUARDIAS. Ing. Hugo Cárdenas cardenas@cnea.gov.ar

SEGURIDAD Y SALVAGUARDIAS. Ing. Hugo Cárdenas cardenas@cnea.gov.ar SEGURIDAD Y SALVAGUARDIAS Ing. Hugo Cárdenas cardenas@cnea.gov.ar C N E A M E M O R I A A N U A L 2 0 0 1 69 SEGURIDAD PROTECCIÓN RADIOLÓGICA Y SEGURIDAD NUCLEAR La manipulación de material radiactivo

Más detalles

Facultad de Ingeniería Informática. Informe de las Prácticas Profesionales

Facultad de Ingeniería Informática. Informe de las Prácticas Profesionales Facultad de Ingeniería Informática CEIS Informe de las Prácticas Profesionales Título: Informatización de los Procesos de Negocio Solicitud de Trabajo Extra laboral en el CITI, a través de la BPMS BizAgi

Más detalles

CATÁLOGO DE SERVICIOS

CATÁLOGO DE SERVICIOS CATÁLOGO DE SERVICIOS NUESTRAS LINEAS DE NEGOCIO 1.- Desarrollo de Software a Medida: Contamos con vasto conocimiento en el desarrollo y arquitectura de Software, aplicamos metodología de proyectos, buenas

Más detalles

CUALIFICACIÓN PROGRAMACIÓN DE SISTEMAS INFORMÁTICOS PROFESIONAL. Nivel 3. Versión 5 Situación RD 1201/2007 Actualización

CUALIFICACIÓN PROGRAMACIÓN DE SISTEMAS INFORMÁTICOS PROFESIONAL. Nivel 3. Versión 5 Situación RD 1201/2007 Actualización Página 1 de 17 CUALIFICACIÓN PROGRAMACIÓN DE SISTEMAS INFORMÁTICOS PROFESIONAL Familia Profesional Informática y Comunicaciones Nivel 3 Código IFC303_3 Versión 5 Situación RD 1201/2007 Actualización Competencia

Más detalles

INTELIGENCIA DE NEGOCIOS CON SQL SERVER 2008 R2

INTELIGENCIA DE NEGOCIOS CON SQL SERVER 2008 R2 Programa de Capacitación y Certificación. INTELIGENCIA DE NEGOCIOS CON SQL SERVER 2008 R2 Contenido PERFIL DE UN ESPECIALISTA EN BASES DE DATOS.... 3 6231. MANTENIENDO UNA BASE DE DATOS DE SQL SERVER 2008

Más detalles

GESTIÓN Y SUPERVISIÓN DE ALARMAS EN REDES DE COMUNICACIONES

GESTIÓN Y SUPERVISIÓN DE ALARMAS EN REDES DE COMUNICACIONES Página 1 de 20 CUALIFICACIÓN PROFESIONAL GESTIÓN Y SUPERVISIÓN DE ALARMAS EN REDES DE COMUNICACIONES Familia Profesional Informática y Comunicaciones Nivel 3 Código IFC364_3 Versión 5 Situación RD 1701/2007

Más detalles

Análisis del Sistema de Información

Análisis del Sistema de Información Análisis del Sistema de Información ÍNDICE DESCRIPCIÓN Y OBJETIVOS... 2 ACTIVIDAD ASI 1: DEFINICIÓN DEL SISTEMA... 6 Tarea ASI 1.1: Determinación del Alcance del Sistema... 6 Tarea ASI 1.2: Identificación

Más detalles

Los mayores cambios se dieron en las décadas de los setenta, atribuidos principalmente a dos causas:

Los mayores cambios se dieron en las décadas de los setenta, atribuidos principalmente a dos causas: SISTEMAS DISTRIBUIDOS DE REDES 1. SISTEMAS DISTRIBUIDOS Introducción y generalidades La computación desde sus inicios ha sufrido muchos cambios, desde los grandes equipos que permitían realizar tareas

Más detalles

Técnico en Seguridad en Redes Locales

Técnico en Seguridad en Redes Locales Titulación certificada por EUROINNOVA BUSINESS SCHOOL Técnico en Seguridad en Redes Locales Duración: 300 horas Precio: 200 * Modalidad: Online * Materiales didácticos, titulación y gastos de envío incluidos.

Más detalles

Simulador de Protocolos de Red a tráves de WEB

Simulador de Protocolos de Red a tráves de WEB Simulador de Protocolos de Red a tráves de WEB Propuesta de Estudio 20071608 Director Ing. Francisco Antonio Polanco Montelongo Resumen Introducción Actualmente, el desarrollo tecnológico a alcanzado niveles

Más detalles

CUALIFICACIÓN PROGRAMACIÓN DE SISTEMAS INFORMÁTICOS PROFESIONAL. Nivel 3. Versión 6. Actualización

CUALIFICACIÓN PROGRAMACIÓN DE SISTEMAS INFORMÁTICOS PROFESIONAL. Nivel 3. Versión 6. Actualización Página 1 de 19 CUALIFICACIÓN PROGRAMACIÓN DE SISTEMAS INFORMÁTICOS PROFESIONAL Familia Profesional Informática y Comunicaciones Nivel 3 Código IFC303_3 Versión 6 Situación Contraste externo Actualización

Más detalles

El monitoreo de una variable física requiere supervisión permanente de señales que

El monitoreo de una variable física requiere supervisión permanente de señales que Capítulo 1 Marco Contextual 1.1. Formulación del problema 1.1.1. Definición del problema El monitoreo de una variable física requiere supervisión permanente de señales que varían con el tiempo. Tal información,

Más detalles

ADMINISTRACIÓN Y PROGRAMACIÓN EN SIS- TEMAS DE PLANIFICACIÓN DE RECURSOS EMPRESARIALES Y DE GESTIÓN DE RELA- CIONES CON CLIENTES

ADMINISTRACIÓN Y PROGRAMACIÓN EN SIS- TEMAS DE PLANIFICACIÓN DE RECURSOS EMPRESARIALES Y DE GESTIÓN DE RELA- CIONES CON CLIENTES IFCT0610: ADMINISTRACIÓN Y PROGRAMACIÓN EN SIS- TEMAS DE PLANIFICACIÓN DE RECURSOS EMPRESARIALES Y DE GESTIÓN DE RELA- CIONES CON CLIENTES CÓDIGO ESPECIALIDAD C.P. PRESEN- CIALES TELEFORMA- CIÓN TOTALES

Más detalles

Plataforma Tecnológica Qué es Marino Imagine? La integración de los requerimientos de sistemas informáticos en la determinados sectores. infraestructura de la empresa ha sucedido de forma Sus carencias

Más detalles

MANUAL DE ORGANIZACIÓN Y FUNCIONES GERENCIA DE INFORMÁTICA

MANUAL DE ORGANIZACIÓN Y FUNCIONES GERENCIA DE INFORMÁTICA MANUAL DE ORGANIZACIÓN Y FUNCIONES GERENCIA DE INFORMÁTICA Aprobando mediante Resolución de Gerencia General N 052-2015 de fecha 26 Junio 2015 ELABORADO POR: APROBADO POR: 1 de 82 ÍNDICE 1 INTRODUCCIÓN...

Más detalles

Guía de Seguridad 5.9

Guía de Seguridad 5.9 Guía de Seguridad 5.9 Documentación para solicitar la autorización e inscripción de empresas de venta y asistencia técnica de equipos de rayos X Madrid, 18 de marzo de 1998 SN CONSEJO DE SEGURIDAD NUCLEAR

Más detalles

Conexión de Empresas Colaboradoras a la red de EDP en España

Conexión de Empresas Colaboradoras a la red de EDP en España Histórico Versión Fecha Elaborado por 1 28/09/2015 Gonzaga de la Sota Aprobación Este documento está aprobado por: Nombre Área Fecha Clasificación del documento 1 Pública Reservada Confidencial Secreta

Más detalles

información proporcionada por el AEMET y la Red de Alerta Radiológica perteneciente a Protección Civil (RAR).

información proporcionada por el AEMET y la Red de Alerta Radiológica perteneciente a Protección Civil (RAR). El Consejo de Seguridad Nuclear (CSN), es el organismo nacional competente en materias de seguridad nuclear y protección radiológica. Entre las funciones más representativas se destacan el control y vigilancia

Más detalles

REPORTE OFICIAL OCTUBRE DE 2014. CA Unified Infrastructure Management para servidores

REPORTE OFICIAL OCTUBRE DE 2014. CA Unified Infrastructure Management para servidores REPORTE OFICIAL OCTUBRE DE 2014 CA Unified Infrastructure Management para servidores 2 Reporte oficial: CA Unified Infrastructure Management para servidores Tabla de contenidos Descripción general de la

Más detalles

CUALIFICACIÓN OPERACIÓN DE REDES DEPARTAMENTALES PROFESIONAL. Nivel 2. Versión 5 Situación RD 1201/2007 Actualización

CUALIFICACIÓN OPERACIÓN DE REDES DEPARTAMENTALES PROFESIONAL. Nivel 2. Versión 5 Situación RD 1201/2007 Actualización Página 1 de 16 CUALIFICACIÓN OPERACIÓN DE REDES DEPARTAMENTALES PROFESIONAL Familia Profesional Informática y Comunicaciones Nivel 2 Código IFC299_2 Versión 5 Situación RD 1201/2007 Actualización Competencia

Más detalles

ALCANCE DE LOS SERVICIOS Y PLIEGO DE PRESCRIPCIONES TÉCNICAS

ALCANCE DE LOS SERVICIOS Y PLIEGO DE PRESCRIPCIONES TÉCNICAS ALCANCE DE LOS SERVICIOS Y PLIEGO DE PRESCRIPCIONES TÉCNICAS DISEÑO, DESARROLLO, IMPLANTACIÓN Y MANTENIMIENTO DE UNA PLATAFORMA INFORMÁTICA PARA LA ReTBioH I. OBJETO El objeto del presente pliego lo constituye

Más detalles

CAPITULO VI: ADMINISTRACIÓN DEL PROYECTO. 6.1. Estructura Detallada del Trabajo (EDT)

CAPITULO VI: ADMINISTRACIÓN DEL PROYECTO. 6.1. Estructura Detallada del Trabajo (EDT) CAPITULO VI: ADMINISTRACIÓN DEL PROYECTO 6.1. Estructura Detallada del Trabajo (EDT) Un EDT es la agrupación orientada a entregables de los elementos del proyecto que organiza y define el total de los

Más detalles

ADMINISTRACIÓN Y PROGRAMACIÓN EN SISTEMAS DE PLANIFICACIÓN DE RECURSOS EMPRESARIALES Y DE GESTIÓN DE RELACIONES CON CLIENTES CUALIFICACIÓN PROFESIONAL

ADMINISTRACIÓN Y PROGRAMACIÓN EN SISTEMAS DE PLANIFICACIÓN DE RECURSOS EMPRESARIALES Y DE GESTIÓN DE RELACIONES CON CLIENTES CUALIFICACIÓN PROFESIONAL Página 1 de 23 CUALIFICACIÓN PROFESIONAL Familia Profesional Nivel 3 Código IFC363_3 Versión 5 Situación RD 1701/2007 Actualización ADMINISTRACIÓN Y PROGRAMACIÓN EN SISTEMAS DE PLANIFICACIÓN DE RECURSOS

Más detalles

12 JUNIO 2014. Rev.1: 07 Agosto 2014 Rev.2: 06 Octubre 2014 Rev.3: 05 Marzo 2015. 1 de 76. BN-MOF-2400-10-05 Rev.3 MOF DEPARTAMENTO DE INFORMÁTICA

12 JUNIO 2014. Rev.1: 07 Agosto 2014 Rev.2: 06 Octubre 2014 Rev.3: 05 Marzo 2015. 1 de 76. BN-MOF-2400-10-05 Rev.3 MOF DEPARTAMENTO DE INFORMÁTICA Rev.1: 07 Agosto 2014 Rev.2: 06 Octubre 2014 : 05 Marzo 2015 MANUAL DE ORGANIZACIÓN Y FUNCIONES DEPARTAMENTO DE INFORMÁTICA Aprobado mediante Resolución de Gerencia General EF/92.2000 N 020-2014, de fecha

Más detalles

PROCESO GESTIÓN DE TECNOLOGÍA E INFORMÁTICA

PROCESO GESTIÓN DE TECNOLOGÍA E INFORMÁTICA VERSIÓN:3 PAGINA 1 DE 22 VERSIÓN:3 PAGINA 2 DE 22 CONTENIDO PAG 1. CARACTERIZACIÓN DEL PROCESO... 4 1.1 Nombre del Proceso... 4 1.2 Nivel del Proceso... 4 1.3 Normatividad... 4 2. OBJETIVO... 5 3. ALCANCE...

Más detalles

BOLETÍN OFICIAL DEL ESTADO

BOLETÍN OFICIAL DEL ESTADO Núm. 300 Miércoles 14 de diciembre de 2011 Sec. I. Pág. 135721 No debe interpretarse que los diversos espacios formativos identificados deban diferenciarse necesariamente mediante cerramientos. Las instalaciones

Más detalles

Operación de aceleradores lineales de uso médico

Operación de aceleradores lineales de uso médico Autoridad Regulatoria Nuclear DEPENDIENTE DE LA PRESIDENCIA DE LA NACION AR 8.2.2. Operación de aceleradores lineales de uso médico REVISIÓN 1 Aprobada por Resolución del Directorio de la Autoridad Regulatoria

Más detalles

LOOKWISE ENTERPRISE MANAGER NOVEDADES RELEASE 5.1

LOOKWISE ENTERPRISE MANAGER NOVEDADES RELEASE 5.1 LOOKWISE ENTERPRISE MANAGER NOVEDADES RELEASE 5.1 LOOKWISE ENTERPRISE MANAGER NOVEDADES RELEASE 5.1 página 2 de 17 S21sec - Pamplona, 2015 La información facilitada en este documento es propiedad de S21sec,

Más detalles

mope SEGURIDAD INFORMÁTICA

mope SEGURIDAD INFORMÁTICA DENOMINACIÓN: Código: IFCT0109 Familia Profesional: Informática y Comunicaciones Área profesional: Sistemas y telemática Nivel de cualificación profesional: 3 Cualificación profesional de referencia: IFC153_3

Más detalles

plataforma gest.org Multi Gestión de Organizaciones Fundaciones y Asociaciones

plataforma gest.org Multi Gestión de Organizaciones Fundaciones y Asociaciones plataforma gest.org Multi Gestión de Organizaciones Fundaciones y Asociaciones ÍNDICE 1. INTRODUCCIÓN. PRESENTACIÓN DEL PRODUCTO Software como Servicio Características técnicas 2. ALCANCE FUNCIONAL DE

Más detalles

VISIÓN GENERAL HERRAMIENTAS COMERCIALES

VISIÓN GENERAL HERRAMIENTAS COMERCIALES VISIÓN GENERAL El servidor de MS SQL se ha convertido en un estándar en muchas partes de la América corporativa. Puede manejar volúmenes de datos grandes y se integra bien con otros productos de Microsoft.

Más detalles

ESPECIALIDAD: GENERAL PRÁCTICAS

ESPECIALIDAD: GENERAL PRÁCTICAS Curso de PR para OPERAR en instalaciones de Rayos X con fines de diagnóstico médico (IRD) ESPECIALIDAD: GENERAL PRÁCTICAS PRÁCTICA 1 DESCRIPCION Y MANEJO DE MONITORES DE RADIACIÓN Y DOSÍMETROS PERSONALES

Más detalles

TABLA DE CONTENIDO 1. REQUERIMIENTOS NO FUNCIONALES... 2

TABLA DE CONTENIDO 1. REQUERIMIENTOS NO FUNCIONALES... 2 TABLA DE CONTENIDO Pág. 1. REQUERIMIENTOS NO FUNCIONALES... 2 1.1 ATRIBUTOS DE CALIDAD DEL SISTEMA... 2 1.2 OTROS REQUERIMIENTOS NO FUNCIONALES... 4 1.3 REQUERIMIENTOS NO FUNCIONALES PARA HERRAMIENTAS

Más detalles

LINEAMIENTOS GENERALES PARA LA IMPLEMENTACIÓN DE PROCESOS ELECTRÓNICOS

LINEAMIENTOS GENERALES PARA LA IMPLEMENTACIÓN DE PROCESOS ELECTRÓNICOS LINEAMIENTOS GENERALES PARA LA IMPLEMENTACIÓN DE PROCESOS LINEAMIENTOS GENERALES PARA LA IMPLEMENTACIÓN DE PROCESOS Ministerio de Tecnologías de la Información y las Comunicaciones Programa de Gobierno

Más detalles

Agrupamiento Familia Puesto Alcance del puesto Requisitos excluyentes

Agrupamiento Familia Puesto Alcance del puesto Requisitos excluyentes TIC-1-1 Analista de monitoreo de redes Monitorear y controlar las redes del GCABA con el fin de detectar incidentes y reportarlos. Analizar las métricas utilizadas para el monitoreo de la red, la configuración

Más detalles

CAPÍTULO V PROPUESTA DE LA SOLUCIÓN

CAPÍTULO V PROPUESTA DE LA SOLUCIÓN CAPÍTULO V PROPUESTA DE LA SOLUCIÓN 5.1 Introducción En los últimos tres años la entidad financiera ha venido sufriendo cambios que le han permitido crecer y pasar de ser una Sociedad Financiera a un Banco

Más detalles

PLIEGO DE PRESCRIPCIONES TECNICAS

PLIEGO DE PRESCRIPCIONES TECNICAS PLIEGO DE PRESCRIPCIONES TECNICAS TITULO: SERVICIO DE SOPORTE A USUARIOS DEL SISTEMA BAS CLAVE: INF.05.020 Expediente nº INF.05.020 Página 1 de 10 1 INTRODUCCIÓN Y ANTECEDENTES La Empresa Pública de Puertos

Más detalles

Ficha Técnica. effidetect

Ficha Técnica. effidetect Ficha Técnica effidetect Página 1 de 9 Introducción El Sistema Pointer es un producto de Predisoft (www.predisoft.com) cuyo propósito es la detección (en línea) del fraude que sufren las instituciones

Más detalles

CUALIFICACIÓN SISTEMAS DE GESTIÓN DE INFORMACIÓN PROFESIONAL. Nivel 3. Versión 5 Situación RD 1201/2007 Actualización

CUALIFICACIÓN SISTEMAS DE GESTIÓN DE INFORMACIÓN PROFESIONAL. Nivel 3. Versión 5 Situación RD 1201/2007 Actualización Página 1 de 16 CUALIFICACIÓN SISTEMAS DE GESTIÓN DE INFORMACIÓN PROFESIONAL Familia Profesional Informática y Comunicaciones Nivel 3 Código IFC304_3 Versión 5 Situación RD 1201/2007 Actualización Competencia

Más detalles

Técnico Especialista TIC en Gestión y la Monitorización de Incidencias de los Sistemas Físicos y del Software Informático

Técnico Especialista TIC en Gestión y la Monitorización de Incidencias de los Sistemas Físicos y del Software Informático Técnico Especialista TIC en Gestión y la Monitorización de Incidencias de los Sistemas Físicos y Titulación certificada por EUROINNOVA BUSINESS SCHOOL Técnico Especialista TIC en Gestión y la Monitorización

Más detalles

Grado en Ingeniería Informática

Grado en Ingeniería Informática Grado en Ingeniería Informática Competencias Generales y trasversales De acuerdo con la resolución del Consejo de Universidades de fecha 3 de marzo de 2009, para obtener este título de grado en ingeniería

Más detalles

SEGUNDA ESPECIALIZACIÓN PROFESIONAL EN PROTECCIÓN RADIOLÓGICA. Convenio IPEN UNI

SEGUNDA ESPECIALIZACIÓN PROFESIONAL EN PROTECCIÓN RADIOLÓGICA. Convenio IPEN UNI SEGUNDA ESPECIALIZACIÓN PROFESIONAL EN PROTECCIÓN RADIOLÓGICA Convenio IPEN UNI INTRODUCCIÓN La Universidad Nacional de Ingeniería, ofrece a través de la Facultad de Ciencias, la Segunda Especialización

Más detalles

ESCUELA POLITÉCNICA DEL EJÉRCITO DEPARTAMENTO DE ELÉCTRICA Y ELECTRÓNICA. Sr. Daniel Cadena M. Sr. Luis Romero S. RESUMEN

ESCUELA POLITÉCNICA DEL EJÉRCITO DEPARTAMENTO DE ELÉCTRICA Y ELECTRÓNICA. Sr. Daniel Cadena M. Sr. Luis Romero S. RESUMEN Diseño e implementación de un sistema de control e inventario electrónico a través de la internet basado en la tecnología RFID para los laboratorios del DEEE-ESPE ESCUELA POLITÉCNICA DEL EJÉRCITO DEPARTAMENTO

Más detalles

Índice Introducción... 2 Metodología... 3 Gestión de solicitudes y parque informático...3 Centro de Atención al Usuario...3 Funcionamiento...

Índice Introducción... 2 Metodología... 3 Gestión de solicitudes y parque informático...3 Centro de Atención al Usuario...3 Funcionamiento... Índice Introducción... 2 Metodología... 3 Gestión de solicitudes y parque informático...3 Centro de Atención al Usuario...3 Funcionamiento...3 Soporte Aplicado y Preventivo...4 Plan de actividades...5

Más detalles

Diseño e implementación de un sistema de información basado en Servicios Web para la gestión de ofertas de empleo y candidatos ANEXOS

Diseño e implementación de un sistema de información basado en Servicios Web para la gestión de ofertas de empleo y candidatos ANEXOS Proyecto Fin de Carrera Ingeniería Informática Diseño e implementación de un sistema de información basado en Servicios Web para la gestión de ofertas de empleo y candidatos ANEXOS Autor: Mariola Valiente

Más detalles

CONFIGURACIÓN Y DESARROLLO

CONFIGURACIÓN Y DESARROLLO CONFIGURACIÓN Y DESARROLLO Beneficios Permite controlar con eficiencia el rendimiento. SQL Server 2005 brinda a los administradores de Microsoft Dynamics GP herramientas de control automatizadas y mejoradas

Más detalles

Introducción ÍNDICE INTRODUCCIÓN...1 APORTACIONES DE MÉTRICA VERSIÓN 3...2

Introducción ÍNDICE INTRODUCCIÓN...1 APORTACIONES DE MÉTRICA VERSIÓN 3...2 Introducción ÍNDICE INTRODUCCIÓN...1 APORTACIONES DE MÉTRICA VERSIÓN 3...2 PROCESOS PRINCIPALES DE MÉTRICA VERSIÓN 3...3 PLANIFICACIÓN DE SISTEMAS DE INFORMACIÓN (PSI)...4 DESARROLLO DE SISTEMAS DE INFORMACIÓN...5

Más detalles

ADMINISTRACIÓN DE SISTEMAS INFORMÁTICOS

ADMINISTRACIÓN DE SISTEMAS INFORMÁTICOS CUALIFICACIÓN PROFESIONAL ADMINISTRACIÓN DE SISTEMAS INFORMÁTICOS NIVEL DE CUALIFICACIÓN: 3 ÁREA COMPETENCIAL: INFORMATICA ÍNDICE 1. ESPECIFICACIÓN DE COMPETENCIA...3 1.1. COMPETENCIA GENERAL...3 1.2.

Más detalles

Monitoreo de red. Inventario de hardware y software. Monitoreo actividad del usuario. Soporte a usuarios. Protección contra fuga de datos.

Monitoreo de red. Inventario de hardware y software. Monitoreo actividad del usuario. Soporte a usuarios. Protección contra fuga de datos. nvision Es una solución modular que permite gestionar la red, llevar el control y cumplimiento de licencias inventario de hardware y software de equipos Windows, monitorear la actividad que realizan diariamente

Más detalles

SISTEMA DE INFORMACIÓN PARA LA PRESTACIÓN ASISTENCIAL DENTAL

SISTEMA DE INFORMACIÓN PARA LA PRESTACIÓN ASISTENCIAL DENTAL SISTEMA DE INFORMACIÓN PARA LA PRESTACIÓN ASISTENCIAL DENTAL Adjunta al Jefe de Informática Consejería de Salud Consultor DMR Consulting Palabras clave SIPAD, prestación asistencial dental, historia de

Más detalles

Sistemas de Informacion Radiologica

Sistemas de Informacion Radiologica 1 Sistemas de Informacion Radiologica Facultad: Ingeniería. Escuela: Biomédica Asignatura: Digitalización de Información en Servicios Médicos Objetivos Conocer los componentes que conforman un Sistema

Más detalles

Especificación de la secuencia de mensajes que se han de intercambiar. Especificación del formato de los datos en los mensajes.

Especificación de la secuencia de mensajes que se han de intercambiar. Especificación del formato de los datos en los mensajes. SISTEMAS DISTRIBUIDOS DE REDES 2.- MODELOS ORIENTADOS A OBJETOS DISTRIBUIDOS 2.1. Tecnologías de sistemas distribuidos Para la implementación de sistemas distribuidos se requiere de tener bien identificados

Más detalles

ISO 9001,9002,9003,9004

ISO 9001,9002,9003,9004 Capitulo 06 ISO 9001,9002,9003,9004 Que es ISO 9001? Es una de las normas para la gestión y el aseguramiento de la calidad. Esta norma forma parte de un conjunto de tres normas sobre los sistemas de la

Más detalles

Nomenclador de cargos

Nomenclador de cargos Nomenclador de cargos ROLES Áreas de I T Definición de módulos y roles Versión: 1.0 Pagina 1 Módulos interactuantes en un área de IT 1. Infraestructura Tecnológica 2. Producción de Software 3. Asistencia

Más detalles

CAPITULO V. IMPLEMENTACIÓN DE UNA HERRAMIENTA INTEGRADA DE RED

CAPITULO V. IMPLEMENTACIÓN DE UNA HERRAMIENTA INTEGRADA DE RED CAPITULO V. IMPLEMENTACIÓN DE UNA HERRAMIENTA INTEGRADA DE RED En el presente capitulo se presenta una aplicación que aborda una herramienta de monitoreo de redes para soportar estudios de disponibilidad.

Más detalles

PLAN DE ESTUDIOS Y CONTENIDOS MÍNIMOS

PLAN DE ESTUDIOS Y CONTENIDOS MÍNIMOS CARRERAS DE DOS AÑOS TECNICATURA EN PROGRAMACIÓN DE COMPUTADORAS PLAN DE ESTUDIOS Y CONTENIDOS MÍNIMOS Resolución UB 004/14 ANEXO Tabla general de asignaturas del Plan de Estudios y Obligaciones Académicas

Más detalles

MF1220_3 Implantación y Mantenimiento de Sistemas de Control de Accesos y Presencia y de Videovigilancia (Online)

MF1220_3 Implantación y Mantenimiento de Sistemas de Control de Accesos y Presencia y de Videovigilancia (Online) MF1220_3 Implantación y Mantenimiento de Sistemas de Control de Accesos y Presencia y de TITULACIÓN DE FORMACIÓN CONTINUA BONIFICADA EXPEDIDA POR EL INSTITUTO EUROPEO DE ESTUDIOS EMPRESARIALES MF1220_3

Más detalles

Catálogo de Servicios

Catálogo de Servicios Catálogo de Servicios Fecha: 14 de mayo de 2013 Índice 1 Presentación... 3 2 Servicios de Consultoría SQL Server... 4 2.1 Monitorización servidores SQL Server... 4 2.2 DBA Remoto... 5 2.3 Consolidación

Más detalles

Carlos Araujo Herrera 1, Vicente Jama Lozano 2. Litoral, Profesor de ESPOL desde 2001.

Carlos Araujo Herrera 1, Vicente Jama Lozano 2. Litoral, Profesor de ESPOL desde 2001. DESARROLLO E IMPLANTACIÓN DE UN SISTEMA DE INFORMACIÓN ORIENTADO HACIA EL CONTROL DE CALIDAD DE PROVEEDORES PARA PLANTAS INDUSTRIALES EN LA CIUDAD DE GUAYAQUIL Carlos Araujo Herrera 1, Vicente Jama Lozano

Más detalles

Aplicaciones Web que Permitan Administrar Portafolios para Gestionar el Aprendizaje

Aplicaciones Web que Permitan Administrar Portafolios para Gestionar el Aprendizaje Escuela Universitaria de Ingeniería Industrial, Informática y Sistemas Área de Computación e Informática Universidad Tarapacá Arica Aplicaciones Web que Permitan Administrar Portafolios para Gestionar

Más detalles

SISTEMA INTEGRAL DE COMUNICACIÓN, CONTROL Y SEGUIMIENTO DE LA VIGILANCIA EPIDEMIOLÓGICA FITOSANITARIA

SISTEMA INTEGRAL DE COMUNICACIÓN, CONTROL Y SEGUIMIENTO DE LA VIGILANCIA EPIDEMIOLÓGICA FITOSANITARIA SISTEMA INTEGRAL DE COMUNICACIÓN, CONTROL Y SEGUIMIENTO DE LA VIGILANCIA EPIDEMIOLÓGICA FITOSANITARIA INTRODUCCIÓN El Centro nacional de Referencia Fitosanitaria (CNRF) hace uso de solicitudes, es decir,

Más detalles

M A N UA L D E U S UA R I O

M A N UA L D E U S UA R I O M A N UA L D E U S UA R I O S I S T E M A A D M I N I S T R AC I Ó N D E C O R R E S P O N D E N C I A V E R S I Ó N 3. 5 (S AC) MAYO 2013 Dirigido a: Elaboró: Personal que recibe y da seguimiento a documentos

Más detalles

Historial de Revisiones

Historial de Revisiones Página: 1 Especificación de Requerimientos de Software Plataforma Libre Orientada a Servicios para la Gestión de Trámites a través de Gobierno Electrónico (Actualización FASE I) Historial de Revisiones

Más detalles

IFCT0610 Administración y Programación en Sistemas de Planificación de Recursos Empresariales y de Gestión de Relaciones con Clientes (Online)

IFCT0610 Administración y Programación en Sistemas de Planificación de Recursos Empresariales y de Gestión de Relaciones con Clientes (Online) IFCT0610 Administración y Programación en Sistemas de Planificación de Recursos Empresariales y de Gestión de Relaciones con Clientes (Online) (Dirigida a la Acreditación de las Titulación certificada

Más detalles

ELEMENTO I INTRODUCCION A LOS SISTEMAS DE BASES DE DATOS

ELEMENTO I INTRODUCCION A LOS SISTEMAS DE BASES DE DATOS Base de Datos ELEMENTO I INTRODUCCION A LOS SISTEMAS DE BASES DE DATOS Una base de datos es un conjunto de elementos de datos que se describe a sí mismo, con relaciones entre esos elementos, que presenta

Más detalles

ASUNTO: MODIFICACIÓN DE LA AUTORIZACIÓN DE LA UNIDAD TÉCNICA DE PROTECCIÓN RADIOLÓGICA DE GEOTECNIA Y CIMIENTOS, S.A. (GEOCISA).

ASUNTO: MODIFICACIÓN DE LA AUTORIZACIÓN DE LA UNIDAD TÉCNICA DE PROTECCIÓN RADIOLÓGICA DE GEOTECNIA Y CIMIENTOS, S.A. (GEOCISA). CSN/MO-1/UTPR/M-0011/11 RA Madrid, 28 de julio de 2011 Version web Geotecnia y Cimientos, S.A. GEOCISA (UTPR) C/ ::::::::::::::: 28820- Coslada (MADRID) Att. D. ::::::::::::::::::::: Director Técnico ASUNTO:

Más detalles

computadoras que tienen este servicio instalado se pueden publicar páginas web tanto local como remotamente.

computadoras que tienen este servicio instalado se pueden publicar páginas web tanto local como remotamente. Investigar Qué es un IIS? Internet Information Services o IIS es un servidor web y un conjunto de servicios para el sistema operativo Microsoft Windows. Originalmente era parte del Option Pack para Windows

Más detalles

Arquitectura Empresarial. Ministerio de Salud

Arquitectura Empresarial. Ministerio de Salud Arquitectura Empresarial Ministerio de Salud Arquitectura de TI - Arquitectura de Aplicaciones Versión 1.1 Versión 1.1 Página: 1 of 34 Tabla de Contenido 1. INTRODUCCIÓN... 3 2. ARQUITECTURA DE APLICACIONES...

Más detalles

CA Nimsoft Monitor para servidores

CA Nimsoft Monitor para servidores INFORME OFICIAL Septiembre de 2012 CA Nimsoft Monitor para servidores agility made possible CA Nimsoft for Server Monitoring tabla de contenido para servidores: 3 descripción general de la solución Monitoreo

Más detalles

Consultoría y Desarrollo de Sistemas CONTROLMAP. Software : Sistema Integral de Registro y Seguimiento de Eventos e Incidencias en Mapas Digitales

Consultoría y Desarrollo de Sistemas CONTROLMAP. Software : Sistema Integral de Registro y Seguimiento de Eventos e Incidencias en Mapas Digitales 1 Software : CONTROLMAP Sistema Integral de Registro y Seguimiento de Eventos e Incidencias en Mapas Digitales Característica Generales 2 ControlMap permite el registro y seguimiento de incidencia o eventos

Más detalles

INFORMATICA MARFER S.L

INFORMATICA MARFER S.L Solución para tus planes de contingencia y continuidad de negocio Copias de seguridad remotas vía Internet de grandes volúmenes de información Backup remoto es un software multiplataforma de alto rendimiento

Más detalles

BASES DE DATOS. 1.1 Funciones de un DBMS

BASES DE DATOS. 1.1 Funciones de un DBMS BASES DE DATOS Un DBMS, son programas denominados Sistemas Gestores de Base de Datos, abreviado SGBD, en inglés Data Base Management System (DBMS) que permiten almacenar y posteriormente acceder a los

Más detalles

PROTECCIÓN RADIOLÓGICA EN LA APLICACIÓN DE LAS TÉCNICAS NUCLEARES COLECTIVO DE AUTORES

PROTECCIÓN RADIOLÓGICA EN LA APLICACIÓN DE LAS TÉCNICAS NUCLEARES COLECTIVO DE AUTORES PROTECCIÓN RADIOLÓGICA EN LA APLICACIÓN DE LAS TÉCNICAS NUCLEARES COLECTIVO DE AUTORES CENTRO DE PROTECCIÓN E HIGIENE DE LAS RADIACIONES CENTRO NACIONAL DE SEGURIDAD NUCLEAR La Habana, Cuba 2002 Colectivo

Más detalles

Características de Advanced Product 7.0 (Access 2003): y SQL

Características de Advanced Product 7.0 (Access 2003): y SQL C/ Ventura Plaja, 4 Local 2 08028 Barcelona Tel. 902157584 / 93 274 28 19 Fax.93 274 23 99 E-mail: comercial@ apsys.es www.apsys.es Advanced Product Características de Advanced Product 7.0 (Access 2003):

Más detalles

BOLETÍN OFICIAL DEL ESTADO MINISTERIO DE EDUCACIÓN

BOLETÍN OFICIAL DEL ESTADO MINISTERIO DE EDUCACIÓN Núm. 187 Martes 4 de agosto de 2009 Sec. III. Pág. 66699 III. OTRAS DISPOSICIONES MINISTERIO DE EDUCACIÓN 12977 Resolución de 8 de junio de 2009, de la Secretaría General de Universidades, por la que se

Más detalles

C O N T E N I D O. 1. Propósito. 2. Alcance. 3. Responsabilidad y autoridad. 4. Normatividad aplicable. 5. Políticas

C O N T E N I D O. 1. Propósito. 2. Alcance. 3. Responsabilidad y autoridad. 4. Normatividad aplicable. 5. Políticas C O N T E N I D O 1. Propósito 2. Alcance 3. Responsabilidad autoridad 4. Normatividad aplicable 5. Políticas 6. Diagrama de bloque procedimiento 7. Glosario 8. Anexos 9. Revisión Histórica 1/12 1. Propósito

Más detalles

Denominación de la materia. N créditos ECTS = 36 carácter = OBLIGATORIO SISTEMAS DE SOFTWARE. Ubicación dentro del plan de estudios y duración

Denominación de la materia. N créditos ECTS = 36 carácter = OBLIGATORIO SISTEMAS DE SOFTWARE. Ubicación dentro del plan de estudios y duración Denominación de la materia SISTEMAS DE SOFTWARE N créditos ECTS = 36 carácter = OBLIGATORIO Ubicación dentro del plan de estudios y duración La materia Sistemas de Software está formada por 6 asignaturas

Más detalles

Técnico Especialista TIC en Administración de CRM: Recursos Empresariales y de Gestión de Relaciones con Clientes

Técnico Especialista TIC en Administración de CRM: Recursos Empresariales y de Gestión de Relaciones con Clientes Técnico Especialista TIC en Administración de CRM: Recursos Empresariales y de Gestión de TITULACIÓN DE FORMACIÓN CONTINUA BONIFICADA EXPEDIDA POR EL INSTITUTO EUROPEO DE ESTUDIOS EMPRESARIALES Técnico

Más detalles

Uso de los Servicios Web en la nueva arquitectura de N-Capas del Sistema Económico Integral Rodas XXI.

Uso de los Servicios Web en la nueva arquitectura de N-Capas del Sistema Económico Integral Rodas XXI. Ponencia para Evento de Redes. Autor: Rubén Rivera Rodríguez, Citmatel Resumen Uso de los Servicios Web en la nueva arquitectura de N-Capas del Sistema Económico Integral Rodas XXI. Las nuevas tendencias

Más detalles

Hospital Nacional de Maternidad UNIDAD DE INFORMATICA

Hospital Nacional de Maternidad UNIDAD DE INFORMATICA Hospital Nacional de Maternidad UNIDAD DE INFORMATICA 87 Introducción Página: I INTRODUCCION Para el propósito de este manual el Hospital Nacional de Maternidad puede ser referido también como El Hospital,

Más detalles

CONTROLE SU INFORMACIÓN ANTES DE QUE ELLA LE CONTROLE A USTED

CONTROLE SU INFORMACIÓN ANTES DE QUE ELLA LE CONTROLE A USTED CONTROLE SU INFORMACIÓN ANTES DE QUE ELLA LE CONTROLE A USTED Gestión integrada de documentos y procesos La gestión documental es un proceso esencial para el correcto desempeño de una empresa, siendo a

Más detalles

Con la interacción de tus empleados mejorará la productividad de tu negocio

Con la interacción de tus empleados mejorará la productividad de tu negocio 1. Introducción Con la interacción de tus empleados mejorará la productividad de tu negocio Los empleados de cualquier compañía precisan numerosos accesos en su trabajo diario, además de interaccionar

Más detalles

Mantenimiento de Sistemas de Información

Mantenimiento de Sistemas de Información de Sistemas de Información ÍNDICE DESCRIPCIÓN Y OBJETIVOS... 1 ACTIVIDAD MSI 1: REGISTRO DE LA PETICIÓN...4 Tarea MSI 1.1: Registro de la Petición... 4 Tarea MSI 1.2: Asignación de la Petición... 5 ACTIVIDAD

Más detalles

Gestión de Redes IP. Presentación realizada por: Ing. Pablo Borrelli. Gestión de Redes IP 1

Gestión de Redes IP. Presentación realizada por: Ing. Pablo Borrelli. Gestión de Redes IP 1 Gestión de Redes IP Lugar: Sala de I.T.I. (Instituto Tecnológico de Informática) Presentación realizada por: Ing. Pablo Borrelli Gestión de Redes IP 1 Presentación e introducción. Gestión de la Red de

Más detalles

UNIVERSIDAD ALBERT EINSTEIN FACULTAD DE INGENIERIA

UNIVERSIDAD ALBERT EINSTEIN FACULTAD DE INGENIERIA UNIVERSIDAD ALBERT EINSTEIN FACULTAD DE INGENIERIA Estudio de las herramientas TOAD y DBArtisan para la administración e integración de bases de datos relacionales. PREVIA OPCION AL TÍTULO DE: INGENIERO

Más detalles