Repositorio Institucional de Documentos

Aplicación Web para la ejecución y gestión de auditorías de calidad internas Autor: Juan Carrey Labarta Director: D. Ignacio Vilalta Ponente: José Javier Merseguer Hernáiz Empresa: Comex Grupo Ibérica Centro Politécnico Superior Universidad de Zaragoza Departamento de Informática e Ingeniería de Sistemas Ingeniería Informática Curso 2009-2010, Mayo 2010 Juan Carrey Labarta – Proyecto fin de carrera Página 1 Juan Carrey Labarta – Proyecto fin de carrera Página 2 GESTIÓN DE AUDITORÍAS DE CALIDAD INTERNAS RESUMEN Se trata del desarrollo e implantación de una aplicación Web para la gestión de auditorías de calidad internas que actualmente la empresa Comex Grupo Ibérica realiza de forma manual. Esta aplicación permitirá la administración de la misma de forma privada, permitiendo gestionar al personal (auditados/auditores), los proyectos y procesos (partes del proyecto) que se auditan, los tipos de auditoría existentes así como las preguntas que se realizan en cada auditoría. Además se podrán gestionar diversos parámetros para la realización de avisos automáticos que sirven para recordar a los interesados de hitos o fases de las auditorías. Por otra parte y de forma separada existirá una parte pública donde se podrán ejecutar auditorías, comprobar el seguimiento de las no conformidades (respuestas negativas a las preguntas) del proyecto y acceder a diversos informes y métricas calculadas por el sistema. La aplicación obtendrá información de los proyectos y personal de la empresa a través de un servicio Web existente, almacenándose en cada caso la información relevante. La arquitectura del sistema se basa en un diseño de tres capas: Una capa de presentación en HTML / JSP, utilizando Ajax y ejecutándose sobre un servidor Tomcat. Una capa de control, basada en componentes de Spring, donde se intercambiarán los datos con la capa de presentación y se ejecutarán las acciones correspondientes para obtener los datos. Una capa de acceso a datos basada en el patrón de diseño Data access object (DAO) y accediendo a ella a través de una fachada (patrón facade). Además existen dos capas de seguridad intermedias para el acceso a la parte privada, una previa a la capa de vista y otra en la capa de acceso a datos. El motor de base de datos utilizado es SQL Server 2005, para acceder a él utilizaremos Java Persistence Api (JPA) como mapeador objeto-relacional (Object Relational Mapping ORM) utilizando la implementación de Hibernate, aunque realizando una implementación fiel al estándar Java Persistence API (JPA) sin utilizar aspectos propios a la implementación de Hibernate. Se han realizado las pruebas necesarias para la validación y verificación del buen funcionamiento del software. Esta aplicación pretende solventar la problemática existente de la distribución de las hojas Excel del método manual que dificultan en gran medida la realización de seguimientos, informes generales, cálculos de métricas, fechas de auditorías, etc. Juan Carrey Labarta – Proyecto fin de carrera Página 3 Tabla de contenidos INTRODUCCION..........................................................................................................................4 OBJETIVO Y ALCANCE DEL PROYECTO ..........................................................................4 ÁMBITO Y MOTIVACION ...........................................................................................4 HERRAMIENTAS Y TECNOLOGIAS................................................................................5 Herramientas.....................................................................................................5 Tecnologías .......................................................................................................6 Otras tecnologías ...............................................................................................7 ESTRUCTURA DEL DOCUMENTO ..................................................................................7 PLANIFICACION..........................................................................................................................9 FASES DEL PROYECTO ..............................................................................................9 CALENDARIO FIJADO.............................................................................................10 HITOS DEL PROYECTO............................................................................................11 GESTION DE CONFIGURACIONES ..............................................................................11 ANALISIS..................................................................................................................................12 REQUISITOS FUNCIONALES PARTE PUBLICA................................................................12 REQUISITOS FUNCIONALES PARTE PRIVADA ...............................................................14 REQUISITOS NO FUNCIONALES ................................................................................15 DISEÑO DE LA BASE DE DATOS.................................................................................................16 MODELO CONCEPTUAL ...........................................................................................16 MODELO LOGICO ..................................................................................................18 MODELO FISICO ...................................................................................................18 DICCIONARIO DE DATOS ........................................................................................19 DISEÑO DEL SISTEMA...............................................................................................................20 ARQUITECTURA SOFTWARE.....................................................................................21 Capa de Modelo ...............................................................................................22 Capa de control................................................................................................22 Capa de vista...................................................................................................22 PATRONES DE DISEÑO ...........................................................................................23 Patrón Data Access Object (DAO).......................................................................23 Patrón Fachada................................................................................................24 DISEÑO DE CLASES ...............................................................................................24 CASOS DE USO .....................................................................................................26 Gestión de auditorías........................................................................................26 IMPLEMENTACION ....................................................................................................................29 MULTIACTIONFORMCONTROLLER ............................................................................29 SERVICIO WEB ....................................................................................................32 MAPEO OBJETO RELACIONAL...................................................................................32 CARGA PEREZOSA ................................................................................................. 33 PAGINACION .......................................................................................................34 SUGERENCIAS......................................................................................................34 AVISOS ..............................................................................................................35 ESTADO DEL PROYECTO Y TIPO DE NO CONFORMIDAD ...................................................36 PRUEBAS...................................................................................................................................38 INTRODUCCION....................................................................................................38 PLAN DE PRUEBAS ................................................................................................38 RESULTADO DE LAS PRUEBAS ..................................................................................39 CONCLUSIONES ........................................................................................................................41 PROBLEMAS ENCONTRADOS ....................................................................................41 TRABAJO FUTURO ................................................................................................. 42 CALENDARIO FINAL...............................................................................................43 VALORACION PERSONAL.........................................................................................44 BIBLIOGRAFIA..........................................................................................................................45 ÍNDICE DE FIGURAS Y TABLAS .................................................................................................46 REFERENCIAS ...........................................................................................................................47 Juan Carrey Labarta – Proyecto fin de carrera Página 4 Introducción Objetivo y alcance del proyecto El objetivo de este proyecto consiste en poner en marcha una aplicación Web de gestión que asista al personal de la empresa Comex Grupo Ibérica a la configuración y realización de auditorías de calidad internas, mejorando el sistema actual y asegurando el mantenimiento de la funcionalidad existente. Los objetivos específicos de este proyecto son: Resolver los problemas existentes en el sistema actual. Facilitar la gestión de auditorías de calidad mediante un sistema de información Mejorar el sistema actual con diversas herramientas El marco que define al proyecto se basa en el desarrollo y puesta en marcha del sistema de gestión, asegurando el buen funcionamiento del mismo, obteniendo como resultado una aplicación que, cumpliendo los objetivos marcados, pueda ser en la medida de lo posible, sostenible y ampliable en un futuro. Ámbito y motivación El proyecto se enmarca en la empresa Comex Grupo Ibérica, donde actualmente el proceso de gestión de auditorías se realiza de forma manual. A continuación se explican los diversos problemas que surgen del método de gestión actual de las auditorías en la empresa. La información se recoge en diversas hojas Excel que se almacenan junto a la información de cada proyecto, lo cual dificulta la localización de una auditoría. Los resultados de las auditorías se reflejan posteriormente en el “Informe General de Auditorías”, replicando de está forma la información, lo cual incurre en posibles inconsistencias. Semestralmente se calculan una serie de métricas, que se realizan también de forma manual, llevando consigo el problema de tener que revisar una a una todas las hojas Excel de auditorías anteriores, situándose cada una en un lugar diferente dependiendo del proyecto, lo cual hace casi imposible realizar una comparación entre proyectos y muy complicado el cálculo de diversas métricas. Cada proyecto además tiene otra hoja Excel con el seguimiento de las no conformidades, que recogen las respuestas negativas de las auditorías ejecutadas sobre dicho proyecto, por lo que resulta complicado realizar el seguimiento dado que todo está en hojas Excel independientes, con información replicada. Otro de los problemas existentes con el sistema actual es que el responsable de calidad debe estar atento a las fechas planificadas para las auditorías y ejecutarlas conforme a la planificación. Esta aplicación pretende solucionar toda esta problemática dado que toda la información resultante de las auditorías se encuentra centralizada en una base de datos única, evitando la replicación, por lo que la explotación de datos será mucho Juan Carrey Labarta – Proyecto fin de carrera Página 5 más sencilla. Además podrá enviar avisos a las personas interesadas a modo de recordatorio para cumplir con las planificaciones establecidas. Herramientas y tecnologías Herramientas Se listan a continuación las diversas herramientas empleadas durante el proyecto, con sus respectivas referencias a su documentación. Apache1 Apache Tomcat se ha utilizado como Servidor Web, se trata de un servidor de aplicaciones Web de uso extendido. OpenSVN2 (Open SubVersion) y Tortoise3 Debido a que en la empresa en la que se enmarca el proyecto trabajan con un sistema de control de versiones se ha optado por aprender a utilizarlo y usarlo para este proyecto. Se utilizan OpenSVN como servicio gratuito para almacenar las versiones y Tortoise para la gestión local de los ficheros. Navegadores Web Para la visualización del resultado y realización de pruebas se han utilizado Internet Explorer4 y Mozilla Firefox5. Microsoft Office 2003 y Acrobat Reader Para la generación de documentos se han utilizado estas herramientas de edición de texto. Eclipse6 Como entorno de desarrollo se ha utilizado Eclipse debido a las grandes ventajas que nos ofrece para el desarrollo de aplicaciones java, una de las principales ha sido el poder lanzar un servidor tomcat en modo depuración, en el propio entorno de desarrollo, lo cual ha facilitado enormemente la resolución de errores. Edge Diagramer7 y GranttProject8 Hemos escogido estas dos aplicaciones para la generación de diagramas y calendarios debido a que ya las conocíamos anteriormente y nos parecieron unas herramientas sencillas de manejar, completas y muy útiles. Testlink9 Para la planificación y ejecución de pruebas hemos utilizado Testlink, se trata de una aplicación Web de gestión donde se introducen los planes de prueba con los pasos a seguir en cada caso de prueba, para que cualquier persona con acceso a la aplicación a la que se le hayan asignado la ejecución de diversos casos de prueba pueda ejecutarlos y redactar los resultados. Juan Carrey Labarta – Proyecto fin de carrera Página 6 Los resultados se obtienen en unos informes generados por la aplicación, esta herramienta que se está empezando a usar en la empresa, por lo que hemos decidido emplearla nosotros también. Microsoft SQL Server Studio Para la gestión de la base de datos en general hemos usado este software que ya estaba previamente instalado en el sistema y nos pareció bastante bueno para manejar SQL Server. Tecnologías Persistencia: Java persistence Api (JPA)10 Object Relational Mapping Se ha decidido utilizar JPA como Object Relational Mapping (ORM) debido a su gran potencia y sencillez, nos hemos intentado abstraer lo más posible del proveedor de persistencia (implementación), dado que de esta forma nos es muy cómodo cambiar. Proveedor de persistencia: Hibernate11 Por su madurez y porque otros proveedores nos dieron problemas anteriormente (para la misma implementación), además será la tecnología usada en la empresa en un futuro y es gratuito. Base de datos: SQL Server 2005 Como gestor de base de datos, la empresa decidió almacenar la información para las auditorías en su base de datos SQL Server 2005 para mantener en ésta todos los datos internos. Servicios Web: WSS4J12 y Axix 1.413 Para el acceso a los Servicios Web existentes, hemos utilizado Web-Service Security for Java (WSS4J) por su fácil configuración a través de un fichero de despliegue, mientras que en otros la configuración iba metida en el código, además buscando información sobre como compatibilizar con Web Service Enhacement (WSE) 3.0 era de las pocas tecnologías para las que se dejaba clara la solución a uno de los problemas que hay en la interoperabilidad entre estos servicios Web. Spring Framework14 Como tecnología Web para la creación de sistemas Web complejos que facilitan la estructuración en tres capas Modelo – Vista – Controlador, (MVC17) así como las grandes ventajas que ofrece sobre otros Frameworks similares como Struts, el cual se planteó inicialmente como opción debido a que iba a ser lo que se iba a utilizar en la empresa en proyectos futuros, pero se cambió a Spring porque era nuestra primera opción dado que mejoraba sustancialmente parte de los problemas que tiene Struts y además la empresa decidió utilizar Spring en sus futuros proyectos. Spring Security15 Dentro de Spring, existe una herramienta que sirve para configurar permisos y cuentas con el fin de restringir el acceso a diversas vistas de la Web a determinados Juan Carrey Labarta – Proyecto fin de carrera Página 7 usuarios, es por ello que decidimos escoger esta opción como seguridad en la capa de vista, porque nos venía con el propio Framework , ya estaba implementado y además era bastante bueno. JUnit Herramienta que nos facilita en gran medida las pruebas unitarias y de integración, realizando para cada caso de prueba una clase JUnit que realice las pruebas sobre un módulo en concreto, ya sea de forma unitaria, o de forma integrada (si el modulo está integrado en el sistema). Otras tecnologías Java con lenguaje de programación para todo el control y acceso a datos. Java Server Pages (JSP) para las vistas, que mezclan código HTML con Java Cascading Style Sheets (CSS) para el diseño Ajax para añadirle usabilidad al sistema JavaScript para añadirle usabilidad al sistema (Para hacer llamadas Ajax y mostrar calendarios) HyperText Markup Language (HTML) como código final generado por el servidor para el navegador Web. Se han utilizado estos lenguajes de programación, en principio estipulados por la empresa para la realización del proyecto dado que es con lo que habitualmente se trabaja en aplicaciones Web. Estructura del documento La estructura general del documento consta de diversas secciones donde cada una está subdividida en subapartados, este documento se divide en una introducción donde se explica brevemente el contexto del proyecto, seguida de varias secciones que se relacionan con diversas fases del proyecto, que se describen a continuación. En la sección de análisis se describe el proceso en el cual el sistema manual actual se transforma en una serie de requisitos que deberá cumplimentar la aplicación a desarrollar. En el diseño de la base de datos, se describen brevemente los pasos seguidos durante el diseño del modelo de datos destacando los aspectos más relevantes. En la fase del diseño del sistema, se explican los métodos que hemos llevado a cabo para obtener un esquema general y la forma de construcción del sistema sin llegar al detalle de la implementación, detallando los casos más particulares y que nos han parecido de mayor interés. En el apartado donde se describe la implementación, hemos considerado explicar los casos problemáticos más destacados e interesantes en la implementación, explicando la solución adoptada. Juan Carrey Labarta – Proyecto fin de carrera Página 8 La última de las secciones referente a las pruebas contiene información relevante de las pruebas indicando los resultados generales de su ejecución, sin entrar en el detalle de cada caso específico de prueba. En el último apartado del documento ponemos de manifiesto nuestras reflexiones y conclusiones sobre el proyecto, así como una valoración y estimación del trabajo realizado. Los anexos contienen la información completa de las fases del proyecto (análisis, diseño, pruebas, documentación, etc.), con todos los detalles pertinentes. Juan Carrey Labarta – Proyecto fin de carrera Página 9 Planificación Durante el proceso de planificación del proyecto, planteamos el ciclo de vida del software a desarrollar, los periodos de tiempo durante los cuales se realizarían cada una de las tareas y se escogen las herramientas y tecnologías a utilizar. El proyecto se planteo para tener una duración aproximada de 400 horas, siguiendo un proceso iterativo incremental donde las primeras fases previas al desarrollo se hicieron siguiendo el modelo en cascada, donde se establecieron los requisitos y diseño iniciales, que poco a poco en las sucesivas iteraciones se van refinando y mejorando para ir desarrollando versiones intermedias, para llegar a obtener el producto final. Estas iteraciones, donde se refina el análisis y los requisitos, vienen recogidas en la fase de implementación, dado que es imposible planificar todas las pequeñas fases por cada versión intermedia a realizar. Cada módulo realizado, se prueba de forma unitaria y posteriormente se integra al sistema, realizando las pruebas de integración, consiguiendo en cada integración versiones intermedias. Fases del proyecto Planificación En esta etapa se planifican los calendarios y se establece la gestión de configuraciones. Análisis En esta fase se intentan captar todas las necesidades del cliente, generando un análisis de requisitos, se escogen las herramientas a utilizar y se establecen las tecnologías que se utilizan, se trata de un análisis inicial que puede ser modificado en posteriores revisiones, que se realizan durante el desarrollo. Diseño En el diseño se generan todos los documentos necesarios para plasmar la solución diseñada, lo más claramente posible, realizando diagramas de clases, esquemas conceptuales, casos de uso, etc. Se escogen los métodos para realizar la implementación (Arquitectura del sistema, patrones de diseño, etc.), y se definen cada uno de los nombres en el diccionario de datos. Se genera además el modelo físico de la base de datos donde se almacenará la información. Implementación En esta fase se desarrollara todo el código fuente siguiendo las pautas del diseño, apartado por apartado (modulo), reanalizando y rediseñando cada uno de forma particular y en detalle, posteriormente se prueba dicho apartado y se integra al sistema, hasta completar todos los apartados y cumplimentar los requisitos. Juan Carrey Labarta – Proyecto fin de carrera Página 16 Diseño de la base de datos Modelo conceptual Dentro de este apartado se identifican todas las necesidades de información de cada uno de los procesos que conforman el sistema de información, con el fin de obtener un modelo de datos que contemple todas las entidades, relaciones y atributos necesarios para dar respuesta a dichas necesidades. Hemos realizado un esquema conceptual entidad-relación de los datos, durante los rediseños hubo muchos cambios y varias versiones del esquema. Así mismo hay datos no relacionados con el esquema pero que requieren ser guardados, son por ejemplo los diversos parámetros configurables de la aplicación, las cuentas de administración y los avisos. Las entidades más importantes del sistema son entre otras: La Auditoría, dado que el objetivo principal del sistema es gestionar auditorías. La “NoConformidad”, que son las respuestas contestadas negativamente y que se revisan en un seguimiento, ya que se tiene especial interés en éstas para poder solucionar los problemas que se manifiestan por esa no conformidad. El EstadoGeneral y el TipoNoConformidad que se explican más adelante en el apartado de implementación. Los atributos han sido omitidos para mayor claridad y se detallan en el anexo correspondiente al diseño de la base de datos. Los detalles se pueden ver en el anexo de diseño de base de datos (Anexo 4), donde se muestran todos los pasos seguidos hasta la obtención del esquema fisico final. La versión final del esquema conceptual es el siguiente (Entidades relacionadas) Auditoria Respuesta Pregunta Tipo Auditoria Proyecto Personal Seguimiento Acciones No Conformidad Ref.Documental TipoNo Conformidad EstadoGeneral CriterioEstado M:N Proceso 1:N tipo 1:N correctiva 1:N cierre 1:N tiene 1:1 posee 1:N tiene posterior 1:N previo 1:N 1:N tipo M:N cuestionario M:N Refs 1:N referente 1:N consiste 1:N jefe M:N auditado M:N auditor M:N responsables 1:N sobre Negativa Ilustración 2 – Diseño conceptual de la Base de datos Leyenda Para las relaciones (1 : N), la punta de la flecha indica la entidad a la que se arrastra la clave primaria como foránea, es decir: [Entidad A] ----- 1 : N ---> [Entidad B]: Significa que una instancia de la entidad A puede tener relación con 0 o más instancias de la entidad B. Juan Carrey Labarta – Proyecto fin de carrera Página 17 Juan Carrey Labarta – Proyecto fin de carrera Página 18 Modelo lógico A partir del modelo conceptual generado y siguiendo una serie de pautas16, se transformó a un modelo lógico, también conocido como esquema relacional, en el cual se generan las distintas relaciones que en el diseño físico se transformaran finalmente en tablas. Durante esta fase se ha realizado la normalización de la base de datos hasta la tercera forma normal, en este procedimiento hemos obtenido como resultado la eliminación de diversos atributos y la consideración de eliminación de otros, cuya decisión se toma durante el diseño físico. Detallamos los aspectos más relevantes de la normalización. Normalización de auditoría En la entidad Auditoría disponíamos de un atributo “valida” que indicaba la validez o invalidez de la auditoría, y otro atributo “estado” que marcaba el estado en el que se encontraba la auditoría (en curso, planificada, caducada, finalizada, invalidada). En la segunda forma normal encontramos la dependencia funcional entre el atributo estado y válida. Si “estado” era invalidada, entonces “valida” era falso. Si “estado” era distinto de invalidada, entonces “valida” era verdadero. Se tomó la decisión de eliminar el atributo “valida”, dado que podía inferirse del atributo “estado”. Normalización de Proceso En la normalización de Tipo de Proceso, el atributo “nombre” que corresponde al nombre del proceso era un simple atributo, sin embargo se vio que era clave candidata. Modelo físico Durante el diseño físico se tomaron decisiones para aumentar el rendimiento de la base de datos, a continuación detallamos algunas de las decisiones tomadas durante esta fase. Claves candidatas de gran tamaño Para tablas con claves candidatas grandes, donde teníamos por ejemplo en la entidad pregunta una clave candidata que era la propia pregunta (un texto de tamaño 300), se ha optado por crear una clave autogenerada mucho más pequeña de forma que la indexación fuera más eficiente. Claves modificables En la entidad Tipo de Proceso, había una clave candidata “Nombre” que el sistema debía permitir cambiar, este cambio afectaría a todas sus relaciones en forma de cascada, sin embargo sabemos que SQL Server 2005 tiene problemas en la Juan Carrey Labarta – Proyecto fin de carrera Página 19 actualización en cascada, por lo que hemos decidido ponerlo como atributo normal y crearle una clave primaria autogenerada. Referencia documental Teníamos una entidad Referencia documental, donde sólo necesitábamos conocer el nombre de la referencia documental, lo cual hace indicar la poca importancia de esta entidad. Esta entidad tenía una relación M:N con la entidad “Pregunta”, lo cual nos llevaba a obtener dos tablas, una contenida en otra: fk: Clave foránea pk: Clave primaria Referencia_Documental__Pregunta (nombre_documento (fk), referencia_pregunta (fk)) Referencias_Documentales (nombre_documento (pk)) En la tabla de la relación (Referencia_Documental_Pregunta) aparecen todas las referencias documentales de la tabla Referencias_Documentales, por lo que ésta segunda tabla se podía obtener de la primera, lo cual hizo la posibilidad de eliminar dicha tabla Sin embargo, al estar utilizando un mapeador automático a relaciones, esta tabla tubo que mantenerse, dado que para dicha relación, JPA (estándar de mapeo objetorelacional) se tiene en la base de datos tres tablas, una para cada entidad y otra para la relación, y no existe la posibilidad de eliminar ninguna de ellas. El esquema físico final puede encontrarse en el anexo del diseño de la base de datos. Diccionario de datos Hemos generado un diccionario de datos en el cual se definen todos los atributos del esquema físico final para aclarar su significado y su comportamiento en el sistema a desarrollar, de forma que en caso de futuras ampliaciones, mejoras o mantenimiento del sistema, se pueda acceder a una definición aclaratoria de cada uno de los atributos del modelo de datos. Juan Carrey Labarta – Proyecto fin de carrera Página 20 Diseño del sistema El diseño del sistema consiste en definir cada uno de los apartados de los que se compone el sistema así como el comportamiento y las decisiones de diseño adoptadas para obtener una solución lógica abarcando todos los requisitos del sistema. Además en el diseño se generan diversos esquemas que dividen en diversas capas el sistema con el fin de facilitar la comprensión del mismo. Así mismo durante esta fase se eligen los patrones de diseño más adecuados para implementar el sistema y que se adecuan a las necesidades requeridas que se recogieron durante la fase de análisis. Arquitectura software La arquitectura del sistema se ha dividido en tres capas, siguiendo un patrón de diseño de arquitectura software para aplicaciones Web (Model View Controller)17, que son el Modelo, la Vista y el Control. Para facilitar esta tarea hemos utilizado Spring Framework14 que implementa este patrón, y facilita la implementación de la aplicación Web ofreciendo múltiples herramientas, como por ejemplo seguridad para el acceso y mantenimiento de sesiones. Al tratarse de una aplicación Web, el esquema parte de un navegador Web desde el cual el usuario podrá acceder a la aplicación. En la siguiente figura podemos observar el esquema general de la aplicación sin entrar mucho en el detalle físico. Spring framework Facade User User DAO Componentes JSP Usuario BeanDAO (Uno por Bean) WebService Manager Servicio web JPA (ORM) Spring security Autenticación Autenticación Facade Admin Admin DAO BeanAdminDAO (Uno por Bean) Control Forms VISTA CONTROL MODELO Ilustración 3 - Diagrama de Componentes Software Juan Carrey Labarta – Proyecto fin de carrera Página 21 Juan Carrey Labarta – Proyecto fin de carrera Página 22 Capa de Modelo La gestión del mapeo objeto-relacional se delega en manos de JPA, reconocido estándar que cuenta con diversas implementaciones, por lo que resultará bastante fácil y rápido el cambio de proveedor. Se utilizan dos formas de acceso a datos, una para usuarios y otra para administradores, en la segunda se requiere autenticación que irá contra la base de datos donde las contraseñas se almacenan cifradas. Todas las operaciones de administración requieren estar autenticado, de forma que saltarse la autenticación en la capa de Vista (Autenticación de Spring security15) no otorgará los permisos para acceder a los datos, solo a la capa de vista de la administración, pero vacía. De esta forma se tienen dos niveles de seguridad, uno en la capa de vista y otro en la capa del modelo. Capa de control La capa de control está formada por diversos componentes, llamados por Spring Framework, que son los que controlan la gestión de los datos requeridos por la página solicitada (vista), de forma que acceden a los datos a través de la fachada correspondiente. La lógica de negocio está implementada en estas acciones o controladores, parte de la funcionalidad también está implementada en la fachada que ofrece diversos métodos más completos. Las dos fachadas proveen a los controladores acceso a lectura y modificación de datos, de una forma más o menos simplificada. De esta forma se encapsula el acceso a datos de la lógica de negocio y además de separar la parte pública de la privada. Capa de vista La implementación del software de servicio en el sistema central se basa en la utilización de un Servidor de Aplicaciones. Entre otros, el Servidor de Aplicaciones ofrece los siguientes recursos fundamentales: Servidor Web – Capaz de servir páginas Web de construcción dinámica. Seguridad – Ofrecerá un sistema de autenticación para permitir la visualización de diversas vistas de administración, esta funcionalidad se delega en manos de Spring Security15. Componentes – Sistema capaz de ejecutar componentes de software que incluya mecanismos estándar para soportar la concurrencia y controlar las distintas sesiones de trabajo En la capa de vista se implementan las distintas vistas de la aplicación, que corresponden a las páginas JSP, que tras pasar por el servidor de aplicaciones se transforman en una página HTML dinámica. Patrones de diseño Los patrones de diseño son formas recomendables de implementar aspectos comunes a diversas aplicaciones, se han diseñado para ser fácilmente implementables, reutilizables y mantenibles, de forma que resulten ser una buena solución. Además del patrón MVC17 explicado en el apartado anterior que corresponde a un patrón de diseño de la arquitectura general, hemos adoptado otros que hemos considerado interesantes para nuestra aplicación. Patrón Data Access Object (DAO) El primero de los patrones utilizados es el patrón DAO18 para la capa de Modelo de datos, donde se encapsula la forma de acceso a los datos. abstract DAOFactory static DAOFactory getDAOFactory(..) abstract void method1(..); abstract void method2(..); .. DAOFactoryImpl DAOInterface_Bean1 getBean1DAO(); DAOInterface_Bean2 getBean2DAO(); .. void method1(..){ impl } «extends» DAOImpl_Bean «implements» «creates» Cliente «call» DAOInterface_Bean insertar() modificar() borrar() .. (Uno por cada Bean) (Uno por cada Interfaz) Figura 1 – Patrón DAO De esta forma, el cliente lo único que conocerá de la capa del modelo, serán los métodos ofrecidos por la clase DAOFactory, sin llegar a conocer la implementación propia de los métodos, incluso podríamos tener varías implementaciones del mismo Juan Carrey Labarta – Proyecto fin de carrera Página 23 Juan Carrey Labarta – Proyecto fin de carrera Página 24 método para distintas bases de datos o distintas formas de implementarlo (mediante algún ORM, de forma manual con sentencias Standard Query Language (SQL), etc.). En nuestro caso, el cliente es la fachada correspondiente (explicadas más adelante), que utiliza tanto el DAOFactory, como los diversos DAOInterface_Bean que crea el DAOFactory. Patrón Fachada Este patrón lo hemos utilizado para abstraernos aun más de la jerarquía utilizada para el acceso a datos (la del patrón DAO), mientras que de esta forma una única clase nos provee de todos los métodos necesarios y además se encarga de facilitarnos algunos métodos algo más complejos que incorporan cierta lógica de negocio, como por ejemplo la obtención del cuestionario de preguntas para una auditoría. Además tendremos implementadas dos fachadas diferentes, una para el acceso a datos como usuario y otra para el acceso a datos como administrador, de esta forma encapsulamos en cada fachada distinta funcionalidad y además simplificamos el uso de los DAO. Diseño de clases En el diseño de clases transformamos los requerimientos del sistema, tanto funcionales como de almacenamiento de datos en un esquema de clases donde se describen las clases principales y los métodos necesarios para su manejo. Los métodos descritos hacia el acceso a datos se han especificado tras el diseño de los casos de uso, donde se observa con más claridad qué datos hacen falta para cada apartado, de forma que serán los métodos a implementar por las fachadas. El diseño de clases final es muy similar al diseño físico de los datos, dado que el mapeo de JPA es una aproximación a una Tabla por Clase. En la siguiente figura podemos observar el diseño de clases realizado. 0..* 0..* 0..* 0..* 0..1 0..* 0..1 0..* 0..1 0..* 0..* 0..* 0..1 0..* 0..* 0..1 0..1 0..1 0..* 0..* 0..1 0..* 0..* 0..* 0..1 0..* 0..1 0..* 0..* 0..* 0..* 0..* 0..1 0..* 0..1 0..* 0..1 0..1 0..1 0..* Personal + + + codigo_personal email nombre_personal : java.lang.String : java.lang.String : java.lang.String Auditoria + + + + + + + + - - - fecha_auditacion valida codigo_auditoria lista_distribucion horas_planificadas numero_personas horas_ejecutadas numero_avisos estado fecha_realizacion fecha_invalidacion : java.util.Date : boolean : java.lang.String : java.lang.String : double : double : double : double : int : Calendar : Calendar + +esEjecutable () esModificable () : Boolean : Boolean Proyecto + + + codigo_proyecto nombre_proyecto tipo_proyecto : java.lang.String : java.lang.String : double TipoProceso + + + + tipo fecha_alta_tipo fecha_baja_tipo nombre_proceso : java.lang.String : java.util.Date : java.util.Date : java.lang.String Respuesta + + + respuesta observaciones codigo_respuesta : java.lang.String : java.lang.String : java.lang.String Pregunta + + + + + pregunta fecha_alta_pregunta fecha_baja_pregunta opcional descripcion_no_conformidad : java.lang.String : java.util.Date : java.util.Date : boolean : java.lang.String Seguimiento + + + estado observaciones_seguimiento codigo_seguimiento : java.lang.String : java.lang.String : java.lang.String Acciones + + + descripcion_accion tipo_accion codigo_accion : java.lang.String : java.lang.String : java.lang.String NoConformidad_Revision + + + + codigo_revision fecha_final_estimada fecha_cierre_real estado : java.lang.String : java.util.Date : java.util.Date : java.lang.String Referencias_documentales +nombre_documento : java.lang.String TipoNoConformidad +grado : java.lang.String EstadosGenerales + +tipo_estado riesgo : java.lang.String : java.lang.String Tiempo_por_defecto + +Tipo_tiempo tiempo_por_defecto : java.lang.String : double TipoAuditoria + + + + tipo_qa descripcion por_defecto especial : java.lang.String : java.lang.String : boolean : boolean Administrador + +login password : java.lang.String : long Ilustración 4 – Diagrama de clases Juan Carrey Labarta – Proyecto fin de carrera Página 25 Juan Carrey Labarta – Proyecto fin de carrera Página 32 Servicio Web En la implementación de la obtención de datos mediante un servicio Web, nos encontramos con un problema de interoperabilidad, debido a las distintas tecnologías utilizadas para la obtención del servicio y el servidor del servicio. Problema De esta forma el servicio Web estaba implementado mediante WSE 3.0, cuyo fichero de descripción de servicio web (Web Services Description Language WSDL20) no incorpora información sobre las cabeceras de seguridad requeridas por el servicio, esto se debe a que sigue un estándar diferente, y desactualizado, al que siguen los actuales servicios Web, que incorporan en el WSDL la información requerida por el servicio 21 cabeceras. Solución Tras mucho tiempo buscando soluciones por la Web, encontramos que el error se basaba en que las llamadas al servicio no incluían las cabeceras, así pues bastaba con añadir en la información de despliegue un resolutor de direccionamiento que añadiera las cabeceras pertinentes. <handler type="java:org.apache.axis.message.addressing.handler.AddressingHandler"> <parameter name="referencePropertyNames" value="*"/> </handler> De forma que se añadan todas las cabeceras, sean o no requeridas por el servicio Web. La solución recomendada en muchos sitios era olvidarse de WSE 3.0 y utilizar otra tecnología que siguiera el estándar, lo cual no nos servía dado que el servicio Web ya estaba implementado y debía usarse ese. Mapeo objeto relacional En el mapeo objeto relacional de JPA hemos utilizado anotaciones, lo cual resulta más cómodo y sostenible que los ficheros xml propios de Hibernate, de esta forma podemos cambiar de proveedor tan solo cambiando en fichero en el cual se define la configuración de la persistencia el atributo del proveedor: <provider>org.hibernate.ejb.HibernatePersistence</provider> Problema En este mapeo objeto-relacional nos encontramos con un problema a la hora de mapear una relación M:N con un atributo de por medio, en nuestro caso se trataba de la relación existente entre Estado y TipoNoConformidad, que tienen una relación M:N con un atributo “maximo_numero_no_conformidades”. Juan Carrey Labarta – Proyecto fin de carrera Página 33 Solución La solución en objetos del mapeo es crear una clase que corresponda a la relación, en nuestro caso la hemos llamado CriterioEstado. Como la clave primaria de esta relación es una clave compuesta, hemos tenido que crear otra clase llamada CriterioEstadoPK que corresponde a la clave primaria de la relación, que posee un atributo por cada parte de la clave, como la clave de CriterioEstado está compuesta por la clave primaria de Estado y la clave primaria TipoNoConformidad, tenemos en la clase CriterioEstadoPK ambos atributos de dicho tipo. @Column private String tipo_no_conformidad; (name="tipo_no_conformidad") @Column(name="estado") private String estado; Y en la clase CriterioEstado, el atributo clave embebido (en la clase CriterioEstadoPK): @Embedded protected CriterioEstadoPK primarykey; Id Esta solución es muy farragosa y poco usable desde el punto de vista de orientación a objetos, sin embargo es una de las dos soluciones propuestas en JPA para este caso, y es la única que funcionaba en Hibernate. Carga perezosa Problema Otro de los problemas comunes en el uso de JPA como motor de persistencia, son los atributos cargados de forma perezosa (Lazy), lo cual significa que no se obtienen directamente los datos de un objeto cuando se realiza la propia consulta, sino cuando se accede a realmente a los datos. Esto ocurre con listas de objetos cuando la relación es 1:N o M:N, por ejemplo, cargar todas las respuestas de una auditoría cuando cargamos un objeto Auditoría, posiblemente no accedamos a ninguna de las respuestas ya que sólo nos interesa saber la fecha de la auditoría, por lo que cargar siempre los datos es mucho más costoso, sin embargo mantener en la cache de Hibernate, todos los objetos Lazy que deben ser cargados en caso de consulta, también es algo costoso de mantener. Solución El mantenimiento en la cache de los datos que están siendo consultados con la opción Lazy, deben estar disponibles desde la llamada al controlador (donde se consultan los datos por primera vez), hasta que se carga completamente la página dinámicamente (jsp), por lo que al inicio de la ejecución de un controlador, es posible limpiar la cache de todos estos datos (anteriores) ya que no van a volver a usarse. Juan Carrey Labarta – Proyecto fin de carrera Página 34 Paginación La paginación es una forma de visualización de datos muy extensos donde se divide la información en diversas páginas, en nuestro caso el cliente nos pidió expresamente la paginación de las preguntas por proceso, tanto en las auditorías como a la hora de gestionar las preguntas. Problema La paginación puede llegar a ser muy ineficiente. Puede resolverse de dos formas distintas, enviar todos los datos al cliente y que el cliente realice la paginación, o filtrar los datos en el servidor y enviar solo los datos referentes a la página. Solución Nosotros hemos escogido la paginación en el servidor, por ser la forma más limpia, eficiente y mantenible. Para aumentar la mantenibilidad, hemos decidido separar la paginación en una clase que ofrezca métodos de paginación, donde la forma de implementarla pueda cambiarse en un futuro de forma cómoda. Hemos creado una clase abstracta y genérica Paginator la cual extienden las diversas clases que pueden paginar un tipo de elemento en páginas de algún tipo. Paginator<TypeElem, TypePage>, para ordenar por ejemplo, en nuestro caso particular, Respuestas por Proceso y Preguntas por Proceso. En esta clase Paginator hay un método abstracto en el cual a partir de todos los elementos a paginar devuelve aquellos referentes a la página solicitada así como los nombres de las diferentes páginas seleccionables. Sugerencias Las sugerencias son ayudas que el sistema ofrece al usuario en la selección de un objeto de un listado previsiblemente grande, como por ejemplo el personal de la empresa en la selección de un Auditor, auditado o responsable. Un ejemplo de sugerencia lo encontramos en el motor de búsqueda de Google, que nos ofrece diversas sugerencias a la vez que nosotros escribimos. Problema Al crear una auditoría, se pide al usuario seleccionar tanto al grupo de auditores como auditados. Es posible que el número de personal de la empresa almacenado en la base de datos sea muy elevado, con la consecuencia directa de la incomodidad de seleccionar al personal. Solución Por ello se planteo la solución de implementar Ajax Suggestion22, lo cual permitiría una mejor usabilidad. Sub-problema Las implementaciones de “Ajax sugestión” encontradas eran poco genéricas, por lo que se realizo una generalización de una de ellas para poder usarlas en cualquier parte de la aplicación Web, así como poder aplicarla múltiples veces en una única vista, realizando diversas operaciones y manteniendo la sesión del formulario de Spring. Avisos Los avisos que el sistema debe generar, son emails que se envían en distintos periodos de tiempo y debidos a la realización de alguna tarea en la aplicación. Problema El problema principal de la gestión de avisos consiste en que una sola tarea, por ejemplo la planificación de una auditoría, genera múltiples avisos a múltiples personas y en periodos de tiempo distintos, por lo que se requiere de algún proceso que compruebe la fecha y envíe los avisos que correspondan. Solución La solución adoptada trata de la creación de un único servlet, que se ejecuta de forma única en el servidor y que contiene diversas tareas periódicas que se ejecutan una vez al día en horario fuera de oficina. Para ello hemos utilizado TimerTask23, que nos facilita la tarea de la periodicidad, asignándole dos tareas periódicas que requiere el sistema, una es la de enviar avisos pendientes y la otra el caducar las auditorías para las que se ha pasado su fecha planificada para ejecutarla. Así pues sólo necesitamos almacenar los avisos pendientes para una fecha determinada, existiendo diversos tipos de aviso (cada tipo de aviso enviará una información diferente), y un email al cual enviárselo (en caso de no existir email, se envía el aviso a toda la lista de distribución). Ésto modificó el diseño de clases y de la base de datos inicial, añadiendo una nueva entidad Aviso, que no habíamos tenido en cuenta. Cómo funciona Aviso Enviador de Email Generador Avisos Sistema Tarea periódica Gestión de Avisos usa crea lee Usuario Juan Carrey Labarta – Proyecto fin de carrera Página 35 El sistema crea los avisos a través del Generador de Avisos (siempre a través de la fachada). La tarea periódica lee los avisos pendientes, genera los mails y los envía utilizando el módulo encargado de enviar mails. Estado del proyecto y tipo de no conformidad Problema Uno de los requisitos del sistema era dotarlo de la máxima configuración posible, por ello la aplicación debe permitir configurar la forma de calcular el estado de un proyecto ó auditoría basándose en el número de respuestas negativas y su gravedad. Solución La solución que hemos adoptado ha sido el poder administrar las gravedades de las no conformidades (Tipo de no conformidad) y los nombres para los estados de un proyecto dependiendo del número de no conformidades (Estado General). De tal forma que exista una fórmula de calculo entre el número de no conformidades y un estado general. De esta forma que se define una función que describa la pertenencia a un estado dependiendo del número de no conformidades de un tipo. Siendo ambos, tanto el estado como la gravedad de las no conformidades configurables, así como todas las constantes. Se define una función por cada tipo de no conformidad de la siguiente forma: ⎪ ⎪ ⎩ ⎪ ⎪ ⎨ ⎧ ≤<⎯⎯← ≤<⎯⎯← ≤⎯⎯← = −nn Si n Si Si constxconstestado constxconstestado constxestado xf 1 212 11 ... )( Donde x es el número de no conformidades de cierta gravedad (tipo de no conformidad). Las constantes const1, const2, … , constn así como los estados estado1, estado2, … , estadon y las gravedades de las no conformidades deben ser configurables. La solución es, tener al Estado relacionado con cardinalidad M:N con TipoNoConformidad, con un atributo en la relación “maximo numero no conformidades”, que corresponde a la constante consti de la fórmula. Lo explicamos con un ejemplo, imaginemos que los estados son Bueno, Regular y Malo, y las gravedades son Leve, Grave. Malo si hay 6 o más no conformidades Graves(s) Regular si hay entre 1 y 5 no conformidad Grave(s) Juan Carrey Labarta – Proyecto fin de carrera Página 36 Bueno si hay hasta 0 no conformidad Grave(s) Malo si hay 10 o más no conformidades Leve(s) Regular si hay entre 3 y 9 no conformidades Leve(s) Bueno si hay hasta 3 no conformidad Leve(s) Estas relaciones o fórmulas corresponderían a las relaciones: Malo Inf. Grave Regular 5 Grave Bueno 0 Grave Malo Inf. Leve Regular 9 Leve Bueno 3 Leve Tabla 1 – Implementación de la fórmula de cálculo De esta forma tenemos que tanto la fórmula, como los tipos de no conformidad como los estados son configurables, dado que se establece una relación entre todos los tipos de no conformidad y todos los estados. Juan Carrey Labarta – Proyecto fin de carrera Página 37 Juan Carrey Labarta – Proyecto fin de carrera Página 38 Pruebas Introducción Se han realizado varios tipos de pruebas para los cuales hemos utilizado una herramienta en la cual se planifican las pruebas, se ejecutan y se obtienen resultados y métricas a raíz de la ejecución. La herramienta utilizada se llama Testlink9. Con esta herramienta lo que conseguimos es aislar la planificación de la ejecución, por lo que distintas personas planifican y ejecutan las pruebas de forma independiente. Plan de pruebas Hemos realizado pruebas de validación, robustez, usabilidad y aceptación, así como pruebas unitarias y de integración durante el desarrollo del producto. El proceso que seguimos en la planificación de las pruebas fue diferente dependiendo del tipo de pruebas. Unitarias Estas pruebas se utilizan para comprobar el correcto funcionamiento de un modulo del sistema, su realización se produce en el momento justo posterior a la implementación del modulo, y una vez el módulo está completamente probado y corregido, se integra en el sistema realizando las pruebas de integración. Integración Las pruebas de integración se realizan durante el desarrollo, acoplando una unidad (modulo), que se ha probado de forma unitaria y que cumple con alguno de los apartados, al sistema, de forma que no produzca efectos colaterales y el resto del sistema siga funcionando igual que hasta ahora. Validación Para las pruebas de validación se partió de los requisitos, generando uno o más casos de prueba por requisito, cubriendo toda la funcionalidad. El objetivo de estas pruebas es comprobar que la aplicación cubre toda la funcionalidad recogida en los requisitos obtenidos durante el análisis Robustez En las pruebas de robustez se intenta hacer que el sistema falle, introduciendo todo tipo de datos incorrectos o no esperados. El objetivo de estas pruebas es solucionar todos los posibles errores que pudieran aparecer a la hora de interactuar con el sistema. Juan Carrey Labarta – Proyecto fin de carrera Página 39 Usabilidad En las pruebas de usabilidad se establecen diversas metas, es decir, se le pide a un usuario inexperto que realice diversas tareas o alcance diversos puntos de la Web, guiándole lo menos posible, de forma que sea el propio usuario quien deba buscarlas. El objetivo de estas pruebas es comprobar cómo ven los usuarios cada apartado de la Web (dónde miran, dónde entran,…) al pedirle cumplir unos objetivos. Aceptación Las pruebas de aceptación consisten en poner al cliente final delante de la aplicación, para que pruebe todos los aspectos del sistema y realice un tipo de validación, dónde se comentan las funcionalidades pendientes ó aspectos que sólo el cliente conoce debido a un mal análisis. El objetivo de estas pruebas es que el cliente acepte el sistema final o solicite cierta funcionalidad extra ó pendiente de realizar. Resultado de las pruebas En el anexo de resultado de pruebas pueden observarse los resultados detallados de cada caso de prueba, habiendo realizado la empresa otros casos de prueba generales para aplicaciones destinadas a cliente final, que no se recogen en este documento dado que no estan a nuestra disposición. Unitarias y de integración Las pruebas unitarias y de integración resolvieron multitud de problemas menores de implementación, que son difícilmente recogidos en un documento de resultados. Para estas pruebas se implementaron clases de prueba con casos de prueba utilizando la tecnología JUnit24, que nos permite repetir las pruebas unitarias una y otra vez desde el entorno de desarrollo, lo cual permite realizar las pruebas unitarias sobre el sistema integrado, lo cual nos asegura (hasta cierto punto), que no se producen efectos colaterales en el resto de unidades lógicas. Esta tecnología nos permite realizar aserciones de igualdad, de veracidad, de falsedad etc., de forma que se comprueben que los resultados devueltos por los módulos son los esperados. Validación Las pruebas de validación obtuvieron unos resultados en general positivos, por lo que no sirvieron de mucho, se encontraron algunos errores menores, sin embargo se satisfacía toda la funcionalidad requerida por el sistema. Esto se debe a que la forma de desarrollar se basaba en la creación de módulos (apartados) que cumplían con alguna funcionalidad de un requisito, siguiendo ordenadamente los requisitos, es decir el desarrollo se basaba en los requisitos. Juan Carrey Labarta – Proyecto fin de carrera Página 40 Robustez Durante la ejecución de estas pruebas se encontraron multitud de errores de verificación de los datos y parámetros, así como el correcto manejo de errores. En la mayoría de los casos no se avisaba al usuario de un error (por ejemplo, introducción una fecha incorrecta, o número incorrecto, email no válido, etc.). Durante estas pruebas se localizaron también aspectos de visualización, donde algún apartado de la Web no tenía un aspecto similar al resto. Usabilidad Gracias a estas pruebas se ha visto como actúa el usuario ante el sistema desconociéndolo y sin ser informático, de esta forma se comprobó que algunas cosas no se entendían bien, resultaban incomodas o incomprensibles y otras no sabía como hacerse. Por ejemplo, en la ejecución de una auditoría, el sistema terminaba la ejecución cuando se habían completado todas las preguntas, sin embargo el usuario quería cambiar una de las respuestas para añadir observaciones y el sistema no se lo permitía. En seis de las dieciséis pruebas realizadas se encontraron problemas en la comprensión del sistema. Aceptación Lamentablemente estas pruebas no pudieron ser ejecutadas, debido a que el cliente final no disponía de tiempo material para ejecutarlas. Juan Carrey Labarta – Proyecto fin de carrera Página 41 Conclusiones La experiencia del trabajo en la empresa ha sido fructífera dado que hemos aprendido a utilizar las herramientas de forma profesional, ya que la mayoría de ellas eran desconocidas hasta el momento. Quizás al ser un proyecto no destinado a cliente final, sino que para uso interno, no resulte ser tan enriquecedor, además de realizarse de forma casi puramente individual y no en un equipo de desarrollo. A excepción del diseño Web (maquetación y estilos de la Web), y la ejecución de algunas de las pruebas (usabilidad), además del uso de diversos recursos obtenidos vía Web, todo ha sido trabajo del autor de forma individual. Problemas encontrados Los principales problemas encontrados han sido las esperas al trabajo de otras personas en el proyecto, al ser de uso interno no se le da la misma importancia que a aquellos que van destinados a cliente final. En el calendario podemos ver como afectan estas esperas a la realización del proyecto, a continuación detallamos cada uno de los problemas encontrados. Esperas al diseño Web La empresa sólo dispone de un diseñador Web, por lo que el diseño Web se nos facilitó con retraso, en el periodo posterior a las pruebas, cuando el sistema estaba completamente funcional. Hubo que paralizar la documentación para la acomodación del sistema al nuevo diseño Web, lo cual nos llevo tres días de retraso. Esperas a la implementación del servicio Web Los servicios Web que se suponían implementados, no lo estaban (al menos uno), por lo que la instalación del sistema se retrasó bastante más de lo esperado. Cambio de herramientas Tras haber realizado una formación previa en el estudio de las herramientas a utilizar (en concreto Struts), y estando a unos días de empezar con la implementación, se modificó la elección de ésta herramienta, dado que un principio se pensó en que sería la que la empresa utilizaría en un futuro, siendo la mejor opción para formarnos. Sin embargo la tecnología que se sugirió posteriormente fue Spring, que fue nuestra primera elección por ser más nueva y basada en Struts (Corrigiendo fallos de diseño), por lo que no hubo ningún impedimento para cambiar, salvo el consecuente retraso de un par de días.