Autorizada la entrega del proyecto al alumno: FRANCISCO JOSÉ VALDIVIESO RUIZ EL DIRECTOR DEL PROYECTO ALBERTO GARCÍA PAÑOSO. Fecha:... /... /...

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

Download "Autorizada la entrega del proyecto al alumno: FRANCISCO JOSÉ VALDIVIESO RUIZ EL DIRECTOR DEL PROYECTO ALBERTO GARCÍA PAÑOSO. Fecha:... /... /..."

Transcripción

1 Autorizada la entrega del proyecto al alumno: FRANCISCO JOSÉ VALDIVIESO RUIZ EL DIRECTOR DEL PROYECTO ALBERTO GARCÍA PAÑOSO Fdo:... Fecha:... /... /... Vº Bº del Coordinador de Proyectos EDUARDO ALCALDE LANCHARRO Fdo:... Fecha:... /... /...

2 UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO TÉCNICO EN INFORMÁTICA DE GESTIÓN PROYECTO FIN DE CARRERA AUTOMATIZACIÓN, OPTIMIZACIÓN E IMPLEMENTACIÓN DE SISTEMAS DE DIAGNÓSTICO HOSPITALARIOS AUTOR: FRANCISCO JOSÉ VALDIVIESO RUIZ MADRID, SEPTIEMBRE DE 2009

3 Agradecimientos En especial, quiero agradecer a mi padre, mi madre y mis hermanos el apoyo que he recibido por su parte, durante este largo camino. De la misma forma, me gustaría hacer mención a todo el equipo de trabajo de SATEC, en especial a Alberto, ya que sin él, este proyecto no hubiese sido posible, agradeciéndole toda la ayuda y lo aprendido de su trabajo. I

4 Resumen El proyecto que se presenta a continuación, acomete de una forma simplificada todos los procesos necesarios en la automatización y optimización de un tratamiento oncológico. Estos tratamientos son procesos muy complejos que requieren una unificación de diversos y distintos factores, que deben trabajar de una forma conjunta para su correcto funcionamiento. Por ello, se considera necesaria la creación de un sistema que ayude a gestionar todo este modelo de trabajo y que sirva de herramienta de apoyo para todo este conjunto de personas y sistemas que forman parte de él. Este proyecto abordará no sólo la creación e identificación de estos procesos, sino que concluirá con la automatización de estos. De esta forma se conseguirá un sistema que automáticamente genere y trate la información del proceso de radioterapia, prestando un servicio nuevo y coordinado a todos sus usuarios. El núcleo del sistema son procesos de negocio (en este caso el negocio es el tratamiento oncológico), que se diseñarán y ejecutarán con una Suite BPM de libre distribución. Puesto que el uso de estos procesos desde los interfaces que proporciona el fabricante del producto puede ser incómodo para el usuario final, se decide crear un interfaz Web que facilite dicho uso. Por tanto, el sistema se plantea como una aplicación Web que reside en un servidor y que, a través de servicios Web, utilizará los procesos de negocio previamente creados. Debido a la complejidad del entorno, será necesario simular ciertos subsistemas. En un caso real, un hospital ya contaría con su sistema hospitalario, pero en este caso se simulará mediante una comunicación basada en el estándar HL7, que facilitará esta comunicación entre cualquier sistema clínico y este desarrollo. II

5 Otro problema se plantea en los dispositivos con los que cuenta la unidad de oncología de un hospital real. Puesto que no se dispone de esos dispositivos se tendrán que simular de una forma sencilla. Dado que todo el proceso esta basado en un tratamiento oncológico, se requiere un sistema capaz de visualizar las distintas imágenes necesarias para su correcto diagnóstico. Para ello, se utilizará una aplicación basada en un applet Java que permitirá visualizar tanto las imágenes como los datos asociados a cada una de estas imágenes. Esta aplicación estará accesible en cualquier punto a lo largo del proceso ya que la funcionalidad de este visualizador se considera necesaria en cualquiera de los pasos del proceso. Finalmente, se desarrollará un monitor que permitirá el seguimiento de cada uno de los tratamientos a través de registros creados en base a los pasos que se irán realizando en cada tarea. De esta forma se podrá controlar, de una forma sencilla, en que punto se encuentra cada uno de los tratamientos generados. III

6 Abstract The project to be presented below, undertake from a simplified way, all the necessary processes in the automation and optimization of a cancer treatment. These treatments are very complex processes that require the unification of several and diferents factors, which must work all jointly, for the correct functioning. Therefore, it is considered necessary to create a system that helps to manage all this model of work and to serve as tool of support for all the entire set of people and systems that are part of it. This project will deal with not only the creation and identification of these processes, by the same way it will conclude with the automation of them. By this way, will be achieved a system that automatically generate and discuss the information of the process of radiation, providing a new service coordinated with all its users. Since the use of these processes from the interfaces that provides the product manufacturer, can be uncomfortable for the end user, the decision is to create a Web interface to facilitate such use. Therefore, the system arises as a Web application that resides in a server, and that, through Web services, will use the business processes previously created. Because of the complexity of the environment, it will be necessary simulate certain subsystems. In a real case, a hospital already would have its hospital system, but in this case is simulated in a communication based on the standard HL7, which will facilitate this communication between any clinical system and this development. Given that the entire process is based on a cancer treatment, requires a system capable of displaying the different images necessary for its proper diagnosis. To that end, will be used an application based on a Java applet that will allow display both images as the data associated with each of these images. This application will be IV

7 accessible at any point along the process since the functionality of this display is considered necessary. Finally, develop a monitor that will allow the follow-up to each of the treatments through records created on the basis of steps that will be carried out in each task. In this way, it can control, in a simple way, in which point is each one of the treatments generated. V

8 ÍNDICE DE CONTENIDO 1.INTRODUCCIÓN MOTIVACIÓN DEL PROYECTO METODOLOGÍA DE DESARROLLO EXPLICACIÓN DEL DOCUMENTO IDENTIFICACIÓN DE NECESIDADES OBJETIVOS DEL SISTEMA ALCANCE DEL SISTEMA TIPOLOGÍA DE USUARIOS Oncólogo Dosimetrista Radioterapeuta Paciente Administrador Administrador HIS ORGANIZACIÓN EMPRESARIAL ANALISIS DE REQUISITOS LISTA DE REQUISITOS MODELO DE CASOS DE USO Modelo de Dominio Modelo de Casos de Uso de Sistema Modelo de Diseño ESTUDIO DE ARQUITECTURA ESPECIFICACIÓN DE LA ALTERNATIVA Necesidades de Software Necesidades de Hardware Necesidades de Comunicaciones ESPECIFICACIÓN DE LA ALTERNATIVA VI

9 4.2.1.Necesidades de Software Necesidades de Hardware Necesidades de Comunicaciones EVALUACIÓN OPERATIVA, TÉCNICA Y ESTRATÉGICA Matriz de Evaluación Operativa Matriz de Evaluación Técnica Matriz de Evaluación Estratégica EVALUACIÓN ECONÓMICA Costes de Implantación Costes de Adquisición de Tecnología Costes Operacionales SELECCIÓN DE LA ALTERNATIVA DISEÑO ENTORNO OPERATIVO DEL SISTEMA Entrada, salida y recogida de datos Generación de informes y formularios Control de información y seguridad del sistema CONFIGURACIÓN HARDWARE/SOFTWARE DESARROLLO DE LOS PROCESOS DE NEGOCIO Proceso de Radioterapia Evaluación Inicial Localización Plan de Irradiación Simulación Aplicación del Tratamiento MANUAL DE USUARIO Introducción Descripción General de RO Information System Acceso al Sistema Funcionalidades del Sistema de Radioterapia Funcionalidades del Sistema de Monitorización Funcionalidades del Visualizador DICOM Planificación Temporal Conclusiones Bibliografía 109 VII

10 Apéndice A. Introducción a BPMN 111 Apéndice B. Servicios Web 122 Apéndice C. XSL (Extensible StyleSheet Language) 134 Apéndice D. Listado de Acrónimos 137 VIII

11 ÍNDICE DE TABLAS Tabla 1: Lista de requisitos...16 Tabla 2: Requisito "Perfiles de Usuario"...17 Tabla 3: Requisito "Imagen Asociativa"...17 Tabla 4: Requisito "Seguridad de Acceso a cada perfil"...17 Tabla 5: Requisito "Menú de Tareas"...18 Tabla 6: Requisito "Carga de Formularios"...18 Tabla 7: Requisito "Firma de Formularios"...18 Tabla 8: Requisito "Monitorización de Procesos"...19 Tabla 9: Requisito "Seguridad de Acceso a monitorización"...19 Tabla 10: Requisito "Datos Monitorizados"...19 Tabla 11: Requisito "Visualización del estado de dispositivos"...20 Tabla 12: Requisito "Historial Clínico del paciente"...20 Tabla 13: Requisito "Visualización de imágenes DICOM"...20 Tabla 14: Requisito "Subproceso de Evaluación Inicial"...21 Tabla 15: Requisito "Informe de Evaluación Inicial"...21 Tabla 16: Requisito "Informe de Decisión Terapéutica"...21 Tabla 17: Requisito "Subproceso Localización"...22 Tabla 18: Requisito "Informe de Localización"...22 Tabla 19: Requisito "Subproceso Plan Irradiación...22 Tabla 20: Requisito "Informe Dosimétrico"...23 Tabla 21: Requisito "Subproceso Simulación"...23 Tabla 22: Requisito "Informe de Colocación Simulada"...23 IX

12 Tabla 23: Requisito "Informe Verificación Simulada"...24 Tabla 24: Requisito "Informe de Resultado de Simulación"...24 Tabla 25: Requisito "Subproceso Aplicación...24 Tabla 26: Requisito "Informe Colocación Aplicada"...25 Tabla 27: Requisito "Informe Verificación Aplicada"...25 Tabla 28: Requisito "Informe Resultado Aplicación"...25 Tabla 29: Requisito "Procesos de Negocio basados en BPM"...26 Tabla 30: Requisito "Uso de herramienta OpenSource "...26 Tabla 31: Requisito "Versión Mobile "...26 Tabla 32: Requisito "Comunicación HL7"...27 Tabla 33: Requisito "Campos de Datos de Paciente bajo HL7"...27 Tabla 34: Requisito "Comunicación entre subprocesos (WSDL)"...27 Tabla 35: Casos de Uso: Generación de Cita...31 Tabla 36: Casos de Uso: Monitorización Registros Tratamientos...31 Tabla 37: Casos de Uso: Completar Evaluación Inicial...31 Tabla 38: Casos de Uso: Realizar Decisión Terapéutica...32 Tabla 39: Casos de Uso: Firmar Decisión Terapéutica...32 Tabla 40: Casos de Uso: Completar Informe Localización...32 Tabla 41: Casos de Uso: Completar Informe Dosimétrico...33 Tabla 42: Casos de Uso: Firmar Informe Dosimétrico...33 Tabla 43: Casos de Uso: Simular Colocación...33 Tabla 44: Casos de Uso: Simular Verificación...34 Tabla 45: Casos de Uso: Completar Informe Simulación...34 Tabla 46: Casos de Uso: Firmar Informe Simulación...34 Tabla 47: Casos de Uso: Aplicar Colocación...35 Tabla 48: Casos de Uso: Aplicar Verificación...35 X

13 Tabla 49: Casos de Uso: Completar Informe Aplicación...35 Tabla 50: Casos de Uso: Aceptar Informe Aplicación...36 Tabla 51: Casos de Uso: Visualizar Imágenes...36 Tabla 52: Características de Hardware Alternativa Tabla 53: Características de Hardware Alternativa Tabla 54: Matriz de Evaluación Operativa...46 Tabla 55: Matriz de Evaluación Técnica...46 Tabla 56: Matriz de Evaluación Estratégica...47 Tabla 57: Costes de Implantación...48 Tabla 58: Costes de Adquisición de Tecnología...48 Tabla 59: Costes Operacionales...49 XI

14 ÍNDICE DE ILUSTRACIONES Ilustración 1: Organigrama de un hospital...11 Ilustración 2: Organigrama. Departamentos implicados...11 Ilustración 3: Modelo de Dominio...29 Ilustración 4: Modelo de Casos de Uso de Sistema...30 Ilustración 5: Modelo de Diseño...37 Ilustración 6: Intalio...39 Ilustración 7: Eclipse...39 Ilustración 8: Geronimo...40 Ilustración 9: PostGreSQL...40 Ilustración 10: Dell PowerEdge 2970 server...41 Ilustración 11: JBPM...42 Ilustración 12: MySQL...43 Ilustración 13: Dell R805 server...44 Ilustración 14: Gráfico de Valoración de Alternativas...47 Ilustración 15: Coste Total...49 Ilustración 16: Configuración Hardware/Software...56 Ilustración 17: Proceso de Radioterapia 1/ Ilustración 18: Proceso de Radioterapia 2/ Ilustración 19: Proceso de Radioterapia 3/ Ilustración 20: Subproceso Evaluación Inicial 1/ Ilustración 21: Subproceso Evaluación Inicial 2/ Ilustración 22: Subproceso Evaluación Inicial 3/ XII

15 Ilustración 23: Subproceso Localización...67 Ilustración 24: Subproceso Plan de Irradiación...69 Ilustración 25: Subproceso Simulación 1/ Ilustración 26: Subproceso Simulación 2/ Ilustración 27: Subproceso Aplicación del Tratamiento 1/ Ilustración 28: Subproceso Aplicación del Tratamiento 2/ Ilustración 29: Subproceso Aplicación del Tratamiento 3/ Ilustración 30: RT: Pantalla de Acceso...80 Ilustración 31: RT: Pantalla de Acceso "Mobile"...81 Ilustración 32: RT: Pantalla de Acceso Monitor...82 Ilustración 33: RT: Pantalla Principal...82 Ilustración 34: RT: Evaluación Inicial 1/ Ilustración 35: RT: Evaluación Inicial 2/ Ilustración 36: RT: Decisión Terapéutica 1/ Ilustración 37: RT: Decisión Terapéutica 2/ Ilustración 38: RT: Aceptación del tratamiento por parte del paciente...89 Ilustración 39: RT: Informe de Localización 1/ Ilustración 40: RT: Informe de Localización 2/ Ilustración 41: RT: Informe Dosimétrico 1/ Ilustración 42: RT: Informe Dosimétrico 2/ Ilustración 43: RT: Aceptación del Oncólogo...93 Ilustración 44: RT: Simulación - Colocación...95 Ilustración 45: RT: Simulación - Verificación de parámetros...96 Ilustración 46: RT: Informe de Simulación...97 Ilustración 47: RT: Aceptación de la Simulación...97 Ilustración 48: RT: Inicio de Aplicación...99 XIII

16 Ilustración 49: RT: Aplicación - Colocación Ilustración 50: RT: Aplicación - Verificación de parámetros Ilustración 51: RT: Informe de Aplicación Ilustración 52: RT: Monitor del Sistema Ilustración 53: Radscaper Ilustración 54: Radscaper Ilustración 55: Diagrama sencillo BPM Ilustración 56: Eventos I Ilustración 57: Eventos II Ilustración 58: Actividades I Ilustración 59: Actividades II Ilustración 60: GateWays I Ilustración 61: GateWays II Ilustración 62: GateWays III Ilustración 63: GateWays IV Ilustración 64: Pools Ilustración 65: Conectors I Ilustración 66: Conectors II Ilustración 67: Conectors III Ilustración 68: Conectors VI Ilustración 69: Conectors V Ilustración 70: Conectors VI Ilustración 71: Conectors VII Ilustración 72: Flujos de Secuencia Ilustración 73: Flujos de Mensajes Ilustración 74: Arquitectura de comunicaciones de los servicios Web XIV

17 Ilustración 75: Estructura Mensaje SOAP XV

18 1. INTRODUCCIÓN 1.1. MOTIVACIÓN DEL PROYECTO Actualmente se vive en un entorno en el que la tecnología forma parte de la propia vida. De la misma forma, uno de los aspectos fundamentales de este día a día es la salud. Por ello, la investigación y desarrollo de productos que integren estos dos factores, tecnología y salud, siempre supondrá un avance y a su vez, un acierto. De esta forma y gracias a la idea impulsada por SATEC, empresa que propuso el proyecto y propuso su realización, se plantea una idea innovadora enfocada hacia la automatización de los procesos necesarios en un tratamiento oncológico. Desde el primer momento en el que este proyecto comenzó a tomar forma, fue latente la verdadera proyección que un proyecto de esta envergadura puede llegar a alcanzar. 1

19 La gestión de los procesos sanitarios es un proceso realmente complejo, pero que a su vez, supone un gran reto que no solo implica su desarrollo, sino que también trata su optimización METODOLOGÍA DE DESARROLLO Tras evaluar de una forma general el proyecto y habiendo analizado posteriormente las distintas alternativas que la Ingeniería de Software ofrece, se ha elegido para el análisis, elaboración y construcción de dicho proyecto el Proceso Unificado de Desarrollo de Software como modelo a seguir en este trabajo. El Proceso Unificado es un marco de desarrollo iterativo e incremental caracterizado por estar dirigido por casos de uso y centrado en la arquitectura. Una vez desarrollada la primara fase, utilizando el Proceso Unificado, se pasará a seguir las fases de alternativas y diseño de la arquitectura que especifica el Proceso Estructurado de análisis de procesos EXPLICACIÓN DEL DOCUMENTO El presente documento se ha estructurado en una serie de capítulos principales y varios apéndices considerados de interés y utilidad. A continuación se explica cada uno de ellos: Este primer capítulo, Introducción, contiene la motivación del proyecto y un pequeño resumen de la metodología a utilizar a lo largo del proyecto. El segundo capítulo, Identificación de necesidades, presenta los diferentes objetivos que se abordarán, el alcance del sistema, que ayudará a delimitar las 2

20 funcionalidades, una clasificación y tipología de usuarios y, por último, los diagramas correspondientes a la organización empresarial, que identificarán los departamentos que englobará el sistema. El tercer capítulo, Análisis de requisitos, contiene la lista de requisitos necesarios dada por el cliente y el modelo de casos de uso, que ayudará a diseñar, de una forma gráfica, los primeros pasos del sistema. En el cuarto capítulo, Estudio de arquitectura, se plantean las posibles alternativas, tanto a nivel software como a nivel hardware. Una vez definidas se realizarán los estudios operativos, técnicos y estratégicos y, junto con la evaluación económica de cada una de ellas, se completará este capítulo con la selección de la mejor alternativa. El quinto capítulo, Diseño, describe el diseño que se ha seguido en el desarrollo del proyecto. En primer lugar, se describe la visión general de la aplicación y su arquitectura, después, se describe detalladamente el diseño de la aplicación mediante diagramas BPM con sus correspondientes comentarios. En el capítulo sexto, Manual de usuario, se describen de forma detallada, todos los pasos necesarios para la utilización del sistema, así como el uso de todas las funcionalidades previamente descritas. En el capítulo séptimo, Planificación Temporal, describe de forma gráfica, el desarrollo que ha tenido el proyecto y la duración de cada una de las etapas a lo largo del año. En el capítulo octavo, Conclusiones, realiza un breve análisis de todos los resultados obtenidos a raíz del estudio realizado. 3

21 El último capítulo, Bibliografía, contiene toda la bibliografía utilizada para la realización del presente proyecto. En el primer apéndice, Introducción a BPMN, se realiza una breve explicación y documentación de esta metodología, utilizada en el desarrollo del proyecto. En el segundo apéndice, Servicios Web, se definen las características de estos elementos utilizados en la comunicación entre procesos. El tercer apéndice, XSL (Extensible StyleSheet Language), describe las transformaciones de documentos XML y su presentación, desarrollados por el W3C. Y por último, Listado de acrónimos, se recopilan todos los acrónimos, junto con su significado, usados en el presente documento. 4

22 2. IDENTIFICACIÓN DE NECESIDADES Esta etapa es el primer acercamiento a las necesidades generales del cliente y al contexto en el que se desarrollará el sistema propuesto. El objetivo de esta etapa es, por tanto, recopilar información para definir los Objetivos que se plantea el cliente con el desarrollo de este sistema, su Alcance, la Tipología de Usuarios del sistema y la Organización Empresarial del cliente. Con el fin de alcanzar un conocimiento real y lo más preciso posible, se utilizará como principal herramienta, en esta etapa, entrevistas a personas claves como médicos especialistas en oncología radioterápica u operadores de la unidad de tratamiento de la organización OBJETIVOS DEL SISTEMA Como organizaciones complejas que son, los hospitales, debido a su propia actividad, deben manejar una gran cantidad de información. Un punto importante es el requerimiento de un profundo análisis de los sistemas de información de un hospital, ya que todos los elementos que interactúan necesitan ser reunidos, 5

23 procesados y suplementados para dar una completa información a las diferentes actividades del hospital. El objetivo principal del estudio se centrará en el análisis de los distintos procesos necesarios en la gestión del hospital, focalizándolo en las tareas necesarias para la realización de un diagnóstico y posterior tratamiento oncológico. Se estudiarán todas las fases de diagnóstico, desde el alta de paciente hasta el seguimiento del tratamiento establecido por el especialista, integrándolo junto a los diferentes servicios hospitalarios anteriormente mencionados. En más detalle, los objetivos principales que se persiguen se podrían resumir en los siguientes puntos: Integración y comunicación, mediante los estándares de intercambio electrónico de información médica definidos por HL7, del sistema y el Sistema de Información Hospitalaria (HIS), también llamado Sistema de Información Clínica (CIS), que es un sistema de información integrado diseñado para manejar los aspectos administrativos, financieros y clínicos de un hospital. Utilización del estándar Integrating the Healthcare Enterprise (IHE), que especificará las mejores prácticas de integración de los sistemas de información necesarios en la atención al paciente. Estudio de la viabilidad de la implantación de un sistema de procesos (BPM), que permita la automatización de los procesos típicos necesarios en el ámbito oncológico. 6

24 Estudio de la posible integración del sistema BPM con herramientas de terceros, como por ejemplo, los sistemas de almacenamiento de imágenes DICOM ALCANCE DEL SISTEMA Como establece el primer objetivo indicado en el punto anterior, el sistema que se desarrollará, tendrá como punto de entrada una petición recibida del HIS del hospital, por ello se puede decir que el sistema cubrirá el proceso de diagnóstico oncológico desde esta petición. Por ello, no se contempla ninguno de los procesos necesarios para la generación de la cita previa del paciente, y de la misma forma, no se contemplarán ni desarrollarán los procesos intermedios necesarios en otros departamentos para la comunicación con el sistema (Radiología o Laboratorios Clínicos). Partiendo de estas premisas, las funcionalidades del sistema serán: Automatización del tratamiento oncológico, consiguiendo así una optimización de proceso de diagnóstico. Acceso a la información, obtenida por los distintos departamentos, desde cualquier equipo de la red y en cualquier fase de dicho tratamiento. Posibilidad de consultar y comparar imágenes en formato DICOM de manera remota. Comunicación unificada de los distintos sistemas de información que componen el proceso, independientemente de su marca o modelo. 7

25 Visualización, en forma de lista, de tareas diarias. Utilización del estándar de información clínica HL7, para una mayor integración en cualquier sistema TIPOLOGÍA DE USUARIOS Los usuarios o actores implicados en el sistema serán: Oncólogo Médico especialista en Oncología Radioterápica, cuyas funciones principales son las siguientes: Evaluar al paciente y determinar cuál es el tratamiento adecuado. Decidir el área a tratar y la radiación a suministrar a partir de los datos obtenidos tanto de la localización como del plan de irradiación. Elaborar y prescribir el plan de tratamiento para cada paciente, y se asegura de que éste se administre correctamente. Monitorizar la evolución del paciente y modificar el tratamiento para que los pacientes reciban atención de alta calidad durante el tratamiento. Identificar y tratar los efectos secundarios de la radioterapia Dosimetrista Médico especialista que establece y determina la dosis correcta de radiación para un tratamiento, cuyas funciones principales son las siguientes: 8

26 Realizar una propuesta terapéutica en base a la enfermedad, el estado del paciente y medios disponibles, para conseguir un tratamiento acorde con el caso. Calcular cuidadosamente la dosis de radiación necesaria para un tumor. Elaborar planes de tratamiento para destruir lo más eficazmente posible el tumor, al mismo tiempo que se protegen los tejidos normales. Colaborar con el oncólogo y el radiofísico para elegir el plan de tratamiento indicado para cada paciente Radioterapeuta Profesional de la salud encargado de la administración del tratamiento de radioterapia establecido, cuyas funciones principales son las siguientes: Suministrar los tratamientos diarios a los pacientes, previa prescripción y supervisión del oncólogo. Mantener el registro diario y revisar las máquinas periódicamente para cerciorarse de que funcionan bien Paciente Persona que necesita de un tratamiento de radioterapia. Su papel dentro del sistema se limitará a firmar la aceptación del Informe Dosimétrico establecido para su caso. 9

27 Administrador Usuario del sistema que tendrá la posibilidad de monitorizar el estado concreto en el que se encuentra un determinado tratamiento de un paciente Administrador HIS Usuario ajeno al sistema, que será el encargado del inicio del proceso de radioterapia, generando una cita con el especialista desde el sistema gestor del hospital. 10

28 2.4. ORGANIZACIÓN EMPRESARIAL Ilustración 1: Organigrama de un hospital Ilustración 2: Organigrama. Departamentos implicados 11

29 Dentro de la Ilustración 1: Organigrama de un hospital, se puede observar, marcados en rojo, los departamentos que formarán parte del sistema, y de la misma forma, lo delimitarán. Marcado en naranja, el departamento de Imagenología, que únicamente servirá de apoyo a el sistema, pero no intercediendo en el proceso de negocio. La Ilustración 2: Organigrama. Departamentos implicados, ayuda a entender de una forma más precisa, donde están ubicados exactamente los actores principales, que formarán parte del proceso de negocio, dentro del organigrama empresarial. 12

30 3. ANALISIS DE REQUISITOS En esta etapa se busca un conocimiento en profundidad del problema planteado. Para ello, es necesario conocer y describir con rigor los requisitos de los usuarios. Será necesario, por tanto, tener contacto con los usuarios finales del sistema y obtener conocimiento de sus experiencias anteriores con sistemas similares para poder aportar mejoras. La recopilación de toda esta información quedará plasmada mediante: Lista de Requisitos Modelo de Casos de Uso Modelo de Dominio Modelo de Casos de Usos del Sistema Modelo de Diseño 13

31 3.1. LISTA DE REQUISITOS En este apartado se presentan una serie de tablas que recogen los requisitos acordados en las reuniones con los futuros usuarios del sistema. En primer lugar, se muestra una tabla que recoge todos los requisitos del sistema, sus códigos y el tipo de requisito, para facilitar una consulta rápida. Las tablas que siguen a la lista de requisitos son las fichas de cada uno de los requisitos, que analizan con más detalle cada uno de ellos. Cada requisito está referenciado con un código único que aporta información sobre el mismo. Dicho código presenta el siguiente formato: R.[Secuencia].[Subsecuencia].[Tipo] [Tipo] puede tomar los siguientes valores dependiendo del tipo de requisito al que haga referencia: F: Funcional O: Operativo S: Seguridad [Secuencia] se refiere a la numeración de los requisitos principales. [Subsecuencia] serie de valores que enumerará los requisitos dependientes de los principales. 14

32 Código Nombre Tipo R F Perfiles de Usuario Funcional R F Imagen Asociativa a cada perfil Funcional R S Seguridad de Acceso a cada perfil Seguridad R F Menú de Tareas Funcional R F Carga de Formularios Funcional R S Firma de Formularios Seguridad R F Monitorización de procesos Funcional R S Seguridad de Acceso a monitorización Seguridad R F Datos Monitorizados Funcional R F Visualización del estado de dispositivos Funcional R F Historial Clínico del paciente Funcional R F Visualización de imágenes DICOM Funcional R F Subproceso Evaluación Inicial Funcional R F Informe de Evaluación Inicial Funcional R F Informe de Decisión Terapéutica Funcional R F Subproceso Localización Funcional 15

33 R F Informe de Localización Funcional R F Subproceso Plan Irradiación Funcional R F Informe Dosimétrico Funcional R F Subproceso Simulación Funcional R F Informe Colocación Simulada Funcional R F Informe Verificación Simulada Funcional R F Informe de Resultado Simulación Funcional R F Subproceso Aplicación Funcional R F Informe Colocación Aplicada Funcional R F Informe Verificación Aplicada Funcional R F Informe Resultado Aplicación Funcional R O Procesos de Negocio basados en BPM Operativo R O Uso de herramienta OpenSource Operativo R O Versión Mobile Operativo R O Comunicación HL7 Operativo R O Campos de Datos de Paciente bajo HL7 Operativo R O Comunicación entre subprocesos (WSDL) Operativo Tabla 1: Lista de requisitos 16

34 Código Tipo R F Funcional Nombre Perfiles de Usuario Descripción Se establecerán tres tipos de usuarios diferentes: oncólogo, radioterapeuta y dosimetrista; cada uno de ellos con funcionalidades distintas. Tabla 2: Requisito "Perfiles de Usuario" Código Tipo R F Funcional Nombre Imagen Asociativa a cada perfil Descripción Cada uno de los perfiles tendrá asociado una imagen, que será mostrada al iniciar su sesión, en la parte superior derecha. Tabla 3: Requisito "Imagen Asociativa" Código Tipo R S Seguridad Nombre Seguridad de Acceso a cada perfil Descripción El acceso de cada uno de los usuarios se establecerá mediante un nombre de usuario y contraseña, que deberá de introducirse siempre que se intente comenzar una sesión. Tabla 4: Requisito "Seguridad de Acceso a cada perfil" 17

35 Código Tipo R F Funcional Nombre Menú de Tareas Descripción Dentro de cada sesión, existirá un menú que deberá ser colocado en la parte izquierda de la pantalla y contener los apartados de procesos, notificaciones y tareas pendientes. Tabla 5: Requisito "Menú de Tareas" Código Tipo R F Funcional Nombre Carga de Formularios Descripción Cada uno de los formularios que la aplicación cargará, serán mostrados en la parte derecha de la pantalla. Tabla 6: Requisito "Carga de Formularios" Código Tipo R S Seguridad Nombre Firma de Formularios Descripción En esta primera versión, la firma de formularios, tanto por el paciente como por el oncólogo, será realizada mediante un selectbox, dejando para un posterior desarrollo la firma de documentos mediante firma electrónica. Tabla 7: Requisito "Firma de Formularios" 18

36 Código Tipo R F Funcional Nombre Monitorización de Procesos Descripción Se deberá implementar un sistema de monitorización, solo accesible por el usuario Administrador, que mostrará los pasos completados en cada uno de los niveles del proceso de negocio, en este caso dicho proceso se corresponde con el tratamiento. Tabla 8: Requisito "Monitorización de Procesos" Código Tipo R S Seguridad Nombre Seguridad de Acceso a monitorización Descripción El acceso se establecerá mediante un número de tratamiento que deberá introducirse siempre que se intente visualizar dicho tratamiento. Tabla 9: Requisito "Seguridad de Acceso a monitorización" Código Tipo R F Funcional Nombre Datos Monitorizados Descripción Los datos mínimos a monitorizar serán: Nombre de la tarea, especialista que la realiza, descripción y fecha de realización. Tabla 10: Requisito "Datos Monitorizados" 19

37 Código Tipo R F Funcional Nombre Visualización del estado de dispositivos Descripción Dentro de esta monitorización de registros se incluirá una visualización del estado actual de los dispositivos de radioterapia, tanto del PPS (Patient Positioning System) como del TDD (Treatment Delivery Device). Tabla 11: Requisito "Visualización del estado de dispositivos" Código Tipo R F Funcional Nombre Historial Clínico del paciente Descripción Posibilidad del acceso al Historial Clínico del paciente desde el formulario de la Evaluación Inicial. Tabla 12: Requisito "Historial Clínico del paciente" Código Tipo R F Funcional Nombre Visualización de imágenes DICOM Descripción Posibilidad de acceso a las imágenes de diagnóstico en formato DICOM, desde cualquiera de los formularios. Tabla 13: Requisito "Visualización de imágenes DICOM" 20

38 Código Tipo R F Funcional Nombre Subproceso de Evaluación Inicial Descripción Subproceso que incluirá la primera valoración del paciente, a la vez que la decisión sobre el tratamiento adecuado en su caso. Tabla 14: Requisito "Subproceso de Evaluación Inicial" Código Tipo R F Funcional Nombre Informe de Evaluación Inicial Descripción Contendrá los datos del paciente y su Historial Clínico. Deberá completarse con los datos de la primera toma de contacto del paciente con el oncólogo. Tabla 15: Requisito "Informe de Evaluación Inicial" Código Tipo R F Funcional Nombre Informe de Decisión Terapéutica Descripción Bajo la primera evaluación y los datos recogidos por las pruebas requeridas (imágenes, análisis), se tomará una decisión sobre el tratamiento más adecuado para el paciente, que posteriormente deberá firmar con su consentimiento. Tabla 16: Requisito "Informe de Decisión Terapéutica" 21

39 Código Tipo R F Funcional Nombre Subproceso Localización Descripción Subproceso que establecerá, una vez aceptado el tratamiento del paciente, el lugar especifico donde el tratamiento debe de ser suministrado. Tabla 17: Requisito "Subproceso Localización" Código Tipo R F Funcional Nombre Informe de Localización Descripción Informe que indicará los parámetros donde el tratamiento deberá ser irradiado. Tabla 18: Requisito "Informe de Localización" Código Tipo R F Funcional Nombre Subproceso Plan Irradiación Descripción Subproceso que, una vez limitado el lugar de irradiación en el subproceso de localización, proporcionará las dosis necesarias en el tratamiento de radioterapia. Tabla 19: Requisito "Subproceso Plan Irradiación 22

40 Código Tipo R F Funcional Nombre Informe Dosimétrico Descripción Informe que fijará las proporciones de las dosis necesarias a irradiar en el tratamiento de radioterapia que, posteriormente, deberá de ser aceptado y firmado por el oncólogo. Tabla 20: Requisito "Informe Dosimétrico" Código Tipo R F Funcional Nombre Subproceso Simulación Descripción Con todos los datos adquiridos en los subprocesos de localización e irradiación, se realizará una simulación previa del tratamiento para su verificación por el departamento de radioterapia. Tabla 21: Requisito "Subproceso Simulación" Código Tipo R F Funcional Nombre Informe de Colocación Simulada Descripción Simulación de los datos recibidos en el informe de localización. Tabla 22: Requisito "Informe de Colocación Simulada" 23

41 Código Tipo R F Funcional Nombre Informe Verificación Simulada Descripción Simulación de los datos recibidos en el informe dosimétrico. Tabla 23: Requisito "Informe Verificación Simulada" Código Tipo R F Funcional Nombre Informe de Resultado de Simulación Descripción Informe que incluirá los datos resultantes de la simulación. Posteriormente deberá de ser aceptada por el oncólogo. En caso de ser rechazada se volverá a realizar los subprocesos de localización e irradiación. Tabla 24: Requisito "Informe de Resultado de Simulación" Código Tipo R F Funcional Nombre Subproceso Aplicación Descripción Una vez simulado correctamente el tratamiento, se procederá a la aplicación del mismo al paciente. Tabla 25: Requisito "Subproceso Aplicación 24

42 Código Tipo R F Funcional Nombre Informe Colocación Aplicada Descripción Aplicación de los datos recibidos en el informe de localización y aceptados en el subproceso de simulación. Tabla 26: Requisito "Informe Colocación Aplicada" Código Tipo R F Funcional Nombre Informe Verificación Aplicada Descripción Aplicación de los datos recibidos en el informe dosimétrico y aceptados en el subproceso de simulación. Tabla 27: Requisito "Informe Verificación Aplicada" Código Tipo R F Funcional Nombre Informe Resultado Aplicación Descripción Informe que incluirá los datos resultantes de la sesión de tratamiento. Posteriormente deberá de ser enviada al oncólogo Tabla 28: Requisito "Informe Resultado Aplicación" 25

43 Código Tipo R O Operativo Nombre Procesos de Negocio basados en BPM Descripción El diseño de los procesos deberá realizarse bajo la notación BPMN, utilizando sus diagramas de negocio Tabla 29: Requisito "Procesos de Negocio basados en BPM" Código Tipo R O Operativo Nombre Uso de herramienta OpenSource Descripción Utilización de una herramienta de Software Libre. Tabla 30: Requisito "Uso de herramienta OpenSource " Código Tipo R O Operativo Nombre Versión Mobile Descripción Realización de una versión Mobile,para su implantación en dispositivos móviles Tabla 31: Requisito "Versión Mobile " 26

44 Código Tipo R O Operativo Nombre Comunicación HL7 Descripción Integración y comunicación, mediante los estándares de intercambio electrónico de información médica definidos por HL7 Tabla 32: Requisito "Comunicación HL7" Código Tipo R O Operativo Nombre Campos de Datos de Paciente bajo HL7 Descripción La información mínima bajo el estándar HL7 será toda la referente a los datos personales del paciente, para así, permitir una mejor interoperabilidad con el HIS. Tabla 33: Requisito "Campos de Datos de Paciente bajo HL7" Código Tipo R O Operativo Nombre Comunicación entre subprocesos (WSDL) Descripción La invocación de los subprocesos, así como de cada uno de los pasos de los mismos, debe de ser posible a través de servicios Web, pudiéndose proporcionar un WSDL si así se requiera. Tabla 34: Requisito "Comunicación entre subprocesos (WSDL)" 27

45 3.2. MODELO DE CASOS DE USO En la elaboración del análisis previo del sistema se utilizarán los pasos previos definidos por el Modelo de Casos de Uso. Primeramente el análisis se centrará en un Modelo de Dominio que proporcionará una imagen conceptual muy general de cómo opera el negocio. Una vez finalizado este Modelo de Dominio, es necesario moverse entre los distintos Casos de Uso del sistema, que facilitarán de una forma esquemática las interacciones posibles que el usuario tiene con el sistema, para alcanzar resultados. Finalmente se pasará a la elaboración del Modelo de Diseño, cuyo propósito es el de describir la combinación de la información del Modelo de Dominio y el comportamiento de los Casos de Uso, con el objetivo de visualizar con mayor facilidad los objetos que el sistema contendrá y las funcionalidades que el sistema va a automatizar. 28

46 Modelo de Dominio Ilustración 3: Modelo de Dominio En este diagrama se puede ver una representación visual de las clases conceptuales u objetos que forman parte del sistema. Se puede entender a través de este diagrama como un el HIS generará una cita asociada a un paciente. Dicha cita será asociada a un tratamiento. Este tratamiento utilizará los sistemas necesarios para su aplicación y a su vez podrá acceder a las imágenes del paciente almacenadas en el PACS. Todos estos movimientos serán almacenados en una base de datos mediante los registros creados en cada uno de los niveles del proceso de negocio. 29

47 Modelo de Casos de Uso de Sistema Ilustración 4: Modelo de Casos de Uso de Sistema 30

48 Nombre: Generación de Cita Actores: Administrador HIS Tipo: Primario Descripción: El sistema gestor del hospital (HIS), manejado por, en este caso, el Administrador HIS, genera una cita con el oncólogo en el sistema. Tabla 35: Casos de Uso: Generación de Cita Nombre: Monitorización Registros Tratamientos Actores: Administrador Tipo: Primario Descripción: El Administrador del sistema de monitorización selecciona un tratamiento a visualizar y el sistema le presenta el detalle de dicho tratamiento. Tabla 36: Casos de Uso: Monitorización Registros Tratamientos Nombre: Completar Evaluación Inicial Actores: Oncólogo Tipo: Primario Descripción: El oncólogo completará este informe, donde se recogerán las primeras valoraciones para un posterior estudio del tratamiento más adecuado. Tabla 37: Casos de Uso: Completar Evaluación Inicial 31

49 Nombre: Realizar Decisión Terapéutica Actores: Oncólogo Tipo: Primario Descripción: Con todos los datos recogidos en la evaluación inicial (análisis, imágenes...), se completará el informe para establecer un pretratamiento para el paciente. Tabla 38: Casos de Uso: Realizar Decisión Terapéutica Nombre: Firmar Decisión Terapéutica Actores: Oncólogo, Paciente Tipo: Primario Descripción: Tras la decisión terapéutica, el oncólogo comunicará la decisión al paciente, que a su vez firmará la aceptación del tratamiento. Tabla 39: Casos de Uso: Firmar Decisión Terapéutica Nombre: Completar Informe Localización Actores: Oncólogo Tipo: Primario Descripción: Con los datos generados por las imágenes realizadas al paciente, se realizará un estudio para especificar las zonas implicadas en el tratamiento reflejadas en este informe. Tabla 40: Casos de Uso: Completar Informe Localización 32

50 Nombre: Completar Informe Dosimétrico Actores: Dosimetrista Tipo: Primario Descripción: El dosimetrista, una vez recibido el informe de localización y con los datos previos del tratamiento, completará el informe que indicará las dosis exactas a irradiar en el paciente. Tabla 41: Casos de Uso: Completar Informe Dosimétrico Nombre: Firmar Informe Dosimétrico Actores: Oncólogo Tipo: Primario Descripción: El oncólogo deberá firmar este informe, que una vez aceptado, dará paso a la simulación y posterior aplicación. Tabla 42: Casos de Uso: Firmar Informe Dosimétrico Nombre: Simular Colocación Actores: Radioterapeuta Tipo: Primario Descripción: El radioterapeuta realizará la simulación de la colocación del paciente en función a los datos recibidos en los informes de localización. Tabla 43: Casos de Uso: Simular Colocación 33

51 Nombre: Simular Verificación Actores: Radioterapeuta Tipo: Primario Descripción: El radioterapeuta realizará la simulación de la verificación de los dispositivos, en función de los datos recibidos en los informes dosimétricos. Tabla 44: Casos de Uso: Simular Verificación Nombre: Completar Informe Simulación Actores: Radioterapeuta Tipo: Primario Descripción: Una vez simulado todo el proceso de la sesión, el radioterapeuta completará un informe para el oncólogo, con los resultados obtenidos. Tabla 45: Casos de Uso: Completar Informe Simulación Nombre: Firmar Informe Simulación Actores: Oncólogo Tipo: Primario Descripción: El oncólogo deberá firmar el resultado de la simulación, y en caso afirmativo se procederá a la aplicación de dicho tratamiento. Tabla 46: Casos de Uso: Firmar Informe Simulación 34

52 Nombre: Aplicar Colocación Actores: Radioterapeuta Tipo: Primario Descripción: El radioterapeuta colocará al paciente mediante los sistemas de posicionamiento, en las posiciones acordadas y aceptadas en el proceso de simulación. Tabla 47: Casos de Uso: Aplicar Colocación Nombre: Aplicar Verificación Actores: Radioterapeuta Tipo: Primario Descripción: El radioterapeuta realizará el tratamiento mediante los sistemas de aplicación del mismo. Tabla 48: Casos de Uso: Aplicar Verificación Nombre: Completar Informe Aplicación Actores: Radioterapeuta Tipo: Primario Descripción: Una vez simulado todo el proceso de la sesión, el radioterapeuta completará un informe para el oncólogo, con los resultados obtenidos. Tabla 49: Casos de Uso: Completar Informe Aplicación 35

53 Nombre: Aceptar Informe Aplicación Actores: Radioterapeuta Tipo: Primario Descripción: El oncólogo deberá recibirá un informe con cada una de las sesiones realizadas al paciente. Tabla 50: Casos de Uso: Aceptar Informe Aplicación Nombre: Visualizar Imágenes Actores: Oncólogo, Dosimetrista, Radioterapeuta Tipo: Subfunción Descripción: Durante todo el procesos, cada uno de estos actores podrá acceder a las imágenes del paciente, para poder realizar las correspondientes fases de la planificación del tratamiento. Tabla 51: Casos de Uso: Visualizar Imágenes 36

54 Modelo de Diseño Ilustración 5: Modelo de Diseño Este Modelo de Diseño, cuyo propósito es el de describir la combinación de la información del Modelo de Dominio y el comportamiento de los Casos de Uso, permite visualizar con mayor facilidad los objetos que el sistema contendrá y las funcionalidades que el sistema va a automatizar. 37

55 4. ESTUDIO DE ARQUITECTURA En esta etapa se pretende, atendiendo tanto a los requisitos del usuario como a las restricciones de diseño, definir la posible solución de arquitectura para todos los ámbitos de desarrollo. Por tanto, la realización de esta etapa consiste básicamente en las siguientes actividades: Especificación de las Alternativas. Evaluación Operativa, Técnica y Estratégica. Evaluación Económica. 38

56 4.1. ESPECIFICACIÓN DE LA ALTERNATIVA 1 Las restricciones dadas por el cliente son claras y delimitan en gran medida las opciones a la hora de tomar una decisión en cuanto a una alternativa especifica. La primera restricción a tener en cuenta es la apuesta del cliente por tecnología de Software Libre y a su vez un desarrollo de los procesos de negocio basados en BPM, logrando de esta forma un mejor entendimiento del negocio a la vez que un desarrollo claro y eficiente enfocado hacia futuras versiones Necesidades de Software La alternativa de software que se presenta será la combinación de distintas herramientas, que ayudarán en el desarrollo a lo largo de todas las etapas del proceso. Estas etapas serán las siguientes: Desarrollo de procesos de negocio BPM y formularios: En esta primera etapa se utilizará Intalio, software Open Source basado en Java-J2EE, que utiliza la Ilustración 6: Intalio notación BPMN para diseñar procesos de negocio. Los componentes que componen esta herramienta son: Una herramienta para el diseño de los procesos de negocio, basada en Eclipse, que a su vez se integra con una herramienta para el desarrollo de formularios, que formarán parte de este proceso, basados en Ilustración 7: Eclipse Orbeon Xforms. 39

57 Un Servidor de Aplicaciones donde residirán los servicios de procesos de negocio que se desplegarán, basado en Apache Geronimo. Ilustración 8: Geronimo Utilización de Web Services en los procesos de negocio: Utilizando los procesos y subprocesos realizados, se utilizará Axis2 para desarrollar los Web Services necesarios para la comunicación entre estos. Base de Datos: Una vez desarrollado todo el modelo de negocio, se incluirá la base de datos necesaria para la creación y monitorización de los registros creados por la aplicación, basada en PostgreSQL. Ilustración 9: PostGreSQL Portal de aplicaciones: Utilizando Eclipse, para su desarrollo, y Apache Tomcat, como servidor de aplicaciones Necesidades de Hardware El equipo hardware que elegido tendrá un soporte para 100 usuarios simultáneos. La aplicación formará parte de un departamento con un máximo de 4 oncólogos y puede atender como máximo unos 20 pacientes diarios, por tanto, será más que suficiente. 40

58 Para desplegar el sistema se ha elegido en este caso el Dell PowerEdge 2970 server con las siguientes características: Ilustración 10: Dell PowerEdge 2970 server Componente Procesador Dual-Core AMD OpteronTM Chipset Broadcom HT-2100 and HT-1000 Server I/O Controllers Instalado 2GB. Ampliable hasta 64GB (8 DIMM slots):2gb/4gb/8gb ECC DDR2 Memoria Sistema Operativo Almacenamiento Red Capacidad Gáfica Ubuntu 9.04 Server Edition 3.5" Nearline SAS (7.2k rpm): 500GB Dual Embedded Broadcom NetXtreme II 5708 Gigabit Ethernet NIC Embedded ATI ES1000 with 16MB memory Tabla 52: Características de Hardware Alternativa 1 41

59 Necesidades de Comunicaciones Dado que este sistema será implantado en una red hospitalaria, se supone que todo el sistema de comunicaciones esta integrado de forma adecuada según haya considerado oportuno el administrador de la red ESPECIFICACIÓN DE LA ALTERNATIVA 2 Siguiendo las restricciones especificadas anteriormente por el cliente, se construye esta alternativa, que cumple de la misma forma que la anterior los puntos principales; apuesta del cliente por la tecnología de Software Libre y desarrollo de los procesos de negocio basados en BPM Necesidades de Software Desarrollo de procesos de negocio BPM y formularios: En esta etapa de desarrollo se utilizará el JBPM de JBoss, suite de desarrollo, que a diferencia de otras herramientas, cumple con el estándar JPDL (JBoss PDL), estándar asociado a WorkFlows. Ilustración 11: JBPM Se debe mencionar que jbpm no utiliza la nomenclatura de desarrollo de BPMN, utilizando una propia. Los componentes que componen esta herramienta son: jbpm-server, un servidor de aplicación jboss preconfigurado. jbpm-designer, el plugin eclipse para crear procesos jbpm en forma gráfica. 42

60 jbpm-db, el paquete de compatibilidad de la base de datos jbpm. En el desarrollo de formularios asociados al proceso de negocio se generan automáticamente en JSF con Facelets, permitiendo trabajar con mayor libertad. El paquete de compatibilidad permite trabajar con cualquier base de datos, casi el 100% de las mas usadas empresarialmente, como, Sybase, Oracle, SQL Server, y no tan empresariales como MySQL. Utilización de Web Services en los procesos de negocio: Al igual que en la primera alternativa, se utilizará Axis2 para desarrollar los Web Services necesarios para la comunicación entre los procesos y subprocesos. Base de Datos: En este caso se utilizará MySQL para el desarrollo de la base de datos necesaria para la creación y monitorización de los registros creados por la Ilustración 12: MySQL aplicación. Portal de aplicaciones: Utilizando Eclipse, para su desarrollo y Apache Tomcat, como servidor de aplicaciones Necesidades de Hardware Para desplegar el sistema se ha elegido en este caso el Dell R805 server con las siguientes caracteristicas: 43

61 Ilustración 13: Dell R805 server Componente Procesador 2x Quad Core AMD Opteron 2344HE, 55W, 1.7GHz, 1Ghz HyperTransport Chipset Broadcom HT-2100 and HT-1000 Server I/O Controllers Memoria 8GB Memory, 4x2GB, 667MHz, Dual Ranked DIMMs Sistema Operativo Almacenamiento Red Ubuntu 9.04 Server Edition 146GB, SAS, 2.5-inch, 10K RPM Hard Drive 4x Broadcom NetXtreme II GbE Capacidad Gáfica Embedded ATI ES1000 with 16MB memory Tabla 53: Características de Hardware Alternativa Necesidades de Comunicaciones Dado que el sistema será implantado en una red hospitalaria, se supone que todo el sistema de comunicaciones esta integrado de forma adecuada según haya considerado oportunos el administrador de la red. 44

62 4.3. EVALUACIÓN OPERATIVA, TÉCNICA Y ESTRATÉGICA Definidas las soluciones, se evaluará el impacto de las alternativas en la organización. Para ello se considerarán diferentes aspectos, que actuarán como parámetros de baremo. Este estudio se centrará en tres aspectos concretos, como son: aspectos operativos, técnicos y estratégicos. El nivel operativo, se centrará en conocer la importancia de puntos como la reducción de gastos de mantenimiento o la fiabilidad de los datos. A nivel técnico se establecerá un baremo que ayudará a conocer las características y facilidades desde el punto de vista tecnológico, de la alternativa elegida. Y finalmente el nivel estratégico ayudará a resolver puntos como el aumento de productividad o la mejora de atención a la demanda. Todos estos factores se plasmarán sobre una matriz, que contendrá los pesos asignados a cada factor y la valoración obtenida a la alternativa elegida. Estos pesos oscilarán del 1 al 3, (3=imprescindible, 2=importante, 1=conveniente), dependiendo de la importancia del factor dentro del negocio. Posteriormente se valorarán cada uno de esos factores (PT) (3=cumple totalmente, 2=cumple en gran parte, 1=cumple un mínimo, 0=no cumple) De la misma forma se obtendrá una valoración (VA) como resultado de multiplicar el peso del factor en concreto, con la puntuación recibida. 45

63 Matriz de Evaluación Operativa Alternativa 1 Factores Operativos (36%) 2 Peso PT VA PT VA Reducción de gastos de mantenimiento Reducción de tareas manuales Fiabilidad de los datos Facilidad de uso y manejo Agilidad de la aplicación Seguridad Puntuación Total Tabla 54: Matriz de Evaluación Operativa Matriz de Evaluación Técnica Alternativa Factores Técnicos (28%) Peso PT VA PT VA Requisitos software Requisitos hardware Independencia con sistemas actuales Facilidad de implantación Integración de diagramas BPM Puntuación Total Tabla 55: Matriz de Evaluación Técnica 46

64 Matriz de Evaluación Estratégica Alternativa 1 Factores Estratégicos (36%) 2 Peso PT VA PT VA Mejorar la imagen de la compañía Mejorar la atención de la demanda Mejorar el control de la gestión Optimización de la gestión Aumentar la productividad Puntuación Total Tabla 56: Matriz de Evaluación Estratégica Alternativa 1 20 Alternativa Operativos Técnicos Estratégicos Ilustración 14: Gráfico de Valoración de Alternativas 4.4. EVALUACIÓN ECONÓMICA Un estudio detallado del factor económico se realiza en base al llamado Análisis de Coste/Beneficio. En él se marcan los costes del proyecto y se contrastan 47

65 con los beneficios que aportará al sistema. Esto sería necesario para cuantificar la recuperación de la inversión (ROI) y de este modo poder conocer si el esfuerzo económico tiene sentido. Sin embargo, desde el punto de vista de valoración de posibles soluciones, se considera suficiente una valoración de costes tangibles, que estarán directamente asociados al desarrollo del proyecto. Estos costes estarán resumidos en costes de implantación, costes de adquisición de tecnología y costes operacionales Costes de Implantación Costes de Implantación Alternativa 1 Alternativa 2 Costes de desarrollo , ,00 Costes de puesta en marcha 2.500, ,00 650,00 470, , ,00 Costes de formación Coste Total Tabla 57: Costes de Implantación Costes de Adquisición de Tecnología Costes de Adquisición de Tecnología Alternativa 1 Alternativa 2 Costes de Hardware 1.816, ,00 Costes de Software 0,00 0,00 Costes de Comunicaciones 0,00 0, , ,00 Coste Total Tabla 58: Costes de Adquisición de Tecnología 48

66 Costes Operacionales Costes Operacionales Alternativa 1 Alternativa 2 Costes de Mantenimiento y Mejora 154,00 267,00 Coste Total 154,00 267,00 Tabla 59: Costes Operacionales Costes Totales Alternativa 1 Alternativa 2 Ilustración 15: Coste Total 4.5. SELECCIÓN DE LA ALTERNATIVA Con los datos recogidos en la especificación de cada alternativa, las matrices de evaluación y las matrices de evaluación de costes, se selecciona la alternativa más conveniente a desarrollar. En este caso, claramente se optará por la alternativa 1, ya que obtuvo una mayor puntuación. 49

67 Pero no sólo se deberá centrar en las puntuaciones obtenidas, sino que además la alternativa no cumple de una forma óptima un requisito importante dado por el cliente, como es la integración de diagramas BPM, ya que JBPM utiliza su propio estándar en cuanto a la notación de diagramas, concepto que a la larga y en desarrollos de futuras versiones podría generar complicaciones. Además, se debe señalar que el coste completo del desarrollo de la Alternativa 1 es ya menor que los costes de implantación de la Alternativa 2, por ello es otro factor a tener en cuenta sobre la elección de la Alternativa 1. 50

68 5. DISEÑO 5.1. ENTORNO OPERATIVO DEL SISTEMA Entrada, salida y recogida de datos En este apartado se especificarán los diferentes tipos de entradas y salidas de datos, a fin de poder diseñar interfaces con otros sistemas que dialogan con éste. Por otro lado, se especificará como van a llevarse a cabo las posibles tomas de datos para la entrada al sistema: quiénes van a realizarlas y qué información se va a introducir. Tal y como se especifica en R F, existirán 3 perfiles principales, encargados de la interacción fundamental con el sistema: oncólogo, dosimetrista y radioterapeuta. Existen a su vez, otros actores como son el administrador del sistema, que no interactúa con el sistema de una forma directa, pero si consume información, controlando los registros generados por cada uno de los procesos del negocio. Finalmente se hará referencia al paciente por un lado, que únicamente formará parte del proceso en la aceptación del tratamiento propuesto, y el 51

69 administrador del HIS, que será en encargado de comenzar el proceso a través de la generación de una cita con el oncólogo. De este pequeño análisis se deduce que el sistema recibe datos de 3 entidades externas que se detallarán a continuación para cada perfil en concreto: Oncólogo Según el modelo de casos de uso (ver 3.2.2), el oncólogo generará informes de evaluación inicial, decisión terapéutica e informe de localización. Estas entradas se definen con detalle en R F, R F y R F, respectivamente. Además completará la firma de los formularios de informe dosimétrico y informe de simulación definidos en detalle en R F y R F, respectivamente. Sus funcionalidades principales serán: Evaluar al paciente y determinar cuál es el tratamiento adecuado. Decidir el área a tratar y la radiación a suministrar a partir de los datos obtenidos tanto de la localización como del plan de irradiación. Elaborar y prescribir el plan de tratamiento para cada paciente, y asegurarse de que éste se administre correctamente. Monitorizar la evolución del paciente y modificar el tratamiento para que los pacientes reciban atención de alta calidad durante el tratamiento. Identificar y tratar los efectos secundarios de la radioterapia. 52

70 Dosimetrista Según el modelo de casos de uso (ver 3.2.2), el dosimetrista generará el informe dosimétrico definido en R F. Las entradas recibidas, en este caso, serán los datos recogidos de el informe de localización y decisión terapéutica definidos en R F y R F, respectivamente. Sus funcionalidades principales serán: Realizar una propuesta terapéutica en base a la enfermedad, el estado del paciente y medios disponibles, para conseguir un tratamiento acorde con el caso. Calcular cuidadosamente la dosis de radiación necesaria para un tumor. Elaborar planes de tratamiento para destruir lo más eficazmente el posible tumor, al mismo tiempo que proteger los tejidos normales. Colaborar con el oncólogo y el radiofísico para elegir el plan de tratamiento indicado para cada paciente. Radioterapeuta Según el modelo de casos de uso (ver 3.2.2), el radioterapeuta será el encargado de proveer al sistema de los subprocesos de simulación y aplicación, completando todos los informes que estos subprocesos requieren. Las entradas recibidas, en este caso, serán los datos recogidos tras la firma del informe dosimétrico definido por R F. Sus funcionalidades principales serán: 53

71 Suministrar los tratamientos diarios a los pacientes previa prescripción y supervisión del oncólogo. Mantener el registro diario y revisar las máquinas periódicamente para cerciorarse de que funcionan bien. Administrador Según el modelo de casos de uso (ver 3.2.2), el administrador del sistema será el responsable de la monitorización del sistema, definido por R F y todos los requisitos que pertenecen a éste. De la misma forma, se especifican en este apartado los sistemas externos que forman parte del proceso: HIS (Hospital Information System) Se trata del sistema que maneja y gestiona toda la información del hospital, como por ejemplo, información general de los pacientes, información de los empleados, control de citas, etc. La comunicación del sistema con el HIS será utilizando el protocolo HL7 utilizando codificación XML y transporte mediante Web Services. Puesto que los HIS suelen ser productos comerciales, se simularán aquellas operaciones que se necesiten mediante Web Services. RT Information System Se trata del sistema asociado al departamento de radioterapia. Dicho sistema almacenará aquella información asociada a un paciente y relativa al campo de la radioterapia. 54

72 PACS Sistema donde se almacenan imágenes de los pacientes. La comunicación con el PACS será mediante el protocolo DICOM a través de un visor de imágenes Generación de informes y formularios La herramienta que se utilizará, según la alternativa elegida, será Intalio. Esta suite de desarrollo, no solo permite el diseño de los diagramas BPM, sino que además se completa con una pequeña herramienta de diseño de formularios que podrán ser posteriormente incluidos en los procesos de negocio desarrollados bajo el diagrama BPM. Esta herramienta de diseño de formularios esta basada en Xforms, nuevo estándar XML que define interfaces de usuario, principalmente formularios Web. Estos formularios Web, están definidos de tal forma que su desarrollo se realiza sin preocuparse de la vista, simplemente se preocuparán de los datos asociados y posteriormente se decidirá si su visualización se realiza mediante formularios Web u otra tecnología (SWT por ejemplo) Control de información y seguridad del sistema El acceso al sistema estará restringido para los diferentes usuarios. En este momento de desarrollo, existe un mecanismo de autenticación/autorización basado en un fichero con los usuarios autorizados, pero en futuros desarrollos existe la prioridad de adaptarlo hacia otra fuente de datos (LDAP, BD, etc.). 55

73 5.2. CONFIGURACIÓN HARDWARE/SOFTWARE Ilustración 16: Configuración Hardware/Software Según se puede observar en la Ilustración 16, los usuarios del sistema podrán conectarse al sistema a través de sus dispositivos habituales de trabajo. El HIS, generando las citas, mediante HL7, el oncólogo, desde su consulta accediendo al sistema, el dosimetrista, desde los equipos habituales del laboratorio y el radioterapeuta, desde el laboratorio de tratamientos y siempre desde un UMPC que le posibilite una mayor movilidad. Para el acceso al sistema simplemente se necesita un navegador Web (IE, Firefox, ). A pesar de su compatibilidad con todos los modelos de navegadores existentes, el sistema ha sido realizado para ejecutarse de manera óptima sobre Mozilla Firefox. 56

74 5.3. DESARROLLO DE LOS PROCESOS DE NEGOCIO Para el desarrollo de los procesos de negocio del sistema, basados en BPMN, se utilizará la herramienta de Intalio, orientada a tal efecto. BPMN está diseñado para cubrir varios tipos de modelado y permite la creación tanto de segmentos de proceso como procesos de negocio de comienzo a fin, y en diferentes niveles de reprensentatividad. Cada uno de los diagramas esta dividido en pools, de los cuales, solo uno de ellos será el pool ejecutable, y el resto, los encargados de representar los distintos actores que forman parte del proceso. Normalmente, los actores físicos implicados, se presentarán en la parte superior del diagrama, y los actores que representan sistemas externos, en la parte inferior, separados por el pool ejecutable. En este caso, el pool ejecutable, tendrá el nombre del proceso que represente. De esta forma, se puede decir que el proceso de negocio, a partir de este momento, proceso de radioterapia, estará dividido en los siguientes subprocesos: Evaluación Inicial Simulación Localización Aplicación Plan de Irradiación 57

75 Proceso de Radioterapia Diagramas Ilustración 17: Proceso de Radioterapia 1/3 58

76 Ilustración 18: Proceso de Radioterapia 2/3 59

77 Ilustración 19: Proceso de Radioterapia 3/3 60

78 Descripción El proceso comienza desde el administrador del HIS, encargado de generar la cita correspondiente al paciente que será tratado para obtener su tratamiento. Esta cita generará unos valores como son: un ID de paciente, una fecha y una hora. Una vez obtenidos estos datos, el sistema los recibirá y consultará mediante un Web Service los datos del paciente a través del ID de paciente recibido. Tanto la petición como la respuesta de este Web Service será en formato HL7, simulando de esta manera la comunicación con un HIS real. Una vez que los datos del paciente viajan en el flujo del proceso, se procederá a una petición mediante Web Services, para autogenerar un ID de tratamiento (necesario para su identificación posterior y almacenamiento en el historial del paciente) y una consulta a su historial clínico. Todos estos datos se mapearán con las variables del proceso, para no perder estos datos a lo largo de su desarrollo y posteriormente se crearán los registros, que se almacenarán en la base de datos, de Inicio de Proceso y Generación de Cita. A partir de este momento se invocará a través de un Web Service al subproceso de Evaluación Inicial, que devolverá una variable que se evaluará una vez completado este subproceso. Esta variable indicará, si el tratamiento ha sido firmado por el paciente, en caso negativo, el tratamiento será cancelado, en caso afirmativo, se procederá a invocar al subproceso de Localización. Una vez realizado este subproceso, se pasará a la realización del Plan de Irradiación que será realizado tantas veces como sea necesario hasta que el oncólogo acepte el plan desarrollado y una vez aceptado se concluirá con la Simulación de este tratamiento, que de la misma forma, no avanzará en el proceso hasta que no sea satisfactorio. 61

79 Una vez que la simulación sea aceptada, se pasará a la fase final de Aplicación del Tratamiento, en la que en este caso se ha supuesto una sola sesión, en caso de ser más de una, se someterá a un subproceso que se repetirá N veces hasta su finalización. Una vez concluido, se generará un informe final con los datos obtenidos en el tratamiento que será entregado al oncólogo y posteriormente y una vez recibido, almacenado en el historial y registrador en su monitor de procesos. 62

80 Evaluación Inicial Diagramas Ilustración 20: Subproceso Evaluación Inicial 1/3 63

81 Ilustración 21: Subproceso Evaluación Inicial 2/3 64

82 Ilustración 22: Subproceso Evaluación Inicial 3/3 65

83 Descripción Una vez lanzado el subproceso, el primer formulario lanzado por la aplicación que deberá de ser completado por el oncólogo, será el de Evaluación Inicial que una vez completado se registrará en la base de datos. Posteriormente se evaluará la petición de nuevas imágenes y una vez realizadas, y nunca antes de que esas imágenes sean recibidas, se comenzará la Decisión Terapéutica, generando su posterior registro. En el caso de que exista una nueva petición de imágenes desde la Decisión Terapéutica, realizándose la misma petición y no continuando con el subproceso hasta su recepción en el sistema. Posteriormente, el sistema generará el formulario con las dos etapas para que el oncólogo realice la comunicación al paciente y éste acepte o decline esta Decisión Terapéutica, evaluando su decisión posteriormente en el proceso de radioterapia. 66

84 Localización Diagramas Ilustración 23: Subproceso Localización 67

85 Descripción En este subproceso se procederá a la localización exacta de la zona a irradiar. Para ello el sistema cargará un formulario con los datos necesarios a completar en esta etapa por el oncólogo. Una vez completado, su registro será almacenado a través de un Web Service en la base de datos. 68

86 Plan de Irradiación Diagramas Ilustración 24: Subproceso Plan de Irradiación 69

87 Descripción Este subproceso será repetido hasta que el oncólogo decida que el Plan Dosimétrico es el adecuado. En primer lugar el dosimetrista recibirá un formulario que deberá completar con los datos necesarios en cuanto a las dosis necesarias en la irradiación. Una vez completado será registrado en la base de datos y comunicado al oncólogo. Este tratamiento especifico será evaluado y en caso de rechazo volverá a generarse en la pantalla del dosimetrista una tarea pendiente de informe de Dosimetría. En caso de aceptación se procederá con la simulación de este tratamiento. 70

88 Simulación Diagramas Ilustración 25: Subproceso Simulación 1/2 71

89 Ilustración 26: Subproceso Simulación 2/2 72

90 Descripción Este subproceso está definido para que el radioterapeuta no tenga que ir avanzando de forma manual en las tareas de muestra de formularios, sino que, a diferencia del resto de subprocesos, éstas se mostrarán de forma automática una vez sean completadas. En primer lugar se generará el formulario de colocación del paciente y una vez verificados todos los parámetros, se registrará en la base de datos y se pasará a la tarea de verificación de parámetros en la dosis, que de la misma forma que la tarea anterior, deberá de ser correctamente completada para finalmente pasar a su informe de resultado, en el que el radioterapeuta informará de una forma concisa todo lo referente a los resultados finales de la simulación. Estos resultados serán enviados al oncólogo que aceptará o declinará este informe y en función de su decisión, se volverá a repetir el subproceso, o pasará definitivamente al subproceso de aplicación. 73

91 Aplicación del Tratamiento Diagramas Ilustración 27: Subproceso Aplicación del Tratamiento 1/3 74

92 Ilustración 28: Subproceso Aplicación del Tratamiento 2/3 75

93 Ilustración 29: Subproceso Aplicación del Tratamiento 3/3 76

94 Descripción Este subproceso está definido para que el radioterapeuta no tenga que ir avanzando de forma manual en las tareas de muestra de formularios, sino que, a diferencia del resto de subprocesos, éstas se mostrarán de forma automática una vez sean completadas. Su ejecución será muy parecida al subproceso de Simulación, con algunas diferencias. En primer lugar, se registrará la acción de Recepción de Cita, y posteriormente, se mostrará un formulario al radioterapeuta con el informe general del tratamiento. Una vez mostrados estos datos se continuará con la tarea de colocación del paciente en el lugar adecuado, para que el tratamiento a recibir sea el correcto. Para ello, el radioterapeuta tendrá que verificar y aceptar todos los parámetros recibidos en el formularios de Colocación y una vez completado se pasará a la verificación de los datos de irradiación. Antes de verificar los datos de irradiación, el sistema comprobará el funcionamiento y estado del PPS, que una vez aceptados todos los parámetros de posicionamiento, se moverá hasta las coordenadas exactas. Mientras se realiza esta operación, a través del sistema de monitorización, se podrá comprobar su estado de actividad, generando a su vez un registro de estado. Una vez concluida esta fase, el proceso mostrará el formulario de Verificación de Parámetros. De una forma similar el proceso de Verificación de Parámetros deberá de ser completado, comprobando su estado y aceptándolos, para poder continuar con el tratamiento. Y de la misma forma que el PPS, el TDD, será registrado y monitorizado, mientras se coloca en su posición, pudiendo ver su estado, antes de pasar al formulario de Informe Resultado. 77

95 En este informe el radioterapeuta, completará un informe, que será enviado al oncólogo, sobre el resultado de la sesión de tratamiento, generando a su vez el registro correspondiente. Finalmente este informe será almacenado en el historial del paciente, para futuras comprobaciones. 78

96 6. MANUAL DE USUARIO A continuación se detallarán todos los pasos necesarios para un buen manejo de la aplicación. Estas especificaciones están basadas bajo la versión actual, pero a medida que se vaya contemplando o modificando el contenido, debe indicarse la versión de la guía y mantener el registro de cambio por versiones. Esta guía se espera que sirva como referencia tanto a usuarios que quieran dar sus primeros pasos en la aplicación, como a los procesos de formación necesarios para su manejo Introducción Dentro de las diferentes técnicas de radioterapia existentes, el sistema se centrará en la radioterapia por haz externo. El proceso objeto de estudio abarca desde que el paciente visita al oncólogo hasta que se le aplica el tratamiento apropiado. Queda fuera del ámbito de dicho proceso tanto la gestión de citas (tanto la cita inicial como las citas intermedias) como el diagnóstico previo realizado al 79

97 paciente (consulta con el médico de cabecera, pruebas radiológicas como TAC o radiografías, etc.) Descripción General de RO Information System Como cualquier aplicación Web, el acceso a la aplicación deberá de realizarse a través de un navegador Web. El sistema ha sido orientado a un perfecto funcionamiento bajo el entorno de Mozilla Firefox, aunque se debe decir, que de la misma forma, ha sido diseñado para su ejecución en cualquier otro navegador Acceso al Sistema El acceso al sistema se puede realizar de diferentes formas, dependiendo del objetivo que se persiga, detalladas a continuación: Versión PC: Adaptada para la ejecución en PC con una resolución de 1280x800 o superior. Será la indicada para el oncólogo y el dosimetrista. El acceso a la aplicación se realizará introduciendo la siguiente dirección en su navegador: Ilustración 30: RT: Pantalla de Acceso 80

98 Version Mobile : Adaptada para una ejecución bajo un dispositivo portátil de una resolución no superior a 1024x600. Las pruebas ejecutadas bajo esta versión, han sido realizadas con el UMPC Q1 Ultra de Samsung. Esta versión está orientada al uso del radioterapeuta en el laboratorio de tratamientos. El acceso a la aplicación se realizará introduciendo la siguiente dirección en su navegador: Ilustración 31: RT: Pantalla de Acceso "Mobile" Monitor del Sistema: Sistema de monitorización de registro de cada uno de los tratamientos. Únicamente accesible para el administrador. El acceso a la aplicación se realizará introduciendo la siguiente dirección en su navegador: 81

99 Ilustración 32: RT: Pantalla de Acceso Monitor Tanto para la versión PC, como para la versión Mobile, se solicitará un usuario y contraseña para poder acceder de manera segura al sistema. Por el contrario, para la visualización del monitor, únicamente será requerido en número de proceso, necesario para identificar un tratamiento concreto. Una vez dentro del sistema, la pantalla principal, tendrá el aspecto detallado en la Ilustración 33. Ilustración 33: RT: Pantalla Principal 82

100 En esta pantalla principal se puede observar a la izquierda el menú donde, de forma automática, se irán cargando las tareas pendientes en cada caso. De la misma forma, sobre la parte derecha se cargarán los formularios necesarios para llevar a cabo el proceso y finalmente, sobre la parte superior derecha se visualizará un botón de desconexión y un icono representativo de cada uno de los tipos de especialistas que podrán acceder al sistema: Oncólogo ( ). Dosimetrista ( Radioterapeuta( ). ) Funcionalidades del Sistema de Radioterapia Para facilitar el estudio se divide el proceso en una serie de subprocesos que se realizan de forma secuencial. Para cada subproceso se detalla la siguiente información: Definición. Objetivo. Responsable del subproceso completo. Procedimientos a realizar, indicando la persona encargada de cada procedimiento, así como, las pantallas del sistema en ejecución. Dentro de cada uno de los formularios a completar a lo largo del proceso, muchos de los campos serán necesarios para la integridad del tratamiento, por ello, han sido marcados ( ) para informar de su necesidad. No será posible avanzar en el proceso hasta que todos los campos marcados sean completados. 83

101 De la misma forma, un elemento presente en todos los formularios es la opción de Visualizar Imágenes ( ), que facilitará el acceso a la aplicación de visualización de imágenes DICOM, tomadas y asociadas al paciente desde cualquier punto del proceso. Evaluación Inicial Definición Etapa clínica en la que el médico especialista en Oncología Radioterápica, valora el estado del paciente, tipo y extensión de la enfermedad y posibilidades terapéuticas aplicables. A partir de ese informe se realizará el documento de Decisión Terapéutica que seleccionará, entre las modalidades de tratamiento posibles, aquella cuyos objetivos, metodología y desarrollo se adapten mejor a las necesidades y deseos del paciente. Objetivo Obtener los datos que permitan ofrecer la mejor opción terapéutica y decidir la decisión terapéutica óptima para cada situación clínica, necesidades y deseos del paciente con relación a los medios disponibles. Responsable Oncólogo. 84

102 Procedimientos Cuando el oncólogo entra al sistema se le mostrará una lista de las tareas pendientes dentro del menú de la derecha con los siguientes datos: Tarea: Las tareas que aplican en este punto serán del tipo Evaluación inicial. Paciente: El paciente a evaluar. Hora: La hora teórica a la que se debería atender al paciente. Una vez que el paciente llegue a la consulta del oncólogo, éste seleccionará la entrada correspondiente del listado anterior. En este momento, el sistema obtendrá la información detallada del paciente. La información que se le presentará al oncólogo será la siguiente: Datos del paciente. Datos de pruebas complementarias. Con esta información el oncólogo deberá rellenar los siguientes datos: Anamnesis. Exploración Física. Diagnóstico Nosopatológico. Diagnóstico de Extensión de la Enfermedad. Evaluación de factores de riesgo (otros tratamientos y patología asociada). 85

103 Petición de Pruebas complementarias (en caso de ser necesarias). Ilustración 34: RT: Evaluación Inicial 1/2 Ilustración 35: RT: Evaluación Inicial 2/2 86

104 Una vez completada toda la información relativa a la exploración inicial del paciente, su caso será analizado para poder proponer un tratamiento lo más ajustado a sus necesidades. Este análisis, será completado con los datos siguientes: Selección del objetivo del tratamiento (curativo, paliativo, etc.). Elección de la modalidad de tratamiento. Definición del Volumen tumoral y vías de diseminación. Definición de tejidos a irradiar con fines preventivos. Identificación de los tejidos u órganos sensibles o críticos. Ilustración 36: RT: Decisión Terapéutica 1/2 87

105 Ilustración 37: RT: Decisión Terapéutica 2/2 Una vez completada la decisión terapéutica el oncólogo tendrá una tarea pendiente en su listado de tareas que se corresponderá con la presentación del tratamiento al paciente. El listado será similar al mostrado en la Ilustración 34: RT: Evaluación Inicial 1/2 con la salvedad de que la tarea será de tipo Comunicación y Aceptación. Una vez que el paciente llega a la consulta del oncólogo, éste selecciona la entrada correspondiente del listado anterior, y procederá a la presentación del tratamiento previsto al paciente. El paciente en este momento deberá dar su conformidad mediante su firma. El mecanismo de firma podría ser el DNI electrónico, pero por simplificar se asume que el paciente firmará mediante el formulario impreso en papel. 88

106 Ilustración 38: RT: Aceptación del tratamiento por parte del paciente En el caso de que el paciente no acepte el tratamiento, el proceso de radioterapia habrá finalizado. En el caso en que lo acepte, se continuará con el subproceso siguiente. Localización Definición Etapa clínico-técnica en la que el Oncólogo delimita el tejido tumoral y los órganos críticos para la planificación del tratamiento. Objetivo Definir y delimitar los volúmenes de tejido a irradiar y proteger. Responsable Oncólogo. 89

107 Procedimientos Cuando el oncólogo entre al sistema se le presentará la lista de las tareas pendientes que tiene para el día actual. El listado será similar al mostrado en la Ilustración 34: RT: Evaluación Inicial 1/2 aunque en este caso las tareas serán de tipo Localización. Como resultado del subproceso anterior, el oncólogo tendrá una tarea por cada paciente que haya finalizado dicho subproceso. Una vez que el radiofísico selecciona la tarea en cuestión, visualizará la decisión terapéutica propuesta, así como las imágenes almacenadas en el PACS a través del enlace a la aplicación de visualización de imágenes (imágenes tomadas previamente al proceso de radioterapia). Ilustración 39: RT: Informe de Localización 1/2 90

108 Ilustración 40: RT: Informe de Localización 2/2 A partir del informe dosimétrico y de las imágenes que se podrán visualizar mediante el visor DICOM, el oncólogo deberá completar el formulario de localización, que servirá como referencia tanto para el dosimetrista, como para el radioterapeuta en el plan de irradiación y simulación respectivamente. Plan de Irradiación Definición Etapa clínico-técnica en la que se hace una propuesta terapéutica en cuanto a las dosis necesarias en el tratamiento, en base a la enfermedad, el estado del paciente, los medios disponibles y la experiencia. Objetivo Obtener el plan de tratamiento óptimo para cada situación y paciente. Responsable Dosimetrista 91

109 Procedimientos Cuando el dosimetrista entre al sistema se le presentará la lista de las tareas pendientes que tiene para el día actual. El listado será similar al mostrado en la Ilustración 34: RT: Evaluación Inicial 1/2 aunque en este caso las tareas serán de tipo Preparación informe dosimétrico. Como resultado del subproceso anterior, el dosimetrista tendrá una tarea por cada paciente que haya finalizado dicho subproceso. Una vez que el dosimetrista selecciona la tarea en cuestión podrá visualizar los datos del paciente, así como la localización definida en el subproceso anterior, y podrá establecer las dosis adecuadas. Ilustración 41: RT: Informe Dosimétrico 1/2 92

110 Ilustración 42: RT: Informe Dosimétrico 2/2 Una vez que el dosimetrista haya finalizado el informe se enviará al oncólogo para su supervisión. Por tanto, en este punto, el oncólogo tendrá una tarea pendiente de Comunicación y Aceptación. Una vez que el oncólogo seleccione la tarea en cuestión visualizará toda la información relativa al paciente, así como el informe de localización y el plan de irradiación, y podrá aceptar o denegar el tratamiento. Ilustración 43: RT: Aceptación del Oncólogo 93

111 En el caso de que el oncólogo acepte el tratamiento el proceso continuará. En caso contrario, habrá que repetir plan de irradiación, teniendo en cuenta las observaciones que haya rellenado el oncólogo. Simulación del Tratamiento Definición Etapa clínica en la que se reproduce de forma fidedigna y documentada, las condiciones del tratamiento prescrito, que se lleva a cabo antes de iniciarlo. Objetivo Verificar que las características del tratamiento previsto se ajustan a las necesidades del paciente en cuanto a su enfermedad, anatomía y posición en la mesa de la unidad. Responsable Radioterapeuta. Procedimientos A través del dispositivo móvil elegido, el radioterapeuta entrará al sistema que le presentará la lista de las tareas pendientes, las cuales serán de tipo Simulación de tratamiento. Como resultado del subproceso anterior, el radioterapeuta tendrá una tarea por cada paciente que haya finalizado dicho subproceso. Una vez que el radioterapeuta selecciona la simulación a realizar, dicha simulación constará de dos etapas: 94

112 Colocación: Ilustración 44: RT: Simulación - Colocación En esta primera etapa de la simulación, el radioterapeuta procederá a la colocación del paciente en la mesa de tratamiento, de acuerdo con la información proporcionada por el informe de localización recibido. Una vez comprobados todos los parámetros, y realizados todos los procedimientos manuales, el sistema de posicionamiento se situará en la posición adecuada y pasará a la segunda etapa. 95

113 Verificación: Ilustración 45: RT: Simulación - Verificación de parámetros Una vez colocado el paciente de la forma acordada en la mesa de tratamiento y la mesa situada en la posición adecuada, el radioterapeuta podrá comenzar a verificar los datos de dosimetría recibidos en el informe dosimétrico. Una vez completada la simulación se presentará un formulario con los datos necesarios para la realización del informe de tratamiento simulado. 96

114 Ilustración 46: RT: Informe de Simulación Una vez que el radioterapeuta haya finalizado el informe se enviará al oncólogo para su supervisión. Por tanto, en este punto, el oncólogo tendrá una tarea pendiente de Aceptación de la simulación. Una vez que el oncólogo seleccione la tarea en cuestión visualizará el informe de simulación y podrá aceptar o denegar la misma. Ilustración 47: RT: Aceptación de la Simulación 97

115 En el caso de que el oncólogo acepte la simulación, el proceso continuará. En caso contrario, comenzará de nuevo, desde la localización, a generar un tratamiento adecuado, ya que se supone que el plan del tratamiento es incorrecto. Aplicación del Tratamiento Definición Etapa clínica en la que se lleva a cabo la irradiación terapéutica, reproduciendo en cada sesión los parámetros de irradiación y posición del paciente, que estarán contenidos en el informe dosimétrico y ficha de tratamiento. Objetivo Reproducir en cada sesión de tratamiento el plan terapéutico previsto y especificado en el informe dosimétrico y ficha de tratamiento. Responsable Radioterapeuta. Procedimientos A través del dispositivo móvil elegido, el radioterapeuta entrará al sistema que le presentará la lista de las tareas pendientes, las cuales serán de tipo Aplicación de tratamiento. Como resultado del subproceso anterior, el radioterapeuta tendrá una tarea por cada paciente que haya finalizado dicho subproceso. En primer lugar, el sistema mostrará un informe con toda la información del tratamiento a realizar. 98

116 Ilustración 48: RT: Inicio de Aplicación Con toda esta información el radioterapeuta podrá comenzar el tratamiento, avanzando a través de los formularios, que se deberán de ir cumplimentando para poder ir avanzando a lo largo del proceso de tratamiento. De esta forma se asegurará que todas las tareas son realizadas. El primer paso será asegurarse de la correcta colocación del paciente para que posteriormente el sistema de posicionamiento se sitúe correctamente. 99

117 Ilustración 49: RT: Aplicación - Colocación Una vez que el radioterapeuta haya completado todos los pasos requeridos, el sistema de posicionamiento (el PPS) se colocará automáticamente en la posición adecuada. El siguiente paso será la verificación de los parámetros relativos a la dosis a aplicar, para posteriormente aplicar dicha dosis. Ilustración 50: RT: Aplicación - Verificación de parámetros 100

118 Una vez que el radioterapeuta haya finalizado el informe se enviará al oncólogo para su supervisión. Una vez que el oncólogo seleccione la tarea en cuestión visualizará el informe de la sesión y podrá añadir las observaciones que estime convenientes, dándose por finalizado el proceso de radioterapia. Una vez que el oncólogo rellene el informe final, el tratamiento se dará por concluido. Además, el informe final será almacenado en el HIS como parte del historial clínico del paciente. Ilustración 51: RT: Informe de Aplicación Funcionalidades del Sistema de Monitorización El acceso a esta funcionalidad, será realizado a través de la pantalla de acceso (Ilustración 32: RT: Pantalla de Acceso Monitor), que solicitará el número de proceso asociado al tratamiento. El administrador del sistema será el único usuario capacitado para acceder a esta opción. Las funcionalidades concretas de la pantalla de monitorización serán: Visualización de todos los registros generados y asociados a cada uno de los pasos del procesos de tratamiento. Estos registros estarán compuestos por nombre de tarea, descripción de la tarea, usuario que la realiza, hora y fecha de finalización. 101

119 Los sistemas de posicionamiento y aplicación de tratamiento serán gráficamente monitoriazados mediante unos gráficos que indicarán el estado de funcionamiento en ese momento. Los sistemas monitorizados serán el PPS y el TDD y sus estados activo e inactivo. Ilustración 52: RT: Monitor del Sistema Funcionalidades del Visualizador DICOM El visualizador utilizado esta basado en la aplicación Radscaper, un potente applet en Java, orientado a la visualización de imágenes DICOM a través de la Web. Permitirá a cualquier usuario del sistema en cualquier momento del desarrollo del tratamiento poder acceder a las imágenes del paciente, pudiendo realizar las siguientes opciones: 102

120 Consultar información y datos del paciente incrustados en la imagen DICOM asociada. Contrastar diferentes imágenes, tomadas en diferentes periodos de tiempo, para observar su evolución. Medir distintos puntos de las imágenes para poder comparar su desarrollo. Ilustración 53: Radscaper 1 103

121 Ilustración 54: Radscaper 2 104

122 7. Planificación Temporal Se muestra el desarrollo que ha tenido el proyecto y la duración de cada una de las etapas a lo largo del año. 105

123 106

124 8. Conclusiones Una vez finalizado por completo el desarrollo del sistema, es un hecho el acierto de la elección de Intalio para el desarrollo e integración de los diagramas BPM y los formularios necesarios para la implementación del proceso. Este software de distribución libre, ha ayudado a poder integrar de una forma precisa todos los procesos necesarios, permitiendo a su vez, una fácil gestión de posibles modificaciones en futuros desarrollos. Se ha conseguido así, el objetivo de poder integrar los diferentes sistemas que rodean a esta aplicación, utilizando ésta, como una herramienta capaz de comunicar todos los elementos que componen un laboratorio oncológico, independientemente de su marca o modelo. El objetivo principal del estudio ha sido centrado en el análisis de los distintos procesos necesarios en la gestión del hospital, focalizándolo en las tareas necesarias para la realización de un diagnóstico y posterior tratamiento oncológico, y a raíz de todo el estudio realizado, se ha llegado a la conclusión de el enorme potencial que este campo puede llegar a tener en futuras aplicaciones, dada la escasa aportación al mercado, de aplicaciones de este estilo. 107

125 Por último, se considerá el resultado de este proyecto como una aproximación muy certera a las necesidades demandadas por el cliente y, a su vez, con una gran capacidad de proyección para desarrollos futuros en temas sanitarios. 108

126 9. Bibliografía [LARM02] Larman, C. (2002). UML Y PATRONES. Una introducción al análisis y diseño orientado a objetos y al proceso unificado. Madrid. Pearson Educación. [DEVE08] Deveboise, T. (2008). The Microguide to Process Modeling in BPMN. Lexinton (Virginia). Tipping Point Solutions [AREB01] Barranco de Areba, J. (2001). Metodología al análisis de estructurado de sistemas. Madrid. Universidad Pontificia Comillas de Madrid. [APAC04] The Apache Software Foundation. (2004). Apache Ant Manual. Disponible en la Web: [SKON01] Skonnard, A. (2001). Essential XML Quick Reference: A Programmer's Reference to XML, XPath, XSLT, SOAP, and More. Addison-Wesley Professional. [WEER05] Weerawarana, S. (2005). Web Services Platform Architecture: SOAP, WSDL, WS-Policy, WS-Addressing, WS-BPEL, WS-Reliable Messaging, and More.Prentice Hall. 109

127 [INTA06] Intalio, PXE Confluence Wiki DashBoard, Disponible en la Web: [INTA08] Intalio, Help section. Disponible en la Web: [WHIT05] White, S. (2005). Using BPMN to Model a BPEL Process. BPTrends. [IHE05] IHE. (2005). IHE Radiology User s Handbook. Integrating the Healthcare Enterprise. 110

128 Apéndice A. Introducción a BPMN QUÉ ES BPM? BPM (Business Process Management), o BPMS (BPM Suite) es el conjunto de servicios y herramientas que facilitan la administración de procesos de negocio. Por administración de procesos se entiende: análisis, definición, ejecución, monitorización, y control de los procesos. BPM además contempla soporte para interacción humana, e integración de aplicaciones, y es aquí la diferencia fundamental con la tecnología de WorkFlow existente, que es que BPM integra en los flujos a los sistemas. En resumen, se puede decir que BPMN proporciona un lenguaje común para que las partes involucradas puedan comunicar los procesos de forma clara, completa y eficiente. De esta forma BPMN define la notación y semántica de un Diagrama de Procesos de Negocio (Business Process Diagram, BPD). 111

129 BPD es un diagrama diseñado para representar gráficamente la secuencia de todas las actividades que ocurren durante un proceso, basado en la técnica de Flow Chart, considerando además toda la información necesaria para el análisis. Las soluciones del tipo WorkFlow sólo se limitaban a definir el flujo de actividades humanas o de documentos, y con esto obtener el seguimiento de los procesos, pero en estos casos si un participante del proceso requería como parte de sus actividades ingresar datos en una aplicación, entonces debía salir del ambiente del WorkFlow, levantar la aplicación, y luego de terminada su operación volver al WorkFlow y registrar el cambio de estado, o termino de la actividad. En BPM todo está integrado en el mismo flujo, lo que es más natural para un participante. De esta forma, el participante completa su actividad dentro del flujo BPM y, tras el proceso en curso, se actualizan los sistemas oportunos. Ilustración 55: Diagrama sencillo BPM 112

130 En la práctica un flujo BPMN visualmente es muy parecido a un WorkFlow, la diferencia está en que uno puede notar que ciertas actividades son realizadas por personas, y otras son actividades sistematizadas (realizadas por sistemas), y ambas aparecen en el flujo. POR QUÉ UTILIZAR BPMN? BPMN es un estándar internacional de modelado de procesos aceptado por la comunidad. BPMN es independiente de cualquier metodología de modelado de procesos. BPMN crea un puente estandarizado para disminuir la brecha entre los procesos de negocio y la implementación de estos. BPMN permite modelar los procesos de una manera unificada y estandarizada permitiendo un entendimiento a todas las personas de una organización. En BPM el modelo del proceso se convierte en el núcleo de la implementación del proceso como solución tecnológica. El modelo del proceso de negocio (su diseño) que realiza el área de negocios de una empresa es en sí lo que se ejecuta sobre el servidor de procesos (el motor de BPM). Dicho en otras palabras: la lógica de negocio principal que antes bajo las tecnología tradicional se debía programar, y colocar sobre un servidor de aplicaciones (tradicional), ahora se reemplaza por un modelo que se sube al servidor de procesos con mucho menos intervención del área de TI (menos programación). 113

131 En la práctica una buena solución BPM debería poder ejecutar un proceso modelado por el área de negocio, sin la necesidad de que TI tenga que programar una sola línea de código, y obtener como solución algo equivalente a un WorkFlow Tradicional (sin integración de sistemas). Luego el área de TI debería tomar este workflow, e implementar los formularios de entrada (de interacción con usuarios), y los servicios (las actividades automatizadas) para completarlo en un flujo BPM. BUSINESS PROCESS MODELING NOTATION Explicación de forma gráfica de la notación utilizada dentro de este lenguaje de procesos. Eventos A) Introducción Los Eventos son sucesos que afectan a la ejecución del proceso de negocio. Todo modelo debe incluir tres tipos fundamentales: Start: Lanzará la instancia de comienzo del modelo de negocio. Intermediate: Indica cuándo un evento debe suceder durante la ejecución del modelo de Ilustración 56: Eventos I negocio. End: Indica cómo y cuándo un flujo del proceso acaba. 114

132 B) Tipos Un evento cualquiera puede ser claramente definido utilizando su símbolo adecuado. La semántica de algunos eventos puede ser interpretada en varios sentidos. Por ejemplo, un evento intermedio tipo Mensaje puede indicar que el sistema envía o recibe datos. Por ello, y con el objetivo de esclarecer este comportamiento, se han definido dos grupos principales de símbolos, que ayudarán a mostrar de una manera gráfica adecuada su significado en el modelo de procesos: Catching: Referencia a una semántica de recepción de flujos de información a través del modelo. Throwing: Referencia a una semántica de envío de flujos de información a través del modelo. Ilustración 57: Eventos II 115

133 Actividades Una actividad es una unidad de trabajo dentro del modelo que debe llevarse a cabo. Puede ser una tarea o un subproceso. Se representará mediante un rectángulo con esquinas redondeadas. Determinadas marcas ayudarán a especificar sus atributos. Las especificaciones de BPMN dan las siguientes definiciones: Una Tarea es una actividad atómica que se utiliza cuando el trabajo en el proceso no es descompuesto en más detalle. Es ejecutada por una persona y/o una aplicación. Ilustración 58: Actividades I Un Subproceso es una actividad compuesta que es incluida dentro de un proceso. Es compuesto dado que esta figura incluye a su vez un conjunto de actividades y una secuencia Ilustración 59: Actividades II lógica (proceso) que indica que dicha actividad puede ser analizada en más detalle. Visualmente podrá mostrarse colapsado o expandido. GateWays Son elementos del modelado que se utilizan para controlar la divergencia y la convergencia del flujo. Tipos Exclusive Data-Based Gateway XOR Actúa como un punto de decisión donde varios flujos de salida son posibles y a su vez todos ellos están bajo una serie de condiciones, que sólo uno de los flujos de salida Ilustración 60: GateWays I 116

134 será capaz de cumplir. Esa condición será evaluada basándose en el proceso de datos. A su vez, esta compuerta puede ser utilizada también para la unión de varios flujos en uno. Exclusive Event-Based Gateway XOR Es similar al Exclusive Data-Based Gateway, la única diferencia es que, en vez de evaluar un conjunto de Ilustración 61: GateWays II alternativas para determinar cual de ellas será el flujo de salida, esta compuerta comenzará una carrera entre los distintos eventos que el proceso debe recibir y el primero en ser recibido, determinara que flujo de salida será el utilizado. Inclusive Gateway XOR Se utilizará como un punto de decisión donde varios flujos de procesos son posibles, que serán elegidos en función de una serie de condiciones, que en caso de ser cierta, pasarán a ejecutarse. Ilustración 62: GateWays III Usándolo como punto de unión de varios flujos, sincronizará todas las ejecuciones de éstos, comenzando el flujo de datos siguiente, una vez finalizados todos los flujos de entrada. Parallel Gateway AND Proporciona una solución para la bifurcación y sincronización de flujos. Ilustración 63: GateWays IV 117

135 Swimlanes Muchas técnicas de modelados utilizan el concepto de swimlanes como mecanismo de organización de actividades en categorías visuales separadas para ilustrar las diferentes capacidades funcionales o responsabilidades. Tipos Pools Un Pool representa un Participante en un Proceso, actuando como contenedor gráfico para separar al grupo de actividades realizadas por un participante de otros Pools. Se utilizan generalmente en el contexto de situaciones B2B (Business To Business) y cuando los diagramas involucran a dos entidades de negocios o participantes separados. Están físicamente separados en el diagrama. Las actividades dentro de Pools separados son consideradas auto contenidas en el proceso. De esta forma, la secuencia del flujo podría no atravesar el límite del Pool. Los flujos de mensajes son los mecanismos que muestran la comunicación entre dos participantes, conectando de esta manera a dos Pools. Lane Un Lane es una partición dentro de un pool y se extiende a lo largo de todo el pool, tanto vertical como horizontalmente. Ilustración 64: Pools 118

136 Son usados para organizar y categorizar actividades y son más cercanos a los swimlanes que tradicionalmente se utilizan para modelar procesos de negocio. Separan actividades asociadas con una función específica de la organización. La secuencia de flujos podría atravesar los límites del Lane dentro de un Pool, pero podrían no usarse flujos de mensajes entre Flow Objects en Lanes del mismo Pool. Conectors BPMN define una serie de flechas para conectar las distintas tareas, eventos y demás elementos. Son utilizados para: Describir el orden en el que los diferentes pasos del proceso deben de ser ejecutados. Añadir información adicional, como por ejemplo comentarios. Describir como los mensajes deben de ser intercambiados entre los diferentes swimlanes. Ilustración 65: Conectors I Tipos Flujos de Secuencia Se utilizan para conectar elementos del flujo de procesos como tareas, eventos o compuertas para poder así especificar de una manera clara su orden de ejecución. Dentro de ese tipo de flujos se encuentran tres subcategorías: 119

137 Standard Sequence Flow: Indica que una vez que el paso actual sea finalizado, se podrá pasar al siguiente paso Ilustración 66: Conectors II indicado por su sentido. Conditional Sequence Flow: Indica que una vez que el paso actual sea finalizado, y sólo si la condición asociada a Ilustración 67: Conectors III este flujo es verdadera, se podrá pasar al siguiente paso indicado por su sentido Default Sequence Flow: Cuando un determinado paso tiene varias Conditional Sequence Flows de salida y tras Ilustración 68: Conectors VI su evaluación serán consideradas como falsas, se utilizará este flujo para la continuación del proceso. Flujos de Mensajes Se utilizan para la representación de los diferentes flujos de mensajes que son posibles de intercambiar entre Ilustración 69: Conectors V procesos. Asociaciones Utilizados para asociar información y artefactos con los distintos objetos del flujo. Ilustración 70: Conectors VI 120

138 Anotaciones de Texto Información adicional debe de ser añadida con el objetivo de documentación a través de las Anotaciones de Ilustración 71: Conectors VII Texto. Reglas de Conexión Ilustración 72: Flujos de Secuencia Ilustración 73: Flujos de Mensajes Esta dos tablas serán de gran utilidad para conocer las posibles conexiones entre los diferentes elementos de un posible diagrama BPM. 121

139 Apéndice B. Servicios Web A) DESCRIPCIÓN DE LOS SERVICIOS WEB Introducción Los servicios Web (WS) son aplicaciones que pueden ser descritas, publicadas, localizadas e invocadas a través de una red, generalmente Internet. Dicho de una manera más formal, los servicios Web son componentes de software alojados en servidores Web públicos o privados por Internet a los que se accede mediante mensajes del protocolo SOAP (también se podrían usar los mensajes XML-RPC, aunque es SOAP el protocolo más usado actualmente) codificados en formato XML a través de protocolos estándares de aplicación (HTTP, SMTP, FTP, etc.) y que proporcionan un servicio a los correspondientes clientes de software. Para hacerse una idea rápida de cómo funciona un servicio Web se puede decir que es una llamada a un procedimiento remoto (RPC) basada en HTTP/SOAP. Los servicios Web se basan en una colección de protocolos y estándares abiertos que sirven para intercambiar datos entre aplicaciones. Las organizaciones 122

140 OASIS y W3C son los responsables de la arquitectura y reglamentación de los servicios Web. Para mejorar la interoperabilidad entre distintas implementaciones de servicios Web se ha creado el organismo WS-I encargado de definir de manera más exhaustiva estos estándares. Algunas de las ventajas de los servicios Web son: Al estar basado en estándares aportan interoperabilidad entre aplicaciones de software independientemente de la plataforma, sistema operativo y lenguaje de programación. Los servicios Web fomentan los estándares y protocolos basados en texto, que hacen más fácil acceder a su contenido y entender su funcionamiento. Al apoyarse en HTTP (en el caso de que usen este protocolo como transporte), los servicios Web pueden aprovecharse de los sistemas de seguridad (firewalls) sin necesidad de cambiar las reglas de filtrado. También existen algunos inconvenientes como son: Su rendimiento es bajo si se compara con otros modelos de computación distribuida, tales como RMI, CORBA o DCOM. Es uno de los inconvenientes derivados de adoptar un formato basado en texto ya que entre los objetivos de XML no se encuentra la concisión ni la eficacia de procesamiento. Para realizar transacciones (conjunto de operaciones que se deben ejecutar como una unidad, es decir, o se hacen todas o ninguna) no puede compararse con plataformas como CORBA. La arquitectura de comunicaciones de los servicios Web (organizada por niveles y protocolos implicados) se puede ver en la siguiente figura. 123

141 Ilustración 74: Arquitectura de comunicaciones de los servicios Web En el nivel de transporte de la arquitectura están los protocolos de Internet existentes que permiten activar servicios Web. Estos protocolos se encargan de transportar los mensajes entre las aplicaciones. Los servicios Web pueden utilizar muchos protocolos de transporte, si bien es el protocolo HTTP el más usado. En el nivel de mensajería están los protocolos que indican cómo se comunican clientes y servidores y la sintaxis de los mensajes intercambiados, de modo que ambos extremos de la comunicación puedan comprenderlos. Por tanto, este nivel es el responsable de la creación, codificacióndecodificación en un formato XML y envío de los correspondientes datos. En este nivel, existen dos posibles protocolos, SOAP y XML-RPC, aunque actualmente es el protocolo SOAP el más utilizado ya que los principales entornos para desarrollar servicios Web (Axis, Apache SOAP,.NET, etc.) utilizan este protocolo. El nivel de descripción del servicio es un nivel intermedio para que los servicios Web pasen del nivel de mensajería al nivel más alto de descubrimiento y publicación. En este nivel, el lenguaje WSDL de definición de servicios Web proporciona una serie de mecanismos para que un 124

142 proveedor de servicios publique un documento WSDL con detalles sobre un servicio en particular y cómo acceder a él. El nivel de descubrimiento y publicación del servicio se utiliza para encontrar y publicar los servicios Web que proporcionan una funcionalidad determinada. El protocolo universal de descripción, descubrimiento e integración (UDDI) es una especificación de un servicio de directorio o servicio Web al que puede acceder la máquina que proporciona estos servicios. De hecho, los registros UDDI son servicios Web y se acceden a ellos a través de SOAP vía HTTP. A continuación se describen los protocolos más importantes de cada nivel: XML-RPC: XML-Remote Procedure Call XML-RPC es un protocolo para ejecutar llamadas a procedimientos remotos (RPC) que funciona sobre Internet. XML-RPC funciona mediante el intercambio de mensajes entre el cliente del servicio y el servidor, usando el protocolo HTTP para el transporte de dichos mensajes. Concretamente, XML-RPC utiliza peticiones POST de HTTP para enviar los mensajes, en formato XML, indicando: El procedimiento que se va a ejecutar en el servidor. Los parámetros que se necesitan para ejecutar dicho procedimiento. XML-RPC maneja un conjunto de tipos para el paso de parámetros, valores de retorno y errores. Estos tipos se representan mediante etiquetas XML. Existen tipos básicos y tipos compuestos: 125

143 Tipos básicos: <int> o <i4>: Enteros de 32 bits. <double>: Coma flotante de 64 bits. <boolean>: Verdadero o falso. <string>: Texto ASCII (y UNICODE). <datetime.iso8601> Fecha en formato ISO8601. <base64>: Binario codificado en base 64. Tipos compuestos: <array>: Información secuencial. <struct>: Contenido desordenado, identificable por nombre de campo. Una petición XML-RPC está formada por: Contenido XML: Contendrá el procedimiento al que se llama y los parámetros pasados en la llamada. Cabecera HTTP: Recubrimiento (wrapper) para enviar la petición por la Web. Será una cabecera de una petición HTTP POST. Una repuesta XML-RPC está formada por: Contenido XML: En caso de que la petición se haya ejecutado sin problemas contendrá un sólo parámetro, aunque este parámetro puede ser de tipo compuesto. En el caso de que haya habido problemas al ejecutar la llamada 126

144 (no se encuentra el procedimiento, no se ejecuta correctamente o no se puede devolver el resultado), en este contenido se indicará que ha habido el error y una descripción del error. Cabecera HTTP: Recubrimiento para enviar la respuesta por la Web. Será una cabecera de una respuesta HTTP. Por último, hay que indicar que al estar basado en XML, XML-RPC es independiente de plataforma y de lenguaje de programación. SOAP: Simple Object Access Protocol Al igual que XML-RPC, SOAP es un protocolo de intercambio de información que usa documentos XML. SOAP es más complejo que XML-RPC aunque también más potente. Alguna de las características de SOAP son: Es independiente de plataforma y de lenguaje de programación ya que los mensajes SOAP están escritos en XML. Permite intercambiar documentos XML y otros tipos de documentos en las peticiones y respuestas. Los mensajes SOAP utilizan espacios de nombrados (namespaces) y esquemas XML (XML Schemas). Funciona sobre HTTP, FTP, SMTP, y algunos protocolos más, aunque es HTTP el protocolo más utilizado. No mantiene el estado. 127

145 Los mensajes SOAP tienen el aspecto mostrado en la siguiente figura: Ilustración 75: Estructura Mensaje SOAP A continuación se detalla cada uno de estos elementos: Envelope (obligatorio): Cada mensaje SOAP tiene un único <Envelope>. En este elemento se definen los espacios de nombres XML a utilizar. Mediante los espacios de nombres incluidos, SOAP puede diferenciar mensajes. Actualmente hay dos versiones: SOAP 1.1 y SOAP 1.2. Header (opcional): Contiene información de cómo se procesa el mensaje, como por ejemplo: encaminamiento, autenticación e identificación de transacción. Body (obligatorio): Contiene el mensaje a enviar o procesar. Normalmente este elemento se utiliza para incluir peticiones y respuestas RPC aunque también se puede utilizar para incluir documentos XML. Fault (opcional): Se utiliza para indicar errores del nivel de protocolo. En caso de que ocurra algún error se devuelve información como: el tipo de error, un mensaje de error explicativo, la URI del nodo que envía el error, mensajes de error explicativos de la aplicación, etc. 128

Christian Bolívar Moya Calderón

Christian Bolívar Moya Calderón UNIVERSIDAD SAN FRANCISCO DE QUITO Software Orientado a Sistemas de Control HMI/Scada usando Recursos Libres y de Código Abierto, desarrollado sobre Plataforma Linux Christian Bolívar Moya Calderón Tesis

Más detalles

Este proyecto tiene como finalidad la creación de una aplicación para la gestión y explotación de los teléfonos de los empleados de una gran compañía.

Este proyecto tiene como finalidad la creación de una aplicación para la gestión y explotación de los teléfonos de los empleados de una gran compañía. SISTEMA DE GESTIÓN DE MÓVILES Autor: Holgado Oca, Luis Miguel. Director: Mañueco, MªLuisa. Entidad Colaboradora: Eli & Lilly Company. RESUMEN DEL PROYECTO Este proyecto tiene como finalidad la creación

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

MONITORIZACIÓN WIRELESS DE INSTALACIÓN FOTOVOLTAICA DE 56 KW P EN EL PARQUE TECNOLÓGICO DE ANDALUCÍA BASADA EN LA TECNOLOGÍA OPC

MONITORIZACIÓN WIRELESS DE INSTALACIÓN FOTOVOLTAICA DE 56 KW P EN EL PARQUE TECNOLÓGICO DE ANDALUCÍA BASADA EN LA TECNOLOGÍA OPC MONITORIZACIÓN WIRELESS DE INSTALACIÓN FOTOVOLTAICA DE 56 KW P EN EL PARQUE TECNOLÓGICO DE ANDALUCÍA BASADA EN LA TECNOLOGÍA OPC * Sidrach-de-Cardona M., * Carretero J., * Pereña A., ** Mora-López L, **

Más detalles

WebRatio. Otro camino para el BPM. Web Models s.r.l. www.webratio.com contact@webratio.com 1 / 8

WebRatio. Otro camino para el BPM. Web Models s.r.l. www.webratio.com contact@webratio.com 1 / 8 WebRatio Otro camino para el BPM Web Models s.r.l. www.webratio.com contact@webratio.com 1 / 8 El BPM El BPM (Business Process Management) no es solo una tecnología, además a grandes rasgos es una disciplina

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

Curso 5007437. Capítulo 4: Arquitectura Orientada a Servicios. Conceptos y estándares de arquitecturas orientadas a servicios Web Curso 2006/2007

Curso 5007437. Capítulo 4: Arquitectura Orientada a Servicios. Conceptos y estándares de arquitecturas orientadas a servicios Web Curso 2006/2007 Curso 5007437 Conceptos y estándares de arquitecturas orientadas a servicios Web Curso 2006/2007 Capítulo 4: Arquitectura Orientada a Servicios Pedro Álvarez alvaper@unizar.es José Ángel Bañares banares@unizar.es

Más detalles

DISEÑO DE UN CRONOTERMOSTATO PARA CALEFACCIÓN SOBRE TELÉFONOS MÓVILES. Entidad Colaboradora: ICAI Universidad Pontificia Comillas.

DISEÑO DE UN CRONOTERMOSTATO PARA CALEFACCIÓN SOBRE TELÉFONOS MÓVILES. Entidad Colaboradora: ICAI Universidad Pontificia Comillas. DISEÑO DE UN CRONOTERMOSTATO PARA CALEFACCIÓN SOBRE TELÉFONOS MÓVILES Autor: Sánchez Gómez, Estefanía Dolores. Directores: Pilo de la Fuente, Eduardo. Egido Cortés, Ignacio. Entidad Colaboradora: ICAI

Más detalles

UNIVERSIDAD TECNOLÓGICA DE QUERÉTARO

UNIVERSIDAD TECNOLÓGICA DE QUERÉTARO UNIVERSIDAD TECNOLÓGICA DE QUERÉTARO Página de seguros Grupo Santos Adilene Lorenzo Sebastian 2011 Nombre del Proyecto: Página Web De Grupo Santos Nombre de la Empresa: Grupo Santos Memoria Que como parte

Más detalles

DISPOSITIVO DE CONTROL PARA REDES DE DISTRIBUCIÓN ELÉCTRICA RESUMEN DEL PROYECTO

DISPOSITIVO DE CONTROL PARA REDES DE DISTRIBUCIÓN ELÉCTRICA RESUMEN DEL PROYECTO I DISPOSITIVO DE CONTROL PARA REDES DE DISTRIBUCIÓN ELÉCTRICA Autor: Juárez Montojo, Javier. Director: Rodríguez Mondéjar, José Antonio. Entidad Colaboradora: ICAI-Universidad Pontificia Comillas RESUMEN

Más detalles

Sistema de gestión de procesos institucionales y documental.

Sistema de gestión de procesos institucionales y documental. [Documento versión 1.7 del 10/10/2015] Sistema de gestión de procesos institucionales y documental. El sistema de gestión de procesos institucionales y documental, es una solución diseñada para mejorar

Más detalles

UNIVERSIDAD DE OVIEDO

UNIVERSIDAD DE OVIEDO UNIVERSIDAD DE OVIEDO ESCUELA POLITÉCNICA DE INGENIERÍA DE GIJÓN MÁSTER EN INGENIERÍA INFORMÁTICA TRABAJO FIN DE MÁSTER SPRING ROO ADD-ONS PARA PROTOTIPADO RÁPIDO JAVIER MENÉNDEZ ÁLVAREZ JULIO 2014 UNIVERSIDAD

Más detalles

APLICATIVO WEB PARA LA ADMINISTRACIÓN DE LABORATORIOS Y SEGUIMIENTO DOCENTE EN UNISARC JUAN DAVID LÓPEZ MORALES

APLICATIVO WEB PARA LA ADMINISTRACIÓN DE LABORATORIOS Y SEGUIMIENTO DOCENTE EN UNISARC JUAN DAVID LÓPEZ MORALES APLICATIVO WEB PARA LA ADMINISTRACIÓN DE LABORATORIOS Y SEGUIMIENTO DOCENTE EN UNISARC JUAN DAVID LÓPEZ MORALES CORPORACIÓN UNIVERSITARIA SANTA ROSA DE CABAL CIENCIAS Y TECNOLOGÍAS DE INFORMACIÓN Y COMUNICACIÓN

Más detalles

Herramientas de Software que posibilitan el BPM

Herramientas de Software que posibilitan el BPM Qué es BPM? BPM (Business Process Management) no es solamente una tecnología, sino en términos generales, una disciplina gerencial que trata a los procesos como bienes tangibles que contribuyen al desempeño

Más detalles

P1 Elaboración de un plan de proyecto utilizando MS Project G3

P1 Elaboración de un plan de proyecto utilizando MS Project G3 UNIVERSIDAD DE CASTILLA-LA MANCHA ESCUELA SUPERIOR DE INFORMÁTICA P1 Elaboración de un plan de proyecto utilizando MS Project G3 José Luís Espinosa Aranda Noelia Vállez Enano Manuel Ramón Guerrero Álvarez

Más detalles

TFC. Ingeniería de Software MEMORIA. Consultor: Juan José Cuadrado Gallego

TFC. Ingeniería de Software MEMORIA. Consultor: Juan José Cuadrado Gallego TFC Ingeniería de Software Alumno: Halyna Klachko Consultor: Juan José Cuadrado Gallego Índice 1. Identificación del proyecto..5 1.1 Introducción...5 1.2 Objetivos del proyecto..5 1.3 Descripción general..5

Más detalles

CAPÍTULO V. Propuesta

CAPÍTULO V. Propuesta CAPÍTULO V Propuesta 5.1 Propuesta Implantación de una aplicación WEB para optimizar el Enlace Laboral de la Cámara de Comercio e Industria de El Salvador, Filial San Miguel 5.2 Requerimientos de la Aplicación

Más detalles

Universidad Autónoma Metropolitana

Universidad Autónoma Metropolitana Universidad Autónoma Metropolitana Unidad Azcapotzalco División de Ciencias Básicas e Ingeniería Licenciatura en Ingeniería en Computación Propuesta de Proyecto Terminal Composición de servicios web para

Más detalles

DIGITAL WAITER CARLOS ANDRES PEDRAZA VALDERRAMA RAMIRO ALBERTO PEDRAZA SANCHEZ

DIGITAL WAITER CARLOS ANDRES PEDRAZA VALDERRAMA RAMIRO ALBERTO PEDRAZA SANCHEZ 1 DIGITAL WAITER CARLOS ANDRES PEDRAZA VALDERRAMA RAMIRO ALBERTO PEDRAZA SANCHEZ CORPORACION UNIVERSITARIA MINUTO DE DIOS TECNOLOGIA EN INFORMATICA SOACHA 2012 2 DIGITAL WAITER CARLOS ANDRES PEDRAZA VALDERRAMA

Más detalles

Carestream RIS. Creación de un flujo de trabajo

Carestream RIS. Creación de un flujo de trabajo Creación de un flujo de trabajo Carestream RIS Un nuevo enfoque para automatizar el flujo de trabajo en su empresa Carestream RIS Necesita un flujo de trabajo mejor, pero se le plantean cuestiones relacionadas

Más detalles

INTEGRACIÓN DE IMÁGENES ELECTROCARDIOGRÁFICAS EN EL SERVICIO DE SALUD DE LAS ISLAS BALEARES

INTEGRACIÓN DE IMÁGENES ELECTROCARDIOGRÁFICAS EN EL SERVICIO DE SALUD DE LAS ISLAS BALEARES INTEGRACIÓN DE IMÁGENES ELECTROCARDIOGRÁFICAS EN EL SERVICIO DE SALUD DE LAS ISLAS BALEARES J. AMER 1, D. BOERNER 1, J. CAMPINS 1, D. GÁNDARA 1, E. GARCÍA 1, L. LAPRESA 2, S. RAMIS 3 1 Fundació IBIT, Palma

Más detalles

Contenidos. Parte I - Introducción Capítulo 1 - Evolución. Capítulo 2 Condiciones de trabajo en el Desarrollo de Software

Contenidos. Parte I - Introducción Capítulo 1 - Evolución. Capítulo 2 Condiciones de trabajo en el Desarrollo de Software IX Contenidos Prólogo... XIX Prefacio... XXI Guía de lectura...xxiii Parte I - Introducción Capítulo 1 - Evolución 1.1 Introducción... 2 1.2 Los hitos en la evolución histórica del desarrollo de software...

Más detalles

DESARROLLO DE APLICACIÓN MÓVIL PARA EMPRESA DE BIENES RAÍCES, VERSIÓN ANDROID

DESARROLLO DE APLICACIÓN MÓVIL PARA EMPRESA DE BIENES RAÍCES, VERSIÓN ANDROID DESARROLLO DE APLICACIÓN MÓVIL PARA EMPRESA DE BIENES RAÍCES, VERSIÓN ANDROID Vicente Moya Murillo (1) Ing. Patricia Chávez Burbano (2) Facultad de Ingeniería en Electricidad y Computación Escuela Superior

Más detalles

Sistema de Control Domótico

Sistema de Control Domótico UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO EN ELECTRÓNICA Y AUTOMATICA PROYECTO FIN DE CARRERA Sistema de Control Domótico a través del bus USB Directores:

Más detalles

Qué ofrece Autentia Real Business Solutions S.L?

Qué ofrece Autentia Real Business Solutions S.L? Avenida de Castilla,1 - Edificio Best Point - Oficina 21B 28830 San Fernando de Henares (Madrid) tel./fax: +34 91 675 33 06 info@autentia.com - www.autentia.com Qué ofrece Autentia Real Business Solutions

Más detalles

SCADA BASADO EN LABVIEW PARA EL LABORATORIO DE CONTROL DE ICAI

SCADA BASADO EN LABVIEW PARA EL LABORATORIO DE CONTROL DE ICAI SCADA BASADO EN LABVIEW PARA EL LABORATORIO DE CONTROL DE ICAI Autor: Otín Marcos, Ana. Directores: Rodríguez Pecharromán, Ramón. Rodríguez Mondéjar, José Antonio. Entidad Colaboradora: ICAI Universidad

Más detalles

HERRAMIENTA WEB PARA LA ELABORACIÓN DE TEST BAJO LA ESPECIFICACIÓN IMS-QTI

HERRAMIENTA WEB PARA LA ELABORACIÓN DE TEST BAJO LA ESPECIFICACIÓN IMS-QTI HERRAMIENTA WEB PARA LA ELABORACIÓN DE TEST BAJO LA ESPECIFICACIÓN IMS-QTI Muñoz-Bouchard J.P., y Álvarez-González L.A. jp.knap@gmail.com@gmail.com, lalvarez@inf.uach.cl Grupo de Investigación en Tecnologías

Más detalles

HISTORIA CLINICA DIGITAL (HCD)

HISTORIA CLINICA DIGITAL (HCD) HISTORIA CLINICA DIGITAL (HCD) DESCRIPCIÓN OBJETIVO La Agencia Pública Empresarial Sanitaria Hospital del Poniente (ASP) ha desarrollado durante cuatro años una Historia Clínica Digital (Plataforma Clínica)

Más detalles

SISTEMA INTEGRADO DE ADMINISTRACIÓN DOCUMENTAL SIMAD CLOUD. La Gestión Documental ahora en la nube, es más eficiente aurea

SISTEMA INTEGRADO DE ADMINISTRACIÓN DOCUMENTAL SIMAD CLOUD. La Gestión Documental ahora en la nube, es más eficiente aurea SISTEMA INTEGRADO DE ADMINISTRACIÓN DOCUMENTAL La Gestión Documental ahora en la nube, es más eficiente aurea SISTEMA INTEGRADO DE ADMINISTRACIÓN DOCUMENTAL El más potente programa para el manejo integral

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

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

TABLA DE CONTENIDOS. Dedicatoria. Agradecimientos. Tabla de Contenidos. Indice de Figuras. Indice de Tablas. Resumen

TABLA DE CONTENIDOS. Dedicatoria. Agradecimientos. Tabla de Contenidos. Indice de Figuras. Indice de Tablas. Resumen TABLA DE CONTENIDOS página Dedicatoria Agradecimientos Tabla de Contenidos Indice de Figuras Indice de Tablas Resumen I II III VII IX X 1. Introducción 11 1.1. Descripción del contexto local......................

Más detalles

JESÚS EDUARDO CORTÉS SÁNCHEZ

JESÚS EDUARDO CORTÉS SÁNCHEZ MÓDULOS ACTIVIDADES Y SERVICIOS DE BIENESTAR DEL SISTEMA DE INFORMACIÓN PARA LA DIVISIÓN DE BIENESTAR INSTITUCIONAL DE LA CORPORACIÓN UNIVERSITARIA SANTA ROSA DE CABAL UNISARC JESÚS EDUARDO CORTÉS SÁNCHEZ

Más detalles

Metodología BPM:RAD Rapid Analysis & Design para la modelización y diseño de procesos orientados a tecnologías BPM

Metodología BPM:RAD Rapid Analysis & Design para la modelización y diseño de procesos orientados a tecnologías BPM Metodología BPM:RAD - Rapid Analysis & Design Capítulo extraído de El Libro del BPM 2011 Metodología BPM:RAD Rapid Analysis & Design para la modelización y diseño de procesos orientados a tecnologías BPM

Más detalles

FOREST BPMS. Arquitectura Forest BPMS. Metodologia de implementación. Fase I Instalación

FOREST BPMS. Arquitectura Forest BPMS. Metodologia de implementación. Fase I Instalación FOREST BPMS Arquitectura Forest BPMS Metodologia de implementación Fase I Instalación 1. Instalación del sistema de información Forest en los servidores provistos por la entidad Entregable: Documento de

Más detalles

PROYECTO INFORMÁTICO PARA LA CREACIÓN DE UN GESTOR DOCUMENTAL PARA LA ONG ENTRECULTURAS

PROYECTO INFORMÁTICO PARA LA CREACIÓN DE UN GESTOR DOCUMENTAL PARA LA ONG ENTRECULTURAS PROYECTO INFORMÁTICO PARA LA CREACIÓN DE UN GESTOR DOCUMENTAL PARA LA ONG ENTRECULTURAS Autor: García Lodares, Victor. Director: Castejón Silvo, Pedro. Entidad Colaboradora: Entreculturas. Resumen del

Más detalles

Gestión de Trámites Académico Administrativos a través del Sistema de Trámites en la Universidad Técnica Particular de Loja

Gestión de Trámites Académico Administrativos a través del Sistema de Trámites en la Universidad Técnica Particular de Loja Gestión de Trámites Académico Administrativos a través del Sistema de Trámites en la Universidad Técnica Particular de Loja María Eugenia Enríquez, María Paula Espinosa, María Patricia Samaniego, a Dirección

Más detalles

Gerencia de Procesos de Negocio (Business Process Management, BPM). Lic. Patricia Palacios Zuleta

Gerencia de Procesos de Negocio (Business Process Management, BPM). Lic. Patricia Palacios Zuleta Gerencia de Procesos de Negocio (Business Process Management, BPM). Lic. Patricia Palacios Zuleta (Business Process Management, BPM). La Gerencia de los Procesos del Negocio: Se define como: "integración

Más detalles

APLICACIONES OPEN SOURCE PARA EL MONITOREO DE REDES IP. Ing. Yubaira Boyer Digitel, Caracas E-mail: yubira_boyer@digitel.com.ve

APLICACIONES OPEN SOURCE PARA EL MONITOREO DE REDES IP. Ing. Yubaira Boyer Digitel, Caracas E-mail: yubira_boyer@digitel.com.ve 1 APLICACIONES OPEN SOURCE PARA EL MONITOREO DE REDES IP. Ing. Yubaira Boyer Digitel, Caracas E-mail: yubira_boyer@digitel.com.ve RESUMEN. El Código abierto es el término por el que se conoce al software

Más detalles

Instalación: Instalación de un agente en una máquina cliente y su registro en el sistema.

Instalación: Instalación de un agente en una máquina cliente y su registro en el sistema. HERRAMIENTA DE MONITORIZACIÓN DE SISTEMAS Autor: Sota Madorrán, Iñaki. Director: Igualada Moreno, Pablo. Entidad Colaboradora: Evotec Consulting, S.L. RESUMEN DEL PROYECTO El proyecto consiste en el diseño,

Más detalles

UNIVERSIDAD CENTROCCIDENTAL "LISANDRO ALVARADO" DECANATO DE CIENCIAS Y TECNOLOGIA MAESTRIA EN CIENCIAS DE LA COMPUTACION MENCION REDES DE COMPUTADORAS

UNIVERSIDAD CENTROCCIDENTAL LISANDRO ALVARADO DECANATO DE CIENCIAS Y TECNOLOGIA MAESTRIA EN CIENCIAS DE LA COMPUTACION MENCION REDES DE COMPUTADORAS UNIVERSIDAD CENTROCCIDENTAL "LISANDRO ALVARADO" DECANATO DE CIENCIAS Y TECNOLOGIA MAESTRIA EN CIENCIAS DE LA COMPUTACION MENCION REDES DE COMPUTADORAS MODELO DE GESTION WBEM PARA ADMINISTRACION DE REDES

Más detalles

Programación en Capas.

Programación en Capas. Programación en Capas. Ricardo J. Vargas Del Valle Universidad de Costa Rica, Ciencias de Computación e Informática, San José, Costa Rica, 506 ricvargas@gmail.com Juan P. Maltés Granados Universidad de

Más detalles

UNIVERSIDAD OBERTA DE CATALUNYA. Herramienta Visual para Diseñar formularios Web WformDesigner

UNIVERSIDAD OBERTA DE CATALUNYA. Herramienta Visual para Diseñar formularios Web WformDesigner UNIVERSIDAD OBERTA DE CATALUNYA Herramienta Visual para Diseñar formularios Web WformDesigner Especialidad: Administración Web y comercio electrónico en entornos de software libre Autor: Wilman Chamba

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

UNIVERSIDAD DE LAS AMERICAS Facultad de ingeniería

UNIVERSIDAD DE LAS AMERICAS Facultad de ingeniería i UNIVERSIDAD DE LAS AMERICAS Facultad de ingeniería Desarrollo de un sistema de información tipo diccionario para ser implementado como servicio SMS Premium Trabajo de Titulación presentado en conformidad

Más detalles

CAPÍTULO 4 NORMA IEEE 1058.1 PARA LA PLANIFICACIÓN DE PROYECTOS SOFTWARE ESTE DOCUMENTO ES PARTE DEL SIGUIENTE TRABAJO:

CAPÍTULO 4 NORMA IEEE 1058.1 PARA LA PLANIFICACIÓN DE PROYECTOS SOFTWARE ESTE DOCUMENTO ES PARTE DEL SIGUIENTE TRABAJO: ESTE DOCUMENTO ES PARTE DEL SIGUIENTE TRABAJO: La norma IEEE 1058.1: Plan para la Gestión de Proyectos Software realizado por el alumno Ismael Caballero Muñoz-Reja para la asignatura Planificación y Gestión

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

OpenSource BPMS. José Nelson Pérez Castillo Universidad Distrital Francisco José de Caldas, Bogotá, Colombia, nelsonp@udistrital.edu.

OpenSource BPMS. José Nelson Pérez Castillo Universidad Distrital Francisco José de Caldas, Bogotá, Colombia, nelsonp@udistrital.edu. Seventh LACCEI Latin American and Caribbean Conference for Engineering and Technology (LACCEI 2009) Energy and Technology for the Americas: Education, Innovation, Technology and Practice June 2-5, 2009,

Más detalles

Automatización del Módulo Convenio-Seguros del Sistema Administrativo Financiero para el Hospital León Becerra

Automatización del Módulo Convenio-Seguros del Sistema Administrativo Financiero para el Hospital León Becerra Automatización del Módulo Convenio-Seguros del Sistema Administrativo Financiero para el Hospital León Becerra Mariuxi Salazar Piedra (1), Bryan Valencia Ronquillo (2), Lenin Freire Cobo (3) Escuela Superior

Más detalles

UNIVERSIDAD TECNOLÓGICA DE QUERÉTARO. Nombre del proyecto SISTEMA DE CORRESPONDENCIA EN SHAREPOINT. Empresa. Comisión Estatal de Aguas

UNIVERSIDAD TECNOLÓGICA DE QUERÉTARO. Nombre del proyecto SISTEMA DE CORRESPONDENCIA EN SHAREPOINT. Empresa. Comisión Estatal de Aguas UNIVERSIDAD TECNOLÓGICA DE QUERÉTARO Nombre del proyecto SISTEMA DE CORRESPONDENCIA EN SHAREPOINT Empresa Comisión Estatal de Aguas Memoria que como parte de los requisitos para obtener el título de: Técnico

Más detalles

Servicios para la integración de sistemas de información sanitarios

Servicios para la integración de sistemas de información sanitarios Servicios para la integración de sistemas de información sanitarios Francisco Javier García Muñoz Resposable de la Unidad de Innovación Área de Tecnologías de la Información jgarcia@sescam.org http://sescam.jccm.es

Más detalles

UTILIZACIÓN DE UN BOLÍGRAFO DÍGITAL PARA LA MEJORA DE PROCEDIMIENTOS DE CAMPO EN UNA CENTRAL NUCLEAR.

UTILIZACIÓN DE UN BOLÍGRAFO DÍGITAL PARA LA MEJORA DE PROCEDIMIENTOS DE CAMPO EN UNA CENTRAL NUCLEAR. UTILIZACIÓN DE UN BOLÍGRAFO DÍGITAL PARA LA MEJORA DE PROCEDIMIENTOS DE CAMPO EN UNA CENTRAL NUCLEAR. Autor: Ruiz Muñoz, Rafael. Director: Muñoz García, Manuel. Entidad Colaboradora: Empresarios Agrupados.

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

eadministración 2.0 UM: sistemas de tramitación horizontal orientados a la gestión de procesos y documentos

eadministración 2.0 UM: sistemas de tramitación horizontal orientados a la gestión de procesos y documentos eadministración 2.0 UM: sistemas de tramitación horizontal orientados a la gestión de procesos y documentos Agenda Motivación Contexto tecnológico Inconvenientes del modelo Objetivos Nuevo modelo Alfresco

Más detalles

Implementación de Servidor XS para despliegue de Proyecto OLPC en Escuelas del Perú

Implementación de Servidor XS para despliegue de Proyecto OLPC en Escuelas del Perú VISIÓN 2009 XIV Congreso Internacional de Ingeniería, VII Arquiforo y IV Open Source Day Facultad de Ingeniería y Arquitectura. Universidad de San Martín de Porres 21-24 Octubre Implementación de Servidor

Más detalles

Agustiniano Ciudad Salitre School Computer Science Support Guide - 2015 Second grade First term

Agustiniano Ciudad Salitre School Computer Science Support Guide - 2015 Second grade First term Agustiniano Ciudad Salitre School Computer Science Support Guide - 2015 Second grade First term UNIDAD TEMATICA: INTERFAZ DE WINDOWS LOGRO: Reconoce la interfaz de Windows para ubicar y acceder a los programas,

Más detalles

e-mail: yepezr_gye@servientrega.com.ec 2 Ingeniero en Computación especialización Sistemas Tecnológicos 2005;

e-mail: yepezr_gye@servientrega.com.ec 2 Ingeniero en Computación especialización Sistemas Tecnológicos 2005; SIITIIO ELECTRÓNIICO DE PAGOS Y TRANSFERENCIIAS EN LÍÍNEA Romina Yepez 1, Peter Calderón Ponce 2, Luis Fernando Ruiz Vera 3, Karina Astudillo Barahona 4 1 Ingeniera en Computación especialización Sistemas

Más detalles

Ingeniería de Software

Ingeniería de Software Ingeniería de Software MSDN Ingeniería de Software...1 Ingeniería del Software_/_ Ingeniería y Programación...1 Análisis de Requerimientos...2 Especificación...3 Diseño...4 Desarrollo en Equipo...5 Mantenimiento...6

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

SOLUCIÓN DE UNA INTRANET BAJO SOFTWARE OPEN SOURCE PARA EL GOBIERNO MUNICIPAL DEL CANTÓN BOLÍVAR [IOS-GMCB]

SOLUCIÓN DE UNA INTRANET BAJO SOFTWARE OPEN SOURCE PARA EL GOBIERNO MUNICIPAL DEL CANTÓN BOLÍVAR [IOS-GMCB] Gobierno Municipal del Cantón Bolívar. SOLUCIÓN DE UNA INTRANET BAJO SOFTWARE OPEN SOURCE PARA EL GOBIERNO MUNICIPAL DEL CANTÓN BOLÍVAR [IOS-GMCB] Visión Universidad Técnica del Norte Histórico de Revisiones

Más detalles

Herramienta para obtener estadísticas del Sistema Gestor de Base de Datos PostgreSQL.

Herramienta para obtener estadísticas del Sistema Gestor de Base de Datos PostgreSQL. Tipo de artículo: Artículo original Temática: SW Libre y sus aplicaciones Herramienta para obtener estadísticas del Sistema Gestor de Base de Datos PostgreSQL. Tool to obtain statistics from PostgreSQL

Más detalles

Vladimir Taco Paucar, Ximena Rojas Aguirre, Víctor Paliz, Gabriel Chiriboga. Universidad de las Fuerzas Armadas ESPE, Ecuador

Vladimir Taco Paucar, Ximena Rojas Aguirre, Víctor Paliz, Gabriel Chiriboga. Universidad de las Fuerzas Armadas ESPE, Ecuador LEVANTAMIENTO, DISEÑO Y AUTOMATIZACIÓN DEL PROCESO DE GESTIÓN DE INCIDENTES PARA MAGMASOFT, UTILIZANDO LA SUITE DE BPM OPEN SOURCE BONITASOFT E INTEGRACIÓN CON ALFRESCO COMO REPOSITORIO DOCUMENTAL, MEDIANTE

Más detalles

RADIATION DOSE MONITOR

RADIATION DOSE MONITOR RADIATION DOSE MONITOR El DACS para Optimizar la Dosis IRE RAYOS X S.A. C/ Isla de Palma, 22 bis, 28703 San Sebastián de los Reyes, MADRID E irerayosx@irerayosx.com W irerayosx.com T 91 653 11 51 / 91

Más detalles

INTRANET DEL COLEGIO MAYOR DE NUESTRA SEÑORA INTRACOLM JULIAN ANDRÉS LÓPEZ VARGAS JORGE ALEXANDER HENAO RAMÍREZ

INTRANET DEL COLEGIO MAYOR DE NUESTRA SEÑORA INTRACOLM JULIAN ANDRÉS LÓPEZ VARGAS JORGE ALEXANDER HENAO RAMÍREZ INTRANET DEL COLEGIO MAYOR DE NUESTRA SEÑORA INTRACOLM JULIAN ANDRÉS LÓPEZ VARGAS JORGE ALEXANDER HENAO RAMÍREZ UNIVERSIDAD DE MANIZALES FACULTAD DE INGENIERÍA PROGRAMA DE TECNOLOGÍA EN SISTEMAS MANIZALES

Más detalles

V. CAPÍTULO: CONTRIBUCIÓN

V. CAPÍTULO: CONTRIBUCIÓN V. CAPÍTULO: CONTRIBUCIÓN Requerimientos del Sistema Para llevar a cabo el desarrollo de nuestro sistema se establecieron tanto los actores como los requerimientos funcionales y no funcionales del sistema.

Más detalles

Muestra de solicitud para una propuesta de un conjunto de aplicaciones de Gestión de Procesos de Negocio KIT DE HERRAMIENTAS DEL COMPRADOR DE BPMS

Muestra de solicitud para una propuesta de un conjunto de aplicaciones de Gestión de Procesos de Negocio KIT DE HERRAMIENTAS DEL COMPRADOR DE BPMS KIT DE HERRAMIENTAS DEL COMPRADOR DE BPMS Muestra de solicitud para una propuesta de un conjunto de aplicaciones de Gestión de Procesos de Negocio Parte 1 del kit completo de herramientas del comprador

Más detalles

Marco nacional de interoperabilidad basado en HL7 CDA-ISO27932

Marco nacional de interoperabilidad basado en HL7 CDA-ISO27932 JORNADA INTERNACIONAL INTEGRACIÓN DE LOS SISTEMAS DE INFORMACIÓN DE SALUD E HISTORIA CLÍNICA ELECTRÓNICA Marco nacional de interoperabilidad basado en HL7 CDA-ISO27932 Arquitectura de repositorios DACS

Más detalles

Innovación para su Contact Center. Reporting Manager. Descubra el valor de negocio de sus datos y la actividad del Contact Center

Innovación para su Contact Center. Reporting Manager. Descubra el valor de negocio de sus datos y la actividad del Contact Center Innovación para su Contact Center Reporting Manager Descubra el valor de negocio de sus datos y la actividad del Contact Center ÍNDICE DATA SHEET 1. Introducción... 3 2. Características principales...

Más detalles

Flujo de Trabajo Clínico en la era de la Interoperabilidad y Mobilidad

Flujo de Trabajo Clínico en la era de la Interoperabilidad y Mobilidad Flujo de Trabajo Clínico en la era de la Interoperabilidad y Mobilidad Junio 2015 p.2 Conceptos p.3 Conociendo las SIGLAS HIS (Hospital Information System). Sistema de gestión hospitalaria. RIS (Radiology

Más detalles

OpenESB FEMI Sofis Solutions - PMA

OpenESB FEMI Sofis Solutions - PMA OpenESB FEMI Sofis Solutions - PMA Página 1 de 22 1 BPMS... 3 1.1 Introducción... 3 1.2 Modelado de Procesos... 5 1.2.1 Editor Gráfico de Procesos... 5 1.2.2 Gestión de Tareas... 6 1.2.3 Interacción Humana...

Más detalles

Sistema para la administración, control y seguimiento de reuniones institucionales.

Sistema para la administración, control y seguimiento de reuniones institucionales. 87 Sistema para la administración, control y seguimiento de reuniones institucionales. María Rodríguez, Luis Luna, Marcos Sixto, Joel Quintanilla y José Aguirre. M. Rodríguez, L. Luna, M. Sixto, J. Quintanilla

Más detalles

DESARROLLO DE COMPONENTES PARA LA INTEGRACIÓN DEL PORTAL CORPORATIVO DEL CITI CON LA BPMS BIZAGI

DESARROLLO DE COMPONENTES PARA LA INTEGRACIÓN DEL PORTAL CORPORATIVO DEL CITI CON LA BPMS BIZAGI DESARROLLO DE COMPONENTES PARA LA INTEGRACIÓN DEL PORTAL CORPORATIVO DEL CITI CON LA BPMS BIZAGI Informe de Práctica Profesional de 4to Año, Ingeniería Informática Autor: Manuel Alejandro Aguilar Díaz

Más detalles

DIGISTAT Software Suite Qué es DIGISTAT Suite? Cuál es la razón para elegir DIGISTA. Cuál es la razón para elegir DIGISTAT Suite?

DIGISTAT Software Suite Qué es DIGISTAT Suite? Cuál es la razón para elegir DIGISTA. Cuál es la razón para elegir DIGISTAT Suite? DIGISTAT Software Suite Qué es DIGISTAT Suite? Qué es DIGISTAT Suite? DIGISTAT Suite es un sistema de software modular para la gestión de datos clínicos en las áreas críticas y especializadas del hospital.

Más detalles

BplSoa: Framework para el desarrollo de líneas de procesos de negocios orientadas a servicios. Víctor Mario Cardona Medina

BplSoa: Framework para el desarrollo de líneas de procesos de negocios orientadas a servicios. Víctor Mario Cardona Medina BplSoa: Framework para el desarrollo de líneas de procesos de negocios orientadas a servicios Víctor Mario Cardona Medina Universidad Nacional de Colombia Facultad de Ingeniería, Departamento de Ingeniería

Más detalles

Telefonía IP. Migraciones masivas y nuevos servicios de valor añadido

Telefonía IP. Migraciones masivas y nuevos servicios de valor añadido Telefonía IP. Migraciones masivas y nuevos servicios de valor añadido PONENCIAS IP Telephony. Mass Migration and new value-added services Resumen M. Ángel García, J. Ángel Martínez y Jesús Martínez Actualmente,

Más detalles

CAPÍTULO 1. A fin de cumplir con los requisitos previos a la obtención del título de. Ingeniero en Sistemas Computacionales, se elabora este proyecto.

CAPÍTULO 1. A fin de cumplir con los requisitos previos a la obtención del título de. Ingeniero en Sistemas Computacionales, se elabora este proyecto. CAPÍTULO 1 1. INTRODUCCION 1.1. Antecedentes A fin de cumplir con los requisitos previos a la obtención del título de Ingeniero en Sistemas Computacionales, se elabora este proyecto. Este capitulo proporciona

Más detalles

Centro de Competencias de Integración. Portal del paciente

Centro de Competencias de Integración. Portal del paciente Centro de Competencias de Integración Portal del paciente 1 Tabla de contenidos Introducción y propósito de este documento...2 Motivación...2 Objetivos...3 Desarrollo...3 Servidor web service Proxy...3

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

SOFTWARE PARA LA GESTIÓN INFORMÁTICA DE UNA CLÍNICA DENTAL

SOFTWARE PARA LA GESTIÓN INFORMÁTICA DE UNA CLÍNICA DENTAL SOFTWARE PARA LA GESTIÓN INFORMÁTICA DE UNA CLÍNICA DENTAL Autora: Laura Martín García Director: Alberto Ciudad Sánchez RESUMEN El objetivo de este proyecto es realizar el análisis, diseño y desarrollo

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

Tema 5. Plataforma Java EE

Tema 5. Plataforma Java EE Tema 5. Plataforma Java EE SCS Sistemas Cliente/Servidor 4 o informática http://ccia.ei.uvigo.es/docencia/scs enero 2009 FJRP, FMBR 2008/09 ccia SCS 5.1 Introducción a Java EE Java EE (Java Enterprise

Más detalles

Boletín de Asesoría Gerencial SOA: enfoque técnico orientado a procesos

Boletín de Asesoría Gerencial SOA: enfoque técnico orientado a procesos Espiñeira, Sheldon y Asociados No. 4-2010 Contenido Haga click en los enlaces para navegar a través del documento Haga click en los enlaces para llegar directamente a cada sección 4 Introducción 4 Qué

Más detalles

Copyright 2011 - bizagi

Copyright 2011 - bizagi Copyright 2011 - bizagi 1. Automatización de Proceso con bizagi... 3 Descripción... 3 Objetivos... 3 Perfil de los asistentes... 4 Duración... 4 2. Parte I - Conceptos Básicos para la Construcción de Soluciones

Más detalles

Service Oriented Architecture

Service Oriented Architecture Service Oriented Architecture Isaac Gutiérrez Gómez, Salvador Otón Tortosa Universidad de Alcalá, Departamento de Ciencias de la Computación, 28871 Alcalá de Henares, Spain igutierrez09@yahoo.es, salvador.oton@uah.es

Más detalles

BOLETÍN DE NOVEDADES Barcelona, junio de 2008

BOLETÍN DE NOVEDADES Barcelona, junio de 2008 BOLETÍN DE NOVEDADES Barcelona, junio de 2008 Introducción El objeto de este documento es presentar y describir brevemente las principales actuaciones en los últimos meses de Carver en algunos de sus clientes,

Más detalles

1 GLOSARIO. Actor: Es un consumidor (usa) del servicio (persona, sistema o servicio).

1 GLOSARIO. Actor: Es un consumidor (usa) del servicio (persona, sistema o servicio). 1 GLOSARIO A continuación se definen, en orden alfabético, los conceptos básicos que se han abordado a lo largo del desarrollo de la metodología para la gestión de requisitos bajo la Arquitectura Orientada

Más detalles

BPMN vs UML. Los Requerimientos y el Modelo del Negocio. Autor: Norberto Figuerola

BPMN vs UML. Los Requerimientos y el Modelo del Negocio. Autor: Norberto Figuerola BPMN vs UML Autor: Norberto Figuerola Los Requerimientos y el Modelo del Negocio Normalmente, siempre que iniciamos un esfuerzo de desarrollo de software éste tiene como objetivo automatizar procesos del

Más detalles

Instalación de IBM SPSS Modeler 14.2 Batch para Windows

Instalación de IBM SPSS Modeler 14.2 Batch para Windows Instalación de IBM SPSS Modeler 14.2 Batch para Windows Las siguientes instrucciones deben utilizarse para instalar IBM SPSS Modeler Batch versión 14.2. IBM SPSS Modeler Batch ofrece todas las capacidades

Más detalles

Integración de Metodologías Ágiles en el Desarrollo de un Sistema de Monitoreo Inalámbrico para Medir la Contaminación del Aire en Tiempo Real.

Integración de Metodologías Ágiles en el Desarrollo de un Sistema de Monitoreo Inalámbrico para Medir la Contaminación del Aire en Tiempo Real. Integración de Metodologías Ágiles en el Desarrollo de un Sistema de Monitoreo Inalámbrico para Medir la Contaminación del Aire en Tiempo Real. Walter Fuertes, Diego Carrera, César Villacís, Fernando Galárraga,

Más detalles

PROCESO DE ASEGURAMIENTO DE LA CALIDAD EN LOS PROYECTOS DE DESARROLLO DE APLICACIONES PARA DISPOSITIVOS MÓVILES EN LA FRG

PROCESO DE ASEGURAMIENTO DE LA CALIDAD EN LOS PROYECTOS DE DESARROLLO DE APLICACIONES PARA DISPOSITIVOS MÓVILES EN LA FRG Revista de investigación Editada por Área de Innovación y Desarrollo, S.L. Envío: 01-03-2013 Aceptación: 12-03-2013 Publicación: 28-03-2013 PROCESO DE ASEGURAMIENTO DE LA CALIDAD EN LOS PROYECTOS DE DESARROLLO

Más detalles

Anteproyecto Fin de Carrera

Anteproyecto Fin de Carrera Universidad de Castilla-La Mancha Escuela Superior de Informática Anteproyecto Fin de Carrera DIMITRI (Desarrollo e Implantación de Metodologías y Tecnologías de Testing) Dirige: Macario Polo Usaola Presenta:

Más detalles

Anexo 11.4. Características Técnicas Infraestructura

Anexo 11.4. Características Técnicas Infraestructura Anexo 11.4. Técnicas Infraestructura Infraestructura. Descripción Servidores Online Técnicas Equipos de Computo. 2 a 4 Técnicas Servidor Datacenter: 1 TB SATA3 + 1 TB SATA3 + RAID 1 Hardware. Ancho de

Más detalles

SISTEMA DE GESTIÓN DE RECIBOS

SISTEMA DE GESTIÓN DE RECIBOS UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO TÉCNICO EN INFORMÁTICA DE GESTIÓN PROYECTO FIN DE CARRERA SISTEMA DE GESTIÓN DE RECIBOS AUTOR: EMILIO DE DIEGO BABARRO

Más detalles

La calidad no está reñida con los costes

La calidad no está reñida con los costes QUIÉNES SOMOS Empresa fundada en 2012. Somos una Consultora de Procesos, Sistemas y Tecnologías de la Información que apuesta por las soluciones Open Source a medida, como alternativa en época de crisis.

Más detalles

http://www.cem.itesm.mx/extension/ms

http://www.cem.itesm.mx/extension/ms Diplomado Programación orientada a objetos con Java y UML Las empresas necesitan contar con sistemas de información modernos, ágiles y de calidad para alcanzar sus objetivos y ser cada vez más competitivos

Más detalles

RODRIGO TAPIA SANTIS (rtapiasantis@gmail com) has a. non-transferable license to use this Student Guide

RODRIGO TAPIA SANTIS (rtapiasantis@gmail com) has a. non-transferable license to use this Student Guide Introducción Objetivos del Curso Al finalizar este curso, debería estar capacitado para: Instalar, crear y administrar Oracle Database 11g Versión 2 Configurar la base de datos para una aplicación Utilizar

Más detalles

Personas IT Ingeniería de Software BPO Capacitación

Personas IT Ingeniería de Software BPO Capacitación Personas IT Ingeniería de Software BPO Capacitación Nosotros Somos una empresa con 23 años de Chile y Colombia. Desarrollamos servicios integrados a través de nuestras 4 unidades de negocio, Outsourcing

Más detalles

Programación orientada a

Programación orientada a Programación orientada a objetos con Java Pedro Corcuera Dpto. Matemática Aplicada y Ciencias de la Computación Universidad de Cantabria corcuerp@unican.es Objetivos Presentar los conceptos de la programación

Más detalles

Beneficios que obtiene con Guardian Support:

Beneficios que obtiene con Guardian Support: Hoja de datos de servicios Beneficios que obtiene con Guardian Support: Un novedoso servicio para alcanzar la máxima disponibilidad, sostenibilidada y rendimiento de su sistema AMS Suite. Beneficios que

Más detalles

UN SISTEMA DE INFORMACIÓN EN UNA BOTELLA (O CASI): CONSOLIDACIÓN Y VIRTUALIZACIÓN DE SERVIDORES EN EL MEC

UN SISTEMA DE INFORMACIÓN EN UNA BOTELLA (O CASI): CONSOLIDACIÓN Y VIRTUALIZACIÓN DE SERVIDORES EN EL MEC UN SISTEMA DE INFORMACIÓN EN UNA BOTELLA (O CASI): CONSOLIDACIÓN Y VIRTUALIZACIÓN DE SERVIDORES EN EL MEC Jefe de Servicio de Sistemas Corporativos Ministerio de Educación y Ciencia Jefe de Servicio de

Más detalles