Proyecto Fin de Carrera - Servidor de la Biblioteca de ...bibing.us.es/proyectos/abreproy/12257/fichero/Memoria-PFC-Jose-Maria... · En este proyecto se recoge la creación de una

Equation Chapter 1 Section 1

Proyecto Fin de Carrera Ingeniería de Telecomunicación

Aplicación para la Gestión de Reserva de Salas de la Red de Bibliotecas de la US

Autor: José María Vidal Vidal

Tutor: Mª Teresa Ariza Gómez

Dep. Ingeniería Telemática Escuela Técnica Superior de Ingeniería

Universidad de Sevilla

Sevilla, 2015

iii

Proyecto Fin de Carrera Ingeniería de Telecomunicación

Aplicación para la Gestión de Reserva de Salas de

la Red de Bibliotecas de la US

Autor:

José María Vidal Vidal

Tutor:

Mª Teresa Ariza Gómez

Profesor titular

Dep. Ingeniería Telemática

Escuela Técnica Superior de Ingeniería

Universidad de Sevilla Sevilla, 2015

v

Proyecto Fin de Carrera: Aplicación para la Gestión de Reserva de Salas de la Red de Bibliotecas de la US

Autor: José María Vidal Vidal

Tutor: Mª Teresa Ariza Gómez

El tribunal nombrado para juzgar el Proyecto arriba indicado, compuesto por los siguientes miembros:

Presidente:

Vocales:

Secretario:

Acuerdan otorgarle la calificación de:

Sevilla, 2015

El Secretario del Tribunal

vii

A mi familia y Susana

ix

Agradecimientos

En 2008 tomé la difícil decisión de dejar un trabajo fijo, buscando un futuro mejor y unas expectativas que en su momento, varias circunstancias no me dejaron llevar a cabo. Por supuesto no fue una decisión de un día para otro y estuve pensando en ello durante más de un año. Quisiera dar aquí las grácias a todos los que me apoyaron en esta difícil decisión, amigos, familia, etc.

Mis padres me criaron en un entorno humilde, pero siempre me inculcaron seguir adelante, superarme. Es a ellos a los que debo el coraje que he necesitado durante estos años. Me dieron lo que estuvo dentro de sus posibilidades, junto con mi hermana quien siempre me tendió su mano para levantarme una y otra vez.

A Susana, quien me dío apoyo, confianza y sobre todo amor durante todos estos años. Por sacarme una sonrisa en los peores momentos y hacerme sentir el hombre mas afortunado. Gracias por formar parte de mi vida.

A mi padre, que aunque no estes conmigo he sentido tu fuerza y coraje para seguir adelante y no rendirme.

Y a todos mis amigos, compañeros de estudios y de trabajo en la biblioteca de la ETSI.

José María Vidal Vidal

Sevilla, 2015

xi

Resumen

Uno de los recursos más demandados por la comunidad universitaria de los ofrecidos por la Biblioteca de la Universidad de Sevilla, es la posibilidad de reservar salas de trabajo en grupo. Exponiendo un ejemplo, en nuestra escuela, su porcentaje de ocupación durante periodos de exámenes supera el 95% y el resto del año nunca está por debajo del 50% (incluyendo periodos no lectivos).

Desde hace años, se utiliza un sistema de gestión con el cual se tramitan las reservas realizadas por los usuarios. Dicha aplicación no cumple con las necesidades propias de cada centro. En este proyecto se recoge la creación de una aplicación nueva, que se ha ido construyendo sin perder la comunicación con los usuarios que se encargarán de su gestión, para cumplir todos los requisitos demandados por ellos.

Para dicha cuestión, se ha optado por seguir la metodología de trabajo MÉTRICA Versión 3, la que ofrece a las Organizaciones un instrumento útil para la sistematización de las actividades que dan soporte al ciclo de vida del software. Este método de trabajo no es nuevo para el autor, que ya aplicó sus recomendaciones durante el desarrollo de su Proyecto Fin de Grado (Ciclo Formativo de Grado Superior en Desarrollo de Aplicaciones Informáticas).

xiii

Abstract

One of the most popular resources, made available to the university community by the Library of the University of Seville, it is the possibility of book rooms for workgroup. The current application does not meet the needs of each center. In this project will be developed a new application that has been built without losing communication with users who are responsible for their management. For this, has chosen the working methodology METRICA Version 3, which working method is not new for the author.

xv

Índice

Agradecimientos ix

Resumen xi

Abstract xiii

Índice xv

Índice de Tablas xvii

Índice de Figuras xix

1 Introducción 1 1.1 Objetivo 2 1.2 Alcance 4 1.3 Estructura de la memoria 5

2 Estado de la cuestión 7 2.1 Desarrollo web 7 2.2 Sistema de Gestión de base de Datos 10 2.3 Entorno de desarrollo 11

3 Introducción a MÉTRICA v3 13 3.1 Procesos principales de MÉTRICA v3 14 3.2 Desarrollo de Sistemas de Información 15 3.3 Interfaces de MÉTRICA v3 17

4 Estudio de Viabilidad del Sistema 21 4.1 Actividad EVS 1: Establecimiento del alcance del Sistema 21 4.2 Actividad EVS 2: Estudio de la situación actual 25 4.3 Actividad EVS 3: Definición de Requisitos del sistema 30 4.4 Actividad EVS 4: Estudio de alternativas de solución. 32 4.5 Actividad EVS 5: Valoración de la Solución. 34 4.6 Actividad EVS 6: Selección de la solución. 36

5 Análisis del Sistema de Información 37 5.1 Actividad ASI 1: Definición del Sistema 38 5.2 Actividad ASI 2: Establecimiento de Requisitos 40 5.3 Actividad ASI 3: Identificación de Subsistemas de Análisis 48 5.4 Actividad ASI 6: Elaboración del Modelo de Datos 52 5.5 Actividad ASI 7: Elaboración del Modelo de Procesos 57 5.6 Actividad ASI 8: Definición de Interfaces de Usuario 58 5.7 Actividad ASI 9: Análisis de Consistencia y especificación de requisitos 60 5.8 Actividad ASI 10: Especificación del plan de pruebas 61 5.9 Actividad ASI 11: Aprobación del Análisis del Sistema de Información 62

6 Diseño del sistema de información. 63 6.1 Actividad DSI 1: Definición de la Arquitectura del Sistema. 64 6.2 Actividad DSI 2: Diseño de la Arquitectura de Soporte 68 6.3 Actividad DSI 5: Diseño de la Arquitectura de Módulos del Sistema 68 6.4 Actividad DSI 6: Diseño Físico de Datos 76 6.5 Actividad DSI 7: Verificación y Aceptación de la Arquitectura del Sistema 77 6.6 Actividad DSI 8: Generación de Especificaciones de Construcción 78 6.7 Actividad DSI 9: Diseño de la Migración y Carga Inicial de Datos 82 6.8 Actividad DSI 10: Especificación Técnica del Plan de Pruebas 82 6.9 Actividad DSI 11: Establecimiento de Requisitos de Implantación 84 6.10 Actividad DSI 12: Aprobación del Diseño del Sistema de Información 84

7 Construcción del Sistema de Información 85 7.1 Actividad CSI 1: Preparación del Entorno de Generación construcción 86 7.2 Actividad CSI 2: Generación del Código de los Componentes y Procedimientos. 86 7.3 Actividad CSI 3: Ejecución de las Pruebas Unitarias e Integración 88 7.4 Actividad CSI 5: Ejecución de las Pruebas del Sistema 89 7.5 Actividad CSI 6: Elaboración de los Manuales de Usuario 89 7.6 Actividad CSI 7: Definición de la Formación de Usuarios Finales 90 7.7 Actividad CSI 9: Aprobación del Sistema de Información 90

8 Implantación y Aceptación del Sistema 91 8.1 Actividad IAS 1: Establecimiento del Plan de Implantación 92 8.2 Actividad IAS 2: Formación Necesaria para la Implantación 92 8.3 Actividad IAS 3: Incorporación del Sistema al Entorno de Operación 92 8.4 Actividad IAS 4: Carga de datos al Entorno de Operación 93 8.5 Actividad IAS 5: Pruebas de Implantación del Sistema 93 8.6 Actividad IAS 6: Pruebas de Aceptación del Sistema 94 8.7 Actividad IAS 10: Paso a Producción 95

9 Conclusiones y Trabajo Futuro 97 9.1 Conclusiones 97 9.2 Trabajo Futuro 98

Glosario 99

Bibliografía 101

Anexos 103 Anexo I: Arbol de directorios de la aplicación 103 Anexo II: Código Back-end funciones DDL, DML y gestión de estadísticas 107 Anexo III: Actas de Reunión. 147

xvii

ÍNDICE DE TABLAS

Tabla 4-1: Objetivos del EVS. 22

Tabla 4-2: Catálogo de requisitos generales. 23

Tabla 4-3: Catálogo de usuarios. 24

Tabla 4-4: Objetivos del EVS. 25

Tabla 4-5: Catálogo de usuarios actuales. 26

Tabla 4-6: Catálogo de requisitos funcionales. 30

Tabla 4-7: Catálogo de requisitos de diseño. 32

Tabla 4-8: Descomposición en subsistemas y usuarios participantes. 33

Tabla 4-9: Planificación. 35

Tabla 5-1: Glosario de términos. 38

Tabla 5-2: Gestión de bibliotecas - Casos de Uso. 43

Tabla 5-3: Gestión de usuarios – Casos de uso. 44

Tabla 5-4: Gestión de salas – Casos de uso. 45

Tabla 5-5: Gestión de Turnos – Casos de uso. 46

Tabla 5-6: Gestión de Reservas – Casos de uso. 47

Tabla 5-7: Modelo lógico de datos, descripción. 54

Tabla 6-1: Catálogo de excepciones. 65

Tabla 6-2: Procesos módulo - Gestión de bibliotecas y preferencias. 69

Tabla 6-3: Procesos módulo - Gestión de usuarios. 69

Tabla 6-4: Procesos módulo - Gestión de salas. 70

Tabla 6-5: Procesos módulo – Gestión de turnos. 70

Tabla 6-6: Procesos módulo de reservas. 71

Tabla 6-7: Sentencias SQL para crear la BBDD. 79

Tabla 6-8: Catálogo de pruebas unitarias y de integración. 82

Tabla 6-9: Catálogo de pruebas de sistema. 83

Tabla 6-10: Catálogo de pruebas de implantación. 83

Tabla 6-11: Catálogo de pruebas de aceptación. 84

Tabla 7-1: Contenido del archivo .htacccess. 87

Tabla 7-2: Código para lanzar el sistema SSO. 88

Tabla 7-3: Resultados de Pruebas Unitarias e integración. 88

Tabla 7-4: Resultados de Pruebas de Sistema 89

Tabla 8-1: Resultado pruebas de implantación. 93

Tabla 8-2: Resultados pruebas de aceptación. 94

xix

ÍNDICE DE FIGURAS

Figura 1-1: Esquema general de la aplicación. 2

Figura 1-2: Distintas pantallas según el rol del usuario. 2

Figura 1-3: Arquitectura del sistema de información y tecnologías usadas. 3

Figura 2-1. Ejemplo SSO. 10

Figura 4-1: Esquema Estudio de Viabilidad del Sistema. 21

Figura 4-2: Esquema situación actual. 26

Figura 4-3: Modelo Entidad /Relación. 27

Figura 4-4: Captura de la aplicación para la Biblioteca de Ingeniería. 28

Figura 4-5: Captura de la Gestión en la Biblioteca de Comunicación. 28

Figura 4-6: Solicitud de reserva, estado actual. 29

Figura 4-7: Tareas e hitos del diagrama de Gantt del proyecto. 35

Figura 4-8: Desarrollo del diagrama de Gantt. 36

Figura 5-1: Esquema del Análisis del Sistema de Información. 37

Figura 5-2: Diagrama Entidad/Relación. 38

Figura 5-3: MCU - Gestión de bibliotecas y preferencias. 40

Figura 5-4: MCU - Gestión de Usuarios. 41

Figura 5-5: MCU - Gestión de Salas. 41

Figura 5-6: MCU - Gestión de Turnos. 42

Figura 5-7: MCU - Gestión de Reservas. 42

Figura 5-8: Subsistemas detectados. 48

Figura 5-9: Flujo de datos – Identificar usuario. 49

Figura 5-10: Flujo de datos - Alta/Baja de usuario. 49

Figura 5-11: Flujo de datos – Crear Grupo de Turnos y Turnos. 50

Figura 5-12: Flujo de datos- Crear Tipo de sala y crear sala 51

Figura 5-13: Flujo de datos - Reservar sala y cancelar reserva. 51

Figura 5-14: Modelo Conceptual de Datos. 52

Figura 5-15: Modelo Lógico de Datos. 53

Figura 5-16: Proceso de consulta de datos. 57

Figura 5-17: Proceso de inserción de datos en la BBDD. 58

Figura 5-18: Proceso de eliminación de datos en la BBDD. 58

Figura 6-1: Esquema del Diseño del Sistema de Información. 63

Figura 6-2: Diagrama de despliegue del Sistema de Información. 64

Figura 6-3: Capas de la aplicación. 64

Figura 6-4: Pantalla y formulario de identificación del sistema SSO. 67

Figura 6-5: Diagrama de Estructura del Sistema. 68

Figura 6-6; Diagrama de estructuras con interfaces entre módulos. 71

Figura 6-7: Interfaz - Pantalla principal de Superadministrador. 72

Figura 6-8: Interfaz - Escritorio principal del Administrador/Revisor. 73

Figura 6-9: Interfaz - Creación de salas. 73

Figura 6-10: Interfaz - Definir turnos de un grupo. 74

Figura 6-11: Interfaz - Estadísticas de reservas. 74

Figura 6-12: Interfaz – Listado de reservas. 75

Figura 6-13: Interfaz – Escritorio del peticionario. 75

Figura 6-14: Modelo Físico de Datos final. 76

Figura 7-1: Esquema de la Construcción del Sistema de Información. 85

Figura 7-2: Entorno de desarrollo. 86

Figura 7-3: Diagrama de flujo – Carga de página. 87

Figura 8-1: Esquema de la Implantación y Aceptación del Sistema. 91

Figura 8-2: Pantalla de estadísticas obtenidas durante el periodo de pruebas. 95

1

1 INTRODUCCIÓN

a reserva de salas de trabajo en grupo y otros espacios, en cualquiera de las bibliotecas que comprenden la red de la Biblioteca de la Universidad de Sevilla, es uno de los servicios más utilizados por los alumnos y otros miembros de la comunidad universitaria. Como apunte, la ocupación de éstas sobrepasa el 70%

de media durante todo el año. Llegando a más del 90% durante periodo de exámenes.

Algunos números que caracterizan este servicio:

• 81 Salas de trabajo en grupo en 11 centros.

• Un total de 491 plazas.

• Capacidad de entre 2 y 16 personas por sala.

Siendo un servicio tan demandado, hace unos años se decidió diseñar un sistema online que permitiese a los alumnos realizar reservas. Dicha aplicación, usada hasta ahora, era de un funcionamiento orientado solamente a los usuarios que realizaban las reservas y obviaba a los responsables de cada biblioteca. Es decir, ésta no contaba con una administración que permitiese a cada biblioteca modificar el servicio ofrecido según sus criterios (añadir más salas o modificar sus datos, modificar horarios, etc.).

Por ello se planteó llevar a cabo su desarrollo en la Biblioteca de Ingeniería, debido a las posibilidades de la misma, al contar con una infraestructura y personal que lo posibilitan. Estando la Sección de Informática de los SSCC (Sevicios Centrales) ocupada en otros proyectos que no han permitido su realización.

Esto se debe a un convenio con AICIA (Asociación de Investigación y Cooperación Industrial de Andalucía), gracias al cual, la biblioteca de la ETSI, dispone de alumnos colaboradores que ayudan y diseñan aplicaciones para mejorar el servicio que se ofrece a sus usuarios además de otras tareas. Siendo este el primer proyecto de un impacto general sobre las funcionalidades de otros centros y que contaba con la suficiente magnitud para seguir una metodología más profesional.

L

-

Introducción

2

1.1 Objetivo

Durante este proyecto, se busca crear una aplicación para suplir las carencias de la actual. Añadiendo las funcionalidades solicitadas por las bibliotecas que conforman la red de la BUS y mejorando las ya existentes. Se persigue el diseño de un sistema al estilo web 2.0, donde el usuario (en este caso refiriéndonos al personal de las bibliotecas) modifique la oferta de espacios y turnos de reservas sin la intervención de personal de la Sección de Informática. Dicha sección solamente se preocupará de la gestión de bibliotecas (habilitar su acceso a la aplicación creando sus cuentas) así como el mantenimiento de la base de datos. Por supuesto no hay que olvidar a los usuarios que realizan las reservas, servicio que deberá seguir funcionando como hasta ahora, de una forma sencilla y rápida. Se muestran las gestiones y usuarios que las ejecutarán en la Figura1-1.

Figura 1-1: Esquema general de la aplicación.

Para ello es necesario un sistema que permita múltiples configuraciones y una amplia personalización de los servicios ofrecidos. Esto requiere un control muy preciso sobre la estabilidad del sistema (manejando la oferta de espacios y sus distintos tipos, varios turnos de reserva, sanciones, horarios, etc.) al gestionar los datos para evitar posibles incoherencias. Además debe ser capaz de identificar el rol del usuario registrado, presentando la aplicación de forma correcta a cada uno y con el acceso restringido a algunas funciones (Figura 1-2). También se muestra a continuación en la Figura 1-3, la arquitectura del sistema y tecnologías usadas en su desarrollo.

Figura 1-2: Distintas pantallas según el rol del usuario.

Aplicación

Común a todas las bibliotecas

Reserva de Espacios

Alumnos, Profesores, etc.

Gestión del servicio

Personal de la biblioteca

Reservas


Turnos de Reserva

Personal de la Biblioteca

Salas


Gestión de Bibliotecas

Sección de Informática

3

3 Aplicación para la Gestión de Reserva de Salas de la Red de Bibliotecas de la US

Figura 1-3: Arquitectura del sistema de información y tecnologías usadas.

Sistema de identificación.

Proporcionado por la Universidad de Sevilla

Cliente

Servidor

Servidor SSO

Servidor de la aplicación.

Contiene el código del sistema y la base de datos.

Superadminstrador Adminsitrador Revisor Peticionario

Navegadores Web

Diseño Web

Programación Base de datos

Protocolo de identificación

Introducción

4

1.2 Alcance

La vida del proyecto puede dividirse en las 3 etapas que se detallan a continuación:

• Desarrollo.

Durante la primera etapa se desarrollará el código de la aplicación mientras se está en contacto con los usuarios finales de la misma. Se llevarán a cabo reuniones con relativa frecuencia, tanto para el seguimiento del trabajo realizado como para extraer las funcionalidades requeridas en la aplicación.

Entre las gestiones a desarrollar se incluyen las ya citadas:

o Gestión de bibliotecas.

o Gestión de salas.

o Gestión de turnos de reserva.

o Gestión de usuarios.

o Gestión de reservas

• Implantación y Ensayo en Biblioteca de la ETSI.

Una vez se tenga una versión estable de la aplicación, se instalará en la Biblioteca de Ingeniería de la Universidad de Sevilla, que ejercerá de prueba piloto. Durante esta fase se corregirán los errores que surjan y serán añadidas las posibles mejoras que se crean oportunas. También se redactarán los manuales de usuario.

Tareas a realizar durante esta fase:

o Implantación

o Pruebas

o Correcciones

o Modificaciones: Nuevas funcionalidades

o Redacción de manuales de usuario

• Implantación final.

Una vez se compruebe que el sistema ha superado la etapa anterior. Se hará entrega del código de la aplicación y manuales de usuario a SSCC y a partir de ese momento la responsabilidad de la aplicación pasará a ellos. Encargándose de la implantación en sus servidores y formar al personal bibliotecario del resto de centros en el uso de ésta.

Por tanto, el alcance de este proyecto concierne solamente a las 2 primeras etapas, donde se diseñará y construirá la aplicación para luego desarrollar las pruebas en la Biblioteca de Ingeniería, hasta considerar que se cumplen los objetivos planteados al inicio.

Durante la posterior implantación por parte de SSCC, se podrán ejecutar labores de apoyo y asesoramiento para solucionar posibles incidencias y dudas.

5


1.3 Estructura de la memoria

Lo primero que se detallará en la memoria será el estado de la cuestión, donde se describen las tecnologías que se han utilizado en el desarrollo de la aplicación, dividiéndola en 3 categorías:

• Desarrollo web.

• Sistema de gestión de base de datos

• Entorno de desarrollo.

A la hora de desarrollar el proyecto, se ha decidido seguir como metodología de trabajo MÉTRICA V3 que ofrece a las Organizaciones un instrumento útil para la sistematización de las actividades que dan soporte al ciclo de vida del software. Este método de trabajo no es ajeno al autor, puesto que aplicó sus recomendaciones durante el desarrollo de su Proyecto Fin de Grado.

Aunque la estructura principal de MÉTRICA V3 se compone de 3 procesos (Planificación del Sistema de Información, Desarrollo del Sistema de Información y Mantenimiento del Sistema de Información.) en este proyecto sólo comprende el segundo, Desarrollo del Sistema de Información, que a su vez esta subdividido en 5 procesos:

• Estudio de Viabilidad del Sistema (EVS).

• Análisis del Sistema de Información (ASI).

• Diseño del Sistema de Información (DSI).

• Construcción del Sistema de Información (CSI).

• Implantación y Aceptación del Sistema (IAS).

En los anexos se incluirá la siguiente información generada durante el desarrollo:

• Árbol de directorios de la aplicación.

• Código.

• Actas de reuniones.

También se hará entrega de otros documentos:

• Manuales de usuarios.

• Guía de Inicio (Donde se detalla la primera configuración de la aplicación).

• Manual de desarrollador (con algunas pautas y descripciones a la hora de implantar el sistema).

Introducción

6

7

2 ESTADO DE LA CUESTIÓN

n la actualidad existen muchísimas posibilidades a la hora de desarrollar un sistema web como el que se plantea en este proyecto. Pero, debido a limitaciones de hardware y software, éstas han sido reducidas y se optará por seguir los mismos esquemas ya utilizados en todos los proyectos realizados en la Biblioteca

de Ingeniería, por otros alumnos colaboradores. Además, el autor del proyecto, cuenta con experiencia en estos campos, obtenida durante sus años trabajando como desarrollador web.

Se describen a continuación estas tecnologías disponibles:

Se cuenta con un servidor con la distribución Debian de Linux, que ya funciona como servidor de aplicaciones webs desarrolladas en PHP, además el autor de este proyecto tiene una amplia experiencia en este lenguaje obtenida durante sus años en la empresa privada.

2.1 Desarrollo web

PHP 5.5

Como se comentó anteriormente, es el lenguaje fundamental elegido para la programación de la aplicación. Se podría haber optado por la plataforma .NET de Microsoft o mediante CGI con Perl, pero fueron rechazadas en favor de PHP debido a que es el lenguaje usado en las demás aplicaciones que ya ofrece la Biblioteca de Ingeniería.

PHP es un lenguaje de programación de uso general, de código del lado del servidor, originalmente diseñado para el desarrollo web de contenido dinámico. Fue uno de los primeros lenguajes de programación del lado del servidor que se podían incorporar directamente en el documento HTML en lugar de llamar a un archivo externo que procese los datos. El código es interpretado por un servidor web con un módulo de procesador de PHP que genera la página Web resultante. PHP ha evolucionado por lo que ahora incluye también una interfaz de línea de comandos que puede ser usada en aplicaciones gráficas independientes. Puede ser usado en la mayoría de los servidores web al igual que en casi todos los sistemas operativos y plataformas sin ningún costo.

Se considera uno de los lenguajes más flexibles, potentes y de alto rendimiento conocidos hasta el día de hoy. Lo que ha atraído el interés de múltiples sitios con gran demanda de tráfico como Facebook, para optar por PHP como tecnología de servidor.

E

Estado de la cuestión

8

El 13 de julio de 2004, fue lanzado PHP 5, utilizando el motor Zend Engine 2.0 (o Zend Engine 2.2) Incluye todas las ventajas que provee el nuevo Zend Engine como:

• Mejor soporte para la programación orientada a objetos, que en versiones anteriores era extremadamente rudimentario.

• Mejoras de rendimiento.

• Mejor soporte para MySQL con extensión completamente reescrita.

• Mejor soporte a XML (XPath, DOM, etc.).

• Soporte integrado para SOAP.

• Iteradores de datos.

• Manejo de excepciones.

HTML

El diseño de la aplicación está implementado en HTML, siglas de HyperText Markup Language (Lenguaje de Marcas de Hipertexto). El código de las páginas está escrito en este lenguaje, que indica básicamente donde colocar cada texto, cada imagen o cada vídeo y la forma que tendrán estos al ser colocados en la página.

Es un lenguaje muy sencillo que permite describir hipertexto, es decir, texto presentado de forma estructurada y agradable, con enlaces (hyperlinks) que conducen a otros documentos o fuentes de información relacionadas, y con inserciones multimedia (gráficos, sonido...).

CSS

Hoja de estilo en cascada o CSS (siglas en inglés de cascading style sheets) es un lenguaje usado para definir la presentación de un documento estructurado escrito en HTML o XML2 (y por extensión en XHTML). El World Wide Web Consortium (W3C) es el encargado de formular la especificación de las hojas de estilo que servirán de estándar para los agentes de usuario o navegadores.

La idea que se encuentra detrás del desarrollo de CSS es separar la estructura de un documento de su presentación.

Algunas ventajas de utilizar CSS son:

• Control centralizado de la presentación de un sitio web completo con lo que se agiliza de forma considerable la actualización del mismo.

• Separación del contenido de la presentación, lo que facilita al creador, diseñador, usuario o dispositivo electrónico que muestre la página, la modificación de la visualización del documento sin alterar el contenido del mismo, sólo modificando algunos parámetros del CSS.

• Optimización del ancho de banda de la conexión, pues pueden definirse los mismos estilos para muchos elementos con un solo selector; o porque un mismo archivo CSS puede servir para una multitud de documentos.

• Mejora en la accesibilidad del documento, pues con el uso del CSS se evitan antiguas prácticas necesarias para el control del diseño (como las tablas), y que iban en perjuicio de ciertos usos de los documentos, por parte de navegadores orientados a personas con algunas limitaciones sensoriales.


JavaScript

Se trata de un lenguaje de programación del lado del cliente, porque es el navegador el que soporta la carga de procesamiento. Gracias a su compatibilidad con la mayoría de los navegadores modernos, es el lenguaje de programación del lado del cliente más utilizado.

Con Javascript se pueden crear efectos en las páginas y definir interactividades con el usuario. El navegador del cliente es el encargado de interpretar las instrucciones Javascript y ejecutarlas para realizar estos efectos e interactividades, de modo que el mayor recurso, y tal vez el único, con que cuenta este lenguaje es el propio navegador.

Al igual que Java, JavaScript es un lenguaje orientado a objetos propiamente dicho, ya que dispone de herencia, si bien esta se realiza siguiendo el paradigma de programación basada en prototipos, ya que las nuevas clases se generan clonando las clases base prototipos) y extendiendo su funcionalidad.

Todos los navegadores modernos interpretan el código JavaScript integrado dentro de las páginas web. Para interactuar con una página web se provee al lenguaje JavaScript de una implementación del DOM.

Twitter Bootstrap

Twitter Bootstrap es un framework o conjunto de herramientas de software libre para diseño de sitios y aplicaciones web. Contiene plantillas de diseño con tipografía, formularios, botones, cuadros, menús de navegación y otros elementos de diseño basado en HTML y CSS, así como, extensiones de JavaScript opcionales adicionales. Es el proyecto más popular en GitHub y es usado por la NASA y la MSNBC junto a más organizaciones

Bootstrap tiene un soporte para HTML5 y CSS3, pero es compatible con la mayoría de los navegadores web. La información básica de compatibilidad de sitios web o aplicaciones está disponible para todos los dispositivos y navegadores. Existe un concepto de compatibilidad parcial que hace disponible la información básica de un sitio web para todos los dispositivos y navegadores. Por ejemplo, las propiedades introducidas en CSS3 para las esquinas redondeadas, gradientes y sombras son usadas por Bootstrap a pesar de la falta de soporte de navegadores antiguos. Esto extiende la funcionalidad de la herramienta, pero no es requerida para su uso.

Desde la versión 2.0 también soporta diseños sensibles. Esto significa que el diseño gráfico de la página se ajusta dinámicamente, tomando en cuenta las características del dispositivo usado (Computadoras, tabletas, teléfonos móviles).

Bootstrap es de código abierto y está disponible en GitHub. Los desarrolladores están motivados a participar en el proyecto y a hacer sus propias contribuciones a la plataforma.

Por supuesto no se usará en su versión original, sino que su código será adaptado a la imagen corporativa de la Biblioteca de la Universidad de Sevilla.

Single Sign-On (SSO)

Single sign-on (SSO) es un procedimiento de autenticación que habilita al usuario para acceder a varios sistemas con una sola instancia de identificación. Su traducción literal sería algo como "sistema centralizado de autenticación y autorización".

En el caso de este proyecto, se usará una versión que el SIC (Servicio de Informática y Comunicaciones) de la US ha habilitado para el uso en aplicaciones desarrolladas en el ámbito de la universidad.

El sistema Single Sign-On (SSO) tiene una doble utilidad:

Para los usuarios supone la comodidad de identificarse una sola vez y mantener la sesión válida para el resto de aplicaciones que hacen uso del SSO. Además le permite identificarse usando los siguientes métodos de autenticación:


10

• Usando su UVUS y contraseña

• Usando su certificado de la Fábrica Nacional de Moneda y Timbre (FNMT)

• Usando su DNI-e (DNI electrónico)

Para los desarrolladores y administradores de aplicaciones es una manera de simplificar enormemente la lógica de sus aplicaciones, al poder delegar completamente la tarea de autenticar a los usuarios a un sistema independiente de las mismas.

Integrando su aplicación en el SSO no tendrá que preocuparse de conocer el protocolo LDAP, de configurar su servidor web para aceptar los certificados de la FNMT o de añadir soporte para DNI-e a su aplicación.

El sistema Single Sign-On de la Universidad de Sevilla soporta los siguientes protocolos:

• SAML 2.0

• CAS 1.0 y 2.0

• PAPI

• OpenSSO

Cada uno tiene sus particularidades, pero la descripción general de funcionamiento, como se muestra en la Figura 2-1, es la que consta a continuación:

Los usuarios reciben tokens, identificadores opacos que quedan asociados internamente a la identidad del usuario que hace uso del sistema.

Figura 2-1. Ejemplo SSO.

Cuando un usuario se identifica usando el sistema, su navegador hace llegar a las aplicaciones su identificador opaco o, en algunos protocolos, su identidad completa cifrada y firmada.

Es por tanto tarea de las aplicaciones comprobar la presencia y validez de los tokens y atributos de identidad, consultando al sistema Single Sign-On si fuera necesario.

2.2 Sistema de Gestión de base de Datos

MySQL

MySQL es un sistema de gestión de base de datos relacional, multihilo y multiusuario con más de seis millones de instalaciones. MySQL AB (desde enero de 2008 una subsidiaria de Sun Microsystems y ésta a su vez de Oracle Corporation desde abril de 2009).

Hasta la versión 5.5.30 contaba con licencia GNU GPLv2, las posteriores se rigen por una más restrictiva. En nuestro caso, los servidores donde funcionará la aplicación cuentan con la versión 5.3, que da soporte a otras aplicaciones.


Al contrario que proyectos como Apache, donde el software es desarrollado por una comunidad pública y el copyright del código está en poder del autor individual, MySQL es propiedad y está patrocinado por una empresa privada, que posee el copyright de la mayor parte del código.

Además de las funciones comunes de un SGBD, cuenta con unas características propias:

• Permite escoger entre múltiples motores de almacenamiento para cada tabla. En MySQL 5.0 éstos debían añadirse en tiempo de compilación, a partir de MySQL 5.1 se pueden añadir dinámicamente en tiempo de ejecución.

• Agrupación de transacciones, reuniendo múltiples transacciones de varias conexiones para incrementar el número de transacciones por segundo.

2.3 Entorno de desarrollo

Durante el desarrollo de la aplicación se va a hacer uso de dos programas que facilitarán el progreso del proyecto, en concreto se contará con un entorno de desarrollo como es NetBeans y un entorno web para la gestión de la base de datos.

NetBeans

NetBeans es un entorno de desarrollo integrado libre, hecho principalmente para el lenguaje de programación Java. Existe además un número importante de módulos para extenderlo. NetBeans IDE es un producto libre y gratuito sin restricciones de uso.

En cuanto a la programación Web con PHP 5 ofrece un potente debugger integrado y además viene con soporte para Symfony un gran framework MVC escrito en PHP. Al tener también soporte para AJAX, cada vez más desarrolladores de aplicaciones LAMP o WAMP, están utilizando NetBeans como IDE.

PhpMyAdmin

Utilizado para gestión y mantenimiento de la base de datos. PhpMyAdmin es una herramienta escrita en PHP con la intención de manejar la administración de MySQL a través de páginas webs, utilizando Internet.

Actualmente puede crear y eliminar bases de datos, crear, eliminar y alterar tablas, borrar, editar y añadir campos, ejecutar cualquier sentencia SQL, administrar claves en campos, administrar privilegios, exportar datos en varios formatos y está disponible en 50 idiomas. Se encuentra disponible bajo la licencia GPL.

Durante este proyecto se usará como depurador durante el diseño de la base de datos, mientras esta se encuentra en desarrollo, además de ofrecer las labores de mantenimiento necesarias durante esta etapa.


12

13

3 INTRODUCCIÓN A MÉTRICA V3

ÉTRICA es una metodología de planificación, desarrollo y mantenimiento de sistemas de información, promovida por el Ministerio de Hacienda y Administraciones Públicas [1] (antiguo Ministerio de Administraciones Públicas) del Gobierno de España para la sistematización de actividades del ciclo de

vida de los proyectos software en el ámbito de las administraciones públicas. Esta metodología propia está basada en el modelo de procesos del ciclo de vida de desarrollo ISO/IEC 12207 (Information Technology - Software Life Cycle Processes) así como en la norma ISO/IEC 15504 SPICE (Software Process Improvement And Assurance Standards Capability Determination).

La metodología MÉTRICA Versión 3 ofrece a las Organizaciones un instrumento útil para la sistematización de las actividades que dan soporte al ciclo de vida del software dentro del marco que permite alcanzar los siguientes objetivos:

• Proporcionar o definir Sistemas de Información que ayuden a conseguir los fines de la Organización mediante la definición de un marco estratégico para el desarrollo de los mismos.

• Dotar a la Organización de productos software que satisfagan las necesidades de los usuarios dando una mayor importancia al análisis de requisitos.

• Mejorar la productividad de los departamentos de Sistemas y Tecnologías de la Información y las Comunicaciones, permitiendo una mayor capacidad de adaptación a los cambios y teniendo en cuenta la reutilización en la medida de lo posible.

• Facilitar la comunicación y entendimiento entre los distintos participantes en la producción de software a lo largo del ciclo de vida del proyecto, teniendo en cuenta su papel y responsabilidad, así como las necesidades de todos y cada uno de ellos.

• Facilitar la operación, mantenimiento y uso de los productos software obtenidos.

M

-

Introducción a MÉTRICA v3

14

En la elaboración de MÉTRICA Versión 3 se han tenido en cuenta los métodos de desarrollo más extendidos, así como los últimos estándares de ingeniería del software y calidad, además de referencias específicas en cuanto a seguridad y gestión de proyectos.

También se ha tenido en cuenta la experiencia de los usuarios de las versiones anteriores para solventar los problemas o deficiencias detectados.

En una única estructura la metodología MÉTRICA Versión 3 cubre distintos tipos de desarrollo: estructurado y orientado a objetos, facilitando a través de interfaces la realización de los procesos de apoyo u organizativos: Gestión de Proyectos, Gestión de Configuración, Aseguramiento de Calidad y Seguridad.

La automatización de las actividades propuestas en la estructura de MÉTRICA Versión 3 es posible ya que sus técnicas están soportadas por una amplia variedad de herramientas de ayuda al desarrollo disponibles en el mercado.

3.1 Procesos principales de MÉTRICA v3

MÉTRICA Versión 3 tiene un enfoque orientado al proceso, ya que la tendencia general en los estándares se encamina en este sentido y por ello, como ya se ha dicho, se ha enmarcado dentro de la norma ISO 12.207, que se centra en la clasificación y definición de los procesos del ciclo de vida del software. Como punto de partida y atendiendo a dicha norma.

MÉTRICA Versión 3 cubre el Proceso de Desarrollo y el Proceso de Mantenimiento de Sistemas de Información. MÉTRICA Versión 3 ha sido concebida para abarcar el desarrollo completo de Sistemas de Información sea cual sea su complejidad y magnitud, por lo cual su estructura responde a desarrollos máximos y deberá adaptarse y dimensionarse en cada momento de acuerdo a las características particulares de cada proyecto.

La metodología descompone cada uno de los procesos en actividades, y éstas a su vez en tareas. Para cada tarea se describe su contenido haciendo referencia a sus principales acciones, productos, técnicas, prácticas y participantes. El orden asignado a las actividades no debe interpretarse como secuencia en su realización, ya que éstas pueden realizar en orden diferente a su numeración o bien en paralelo, como se muestra en los gráficos de cada proceso. Sin embargo, no se dará por acabado un proceso hasta no haber finalizado todas las actividades del mismo determinadas al inicio del proyecto.

Así los procesos de la estructura principal de MÉTRICA Versión 3 son los siguientes:

• PLANIFICACIÓN DE SISTEMAS DE INFORMACIÓN.

• DESARROLLO DE SISTEMAS DE INFORMACIÓN.

• MANTENIMIENTO DE SISTEMAS DE INFORMACIÓN.

El enfoque del Proceso de Planificación de Sistemas de Información, al no estar dentro del ámbito de la norma ISO 12.207 de Procesos del Ciclo de Vida de Software, se ha determinado a partir del estudio de los últimos avances en este campo, la alta competitividad y el cambio a que están sometidas las organizaciones. El entorno de alta competitividad y cambio en el que actualmente se encuentran las organizaciones, hace cada vez más crítico el requerimiento de disponer de los sistemas y las tecnologías de la información con flexibilidad para adaptarse a las nuevas exigencias, con la velocidad que demanda dicho entorno.

La existencia de tecnología de reciente aparición, permite disponer de sistemas que apoyan la toma de decisiones a partir de grandes volúmenes de información procedentes de los sistemas de gestión e integrados en una plataforma corporativa. MÉTRICA Versión 3 ayuda en la planificación de sistemas de información facilitando una visión general necesaria para posibilitar dicha integración y un modelo de información global de la organización.


En cuanto al Proceso de Desarrollo de Sistemas de Información, para facilitar la comprensión y dada su amplitud y complejidad se ha subdividido en cinco procesos:

• ESTUDIO DE VIABILIDAD DEL SISTEMA (EVS).

• ANÁLISIS DEL SISTEMA DE INFORMACIÓN (ASI).

• DISEÑO DEL SISTEMA DE INFORMACIÓN (DSI).

• CONSTRUCCIÓN DEL SISTEMA DE INFORMACIÓN (CSI).

• IMPLANTACIÓN Y ACEPTACIÓN DEL SISTEMA (IAS).

La necesidad de acortar el ciclo de desarrollo de los sistemas de información ha orientado a muchas organizaciones a la elección de productos software del mercado cuya adaptación a sus requerimientos suponía un esfuerzo bastante inferior al de un desarrollo a medida, por no hablar de los costes de mantenimiento. Esta decisión, que es estratégica en muchas ocasiones para una organización, debe tomarse con las debidas precauciones, y es una realidad que está cambiando el escenario del desarrollo del software. Otra consecuencia de lo anterior es la práctica, cada vez más habitual en las organizaciones, de la contratación de servicios externos en relación con los sistemas y tecnologías de la información y las comunicaciones, llevando a la necesidad de una buena gestión y control de dichos servicios externos y del riesgo implícito en todo ello, para que sus resultados supongan un beneficio para la organización. MÉTRICA Versión 3 facilita la toma de decisión y la realización de todas las tareas que comprende el desarrollo de un sistema de información.

Desde el enfoque de la norma ISO 12.207, el Proceso de Mantenimiento de Sistemas de Información comprende actividades y tareas de modificación o retirada de todos los componentes de un sistema de información (hardware, software, software de base, operaciones manuales, redes, etc.). Este marco de actuación no es el objetivo de MÉTRICA Versión 3, ya que esta metodología está dirigida principalmente al proceso de desarrollo del software. Por lo tanto, MÉTRICA Versión 3 refleja los aspectos del Mantenimiento, correctivo y evolutivo, que tienen relación con el Proceso de Desarrollo.

Durante este proyecto solamente se llevará a cabo el segundo proceso de MÉTRICA v3, del cual se expondrán sus características en los siguientes apartados.

3.2 Desarrollo de Sistemas de Información

El proceso de Desarrollo de MÉTRICA Versión 3 contiene todas las actividades y tareas que se deben llevar a cabo para desarrollar un sistema, cubriendo desde el análisis de requisitos hasta la instalación del software. Además de las tareas relativas al análisis, incluye dos partes en el diseño de sistemas: arquitectónico y detallado. También cubre las pruebas unitarias y de integración del sistema, aunque siguiendo la norma ISO 12.207 no propone ninguna técnica específica y destaca la importancia de la evolución de los requisitos. Este proceso es, sin duda, el más importante de los identificados en el ciclo de vida de un sistema y se relaciona con todos los demás.

Estudio de Viabilidad del Sistema (EVS)

El propósito de este proceso es analizar un conjunto concreto de necesidades, con la idea de proponer una solución a corto plazo. Los criterios con los que se hace esta propuesta no serán estratégicos sino tácticos y relacionados con aspectos económicos, técnicos, legales y operativos.

Los resultados del Estudio de Viabilidad del Sistema constituirán la base para tomar la decisión de seguir adelante o abandonar. Si se decide seguir adelante pueden surgir uno o varios proyectos que afecten a uno o varios sistemas de información. Dichos sistemas se desarrollarán según el resultado obtenido en el estudio de viabilidad y teniendo en cuenta la cartera de proyectos para la estrategia de implantación del sistema global.


16

Análisis del Sistema de Información (ASI)

El propósito de este proceso es conseguir la especificación detallada del sistema de información, a través de un catálogo de requisitos y una serie de modelos que cubran las necesidades de información de los usuarios para los que se desarrollará el sistema de información y que serán la entrada para el proceso de Diseño del Sistema de Información.

En primer lugar se describe inicialmente el sistema de información, a partir de los productos generados en el proceso Estudio de Viabilidad del Sistema (EVS). Se delimita su alcance, se genera un catálogo de requisitos generales y se describe el sistema mediante unos modelos iniciales de alto nivel.

Se recogen de forma detallada los requisitos funcionales que el sistema de información debe cubrir, catalogándolos, lo que permite hacer la traza a lo largo de los procesos de desarrollo. Además, se identifican los requisitos no funcionales del sistema, es decir, las facilidades que ha de proporcionar el sistema, y las restricciones a que estará sometido, en cuanto a rendimiento, frecuencia de tratamiento, seguridad, etc.

Para facilitar el análisis del sistema se identifican los subsistemas de análisis, y se elaboran los modelos de Casos de Uso y de Clases, en desarrollos orientados a objetos, y de Datos y Procesos en desarrollos estructurados. Se ha incorporado una actividad específica para la definición de Interfaces de Usuario al tiempo que se van obteniendo y depurando los requisitos y los anteriores modelos. Se especificarán todas las interfaces entre el sistema y el usuario, como formatos de pantallas, diálogos, formatos de informes y formularios de entrada.

Diseño del Sistema de Información (DSI)

El propósito del Diseño del Sistema de Información (DSI) es obtener la definición de la arquitectura del sistema y del entorno tecnológico que le va a dar soporte, junto con la especificación detallada de los componentes del sistema de información. A partir de dicha información, se generan todas las especificaciones de construcción relativas al propio sistema, así como la especificación técnica del plan de pruebas, la definición de los requisitos de implantación y el diseño de los procedimientos de migración y carga inicial, éstos últimos cuando proceda. El diseño de la arquitectura del sistema dependerá en gran medida de las características de la instalación, de modo que se ha de tener en cuenta una participación activa de los responsables de Sistemas y Explotación de las Organizaciones para las que se desarrolla el sistema de información.

Este proceso consta de un primer bloque de actividades, que se realizan en paralelo, y cuyo objetivo es obtener el diseño de detalle del sistema de información que comprende la partición física del sistema de información, independiente de un entorno tecnológico concreto, la organización en subsistemas de diseño, la especificación del entorno tecnológico sobre el que se despliegan dichos subsistemas y la definición de los requisitos de operación, administración del sistema, seguridad y control de acceso. En el caso de diseño orientado a objetos, conviene señalar que se ha contemplado que el diseño de la persistencia se lleva a cabo sobre bases de datos relacionales.

Construcción del Sistema de Información (CSI)

La construcción del Sistema de Información (CSI) tiene como objetivo final la construcción y prueba de los distintos componentes del sistema de información, a partir del conjunto de especificaciones lógicas y físicas del mismo, obtenido en el Proceso de Diseño del Sistema de Información (DSI). Se desarrollan los procedimientos de operación y seguridad y se elaboran los manuales de usuario final y de explotación, estos últimos cuando proceda.

Para conseguir dicho objetivo, se recoge la información relativa al producto del diseño de especificaciones de construcción del sistema de información. Se prepara el entorno de construcción, se genera el código de cada uno de los componentes del sistema de información y se van realizando, a medida que se vaya finalizando la construcción, las pruebas unitarias de cada uno de ellos y las de integración entre subsistemas.


Implantación y Aceptación del Sistema (IAS)

Este proceso tiene como objetivo principal, la entrega y aceptación del sistema en su totalidad, que puede comprender varios sistemas de información desarrollados de manera independiente, según se haya establecido en el proceso de Estudio de Viabilidad del Sistema (EVS), y un segundo objetivo que es llevar a cabo las actividades oportunas para el paso a producción del sistema.

En este proceso se elabora el plan de mantenimiento del sistema de forma que el responsable del mantenimiento conozca el sistema antes de que éste pase a producción. También se establece el acuerdo de nivel de servicio requerido una vez que se inicie la producción. El acuerdo de nivel de servicio hace referencia a servicios de gestión de operaciones, de soporte a usuarios y al nivel con el que se prestarán dichos servicios.

3.3 Interfaces de MÉTRICA v3

La estructura de MÉTRICA Versión 3 incluye también un conjunto de interfaces que definen una serie de actividades de tipo organizativo o de soporte al proceso de desarrollo y a los productos, que en el caso de existir en la organización se deberán aplicar para enriquecer o influir en la ejecución de las actividades de los procesos principales de la metodología y que si no existen habrá que realizar para complementar y garantizar el éxito del proyecto desarrollado con MÉTRICA Versión 3.

La aplicación de MÉTRICA Versión 3 proporciona sistemas con calidad y seguridad, no obstante puede ser necesario en función de las características del sistema un refuerzo especial en estos aspectos, refuerzo que se obtendría aplicando la interfaz.

Las interfaces descritas en la metodología son:

• Gestión de Proyectos (GP)

• Seguridad (SEG)

• Aseguramiento de la Calidad (CAL)

• Gestión de la Configuración (GC)

Gestión de Proyectos

La Gestión de Proyectos tiene como finalidad principal la planificación, el seguimiento y control de las actividades y de los recursos humanos y materiales que intervienen en el desarrollo de un Sistema de Información. Como consecuencia de este control es posible conocer en todo momento qué problemas se producen y resolverlos o paliarlos lo más pronto posible, lo cual evitará desviaciones temporales y económicas.

La Interfaz de Gestión de Proyectos de MÉTRICA Versión 3 contempla proyectos de desarrollo de Sistemas de Información en sentido amplio, acorde con EUROMÉTODO se consideran proyectos de desarrollo de nuevos Sistemas de Información y también los proyectos de ampliación y mejora de los ya existentes.

Las actividades de la Interfaz de Gestión de Proyectos son de tres tipos:

• Actividades de Inicio del Proyecto (GPI), que permiten estimar el esfuerzo y establecer la planificación del proyecto.

• Actividades de Seguimiento y Control (GPS), supervisando la realización de las tareas por parte del equipo de proyecto y gestionando las incidencias y cambios en los requisitos que puedan presentarse y afectar a la planificación del proyecto.

• Actividades de Finalización del Proyecto, cierre y registro de la documentación de gestión.

• Estas actividades pueden requerir, en función de la complejidad del proyecto, el soporte de herramientas comerciales de gestión de proyectos.


18

Seguridad

El análisis de los riesgos constituye una pieza fundamental en el diseño y desarrollo de sistemas de información seguros. Si bien los riesgos que afectan a un sistema de información son de distinta índole: naturales (inundaciones, incendios, etc.) o lógicos (fallos propios, ataques externos, virus, etc.) son estos últimos los contemplados en la interfaz de Seguridad de MÉTRICA Versión 3.

El objetivo de la interfaz de seguridad de MÉTRICA Versión 3 es incorporar en los sistemas de información mecanismos de seguridad adicionales a los que se proponen en la propia metodología, asegurando el desarrollo de cualquier tipo de sistema a lo largo de los procesos que se realicen para su obtención.

La interfaz de Seguridad hace posible incorporar durante la fase de desarrollo las funciones y mecanismos que refuerzan la seguridad del nuevo sistema y del propio proceso de desarrollo, asegurando su consistencia y seguridad, completando el plan de seguridad vigente en la organización o desarrollándolo desde el principio, utilizando MAGERIT como metodología de análisis y gestión de riesgos en el caso de que la organización no disponga de su propia metodología.

En consecuencia, la interfaz contempla dos tipos de actividades diferenciadas:

• Actividades relacionadas con la seguridad intrínseca del sistema de información.

• Actividades que velan por la seguridad del propio proceso de desarrollo del sistema de información.

Así mismo se hace especial hincapié en la formación en materia de seguridad. Las valoraciones sobre la seguridad deben realizarse en función de las características del sistema sin perder de vista además que, al ser finitos los recursos, no pueden asegurarse todos los aspectos del desarrollo de los sistemas de información, por lo que habrá que aceptar un determinado nivel de riesgo concentrándose en los aspectos más comprometidos o amenazados, que serán diferentes según las circunstancias.

Gestión de la Configuración

La interfaz de gestión de la configuración consiste en la aplicación de procedimientos administrativos y técnicos durante el desarrollo del sistema de información y su posterior mantenimiento. Su finalidad es identificar, definir, proporcionar información y controlar los cambios en la configuración del sistema, así como las modificaciones y versiones de los mismos. Este proceso permitirá conocer el estado de cada uno de los productos que se hayan definido como elementos de configuración, garantizando que no se realizan cambios incontrolados y que todos los participantes en el desarrollo del sistema disponen de la versión adecuada de los productos que manejan.

La interfaz de gestión de configuración de MÉTRICA Versión 3 permite definir las necesidades de gestión de configuración para cada sistema de información, recogiéndolas en un plan de gestión de configuración, en el que se especifican actividades de identificación y registro de productos, que se realizan durante todas las actividades de MÉTRICA Versión 3 asociadas al desarrollo y mantenimiento del sistema de información.

Asimismo, permite controlar el sistema como producto global a lo largo de su creación, obtener informes sobre el estado de desarrollo en que se encuentra y reducir el número de errores durante el mismo, lo que se traduce en un aumento de calidad del proceso de desarrollo y de mejora de la productividad en la organización.

La gestión de configuración facilita además el mantenimiento del sistema, aportando información precisa para valorar el impacto de los cambios solicitados y reduciendo el tiempo de implementación de un cambio, tanto evolutivo como correctivo.


Aseguramiento de la Calidad

El objetivo de la interfaz de Aseguramiento de la Calidad de MÉTRICA Versión 3 es proporcionar un marco común de referencia para la definición y puesta en marcha de planes específicos de aseguramiento de calidad aplicables a proyectos concretos.

Las actividades propias de la interfaz de Calidad en MÉTRICA Versión 3 están orientadas a verificar la calidad de los productos. Son actividades que evalúan la calidad y que son realizadas por un grupo de Asesoramiento de la Calidad independiente de los responsables de la obtención de los productos. Estas actividades de interfaz de MÉTRICA Versión 3 no entran en contradicción con el Plan General de Garantía de Calidad (PGGC), siendo lo suficientemente abiertas como para soportar una nueva versión del PGGC en el futuro.

Las actividades contempladas en la interfaz de Aseguramiento de la Calidad permitirán:

• Reducir, eliminar y prevenir las deficiencias de calidad de los productos a obtener.

• Alcanzar una razonable confianza en que las prestaciones y servicios esperados por el cliente o el usuario queden satisfechas.


20

21

4 ESTUDIO DE VIABILIDAD DEL SISTEMA

l objetivo del Estudio de Viabilidad del Sistema es el análisis de un conjunto concreto de necesidades para proponer una solución a corto plazo, que tenga en cuenta restricciones económicas, técnicas, legales y operativas. La solución obtenida como resultado del estudio puede ser la definición de uno o varios

proyectos que afecten a uno o varios sistemas de información ya existentes o nuevos. Pueden verse a continuación, en la Figura 4-1, las actividades que componen este proceso.

Figura 4-1: Esquema Estudio de Viabilidad del Sistema.

4.1 Actividad EVS 1: Establecimiento del alcance del Sistema

Tarea EVS 1.1: Estudio de la Solicitud

Desde los SSCC se busca una solución que incluya en una sola aplicación la reserva de espacios en cada una de las bibliotecas de la US y su gestión. Para ello, se ha decidido llevar a cabo su desarrollo en la Biblioteca de Ingeniería. Debido a las posibilidades de la misma, al contar con una infraestructura y personal que lo posibilitan. Estando la Sección de Informática de los SSCC ocupada en otros proyectos que no han permitido la realización del que se expone. La jefa de sección Mercedes Aguilar, responsable de la Biblioteca de Ingeniería, encargó el desarrollo del mismo a uno de los alumnos colaboradores (el autor de este proyecto) y uno de los usuarios que ejercía de administrador en la reserva de espacios, Francisco Avellaneda, quien ejercerá de asesor.

E

-

Estudio de Viabilidad del Sistema

22

22

Descripción General del Sistema.

Como ya se ha comentado en anteriores apartados, la aplicación que concierne a este proyecto se basa en la posibilidad de realizar la reserva de salas que pone a disposición la Biblioteca de la US en sus múltiples centros. Pero la dificultad del proyecto no radica en ofrecer este servicio como hasta ahora se estaba realizando. El verdadero problema es adaptarlo a cada uno de los centros que lo oferta. Esto lleva a que en cada centro se elegirán las opciones que lo caracterizarán y podrá cambiarlo:

• Gestión de oferta de salas, modificando, añadiendo, etc.

• Poder cambiar los horarios de reserva disponibles para acomodarlos a las necesidades de los usuarios.

• Gestión de salas especiales, que requieran de autorización.

• Distintos tipos de usuario con varias funcionalidades.

• Posibilidad de sancionar a usuarios que no cumplan las normas establecidas.

Y todo partiendo de una aplicación donde los usuarios responsables de cada biblioteca decidan como desean ofertar el servicio. Por supuesto esto conlleva una gran casuística de opciones y por tanto requiere de un control milimétrico por parte de la aplicación para evitar incoherencias (reservas fuera de horario, cancelaciones fuera de horario, imposibilitando la sanción pertinente, etc.)

Por lo tanto son diferenciables dos módulos. La aplicación que ve el usuario que realiza las reservas (un sistema no muy diferente al actual, donde se ofertan unas salas en unos horarios) al que se accede mediante una página web donde se elige el turno y la sala, se rellenan los datos y se reserva. Por otra parte, la parte que ven los gestores de la aplicación, con mucho más contenido (gestión de bibliotecas, gestión de salas, gestión de horarios, sanciones, preferencias, estadísticas, etc.)

Objetivos del EVS.

En este proceso, se busca realizar una descripción del sistema, donde se establecen los requisitos fundamentales de la aplicación así como los usuarios (y sus responsabilidades) que darán uso a la aplicación, buscando crear una primera solución que permita encaminar el proyecto:

Tabla 4-1: Objetivos del EVS.

Objetivo Descripción

Estudio de la situación actual Estudio del funcionamiento del servicio actualmente y los requisitos que se desean incorporar.

Definición de requisitos del Sistema

Se define cada requisito como una funcionalidad o un conjunto de ellas que se necesita, junto con su descripción de comportamiento y se le asigna una prioridad.

Definición de usuarios Se definen los usuarios que participarán del uso de la aplicación y la función y privilegios de los que contarán.

Estudio y valoración de alternativas

Se plantearán las opciones disponibles y sus ventajas einconvenientes.

Descripción de la solución Elección del camino a seguir en el desarrollo del proyecto.


Catálogo de requisitos.

En el siguiente apartado se realiza una clasificación de los requisitos generales obtenidos de la solicitud y la documentación de inicio aportada.

Tabla 4-2: Catálogo de requisitos generales.

RG-01 Gestión de bibliotecas y preferencias

Prioridad Alta

Descripción Dar de alta o bajas nuevas bibliotecas dentro de la aplicación. Gestionar preferenciasy cerrar/abrir días por festividad.

RG-02 Gestión de salas

Prioridad Alta

Descripción Posibilidad de gestionar la creación de salas con sus atributos (capacidad, etc.), eliminarlas o modificarlas, así como asignarles un tipo de sala (con/sin autorización).

Posibilidad de cerrar una sala en un turno concreto o día y así imposibilitar su reserva.

RG-03 Gestión de turnos de reserva

Prioridad Alta

Descripción Creación, modificación, etc. de turnos de reserva, dividiendo el horario en variosturnos. Siendo estos de duración variable y con la posibilidad de varios grupos de turnos por biblioteca.

Posibilidad de cerrar turnos concretos en un periodo seleccionado. Posibilidad de cerrar días completos.

RG-04 Gestión de reservas

Prioridad Alta

Descripción Alta de reservas de una sala en un turno concreto, por parte de peticionarios. Consulta, búsqueda y eliminación de reservas por parte del personal bibliotecario encargado.

RG-05 Gestión de sanciones

Prioridad Alta

Descripción Opción de sancionar a un usuario que haya realizado una reserva y no haya cumplido las normas de uso. Levantamiento de sanciones.

RG-06 Gestión de usuarios

Prioridad Alta

Descripción Posibilidad de dar de alta o baja nuevos usuarios con privilegios, personal bibliotecario que hará uso de la aplicación.


24

24

Tarea EVS 1.2: Identificación del Alcance del Sistema

Durante esta tarea se ha realizado la primera reunión para contrastar opiniones. En ella se realizó un primer acercamiento a usuarios y requisitos del sistema, así como la documentación existente sobre la aplicación a sustituir. El acta de reunión nº 1 puede ser consultada en los anexos.

Descripción General del Sistema

Del sistema es posible destacar los siguientes ejemplos de uso.

• Usuarios con un acceso total a las funcionalidades, encargados de definir la oferta de la biblioteca (Definir salas, turnos de reserva, etc.).

• Personal bibliotecario que atiende a la comunidad universitaria en los mostradores, entregando las llaves y encargado de revisar las reservas.

• Los peticionarios, miembros de la comunidad universitaria que pueden realizar las reservas.

Catálogo de usuarios:

En la siguiente tabla quedan definidos los usuarios que pueden extraerse de las necesidades de la funcionalidad del sistema y peticiones realizadas.

Tabla 4-3: Catálogo de usuarios.

Cód. Denominación Cometido

U-01 Superadministrador Personal de la SI de los SSCC, encargado de la gestión de bibliotecas.

U-02 Administrador Personal bibliotecario, encargado de la gestión completa (salas, horarios, usuarios, etc.) de una biblioteca en concreto.

U-03 Revisor Personal que atiende a los usuarios en los mostradores y hace entrega de las llaves de las salas. Se encarga de la gestión de reservas y sanciones.

U-04 Peticionario Usuarios que solicitan las reservas.


Tarea EVS 1.3: Especificación del Alcance del EVS

En esta parte del EVS se definen qué actividades del mismo se realizarán a continuación y cuales no son necesarias, reflejándolos en los objetivos del EVS.

Objetivos del EVS

Tabla 4-4: Objetivos del EVS.

Objetivo Descripción

Actividad EVS 2:Estudio de la situación actual

Es necesario un acercamiento al funcionamiento actual, pues la nueva aplicación apenas deberá cambiar su funcionamientofrente a las solicitudes de reserva.

Actividad EVS 4: Estudio de alternativas de solución

Ya se ha comentado en anteriores apartados que la solución planteada ya viene impuesta por los SSCC de la Biblioteca, por tanto solo se expondrá la solución ya impuesta.

Actividad EVS 5: Valoración de las alternativas

Al igual que la actividad EVS 4, se expondrá solamente la valoración de la solución ya tomada.

Actividad EVS 6: Selección de la solución.

No será necesaria llevarla a cabo pues ha sido impuesta.

4.2 Actividad EVS 2: Estudio de la situación actual

Tarea EVS 2.1: Valoración del Estudio de la Situación Actual

Contexto de la situación actual

En la actualidad, la red de bibliotecas de la Universidad de Sevilla, cuenta con una script PHP personalizado para cada biblioteca, que sólo permite definir el estado de las salas (disponible o reservada). Cualquier otro cambio: salas, horarios, tipos de salas, etc. debe ser realizado directamente en el código de script, eliminando cualquier tipo de gestión dinámica.

Cuando un usuario quiere reservar una sala, accede a la aplicación mediante la web de la biblioteca donde quiere realizar dicha reserva (http://bib.us.es/ingenieros/servicios/reserva_sala-ides-idweb.html, por ejemplo), tras loguearse mediante el UVUS el usuario accede a una tabla donde puede ver las salas disponibles y los turnos. Para reservar sólo hay que pulsar el botón que corresponde a una sala en un turno concreto.

Como ya se ha comentado, el administrador de las salas (al menos un usuario por cada centro) sólo puede cerrar salas a través de una dirección específica, y si quiere realizar algún cambio estructural, ya sea referente al número de salas, capacidad de estas u horarios, deberá ponerse en contacto con la SI y solicitarlo, para que ésta se encargue, algo que se demora por problemas de cargas de trabajo, se muestra en la Figura 4-2, un esquema de la situación actual donde pueden verse sus componentes.


26

26

Descripción de los Sistemas de Información Actuales

Figura 4-2: Esquema situación actual.

El sistema cuenta con los siguientes elementos:

• Servidor Web: donde se aloja el script PHP, cuenta con Apache 2.2 y PHP 4.6

• Script PHP: Código PHP donde se realiza la reserva de salas, hay un archivo por biblioteca.

• Servidor de Bases de datos: Donde se registran las reservas, se trata de un SGBD MySQL

• Servidor LDAP: Donde la aplicación comprueba la identidad del usuario.

Tarea EVS 2.2: Identificación de los Usuarios Participantes en la Situación Actual

Catálogo de usuarios del sistema actual

En la siguiente tabla se catalogan los usuarios que intervienen actualmente en la aplicación.

Tabla 4-5: Catálogo de usuarios actuales.

Cód. Denominación Cometido

Ua-01 Superadministrador Personal de la SI de los SSCC, encargado de editar el script PHP

Ua-02 Administrador Personal del centro en cuestión, encargado de cerrar/abrir salas.

Ua-03 Peticionario Usuarios que solicitan las reseras

Servidor BBDD

(MySQL)

Servidor LDAP

Script PHP

Cliente (Navegador web)

Servidor web

(Apache 2.2, PHP 4)


Tarea EVS 2.3: Descripción de los Sistemas de Información Existentes

Descripción lógica del Sistema

Figura 4-3: Modelo Entidad /Relación.

En la Figura 4-3 se puede ver el modelo E/R del sistema de reservas actual, donde sólo hay dos tablas no relacionadas:

• Reservas: Donde se quedan registradas las reservas, clave primaria (sala, turno, fecha).

• Cerradas: Donde se registran las salas cerradas, clave primaria (sala, turno, fecha).

Llama la atención que ni salas ni turnos sean entidades, y sus identificadores se definen mediante matrices estáticas en el código de la aplicación. La definición de los administradores también ha sido resuelta de la misma forma, incorporando una constante con el UVUS del usuario. Todo esto concluye en un sistema muy escueto, con nula usabilidad y escalabilidad de cara a los centros.

En cuanto a la aplicación en sí, sus funcionalidades son mínimas, sirva como ejemplo las capturas del apartado de gestión de dos de las bibliotecas donde está disponible:

En ellas se puede ver que las únicas funcionalidades son: ver información de las reservas y cerrar salas (todas durante todo el día o una en un turno) además de moverse entre fechas mediante el calendario mostrado arriba a la derecha.

El enlace a estadísticas que se muestra debajo de este no es operativo. En cuanto al buscador, su función es buscar un usuario dentro del día mostrado en pantalla, no un histórico completo de reservas.


28

28

Figura 4-4: Captura de la aplicación para la Biblioteca de Ingeniería.

Figura 4-5: Captura de la Gestión en la Biblioteca de Comunicación.

Un ejemplo de que el script es diferente por centro. En la Figura 4-5 se muestra un breve resumen de la reserva en cada una de estas, mostrando nombre del peticionario y fecha de la reserva, a diferencia de la mostrada en la Figura 4-4, donde no es accesible desde esa interfaz. Es un error desde el punto de vista de un usuario que para un centro se muestre una funcionalidad que no se muestra en el resto.


Y en el siguiente diagrama (Figura 4-6) puede verse el proceso que se sigue a la hora de realizar una reserva:

Figura 4-6: Solicitud de reserva, estado actual.

Tarea EVS 2.4: Realización del Diagnóstico de la Situación Actual

Diagnóstico de la Situación Actual

Se concluye que la aplicación no responde a las necesidades mínimas de este tipo de servicios. Fue creada sin la planificación necesaria y como tal no cuenta con las características necesarias para considerarla una aplicación en sí, sino más como un servicio online de mínima funcionalidad.

Por tanto su renovación es crítica a la hora de mejorar el servicio y dotar de las características y funcionalidades demandadas por los centros. Permitiendo que de esta manera, sean los propios centros los que mantengan su gestión (como de otra manera es lógico) y desde SSCC sólo mantengan la programación y no labores de gestión.

En resumen:

• No cuenta con un modelo E/R acorde a este tipo de aplicaciones.

• Funcionalidades escasas.

• Labores de gestión por parte de los SSCC y no de los centros.

• Discriminación entre centros.

Consulta de estado actual

Muestra la información

Login

Comprobación de identidad

Consulta de estado actual

Muestra de información

Solicitud de reservas

Confirmación

Registro de la solicitud


30

30

4.3 Actividad EVS 3: Definición de Requisitos del sistema

Tarea EVS 3.1: Identificación de las Directrices Técnicas y de Gestión

En esta tarea queda definido el catálogo de normas que da una visión de las directrices técnicas y de gestión. Quedan recogidas los estándares y procedimientos a seguir a la hora de plantear la solución del sistema.

Catálogo de Normas

• Políticas técnicas: En cuanto a la gestión del proyecto, se realizará un seguimiento periódico, con reuniones semanales al inicio de este y mensuales una vez el desarrollo se haya encarrilado. El lenguaje usado será PHP como ya ha sido expuesto, con apoyo de otros (JavaScript, etc.) siguiendo el paradigma de programación lineal. Para la documentación del proyecto se utilizará la suitte ofimática Microsoft Office®.

• Política de Seguridad: Se ha decidido usar el sistema SSO, ya explicado en los anteriores apartados, donde tras loguearse el usuario mediante el UVUS y comprobar que se forma parte de la comunidad universitaria, será la aplicación la que compruebe el rol que desempeña en la aplicación.

• Directrices de Gestión de Cambios: Se habilitará una versión de prueba de la aplicación, donde probar correcciones y cambios cuando se entre en fase de pruebas. Ambas funcionarán con la misma BBDD, siempre y cuando los cambios no sean estructurales, en cuyo caso habrá que detener el servicio para actualizar el modelo de datos.

Tarea EVS 3.2: Identificación de Requisitos

Para la realización de esta tarea, se ha llevado a cabo la 2ª reunión (consultar en el anexo III, acta nº 2), en este caso, con uno de los usuarios finales de la aplicación. Éste recogió en fases iniciales las demandas de la mayoría de los centros para poder exponerlas, además de contar con su experiencia propia en el sistema actual.

En dicha reunión se recogen los requisitos funcionales y de diseño (los generales ya fueron definidas en tareas anteriores) demandados, en la siguiente tarea serán catalogados y expuestos. Estos podrán ir cambiando a lo largo del proyecto, comprobando si su implementación es correcta y cumplen lo planteado.

Tarea EVS 3.3: Catalogación de Requisitos

Los requisitos generales de la aplicación ya han sido definidos en la tabla 4-2 en la actividad EVS 1, en las siguientes tablas se catalogan los requisitos funcionales y de diseño que deberán contemplarse en la solución.

Catálogo de requisitos funcionales

Tabla 4-6: Catálogo de requisitos funcionales.

RF-01 Listados de reservas

Prioridad Alta

Descripción La aplicación debe crear listados de reservas, permitiendo búsquedas.


RF-02 Notificaciones

Prioridad Alta

Descripción Las notificaciones de reservas (reservada/denegada/cancelada) y de sanciones se harán mediante correo electrónico.

RF-03 Cierre de salas intuitivo

Prioridad Alta

Descripción Se debe facilitar el cierre de salas, con un solo clic y en todos los periodos (díacompleto, turno completo, todas las salas, en un turno concreto).

RF-04 Salas especiales (de turno libre)

Prioridad Media

Descripción Algunas salas no se regirán a un grupo de turnos sino que se elegirá el periodo de tiempo al realizar la reserva, estas deberán requerir la aprobación del administrador o un responsable de dicha sala.

RF-05 Grupos de turnos

Prioridad Alta

Descripción Un grupo de turnos es una división del horario de la biblioteca en varios turnos de reservas. Cada biblioteca puede tener varios que son asignados a las salas.

RF-06 Duración de turnos variable.

Prioridad Alta

Descripción Los turnos tendrán una duración variable a elegir por el usuario.

RF-07 Sanciones según biblioteca

Prioridad Alta

Descripción Las sanciones y su periodo podrán variar según la biblioteca y elegirá si se aplican las propias o las de todos los centros.

RF-08 UVUS para identificar a los usuarios

Prioridad Alta

Descripción El UVUS identificará los usuarios y definirá que rol se le asignará en la aplicación.

RF-09 Preferencias

Prioridad Alta

Descripción Cada biblioteca podrá seleccionar algunas preferencias como: email remitente, días de sanción, días con antelación para realizar una reserva, reservas máximas.


32

32

RF-10 Informes de estadísticas

Prioridad Alta

Descripción Creación de informe de estadísticas en un periodo de tiempo a determinar. Los datos importantes son número de reservas, ratio usuarios/reservas, porcentaje de ocupación, etc.

RF-11 Reservas de administradores y revisores

Prioridad Media

Descripción Tanto los administradores como revisores también podrán realizar reservas.

Catálogo de requisitos de diseño

Tabla 4-7: Catálogo de requisitos de diseño.

RD-01 Diseño responsivo

Prioridad Media

Descripción El diseño de la aplicación debe adecuarse al dispositivo donde se visualiza. Permitiendo su interactividad desde smartphones y tablets además de ordenadores.

RD-02 Diseño corporativo

Prioridad Media

Descripción Se recomienda intentar usar la paleta de colores del manual de identidad corporativa.

4.4 Actividad EVS 4: Estudio de alternativas de solución.

Como ya ha sido expuesto, la solución a seguir ha sido definida por SSCC, por lo que se ha decidido no realizar la tarea EVS 4.1 (Preselección de alternativas) y se pasa a la siguiente.

Tarea EVS 4.2: Descripción de las Alternativas de Solución

La solución adoptada en SSCC es la creación de una aplicación web, usando PHP como lenguaje de desarrollo y otras tecnologías de apoyo comunes en estos proyectos como son HTML, CSS o JavaScript.

Modelo de Descomposición en Subsistemas

Antes de nada se realizará una descomposición en subsistemas del sistema, para realizar un acercamiento a la solución, por supuesto todos se ejecutarán dentro de la misma aplicación, aunque su tratamiento supondrá secciones separadas dentro de esta.


Tabla 4-8: Descomposición en subsistemas y usuarios participantes.

Gestión de Bibliotecas y Preferencias Gestión de Salas Gestión de Turnos

• Superadministrador

• Administrador

• Administrador • Administrador

Gestión de Usuarios Gestión de Reservas Gestión de Sanciones Solicitud de Reserva

• Superadministrador

• Administrador

• Administrador

• Revisor

• Administrador

• Revisor

• Administrador

• Revisor

• Peticionario

Cobertura de requisitos.

Al tratarse de un desarrollo completamente nuevo, en un principio todos los requisitos planteados son admisibles. Sólo se necesita un buen diseño relacional que cumpla con las necesidades y un desarrollo estructurado que permita diferenciar bien los usuarios y las gestiones sobre las que tienen privilegios.

Partiendo de estos puntos, se puede concluir que el desarrollo en HTML y PHP cumplirá las expectativas planteadas.

Entorno Tecnológico y Comunicaciones

El desarrollo del sistema se realizará usando las tecnologías de desarrollo web más comunes y populares, como son HTML, PHP, JavaScript y CSS. Así ha sido decidido por SSCC, puesto que es la metodología que se utiliza en la Sección de Informática para este tipo de desarrollos.

Como servidor, durante el desarrollo y fase de pruebas, se utilizará un sistema Linux (con la distribución Debian) disponible en la Biblioteca de Ingeniería (www.bibing.es) donde se alojan multitud de aplicaciones ya desarrolladas por los alumnos colaboradores.

El software con el que cuenta el servidor web incluye:

• PHP 5.5

• MySQL 5.5

• phpMyAdmin 3.4

• Apache 2.2

Además para la identificación de usuarios se utilizará el ya mencionado sistema SSO que pone a nuestra disposición la US y que proporciona toda la información relevante del usuario (UVUS, nombre, email, titulación, etc.).

Estrategia de Implantación Global del Sistema

Una vez se considere que la aplicación se encuentra en un estado correcto para entrar en estado de prueba se pondrá a disposición de los alumnos y personal bibliotecario de la biblioteca de la ETSI. Durante este periodo, previsiblemente varios meses, se estudiará su impacto y se corregirán errores que vayan surgiendo. Además se incorporarán las mejoras que se crean convenientes para mejorar su usabilidad.

Tras considerar que la aplicación ha superado el periodo de prueba, se avisará a SSCC de que la aplicación esta lista, entregando el código de la misma, la estructura de la BBDD (Sentencias SQL) y un manual de instalación, así como aclaración de directorios y de archivos.


34

34

Una vez esté disponible el servidor virtual, se instalará en la aplicación y su gestión pasará a manos de la Sección de Informática quedando el autor de este proyecto y la biblioteca de ingeniería libres de su gestión.

Resumiendo:

• 1ª etapa: Desarrollo:

• 2ª etapa: Implantación y pruebas en la biblioteca de ingeniería.

• 3ª etapa: Entrega de información a SSCC

• 4ª etapa: Implantación en servidor virtual a cargo de SI

• 5ª etapa: Implantación en el resto de centros.

4.5 Actividad EVS 5: Valoración de la Solución.

Tarea EVS 5.1: Estudio de la Inversión.

Impacto en la Organización de Alternativas.

El impacto más importante que se puede detectar es el producido sobre el personal bibliotecario, que deberá atender una nueva tarea, ya sean administradores o revisores. Para minimizar este impacto es necesario la elaboración de un manual en el que se expliquen detalladamente todas las tareas a realizar así como crear una aplicación con una interfaz lo más amigable posible.

En cuanto al impacto causado en los usuarios que realicen reservas (peticionarios), ya se ha establecido como requisito que sea mínimo, utilizando un sistema lo más similar al actual. Donde el usuario pueda solicitar la reserva en unos cuantos clics de ratón.

Coste / beneficio de Alternativas

Al usar los medios ya existentes y siendo el alumno, empleado de la biblioteca por parte de AICIA, el coste para los implicados será nulo, siendo ésta, una de sus funciones. La única nueva adquisición necesaria será la del servidor virtual, lo que tampoco supone ningún tipo de coste (es un servicio de la US) y el software utilizado en el desarrollo y soporte de la aplicación carecen de licencias que impliquen un desembolso.

En cuanto a los beneficios existen varios a destacar:

• Liberar de una carga innecesaria a la Sección de Informática de los SSCC

• Mejorar la gestión del servicio.

• Añadir nuevas características.

• Aumentar la independencia de los centros.

Tarea EVS 5.2: Estudio de los Riesgos.

Los riesgos más comunes en este tipo de desarrollos suelen ser debidos a la inexperiencia del desarrollador del proyecto, en este caso no es así. El autor cuenta con el título de “Grado Superior en Desarrollo de Aplicaciones Informáticas” cursado entre los años 2003 y 2005 donde se desarrollan aptitudes necesarias para este tipo de proyectos. Además cuenta con más de 3 años de experiencia en el sector privado, realizando aplicaciones tanto web como de escritorio para la empresa Euro-System Informática SLL, con sede en Sanlúcar de Barrameda.


Tarea EVS 5.3: Planificación de Alternativas.

Se estima que la aplicación debe entrar en funcionamiento a principios del curso 2014-2015, por lo que hay mucho tiempo de desarrollo y de revisiones disponible, en la siguiente tabla se resumen los estados y fechas del proyecto:

Tabla 4-9: Planificación.

Cód. Tarea Inicio Fin Total en días

00 Documentación del sistema 01/07/2013 31/05/2014 11 meses

01 Estudio de la solicitud 01/07/2013 07/07/2013 7 días

02 Diseño del Sistema 08/07/2013 14/07/2013 7 días

03 Desarrollo del Sistema 15/07/2013 15/09/2013 63 días

04 Implantación en Biblioteca ETSI 16/09/2013 23/09/2013 7 días

05 Fase de Pruebas 23/09/2013 31/05/2014 250 días

06 Elaboración manuales 02/01/2014 27/02/2014 56 días

07 Entrega del código y documentos a SSCC y resolución de dudas

02/06/2014 06/06/2014 5 días

08* Instalación en Servidor Virtual 08/06/2014 Sin determinar -

09* Implantación en todos los centros 15/09/2014 Sin determinar -

(*) Hay que aclarar que durante las dos últimas tareas ya no habrá responsabilidad por parte de la Biblioteca de Ingeniería ni del autor del proyecto, recayendo sobre la Sección de Informática de los SSCC.

A continuación se muestra el diagrama de Gantt del proyecto (Figura 4-7 y Figura 4-8) que se prevee seguir durante el desarrollo del proyecto.

Diagrama de Gantt

Figura 4-7: Tareas e hitos del diagrama de Gantt del proyecto.


36

36

Figura 4-8: Desarrollo del diagrama de Gantt.

4.6 Actividad EVS 6: Selección de la solución.

Como se ha ido detallando desde el inicio del EVS, la solución viene tomada previamente por los SSCC por lo que no es necesario realizar esta actividad, quedando la solución ya expuesta en los apartados anteriores.

37

5 ANÁLISIS DEL SISTEMA DE INFORMACIÓN

urante las actividades de este proceso (Figura 5-1) se busca conseguir una especificación detallada del sistema de información que satisfaga las necesidades de información de los usuarios y sirva de base para el posterior diseño del sistema final. Las tareas de esta actividad se pueden haber desarrollado ya en parte

en el proceso anterior (Estudio de Viabilidad del Sistema) de modo que se parte de los productos obtenidos en dicho proceso para proceder a su adecuación como punto de partida para definir el sistema de información, como tal, puede no ser necesario modificarlas.

Como el modelo seguido en este proyecto es el de programación estructurada, no es necesaria la realización de las actividades 4 y 5, las cuales se realizan sobre un modelo orientado a objetos.

Figura 5-1: Esquema del Análisis del Sistema de Información.

D

-

Análisis del Sistema de Información

38

38

5.1 Actividad ASI 1: Definición del Sistema

Tarea ASI 1.1: Determinación del Alcance del Sistema

En esta tarea se delimita el sistema de información. Se obtiene un modelo conceptual de datos identificando las entidades y relaciones que forman parte del sistema. De este proceso se obtiene el diagrama ER, Figura 5-2.

Diagrama Entidad relación

Figura 5-2: Diagrama Entidad/Relación.

Para conseguir una mayor precisión en la especificación del sistema de información, se procede a definir un glosario donde se describen términos del ámbito del proyecto, algunos ya usados en anteriores tareas y que ahora quedan concretados.

Glosario de términos

Tabla 5-1: Glosario de términos.

Término Definición

Superadministrador Personal de la Sección de Informática de los SSCC encargado de revisar la aplicación y dar de alta a las bibliotecas.

Administrador Personal de la Biblioteca que se encarga de la gestión de la aplicación a nivel local (al menos uno por centro) con acceso a todas las funcionalidades.

Revisor Personal de la biblioteca que atiende a los peticionarios, hace entrega de las llaves de las salas y se encarga de la gestión de reservas.

Peticionario Usuario que ha realizado una reserva a través de la aplicación.

Turno División de tiempo en la que se puede realizar una reserva.

Grupo de Turnos Conjunto de turnos en los que se divide el horario de la biblioteca, cada biblioteca puede contar con varios grupos de turnos.


Tarea ASI 1.2: Identificación del Entorno Tecnológico

Se describe a continuación los equipos donde se ejecutará y alojará la aplicación:

Equipo de usuarios:

Se busca que el usuario pueda acceder a la aplicación desde cualquier sistema, por tanto:

• Especificaciones técnicas: Indiferentes.

• Sistema Operativo: Indiferente.

• Conexión a internet: Requerida, recomendado al menos 1Mbps.

• Navegador Web: La aplicación funciona sobre los navegadores más comunes, pero consta de una mejor integración sobre en Mozzilla Firefox® y Google Chrome®.

Servidor de la aplicación:

El Sistema funcionará sobre el servidor de la Biblioteca de Ingeniería (http://bibing.us.es) que marcará los requisitos mínimos requeridos:

• Especificaciones técnicas: Intel Xeon, 2GB de RAM, 500 GB de HDD

• Sistema Operativo: Debian 7.

• Software instalado: Apache 2.2, PHP 5.5, MySQL 5.5.4, phpMyAdmin 3.4.11, Pearl(librería Mime)

Tarea ASI 1.3: Especificación de Estándares y Normas

Al catálogo de normas ya descrito en la tarea EVS 3.1 hay que añadir algunas normas al diseño de la aplicación:

• Normas de diseño: El diseño debe ajustarse al Manual de Imagen Corporativa. Se exige el uso de los siguientes pantones:

Interfaz peticionario:

#e34b3d

#d3e8a3

#8ec9d1

Interfaz de gestión:

#9c1f2f #f9a427

#ecabb4

#f9db91

Tarea ASI 1.4: Identificación de Usuarios Participantes y Finales

No es necesaria la revisión del catálogo de usuario ni de la planificación. Se remite a los documentos ya generados durante la tarea EVS 1.3 (Catálogo de usuarios) y la EVS 5.3 (Planificación).


40

40

5.2 Actividad ASI 2: Establecimiento de Requisitos

En esta actividad se lleva a cabo la definición, análisis y validación de los requisitos a partir de la información facilitada por el usuario, completándose el catálogo de requisitos obtenido en actividades anteriores. El objetivo es obtener un catálogo detallado de los requisitos, a partir del cual se pueda comprobar que los productos generados en las actividades de modelización se ajustan a los requisitos de usuario.

Tarea ASI 2.1: Obtención de Requisitos

Obtenidos los requisitos durante actividades anteriores del EVS, se procede a la definición de los casos de uso (de la Figura 5-3 a la Figura 5-7) detectados en el sistema. Dividido en los subsistemas ya planteados. Aclarar que en estos diagramas hacen el rol de usuario los ya definidos (superadministrador, administrador, revisor y peticionario) y además, el servidor de la aplicación, encargado de mostrar la interfaz y la gestión de datos.

Modelos de casos de uso.

Figura 5-3: MCU - Gestión de bibliotecas y preferencias.


Figura 5-4: MCU - Gestión de Usuarios.

Figura 5-5: MCU - Gestión de Salas.


42

42

Figura 5-6: MCU - Gestión de Turnos.

Figura 5-7: MCU - Gestión de Reservas.


Tarea ASI 2.2: Especificación de Casos de Uso

Se describen a continuación los casos de uso identificados en el apartado anterior:

Tabla 5-2: Gestión de bibliotecas - Casos de Uso.

CU-01 Identificar Usuario

Descripción Identificado el usuario a través del sistema SSO, el servidor identificará su rol.

Dependencias El servidor consultará en su BBDD si el UVUS está dado de alta.

CU-02 Crear espacio de datos para la biblioteca

Descripción El servidor crea las tablas propias de la biblioteca en la BBDD.

Dependencias Es necesario que se haya dado de alta los datos de la biblioteca en la BBDD.

CU-03 Listar Bibliotecas

Descripción Se generará un listado con información sobre la biblioteca.

CU-04 Cerrar por defecto días festivos

Descripción Se insertan los días festivos por defecto (navidades, fiestas patronales) en la BBDD.

Dependencias Es necesario que se haya dado de alta los datos de la biblioteca en la BBDD.

CU-05 Crear Biblioteca

Descripción Dar de alta una biblioteca en la BBDD.

Dependencias Se necesita previamente una solicitud con los datos del centro. Este CU-05, una vez concluido con éxito, lanza los CU-01 y CU-02 respectivamente.

CU-06 Editar Biblioteca

Descripción Cambiar los datos fundamentales de la biblioteca (Nombre, etc.).

CU-07 Definir Horario

Descripción Cambiar el horario de apertura de la biblioteca.

CU-08 Configurar preferencias

Descripción Cambiar las preferencias propias de la biblioteca (reservas máximas, etc.).

CU-09 Definir días festivos/cerrados

Descripción Añade un día como festivo/cerrado, quedando inhabilitado para reservar sala.

CU-10 Cerrar/abrir día

Descripción Cerrar/abrir día de forma rápida.


44

44

Tabla 5-3: Gestión de usuarios – Casos de uso.

CU-11 Alta Superadministrador

Descripción Dar de alta un UVUS como Superadministrador.

CU-12 Baja Superadministrador

Descripción Dar de baja el UVUS de un Superadministrador.

CU-13 Listar Superadministrador

Descripción Generar un listado con todos los Superadministradores.

CU-14 Alta Administrador

Descripción Dar de alta un UVUS como Administrador.

CU-15 Baja Administrador

Descripción Dar de baja el UVUS de un Administrador.

CU-16 Listar Administrador

Descripción Generar un listado con todos los Administradores de una biblioteca.

CU-17 Alta Revisor

Descripción Dar de alta un UVUS como Revisor.

CU-18 Baja Revisor

Descripción Dar de baja el UVUS de un Revisor.

CU-19 Listar Revisor

Descripción Generar un listado con todos los Revisores de una biblioteca.


Tabla 5-4: Gestión de salas – Casos de uso.

CU-20 Crear Tipo de Sala

Descripción Define un Tipo de Sala (Nombre, días de antelación en la reserva, etc.).

CU-21 Editar Tipo de Sala

Descripción Edita los datos de un Tipo de Sala.

CU-22 Listar Tipos de Sala

Descripción Generar un listado de los Tipos de Sala de un centro.

CU-23 Crear Sala

Descripción Dar de alta un UVUS como Administrador.

Dependencias Es necesario haber definido previamente algún Tipo de Sala (CU-20) y un Grupo de Turnos (CU-29).

CU-24 Editar Sala

Descripción Edita los datos de una Sala (Nombre, capacidad, tipo, etc.)

CU-25 Eliminar Sala

Descripción Elimina una Sala.

CU-26 Activar/desactivar Sala

Descripción Inhabilita (deja de ser visible) o Habilita una Sala para realizar reservas.

CU-27 Cerrar/Abrir Sala

Descripción Cierra o abre una sala en una fecha y turno concretos (aparece como cerrada) lo que impide su reserva en ese turno y fecha.

CU-28 Listar Salas

Descripción Generar un listado con todas las salas de una biblioteca.


46

46

Tabla 5-5: Gestión de Turnos – Casos de uso.

CU-29 Crear Grupo de Turnos

Descripción Se crea un grupo de turnos, eligiendo la configuración de turnos del grupo.

Dependencias Es necesario que los datos sean validados (CU-30)

CU-30 Validar datos de Grupo de Turnos

Descripción Se comprueban que los datos de configuración de un grupo de turnos son correctos (duración correcta de cada turno, hora de inicio y fin, etc.).

Dependencias Se ejecuta antes de crear un Grupo de Turnos (CU-29), para comprobar los datos.

CU-31 Crear Turnos

Descripción Se crea cada uno de los turnos en los que se divide un Grupo.

Dependencias Es necesario haber validado los datos (CU-30)

CU-32 Editar Turnos

Descripción Permite editar los turnos de un grupo.

CU-33 Eliminar Grupo de Turnos

Descripción Elimina un Grupo de Turnos Completo.

CU-34 Cerrar/Abrir Turnos

Descripción Cierra o abre todas las sala en una fecha y turno concretos (aparece como cerrada) lo que impide su reserva en ese turno y fecha.

CU-35 Listar Turnos

Descripción Generar un listado con todos los Grupos de Turnos de una biblioteca.


Tabla 5-6: Gestión de Reservas – Casos de uso.

CU-36 Reservar

Descripción Un peticionario realiza una reserva de sala en un turno y fecha concretos.

Dependencias Es necesario haber dado de alta alguna sala y turnos (CU-23 y CU-29).

CU-37 Cancelar

Descripción Se cancela una reserva concreta.

CU-38 Consultar

Descripción Consulta de información de una reserva (Peticionario, sala, turno, etc.).

CU-39 Sancionar

Descripción Sanciona a un usuario por haber cometido una infracción en su reserva.

Dependencias El usuario debe tener una reserva activa.

CU-40 Eliminar Sanción

Descripción Elimina una sanción.

CU-41 Buscar Reservas

Descripción Busca reservas a partir de datos (UVUS de peticionario, nombre, etc.).

CU-42 Generar Listado

Descripción Generar un listado las reservas a partir, o no, de una búsqueda.

CU-43 Generar Estadísticas

Descripción Generar un listado con todos los Grupos de Turnos de una biblioteca.

CU-44 Envío de e-mails informativos

Descripción El servidor envía un e-mail informativo al Peticionario de una reserva.

Dependencias Necesario que se haya reservado, cancelado o sancionado (CU-36, CU-37 o CU-39).

CU-45 Generar Cuadrante

Descripción Generar el cuadrante donde aparecen las posibles reservas del día. Cuadrante dividido en salas y turnos.

Dependencias Debe haber salas y grupos de turnos ya definidos (CU-23 y CU-29).


48

48

Tarea ASI 2.3: Análisis de Requisitos

No se han detectado inconsistencias, ambigüedades o escasez de información en la especificación de los requisitos y de los casos de uso definidos en las tareas anteriores.

Tarea ASI 2.4: Validación de Requisitos

Todos los requisitos especificados y los casos de uso se confirman como válidos tras la exposición en la reunión de seguimiento, se puede consultar su acta (3ª reunión) en el anexo III.

5.3 Actividad ASI 3: Identificación de Subsistemas de Análisis

Tarea ASI 3.1: Determinación de Subsistemas de Análisis

En análisis estructurado, los subsistemas coinciden habitualmente con el primer nivel de descomposición del Diagrama de Flujo de Datos que se representará en la siguiente tarea, y aunque no es objeto de desarrollo (es normal en POO) se muestra el diagrama de subsistemas con sus líneas de dependencia en la Figura 5-8.

Figura 5-8: Subsistemas detectados.

Tarea ASI 3.2: Integración de Subsistemas de Análisis

Como se ha comentado en la etapa anterior, al seguir un análisis estructurado, durante esta tarea se describirán los diagramas de flujo de datos (en UML) que describen varios casos de uso.

En concreto, no se han elegido todos ya que sería bastante tedioso para el lector (se han detectado 45 en total), se expondrán los más característicos (mostrados de la Figura 5-9 a la Figura 5-13) de cada Gestión y que no se limitan a introducir datos e insertarlos en la BBDD del sistema.


Figura 5-9: Flujo de datos – Identificar usuario.

Figura 5-10: Flujo de datos - Alta/Baja de usuario.


50

50

Figura 5-11: Flujo de datos – Crear Grupo de Turnos y Turnos.


Figura 5-12: Flujo de datos- Crear Tipo de sala y crear sala

Figura 5-13: Flujo de datos - Reservar sala y cancelar reserva.


52

52

5.4 Actividad ASI 6: Elaboración del Modelo de Datos

Tarea ASI 6.1: Elaboración del Modelo Conceptual de Datos

Durante esta etapa se ha tomado una decisión que afectará de manera definitiva al diseño relacional de la BBDD. Como se ha insistido durante el proceso de análisis, se tiene la idea de que cada biblioteca tenga su espacio en el sistema. Por lo que se decide tener los datos divididos en dos áreas:

• Los que pertenecen al sistema (usuarios y bibliotecas).

• Los que pertenecen a las bibliotecas (salas, turnos, etc.).

Por lo que se ha decidido que cada biblioteca tenga sus propias tablas para algunos datos, esto implica que el sistema cuente con una BBDD de estructura dinámica, donde se crean algunas tablas cuando son necesarias, partiendo de unas fijas. Para identificar estas tablas, a cada biblioteca se le asignará unas siglas que estarán presentes en los nombres de las tablas propias de la biblioteca, por ejemplo, si las siglas fueran SSS la tabla donde se almacenaría los datos sobre las salas podría ser: SSS_salas.

Esta decisión conlleva algunos beneficios, el principal es que el motor de la BBDD manejará 10 veces menos registros en cada consulta (ya que se consultarán datos de un centro y no de los 10 existentes) la otra es que se pueden diferenciar los espacios de trabajo. Aunque puede repercutir negativamente en el mantenimiento de la BBDD.

Se presenta a continuación, en la Figura 5-14, el modelo conceptual de datos, incluyendo solamente el nombre de las tablas. Como ya se ha comentado, las tablas con estructura de nombre: SSS_nombre, son las que se crearán propias a cada biblioteca.

Figura 5-14: Modelo Conceptual de Datos.


Tarea ASI 6.2: Elaboración del Modelo Lógico de Datos

Partiendo del modelo conceptual, se definen los atributos de cada tabla que se han considerado necesarios, se muestra a continuación el Modelo Lógico de Datos (Figura 5-15).

Figura 5-15: Modelo Lógico de Datos.


54

54

A continuación se describen cada una de las tablas y sus atributos:

Tabla 5-7: Modelo lógico de datos, descripción.

Sup

erad

min

istra

dor

Tabla donde se almacena el UVUS de los superadministradores.

• ID : identificador.

• UVUS: Usuario Virtual de la US del usuario.

Adm

inis

trad

or

Tabla donde se almacena el UVUS de los administradores.



• ID Biblioteca: Biblioteca de la que es responsable.

Rev

isor

Tabla donde se almacena el UVUS de los revisores.



• ID Biblioteca: Biblioteca de la que es responsable.

Bib

liote

cas

Información propia de cada biblioteca. Contiene información acerca de horarios y algunas configuraciones propias.


• Nombre: Nombre de la biblioteca.

• Siglas: Siglas de la biblioteca, servirán para identificar sus tablas propias (añadiéndolas al nombre de estas).

• Apertura : Hora de apertura.

• Cierra : Hora de cierre.

• Apertura fin de semana: Apertura en fin de semana.

• Cierre fin de semana: Cierre fin de semana.

• Duración mínima: Duración mínima de un turno.

• Abierto domingos: Si está abierta los domingos, por defecto es negativo, pero debe existir la posibilidad.

San

cion

es

Sanciones registradas. Es una tabla global, se puede decidir aplicar sanciones de todos los centros o sólo las propias.

• ID : identificador

• UVUS: UVUS del sancionado

• ID biblioteca: identificador de la biblioteca donde se produjo la sanción.

• Fecha inicio: Fecha de inicio de la sanción.

• Fecha fin: Fecha de fin de la sanción.

• Email: Correo del sancionado.

• Sancionador: UVUS del revisor o administrador que sancionó.

• Motivo : Descripción del porqué de la sanción.


Tip

o de

Sal

a

Información de los tipos de sala de una biblioteca. Cada tipo de sala une unas características propias a estas salas y que se aplicarán a la forma en que son reservadas


• Nombre: Nombre dado a este tipo de sala.

• Descripción: Descripción de la sala.

• Días antelación: Días con antelación con los que se puede reservar este tipo de salas.

• Turno libre : Si es positivo, indica que la sala tiene un tipo de turno donde el usuario elige la hora de inicio y fin, sin prefijar.

• Autorización: Si es necesaria autorización para su reserva.

• UVUS responsable: Si necesita credencial, UVUS del usuario que debe autorizarla.

• Correo responsable: Dirección de correo al que llegará la notificación de la reserva, para que se valide o no.

• Material audiovisual: Si la sala dispone de algún tipo de material audiovisual (proyector, pantalla táctil, etc.).

• Pregunta audiovisual: Pregunta que se le realizará al usuario para poder solicitar el material audiovisual.

• Duración mínima turno : En caso de ser de turno libre, el tiempo mínimo que puede durar la reserva.

Sal

a

Información de las salas de una biblioteca.


• ID tipo: Tipo al que pertenece la sala.

• Nombre: Nombre de la sala

• Capacidad: Nº máximo de personas permitidas.

• Grupo de turnos: Grupo de turnos de reserva en los que se puede solicitar la sala.

• Numeración: Número para ordenar las salas a la hora de mostrarlas en los espacios de trabajo.

• Activa: Si la sala puede o no reservarse.

Gru

po d

e T

urno

s Grupos de turnos, que agrupan, valga la redundancia, los turnos de cada biblioteca. Cada grupo es una forma diferente de dividir el horario de reserva.


• Letra : Letra que sirve para nombrar al grupo (A,B, etc.)

• Activo: Si el grupo de turnos está activo o no.

Tur

nos

Turnos posibles dentro de cada grupo.


• ID grupo: Identificador del grupo al que pertenece el turno.

• Inicio : Hora de inicio.

• Fin: Hora de fin.

• Activo: Si es posible reservar en ese turno.

• Activo fin de semana: Si se puede reservar durante el fin de semana, en ese horario.


56

56

Res

erva

s

Reservas realizadas en una biblioteca


• ID sala: ID de la sala reservada.

• ID turno : ID del turno en el que se ha reservado la sala.

• UVUS: Usuario virtual de la US que realiza la reserva.

• Fecha: Fecha de la reserva.

• Fecha petición: Fecha en la que se realizó la reserva.

• Nombre: Nombre del peticionario. Es necesario para comprobar la identidad a la hora de entregar las llaves de la sala.

• Correo: email donde se enviarán las notificaciones sobre la reserva.

• Titulación : Se guarda la titulación por motivos estadísticos.

• Nº de personas: En algunas salas se exige informar del número de personas que habrá en la sala.

• Audiovisual: Si se ha pedido usar o no, el material audiovisual del que dispone la sala.

• Motivo : Motivo de la reserva, necesario en las salas con autorización, en las otras, será nulo.

• Activa: Si la reserva está activa. En el caso requerir autorización, la reserva no pasará a estar activa hasta que no la haya validado el responsable de la sala.

• Turno libre : Si la sala es de turno libre, aquí se especifica la hora de inicio y fin.

Fes

tivos

Días que la biblioteca está cerrada, puede ser por ser festivo o por que no se abra.

• Fecha: Fecha en la que no está abierta la biblioteca, y por tanto no es posible reservar

Pre

fere

ncia

s

Guarda información de la biblioteca, como por ejemplo el email que aparecerá como remitente en las notificaciones.

• ID : Identificador.

• Nombre: Nombre de la preferencia, por ejemplo: pie del correo de notificación.

• Valor : Valor de la preferencia.

• Descripción: Breve descripción.

Cer

rada

s

Información sobre salas cerradas en una fecha concreta.

• ID : Identificador.

• ID sala: ID de la sala cerrada.

• ID turno : ID del turno en el que la sala está cerrada.

• Fecha: Fecha en la que es efectivo el cierre.

• UVUS: Usuario virtual que cerró la sala (Administrador o revisor de la biblioteca donde está cerrada).


Tarea ASI 6.3: Normalización del Modelo Lógico de Datos

Durante esta tarea, se busca comprobar que el Modelo Lógico de Datos cumple con la 3NF (tercera forma normal) durante el diseño del modelo se ha tenido en cuenta esta normalización, por lo que se puede concluir que se cumplen las exigencias y puede considerarse normalizado.

Tarea ASI 6.4: Especificación de Necesidades de Migración de Datos y Carga Inicial

La propia filosofía de la aplicación, donde son los usuarios finales (administradores de las bibliotecas) los encargados de ingresar los datos de cada uno de sus centros, excluye una migración de datos desde otros sistemas. No obstante, en cuanto al proceso de dar de alta una biblioteca, hay varias pautas a tener en cuenta.

En el momento de dar de alta todas las bibliotecas, por cada una de ellas, serán necesarios los siguientes datos:

• Nombre de la biblioteca.

• Siglas que identificarán a la biblioteca.

• Administrador principal.

• Dirección de correo electrónico desde el que enviará las notificaciones de aplicación.

Esta “carga inicial” se acometerá desde los SSCC, ya que, como se ha comentado con anterioridad, no es competencia de este proyecto. Durante el cual solo se añadirán los datos de la biblioteca de la Escuela Superior de Ingenieros por lo que no es necesario especificar más esta tarea.

5.5 Actividad ASI 7: Elaboración del Modelo de Procesos

Tarea ASI 7.1: Obtención del Modelo de Procesos del Sistema

Dentro del sistema se pueden identificar tres tipos de procesos, que salvo la forma en la que son implementados respecto al usuario, siguen un flujo de acciones y datos idéntico. Se pueden identificar los siguientes: los que recogen información de la base de datos y la muestran en pantalla, los que insertan datos tras validarlos y en los que se borra información.

Figura 5-16: Proceso de consulta de datos.

Durante el proceso de consulta, Figura 5-16, la petición se hace desde el navegador web, el servidor la interpreta y consulta los datos a mostrar que se presentarán en la pantalla.


58

58

Figura 5-17: Proceso de inserción de datos en la BBDD.

En los procesos que requieren inserción de datos funcionan como se expone en la Figura 5-17, primero se recogen y validan los datos. Luego son insertados en la BBDD y si todas las operaciones han sido llevadas a cabo se muestra un mensaje de éxito, si no, se deshacen todos los cambios.

En cuanto a las actualizaciones de datos, siguen básicamente el mismo proceso descrito anteriormente, validar, insertar y volver a validar.

Figura 5-18: Proceso de eliminación de datos en la BBDD.

En el caso de una necesidad de eliminar datos, el proceso es parecido al de inserción, cambiando solamente en la etapa final ya que no hay datos residuales, como mucho se producirá un error que imposibilite la acción. En ese caso se avisará al usuario y se redirigirá al principio del proceso para dar la oportunidad de volver a intentar el proceso. Puede verse el flujo de información seguido en la Figura 5-18.

5.6 Actividad ASI 8: Definición de Interfaces de Usuario

Tarea ASI 8.1: Especificación de Principios Generales de la Interfaz

Se especifican a continuación los principios generales de las interfaces de la aplicación, los cuales son comunes para todos los usuarios que hagan uso de ellas:

• Intuitiva y sencilla tanto para peticionarios como personal bibliotecario, incluyendo una barra de menú para seleccionar que gestión desea realizar.

• Las acciones que no requieran entrada de datos deberán resumirse a pocas interacciones mediante botones, ocultando la complejidad de las operaciones a los usuarios.

• Los avisos importantes, se deben mostrar mediante pop-ups que bloqueen la aplicación hasta confirmar/cancelar el aviso.

• Las operaciones correctas y errores se mostrarán mediante recuadros al inicio de la página.


Tarea ASI 8.2: Identificación de Perfiles y Diálogos

Existen cuatro tipos de usuario en la aplicación, pero a la hora de gestionar la interfaz gráfica se pueden dividir en dos perfiles.

• Peticionarios: Accede a la interfaz gráfica de usuario sin privilegios, en la que solo se pueden acceder a las solicitudes de reserva (elegir tipo de sala, día de reserva y reserva) además cuenta con un CSS propio con distintos colores y estilos.

• Usuarios con responsabilidad de gestión: Acceden a una interfaz distinta donde, desde una barra de menús, se puede elegir que gestión (esta barra será diferente según el rol del usuario) realizar. Se cuenta con un CSS propio con los pantones corporativos de la US.

Tarea ASI 8.3: Especificación de Formatos Individuales de la Interfaz de Pantalla

Formatos Individuales de Interfaz de Pantalla.

Cada pantalla se adaptará a la función que lleva a cabo, se pueden diferenciar en las siguientes categorías:

• Cuadrante de reservas (peticionarios): Se muestra un menú donde el usuario elige día, tipo de sala. Se muestra el cuadrante del día elegido donde aparecen cada celda sala/turno con su estado: Libre, Reservada y si ya ha sido reservada por el usuario logueado, se permite la opción de cancelar.

• Cuadrante de reservas (administradores y revisores): Se presentan una matriz divididas en salas/turno de reserva. Se podrán realizar varias funciones por cada una de las celdas del cuadrante, consultar, cancelar, sancionar usuario. Permite navegar por distintas fechas y cerrar días, salas o turnos.

• Recogida de datos y consulta/edición: En este tipo de pantallas se mostrarán los campos donde introducir la información, hay varios formatos de recogida (textbox, selects, etc.) donde se introducirán los datos. Como es lógico también contará con botones donde confirmar la acción (editar o insertar).

• Listados: Se mostrará un listado, donde en cada registro muestra los datos de la consulta realizada. Y a a partir de él, desencadenar acciones sobre el registro (actualizar, borrar, consultar).

Catálogo de Controles y Elementos de Diseño de Interfaz de Pantalla.

Al trabajar con HTML y JavaScript, los controles y elementos se limitan a los típicos en una página web, se basan en la librería CSS3 de Bootstrap ya explicada en el punto 2.1 de este documento:

• Barra de navegación: Sólo se muestran a los usuarios con privilegios (superadministrador, administrador, revisor) donde el usuario elige a la sección que quiere acceder.

• Botones: Donde se confirman acciones (insertar datos, editar, deshacer cambios)

• Enlaces: Para desencadenar una acción o ir a una sección distinta.

• Textbox: Donde se introducen datos en formato texto.

• Selects: Donde el usuario elige entre varias opciones.


60

60

Tarea ASI 8.4: Especificación del Comportamiento Dinámico de la Interfaz

Al tratarse de una aplicación web, el comportamiento dinámico se limita al uso de pop-ups y tags aclarativos. El resto de información se que carga junto con el código HTML es estática, y los efectos son los aportados por las librerías CSS y JavaScript, como puede ser un sombreado dinámico, difuminaciones, etc.

5.7 Actividad ASI 9: Análisis de Consistencia y especificación de requisitos

Tarea ASI 9.1: Verificación de los Modelos

Los modelos especificados en la tarea ASI 1.3 se han verificado satisfactoriamente. Aunque puedan existir modificaciones o mejoras según algunos criterios, se ha buscado encontrar una solución de compromiso entre eficiencia y sencillez en el desarrollo.

Tarea ASI 9.2: Análisis de Consistencia entre Modelos

Modelo Lógico de Datos Normalizado / Modelo de Procesos.

Se verifica que:

� Modelo de datos en 3ª Forma Normal.

� Se cubren las necesidades de consulta de información.

� Relaciones establecidas y sin duplicidades.

� Elección correcta de claves primarias.

� Todas y cada una de las entidades del modelo lógico normalizado son accedidas por algún proceso primitivo.

Modelo Lógico de Datos Normalizado / Interfaz de Usuario.

� En este análisis se ha comprobado que los atributos relevantes que aparecen en cada diálogo de la interfaz de usuario forman parte del modelo lógico de datos normalizado o, en su caso, atributos derivados de los mismos.

Modelo de Procesos / Interfaz de Usuario.

• Se comprueba que todo proceso en línea tiene asociado al menos un diálogo.


5.8 Actividad ASI 10: Especificación del plan de pruebas

Tarea ASI 10.1: Definición del Alcance de las Pruebas

Durante el proyecto se realizarán varios tipos de pruebas, según la etapa del proyecto en la que se encuentre su desarrollo y los usuarios que interactuarán.

• Pruebas unitarias y de integración, de cada una de las funciones de la BBDD del sistema. Se realizarán durante las primeras fases de programación del sistema. Se harán prueba de consistencia en el sistema, realizando el tipo de consultas que habrá durante su funcionamiento normal. Estas pruebas se llevarán a cabo directamente en la BBDD usando como software de apoyo PhpMyAdmin y sobre la etapa de desarrollo de la aplicación, comprobando que cada elemento cumple su acción correspondiente.

• Pruebas del sistema, una vez desarrollados todos los módulos de gestión del sistema se debe probar en un entorno local el correcto funcionamiento total del sistema con datos reales. Se harán pruebas en todas las gestiones y se definirá la “Biblioteca de Pruebas” donde se comprobarán estas funciones.

• Pruebas de implantación, una vez superadas las pruebas del sistema de manera local, debe probarse en la localización real. Para ser verificadas, el sistema debe presentar el mismo resultado que en el entorno local. En este periodo, la aplicación entrará en prueba piloto en la Biblioteca de Ingeniería. Para ello se creará la Biblioteca de Ingeniería dentro de sistema siguiendo el proceso normal y con la configuración normal.

• Pruebas de aceptación, los usuarios empezarán a hacer uso normal de la aplicación y se monitorizarán las incidencias producidas.

Tarea ASI 10.2: Definición de Requisitos del Entorno de Pruebas

Al tratarse de una aplicación web, para realizar las pruebas sólo será necesario un equipo con conexión a internet y un navegador. Por cuestiones técnicas, CSS3 presenta una mejor ejecución, se recomienda el uso de Mozilla Firefox® o Google Chrome®. Como medida de seguridad, se restringirá el acceso a la aplicación al rango de IP utilizadas en las instalaciones de la biblioteca.

En el momento en el que la prueba piloto comience, cualquier miembro de la comunidad universitaria podrá realizar reservas en la biblioteca de la ETSI mediante un navegador. Los revisores y administradores de la biblioteca también tendrán acceso total a la aplicación, estando ésta totalmente funcional.

Requisitos:

• Especificaciones técnicas y SO, indiferente.

• Navegador Web (Mozilla FireFox® o Google Chrome®, preferiblemente).

• Bloqueo de direcciones IP externas durante las primeras fases de prueba.

• Desbloqueo de direcciones IP una vez se conceda el paso a las pruebas de aceptación.


62

62

Tarea ASI 10.3: Definición de las Pruebas de Aceptación del Sistema

Para la aceptación será necesario que se confirme lo siguiente:

• Los usuarios pertenecientes a la comunidad universitaria que sean identificados como peticionarios, deberán poder realizar reserva de salas o cancelar reservas ya realizadas, recibir correctamente las notificaciones que genera el servidor.

• Que no se produzcan errores incoherentes, como que distintos usuarios puedan realizar la misma reserva (sala, turno y fecha).

• Los revisores dados de alta, tendrán acceso a los módulos permitidos pudiendo realizar las gestiones de reservas y sanciones.

• Los administradores, tendrán acceso total a la gestión de la biblioteca y podrán configurar la oferta. Crear salas, definir turnos y horarios.

• Se generen correctamente las estadísticas de reservas.

• Que el sistema soporte el acceso de múltiples usuarios sin que se vea afectada su ejecución.

5.9 Actividad ASI 11: Aprobación del Análisis del Sistema de Información

Tarea 11.1: Presentación y Aprobación del Análisis del Sistema de Información

Tras mostrarse los documentos generados y planificación a Mercedes Aguilar, se dan por aceptados y se aprueba el paso al siguiente proceso.

63

6 DISEÑO DEL SISTEMA DE INFORMACIÓN.

ras extraer la información fundamental del sistema durante el proceso de análisis se avanza a continuación al diseño del sistema de información. El objetivo final es la definición de la arquitectura del sistema y del entorno tecnológico que le dará soporte, junto con la especificación detallada de los componentes del

sistema de información. A partir de dicha información, se generan todas las especificaciones de construcción relativas al propio sistema, así como la descripción técnica del plan de pruebas.

Este proceso, como puede verse en la Figura 6-1, se divide en dos grandes bloques:

• Durante el primer bloque se realizan una serie de actividades en paralelo con el objetivo de detallar el sistema de información.

• En el segundo bloque, este diseño, se especifica con la información de construcción, carga inicial de datos, especificación del plan de pruebas y los requisitos de implantación.

Figura 6-1: Esquema del Diseño del Sistema de Información.

T

-

Diseño del sistema de información.

64

64

6.1 Actividad DSI 1: Definición de la Arquitectura del Sistema.

Tarea DSI 1.1: Definición de Niveles de Arquitectura

El diseño de la arquitectura del sistema es el mismo definido durante la tarea ASI 1.2, se completa a continuación con un diagrama de despliegue (Figura 6-2) donde se ven los nodos participantes:

Figura 6-2: Diagrama de despliegue del Sistema de Información.

• Nodo Servidor: Donde se aloja la aplicación y que se comunica con el cliente y servidor de autenticación mediante sistema SSO. Además será encargado de redirigir al usuario al servidor de autenticación.

• Nodo Servidor de autenticación SSO: Cuando el Servidor de la aplicación redirige al usuario, este se encarga de comprobar los datos e identificarlo dentro de la comunidad universitaria. Este se trata de un servicio ofrecido por la US, como ya se explicó y es externo a Sistema de Información.

• Nodo Base de datos: Base de datos relacional de la aplicación. Se encuentra en el mismo servidor, pero por motivo de claridad se representa de forma externa.

• Nodo Cliente: El cliente puede ser cualquier equipo en el que pueda funcionar un navegador web y disponga de conexión a internet.

En cuanto a la arquitectura de la aplicación, se dividirá en dos capas como se muestra en la Figura 6-3, a una corresponderán los archivos que modelan las funciones (Back-end) y por otro lado, la encargada de visualizar los distintos módulos (Front-end).

Figura 6-3: Capas de la aplicación.

• Front-end: Capa de presentación diseñada mediante HTML y CSS, acorde a las especificaciones, con un diseño sencillo e interactivo y acorde a los requisitos definidos.

• Back-end: Código PHP donde residen las operaciones a realizar y la gestión de datos.

Una vez estén definidas las dos, habrá que añadir a la capa de presentación el código necesario para que se comuniquen correctamente.


Tarea DSI 1.2: Identificación de Requisitos de Diseño y Construcción

Los requisitos a seguir son los siguientes:

• Sistema implementado en los siguientes lenguajes: PHP, HTML, CSS JavaScript.

• Los usuarios deben ser identificados mediante el sistema SSO proporcionado por la Universidad.

• La aplicación debe funcionar en cualquier dispositivo que pueda ejecutar un navegador, es decir, respetar un diseño responsivo.

• La estará diseñada para funcionar sobre el servidor que la biblioteca de la ETSI tiene funcionando.

Tarea DSI 1.3: Especificación de Excepciones

Durante la ejecución del sistema, se pueden detectar varios tipos de excepciones.

Primero se contemplan las debidas a la imposibilidad de acceder a alguno de los nodos de la aplicación. Luego las que surgen por errores en la definición de la oferta de la biblioteca a la que se desea acceder o por la imposibilidad de llevar a cabo una acción concreta.

Tabla 6-1: Catálogo de excepciones.

EX-01 Error de conexión con el servidor SSO

Condiciones Previas El servicio SSO no está disponible.

Nodos Afectados Servidor, Cliente.

Respuesta Error 503. Servicio no disponible.

EX-02 Error con el servidor de la aplicación

Condiciones Previas Servidor inaccesible.

Nodos Afectados Cliente.

Respuesta Error 503. Servicio no disponible.

EX-03 Base de datos no disponible

Condiciones Previas No se puede acceder a la BBDD.

Nodos Afectados Servidor, Cliente.

Respuesta No se puede acceder a la Base de Datos.

EX-04 Error de configuración de turnos

Condiciones Previas Los turnos de la biblioteca no han sido definidos o no son correctos.


Respuesta Error. No existe una configuración válida de turnos


66

66

CU-05 Error de tipo salas

Condiciones Previas Se intenta crear una sala sin haber definido los tipos.


Respuesta Error. Para crear salas es necesario primero añadir un Tipo de Sala

EX-06 Error de salas

Condiciones Previas No hay definidas salas en la biblioteca.


Respuesta Error. No se encuentran salas almacenadas en este momento.

EX-07 Error en reserva

Condiciones Previas Se ha intentado realizar una reserva, pero no se pudo insertar en la BBDD.


Respuesta Error. No se pudo crear la reserva. Inténtelo más tarde o revise los datos.

EX-08 Error de notificaciones

Condiciones Previas No se pudo llevar a cabo el envío de un e-mail de notificación.


Respuesta Error en notificación. No se llevó a cabo el envío del correo.

EX-09 Reserva no encontrada

Condiciones Previas Se intenta acceder a los datos de una reserva que no existe.


Respuesta Reserva no encontrada. No existe la reserva a la que está intentando acceder.

EX-10 Página no encontrada

Condiciones Previas Se intenta acceder a una dirección no contemplada.


Respuesta Página no encontrada. La dirección a la que intenta acceder no existe.

Tarea DSI 1.6: Especificación del Entorno Tecnológico.

No es necesario especificar el Entorno Tecnológico más allá de lo expuesto en la tarea ASI 1.2.


Tarea DSI 1.7: Especificación de Requisitos de Operación y Seguridad

Procedimientos de Seguridad y Control de Acceso.

Como ya se ha expuesto en las anteriores actividades, para controlar el acceso a la aplicación se utiliza el sistema SSO que proporciona la US. Con este sistema, el usuario ingresa mediante su UVUS (lo identifica como miembro de la comunidad universitaria) y entrega una instancia con los datos personales almacenados al servidor de la aplicación a través de una pasarela entre servidor de la aplicación y servidor SSO, Figura 6-4.

Figura 6-4: Pantalla y formulario de identificación del sistema SSO.

Además de identificación mediante el UVUS del usuario, también cuenta con otros medios de autenticación como son el DNI-e y el certificado emitido por la Fábrica Nacional de Moneda y Timbre.

Una vez, autenticado en el sistema, éste identificará el rol del usuario (peticionario, revisor, administrador o superadministrador) y dará acceso a las funciones que tiene asignadas.

Procedimientos de Operación y Administración del Sistema.

• Un peticionario podrá realizar la reserva siempre y cuando no haya una reserva (de la misma sala) por otro usuario en el mismo turno y día. La aplicación estará disponible, salvo error, durante todos los días sin distinción horaria.

• En cuanto a la gestión de las bibliotecas, lo único necesario es que un superadministrador haya dado de alta al centro correspondiente. Una vez se cumpla esta condición, los administradores pueden acceder en cualquier momento para realizar las gestiones pertinentes.

• Los sistemas de backup son externos a la aplicación, en el caso del servidor de la biblioteca cuenta con un servidor NAS que se encarga de realizar copias de las BBDD cada cierto tiempo programado. Una vez la aplicación pase a producción en las instalaciones de los Servicios Centrales, serán ellos los encargados de definir este sistema según sus protocolos establecidos.


68

68

6.2 Actividad DSI 2: Diseño de la Arquitectura de Soporte

La realización de esta actividad no se considera necesaria, puesto que todos los módulos del sistema se encuentran en el mismo equipo (el servidor de la biblioteca) y la comunicación con los usuarios se realizará a través de la conexión a internet.

Sólo cabe mencionar que el servidor se comunica con el sistema SSO mediante una serie de clases ya definidas y un conjunto de órdenes que será necesario incorporar en el código de la aplicación. Por supuesto no es objetivo de este proyecto el especificarlas y se remite a la web del sistema de la US para más información.

6.3 Actividad DSI 5: Diseño de la Arquitectura de Módulos del Sistema

Tarea DSI 5.1: Diseño de Módulos del Sistema

Atendiendo a los subsistemas ya identificados durante el proceso de análisis se puede definir la estructura de módulos en la Figura 6-5, que se muestra a continuación.

Figura 6-5: Diagrama de Estructura del Sistema.

Durante la actividad 3 del ASI se definieron los subsistemas que se consideraban dentro de la aplicación. En este punto del proyecto y recurriendo a la información obtenida en los diagramas de casos de uso y la identificación de procesos, se puede realizar una descripción de cada uno de los procesos que comprenden estos módulos, atendiendo a su tipo, desencadenante e inicio.

En las siguientes tablas, que identificará a cada uno de los módulos representados en el diagrama, quedan reflejados todos los procesos que han sido detectados durante la etapa de análisis.


Tabla 6-2: Procesos módulo - Gestión de bibliotecas y preferencias.

Módulo 01: Gestión de bibliotecas y preferencias

Proceso. Iniciación Usuario que lo lanza. Tipo de proceso

101 Crear biblioteca. Petición. Superadministrador. Inserción.

102 Crear estructura de datos. Sistema (tras 101). - Inserción.

103 Crear festivos por defecto. Sistema (tras 102). - Inserción.

104 Editar biblioteca. Petición. Superadministrador. Edición.

105 Listar bibliotecas. Petición. Superadministrador. Consulta.

106 Definir horario. Petición. Administrador. Inserción.

107 Configurar preferencias. Petición. Administrador. Consulta / Edición.

108 Definir días festivos/cerrados. Petición. Administrador. Inserción.

109 Cerrar/abrir día. Petición Administrador, revisor. Inserción / Borrado.

Tabla 6-3: Procesos módulo - Gestión de usuarios.

Módulo 02: Gestión de usuarios


201 Identificar usuario. Sistema (tras acceso). - Consulta.

202 Alta superadministrador. Petición. Superadministrador. Inserción.

203 Baja superadministrador. Petición. Superadministrador. Borrado.

204 Listar superadministrador. Petición. Superadministrador. Consulta.

205 Alta administrador. Petición. Administrador. Inserción.

206 Baja administrador. Petición. Administrador. Borrado.

207 Listar administrador. Petición. Administrador. Consulta.

208 Alta revisor. Petición. Administrador. Inserción.

209 Baja revisor. Petición. Administrador. Borrado.

210 Listar revisor. Petición. Administrador. Consulta.


70

70

Tabla 6-4: Procesos módulo - Gestión de salas.

Módulo 03: Gestión de salas


301 Crear tipo de sala. Petición. Administrador. Consulta.

302 Editar tipo de sala. Petición. Administrador. Inserción.

303 Eliminar tipo de sala. Petición. Administrador Borrado.

304 Listar tipo de sala. Petición. Administrador. Inserción.

305 Crear sala. Petición. Administrador. Consulta.

306 Editar sala. Petición. Administrador. Inserción.

307 Eliminar sala. Petición. Administrador. Borrado.

308 Listar sala. Petición. Administrador. Inserción.

309 Activar / Desactivar sala. Petición. Administrador. Edición.

310 Abrir / Cerrar sala. Petición. Administrador, Revisor. Edición.

Tabla 6-5: Procesos módulo – Gestión de turnos.

Módulo 04: Gestión de turnos


401 Crear grupo de turnos. Petición. Administrador. Inserción.

402 Validar datos de grupo. Sistema (tras 401). - Consulta.

403 Crear turnos. Sistema (tras 402). - Inserción.

404 Listar grupo de turnos. Petición. Administrador. Consulta.

405 Listar turnos. Petición. Administrador. Consulta.

406 Editar grupo de turnos. Petición. Administrador. Edición.

407 Eliminar grupo de turnos. Petición. Administrador. Borrado.


Tabla 6-6: Procesos módulo de reservas.

Módulo 05: Gestión de reservas


501 Reservar. Petición. Peticionario. Inserción.

502 Cancelar. Petición Peticionario, revisor, administrador.

Borrado.

503 Consultar. Petición. Administrador, revisor. Consulta.

504 Listar reservas. Petición. Administrador, revisor. Edición.

505 Sancionar. Petición. Administrador, revisor. Inserción.

506 Eliminar sanción. Petición. Administrador, revisor. Borrado.

507 Listar sanciones. Petición. Administrador, revisor. Consulta.

508 Buscar reservas. Petición. Administrador, revisor. Consulta.

509 Generar Cuadrante. Sistema (tras 201). - Consulta.

510 Generar estadísticas. Petición. Administrador, revisor. Consulta.

511 Enviar notificación. Sistema (tras 501, 502, 505).

Administrador, revisor.

Tarea DSI 5.2: Diseño de Comunicaciones entre Módulos

Para diseñar las comunicaciones de los distintos módulos hay que entender que se trata de un desarrollo estructurado sobre PHP y por tanto la comunicación entre los distintos módulos se ha decidido implementar mediante banderas y array de datos que contienen la información para funcionar correctamente.

De este modo se pueden identificar las siguientes interfaces (Figura 6-6) sobre el diagrama de estructura del sistema. Se ha añadido el sistema de identificación SSO (aunque es externo) que se comunica con la gestión de usuario mediante código, devolviendo un array con los datos del usuario autenticado.

Figura 6-6; Diagrama de estructuras con interfaces entre módulos.


72

72

� Interfaz Gestión Usuarios – SSO.

Tras realizar la autenticación del usuario en el sistema SSO este redirige una variable de sesión donde se encuentran los datos del usuario, que sirven para identificar el rol del usuario. Entre estos datos se encuentran los siguientes:

o UVUS.

o Nombre y apellidos.

o Correo electrónico.

o Titulación.

� Interfaz Gestión Usuarios – Gestión de Bibliotecas y de Reservas.

Desde la Gestión de usuarios se entregan los datos de éste necesitados en el resto de módulos.

� Interfaz Gestión de Bibliotecas – Gestión de Reservas.

El módulo de Gestión de bibliotecas entrega la información de su oferta (espacios y turnos) a la Gestión de reservas para que esta realice el cuadrante de reservas y lo presente. Entrega identificador de biblioteca, horarios, array con las salas disponibles y turnos.

� Interfaz Gestión de Bibliotecas – Gestión de Turnos y de Salas

La biblioteca entrega a los módulos de Gestión de Turnos y Salas la información que la identifica, para así acceder a los datos almacenados en ellos.

Tarea DSI 5.3: Revisión de la Interfaz de Usuario

Ya se comentó al inicio del proceso de análisis que la aplicación se dividiría en dos capas. La interfaz de usuario se refiere al Front-end de la aplicación y se presentan a continuación (de la Figura 6-7 a la Figura 6-13) algunas de las capturas más características.

Figura 6-7: Interfaz - Pantalla principal de Superadministrador.


Figura 6-8: Interfaz - Escritorio principal del Administrador/Revisor.

Figura 6-9: Interfaz - Creación de salas.


74

74

Figura 6-10: Interfaz - Definir turnos de un grupo.

Figura 6-11: Interfaz - Estadísticas de reservas.


Figura 6-12: Interfaz – Listado de reservas.

Figura 6-13: Interfaz – Escritorio del peticionario.


76

76

Puede verse que cada pantalla, excepto la de peticionarios, cuenta con una barra de menús con la que acceder a cada módulo/gestión (necesidad especificada en el ASI), para ver todas las pantallas y su uso, se recomienda leer los manuales de la aplicación, entregados con este proyecto.

6.4 Actividad DSI 6: Diseño Físico de Datos

Tarea DSI 6.1: Diseño del Modelo Físico de Datos

El modelo físico de datos final se muestra a continuación en la Figura 6-14.

Figura 6-14: Modelo Físico de Datos final.

Es prácticamente el mismo ya definido durante la actividad 6 del ASI, como puede verse están definidas las tablas de la biblioteca de la escuela (siglas BIA) donde se llevará a cabo el periodo de pruebas.

En este modelo ya aparecen los tipos de cada uno de los campos de las tablas necesarias y sus relaciones. Siguen los estándares del SGBD usado, en este caso MySQL, y se han cambiado mínimamente el nombre de algunas tablas y atributos, aunque son perfectamente reconocibles respecto al anterior modelo.


Tarea DSI 6.2: Especificación de los Caminos de Acceso a los Datos

Durante la ejecución de la aplicación no existe ningún proceso que desencadene una situación crítica de acceso a los datos, cualquier tipo de concurrencia se resuelve mediante el código PHP de la aplicación y las reglas establecidas en el modelo relacional de la BBDD.

Por explicar el caso de acceso a la BBDD que podría causar algún problema, sería el caso en el que dos peticionarios quisiesen realizar la misma reserva y lo hiciesen en el mismo momento. Como es lógico, el servidor ejecutará una de las dos reservas primero, y la siguiente no se podrá insertar debido a que habría duplicidad de clave primaria en la tabla de reservas de la biblioteca. Por tanto la segunda reserva no se llevaría a cabo y devolvería un mensaje de error.

Tarea DSI 6.3: Optimización del Modelo Físico de Datos

El modelo físico de datos se considera optimizado y no es necesario realizar ninguna modificación sobre el mismo.

Tarea DSI 6.4: Especificación de la Distribución de Datos

Todos los datos de la aplicación serán almacenados en el mismo nodo, en este caso, el nodo servidor, donde se encuentran tanto el código de la aplicación como los datos en la base de datos MySQL. No incluye esto las posibles copias de seguridad almacenadas en otros sistemas, como un servidor NAS o soporte físico que se realicen

6.5 Actividad DSI 7: Verificación y Aceptación de la Arquitectura del Sistema

Tarea DSI 7.1: Verificación de las Especificaciones de Diseño

Se ha revisado todo el sistema, incluyendo el Modelo Físico de Datos final, añadido durante la última actividad. No se han encontrado inconsistencias y por lo tanto las especificaciones de diseño quedan verificadas.

Tarea DSI 7.2: Análisis de Consistencia de las Especificaciones de Diseño

Las verificaciones realizadas son las siguientes:

Arquitectura del Sistema / Subsistemas:

� Cada subsistema de diseño está asociado al menos con un nodo del particionamiento físico del sistema de información.

Arquitectura del Sistema / Modelo Físico de Datos:

� Todos los elementos definidos en el Modelo físico de datos se incorporan, al menos, en un esquema físico de datos.

Arquitectura del Sistema / Entorno Tecnológico del Sistema de Información:

� Cada nodo del particionamiento del sistema de información está soportado por el entorno tecnológico.

� Se da soporte a todas las necesidades de comunicaciones entre nodos.

Arquitectura del Sistema / Diseño Detallado de Subsistemas:

� Cada módulo o clase del diseño detallado pertenece al menos a un subsistema.

� La interfaz del subsistema está proporcionada por interfaces de módulos o clases internas al subsistema.

Catálogo de Excepciones / Diseño Detallado de Subsistemas:

� Cada excepción del catálogo es tratada en el diseño de detalle del sistema de información, según los criterios establecidos en la creación del catálogo.


78

78

Diseño Detallado de Subsistemas / Modelo Físico de Datos:

� Los elementos del modelo físico de datos corresponden con los elementos utilizados por los módulos del diseño detallado, tanto de los subsistemas específicos como de los de soporte.

Diseño Detallado de Subsistemas / Interfaz de Usuario:

� Los datos o formatos de mensajes necesarios en el diseño de la interfaz de usuario corresponden con los datos o formatos de mensajes de los correspondientes módulos.

� Para cada evento / acción solicitado por el usuario existe un módulo que le da respuesta.

Tarea DSI 7.3: Aceptación de la Arquitectura del Sistema

La arquitectura del sistema se considera válida y por lo tanto se acepta su instalación.

6.6 Actividad DSI 8: Generación de Especificaciones de Construcción

Tarea DSI 8.1: Especificación del Entorno de Construcción

El entorno de construcción coincide con el tecnológico ya expuesto durante la tarea ASI 1.2, de todas formas se vuelve a recordar en este punto, pero sin entrar en mucho detalle.

• Hardware: El equipo que ejerce como servidor se trata de un sistema Linux (Distribución Debian) con unos requisitos tecnológicos medio-bajo ya que las necesidades de procesamiento y espacio no son críticas. En los equipos usuario sólo existe la necesidad de ejecutar un navegador web.

• Software: El servidor cuenta con PHP y MySQL para ejecutar la aplicación. En cuanto a los equipos que ejercen de clientes de la aplicación, sólo es necesario un navegador web como ya se ha explicado.

• Comunicaciones: El servidor ya se encuentra conectado a la red de la universidad y cuenta con una conexión perfecta para atender todas las demandas que surjan. En cuando a los clientes se recomienda un mínimo de 1Mbps para un correcto funcionamiento.

Tarea DSI 8.2: Definición de Componentes y Subsistemas de Construcción

Al tratarse de una aplicación web y contar solamente con un servidor solo se puede identificar un subsistema de construcción, en este caso, el mismo servidor en sí.

Subsistema Servidor:

• Contiene el código de todos los módulos de la aplicación, cada uno en sus respectivos directorios dentro del principal. Se han definido estos directorios según módulo o sección en la barra de menús. Además se distribuirán algunos archivos de utilidades en otros directorios como pueden ser archivos de configuración, constantes etc.

• Los módulos se comunican entre sí a través de las interfaces ya definidas, es decir usando variables que contienen la información necesaria.

• La base de datos, con su configuración inicial.

Tarea DSI 8.3: Elaboración de Especificaciones de Construcción

No es necesario hacer una especificación detallada del sistema ya que los archivos con el código fuente e interfaz de usuario realizada en HTML se adjuntarán junto con este documento y sólo dificultaría la lectura del mismo añadir tantas líneas de código.

Las guías de inicio, y manual para el desarrollador detallan estos apartados de forma más precisa y se añadirán en los anexos de este documento.


Tarea DSI 8.4: Elaboración de Especificaciones del Modelo Físico de Datos

En este punto se muestra el código SQL para definir cada una de las tablas que corresponde al sistema. En cuanto a las tablas propias de la biblioteca que contienen las siglas al inicio del nombre de la tabla, se adjuntan las creadas para la Biblioteca de la ETSI, donde se realizarán las pruebas.

Tabla 6-7: Sentencias SQL para crear la BBDD.

--------------------------------------------------- -------- -- Base de datos: `reserva_salas` -- ------------------------------------------------ -------- -- Tablas comunes CREATE TABLE IF NOT EXISTS `bibliotecas` ( `bib_id` int(11) NOT NULL AUTO_INCREMENT, `nombre_biblioteca` varchar(255) COLLATE utf8_uni code_ci NOT NULL, `siglas` varchar(5) COLLATE utf8_unicode_ci NOT N ULL, àpertura` varchar(5) COLLATE utf8_unicode_ci NOT NULL, `cierre` varchar(5) COLLATE utf8_unicode_ci NOT N ULL, àpertura_fs` varchar(10) COLLATE utf8_unicode_ci NOT NULL, `cierre_fs` varchar(10) COLLATE utf8_unicode_ci N OT NULL, `num_turnos` int(2) NOT NULL, `dmin` int(4) NOT NULL DEFAULT '30', `domingo` int(1) NOT NULL DEFAULT '0', PRIMARY KEY (`bib_id`), UNIQUE KEY `nombre_biblioteca` (`nombre_bibliotec a`,`siglas`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_ unicode_ci; CREATE TABLE IF NOT EXISTS `super_administrador` ( ìd` int(11) NOT NULL AUTO_INCREMENT, ùvus` varchar(255) COLLATE utf8_unicode_ci NOT N ULL, PRIMARY KEY (ìd`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_ unicode_ci ; CREATE TABLE IF NOT EXISTS àdministrador` ( ìd` int(11) NOT NULL AUTO_INCREMENT, ùvus` varchar(255) COLLATE utf8_unicode_ci NOT N ULL, `bib_id` int(11) NOT NULL, PRIMARY KEY (ìd`), KEY `bib_id` (`bib_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_ unicode_ci; CREATE TABLE IF NOT EXISTS `revisor` ( ìd` int(11) NOT NULL AUTO_INCREMENT, ùvus` varchar(255) COLLATE utf8_unicode_ci NOT N ULL, `bib_id` int(11) NOT NULL, PRIMARY KEY (ìd`), KEY `bib_id` (`bib_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_ unicode_ci; CREATE TABLE IF NOT EXISTS `sanciones` ( `sancion_id` int(255) NOT NULL AUTO_INCREMENT, `bib_id` int(11) NOT NULL, ùvus` varchar(25) COLLATE utf8_unicode_ci NOT NU LL, `correo` varchar(255) COLLATE utf8_unicode_ci NOT NULL, `fecha` datetime DEFAULT NULL, `fin` date NOT NULL, `motivo` varchar(255) COLLATE utf8_unicode_ci NOT NULL, ùvus_sanc` varchar(25) COLLATE utf8_unicode_ci N OT NULL, PRIMARY KEY (`sancion_id`), KEY `bib_id` (`bib_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_ unicode_ci;


80

80

--- Restricciones de las tablas ALTER TABLE àdministrador` ADD CONSTRAINT àdministrador_ibfk_1` FOREIGN KEY ( `bib_id`) REFERENCES

`bibliotecas` (`bib_id`) ON DELETE CASCADE ON UPDAT E CASCADE; ALTER TABLE `revisor` ADD CONSTRAINT `fk_Revisor` FOREIGN KEY (`bib_id`) REFERENCES `bibliotecas`

(`bib_id`); ALTER TABLE `sanciones`

ADD CONSTRAINT `sanciones_ibfk_1` FOREIGN KEY (`b i b_id`) REFERENCES `bibliotecas` (`bib_id`) ON DELETE CASCADE ON UPDATE CASCADE;

-- Tablas propias de cada biblioteca: -- Instanciadas para la bibliteca de la ETSI, sigla s:BIA -- ------------------------------------------------ --------

CREATE TABLE IF NOT EXISTS `BIA_grupo_turnos` ( `grupo_id` int(5) NOT NULL AUTO_INCREMENT, `letra` varchar(1) COLLATE utf8_unicode_ci NOT NU LL, àctivo` tinyint(1) NOT NULL DEFAULT '1', PRIMARY KEY (`grupo_id`), UNIQUE KEY `letra` (`letra`) ) ENGINE=MyISAM DEFAULT CHARSET=utf8 COLLATE=utf8_ unicode_ci ; CREATE TABLE IF NOT EXISTS `BIA_turnos` ( `turno_id` int(11) NOT NULL AUTO_INCREMENT, `grupo` int(11) NOT NULL, ìnicio` varchar(5) COLLATE utf8_unicode_ci NOT N ULL, `fin` varchar(5) COLLATE utf8_unicode_ci NOT NULL , àctivo` tinyint(1) NOT NULL DEFAULT '1', àctivo_fs` tinyint(1) NOT NULL DEFAULT '1', PRIMARY KEY (`turno_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_ unicode_ci;

CREATE TABLE IF NOT EXISTS `BIA_salas` ( `sala_id` int(11) NOT NULL AUTO_INCREMENT, `tipo_id` int(11) NOT NULL, `grupo_id` int(11) NOT NULL, `nombre_sala` varchar(255) COLLATE utf8_unicode_c i NOT NULL, `num_sala` int(11) NOT NULL, `capacidad` int(11) NOT NULL, àctiva` tinyint(1) NOT NULL DEFAULT '1', PRIMARY KEY (`sala_id`), UNIQUE KEY `nombre_sala` (`nombre_sala`), KEY `tipo_id` (`tipo_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_ unicode_ci ; CREATE TABLE IF NOT EXISTS `BIA_tipo_salas` ( `tipo_id` int(11) NOT NULL AUTO_INCREMENT, `nombre_tipo` varchar(255) COLLATE utf8_unicode_c i NOT NULL, `descripcion` varchar(255) COLLATE utf8_unicode_c i NOT NULL, àutorizar` tinyint(1) NOT NULL DEFAULT '0', ùvus_responsable` varchar(25) COLLATE utf8_unico de_ci NOT NULL, èmail_responsable` varchar(255) COLLATE utf8_uni code_ci DEFAULT NULL, `dias_antelacion` int(2) NOT NULL, `min_turno` int(2) NOT NULL, `turno_libre` int(2) NOT NULL, àv` tinyint(1) NOT NULL, `pregunta_av` varchar(100) COLLATE utf8_unicode_c i DEFAULT NULL, PRIMARY KEY (`tipo_id`), UNIQUE KEY `nombre_tipo` (`nombre_tipo`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_ unicode_ci;


CREATE TABLE IF NOT EXISTS `BIA_reservas` ( `reserva_id` int(255) NOT NULL AUTO_INCREMENT, `sala_id` int(11) NOT NULL, `turno_id` int(11) NOT NULL, `fecha_reserva` date DEFAULT NULL, `fecha_peticion` varchar(20) COLLATE utf8_unicode _ci DEFAULT NULL, ùvus` varchar(20) COLLATE utf8_unicode_ci NOT NU LL, `nombre` varchar(255) COLLATE utf8_unicode_ci NOT NULL, `correo` varchar(255) COLLATE utf8_unicode_ci NOT NULL, `titulacion` varchar(255) COLLATE utf8_unicode_ci NOT NULL, `num_personas` int(2) NOT NULL, àv` tinyint(1) NOT NULL, `motivo` varchar(255) COLLATE utf8_unicode_ci NOT NULL, àctiva` tinyint(1) NOT NULL DEFAULT '1', `turno_libre` varchar(11) COLLATE utf8_unicode_ci NOT NULL, PRIMARY KEY (`reserva_id`), UNIQUE KEY `sala_id` (`sala_id`,`turno_id`,`fecha _reserva`,`turno_libre`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_ unicode_ci ; CREATE TABLE IF NOT EXISTS `BIA_preferencias` ( `pref_id` int(11) NOT NULL AUTO_INCREMENT, `nombre` varchar(255) COLLATE utf8_unicode_ci NOT NULL, `valor` varchar(255) COLLATE utf8_unicode_ci NOT NULL, `descripcion` varchar(255) COLLATE utf8_unicode_c i NOT NULL, PRIMARY KEY (`pref_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_ unicode_ci ; CREATE TABLE IF NOT EXISTS `BIA_festivos` ( `fecha` date NOT NULL, PRIMARY KEY (`fecha`) ) ENGINE=MyISAM DEFAULT CHARSET=utf8 COLLATE=utf8_u nicode_ci; --- Restricciones de las tablas

ALTER TABLE `BIA_cerradas` ADD CONSTRAINT `BIA_cerradas_ibfk_1` FOREIGN KEY (` turno_id`) REFERENCES

`BIA_turnos` (`turno_id`) ON DELETE CASCADE ON UPDA TE CASCADE, ADD CONSTRAINT `BIA_cerradas_ibfk_2` FOREIGN KEY (` sala_id`) REFERENCES

`BIA_salas` (`sala_id`) ON DELETE CASCADE ON UPDATE CASCADE; ALTER TABLE `BIA_salas`

ADD CONSTRAINT `BIA_salas_ibfk_1` FOREIGN KEY (`tip o_id`) REFERENCES `BIA_tipo_salas` (`tipo_id`) ON DELETE CASCADE ON U PDATE CASCADE;

Algunas restricciones de claves foráneas no se han implementado en el código de la BBDD, por ejemplo las que corresponderían a la tabla reservas. Esto es debido a que aunque se borrasen salas o turnos (que incluyen su clave como foránea en la tabla reservas) se desea guardar esta información por motivos estadísticos.

Por lo tanto estas restricciones se implementarán mediante el código de la aplicación, evitando así incoherencias en los datos.

Por otro lado, el diseño del modelo lógico de datos, optimizado durante varias actividades, evita completamente la duplicidad de información en la BBDD al cumplir con la 3NF.


82

82

6.7 Actividad DSI 9: Diseño de la Migración y Carga Inicial de Datos

En este proyecto no es necesario la migración de datos desde otro sistema ya existente.

Respecto a la carga inicial de datos, no es necesario especificar un escenario específico ni un proceso en particular. Se realizarán de forma normal para comprobar que la aplicación funciona correctamente a la hora de crear una biblioteca, en este caso, la biblioteca de la ETSI.

• Biblioteca: Se añadirán los datos de la biblioteca, como son su horario, salas, turnos y preferencias. No es motivo de este proyecto documentarlas a continuación y por tanto, se omiten estos datos.

• Usuarios: También se darán de alta al personal de la biblioteca con su rol pertinente (Administrador o Revisor).

6.8 Actividad DSI 10: Especificación Técnica del Plan de Pruebas

Tarea DSI 10.1: Especificación del Entorno de Pruebas

Una vez la aplicación se encuentre lista para comenzar el periodo de pruebas, estas se realizarán directamente sobre el entorno final. Se accederá desde distintos navegadores y equipos a la dirección donde funcionará la aplicación.

Para comprobar correctamente el funcionamiento de operaciones de definición y manipulación de datos, que se realizarán sobre la aplicación, se accederá a la BBDD del sistema usando PhpMyAdmin. Este ya se encuentra instalado en el servidor, ya que se usa para la administración de otras BBDD ya alojadas en él.

Nodos:

• Clientes: Cualquier equipo (ordenadores de la biblioteca, tablets y smartphones) con conexión y posibilidad de ejecutar un navegador (Internet Explorer®, Mozilla Firefox®, Google Chrome®).

• Servidor: El servidor de la Biblioteca, donde se instalará la aplicación (bibing.us.es).

Tarea DSI 10.2: Especificación Técnica de Niveles de Prueba

A continuación se describen las pruebas agrupadas por los niveles ya descritos durante la actividad 10 del ASI:

• Pruebas unitarias y de integración.

Tabla 6-8: Catálogo de pruebas unitarias y de integración.

P-01 Pruebas DDL

Objetivo Comprobar que las tablas dinámicas se crean correctamente.

Resultado Tras dar de alta una biblioteca se crean todas sus tablas propias, con sus siglas.

P-02 Pruebas DML

Objetivo Comprobar la manipulación de datos de la aplicación

Resultado Los resultados se consultan, insertan, actualizan y borran correctamente.

P-03 Interfaz gráfica

Objetivo Comprobar que los elementos de la interfaz gráfica se muestran correctamente.

Resultado No se pueden acceder a la Base de Datos.


P-04 Pruebas de notificaciones.

Objetivo Comprobar que las notificaciones se envían correctamente.

Resultado Las notificaciones llegan por email correctamente.

• Pruebas del sistema.

Tabla 6-9: Catálogo de pruebas de sistema.

P-05 Prueba usuarios

Objetivo Comprobar que los usuarios se dan de alta y acceden correctamente a los procesos en los que tiene privilegios su rol.

Resultado Los usuarios son identificados y la funcionalidad e interfaz gráfica se adecuan a su rol en la aplicación.

P-06 Pruebas de excepciones

Objetivo Comprobar que se muestran correctamente los mensajes.

Resultado Tras provocar los errores deliberadamente, se deberán gestionar y mostrar mensajesde las excepciones.

P-07 Gestión de salas

Objetivo Comprobar la gestión de salas

Resultado Los tipos de salas y salas se crean, modifican y borran correctamente.

P-08 Gestión de turnos

Objetivo Comprobar la gestión de turnos

Resultado Los grupos de turnos y turnos se crean, modifican y borran correctamente.

• Pruebas de implantación.

Tabla 6-10: Catálogo de pruebas de implantación.

P-09 Prueba de implantación

Objetivo Funcionamiento en entorno real.

Resultado La aplicación funciona correctamente en los equipos del personal de la biblioteca y desde fuera de la red de la US.


84

84

• Pruebas de aceptación.

Tabla 6-11: Catálogo de pruebas de aceptación.

P-10 Prueba piloto en la Biblioteca

Objetivo Funcionamiento con usuarios y de forma normal, durante un periodo de tiempo extenso, en concreto el curso 2013 - 2014.

Resultado Los usuarios podrán realizar reservas, gestionarlas correctamente, etc.

Tarea DSI 10.3: Revisión de la Planificación de Pruebas

El desarrollo de las pruebas se llevará a cabo durante el desarrollo del proyecto (pruebas unitarias, integración y sistema) y la fase final de pruebas entre el 23/09/13 y el 31/05/14 (pruebas de implantacón y acpetación), periodo asignado a la fase de pruebas de proyecto en la planificación (tarea 5.3 EVS). Durante este periodo se ejecutarán en orden descendente y se iniciarán los distintos niveles cuando se comprueben que el anterior ha sido superado.

La fase de pruebas la llevará a cabo el desarrollador durante todos los niveles, buscando las situaciones críticas que puedan llevar a error al sistema.

Durante los dos últimos niveles (pruebas de implantación y aceptación) el personal de la Biblioteca de Ingeniería que ejerza de administrador o revisor comenzará a familiarizarse con la aplicación. También se abrirá el acceso al resto de la comunidad universitaria (quienes actuarán como peticionarios) dando comienzo la prueba piloto de la aplicación.

6.9 Actividad DSI 11: Establecimiento de Requisitos de Implantación

Tarea DSI 11.1: Especificación de Requisitos de Documentación de Usuario

Antes de abrir el acceso a la aplicación, se realizará una o dos presentaciones en la sala de formación con idea de familiarizar al personal de la biblioteca con los procedimientos a realizar. En esta presentación se mostrará el uso en tiempo real de la misma.

También se hará entrega de los siguientes manuales:

• Guía de inicio, con la información para crear una biblioteca desde cero.

• Manual de uso, para los revisores.

• Manual de administrador.

Los peticionarios no requieren de formación alguna. La aplicación funcionará prácticamente igual a como lo venía haciendo hasta ahora en el antiguo sistema, siendo totalmente intuitiva.

Tarea DSI 11.2: Especificación de Requisitos de Implantación

No es necesario especificar más allá de lo expuesto en la tarea DSI 10.2.

6.10 Actividad DSI 12: Aprobación del Diseño del Sistema de Información

Tarea DSI 12.1: Presentación y Aprobación del Diseño del Sistema de Información

El sistema ha sido presentado y aprobado satisfactoriamente durante la cuarta reunión, donde se han presentado los resultados a la Jefa de Sección, Mercedes Aguilar y a Francisco Avellaneda.

85

7 CONSTRUCCIÓN DEL SISTEMA DE

INFORMACIÓN

urante las actividades de este proceso (Figura 7-1) se genera el código de los componentes del Sistema de Información, se desarrollan todos los procedimientos de operación y seguridad y se elaboran todos los manuales de usuario final y de explotación con el objetivo de asegurar el correcto funcionamiento del

Sistema para su posterior implantación.

En el caso de este proyecto se ejecutarán las actividades 3 y 4 en el mismo apartado, puesto que según el plan de pruebas diseñado durante el DSI, las pruebas unitarias y de integración son intrínsecas. Tampoco es necesario realizar la actividad 8, puesto que no existe la necesidad de una migración de datos.

Figura 7-1: Esquema de la Construcción del Sistema de Información.

D

Construcción del Sistema de Información

86

86

7.1 Actividad CSI 1: Preparación del Entorno de Generación construcción

Tarea CSI 1.1: Implantación de la Base de Datos Física o Ficheros

Lo primero durante esta actividad ha sido comprobar que las sentencias SQL generadas durante la actividad 8 del DSI son correctas y se han ejecutado sobre el servidor de BBDD, usando phpMyAdmin. Lo fundamental ha sido comprobar que tanto las sentencias de las tablas comunes, como las propias (que como se ha expuesto, se crean dinámicamente al crear la biblioteca) se ejecutan correctamente.

Una vez comprobado, sólo se han dejado las comunes, el resto se añadirán durante la ejecución de la aplicación.

Tarea CSI 1.2: Preparación del Entorno de Construcción

Al estar el servidor de la Biblioteca funcionando, puesto que implementa varias aplicaciones ya desarrolladas con la misma tecnología, no es necesario realizar ninguna adaptación.

7.2 Actividad CSI 2: Generación del Código de los Componentes y Procedimientos.

Tarea CSI 2.1: Generación del Código de Componentes

Durante esta tarea ha sido detectado un problema debido al sistema SSO. Al añadir su código al sistema, el servidor siempre ejecuta la llamada (no se puede bloquear y es necesario que esté incluida en ese archivo) y se requiere por tanto que el usuario esté autenticado. Por lo tanto un usuario Peticionario que solo desee saber el estado de las salas (libres u ocupadas) debe estar logueado, algo no admisible.

La solución adoptada es crear una capa de visualización externa, que se denominada estado de salas en ella solo se visualizará el estado de las salas y la única acción que permitirá realizar al usuario será la de redirigir a la aplicación en sí, donde ya le será requerida la auntenticación.

En cuanto al código de la aplicación, se trata de un sistema escrito en PHP, HTML, CSS y JavaScript que aúna diseño y funcionalidad en el mismo código, además de incluir una gestión completa y varias interfaces según usuarios. Por lo tanto no se adjuntará todo el código (Se calculan unas 8000 líneas) para no alargarlo en exceso. En la Figura 7-2 se ve que el archivo más extenso, funciones.php, que pertenece a la capa Back-end ya supera las 2000 líneas de código, éste si será entregado en el anexo II. Este será entregado en formato digital, aunque si se detallará el árbol de directorios y cada uno de sus archivos en los anexos.

Figura 7-2: Entorno de desarrollo.


Lo que si se explica a continuación es la solución adoptada para su ejecución.

Funcionamiento de la aplicación.

El funcionamiento de la aplicación es bastante sencillo y consigue ocultar su estructura. Se basa en construir el índex, en función de las peticiones realizadas. Para ello las identifica mediante la URL a la que se está intentando acceder (y en caso de necesidad de variables enviadas por método POST), se adjunta un esquema de funcionamiento en la Figura 7-3. Para contar con esta función es necesario habilitar en el mod_rewrite en el servidor y configurar un archivo de acceso al directorio .htaccess.

Tabla 7-1: Contenido del archivo .htacccess.

ddDefaultCharset UTF-8 #Habilitar mod_rewrite RewriteEngine on ErrorDocument 404 /reserva_salas/

#Redirigir todos los accesos al index.php donde s e interpretan

RewriteRule !\.(js|ico|gif|jpg|png|css|csv)$ index. php [L] #Filtros de texto a UTF8 AddOutputFilterByType DEFLATE text/html text/plain text/xml text/css application/x-

javascript=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf 8_unicode_ci;

Con este método, la aplicación siempre será redirigida al index.php donde se interpretará la URL y se cargarán la interfaz gráfica y porciones de código necesarios para ejecutar la petición realizada.

Como ejemplo véase la URL cuando se intentan listar todas las reservas:

• https://bibing.us.es/reserva_salas/reservas/listar/

Se divide la URL dentro del archivo peticiones.php donde se obvia el directorio raíz, quedando dos peticiones:

• reservas y listar

Mediante el archivo peticiones.php, se identifica que la petición reservas se accede a la parte de gestión de reservas, y dentro de esta, se pide que se muestre el listado con la petición listar

Figura 7-3: Diagrama de flujo – Carga de página.


88

88

Tarea CSI 2.2: Generación del Código de los Procedimientos de Operación y Seguridad

En esta parte que se realiza a la vez que la anterior se generan los procedimientos para verificar usuario, para ello haciendo uso del manual proporcionado por la US para implementar el sistema SSO se utiliza el siguiente código y se incluye una carpeta (vendor) con los archivos necesarios.

Tabla 7-2: Código para lanzar el sistema SSO.

/***************** Código para autenticación Single Sing-On *******************/ session_start(); error_reporting(E_ALL ^ E_NOTICE); //requires SSO require_once('vendor/autoload.php'); $u = new \US\OpenSSO\User('sso.us.es_001'); // Logout if (isset($_GET['logout']) && $_GET['logout'] == "s alir") { if($_GET['siglas']) $u->logout("https://bibing.us.es/estado_sal as/".$_GET['siglas']); else $u->logout("https://bibing.us.es/reserva_sa las/"); } try { if ($u->isAuthenticated()) { $atributos = $u->allAttributes(FALSE); } else { if ($u->enforceAuthentication()) { } } } catch (Exception $e) { echo $e->getMessage(); }

Además son añadidas funciones de control de errores y validación de datos introducidos.

7.3 Actividad CSI 3: Ejecución de las Pruebas Unitarias e Integración

Tarea CSI 3.1: Preparación del Entorno de las Pruebas Unitarias e Integración.

Las pruebas se realizan sobre el sistema final.

Tarea CSI 3.2: Realización y Evaluación de las Pruebas Unitarias e Integración.

Tabla 7-3: Resultados de Pruebas Unitarias e integración.

Prueba Objetivo Incidencias Resultado

P-01 Comprobar las tablas dinámicas. - Superada.

P-02 Comprobar manipulación de datos. - Superada.

P-03 Comprobar interfaz gráfica. - Superada.

P-04 Comprobar notificaciones. - Superada.


7.4 Actividad CSI 5: Ejecución de las Pruebas del Sistema

Tarea CSI 5.1: Preparación del Entorno de las Pruebas del Sistema

Las pruebas, como ya se ha expuesto se realizan sobre el sistema final.

Tarea CSI 5.2: Realización de las Pruebas del Sistema

Tabla 7-4: Resultados de Pruebas de Sistema

Prueba Objetivo Incidencias Resultado

P-05 Comprobar gestión de usuarios. Si el sistema SSO cae, no se podrá acceder a la aplicación.

Superada.

P-06 Comprobar excepciones. Errores en la interfaz gráfica (subsanada).

Superada.

P-07 Comprobar gestión de salas. - Superada.

P-08 Comprobar gestión de turnos. - Superada.

Tarea CSI 5.3: Evaluación del Resultado de las Pruebas del Sistema

Todas las pruebas se han superado con éxito. Los problemas detectados han sido corregidos favorablemente. No son necesarias nuevas acciones de depuración en este punto.

7.5 Actividad CSI 6: Elaboración de los Manuales de Usuario

Tarea CSI 6.1: Elaboración de los Manuales de Usuario

Durante esta tarea se realizan los manuales de usuario que se adjuntan en formato electrónico. Los documentos entregados son los siguientes:

• Manual de desarrollador: En este manual se explican algunas pautas para el usuario encargado de instalar el sistema en los Servicios Centrales. Información de la BBDD, usuarios y archivos.

• Manual de administrador: Contiene toda la información relevante para un usuario que ejerza el rol de administrador. La completa gestión de la biblioteca, salas, turnos y preferencias.

• Guía de Inicio: Guía para crear una biblioteca desde 0, para que el administrador no tenga problemas a la hora de crear la oferta del centro por primera vez.

• Manual de uso: Manual de uso para los revisores, que incluye la gestión de reservas y sanciones.

Cada documento contará con la siguiente estructura:

• Portada.

• Índice.

• Introducción.

• Contenido.

Para la elaboración de los manuales se ha decidido usar Microsoft Word® con la fuente Latin Roman y un estilo consensuado con la Jefa de Sección, Mercedes Aguilar, para que respete los estándares de la documentación generada en la biblioteca. Se entregará la documentación en formato DOCX, ODT y PDF.


90

90

7.6 Actividad CSI 7: Definición de la Formación de Usuarios Finales

Tarea CSI 7.1: Definición del Esquema de Formación

Durante el desarrollo proceso de Diseño el Sistema se decidió que era necesario realizar una serie de presentaciones además de la entrega de los manuales de usuario.

Se plantean 3 sesiones de formación:

• Presentación con diapositivas. Se realizará una presentación (para el personal bibliotecario) cuando falté poco menos de un mes para la implantación del sistema. En ésta se mostrará la interfaz y las tareas nuevas a seguir por el personal de la biblioteca.

Duración: 1’5 horas

Documentos: Presentación en Microsoft PowerPoint®

• Presentación uso real de la aplicación. El día antes de lanzar la aplicación se realizará una presentación para los revisores y administradores, en ella se mostrará el funcionamiento real de la aplicación y se responderán dudas. Se simularán todos los casos de uso descritos.

Duración: 2 horas

Documentos: Se hará uso de la aplicación en tiempo real.

• Presentación para los SSCC y otras bibliotecas. Presentación de la aplicación una vez se considere que ha superado el periodo de pruebas piloto y el sistema es aceptado. Durante esta presentación se mostrarán estadísticas de uso y se hará entrega de la documentación a los SSCC.

Duración: 3 horas

Documentos: Uso en tiempo real de la aplicación y manuales de usuario.

Tarea CSI 7.2: Especificación de los Recursos y Entornos de Formación

Durante las sesiones antes presentadas se hará uso de la Sala de Formación de la Biblioteca, la cual dispone de proyector y un equipo con conexión por asiento donde los usuarios puedan hacer pruebas en la misma sesión si es necesario.

Sala de formación:

• Proyector

• 30 puestos con un equipo funcional en cada puesto.

• Conexión de los equipos por cable y conexión Wi-Fi.

Para las presentaciones, como ya se ha informado se hará uso del software Microsoft PowerPoint®. Además se entregarán impresiones de los manuales de usuario para los presentes.

7.7 Actividad CSI 9: Aprobación del Sistema de Información

Tarea CSI 9.1: Presentación y Aprobación del Sistema de Información

El sistema ha sido presentado tanto a los usuarios como a los encargados de su aprobación. No se han producido objeciones salvo la posibilidad de añadir un sistema por el cual un administrado o revisor pueda ver el sistema como un peticionario normal, una variedad de modo sin privilegios. Será añadido durante la siguiente etapa.

Se considera aprobado y se da el visto bueno para su implantación final.

91

8 IMPLANTACIÓN Y ACEPTACIÓN DEL SISTEMA

ste proceso tiene como objetivo principal la entrega y aceptación del sistema en su totalidad, y la realización de todas las actividades (Figura 8-1) necesarias para el paso a producción del mismo. Las actividades previas al inicio de la producción incluyen la preparación de la infraestructura necesaria para

configurar el entorno, la instalación de los componentes, la activación de los procedimientos manuales y automáticos asociados y, cuando proceda. Para ello se toman como punto de partida los productos software probados, obtenidos en el proceso Construcción del Sistema de Información (CSI) y su documentación asociada.

No será necesario realizar las actividades 7, 8 y 9, ya que no concierne a este proyecto dar mantenimiento ni establecer un SLA (acuerdo de nivel de servicio) y al tratarse de una aplicación con propósito académico no requieren de una presentación oficial. Ésta y el mantenimiento serán tareas de los Servicios Centrales una vez asumido el control del proyecto.

Figura 8-1: Esquema de la Implantación y Aceptación del Sistema.

E

-

Implantación y Aceptación del Sistema

92

92

8.1 Actividad IAS 1: Establecimiento del Plan de Implantación

Tarea IAS 1.1: Definición del Plan de Implantación

El sistema se viene desarrollando sobre el servidor final desde el inicio de su construcción, al tratarse de un sistema PHP con una BBDD en MySQL lo más lógico es probarlo directamente sobre el equipo final. Se han subido los archivos periódicamente desde los equipos de trabajo, comprobando la funcionalidad.

Por lo que no es necesario realizar una preparación ya que el sistema, una vez finalizado, está funcionando sobre el equipo final donde los usuarios sólo necesitan un navegador para acceder.

En cuanto a la formación de los usuarios ya se ha expuesto las presentaciones que se llevan a cabo durante la tarea 7.1 del CSI. Además, se contará con los manuales ya nombrados con anterioridad.

Resumiendo:

• El sistema ya se encuentra instalado y en funcionamiento.

Se realiza las presentaciones con fechas (las dos iniciales, el resto habrá que esperar al final de las pruebas piloto).

• Presentación. 07/09/2013 – 11:00 a-m. aula de Formación de la Biblioteca ETSI.

• Presentación del entorno final. 13/09/2013 – 11:00 a.m. aula de Formación de la Biblioteca ETSI.

• Fase de pruebas de implantación y aceptación. Inicio de prueba piloto en la ETSI. 16/09/2013.

Tarea IAS 1.2: Especificación del Equipo de Implantación

Los usuarios implicados en la implantación serán los siguientes:

• Revisores: Personal de la biblioteca de la ETSI que está en el mostrador y entrega las llaves de las salas, ejercerá el rol de revisor.

• Administradores: Personal de la biblioteca, en este caso Fco. Avellaneda y Mercedes Aguilar. El autor de este proyecto, José María Vidal ejercerá también este rol para controlar la aplicación durante las pruebas de implantación y aceptación.

• Equipo Técnico / Mantenimiento: Se encargará esta labor al autor de este proyecto, responsable de realizar las correcciones y el mantenimiento durante esta etapa.

8.2 Actividad IAS 2: Formación Necesaria para la Implantación

Salvo las acciones ya especificadas para los usuarios durante la actividad CSI 7 (Presentaciones y manuales), no es necesario realizar ninguna acción más.

8.3 Actividad IAS 3: Incorporación del Sistema al Entorno de Operación

Tarea IAS 3.1: Preparación de la Instalación

No es requerido realizar preparativos adicionales para la implantación final.

Tarea IAS 3.2: Realización de la Instalación

El sistema ya ha sido instalado durante su proceso de desarrollo, para su completo funcionamiento se habilitan los enlaces en las correspondientes direcciones web:

• Para el personal de biblioteca: https://bibing.us.es/reserva_salas

• Para la comunidad universitaria, acceso incrustado dentro de la web de la biblioteca de Ingeniería (peticionarios): http://bib.us.es/ingenieros/reserva-de-salas


8.4 Actividad IAS 4: Carga de datos al Entorno de Operación

Tarea IAS 4.1: Migración y Carga inicial de Datos

La BBDD ya se cargó durante el proceso de Construcción. En cambio para poder comenzar la implantación para la prueba de lanzamiento en la Biblioteca de Ingeniería, se ha dado de alta a la Biblioteca de Ingeniería, creándose sus tablas propias, por parte del autor de este proyecto, ejerciendo la labor de Superadministrador.

La información a ingresar para comenzar las pruebas es la siguiente:

• Datos generales de la Biblioteca de Ingeniería.

• Preferencias.

• Grupos de turnos y turnos.

• Tipos de salas y salas

• Administradores.

• Revisores.

Una vez realizado, ya está listo para que el sistema entre en producción.

8.5 Actividad IAS 5: Pruebas de Implantación del Sistema

Tarea IAS 5.1: Preparación de las Pruebas de Implantación

Una vez ingresados los datos de la biblioteca y los usuarios que tendrán algún rol con privilegios (administradores y revisores), el sistema está listo para comenzar las pruebas.

Tarea IAS 5.2: Realización de las Pruebas de implantación

Las pruebas de implantación se ejecutarán durante el fin de semana que va desde el 13/09/13 al 15/09/13 ya que se ha programado el acceso a la aplicación justo después de la presentación a los usuarios, calculada sobre las 15:00 del viernes 13.

Se ha decidido esta fecha por coincidir con el final de los exámenes y fin de semana, periodo donde el número de reservas disminuye a menos del 10%. Durante esa tarde y fin de semana se monitorizará la aplicación para comprobar las incidencias que se producen.

Durante estos días algunos peticionarios realizarán reservas y se comprobará que la gestión de ellas es correcta, además el autor también realizará pruebas con todos los roles para detectar incidencias.

Tarea IAS 5.3: Evaluación del Resultado de las Pruebas de Implantación

Resultados e incidencias:

Tabla 8-1: Resultado pruebas de implantación.

Prueba Objeto Incidencias

P-09 Comprobar implantación. • Algunos errores de visualización (subsanada).

• Durante el domingo (que la biblioteca está cerrada) no aparecer el siguiente día hábil sino mensajes de día cerrado. (subsanada).

Se han subsanado las incidencias y se considera esta tarea finalizada.


94

94

8.6 Actividad IAS 6: Pruebas de Aceptación del Sistema

Tarea IAS 6.1: Preparación de las Pruebas de Aceptación

No es necesario realizar ninguna actividad adicional.

Tarea IAS 6.2: Realización de las Pruebas de Aceptación

A partir del día 16 de septiembre, se dará comienzo a la fase piloto de la aplicación en la Biblioteca de Ingeniería. Su duración ha sido estimada durante los dos cuatrimestres del curso 2013-2014, y se dará por concluida el 31 de mayo. Momento en el que se realizará a entrega del código y documentación a los responsables de la SI de los SSCC de la BUS.

Durante este periodo, como ya se ha ido detallando en anteriores etapas, los peticionarios que realicen reservas en la Biblioteca ETSI lo harán a través de la nueva aplicación, mientras que en otros centros sigue funcionando el anterior sistema.

Estas pruebas comprenden un seguimiento exhaustivo a la aplicación, sus incidencias y errores, realizadas tanto por peticionarios como por usuarios con privilegios, consistiendo en una prueba real del sistema.

Tarea IAS 6.3: Evaluación del Resultado de las Pruebas de Aceptación

Tabla 8-2: Resultados pruebas de aceptación.

Prueba Objetivo Incidencias

P-10 Comprobar aceptación.

• Vulnerabilidad encontrada: Algunos usuarios podían realizar más reservas de las permitidas por las preferencias. Un usuario entrando desde varios ordenadores, realizando dos reservas a la vez consiguió saltarse esta restricción. subsanada

Para su solución, se cambia el sistema de comprobación de número máximo de reservas justo antes de insertarla en la BBDD. subsanada

• Nuevo requisito: Se ha añadido el sistema (denominado Modo Usuario) por el cual un revisor o administrador puede intercambiar su rol con el de peticionario y comprobar el sistema. subsanada

• Nuevo requisito: Sistema de reservas masivas añadido. Un administrador puede duplicar la misma reserva durante un periodo de tiempo determinado. Necesidad surgida a algunos profesores para solicitar realizar cursos en la sala de formación que se extendería por varias semanas. subsanada

• UVUS nulo en SSO: Se ha comprobado que el sistema SSO podía incurrir en un fallo, donde daba por logueado a un usuario con el UVUS nulo, se han realizado los ajustes de código para prevenirlo. subsanada

• Nuevo requisito: Necesidad para las salas de turno libre de poder ver un calendario con las reservas programadas durante el mes. subsanada

Tras la finalización y superación de estas pruebas, se considera el sistema aceptado.


Se muestra a continuación, en la Figura 8-2, algunas estadísticas durante este periodo.

Figura 8-2: Pantalla de estadísticas obtenidas durante el periodo de pruebas.

Como puede verse en la imagen se han producido en total 9325 reservas, con un 75.3% de ocupación. Lo cual puede considerarse como un amplio espectro para definir como exitosa la fase de piloto de la aplicación.

Han realizado reservas un total de 2401 usuarios (peticionarios) distintos, quienes han alabado los cambios introducidos, como son las sanciones y la nueva usabilidad e interfaz.

Se considera finalizada esta etapa y se da paso a la producción.

8.7 Actividad IAS 10: Paso a Producción

Semanas antes de finalizar el periodo de prueba piloto en la biblioteca de la escuela, se concertó la última reunión. En este caso los asistentes no son el personal bibliotecario sino los encargados de su implantación final en los SSCC y jefes de sección del resto de bibliotecas.

14 de mayo de 2014

Durante esta reunión se presentó la funcionalidad de la aplicación y los resultados obtenidos durante las pruebas de aceptación. Además se hizo entrega del código a los responsables de su paso a producción en los servidores de los SSCC. También se hizo entrega de los manuales y documentación de la aplicación.

En cuanto al paso a producción final, ya se expuso en los inicios de ese documento que no es un objetivo. Y como fue acordado se encargarán de ello el personal de la Sección de Informática de la BUS, siendo la labor del autor la de asesor.

15 de septiembre de 2014

La aplicación entró en producción durante el inicio de este curso 2014-2015. Desde la siguiente dirección: https://bib2.us.es/reserva_salas/ se puede acceder al menú de selección de centro para realizar la reserva, cada una con una oferta diferente gestionada por sus responsables. Siendo un éxito su implantación y formación de usuarios.


96

96

97

9 CONCLUSIONES Y TRABAJO FUTURO

n el último capítulo, se abordarán las conclusiones finales que se pueden extraer del proyecto ya terminado y una vez comprobada su implantación total en todos los centros, así como intentar identificar posibles modificaciones que mejorasen el servicio final ofrecido.

9.1 Conclusiones

Tras la finalización del proyecto se puede ver que se han cumplido con los requisitos demandados en un inicio y algunos añadidos durante la etapa final. Una aplicación que permite a cada centro gestionar la oferta de su servicio de reserva de salas de trabajo y diversos espacios, librando de esta tarea a usuarios que no pertenecían al centro. Todos estos cambios han repercutido en una mejora del servicio, se ha agilizado su gestión, se ha añadido un sistema de sanciones para usuarios que no respeten las normas. Se ha proporcionado además un demandado módulo para obtener estadísticas precisas del servicio. Por lo que ha sido mejorado considerablemente.

El desarrollo, llevado a cabo en tecnologías tan comunes y extendidas como HTML, PHP y JavaScript y otra que en este momento goza de gran popularidad y funcionalidad como Bootstrap, permiten en un determinado momento poder avanzar en el proyecto y mejorarlo añadiendo más funcionalidades sin necesitar de un periodo de aprendizaje extenso.

Por último cabe destacar la gran acogida que ha recibido la aplicación, tanto por el personal bibliotecario como por los peticionarios. Ambos grupos han visto cumplidas varias demandas que habían realizado. Sobre todo al sistema de sanciones, gracias al cual el mal uso de las salas (ya sea por no comparecer a recoger la llave o por no cuidar los espacios) ha disminuido radicalmente. Los usuarios se sienten más responsables y el personal de la biblioteca lo agradece significativamente.

En cuanto al personal de biblioteca, cabe destacar la aceptación recibida por su sencillez y usabilidad, alabada por los diferentes jefes de sección de cada centro y de la dirección de la BUS. También nombrar a la SI de los SSCC, que la ha recibido muy satisfactoriamente, tanto por su sencillez de implantación, rapidez de aprendizaje y dinamismo. Además apenas ha sido requerida por parte de la SI la participación del autor en labores de mantenimeinto.

Para finalizar, nombrar que en lo que se lleva de curso, se han producido cerca de 70.000 reservas, por más de 20.000 usuarios distintos, lo que demuestra la gran aceptación del sistema.

E

-

Conclusiones y Trabajo Futuro

98

98

9.2 Trabajo Futuro

Existen varios puntos donde el proyecto puede avanzar para ofrecer un sistema más completo si cabe y algunas mejoras que respondería a algunas peticiones por parte de los alumnos. Se enumeran a continuación estas líneas de mejora:

• Cambiar de OpenSSO a otro protocolo de acceso: Durante los meses posteriores a la implantación general del sistema se ha desaconsejado (Aunque no atañe más problemas que la falta de actualización) el uso de este sistema de conexión SSO, y se aconseja cambiar a CAS o SALM para aplicaciones diseñadas en PHP. Este sería uno de los puntos más importantes a abordar.

• Estadísticas de sanciones: Desde la dirección de la biblioteca, se comenta que sería una opción interesante para las estadísticas de la BUS sacar información acerca de las sanciones que se producen (campus con más sanciones, fechas, etc.).

• Sistema que permita consultar salas libres por campus: Algunos alumnos han planteado la posibilidad de un módulo que agrupe los centros según el campus donde se sitúan. Y poder consultar si hay salas disponibles en esa zona, consultarlas y realizar la reserva.

Esta mejora ayudaría a presentar el servicio de forma más global, y solo sería necesario añadir un atributo más a las bibliotecas, el campus al que pertenecen. Y realizar búsquedas conjuntas.

• Aplicación para smartphones: Aprovechando el diseño basado en Bootstrap que permite un diseño responsivo, sería relativamente sencillo crear una app basada en HTML5 que se conectase a las páginas de las bibliotecas, añadiendo una nueva capa de presentación. Una manera más rápida y accesible a la aplicación.

99

GLOSARIO 3NF: Third Normal Form 55

AICIA: Asociación de Investigación y Cooperación Industrial de Andalucía 1

BBDD: Base de Datos 28

BUS: Biblioteca de la Universidad de Sevilla 2

DDL: Data Definition Language 80

DML: Data Manipulation Language 80

HTML: HyperText Markup Language 6

NAS: Network-Attached Storage 65

PHP: PHP Hypertext Pre-processor 5

POO: Programación Orientada a Objetos 46

SGBD: Sistema Gestor de Bases de Datos 9

SI: Sección de Informática de los SSCC 23

SIC: Servicio de Informática y Comunicaciones de la US 7

SLA: Service Level Agreement 89

SQL: Structured Query Language 31

SSCC: Servicios Centrales de la Biblioteca de la US 1

SSO: Single Sing-On 7

UML: Unified Modeling Language™ 46

URL: Uniform Resource Locator 85

UVUS: Usuario Virtual de la Universidad de Sevilla 8

Glosario

100

100

101

BIBLIOGRAFÍA

[1] Ministerio de Hacienda y Administraciones Públicas 2012, 2001-last update, Métrica v.3. [En línea] Available: http://administracionelectronica.gob.es/pae_Home/pae_Documentacion/pae_Metodolog/pae_Metrica_v3.html#.VO8rluH0chR.

[2] Gómez Fernández, L. & Andrés Álvarez, A. 2012, Guía de aplicación de la Norma UNE-ISOIEC 27001 sobre seguridad en sistemas de información para pymes, 2a edn, Aenor, Madrid.

[3] The Apache Software Foundation 2015, The Apache Software Foundation. [En línea] Available: http://www.apache.org/ [2013].

[4] Coar, K. & Bowen, R. 2008, Apache, Anaya Multimedia, Madrid.

[5] Oracle Corporation 2015, , MySQL. [En línea] Available: http://www.mysql.com/ [2013, .

[6] Bell, C.A., Kindahl, M. & Thalmann, L. 2014, MySQL high availability :[Tools for Building Robust Data Centers], 2nd edn, O'Reilly, Sebastopol, CA.

[7] Gilmore, W.J. 2010, Beginning PHP and MySQL, Fourth Edition edn, Apress, Berkeley, CA.

[8] The PHP Group 2015, 19 Feb 2015-last update, PHP: Hypertext Prepocessor. [En línea] Available: http://php.net/ [2013].

[9] Mitchell, L.J. 2013, PHP web services, O'Reilly Media, Sebastopol, Calif.

[10] Fogus, M. 2013, Functional JavaScript, O'Reilly Media, Sebastopol, CA.

[11] Mark Otto, J.T. 2015, 2015-last update, Bootstrap main page. [En línea] Available: http://getbootstrap.com/ [2013].

[12] Spurlock, J. 2013, Bootstrap, O'Reilly Media, Sebastopol, CA.

[13] Michal Čihař 2015, 2015-last update, phpMyAdmin. [En línea] Available: http://www.phpMyAdmin.net/home_page/index.php [2013].

[14] Oracle Corporation 2015 , NetBeans official page. [En línea] Available: https://netbeans.org/ [2013].

[15] Universidad de Sevilla 2015, 2015-last update, Single Sign-On de la Universidad de Sevilla. [En línea] Available: https://sso.us.es/integracion/ [2013].

Bibliografía

102

102

103

ANEXOS

Anexo I: Arbol de directorios de la aplicación

reserva_salas: /* Directorio principal */

│ .htaccess /* Archivo de configuración de acceso */

│ index.php /* Index de la aplicación donde se construye la int erfaz */

│

├───privado /* Directorio con el código, inaccesible desde fuer a*/

│ │ body_admin.php /* Espacio de trabajo del administrador */

│ │ body_revisor.php /* Espacio de trabajo del revisor */

│ │ body_sadmin.php /* Espacio de trabajo del superadministrador */

│ │ body_user.php /* Espacio de trabajo de un peticionario */

│ │ error.php /* Página de error para adminsitradores/revisores * /

│ │ error_sadmin.php /* Página de error para superadminsitrador */

│ │ error_user.php /* Página de error para peticionarios */

│ │ head.php /* Head HTML de la página, incluye .css y .js */

│ │

│ ├───basico /* Back-end de la aplicación, con las funciones y c osntantes*/

│ │ definiciones.php /* Definición de las constantes */

│ │ funciones.php /* Funciones de la aplicación, manejo de datos, etc .*/

│ │ fun_estadisticas.php /* Funciones para el apartado de estadísticas*/

│ │ peticiones.php /* Archivo principal de peticiones*/

│ │ peticiones_admin.php /* Se extrae la petición, administradores */

│ │ peticiones_revisor.php /* Se extrae la petición, revisores */

│ │ peticiones_sadmin.php /* Se extrae la petición, superadminsitrador*/

│ │ peticiones_user.php /* Se extrare la peticíon peticionarios */

│ │ sql_tablas.php /* Sentencias SQL para tablas de bibliotecas */

│ │

│ ├───bibliotecas /* Directorio módulo/Front-end bibliotecas */

│ │ biblioteca.php /* Interfaz de creación de bibliotecas*/

│ │ conf_eliminar.php /* Interfaz de confirmación de eliminar */

│ │ editar.php /* Interfaz de edición*/

│ │ listar.php /* Interfaz de listado */

│ │

│ │

Anexos

104

104

│ ├───configuracion /* Directorio módulo/configuración y usuarios*/

│ │ ├───administrador /* Directorio Front-end administrador */

│ │ │ administrador.php /* Interfaz de gestión y listado*/

│ │ │ administrador_todos.php /* Listado de todos los centros */

│ │ │

│ │ ├───festivos /* Directorio Front-end festivos y cerrados*/

│ │ │ festivos.php /* Interfaz de listado y gestión */

│ │ │

│ │ ├───preferencias /* Directorio Front-end preferencias */

│ │ │ editar.php /* Interfaz de edición*/

│ │ │ preferencias.php /* Interfaz de listado*/

│ │ │

│ │ ├───revisor /* Directorio Front-end revisor */

│ │ │ revisor.php /* Interfaz de gestión y listado*/

│ │ │

│ │ └───superadmin /* Directorio Front-end superadministrador */

│ │ superadmin.php /* Interfaz de gestión y listado*/

│ │

│ ├───estadisticas /* Directorio Front-end estadísticas */

│ │ reservas.php /* Interfaz con las estadísticas calculadas*/

│ │

│ ├───plantillas /* Plantillas de noticicaciones */

│ │ mail_cancelar.php /* Notificación de cancelación */

│ │ mail_cancelar_admin.php /* Not. De cancelación por revisor/admin */

│ │ mail_reserva.php /* Not. De reserva */

│ │ mail_responsable.php /* Not. De petición de reserva a responsable */

│ │ mail_sancion.php /* Not. De sanción */

│ │ mail_solicitud.php /* Not. De solicitud aceptada */

│ │ mail_solicitud_den.php /* Not. De solicitud denegada */

│ │

│ ├───reservas /* Directorio módulo/Front-end gestión de reservas */

│ │ buscar.php /* Interfaz para búsqueda de reservas */

│ │ calendario.php /* Cuadrante de reservas para admin./revisores */

│ │ calendario_modo_user.php /* Cuadrante modo usuario para revisores */

│ │ calendario_user.php /* Cuadrante de reservas para peticionarios */

│ │ cancelar.php /* Interfaz de cancelación*/

│ │ conf_cancelar.php /* Interfaz de confirmación de cancelación*/

│ │ conf_cerrar.php /* Interfaz de confirmación de cierre de sala*/

│ │ conf_reserva.php /* Interfaz de confirmación de reserva */

│ │ conf_responsable.php /* Interfaz de confirmación para responsable*/


│ │ info.php /* Interfaz de información sobre una reserva*/

│ │ listar.php /* Interfaz de listado de reservas */

│ │ menu.php /* Menú superior de aplicación para revisores/admin .*/

│ │ menu_modo_user.php /* Menú de aplicación para peticionarios */

│ │ menu_user.php /* Menú en modo peticionario para revisores */

│ │ reservar.php /* Interfaz para reservar una sala */

│ │ reservas_masivas.php /* Interfaz de reservas masivas*/

│ │ sancionar.php /* Interfaz para sancionar usuario*/

│ │ turno_libre_mes.php /* Cuadrante mensual sala de turno libre*/

│ │

│ ├───salas /* Directorio módulo/Front-end gestión de salas*/

│ │ conf_eliminar.php /* Interfaz para confirmar eliminar sala*/

│ │ conf_eliminar_tipo.php /* Interfaz para conf.eliminar tipo de sala*/

│ │ editar.php /* Interfaz para editar datos de una sala*/

│ │ editar_tipo.php /* Interfaz para editar datos de un tipo de sala*/

│ │ listar.php /* Interfaz de listado de salas*/

│ │ listar_tipos.php /* Interfaz de listado de tipos de sala */

│ │ salas.php /* Interfaz para crear nuevas salas */

│ │ tipos.php /* Interfaz para crear nuevos tipos */

│ │

│ ├───sanciones /* Directorio Front-end sanciones */

│ │ listar.php /* Interfaz de listado de sanciones de una bibliote ca*/

│ │ listar_todos.php /* Interfaz de sanciones de todas las biliotecas*/

│ │

│ └───turnos /* Directorio módulo/Front-end gestión de turnos */

│ configuracion.php /* Interfaz para configurar un grupo de turnos */

│ conf_eliminar.php /* Interfaz para confirmar eliminar un grupo*/

│ disposicion.php /* Interfaz para cuadrar la disposición de turnos * /

│ editar.php /* Interfaz de edición */

│ listar.php /* Interfaz de listados*/

│ turnos.php /* Interfaz para crear nuevo grupo y turnos*/

│ validarturnos.php /* Archivo que valida la disposición de turnos */

│

├───publico /* Directorio con archivos accesibles */

│ ├───css /* Hojas de estilo de la aplicación */

│ ├───img /* Imagenes e iconos usados en la aplicación */

│ └───js /* Archivos y funciones JavaScript */

└───vendor /* Directorio con la programación de acceso SSO */

Anexos

106

106


Anexo II: Código Back-end funciones DDL, DML y gest ión de estadísticas

/****************** MANEJO DE URL PARA PETICIONES ******************/

function get_url() {

$parametros = array();

$url = parse_url(substr($_SERVER['REQUEST_URI'], 1));

$i = 0;

foreach (explode("/", $url['path']) as $p) {

$parametros[$i] = corrige_slash(urldecode($p));

$i++;

}

return $parametros;

}

function corrige_slash($texto) {

$texto = str_replace('%252F', '%2F', $texto);


return $texto;

}

function crea_slash($texto) {



return $texto;

}

/****************** MANEJO DE BASE DE DATOS ******************/

// Creación de una nueva conexión a la base de datos.

function db_connect() {

$resultado = false;

// Conexión con el servidor bbdd

$conn = mysql_connect(SERVIDOR_BBDD, USUARIO_BBDD, CLAVE_BBDD);

// Selección de bbdd

if ($conn != false)

$resultado = mysql_select_db(NOMBRE_BBDD);

// Si todas las operaciones terminaron satisfactoriamente, devolver recurso.

if ($resultado)

$resultado = $conn;

return $resultado;

}

Anexos

108

108

// Cierre de una conexión a la base de datos ($conn)

function db_close($conn) {

return mysql_close($conn);

}

function db_query($sentencia_sql, $sentencia_insert = FALSE) {

$idx = mysql_query($sentencia_sql);

if ($sentencia_insert && $idx) {

$idx = mysql_insert_id();

}

return $idx;

}

// Devuelve el número de resultados obtenidos en la última sentencia select ejecutada (ojo: sólo si se incluyó

"SELECT SQL_CALC_FOUND_ROWS * FROM..."

function db_num_results($bib_siglas) {

$idx = mysql_fetch_row(mysql_query("SELECT COUNT(reserva_id) FROM `".$bib_siglas."_reservas`"));

return $idx[0];

}

// Devuelve el número de resultados producido por query_proy (entero)

function db_query_num_results($idx) {

return mysql_num_rows($idx);

}

function db_listar_bibliotecas_uvus($uvus, $rol) {

$sentencia_sql = "SELECT bibliotecas.* FROM `$rol`,`bibliotecas` WHERE $rol.bib_id = bibliotecas.bib_id AND

uvus = '$uvus'";

$resultado_sql = db_query($sentencia_sql);

while ($row = mysql_fetch_array($resultado_sql)) {

$resultado[] = $row;

}

return $resultado;

}

function db_datos_biblioteca($uvus,$dato, $rol) {

$sentencia_sql = "SELECT bibliotecas.* FROM `$rol`,`bibliotecas` WHERE $rol.bib_id = bibliotecas.bib_id AND

uvus = '" . $uvus . "' LIMIT 1";

$resultado_sql = mysql_fetch_array(db_query($sentencia_sql));

return $resultado_sql[$dato];

}

function db_datos_biblioteca_siglas($siglas,$dato) {


$sentencia_sql = "SELECT bibliotecas.* FROM `bibliotecas` WHERE siglas = '" . $siglas . "'";


return $resultado_sql[$dato];

}

function db_user_is_sadmin($uvus) {

$sentencia_sql = "SELECT EXISTS(SELECT 1 FROM `super_administrador` WHERE uvus = '" . $uvus . "' LIMIT 1)";


return $resultado_sql[0];

}

function db_user_is_admin($uvus) {

$sentencia_sql = "SELECT EXISTS(SELECT 1 FROM àdministrador` WHERE uvus = '" . $uvus . "' LIMIT 1)";



}

function db_user_is_revisor($uvus) {

$sentencia_sql = "SELECT EXISTS(SELECT 1 FROM `revisor` WHERE uvus = '" . $uvus . "' LIMIT 1)";



}

function db_user_sancionado($uvus) {

$sentencia_sql = "SELECT EXISTS(SELECT 1 FROM `sanciones` WHERE uvus = '" . $uvus . "' AND fin >= '".date('Y-

m-d')."' LIMIT 1)";



}

/****************** INSERCIONES DE DATOS ******************/

function db_insertar_biblioteca($siglas,$nombre, $administrador, $correo){

require_once('./privado/basico/sql_tablas.php');

echo $sql_tablas; //recojemos un array con las sql usadas para crear las tablas

$idx=1;

for($i=0; $i < count($create_tables) && $idx; $i++){

$idx = db_query($create_tables[$i]);

}

//solo insertamos la biblioteca si todas las tablas se han creado

if($idx){

$sentencia = "INSERT INTO `bibliotecas`

(`siglas`,`nombre_biblioteca`,àpertura`,`cierre`,àpertura_fs`,`cierre_fs`) VALUES (";

$sentencia.="'$siglas',";

$sentencia.="'$nombre',";

$sentencia.="'08:00',";

Anexos

110

110

$sentencia.="'21:00',";

$sentencia.="'09:00',";

$sentencia.="'20:00')";

$idx = db_query($sentencia);

if($idx){

$bib_id = db_datos_biblioteca_siglas($siglas, 'bib_id');

$idx = db_insertar_administrador($administrador, $bib_id);

$pref = db_listar_preferencia($bib_siglas, "email_remitente");

$idx = db_actualizar_preferencia($siglas, $pref['pref_id'], $correo);

}

}

return $idx;

}

function db_insertar_sala($bib_siglas, $nombre, $numeracion, $tipo, $capacidad, $activa, $grupo) {

$sentencia = "INSERT INTO `".$bib_siglas."_salas";

$sentencia.= "` (`tipo_id`,`grupo_id`,`nombre_sala`, `num_sala`, `capacidad`,àctiva`) VALUES (";

$sentencia.="'$tipo',";

$sentencia.="$grupo,";


$sentencia.="$numeracion,";

$sentencia.="$capacidad,";

$sentencia.="'$activa')";


return $idx;

}

function db_insertar_tipo_sala($bib_siglas, $nombre, $descripcion, $autorizacion, $uvus, $email, $dias_ant,

$turno_libre, $min_turno, $av, $pregunta) {

$sentencia = "INSERT INTO `".$bib_siglas."_tipo_salas";

$sentencia.= "` (`nombre_tipo`,`descripcion`,àutorizar`,ùvus_responsable`, `dias_antelacion`,

èmail_responsable`,`turno_libre`,`min_turno`,àv`,`pregunta_av`) VALUES (";


$sentencia.="'$descripcion',";

$sentencia.="'$autorizacion',";

$sentencia.="'$uvus',";

$sentencia.="'$dias_ant',";

$sentencia.="'$email',";

$sentencia.="$turno_libre,";

$sentencia.="$min_turno,";

$sentencia.="$av,";

$sentencia.="'$pregunta_av')";


return $idx;


}

function db_insertar_turno($bib_siglas, $grupo, $inicio, $fin, $activo, $activo_fs) {

$sentencia = "INSERT INTO `".$bib_siglas."_turnos` (`grupo`,ìnicio`,`fin`,àctivo`,àctivo_fs`) VALUES (";

$sentencia.="$grupo,'$inicio','$fin',$activo,$activo_fs)";


return $idx;

}

// Insertar reserva normal

function db_insertar_reserva($bib_siglas, $sala_id, $turno_id, $fecha_reserva ,$fecha_peticion, $uvus, $nombre,

$correo, $titulacion, $motivo, $max_reservas){

$num_reservas = db_consultar_num_reserva_user($bib_siglas, $fecha_reserva, $uvus);

if($uvus!= '' && $nombre !=''){

if(($max_reservas-$num_reservas) > 0){

$sentencia = "INSERT INTO `".$bib_siglas."_reservas`";

$sentencia.= " (`sala_id`,`turno_id`,`fecha_reserva`,`fecha_peticion`,ùvus`, `nombre`, `correo`,`titulacion`,

`turno_libre`) VALUES (";

$sentencia.="$sala_id,";

$sentencia.="$turno_id,";

$sentencia.="'".fecha_eeuu($fecha_reserva)."',";

$sentencia.="'$fecha_peticion',";



$sentencia.="'$correo',";

$sentencia.="'$titulacion',";

$sentencia.="'0')";

$resultado_sql = db_query($sentencia);

}

}

return $resultado_sql;

}

//Insertar reserva con responsable pero turnos normales

function db_insertar_reserva_res($bib_siglas, $sala_id, $turno_id, $fecha_reserva ,$fecha_peticion, $uvus,

$nombre, $correo, $titulacion, $motivo, $av, $num_personas){

if($uvus!= '' && $nombre !=''){


$sentencia.= " (`sala_id`,`turno_id`,`fecha_reserva`,`fecha_peticion`,ùvus`, `nombre`, `correo`,`titulacion`,àv`,

`num_personas`, `motivo`, àctiva` ) VALUES (";






Anexos

112

112




$sentencia.="$av,";

$sentencia.="$num_personas,";

$sentencia.="'$motivo',";

$sentencia.="0)";


}


}

//Insertar reserva con responsable y turno libre, en estos casos se reserva el el turno_id = 0

function db_insertar_reserva_turno_libre($bib_siglas, $sala_id, $turno_id, $fecha_reserva ,$fecha_peticion,

$uvus, $nombre, $correo, $titulacion, $motivo, $turno_libre, $av, $num_personas){

//Cuando queremos cerrar estas salas con turnos libres, lo que hacemos es una reserva al nombre de cerrada

if($nombre != 'Cerrada')

$activa=0;

else

$activa=1;

if($uvus!= '' && $nombre !=''){


$sentencia.= " (`sala_id`,`turno_id`,`fecha_reserva`,`fecha_peticion`,ùvus`, `nombre`, `correo`,`titulacion`,

`motivo`,`turno_libre`,àv`, `num_personas`,àctiva` ) VALUES (";










$sentencia.="'$turno_libre',";

$sentencia.="$av,";

$sentencia.="$num_personas,";

$sentencia.="$activa)";

}



}

function db_sancionar_uvus($bib_ID, $uvus, $correo, $fin, $motivo, $uvus_sanc){

if($correo){


$sentencia = "INSERT INTO `sanciones`";

$sentencia.= " (`bib_id`,ùvus`,`correo`,`fecha`,`fin`,`motivo`, ùvus_sanc` ) VALUES (";

$sentencia.="$bib_ID,";



$sentencia.="'".date("Y-m-d H:i:s")."',";

$sentencia.="'".fecha_eeuu($fin)."',";


$sentencia.="'$uvus_sanc')";


}


}

/****************** UPDATES ******************/

function db_actualizar_bib($id, $apertura, $cierre, $apertura_fs, $cierre_fs, $nturnos, $domingo) {

$sentencia = "UPDATE `bibliotecas` ";

$sentencia.="SET àpertura` = '" . $apertura . "' ,";

$sentencia.="`cierre` = '" . $cierre . "' ,";

$sentencia.="àpertura_fs` = '" . $apertura_fs . "' ,";

$sentencia.="`cierre_fs` = '" . $cierre_fs . "' ,";

$sentencia.="`num_turnos` = " . $nturnos . " ,";

$sentencia.="`domingo` = " . $domingo . " ";

$sentencia.=" WHERE bib_id = " . (int) $id . " LIMIT 1";


return $idx;

}

function db_actualizar_bib_nombre($id, $nombre) {

$sentencia = "UPDATE `bibliotecas` ";

$sentencia.="SET `nombre_biblioteca` = '" . $nombre . "' ";

$sentencia.=" WHERE bib_id = " . (int) $id . " LIMIT 1";


return $idx;

}

function db_actualizar_sala($bib_siglas,$id , $nombre, $numeracion, $tipo, $capacidad, $activa, $grupo) {

$sentencia = "UPDATE `".$bib_siglas."_salas` ";

$sentencia.="SET `nombre_sala` = '" . $nombre . "' ,";

$sentencia.="`num_sala` = '" . $numeracion . "' ,";

$sentencia.="`tipo_id` = $tipo,";

$sentencia.="`grupo_id` = $grupo,";

$sentencia.="`capacidad` = " . $capacidad . " ,";

$sentencia.="àctiva` = " . $activa . " ";

$sentencia.=" WHERE `sala_id` = " . (int) $id . " LIMIT 1";

Anexos

114

114


return $idx;

}

function db_actualizar_estado_sala($bib_siglas,$id, $activa) {

$sentencia = "UPDATE `".$bib_siglas."_salas` ";

$sentencia.="SET activa = " . $activa . " ";

$sentencia.=" WHERE sala_id = " . (int) $id . " LIMIT 1";


return $idx;

}

function db_actualizar_estado_grupo($bib_siglas,$id, $activo) {

$sentencia = "UPDATE `".$bib_siglas."_grupo_turnos` ";

$sentencia.="SET activo = " . $activo . " ";

$sentencia.=" WHERE grupo_id = " . (int) $id ;


return $idx;

}

function db_actualizar_tipo_sala($bib_siglas,$id , $nombre, $autorizar, $uvus, $responsable, $descripcion,

$dias_ant, $turno_libre, $min_turno, $av, $pregunta) {

$sentencia =" UPDATE `".$bib_siglas."_tipo_salas` ";

$sentencia.=" SET `nombre_tipo` = '" . $nombre . "' ,";

$sentencia.="àutorizar` = " . $autorizar . " ,";

$sentencia.="ùvus_responsable` = '" . $uvus . "' ,";

$sentencia.="èmail_responsable` = '" . $responsable . "' ,";

$sentencia.="`descripcion` = '" . $descripcion . "' ,";

$sentencia.="`dias_antelacion` = " . $dias_ant . " ,";

$sentencia.="àv` = " . $av . " ,";

$sentencia.="`pregunta_av` = '" . $pregunta . "' ,";

$sentencia.="`turno_libre` = " . $turno_libre . " ,";

$sentencia.="`min_turno` = '" . $min_turno . "' ";

$sentencia.=" WHERE `tipo_id` = " . (int) $id . " LIMIT 1";


return $idx;

}

function db_actualizar_preferencia($bib_siglas, $id, $valor) {

$sentencia = "UPDATE `".$bib_siglas."_preferencias` ";

$sentencia.="SET `valor` = '" . $valor . "' ";

$sentencia.=" WHERE `pref_id` = " . (int) $id . " LIMIT 1";


return $idx;

}


function db_actualizar_turno($bib_siglas, $id, $inicio, $fin, $activo, $activo_fs) {

$sentencia = "UPDATE `".$bib_siglas."_turnos` ";

$sentencia.= "SET ìnicio` = '" . $inicio . "', ";

$sentencia.= "`fin` = '" . $fin . "', ";

$sentencia.= "àctivo` = " . $activo . ", ";

$sentencia.= "àctivo_fs` = " . $activo_fs . " ";

$sentencia.= "WHERE `turno_id` = " . (int) $id ;


return $idx;

}

function db_cancelar_reserva($bib_siglas, $id){

$sentencia = "DELETE FROM `".$bib_siglas."_reservas` WHERE ";

$sentencia.="`reserva_id` = " . $id;


return $idx;

}

//Cancela las próximas reservas de un usuario que acaba de ser sancionado

function db_cancelar_reserva_sanc($bib_siglas, $fecha, $uvus){

$sentencia = "DELETE FROM `".$bib_siglas."_reservas` WHERE ";

$sentencia.="`fecha_reserva` >= '$fecha' AND uvus = '$uvus'";


return $idx;

}

//Cancela varias reservas en una sala con responsable

function db_cancelar_reservas_varias($bib_siglas, $fecha, $sala_id, $uvus ){

$sentencia = "DELETE FROM `".$bib_siglas."_reservas` WHERE sala_id = " . $sala_id. " AND uvus = '" .$uvus. "'

AND fecha_reserva = '" .$fecha."'";


return $idx;

}

function db_confirmar_reserva($bib_siglas, $id){

$sentencia = "UPDATE `".$bib_siglas."_reservas` ";

$sentencia.="SET activa = 1 WHERE reserva_id = " . (int) $id . " LIMIT 1";


return $idx;

}

//Confirma varias reservas en una sala con responsable

function db_confirmar_reservas_varias($bib_siglas, $fecha, $sala_id, $uvus ){

$sentencia = "UPDATE `".$bib_siglas."_reservas` ";

$sentencia.=" SET activa = 1 ";

Anexos

116

116

$sentencia.=" WHERE sala_id = " . $sala_id. " AND uvus = '" .$uvus. "' AND fecha_reserva = '" .$fecha."'";


return $idx;

}

/****************** LISTADOS ******************/

function db_listar_bibliotecas() {

$sentencia_sql = "SELECT * FROM `bibliotecas` ORDER BY `siglas` ASC";




}

return $resultado;

}

function db_listar_biblioteca($bib_id) {

$sentencia_sql = "SELECT * FROM `bibliotecas` WHERE bib_id = $bib_id";


return mysql_fetch_array($resultado_sql);

}

function db_listar_tipo_sala($bib_siglas) {

$sentencia_sql = "SELECT * FROM `".$bib_siglas."_tipo_salas` ORDER BY `tipo_id` ASC";




}

return $resultado;

}

function db_num_tipos($bib_siglas) {

$sentencia_sql = "SELECT count(*) AS num FROM `".$bib_siglas."_tipo_salas`";

$resultado = mysql_fetch_array(db_query($sentencia_sql));

return $resultado['num'];

}

function db_listar_turnos($bib_siglas, $grupo_id) {

$sentencia_sql = "SELECT * FROM `".$bib_siglas."_turnos` WHERE grupo = $grupo_id ORDER BY turno_id ASC";




}

return $resultado;


}

function db_listar_turnos_activos($bib_siglas) {

$sentencia_sql = "SELECT * FROM `".$bib_siglas."_turnos` WHERE activo=1 ORDER BY turno_id ASC";




}

return $resultado;

}

function db_listar_turno_id($bib_siglas, $id) {

$sentencia_sql = "SELECT * FROM `".$bib_siglas."_turnos` WHERE turno_id = $id LIMIT 1";



}

function db_listar_tipo($bib_siglas, $id) {

$sentencia_sql = "SELECT * FROM `".$bib_siglas."_tipo_salas` WHERE tipo_id = ".$id." LIMIT 1";

$resultado = mysql_fetch_array($db_query($sentencia_sql));

return $resultado;

}

function db_listar_grupos($bib_siglas) {

$sentencia_sql = "SELECT `".$bib_siglas."_grupo_turnos`.*, COUNT(turno_id) AS num, MIN(inicio) AS inicio,

MAX(fin) AS fin FROM `".$bib_siglas."_grupo_turnos`, `".$bib_siglas."_turnos` WHERE

`".$bib_siglas."_grupo_turnos`.grupo_id = `".$bib_siglas."_turnos`.grupo GROUP BY

`".$bib_siglas."_turnos`.grupo";




}

return $resultado;

}

function db_listar_grupo($bib_siglas, $id) {

$sentencia_sql = "SELECT `".$bib_siglas."_grupo_turnos`.*, COUNT(turno_id) AS num, MIN(inicio) AS inicio,

MAX(fin) AS fin FROM `".$bib_siglas."_grupo_turnos`, `".$bib_siglas."_turnos` WHERE

`".$bib_siglas."_grupo_turnos`.grupo_id = `".$bib_siglas."_turnos`.grupo AND

`".$bib_siglas."_grupo_turnos`.grupo_id = $id GROUP BY `".$bib_siglas."_turnos`.grupo";


return $resultado;

}

function db_listar_grupo_letra($bib_siglas, $letra) {

Anexos

118

118

$sentencia_sql = "SELECT * FROM `".$bib_siglas."_grupo_turnos` WHERE letra = '".$letra."' LIMIT 1";


return $resultado;

}

function db_listar_sala($bib_siglas, $id) {

$sentencia_sql = "SELECT * FROM `".$bib_siglas."_salas` WHERE sala_id = ".$id." LIMIT 1";


return $resultado;

}

function db_listar_salas($bib_siglas) {

$sentencia_sql = "SELECT SQL_CALC_FOUND_ROWS ".$bib_siglas."_salas.*,

".$bib_siglas."_tipo_salas.nombre_tipo AS `nombre_tipo`,

".$bib_siglas."_tipo_salas.descripcion AS `descripcion`,

".$bib_siglas."_tipo_salas.uvus_responsable AS `responsable`

FROM `".$bib_siglas."_salas`, `".$bib_siglas."_tipo_salas`

WHERE ".$bib_siglas."_salas.tipo_id = ".$bib_siglas."_tipo_salas.tipo_id

ORDER BY tipo_id ASC, num_sala ASC";




}

return $resultado;

}

function db_listar_salas_activas($bib_siglas) {




".$bib_siglas."_tipo_salas.email_responsable AS `responsable`



AND activa = 1

ORDER BY tipo_id ASC, num_sala ASC";




}

return $resultado;

}

function db_listar_salas_activas_tipo($bib_siglas, $tipo_id) {





".$bib_siglas."_tipo_salas.email_responsable AS `responsable`



AND activa = 1 AND ".$bib_siglas."_tipo_salas.tipo_id=".$tipo_id."

ORDER BY activa DESC, tipo_id ASC";




}

return $resultado;

}

function db_listar_salas_tipo_grupo($bib_siglas, $grupo_id, $tipo_id) {

$sentencia_sql = "SELECT COUNT(*) as num FROM `".$bib_siglas."_salas` WHERE grupo_id = $grupo_id AND

tipo_id = $tipo_id AND activa = 1";


return $resultado_sql['num'];

}

function db_paginar_resultados($bib_siglas, $pagina_a_mostrar = 1, $tamano_pagina) {

$resultado = array();

$num_total_registros = db_num_results($bib_siglas);

$total_paginas = ceil($num_total_registros / $tamano_pagina);

if ($pagina_a_mostrar > $total_paginas)

$pagina_a_mostrar = $total_paginas;

if ($pagina_a_mostrar > 10) {

$paginador_limite_inferior = $pagina_a_mostrar - 5;

$paginador_limite_superior = $pagina_a_mostrar + 5;

} else {

$paginador_limite_inferior = 1;

if ($total_paginas < 10)

$paginador_limite_superior = $total_paginas;

else

$paginador_limite_superior = 10;

}

if ($paginador_limite_superior > $total_paginas){

$paginador_limite_superior = $total_paginas;

}

$limite = ($pagina_a_mostrar * $tamano_pagina) - $tamano_pagina;

Anexos

120

120

$resultado['total_paginas'] = $total_paginas;

$resultado['limite_inferior'] = $paginador_limite_inferior;

$resultado['limite_superior'] = $paginador_limite_superior;

$resultado['limite_sql'] = $limite;

return $resultado;

}

function db_listar_reservas($bib_siglas, $limite = FALSE, $tamano_pagina = FALSE) {

$sentencia_sql = "SELECT SQL_CALC_FOUND_ROWS ".$bib_siglas."_reservas.*, ".$bib_siglas."_reservas.activa

AS actv,

".$bib_siglas."_salas.*,

".$bib_siglas."_turnos.*

FROM `".$bib_siglas."_reservas`, `".$bib_siglas."_salas`, `".$bib_siglas."_turnos`

WHERE ".$bib_siglas."_salas.sala_id = ".$bib_siglas."_reservas.sala_id

AND ".$bib_siglas."_turnos.turno_id = ".$bib_siglas."_reservas.turno_id

ORDER BY fecha_reserva DESC, inicio ASC";

if ($limite || $tamano_pagina) {

$sentencia_sql.=" LIMIT " . $limite . ", " . $tamano_pagina;

}




}

return $resultado;

}

function db_listar_reserva($bib_siglas, $reserva_id) {

$sentencia_sql = "SELECT * FROM `".$bib_siglas."_reservas` WHERE reserva_id = ".$reserva_id;



}

function db_listar_id_reserva($bib_siglas, $sala_id, $turno_id,$fecha_reserva, $fecha_peticion) {

$sentencia_sql = "SELECT reserva_id FROM `".$bib_siglas."_reservas` WHERE sala_id = ".$sala_id." AND

turno_id = ".$turno_id." AND fecha_reserva = '".$fecha_reserva."' AND fecha_peticion = '".$fecha_peticion."'

LIMIT 1";


return $resultado_sql['reserva_id'];

}

function db_listar_sanciones() {

$sentencia_sql = "SELECT `sanciones`.* , `bibliotecas`.nombre_biblioteca FROM `sanciones`, `bibliotecas` WHERE

bibliotecas.bib_id = sanciones.bib_id ORDER BY sancion_id DESC";





}

return $resultado;

}

function db_listar_sancion($uvus) {

$sentencia_sql = "SELECT `sanciones`.* , `bibliotecas`.nombre_biblioteca FROM `sanciones`, `bibliotecas`

WHERE bibliotecas.bib_id = sanciones.bib_id

AND sanciones.uvus = '".$uvus."'

ORDER BY fin DESC LIMIT 1";


return $resultado;

}

function db_listar_sanciones_bib($bib_ID) {


bibliotecas.bib_id = sanciones.bib_id AND sanciones.bib_id = ".$bib_ID." ORDER BY fin DESC";




}

return $resultado;

}

function db_listar_preferencias($bib_siglas) {

$sentencia_sql = "SELECT * FROM `".$bib_siglas."_preferencias` ";




}

return $resultado;

}

function db_listar_preferencia($bib_siglas, $nombre) {

$sentencia_sql = "SELECT * FROM `".$bib_siglas."_preferencias` WHERE nombre = '" . $nombre . "' LIMIT 1";


return $resultado_sql['valor'];

}

function db_listar_preferencia_id($bib_siglas, $id) {

$sentencia_sql = "SELECT * FROM `".$bib_siglas."_preferencias` WHERE pref_id = " . $id . " LIMIT 1";


Anexos

122

122


}

function db_buscar_sanciones($texto, $campo_busqueda) {


bibliotecas.bib_id = sanciones.bib_id AND sanciones.".$campo_busqueda." LIKE '%".$texto."%' ORDER BY fin

DESC";




}

return $resultado;

}

function db_buscar_sanciones_bib($bib_id, $texto, $campo_busqueda) {


bibliotecas.bib_id = sanciones.bib_id AND sanciones.bib_id = ".$bib_id." AND sanciones.".$campo_busqueda."

LIKE '%".$texto."%' ORDER BY fin DESC";




}

return $resultado;

}

function db_listar_sancion_bib($uvus, $bib_ID) {


bibliotecas.bib_id = sanciones.bib_id AND sanciones.bib_id = ".$bib_ID." AND sanciones.uvus = '".$uvus."' ORDER

BY fin DESC LIMIT 1";


return $resultado;

}

/****************** MANEJO DE FESTIVOS O CERRADOS ******************/

function db_insertar_festivo($bib_siglas, $fecha) {

$sentencia = "INSERT INTO `".$bib_siglas."_festivos` ( `fecha` ) VALUES ('$fecha')";


return $idx;

}

function db_insertar_festivo_defecto($bib_siglas) {

$anno = date('Y');

$anno_sig = (int)$anno +1;

$sentencia = "INSERT INTO `".$bib_siglas."_festivos` ( `fecha` ) VALUES ('".$anno."-10-12')";















$sentencia = "INSERT INTO `".$bib_siglas."_festivos` ( `fecha` ) VALUES ('".$anno_sig."-01-01')";






return $idx;

}

function db_eliminar_festivo($bib_siglas, $fecha) {

$sentencia = "DELETE FROM `".$bib_siglas."_festivos` WHERE `fecha` = '" . $fecha."' LIMIT 1";


return $idx;

}

function db_listar_festivos($bib_siglas) {

$fecha = date('Y-m-d');

$sentencia_sql = "SELECT * FROM `".$bib_siglas."_festivos` WHERE fecha like '%".$anno."%' OR fecha like

'%".$anno_sig."%'";




}

return $resultado;

}

function db_listar_festivos_sig($bib_siglas) {

$fecha = date('Y-m-d');

$sentencia_sql = "SELECT * FROM `".$bib_siglas."_festivos` WHERE fecha > '$fecha'";



Anexos

124

124


}

return $resultado;

}

function db_es_festivo($bib_siglas, $fecha) {

$fecha = fecha_eeuu($fecha);

$sentencia_sql = "SELECT count(*) as festivo FROM `".$bib_siglas."_festivos` WHERE fecha = '$fecha'";


return $resultado['festivo'];

}

/****************** GESTIÓN DE USUARIOS ******************/

function db_insertar_sadmin($uvus) {

$sentencia = "INSERT INTO `super_administrador` (ùvus` ) VALUES ('$uvus')";


return $idx;

}

function db_eliminar_sadmin($id) {

if(db_num_sadmin() > 1){

$sentencia = "DELETE FROM `super_administrador` WHERE ";

$sentencia.="ìd`=" . (int) $id;

$sentencia.=" LIMIT 1";

// Se hace la consulta


}

return $idx;

}

function db_listar_sadmin() {

$sentencia_sql = "SELECT * FROM `super_administrador`";




}

return $resultado;

}

function db_num_sadmin() {

$sentencia_sql = "SELECT COUNT(*) AS num FROM `super_administrador`";



}


function db_insertar_administrador($uvus, $bib_id) {

$sentencia = "INSERT INTO àdministrador` ( `bib_id`,ùvus` ) VALUES (".$bib_id.", '$uvus')";


return $idx;

}

function db_eliminar_administrador($id, $bib_ID) {

if(!$bib_ID){

$sentencia = "SELECT bib_id FROM àdministrador` WHERE ìd`=" . (int) $id;

$resultado = mysql_fetch_array(db_query($sentencia));

$bib_ID =$resultado['bib_id'];

}

if(db_num_administradores($bib_ID) > 1){

$sentencia = "DELETE FROM àdministrador` WHERE ìd`=" . (int) $id." LIMIT 1";


}

return $idx;

}

function db_listar_todos_admin() {

$sentencia_sql = "SELECT * FROM àdministrador` ORDER BY bib_id";




}

return $resultado;

}

function db_listar_administradores($bib_ID) {

$sentencia_sql = "SELECT * FROM àdministrador` WHERE bib_id =" .$bib_ID;




}

return $resultado;

}

function db_listar_administrador($bib_ID) {

$sentencia_sql = "SELECT * FROM àdministrador` WHERE bib_id =" .$bib_ID." ORDER BY id ASC LIMIT 1";


return mysql_fetch_array($resultado_sql);

}

Anexos

126

126

function db_num_administradores($bib_ID) {

$sentencia_sql = "SELECT COUNT(*) AS num FROM àdministrador` WHERE bib_id =" .$bib_ID;



}

function db_insertar_revisor($uvus, $bib_id) {

$sentencia = "INSERT INTO `revisor` ( `bib_id`,ùvus` ) VALUES (".$bib_id.", '$uvus')";


return $idx;

}

function db_eliminar_revisor($id) {

$sentencia = "DELETE FROM `revisor` WHERE ìd`=" . (int) $id." LIMIT 1";


return $idx;

}

function db_listar_revisores($bib_ID) {

$sentencia_sql = "SELECT * FROM `revisor` WHERE bib_id =" .$bib_ID;




}

return $resultado;

}

/****************** GESTIÓN DEL ESPACIO DE TRABAJO (CUADRANTE DE RESERVAS)******************/

function db_abrir_sala_fecha($bib_siglas, $id_sala, $fecha){

$turnos = db_listar_turnos_activos($bib_siglas);

foreach($turnos as $turno){

$sentencia_sql = "DELETE FROM `".$bib_siglas."_cerradas` WHERE sala_id =".$id_sala." AND turno_id =

".$turno['turno_id']." AND fecha = '".fecha_eeuu($fecha)."'";


}


}

function db_abrir_turno_fecha($bib_siglas, $id_turno, $fecha){

$salas = db_listar_salas_activas($bib_siglas);

foreach($salas as $sala){

$sentencia_sql = "DELETE FROM `".$bib_siglas."_cerradas` WHERE sala_id =".$sala['sala_id']." AND turno_id =

".$id_turno." AND fecha = '".fecha_eeuu($fecha)."'";

echo $sentencia;



}


}

function db_abrir_sala_turno_fecha($bib_siglas, $cerrada_id){

$sentencia_sql = "DELETE FROM `".$bib_siglas."_cerradas` WHERE cerrada_id =".$cerrada_id;



}

function db_cerrar_sala_fecha($bib_siglas, $id_sala, $fecha_cerrar, $uvus){

$sala = db_listar_sala($bib_siglas, $id_sala);

$turnos = db_listar_turnos($bib_siglas, $sala['grupo_id']);


$reserva = db_consultar_reserva($bib_siglas, $fecha_cerrar, $turno['turno_id'], $id_sala);

if($reserva['reserva_id'])

return true;

}


$sentencia = "INSERT INTO `".$bib_siglas."_cerradas";

$sentencia.= "` (`sala_id`,`turno_id`,ùvus`,`fecha`) VALUES (";

$sentencia.= $id_sala.",";

$sentencia.= $turno['turno_id'].",";

$sentencia.= "'$uvus',";

$sentencia.="'".fecha_eeuu($fecha_cerrar)."')";


}

return false;

}

function db_cerrar_turno_fecha($bib_siglas, $turno_id_cerrar, $fecha_cerrar, $uvus){

$salas = db_listar_salas_activas($bib_siglas);


$reserva = db_consultar_reserva($bib_siglas, $fecha_cerrar, $turno_id_cerrar, $sala['sala_id']);

if($reserva['reserva_id'])

return true;

}




Anexos

128

128

$sentencia.= $sala['sala_id'].",";

$sentencia.="$turno_id_cerrar,";




}

return false;

}

function db_cerrar_sala_turno_fecha($bib_siglas, $id_sala_cerrar, $id_turno_cerrar,$fecha_cerrar, $uvus){



$sentencia.="$id_sala_cerrar,";

$sentencia.="$id_turno_cerrar,";





}

function db_consultar_sala_cerrada($bib_siglas, $sala_id, $fecha){

$sentencia_sql = "SELECT COUNT(cerrada_id) FROM `".$bib_siglas."_cerradas` WHERE sala_id = ".$sala_id." AND

fecha = '".fecha_eeuu($fecha)."'";

$cerradas = mysql_fetch_array(db_query($sentencia_sql));

$sentencia_sql = "SELECT COUNT(turno_id) FROM `".$bib_siglas."_turnos` WHERE activo = 1";

$turnos = mysql_fetch_array(db_query($sentencia_sql));

if(($cerradas[0] - $turnos[0])==0)

return false;

else

return true;

}

function db_cerrar_sala_varios_dias($bib_siglas, $inicio,$fin){

$dini = date('d-m-Y', strtotime($inicio));

$dfin = date('d-m-Y', strtotime($fin));

$dias = floor((strtotime($fin) - strtotime($inicio))/(60*60*24));

for($i=0; $i<= $dias; $i++){

$fecha_cerrar = date('d-m-Y',strtotime($inicio) + $i*(60*60*24));

db_insertar_festivo($bib_siglas, fecha_eeuu($fecha_cerrar));

}

}

/****************** BÚSQUEDAS ******************/


function fecha_reserva_mas_antigua($bib_siglas) {

$sentencia_sql = "SELECT * FROM `".$bib_siglas."_reservas` ORDER BY reserva_id ASC LIMIT 1";


return $resultado_sql['fecha_reserva'];

}

function busqueda_avanzada($bib_siglas, $texto, $campo_busqueda, $orden, $sentido) {

if($campo_busqueda == 'fecha_reserva')

$texto = fecha_eeuu ($texto);

$sentencia_sql = "SELECT SQL_CALC_FOUND_ROWS ".$bib_siglas."_reservas.*,

".$bib_siglas."_salas.nombre_sala AS `nombre_sala`,

".$bib_siglas."_turnos.inicio AS ìnicio`,

".$bib_siglas."_turnos.fin AS `fin`

FROM `".$bib_siglas."_reservas`, `".$bib_siglas."_salas`, `".$bib_siglas."_turnos`

WHERE ".$bib_siglas."_reservas.sala_id = ".$bib_siglas."_salas.sala_id

AND ".$bib_siglas."_reservas.turno_id = ".$bib_siglas."_turnos.turno_id";

$sentencia_sql.=" AND " . $campo_busqueda . " LIKE '%" . $texto . "%'";

$sentencia_sql.=" ORDER BY " . $orden . " " . $sentido . " ";




}

return $resultado;

}

/****************** DELETES ******************/

function db_eliminar_biblioteca($bib_id){

$biblioteca = db_listar_biblioteca($bib_id);

$administradores = db_listar_administradores($bib_id);

$revisores = db_listar_revisores($bib_id);

foreach ($administradores as $admin){

db_eliminar_administrador($admin['id']);

}

foreach ($revisores as $revisor){

db_eliminar_revisor($revisor['id']);

}

$administradores = db_listar_administradores($bib_id);

$revisores = db_listar_revisores($bib_id);

if(!$revisores && !$administradores){

Anexos

130

130

$sentencia = "DELETE FROM `bibliotecas` WHERE bib_id = ".$bib_id;


if($idx){

$sentencia = "DROP TABLE `".$biblioteca['siglas']."_festivos`";


$sentencia = "DROP TABLE `".$biblioteca['siglas']."_preferencias`";


$sentencia = "DROP TABLE `".$biblioteca['siglas']."_cerradas`";

$idx = db_query($sentencia);;

$sentencia = "DROP TABLE `".$biblioteca['siglas']."_reservas`";


$sentencia = "DROP TABLE `".$biblioteca['siglas']."_salas`";


$sentencia = "DROP TABLE `".$biblioteca['siglas']."_tipo_salas`";


$sentencia = "DROP TABLE `".$biblioteca['siglas']."_turnos`";


}

}

}

function db_eliminar_sancion($bib_id, $id) {

$sentencia_sql = "DELETE FROM `sanciones` WHERE sancion_id = ".$id." AND bib_id = ".$bib_id;



}

function db_eliminar_sala($bib_siglas, $id) {

$sentencia_sql = "DELETE FROM `".$bib_siglas."_salas` WHERE sala_id = ".$id." ";



}

function db_eliminar_tipo_sala($bib_siglas, $id) {

$sentencia_sql = "SELECT count(sala_id) AS num FROM `".$bib_siglas."_salas` WHERE tipo_id = ".$id." ";


if(!$resultado_sql['num']){


$sentencia_sql = "DELETE FROM `".$bib_siglas."_tipo_salas`

WHERE tipo_id = ".$id." ";


}


}

function db_eliminar_grupo($bib_siglas, $id) {

if(db_eliminar_turnos($bib_siglas, $id)){

$sentencia_sql = "DELETE FROM `".$bib_siglas."_grupo_turnos` WHERE grupo_id = $id ";


}


}

function db_eliminar_turnos($bib_siglas, $grupo_id) {

$sentencia_sql = "DELETE FROM `".$bib_siglas."_turnos` WHERE grupo = $grupo_id";



}

/****************** CONSULTAS DE DATOS ******************/

function db_consultar_turno_activo($bib_siglas, $turno_id, $dia, $bib_domingo) {

if($dia != 'Sun' && $dia != 'Sat')

$sentencia_sql = "SELECT * FROM `".$bib_siglas."_turnos` WHERE turno_id = ".$turno_id." AND activo=1

ORDER BY turno_id ASC";

elseif ($dia == 'Sat' || ($dia == 'Sun' && $bib_domingo))

$sentencia_sql = "SELECT * FROM `".$bib_siglas."_turnos` WHERE turno_id = ".$turno_id." AND activo_fs=1

ORDER BY turno_id ASC";

else

$sentencia_sql='';

if($sentencia_sql)



}

function db_consultar_reserva($bib_siglas, $fecha, $turno_id, $sala_id) {

$sentencia_sql = "SELECT * FROM `".$bib_siglas."_reservas` WHERE turno_id = ".$turno_id." AND sala_id =

".$sala_id." AND fecha_reserva LIKE '".fecha_eeuu($fecha)."' AND activa = 1 LIMIT 1";



}

Anexos

132

132

function db_consultar_reserva_libre($bib_siglas, $fecha, $turno_id, $sala_id) {

$sentencia_sql = "SELECT * FROM `".$bib_siglas."_reservas` WHERE `turno_id` = 0 AND sala_id = ".$sala_id."

AND fecha_reserva LIKE '".fecha_eeuu($fecha)."'";




}

return $resultado;;

}

function db_consultar_solicitudes($bib_siglas, $fecha, $turno_id, $sala_id) {


".$sala_id." AND fecha_reserva LIKE '".fecha_eeuu($fecha)."' AND activa = 0 LIMIT 1";



}

function db_consultar_solicitudes_libre($bib_siglas, $fecha, $turno_id, $sala_id, $turno_libre) {


".$sala_id." AND fecha_reserva LIKE '".fecha_eeuu($fecha)."' AND turno_libre LIKE '".$turno_libre."' AND activa = 0

LIMIT 1";



}

function db_consultar_reserva_user($bib_siglas, $fecha, $turno_id, $sala_id) {


".$sala_id." AND fecha_reserva LIKE '".fecha_eeuu($fecha)."' LIMIT 1";



}

function db_consultar_num_reserva_user($bib_siglas, $fecha, $uvus) {

$sentencia_sql = "SELECT COUNT(reserva_id) as num_reservas FROM `".$bib_siglas."_reservas` WHERE uvus =

'".$uvus."' AND fecha_reserva = '".fecha_eeuu($fecha)."' AND activa = 1";


return $resultado_sql['num_reservas'];

}

function db_consultar_reserva_id($bib_siglas, $id) {

$sentencia_sql = "SELECT * FROM `".$bib_siglas."_reservas` WHERE reserva_id = ".$id." LIMIT 1";



}


function db_turnos_solicitud($bib_siglas, $fecha, $uvus, $sala){

$sentencia_sql = "SELECT inicio, fin FROM `".$bib_siglas."_reservas`, `".$bib_siglas."_turnos` WHERE

fecha_reserva = '$fecha' AND uvus= '$uvus' AND sala_id = $sala AND `".$bib_siglas."_reservas`.turno_id =

`".$bib_siglas."_turnos`.turno_id ORDER BY `".$bib_siglas."_turnos`.turno_id";




}

return $resultado;

}

function db_consultar_cerrada($bib_siglas, $fecha, $turno_id, $sala_id) {

$sentencia_sql = "SELECT * FROM `".$bib_siglas."_cerradas` WHERE turno_id = ".$turno_id." AND sala_id =

".$sala_id." AND fecha LIKE '".fecha_eeuu($fecha)."' LIMIT 1";



}

function db_consultar_numeracion_tipo($bib_siglas, $tipo_id) {

$sentencia_sql = "SELECT MAX(num_sala) AS ultimo FROM `".$bib_siglas."_salas` WHERE tipo_id = ".$tipo_id;


return $resultado_sql['ultimo'];

}

/****************** MANEJO DE SALAS CON TURNO LIBRE (id_turno=0) ******************/

function db_calcular_divisiones($bib_siglas, $sala_id,$fecha,$min, $bib_apertura, $bib_cierre, $colspan){

$reservas= db_consultar_reserva_libre($bib_siglas, $fecha, 0, $sala_id);

//Se construye una especie de puzle según las reservas y sus horarios y el horario total disponible

$divisiones;

$ult_division;

$apertura = explode(":", $bib_apertura);

$cierre = explode(":", $bib_cierre);

if($reservas){

foreach ($reservas as $reserva){

//Guardamos los datos de cada reserva en una matriz, que luego servirá para representarlas

$horario = explode("/", $reserva['turno_libre']);

$inicio = explode(":", $horario[0]);

$fin = explode(":", $horario[1]);

if(!$ult_division){

$minutos = ((int)($inicio[0]-$apertura[0])* 60) + (int)($inicio[1]-$apertura[1]);

if($minutos > 0){

Anexos

134

134

$division['activa'] = 0;

$division['uvus'] = '';

$division['inicio'] = $bib_apertura;

$division['fin'] = $horario[0];

$division['colspan'] = $minutos/$min; //El span determina cuanto de ancho, mas o menos equivalente

ocupara en la representacion

$ult_division = $division

$divisiones[] = $division;

}

}

else{

$cierre_ant = explode(":", $ult_division['fin']);

$minutos = ((int)($inicio[0]-$cierre_ant[0])* 60) + (int)($inicio[1]-$cierre_ant[1]);

if($minutos > 0){



$division['inicio'] = $ult_division['fin'];


$division['colspan'] = $minutos/$min;

$ult_division = $division;


}

}

$minutos = ((int)($fin[0]-$inicio[0])* 60) + (int)($fin[1]-$inicio[1]);


$division['uvus'] = $reserva['uvus'];

$division['inicio'] = $horario[0];



$division['reserva'] = $reserva;



}

if($ult_division){//para añadir correctamente la última división hay que calcularlo de nuevo

$cierre_ant = explode(":", $ult_division['fin']);

$minutos = ((int)($cierre[0]-$cierre_ant[0])* 60) + (int)($cierre[1]-$cierre_ant[1]);

if($minutos > 0){



$division['inicio'] = $ult_division['fin'];

$division['fin'] = $bib_cierre;





}

}

}

else{

$minutos = ((int)($cierre[0]-$apertura[0])* 60) + (int)($cierre[1]-$apertura[1]);

if($minutos > 0){



$division['inicio'] = $bib_apertura;

$division['fin'] = $bib_cierre;



}

}

return $divisiones;

}

/****************** FÚNCIONES MISCELANEAS PARA TURNOS ******************/

//Las funciones que registran datos de los turnos, trabajan con el post creado dinámicamente por eso deben

recibirlo entero y escanearlo para comprobar el número de turnos

function db_insertar_turnos($my_POST, $bib_siglas){

$inicio='';

$fin='';

$activo='';

$activo_fs='';

$resultado = 1;

$letra = db_grupo_letra_sig($bib_siglas);

$sentencia = "INSERT INTO `".$bib_siglas."_grupo_turnos` (`letra`) VALUES ('$letra')";

$resultado = db_query($sentencia);

$grupo = db_listar_grupo_letra($bib_siglas, $letra);

while ($grupo && ($post = each($my_POST)) && $resultado){

if(strpos($post[0], 'INI'))

$inicio = $post[1];

elseif (strpos($post[0], 'FIN'))

$fin = $post[1];

elseif (strpos($post[0], 'fs_actv'))

$activo_fs = $post[1];

elseif (strpos($post[0], 'actv'))

$activo = $post[1];

if($inicio && $fin && ($activo!='') && ($activo_fs!='')){

Anexos

136

136

$resultado = db_insertar_turno($bib_siglas, $grupo['grupo_id'], $inicio, $fin, $activo, $activo_fs);

$inicio='';

$fin='';

$activo='';

$activo_fs='';

}

}

return $resultado;

}

function db_actualizar_turnos($my_POST, $bib_siglas, $grupo_id){

$turnos = db_listar_turnos($bib_siglas, $grupo_id);

$inicio='';

$fin='';

$activo='';

$activo_fs='';

$resultado = 1;

$i=0;

while (($post = each($my_POST)) && $resultado){

if(strpos($post[0], 'INI'))

$inicio = $post[1];

elseif (strpos($post[0], 'FIN'))

$fin = $post[1];

elseif (strpos($post[0], 'fs_actv'))

$activo_fs = $post[1];

elseif (strpos($post[0], 'actv'))

$activo = $post[1];

if($inicio && $fin && ($activo!='') && ($activo_fs!='')){

$resultado = db_actualizar_turno($bib_siglas, $turnos[$i]['turno_id'], $inicio, $fin, $activo, $activo_fs);

$i++;

$inicio='';

$fin='';

$activo='';

$activo_fs='';

}

}

return $resultado;

}

function db_minutos_turno($bib_apertura,$bib_cierre,$bib_num_turnos){





return $minutos/$bib_num_turnos;

}

function db_calc_turnos_dmin($bib_apertura,$bib_cierre,$bib_dmin){




return ceil($minutos/$bib_dmin);

}

/****************** MISCELÁNEAS PARA FECHAS Y HORAS ******************/

function mostrar_fecha($fecha){

$meses =

array('','Enero','Febero','Marzo','Abril','Mayo','Junio','Julio','Agosto','Septiembre','Octubre','Noviembre','Diciembre'

,'',);

$fecha_aux = explode('-', $fecha);

switch (date('D', mktime (0, 0, 0, $fecha_aux[1], $fecha_aux[0], $fecha_aux[2]))){

case 'Mon': echo 'Lunes, '; break;

case 'Tue': echo 'Martes, '; break;

case 'Wed': echo 'Miércoles, '; break;

case 'Thu': echo 'Jueves, '; break;

case 'Fri': echo 'Viernes, '; break;

case 'Sat': echo 'Sábado, '; break;

case 'Sun': echo 'Domingo, '; break;

}

echo (int)$fecha_aux[0]. ' de ' . $meses[(int)$fecha_aux[1]]. ' de ' .$fecha_aux[2];

}

function obtener_dia($fecha){

$fecha_aux = explode('-', $fecha);

return (date('D', mktime (0, 0, 0, (int)$fecha_aux[1], (int)$fecha_aux[0], (int)$fecha_aux[2])));

}

function obtener_duracion_media($bib_siglas){

$turnos = db_listar_turnos($bib_siglas);

$duracion;

$i=0;

foreach ($turnos as $turno){

$inicio = explode(":", $turno['inicio']);

$fin = explode(":", $turno['fin']);

if($inicio[1]==$fin[1]){

$duracion += ($fin[0]-$inicio[0])*60;

}

elseif($fin[1]>$inicio[1]){

Anexos

138

138

$duracion += ($fin[0]-$inicio[0])*60;

$duracion += ($fin[1]-$inicio[1]);

}

else{

$duracion += ($fin[0]-$inicio[0] - 1)*60;

$duracion += ($fin[1]-$inicio[1]);

}

$i++;

}

$duracion = $duracion / $i;

return $duracion;

}

//Comrpueba si la sancion esta aun vegente

function sancion_activa($fecha){

if(strtotime($fecha) - strtotime(date('Y-m-d')) >= 0)

return true;

else

return false;

}

//pasar fecha a formato europeo

function fecha_eurp($fecha){

return date("d-m-Y",strtotime($fecha));

}

//pasar fechha a formato americano

function fecha_eeuu($fecha){

return date("Y-m-d",strtotime($fecha));

}

//Cambia las hora mostrada en los turnos (primero y final) en los finas de semana

function cambio_horario_fs($turno, $apertura_fs, $cierre_fs){

if( $turno['activo_fs']){

$apertura = explode(":", $apertura_fs);

$cierre = explode(":", $cierre_fs);

$turno_incio = explode(":", $turno['inicio']);

$turno_fin = explode(":", $turno['fin']);

if($turno_fin[0] < $apertura[0]){

$turno['activo_fs'] = 0;

}

elseif(($turno_fin[0] == $apertura[0]) && ($turno_fin[1] <= $apertura[1])){



}

if($turno_incio[0] >= $cierre[0]){


}elseif(($turno_fin[0] - $cierre[0]) == 1 && ($cierre[1] - $turno_incio[1])< 0){


}

if( $turno['activo_fs']){

if($apertura[0] > $turno_incio[0]){

$turno['inicio'] = $apertura_fs;

}

elseif(($apertura[0] == $turno_incio[0]) && ($apertura[1] > $turno_incio[1])){

$turno['inicio'] = $apertura_fs;

}

if($cierre[0] < $turno_fin[0]){

$turno['fin'] = $cierre_fs;

}

elseif(($cierre[0] == $turno_fin[0]) && ($cierre[1] < $turno_fin[1])){


}elseif(($turno_fin[0] - $cierre[0]) == -1 && ($cierre[1] - $turno_incio[1]) < 0){


}

}

}

return $turno;

}

//Calcular la letra a asignar al siguiente grupo, se supone que nunca habrán mas de 27 grupos

function db_grupo_letra_sig($bib_siglas) {

$sentencia_sql = "SELECT COUNT(grupo_id) AS num FROM `".$bib_siglas."_grupo_turnos`";


$letra = range('A','Z');

$step=(int)$resultado_sql['num'];

return $letra[$step];

}

//Devuelve si el turno esa pasado de hora y no se puede reservar

function turno_pasado($hora, $turno_fin, $fecha){

$hora = explode(":", $hora);

$turno_fin = explode(":", $turno_fin);

if($fecha == date('d-m-Y')){

Anexos

140

140

if($hora[0] > $turno_fin[0]){

$turno_pasado = 1;

}

else if($hora[0] == $turno_fin[0]){

if($hora[1] >= $turno_fin[1]){

$turno_pasado = true;

}

}

}

return $turno_pasado;

}

//Devuelve si la hora de cancelación ha pasado

function cancelacion_pasada($hora, $turno_inicio, $fecha){

$hora = explode(":", $hora);

$turno_inicio = explode(":", $turno_inicio);

$min = 0;


$min = ((int)($hora[0]-$turno_inicio[0])* 60) + (int)($hora[1]-$turno_inicio[1]);

}

if($min > CANCELACION_MAX_MIN)

return true;

else

return false;

}

//Función que devuelve el ancho para los turnos libres

function db_calcular_colspan($min, $bib_apertura, $bib_cierre){




return $minutos/$min;

}

function calcular_dias_entre_fechas($fecha){

$diff = abs(strtotime(fecha_eeuu($fecha)) - strtotime(fecha_eeuu(date('d-m-Y'))));

$years = floor($diff / (365*60*60*24));

$months = floor(($diff - $years * 365*60*60*24) / (30*60*60*24));

$days = floor(($diff - $years * 365*60*60*24 - $months*30*60*60*24)/ (60*60*24));

return $days;

}

function hora_pasada($res_inicio, $hora_actual, $fecha){


$inicio = explode(":", $res_inicio);

$fin = explode(":", $hora_actual);

$min = 1;


$min = ((int)($inicio[0]-$fin[0])* 60) + (int)($inicio[1]-$fin[1]);

}

if($min < 0){

if($fin[1] <= 30){

$fin[1] = 30;

}

else{

$fin[0] = 1;

$fin[1] = 0;

}

$res_inicio = $fin[0].':'.$fin[1];

}

return $res_inicio;

}

function fin_pasado($res_fin, $hora_actual, $fecha, $min_turno){

$inicio = explode(":", $res_fin);

$fin = explode(":", $hora_actual);

$min = $min_turno+1;


$min = ((int)($inicio[0]-$fin[0])* 60) + (int)($inicio[1]-$fin[1]);

}

if($min < $min_turno){

return 1;

}

return 0;

}

function microtime_float(){

list($useg, $seg) = explode(" ", microtime());

return ((float)$useg + (float)$seg);

}

function calcula_numero_dia_semana($dia,$mes,$ano){

$numerodiasemana = date('w', mktime(0,0,0,$mes,$dia,$ano));

if ($numerodiasemana == 0)

$numerodiasemana = 6;

Anexos

142

142

else

$numerodiasemana--;

return $numerodiasemana;

}

//Calcula el último día del mes

function ultimoDia($mes,$ano){

$ultimo_dia=28;

while (checkdate($mes,$ultimo_dia + 1,$ano)){

$ultimo_dia++;

}

return $ultimo_dia;

}

function dame_nombre_mes($mes){

$meses = array("1" => "Enero", "2" => "Febrero", "3" => "Marzo", "4" => "Abril", "5" => "Mayo", "6" => "Junio", "7"

=> "Julio", "8" => "Agosto", "9" => "Septiembre", "10" => "Octubre", "11" => "Noviembre", "12" => "Diciembre",);

return $meses[$mes];

}

/****************** MANEJO DE ESTADÍSTICAS ******************/

function est_reservas_x_fecha($bib_siglas, $fecha_ini, $fecha_fin, $agrupar) {

$sentencia = "SELECT ";

switch ($agrupar){

case 1: $sentencia.= "fecha_reserva";

break;

case 2: $sentencia.= "MONTH(fecha_reserva)";

break;

case 3: $sentencia.= "YEAR(fecha_reserva)";

break;

case 4:$sentencia.= " WEEKDAY(fecha_reserva)";

break;

default: $sentencia.= "fecha_reserva";

break;

}

$sentencia.= ", count(reserva_id) AS num_res FROM `".$bib_siglas."_reservas`";

if($fecha_fin && $fecha_ini)

$sentencia .= " WHERE fecha_reserva >= '$fecha_ini' AND fecha_reserva <= '$fecha_fin'";

switch ($agrupar){

case 1: $sentencia.= " GROUP BY fecha_reserva";

break;


case 2: $sentencia.= " GROUP BY MONTH(fecha_reserva)";

break;

case 3: $sentencia.= " GROUP BY YEAR(fecha_reserva)";

break;

case 4: $sentencia.= " GROUP BY WEEKDAY(fecha_reserva)";

break;

default: $sentencia.= " GROUP BY fecha_reserva";

break;

}




}

return $resultado;

}

function est_sanciones_x_fecha($bib_ID, $fecha_ini, $fecha_fin) {

$sentencia = "SELECT count(*) as num from `sanciones` WHERE bib_id = $bib_ID";


$sentencia .= " AND fin >= '$fecha_ini' AND fin <= '$fecha_fin'";


$resultado = mysql_fetch_array($resultado_sql);


}

/* RESERVAS TOTALES

* $agrupar = 1 -> agrupadas por dia semana

* $agrupar = 2 -> por mes

* $agrupar = 3 -> por año

*/

function est_fechas_agrupada($bib_siglas, $fecha_ini, $fecha_fin, $agrupar) {

switch ($agrupar){

case 1:$sentencia.= " SELECT X.dia_sem, count(X.dia_sem) AS num FROM (SELECT WEEKDAY(fecha_reserva)

as dia_sem FROM `".$bib_siglas."_reservas`";

break;

case 2: $sentencia.= "SELECT X.mes, count(X.mes) AS num FROM (SELECT MONTH(fecha_reserva) as mes

FROM `".$bib_siglas."_reservas`";

break;

case 3: $sentencia.= "SELECT X.anio, count(X.anio) AS num FROM (SELECT YEAR(fecha_reserva) as anio FROM

`".$bib_siglas."_reservas`";

break;

}

Anexos

144

144


$sentencia .= " WHERE fecha_reserva >= '$fecha_ini' AND fecha_reserva <= '$fecha_fin' GROUP BY

fecha_reserva) AS X ";

switch ($agrupar){

case 1: $sentencia.= " GROUP BY X.dia_sem ORDER BY X.dia_sem ASC";

break;

case 2: $sentencia.= " GROUP BY X.mes ORDER BY X.mes ASC";

break;

case 3: $sentencia.= " GROUP BY X.anio ORDER BY X.anio ASC";

break;

}




}

return $resultado;

}

function est_totales($reservas){

$total=0;

foreach($reservas as $reserva){

$total += $reserva[1];

}

return $total;

}

function est_reservas_x_titulacion($bib_siglas, $fecha_ini, $fecha_fin) {

$sentencia = "SELECT titulacion, count(reserva_id) AS num_res FROM `".$bib_siglas."_reservas`";


$sentencia .= " WHERE fecha_reserva >= '$fecha_ini' AND fecha_reserva <= '$fecha_fin' AND titulacion <> ''";

$sentencia.= " GROUP BY titulacion ORDER BY num_res DESC";




}

return $resultado;

}


function est_reservas_x_salas($bib_siglas, $fecha_ini, $fecha_fin) {

$sentencia = "SELECT nombre_sala, count(reserva_id)as num_res FROM

`".$bib_siglas."_reservas`,`".$bib_siglas."_salas` WHERE ";


$sentencia .= "fecha_reserva >= '$fecha_ini' AND fecha_reserva <= '$fecha_fin' AND";

$sentencia.= " ".$bib_siglas."_reservas.sala_id=".$bib_siglas."_salas.sala_id GROUP BY

".$bib_siglas."_reservas.sala_id";




}

return $resultado;

}

function est_reservas_x_turnos($bib_siglas, $fecha_ini, $fecha_fin) {

$sentencia = "SELECT inicio, fin, count(reserva_id) as num_res FROM

`".$bib_siglas."_reservas`,`".$bib_siglas."_turnos` WHERE ";


$sentencia .= "fecha_reserva >= '$fecha_ini' AND fecha_reserva <= '$fecha_fin' AND";

$sentencia.= " ".$bib_siglas."_reservas.turno_id=".$bib_siglas."_turnos.turno_id GROUP BY

".$bib_siglas."_reservas.turno_id";




}

return $resultado;

}

function est_ocupacion($bib_siglas){

$ocupacion =0;

$sentencia = "SELECT count(turno_id) as num_t ,grupo_id FROM `".$bib_siglas."_turnos`,

`".$bib_siglas."_grupo_turnos`

WHERE `".$bib_siglas."_turnos`.grupo = `".$bib_siglas."_grupo_turnos`.grupo_id

AND `".$bib_siglas."_grupo_turnos`.activo=1 GROUP BY grupo ORDER BY grupo_id ASC";



$turnos[] = $row;

}

Anexos

146

146

$sentencia = "SELECT count(sala_id) as num_s , grupo_id FROM `".$bib_siglas."_salas`,

`".$bib_siglas."_tipo_salas`

WHERE `".$bib_siglas."_tipo_salas`.tipo_id = `".$bib_siglas."_salas`.tipo_id

AND turno_libre= 0 GROUP BY grupo_id ORDER BY grupo_id ASC";



$salas[] = $row;

}

foreach ($turnos as $turno){

foreach ($salas as $sala){

if($turno['grupo_id'] == $sala['grupo_id']){

$ocupacion += $turno['num_t'] * $sala['num_s'];

}

}

}

return $ocupacion;

}

function pri_fecha($bib_siglas){

$sentencia = "SELECT fecha_reserva FROM `".$bib_siglas."_reservas` ORDER BY fecha_reserva ASC LIMIT 1";

$resultado_sql = mysql_fetch_array(db_query($sentencia));


}

function ult_fecha($bib_siglas){

$sentencia = "SELECT fecha_reserva FROM `".$bib_siglas."_reservas` ORDER BY fecha_reserva DESC LIMIT 1";



}

function usr_distintos($bib_siglas, $fecha_ini, $fecha_fin){

$sentencia = "SELECT count(distinct uvus) as total FROM `".$bib_siglas."_reservas` ";


$sentencia .= " WHERE fecha_reserva >= '$fecha_ini' AND fecha_reserva <= '$fecha_fin'";


return $resultado_sql['total'];

}


Anexo III: Actas de Reunión.

Departamento: Proceso Técnico Autor: Vidal Vidal, José María Teléfono: 954 486 135 E-Mail: [email protected]

Proyecto "Reserva de Salas de Trabajo".

Acta de la 1ª reunión celebrada el 01-07-2013.

Fecha, hora: 01-07-2014, 10:00 Lugar: Despacho Proceso Técnico Asistentes: Mercedes Aguilar

Francisco Avellaneda José María Vidal

Puntos del orden del día

Punto Tema

1. Punto 1: Entrega de documentación.

2. Punto 2: Definición del alcance del proyecto

2.1 Requisitos

2.2 Usuarios

2.3 Fechas

Anexos

148

148

___________________________________ ___________________________________

Sevilla, 2 de Julio de 2013 José María Vidal / P. Técnico

Anexos:

• Requisitos del sistema.

• Catálogo de usuarios.

Resultados

Resultados/ acuerdos

Punto 1 Se hace entrega a José María Vidal, el código de la antigua aplicación, así como las claves

para poder acceder a la misma y comprobar su funcionamiento.

También se entregan la documentación existente del desarrollo de la misma.

Punto 2 • Acuerdo 2.1: Se definen los requisitos iniciales, que quedarán contemplados en el

anexo 1, requisitos.

• Acuerdo 2.2: Primera valoración sobre los usuarios que participarán en ella y

descripción de sus roles.

• Acuerdo 2.3: No existe fecha inicial de entrega, pero se espera que el

funcionamiento de la primera alfa del proyecto para inicios del curso académico

(23 de Septiembre de 2013) .

Fecha de la siguiente reunión: 8 de Julio de 2013


Requisitos del sistema

• La aplicación debe ser flexible a la hora de crear y gestionar bibliotecas. Siendo necesarias la

definición de tipos de salas, número de salas, turnos y preferencias.

• Según el rol del usuario se mostrará unas opciones u otras, para que la labor de cada usuario

quede bien definida.

• Minimizar el impacto sobre el usuario que realiza reservas, no debe complicarse la forma en que

se llevan a cabo.

• Diseño intuitivo y mediante portal web.

• Login mediante el sistema SSO proporcionado por la Universidad de Sevilla

• Posibilidad de definir nuevas bibliotecas una vez la aplicación esté funcionando.

• Posibilidad de penalizar usuarios, según criterios propios.

• Gestión total de reservas con la máxima información.

• Gestión total de salas y turnos de las bibliotecas.

• Gestión de usuarios.

• Gestión de preferencias.

• Gestión de bibliotecas.

Anexos

150

150

Catálogo de usuarios

Orden de menos a más privilegios:

• Usuario general: Es quien realiza la reserva, solo accede al día y turno que quiere desear la

reserva y recibe notificaciones sobre la misma (Confirmación y anulación).

• Revisor: Personal técnico que atiende a los alumnos en mostrador de la biblioteca, encargado

de verificar las reservas y su gestión.

• Administrador: Usuario encargado de la gestión de una biblioteca en concreto (salas, turnos,

usuarios, preferencias, etc.).

• Superadministrador: Usuario encargado de la gestión de bibliotecas (dar de alta/baja, nombrar

el administrador de la misma) pensado para que lo ejerza personal de SSCC.





Fecha, hora: 08-07-2014, 10:30 Lugar: Despacho Proceso Técnico Asistentes: Mercedes Aguilar



Punto Tema

1. Punto 1: Exposición de trabajo realizado.

2 Punto 2: Definición de requisitos funcionales.

3 Punto 3: Definición de requisitos de diseño.

4 Punto 4: Actualización de requisitos generales en función de lo expuesto.

Anexos

152

152

___________________________________ ___________________________________


Anexos:

• Requisitos del sistema.

Resultados


Punto 1 Se realizó una visión del proyecto, una semana después del estudio de la situación actual.

Punto 2 Quedan recogidos los requisitos de funcionalidad demandados por los usuarios.

Punto 3 Quedan recogidos los requisitos de diseño planteados.

Punto 4 Una vez vistos los requisitos funcionales y de diseño, se comprueba si hay que actualizar

los generales de la aplicación.

Fecha de la siguiente reunión: 12 de Julio de 2013.


Anexo: Requisitos del sistema

Reservas:

• Creación de listados online de reservas, con posibilidad de buscar por varios campos.

• Todas las notificaciones se realizarán mediante e-mails.

Salas:

• Cierre de salas: Se debe poder cerrar varias salas a la vez, y durante varios días. También cerrar

turnos completos y desactivar salas.

• Habrá salas especiales que no se ciñan a un turno prefijado, sino a un horario a elegir y que

además requerirán de una autorización por parte del administrador (mediante email).

Turnos:

• Los turnos se agruparán en “grupos de turnos” que abarquen un horario completo con

divisiones establecidas ya sea por número o duración.

• Los turnos dentro de un grupo pueden ser de longitud variable.

• Las salas con requerimiento de autorización contarán con turnos libres que solicitarán los

usuarios.

Sanciones:

• Las sanciones se regirán a las preferencias de la biblioteca, pudiendo elegir el número de días

naturales y decidiendo si se tienen en cuenta sanciones de toda la red de centros o sólo de la

biblioteca propia.

Usuarios:

• La creación de usuarios y roles se registrarán mediante su UVUS.

• La autenticación de usuarios se realizará mediante el sistema SSO.

Preferencias:

• Cada biblioteca podrá seleccionar algunas preferencias como: email remitente, días de sanción,

días con antelación para realizar una reserva, reservas máximas por parte de los usuarios, etc.

Estadísticas:

• Creación de informe de estadísticas en un periodo de tiempo a determinar, los datos

importantes son número de reservas, ratio usuarios/reservas, porcentaje de ocupación.

Reservas por parte de revisores o administradores:

• Tanto los administradores como revisores también podrán realizar reservas.

Diseño:

• Se debe intentar que el diseño de la aplicación sea responsivo para acceder desde smartphones

y tablets además de ordenadores.

• El cierre de salas y sanciones debe ser muy accesible a los usuarios, para no perder tiempo.

Anexos

154

154




Fecha, hora: 12-07-2014, 12:30 Lugar: Despacho Dirección Asistentes: Mercedes Aguilar


___________________________________ ___________________________________



Punto Tema

1. Punto 1: Exposición de requisitos extraídos.

2 Punto 2: Exposición de casos de uso.

Resultados


Punto 1 Se realizó una exposición del trabajo realizado e información extraída.

Punto 2 Se muestran y se validan los casos de uso.





Fecha, hora: 20-07-2014, 10:30 Lugar: Despacho Dirección Asistentes: Mercedes Aguilar


___________________________________ ___________________________________



Punto Tema

1. Punto 1: Exposición de la solución de diseño adoptada.

Resultados


Punto 1 Se realizó una exposición del trabajo realizado e información extraída. Fue validada por

los usuarios responsables.

Documents

Proyecto Fin de Carrera - Servidor de la Biblioteca de ...bibing.us.es/proyectos/abreproy/12257/fichero/Memoria-PFC-Jose-Maria... · En este proyecto se recoge la creación de una