ESCUELA POLITÉCNICA SUPERIOR
Grado en Ingeniería Informática
TRABAJO FIN DE GRADO
DISEÑO E IMPLANTACIÓN DE UN SISTEMA DE INCIDENCIAS BASADO EN WORKFLOWS
Sara Aragón Pérez
Tutor: Miguel Ángel Mora Rincón
Julio 2015
Resumen
El método de comunicación actual en la Escuela Politécnica Superior es a través del correo institucional. Esto implica la pérdida de información, ya que los e-mails pueden perderse, traspapelarse o borrarse por equivocación.
El objetivo de este trabajo de fin de grado es diseñar, desarrollar e implementar un sistema de gestión de incidencias tipo helpdesk basado en el concepto de workflow. Gracias a esto se debería mejorar la gestión de incidencias en la escuela en los aspectos de rapidez, comodidad, eficacia y eficiencia.
El sistema propuesto, llamado Iris, está centrado en la automatización de incidencias y consultas a nivel interno entre los distintos departamentos dentro de la Escuela.
El proyecto se ha desarrollado utilizando la plataforma Google App Engine, almacenando información en una base de datos externa proporcionada por Google datastore, gestionada por Objectify.
Finalizado el trabajo, se concluye que el resultado es satisfactorio. Se alcanzaron los objetivos marcados y se cumplieron todas las especificaciones para este estadio de desarrollo.
Al final de esta memoria se analizan las posibles mejoras o ampliaciones para el sistema Iris si se decide seguir desarrollándolo en un futuro.
Palabras clave
Comunicación, correo, información, workflow, helpdesk, mejorar, rapidez, comodidad, eficacia, eficiencia, incidencia, solicitud, proceso, departamento, Escuela Politécnica Superior, Google App Engine, datastore, Objectify.
II
Abstract
The current communication method at Escuela Politécnica Superior is through institutional e-mail, which implies losing information due to losing, misplacing or wrong- deleting emails.
The object of this degree final project is the design, development and implementation of a helpdesk-like system issue management tool based in the workflow concept. Thanks to this tool the system issue management should be enhanced with faster, more comfortable system with better effectiveness and efficiency.
The proposed system, called Iris, is focused in automatizing incidents and queries at an internal level between the departments of the EPS.
This project has been developed using Google App Engine platform, storing information inside an external data base provided by Google Datastore and being managed by Objectify.
Once the project was finished, the result was satisfactory. All the goals and requirements were met for this design stage.
At the end of this report I analyze all the possible updates and improvements for the Iris system, if it is decided to continue the development.
Keywords
Communication, e-mail, information, workflow, helpdesk, enhance, speed up, comfort, effectiveness, efficiency, incidence, request, process, department, Escuela Politécnica Superior, Google App Engine, datastore, Objectify.
IV
ÍNDICE GENERAL
1. Introducción ... 1
Motivación... 1
1.1. Objetivos ... 3
1.2. 1.2.1. Análisis de problemas ... 3
1.2.2. Líneas guía propuestas para resolver los problemas ... 4
1.2.3. Herramientas disponibles en la EPS ... 4
1.2.4. Soluciones y análisis de viabilidad ... 4
1.2.5. Objetivos del nuevo sistema ... 5
1.2.6. Funciones para el nuevo sistema ... 5
1.2.7. Análisis de herramientas requeridas ... 6
Organización de la memoria ... 6
1.3. 2. Estado del arte ... 7
Sistemas HelpDesk ... 7
2.1. 2.1.1. Comparación técnica con otros sistemas ... 7
2.1.2. BugZilla ... 7
2.1.3. Mantis ... 8
2.1.4. Jira ... 9
2.1.5. Iris ... 10
Workflow ... 12
2.2. 2.2.1. Definiciones ... 13
2.2.2. Ejemplo práctico de workflow: el coche roto ... 13
2.2.3. Definición del sistema Iris como sistema de gestión de workflows ... 14
2.2.4. Ejemplos prácticos de workflow dentro del sistema Iris ... 15
Cloud computing ... 16
2.3. 2.3.1. Introducción: Del proyecto ARPANET a la web 2.0 ... 16
2.3.2. Modelos de servicios ... 16
2.3.3. Google App Engine ... 17
2.3.4. Comparación con otros sistemas ... 19
Objectify ... 23
2.4. 2.4.1. Introducción ... 23
2.4.2. Definición ... 23
2.4.3. Conceptos ... 24
Google Web Toolkit ... 27
2.5. 2.5.1. ¿Qué es GWT? ... 27
2.5.2. Estructura de GWT ... 28
2.5.3. Interfaz de Usuario ... 28
2.5.4. Llamadas RPC ... 29
2.5.5. Compilador ... 31
2.5.6. Pruebas ... 31
3. Arquitectura ... 33
Arquitectura del proyecto ... 33
3.1. Tecnologías del servidor ... 34 3.2.
VI
3.2.1. Cloud computing ... 34
3.2.2. Modelo de Datos ... 35
Tecnologías del cliente ... 37
3.3. Tecnologías de comunicación ... 39
3.4. 3.4.1. HTTP ... 39
3.4.2. Serialización de Objetos ... 41
3.4.3. Java servlets... 41
4. Análisis y Diseño ... 43
Actores ... 43
4.1. Requisitos funcionales ... 43
4.2. 4.2.1. Anónimos ... 43
4.2.2. Usuario registrado ... 43
4.2.3. Usuario administrador... 44
Requisitos no funcionales ... 45
4.3. Casos de uso y diagramas de secuencia ... 46
4.4. 4.4.1. Caso de uso 001... 46
4.4.2. Caso de uso 002... 48
4.4.3. Caso de uso 003... 50
4.4.4. Caso de uso 004... 52
5. Funcionamiento del sistema ... 53
Resolución de solicitudes ... 53
5.1. Usuario público ... 55
5.2. Usuario registrado ... 59
5.3. 5.3.1. Mis flujos ... 60
5.3.2. Nueva incidencia ... 64
Usuario administrador ... 65
5.4. 5.4.1. Gestor de Workflows ... 67
5.4.2. Gestor de Grupos y Usuarios ... 69
5.4.3. Gestor de Preguntas Frecuentes ... 71
5.4.4. Gestor de solicitudes ... 73
6. Pruebas y resultados ... 77
CU-001 – Iniciar sesión ... 77
6.1. CU-002 – Registrar una incidencia ... 77
6.2. CU-003 – Ver preguntas frecuentes ... 78
6.3. CU-004 – Realizar etapa de solicitud ... 78
6.4. CU-005 – Modificar etapa de una solicitud ... 79
6.5. CU-006 – Resolver una solicitud ... 79
6.6. CU-007 – Ver miembros encargados de un tipo de workflow ... 79
6.7. CU-008 – Enviar un mensaje a un flujo de trabajo ... 80
6.8. CU-009 – Ver ficha personal ... 80
6.9. CU-010 – Logout del sistema ... 80
6.10. CU-011 – Ver solicitudes ... 81
6.11. CU-012 – Gestión tipo de workflow ... 81 6.12.
CU-014 – Gestión de grupos de usuarios ... 82
6.14. CU-015 – Gestión de preguntas frecuentes ... 83
6.15. CU-016 – Gestión de bloques de preguntas frecuentes ... 83
6.16. CU-017 – Buscar solicitudes ... 84
6.17. 7. Conclusiones y trabajo futuro ... 85
Conclusiones ... 85
7.1. Trabajo futuro ... 85
7.2. 7.2.1. Reabrir workflows ... 85
7.2.2. Un workflow como tarea parte de otro workflow ... 86
7.2.3. Análisis de calidad de los métodos de trabajo ... 86
7.2.4. Dependencias entre tareas ... 87
7.2.5. Scripts automáticos como puente entre la EPS e Iris ... 88
8. Bibliografía ... 89
9. Anexos ... 93
Anexo I: Modelos... 93
9.1. 9.1.1. Entidad ... 93
9.1.2. BloquePreguntaFrecuente ... 93
9.1.3. PreguntaFrecuente ... 93
9.1.4. Grupo ... 94
9.1.5. TipoWorkflow ... 94
9.1.6. TipoEtapa ... 94
9.1.7. MensajeWorkflow ... 95
9.1.8. CampoFormulario ... 95
9.1.9. Usuario ... 95
9.1.10. UserDTO ... 96
9.1.11. Etapa ... 96
9.1.12. Solicitud ... 96
9.1.13. Ticket ... 97
9.1.14. Workflow ... 97
VIII
ÍNDICE DE FIGURAS
FIGURA 1.LOGO BUGZILLA ... 7
FIGURA 2.LOGO MANTIS BUG TRACKER ... 8
FIGURA 3.LOGO JIRA SERVICE DESK ... 9
FIGURA 4.LOGO IRIS... 10
FIGURA 5.LOGOTIPO OFICIAL DE GOOGLE APP ENGINE ... 17
FIGURA 6.TEST DE SEGURIDAD PARA IRIS CON LA HERRAMIENTA CLOUD SECURITY SCANNER DE GOOGLE. ... 18
FIGURA 7.LOGOS DE AMAZON WEB SERVICES Y MICROSOFT AZURE ... 19
FIGURA 8.LOGOTIPO OFICIAL OBJECTIFY ... 23
FIGURA 9.EJEMPLO DE MAPA DE UN MÓDULO EN EL SERVICIO .XML ... 28
FIGURA 10.PATRÓN MODELO-VISTA-PRESENTADOR [69] ... 29
FIGURA 11.EJEMPLO DE INTERFAZ DE SERVICIO QUE EXTIENDE REMOTESERVICE ... 29
FIGURA 12.EJEMPLO DE INTERFAZ DE SERVICIO QUE EXTIENDE REMOTESERVICESERVLET ... 30
FIGURA 13.EJEMPLO DE INTERFAZ DE SERVICIO ASÍNCRONA ... 30
FIGURA 14.ESTRUCTURA DE SERVICIOS RPC ... 30
FIGURA 15.ARQUITECTURA GENERAL DEL PROYECTO ... 33
FIGURA 16.DIAGRAMA DE CLASES DE MODELOS ... 36
FIGURA 17.MENSAJE HTTP DE PETICIÓN [15] ... 39
FIGURA 18.MENSAJE HTTP DE RESPUESTA [16] ... 40
FIGURA 19.DIAGRAMA DE SECUENCIA –LOGIN ... 47
FIGURA 20.DIAGRAMA DE SECUENCIA -REGISTRAR INCIDENCIA... 49
FIGURA 21.DIAGRAMA DE SECUENCIA -RESOLVER TAREA ... 51
FIGURA 22.DIAGRAMA DE SECUENCIA -CREA TIPO DE WORKFLOW ... 52
FIGURA 23.FUNCIONAMIENTO GENERAL DEL SISTEMA... 53
FIGURA 24.DESCRIPCIÓN TÉCNICA DE CREACIÓN DE WORKFLOWS ... 54
FIGURA 25.PANTALLA INICIAL ... 55
FIGURA 26.PANTALLA SISTEMA AUTENTICACIÓN – USUARIO ANÓNIMO ... 56
FIGURA 27.PANTALLA REGISTRAR INCIDENCIA - USUARIO ANÓNIMO ... 57
FIGURA 28.PANTALLA PREGUNTAS FRECUENTES - USUARIO ANÓNIMO ... 58
FIGURA 29.PANTALLA INICIAL - USUARIO REGISTRADO ... 59
FIGURA 30.OPCIONES SUBMENÚ PERFIL - USUARIO REGISTRADO ... 59
FIGURA 31.PANTALLA PERFIL USUARIO ... 59
FIGURA 32.PANTALLA MENÚ - USUARIO REGISTRADO ... 60
FIGURA 33.PANTALLA LISTA DE FLUJOS DE TRABAJO ... 60
FIGURA 34.PANTALLA SUBMENÚ FLUJO DE TRABAJO ... 60
FIGURA 35.PANTALLA ETAPAS PENDIENTES ... 61
FIGURA 36.PANTALLA ETAPAS RESUELTAS ... 61
FIGURA 37.PANTALLA SOLICITUDES FINALIZADAS ... 62
FIGURA 38.PANTALLA PREGUNTAS FRECUENTES - USUARIO REGISTRADO ... 62
FIGURA 39.PANTALLA MIEMBROS DEL FLUJO DE TRABAJO ... 63
FIGURA 40.PANTALLA MENSAJES ... 63
FIGURA 41.PANTALLA PRE-ENVÍO DE INCIDENCIA ... 64
FIGURA 42.PANTALLA REGISTRAR INCIDENCIA - USUARIO REGISTRADO ... 64
FIGURA 43.PANTALLA INICIAL - USUARIO ADMINISTRADOR ... 65
FIGURA 44.PANTALLA HOME - USUARIO ADMINISTRADOR ... 65
FIGURA 45.VISTA NUEVA SOLICITUD - USUARIO ADMINISTRADOR ... 66
FIGURA 46.VISTA SOLICITUD CERRADA - USUARIO ADMINISTRADOR ... 66
X
FIGURA 48.TITULO DE WORKFLOW ... 67
FIGURA 49.¿A QUIÉN LE ENVÍO LA SOLICITUD AL FINALIZAR? ... 67
FIGURA 50.GRUPOS QUE PUEDEN ENVIARLE SOLICITUDES ... 68
FIGURA 51.GRUPO DE USUARIOS ENCARGADO ... 68
FIGURA 52.FORMULARIO TIPO DE ETAPA ... 68
FIGURA 53.PANTALLA GRUPOS Y USUARIOS - USUARIO ADMINISTRADOR ... 69
FIGURA 54.INSERTAR NUEVO GRUPO ... 69
FIGURA 55.PADRES DEL GRUPO ... 70
FIGURA 56.USUARIOS DEL GRUPO ... 70
FIGURA 57.DATOS PERSONALES DEL USUARIO ... 71
FIGURA 58.PANTALLA PREGUNTAS FRECUENTES – USUARIO ADMINISTRADOR ... 71
FIGURA 59.BLOQUE DE PREGUNTAS ... 72
FIGURA 60.WORKFLOW ... 72
FIGURA 61.PREGUNTAS ... 72
FIGURA 62.NUEVA PREGUNTA FRECUENTE ... 73
FIGURA 63.PANTALLA SOLICITUDES - USUARIO ADMINISTRADOR ... 73
FIGURA 64.VISTA ETAPA DE SOLICITUD ... 74
FIGURA 65.MENSAJES ... 74
FIGURA 66.MENSAJES DE WORKFLOW ... 75
FIGURA 67.FLUJOS DE TRABAJO - USUARIO ADMINISTRADOR ... 75
FIGURA 68.DIAGRAMA DE ESTADOS DE WORKFLOWS ... 86
FIGURA 69.EJEMPLO DIAGRAMA PERT... 87
ÍNDICE DE TABLAS
TABLA 1.COMPARACIÓN ENTRE DISTINTOS SISTEMAS HELPDESK[53] ... 11
TABLA 2.PROVEEDORES DE BASE DE DATOS EN LA NUBE POR IMPLEMENTACIÓN DEL MODELO Y MODELO DE DATOS [62] ... 35
TABLA 3.CASO DE USO 001 ... 46
TABLA 4.CASO DE USO 002 ... 48
TABLA 5.CASO DE USO 003 ... 51
TABLA 6.CASO DE USO 004 ... 52
TABLA 7.PRUEBAS -INICIAR SESIÓN ... 77
TABLA 8.PRUEBAS -REGISTRAR INCIDENCIA ... 77
TABLA 9.PRUEBAS -VER PREGUNTAS FRECUENTES ... 78
TABLA 10.PRUEBAS -REALIZAR ETAPA DE SOLICITUD ... 78
TABLA 11.PRUEBAS -MODIFICAR ETAPA DE UNA SOLICITUD ... 79
TABLA 12.PRUEBAS -RESOLVER UNA SOLICITUD ... 79
TABLA 13.PRUEBAS -VER MIEMBROS ENCARGADOS DE UN TIPO DE WORKFLOW ... 79
TABLA 14.PRUEBAS -ENVIAR UN MENSAJE A UN FLUJO DE TRABAJO ... 80
TABLA 15.PRUEBAS -VER FICHA PERSONAL ... 80
TABLA 16.PRUEBAS -LOGOUT DEL SISTEMA ... 80
TABLA 17.PRUEBAS -VER SOLICITUDES ... 81
TABLA 18.PRUEBAS -GESTIÓN TIPO DE WORKFLOW ... 81
TABLA 19.PRUEBAS -GESTIÓN DE USUARIOS ... 82
TABLA 20.PRUEBAS -GESTIÓN DE GRUPOS DE USUARIOS ... 82
TABLA 21.PRUEBAS -GESTIÓN DE PREGUNTAS FRECUENTES ... 83
TABLA 22.PRUEBAS -GESTIÓN DE BLOQUE DE FAQS ... 83
TABLA 23.PRUEBAS -BUSCAR SOLICITUDES ... 84
TABLA 24.TABLA ENTIDAD ... 93
TABLA 25.TABLA ENTIDAD BLOQUEPREGUNTAFRECUENTE ... 93
TABLA 26.TABLA ENTIDAD PREGUNTAFRECUENTE ... 93
TABLA 27.TABLA ENTIDAD GRUPO ... 94
TABLA 28.TABLA ENTIDAD TIPOWORKFLOW ... 94
TABLA 29.TABLA ENTIDAD TIPOETAPA ... 94
TABLA 30.TABLA ENTIDAD MENSAJEWORKFLOW ... 95
TABLA 31.TABLA ENTIDAD CAMPOFORMULARIO ... 95
TABLA 32.TABLA ENTIDAD USUARIO ... 95
TABLA 33.TABLA ENTIDAD USERDTO ... 96
TABLA 34.TABLA ENTIDAD ETAPA ... 96
TABLA 35.TABLA ENTIDAD SOLICITUD ... 96
TABLA 36.TABLA ENTIDAD TICKET ... 97
TABLA 37.TABLA ENTIDAD WORKFLOW ... 97
XII
Glosario
1 TFG Trabajo de Fin de Grado 2 EPS Escuela Politécnica Superior 3 UAM Universidad Autónoma de Madrid 4 SGI Sistema de Gestión de Incidencias 5 NoSQL Not Only SQL
6 GAE Google App Engine 7 GWT Google Web Toolkit
8 MVC Patrón Modelo-Vista-Controlador 9 AJAX Asynchronous JavaScript And XML 10 HTML HyperText Markup Language 11 CSS Cascade Style Sheet
12 JS JavaScript
13 API Application Programming Interface 14 AWS Amazon Web Services
15 GFS Google File System
16 MVP Patrón Modelo-Vista-Presentador 17 RPC Remote Procedure Calls
18 EG Grupo de entidades (Entity Group)
XIV
1. Introducción
Motivación 1.1.
“El Trabajo Fin de Grado [1] (TFG) tiene carácter obligatorio y 12 créditos ECTS. Se defenderá al finalizar los estudios de Grado, una vez superadas el resto de asignaturas. Se trata de un proyecto original, que resulta de la inventiva o trabajo de su autor, realizado individualmente, que se presentará y defenderá ante una comisión universitaria, y que consistirá en un proyecto en el ámbito de las tecnologías específicas de la Titulación en el que se sinteticen e integren las competencias adquiridas en las enseñanzas.”1
Como todas las organizaciones modernas de cierto nivel, la Escuela Politécnica Superior [2] (EPS) de la Universidad Autónoma de Madrid [3] (UAM) cuenta con un sistema de gestión informatizado. Dicho sistema se utiliza, por ejemplo, para facilitar información a los alumnos a través de la web, para programar la vida académica o para gestionar las tareas de administración de la escuela.
Desde el 1 de septiembre de 2013 al 19 de diciembre de 2014 desarrollé mi trabajo de prácticas como becaria webmaster de la EPS. Por ello cuento con un conocimiento amplio del sistema usado actualmente.
Este sistema, FatWire, no cuenta con una herramienta adecuada para gestionar las incidencias y problemas surgidos durante la utilización del mismo. La herramienta de gestión de la nueva intranet, Joomla2, tampoco cuenta con una herramienta adecuada. Existe (o existió) un formulario para informar de incidencias dentro de la antigua intranet pero, actualmente3, no he sido capaz de localizarlo.
El método utilizado para gestionar las incidencias surgidas en el sistema por parte del personal de la escuela se basa en la utilización del correo institucional (@uam.es ó
@estudiante.uam.es). Estos correos le llegan al webmaster como copia y este se encarga de reenviarlos a las personas adecuadas. Cabe decir que, normalmente, el trabajo de un webmaster no incluye esta tarea, por lo ineficiente.
Este método consiste en el envío, reenvío y copia de correos con la información acerca de la incidencia. Esto origina gran cantidad de problemas por las siguientes causas:
Resulta imposible trazar y acceder a toda la información referida a una incidencia en cuanto hay más de dos personas implicadas. Y en las situaciones en las que solo hay dos personas trabajando en la incidencia, la información se pierde fácilmente en los extensos correos de respuesta-respuesta.
1 Ref. [58, p.1]
2 “Motor de portales dinámicos y sistema de administración de contenidos.”[38]
3 A 10 de junio de 2015.
2 DISEÑO E IMPLANTACIÓN DE UN SISTEMA DE INCIDENCIAS BASADO EN WORKFLOWS No existe una forma de controlar el estado de la incidencia. El único registro que existe son los correos, que se pueden traspapelar con fascinante facilidad.
La única forma de registro de la información de la incidencia, si se le puede llamar así, consiste en enviar como copia cada correo al webmaster. Esto genera un flujo de correos sin sentido ni orden que rozan la calificación de spam4.
Enviar un correo no asegura que este sea leído, por lo que una persona importante para la resolución de una incidencia podría leerlo tarde o, incluso, no llegar a leerlo jamás.
No existe manera de distribuir responsabilidades en la tarea de gestión de incidencias, a pesar de que existen muchos agentes implicados. Esto genera tensiones cuando las incidencias tardan mucho en resolverse o no se resuelven porque no existe un responsable directo.
Como solución a esta necesidad dentro del sistema de la EPS, este proyecto se centra en la creación de un sistema de gestión de incidencias [4] (SGI), llamado sistema Iris. Este sistema se basa en el concepto de workflow para gestionar las incidencias:
“El workflow (del inglés: flujo de trabajo) es el estudio de los aspectos operacionales de una actividad de trabajo: cómo se estructuran las tareas, cómo se realizan, cuál es su orden correlativo, cómo se sincronizan, cómo fluye la información que soporta las tareas y cómo se le hace seguimiento al cumplimiento de las tareas.” [63]
Teniendo claro este concepto, usaremos la tecnología Help Desk (del inglés: Mesa de ayuda):
“Mesa de Ayuda (en inglés: Help Desk, mal traducido como 'Ayuda de Escritorio'), […] es un conjunto de recursos tecnológicos y humanos, para prestar servicios con la posibilidad de gestionar y solucionar todas las posibles incidencias de manera integral, junto con la atención de requerimientos relacionados a las Tecnologías de la Información y la Comunicación (TIC).”[68]
En resumen, el sistema Iris, es un sistema Help Desk basado en workflows.
4 Correo basura. El nombre viene dado por la carne de baja calidad enlatada de mismo nombre.
Este nombre se popularizó en informática gracias al famoso sketch de los humoristas Monty Python de 1970. Ref. [73]
Objetivos
1.2.El objetivo de este trabajo pone la vista directamente sobre los problemas analizados anteriormente para darles solución.
1.2.1.
Análisis de problemas
Los problemas:
• Trazabilidad y registro.
• Reparto de tareas y responsabilidad.
• Comunicación.
Trazabilidad5: El uso exclusivo del correo institucional para realizar las tareas de gestión de incidencias facilita que tras un breve intercambio de correos entre varias personas resulte imposible para alguien sin acceso a todos los correos hacer una regresión dentro de la tarea para analizar. Para suplir esto se suele enviar copia a todos e, incluso, al webmaster. Esto genera un flujo de correos que permite la trazabilidad, pero a un elevado coste de tiempo y esfuerzo.
Registro: Este problema deriva del anterior. Al usar exclusivamente el correo como forma de registro la información acerca de la incidencia se puede perder con facilidad. Esto facilita que la probabilidad de que una incidencia quede sin resolver aumente de forma directamente exponencial al tiempo transcurrido desde su inicio.
Reparto de tareas y responsabilidad: No existe un protocolo o normalización interna para realizar las tareas de resolución de incidencias. No existe un reparto de tareas oficial entre los agentes implicados. Como consecuencia no hay una cadena de responsabilidad a la que acudir en caso de fallo, lo que suele dirigir esta responsabilidad al webmaster, entre cuyas atribuciones no está la de dirigir estas tareas.
Comunicación: La comunicación vía correo electrónico no asegura que el receptor lo lea así que el método siguiente es la llamada por teléfono. Esto genera problemas de trazabilidad y registro puesto que esa conversación no queda registrada en ningún sitio y los demás agentes implicados desconocen su contenido. Además también puede pasar que sea imposible localizar a una persona de ninguna forma con el evidente problema que esto conlleva.
5 En aseguramiento de la calidad, la trazabilidad es la capacidad de rastrear el recorrido de un servicio o producto desde su origen a su destino final. De esta forma se pueden controlar los procesos implicados en su producción o realización. Según el Comité de Seguridad Alimentaria de AECOC: “Se entiende trazabilidad como el conjunto de aquellos procedimientos preestablecidos y autosuficientes que permiten conocer el histórico, la ubicación y la trayectoria de un producto o lote de productos a lo largo de la cadena de suministros en un momento dado, a través de unas herramientas determinadas.”[74]
4 DISEÑO E IMPLANTACIÓN DE UN SISTEMA DE INCIDENCIAS BASADO EN WORKFLOWS 1.2.2.
Líneas guía propuestas para resolver los problemas
Para marcar los objetivos y requisitos del proyecto tendremos que proponer soluciones a los problemas analizados:
• Centralización del registro en un solo sitio: Toda la información acerca de la incidencia; descripción del problema, agentes implicados, comunicaciones, estado de resolución, etc., debe estar localizada en un solo sitio y no flotando en la nube del correo electrónico.
• Creación de grupos de trabajo para cada incidencia: cada incidencia tendrá una serie de personas asignadas para su resolución dependiendo de la naturaleza de la incidencia. De esta forma solo se implica a aquellos agentes necesarios en la tarea.
• Resolución de incidencias mediante workflows: mediante el uso de workflows podremos crear los grupos de trabajo y, de esta forma, mantener un control sobre el proceso de resolución en todas sus etapas.
1.2.3.
Herramientas disponibles en la EPS
Las herramientas que actualmente se usan en el sistema de la EPS son:
• FatWire: Un gestor de contenidos para la gestión y mantenimiento de la página web.
• Intranet (antigua): La actual intranet de la EPS que tiene una antigüedad de aproximadamente una década.
• Joomla: Un gestor de contenidos para la futura intranet. La cual ya está terminada pero no ha sido implementada todavía.
Todas estas herramientas carecen de las características adecuadas para gestionar la resolución de incidencias.
1.2.4.
Soluciones y análisis de viabilidad
Entre las posibles soluciones barajadas están las siguientes:
• Resolver las incidencias mediante un registro burocrático a través de administración: Esta solución es la que se ha empleado históricamente, aparece un problema, se rellena un formulario, se entrega una copia en administración y en un plazo estimado se tendrá una respuesta y/o solución.
No hace falta explicar por qué esto no es viable.
• Usar el mismo SGI actual creando una normalización interna para mejorar su aplicación: Consistiría en crear un protocolo riguroso a la hora de informar de una incidencia. Esto requiere la formación del personal (alumnos, profesores y administración) en la nueva normativa interna, lo cual implica un gran esfuerzo y, muy probablemente, un bajo rendimiento de la norma.
Por este motivo, descartamos esta posibilidad.
• Migrar las herramientas y usar el mismo SGI: Cambiaríamos algunas o todas las herramientas actuales (FatWire, Intranet y Joomla) por otras más seguras y con mayores capacidades. Esto conlleva un gasto importante de dinero y tiempo y no nos asegura que se corrija el problema, por lo tanto descartamos también esta opción.
• Contratar a un gestor de calidad para la resolución de incidencias: Se contrata a una persona para que su único trabajo sea la resolución de incidencias. Esto conllevaría una mejora notable en la calidad del SGI actual, pero también un gasto a la escuela.
• Nuevo sistema, Iris: Creamos un sistema nuevo, llamado Iris, que funcione de manera paralela, pero independiente, al sistema informático de la EPS. Iris tendrá las ventajas de un gestor sin el inconveniente del precio.
1.2.5.
Objetivos del nuevo sistema
El sistema Iris tendrá que cumplir los siguientes objetivos:
• Resolver los problemas existentes en el SGI actual.
• Generar costes de mantenimiento bajos o nulos.
• Facilidad de uso.
• Reducir tiempos de respuesta.
• Mejorar la comunicación entre los agentes implicados.
• Aumentar la tasa de resolución de incidencias.
1.2.6.
Funciones para el nuevo sistema
Para cumplir estos objetivos, el sistema Iris contará con las siguientes funciones:
• Creación automática de workflows para cada incidencia recibida.
• Envío de correo electrónico de información.
• Cerrar workflows.
• Identificar distintos tipos de usuarios: Administrador, registrado, no registrado.
• Login a través de un proveedor de servicios externo.
• Comunicación a través del sistema.
• Mostrar los flujos de trabajo solo a los agentes implicados.
• Posibilidad de enviar una incidencia resuelta a otro flujo de trabajo.
En los apartados 4.2 y 4.3 se muestran los requisitos funcionales y no funcionales que debe realizar este proyecto.
6 DISEÑO E IMPLANTACIÓN DE UN SISTEMA DE INCIDENCIAS BASADO EN WORKFLOWS 1.2.7.
Análisis de herramientas requeridas
Se han realizado unos pasos previos antes de la realización de esta aplicación, las más destacables son:
• Realizar un análisis de sistemas de workflow actuales en el mercado e identificar qué sistema sería válido para el TFG.
• Realizar un estudio del funcionamiento Google App Engine [6] (GAE), Objectify, Not Only Sql [5] (NoSQL) y Google Web Toolkit [7] (GWT).
Tras la recopilación de información necesaria, se crearon las entidades para manejar la información en el sistema.
Organización de la memoria
1.3.La estructura de este documento queda reflejada en 11 capítulos que se detallan a continuación:
Capítulo 1. Introducción al documento: Análisis del problema, soluciones propuestas, objetivos señalados, herramientas usadas y estructura de la memoria.
Capítulo 2. Estado del arte: Descripción de las tecnologías helpdesk, workflow, cloud computing, Objectify y Google Web Toolkit.
Capítulo 3. Arquitectura del sistema: Descripción minuciosa de la arquitectura del proyecto y las tecnologías utilizadas.
Capítulo 4. Análisis y diseño: Descripción detallada de requisitos funcionales y no funcionales, diagramas de clase y principales casos de uso de la aplicación.
Capítulo 5. Funcionamiento del sistema: Descripción de la funcionalidad de la aplicación desarrollada, por parte de un usuario anónimo, registrado y administrador.
Capítulo 6. Pruebas y resultados: Se explican las pruebas llevadas a cabo a través de casos de uso y los resultados obtenidos.
Capítulo 7. Conclusiones y trabajo futuro: Se explican los resultados obtenidos, además de la validación. También se detallan los posibles trabajos futuros y mejoras.
2. Estado del arte
Sistemas HelpDesk 2.1.
Ya en el apartado 1.1 definimos qué es un sistema HelpDesk.
Cuando entré como becaria web, no existía ningún sistema de incidencias operativo. Al entrar el nuevo webmaster, con todos los cambios que empezamos a realizar vimos necesario un sistema que recogiese los cambios y los problemas surgidos.
2.1.1.
Comparación técnica con otros sistemas
Aunque existen muchos sistemas de bug tracking6, compararemos nuestro sistema Iris con otros tres sistemas distintos:
• BugZilla
• Mantis (gratuito durante los primeros 30 días)
• Jira
2.1.2.
BugZilla
Figura 1. Logo BugZilla
BugZilla es un sistema OpenSource gratuito, por lo que podemos modificar su código para adaptarlo a nuestras necesidades. Su funcionamiento es bastante sencillo, sólo necesitamos un navegador y una cuenta de correo en el caso de que queramos recibir notificaciones (esto es totalmente configurable). Al acceder a la página principal, nos muestra una pantalla de inicio con la configuración que queramos darle a nuestro sistema: darnos de alta, realizar búsqueda de bugs existentes (abiertos o cerrados), crear un nuevo bug, modificar datos de configuración, etc. Dispone también de ventanas de ayuda para los usuarios que necesiten profundizar más en los conceptos que BugZilla ofrece.
Requisitos técnicos
• Sistema operativo: Windows, Linux y Mac OS X. Linux es el más recomendable.
6 “[]… aplicación informática diseñada para ayudar a asegurar la calidad de software y asistir a los programadores y otras personas involucradas en el desarrollo y uso de sistemas informáticos en el seguimiento de los defectos de software.”[72]
8 DISEÑO E IMPLANTACIÓN DE UN SISTEMA DE INCIDENCIAS BASADO EN WORKFLOWS
• Hardware: 4 GB o más de RAM, un procesador rápido (3 GHz, por ejemplo) y un disco duro con suficiente capacidad (50 GB es lo suficientemente grande).
• Software:
o Lenguaje de programación Perl
o Base de datos del servidor soporta MySQL, PostgreSQL, Oracle y SQLite.
Recomiendan altamente el uso de MySQl y PostgreSQL.
o Servidor web: Funciona con Apache y con Microsoft IIS.
2.1.3.
Mantis
Figura 2. Logo Mantis Bug Tracker
Mantis también es un sistema OpenSource gratuito. A diferencia de BugZilla, está programado en PHP y utiliza MySQL. También funciona a través del navegador. Las características principales del sistema son:
• Permite crear diversas cuentas con distintos roles cada una, de tal forma que limita quién puede abrir, analizar o resolver bugs.
• Permite realizar búsquedas aplicando distintos filtros.
• Soporta RSS.
• Permite chatear con los usuarios conectados.
• Cuenta con integración con SVN.
• Puede exportar informes en distintos formatos (CVS, Excell y Word).
• Puede crear proyectos, subproyectos, categorías, versiones, etc.
Requisitos técnicos
• Sistema operativo: Windows, Linux, Mac OS, BSDs y cualquier otro sistema operativo que soporte los requisitos del software del servidor.
• Hardware: 4 GB o más de RAM, un procesador rápido (3 GHz, por ejemplo) y un disco duro con suficiente capacidad (50 GB es lo suficientemente grande).
• Software:
o Lenguaje de programación PHP.
o Base de datos del servidor soporta MySQL, PostgreSQL,Microsoft SQL Server y Oracle.
o Servidor web: Funciona con Apache y con Microsoft IIS.
2.1.4.
Jira
Figura 3. Logo Jira Service Desk
Al principio, Jira era libre y de código abierto. Sin embargo, a partir de su cuarta versión pasó a ser de pago (desde 10 $/mes). El inconveniente de este sistema es que es más un gestor de proyectos que un gestor de incidencias. Las características más relevantes son:
• Planificación: Al ser un gestor de proyectos, permite a sus usuarios establecer prioridades y organizar sus proyectos.
• Seguimiento: En Jira se pueden definir tareas de distintos tipos. Por lo que un usuario podría crear un hito estableciendo plazos y asignárselo a cualquiera de los involucrados en el proyecto. Además, podemos definir nuevos tipos de tareas y gestionar la información con el resto del equipo.
• Lanzamiento: Proporciona la información más actualizada posible para que el lanzamiento de nuestros proyectos no suponga un alto riesgo.
• Informes: Permite la realización de informes totalmente personalizables, para un proyecto en concreto y para una fecha específica.
En marzo de 2015 se lanzó Jira Portfolio Cloud, que realiza [8]:
• Integración de las versiones existentes en Jira.
• Rápida visualización de dependencias entre las distintas tareas, entrantes o salientes.
• Planificación general de tareas en función de estimaciones del tiempo que tardarán los equipos en resolverlas.
Jira Portfolio Cloud surge como solución para mejorar la calidad y velocidad de resolución de los distintos proyectos. Al realizar la fusión con Jira, podremos agregar el trabajo de varios usuarios en un mismo sistema y actualizar su contenido en tiempo real, visualizando el estado del trabajo del resto de integrantes del equipo.
Requisitos técnicos
• Sistema operativo: Windows, Linux, Mac OS.
• Software:
o Lenguaje de programación Java.
o Base de datos del servidor soporta MySQL, PostgreSQL, Microsoft SQL Server y Oracle.
o Servidor web: Funciona con Apache.
o JRE/JDK de Java
10 DISEÑO E IMPLANTACIÓN DE UN SISTEMA DE INCIDENCIAS BASADO EN WORKFLOWS 2.1.5.
Iris
Figura 4. Logo Iris
Iris, por su parte, es un sistema web HelpDesk, en el que los usuarios que quieran utilizarlo sólo necesitarán un navegador web dado que está desarrollado en la nube. Los requisitos más importantes y que sirven aquí para hacer la comparativa son:
• 100% web.
• Soporta BBDD No Relacionales (NoSQL)
• Creación automática de tickets vía e-mail.
• Manejo de incidencias
• Creación de tareas totalmente personalizable
• No utiliza una plantilla fija para cada tarea dentro de un workflow, sino que cada flujo de trabajo rellena unos formularios personalizados
• FAQ's
• Permite la comunicación entre los distintos usuarios de un mismo flujo de trabajo
• Permite la creación de flujos de trabajo internos
• Permite el envío de un workflow terminado a otro flujo de trabajo para que éste lo finalice.
• Permite crear grupos y usuarios de trabajo, sin la necesidad de tener que repetir grupos.
• Asignación de prioridades Requisitos técnicos
• Sistema operativo: Windows, Linux, Mac OS.
• Software:
o Lenguaje de programación Java.
o Base de datos del servidor: NoSQL.
o Servidor web: en la nube a través de Google App Engine.
o JRE/JDK de Java
BugZilla Mantis Jira Iris Arquitectura Basado en
web
Basado en
web Basado en web Basado en
web Importación/Exportació
n Sí No Sí No
RSS Sí Sí Sí No
Relaciones entre bugs Sí
(depende, bloquea)
Sí (padre, hijo, duplicado)
Sí
(relacional/duplic ado, bloqueante)
No
Campos personalizados Sólo flags Sí Sí Sí
Aspecto visual Por medio
de plantillas Menús/CSS Menús/CSS Menús/CSS
Formularios No Sí (mostrar,
ocultar)
Sí, a través de un plugin son dinámicos
Personalizable s
Workflow Fijo
Cambiar transacciones válidas y quién puede
realizarlas
Workflows personalizables por el
administrador del sistema
Personalizable s por el administrador
Extensiones No Sí, mediante
funciones
Sí, mediante funciones y plugins para el navegador
Sí, mediante funciones
Autenticación BD/LDAP BD/LDAP Propio OpenID
Permisos
Editando código y usando grupos de usuarios
Cambiando los thresholds de cada rol (editar fichero)
El administrador del sistema asigna permisos a cada rol
Todos con permiso de lectura y escritura
Roles No
Fijos
(modificación por código)
Personalizable Personalizable Usuarios en un proyecto
concreto No Sí Sí Sí
Proyectos privados No Sí Sí Sí
Tabla 1. Comparación entre distintos sistemas HelpDesk[53]
12 DISEÑO E IMPLANTACIÓN DE UN SISTEMA DE INCIDENCIAS BASADO EN WORKFLOWS
Workflow 2.2.
Según la Workflow Management Coalition, se define workflow como:
“The automation of a business process, in whole or part, during which documents, information or tasks are passed from one participant to another for action, according to a set of procedural rules.”7
En An overview of workflow management: From process modeling to workflow automation infrastructure [] encontramos una definición más amplia:
“Workflow is a concept closely related to reengineering and automating business and information processes in an organization. A workflow may describe business process tasks at a conceptual level necessary for understanding, evaluating, and redesigning the business process. On the other hand, workflows may capture information process tasks at a level that describes the process requirements for information system functionality and human skills. The distinction between these workflow perspectives is not always made, and sometimes the term workflow is used to describe either, or both, of the business and information systems perspectives.
Workflow management (WFM) is a technology supporting the reengineering of business and information processes.”8
El término workflow nace en el mundo empresarial como una nueva forma de entender los procesos de producción y las tareas implicadas. Los workflows nacen de la necesidad de estudiar cómo funcionan estos procesos: los agentes implicados, la estructura y reparto de tareas, como se realizan estas tareas, como se ordenan en el tiempo y como dependen unas de otras, como se organiza la información y como se evalúa el cumplimiento de las tareas.
En términos de calidad, el uso de workflows en los procesos permite un análisis profundo de estos para su mejora y optimización.
En términos de trabajo, el workflow permite un seguimiento y control mejorados sobre los procesos de trabajo respecto de los modelos de trabajo tradicionales.
En informática toma un especial interés puesto que sin el control de los procesos, sería muy difícil coordinar a grupos de personas en trabajo colaborativo o en grupo.
7 Ref. [76, p.8]
8 Ref. [13, p.2]
2.2.1.
Definiciones
Definimos algunos conceptos ligados a los workflows:
• Proceso: Un proceso es un conjunto de procedimientos y/o actividades que se realizan con el fin de alcanzar un objetivo dentro de una estructura organizativa.9
• Tarea: Una tarea o actividad es cada uno de los pasos dentro de un proceso.
Estas pueden ser manuales, sin automatización por ordenador; o pueden ser automáticas o de tipo workflow. Estas últimas requieren de recursos humanos y/o maquinas que soporten la ejecución de la tarea.10
• Sistema de gestión de flujos de trabajo: Un sistema de gestión de flujos de trabajo es un sistema, apoyado en el uso de software informático, que permite la definición, creación y gestión de ejecución de workflows. Podemos decir que Iris es un sistema de gestión de workflows orientado a incidencias de sistema.11
• Agente: Generalmente, el término agente se relación con un recurso humano, pero también puede ser una maquina como un agente inteligente.12 2.2.2.
Ejemplo práctico de workflow: el coche roto
El concepto de workflow es algo abstracto puesto que sirve para cualquier proceso o tarea imaginable. Por ello, para explicar mejor el concepto, vamos a poner un ejemplo práctico y cómo funcionaría:
El coche roto
Nuestro coche no funciona, así que lo llevamos a un taller. En el taller, el jefe de mecánicos crea workflow de reparación de coche. Este se divide, inicialmente, en las tareas de recogida de datos, análisis de datos, diagnostico de problemas, planteamiento de soluciones, cálculo de presupuesto, comunicación con el cliente y tareas pendientes en función de las anteriores.
1. Recogida de datos: El mismo jefe de mecánicos se encarga de preguntarnos acerca del problema. Le decimos que le cuesta frenar y hace un ruido raro en el lado derecho.
2. Análisis de datos: El jefe de mecánicos resuelve que el problema viene del sistema de frenado del coche.
3. Diagnóstico de problemas: El mecánico 1 es asignado para desmontar la rueda derecha y hacer un diagnóstico del problema con el sistema de frenado. Al
9 Ref. [76, p.10]
10 Ref. [76, p.13]
11 Ref. [76, p.9]
12 Ref. [76, p.18]
14 DISEÑO E IMPLANTACIÓN DE UN SISTEMA DE INCIDENCIAS BASADO EN WORKFLOWS desmontar la rueda encuentra que el sistema hidráulico del disco se ha perforado y pierde líquido de frenos.
4. Planteamiento de soluciones: El mecánico 1 plantea dos soluciones: o cambiar el hidráulico o parchearlo para impedir la pérdida de líquido.
5. Calculo de presupuesto: Se le encarga a administración calcular los presupuestos para las soluciones.
6. Comunicación con el cliente: Administración nos llama y nos plantea los dos presupuestos. Elegimos sustituir la pieza. Además, les decimos que nos pinten la puerta izquierda porque tiene un desconchón. Se nos comunica el nuevo presupuesto.
7. Tareas pendientes: Se añaden nuevas tareas al workflow: pedir la pieza, sustituir la pieza, comprobar la reparación, pintar la puerta, llamar al cliente, cobrar al cliente y entregar el coche.
8. Reparacion de la rueda:
a. Pedir la pieza: Administración se encarga de pedir la pieza a Alemania.
b. Sustituir la pieza: Se asigna al mecánico 2 sustituir la pieza.
c. Comprobar la reparación: El jefe de mecánicos y el mecánico 2 realizan pruebas para comprobar que el problema se ha resuelto.
9. Pintar la puerta: Se le asigna al mecánico 3 la tarea de pintar la puerta mientras se repara la rueda. Esta tarea es más rápida así que no debería interferir en las tareas de reparación.
10. Llamar al cliente: Administración nos llama para comunicarnos que el coche ha sido reparado con éxito.
11. Cobrar al cliente: Cuando llegamos al taller nos cobran la reparación en administración.
12. Entregar el coche: Nos entregan nuestro coche reparado.
2.2.3.
Definición del sistema Iris como sistema de gestión de workflows
Para definir el sistema Iris como sistema de gestión de workflows analizamos las funciones que lo definen como tal:
• Definición y creación de workflows: El sistema Iris crea de forma automática un workflow asociado a cada nueva incidencia.
• División de tareas: El administrador del sistema define las tareas dentro del workflow y distribuye las mismas entre los agentes implicados.
• Seguimiento del proceso: El sistema recoge en todo momento los avances y el estado del proceso, permitiendo su consulta.
2.2.4.
Ejemplos prácticos de workflow dentro del sistema Iris
Registro de personal
Una persona de administración tiene que solicitar el registro de nuevo personal en la intranet de la escuela. Para esto, envía una solicitud a través del sistema Iris. Esta solicitud genera de forma automática un nuevo workflow llamado “registro de personal nuevo” usando el tipo de workflow definido previamente por el administrador como “Registro”.
Este workflow se divide en la tareas: introducción de datos académicos, introducción de datos personales, registro en la intranet. Una vez completadas las tareas se devuelve un correo de información a administración.
1. Introducción de datos académicos: Se asigna a una persona de administración para que recopile e introduzca en un formulario los datos académicos de los nuevos usuarios.
2. Introducción de datos personales: Se asigna a la secretaria del director la recopilación e introducción de datos personales de los nuevos usuarios.
3. Registro en la intranet: Una vez rellenos los formularios de datos, el webmaster registra los nuevos usuarios en la intranet.
Duda de un alumno
Un alumno plantea una duda acerca de la solicitud de su título de TFG a través de una incidencia anónima. Esto crea un workflow del tipo “Duda administración” llamado “Solicitud de TFG”. Consta de la tarea responder.
1. Responder: Administración responde al alumno con toda la información acerca de la solicitud del título.
Creación de guías docentes
Todos los años hay que actualizar las guías docentes. Para ello el subdirector de calidad e innovación docente envía una solicitud a través de Iris. El workflow creado es de tipo “Guías docentes” y se llama “Guías docentes 2015-16”. Este workflow consta de las tareas: envío de información a secretaria de dirección, creación y traducción de página web, enlace de documentos.
1. Envío de información: el subdirector de calidad e innovación docente envía las guías en formato pdf a la secretaria de dirección.
2. Creación y traducción: El becario webmaster crea la página web nueva y el becario traductor web traduce la página al inglés.
3. Enlace de documentos: La secretaria de dirección enlaza los documentos pdf en la página web.
16 DISEÑO E IMPLANTACIÓN DE UN SISTEMA DE INCIDENCIAS BASADO EN WORKFLOWS
Cloud computing 2.3.
2.3.1.
Introducción: Del proyecto ARPANET a la web 2.0
Internet no siempre ha sido lo que conocemos en la actualidad. Lo que empezó como un proyecto de la agencia de proyectos de investigación avanzada (ARPA en sus siglas en inglés, lo que hoy se conoce como DARPA, que desarrolla armamento para EEUU) para comunicar ordenadores a larga distancia se ha terminado como una red de redes que comunica casi cualquier punto del planeta.
Durante los años 60 y 70 ARPA trabajó con diversas universidades como el MIT, la UCLA y Stanford para crear una red que permitiese a los investigadores acceder a la información de otras universidades y laboratorios en lo que conocería como ARPAnet y que más tarde pasaría a ser Internet.
Ya en los años 80 aparecen los actuales protocolos de red TCP/IP e Internet empieza a crecer gracias a las redes públicas y privadas que surgen por el planeta.
La web original, conocida hoy como web 1.0 solo permitía el uso pasivo, es decir, el contenido se creaba y el usuario accedía a él sin ninguna interacción posible. Con la aparición de las redes sociales, los blogs (bitácoras digitales) y otras herramientas de creación de contenido, la web pasa a su versión 2.0. Esto no significa que nadie pulsase el botón Update de internet, si no que pasaba a una nueva época en la que el usuario, aparte de consumir, generaba contenido de forma directa.
2.3.2.
Modelos de servicios
Existen diferentes modelos de servicio de cloud computing, dependiendo de los recursos aportados por el proveedor:
• Infraestructure as a Service (IaaS): Es el encargado de proporcionar la infraestructura necesaria para la computación física y virtual, así como una amplia gama de recursos como balanceadores de carga, firewalls, direcciones IP, etc. Su existencia se apoya en la virtualización del hardware.[34]
• Plataform as a Service (PaaS): Proporciona plataformas que incluyen sistema operativo, entorno de ejecución de lenguaje de programación, BBDD, servidores web, etc. Su existencia se apoya en el IaaS.[35]
• Software as a Service (SaaS): Proporciona acceso a las aplicaciones sin tener que preocuparnos acerca de la instalación, configuración ni funcionamiento de las mismas. Su existencia se apoya en el PaaS.[36]
2.3.3.
Google App Engine
Figura 5. Logotipo Oficial de Google App Engine
Google App Engine es una plataforma de Google que proporciona herramientas a los desarrolladores para crear aplicaciones web y desplegarlas en sus servidores.
En el apartado 2.2.1 se explicó qué es el cloud computing y por qué se elegía Google App Engine como plataforma. Que el proyecto Iris esté desarrollado sobre GAE permite una serie de ventajas:
• El servicio gratuito ofrece, entre otras, las siguientes características[28]: o Almacenamiento en la nube de 5GB.
o 657.000 llamadas al día al Channel service (máx.: 3.000 llamadas /min).
o Almacenamiento de código y datos estáticos: 1 GB.
o Número de índices al día: 200.
o Operaciones de escritura, lectura y pequeñas operaciones al día: 50.000 de cada.
o Correos enviados al día: 100.
o Datos enviados y recibidos al servicio: 4GB cada uno.
• El servicio es gratuito, lo que elimina los costes de mantenimiento a corto plazo.
• Permite la programación de la aplicación es varios lenguajes: Python, Java, PHP y Go. Hemos elegido Java para desarrollar Iris.
• Una amplia y detallada documentación facilitada por Google.
• Las características necesarias para considerarse computación en la nube:
o Desde cualquier sitio.
o En cualquier momento.
o Desde cualquier navegador actualizado.
• Su uso reduce las emisiones de CO2 a la atmósfera, puesto que sus servidores generan menos que el equivalente en servidores individuales para el servicio prestado.
18 DISEÑO E IMPLANTACIÓN DE UN SISTEMA DE INCIDENCIAS BASADO EN WORKFLOWS A pesar de todas estas ventajas, existen ciertas consideraciones que, si bien, no tienen por qué ser desventajas podrían serlo debido a su naturaleza [39]:
• Seguridad: La seguridad del servicio depende de la seguridad ofrecida tanto por el desarrollador de la aplicación web como aquellos proveedores de tecnologías de las que depende el servicio. En nuestro caso dependeremos de la seguridad implantada en la aplicación web por nuestro lado y de la seguridad implantada por Google a través de Google App Engine y sus servidores.
Recientemente [33], Google ha lanzado una herramienta para analizar la seguridad de las aplicaciones que corren sobre GAE. En la figura 6 se ven resultados para el sistema Iris.
Figura 6. Test de seguridad para Iris con la herramienta Cloud Security Scanner de Google.
• Privacidad: Los datos de la aplicación, de los usuarios y toda la información sobre las incidencias se almacena en los servidores de Google App Engine. Esto supone un riesgo del lado del servidor, porque la vulneración de los datos depende la seguridad del servidor. Para evitar guardar contraseñas en la aplicación, por su naturaleza sensible, usamos OpenID para la identificación de usuarios.
• Conectividad: El servicio depende de que la conexión funcione por ambos lados. A diferencia de un SGI en un servidor propio, en el que solo dependemos del estado del mismo, con Google App Engine también dependemos de que sus servidores estén en línea. Esto es una preocupación menor, puesto que Google es una empresa muy grande y no es previsible que sus servidores estén fuera de línea.
