TRABAJO FIN DE GRADO

Título

Desarrollo de una intranet integrada con un gestor de

documentos para la gestión interna de un colegio

Autor/es

Paula Mayor Berenguer

Director/es

César Domínguez Pérez

Facultad

Facultad de Ciencia y Tecnología

Titulación

Grado en Ingeniería Informática

Departamento

Curso Académico

2015-2016
 Desarrollo de una intranet integrada con un gestor de documentos para la
gestión interna de un colegio, trabajo fin de grado
de Paula Mayor Berenguer, dirigido por César Domínguez Pérez (publicado por la
Universidad de La Rioja), se difunde bajo una Licencia
Creative Commons Reconocimiento-NoComercial-SinObraDerivada 3.0 Unported.
Permisos que vayan más allá de lo cubierto por esta licencia pueden solicitarse a los
titulares del copyright.

© El autor
© Universidad de La Rioja, Servicio de Publicaciones, 2016
publicaciones.unirioja.es
E-mail: publicaciones@unirioja.es
 Facultad de Ciencia y Tecnología

TRABAJO FIN DE GRADO

Grado en Ingeniería informática

Desarrollo de una intranet integrada con un gestor de

documentos para la gestión interna de un colegio

Alumno:

Paula Mayor Berenguer

Tutores:

César Domínguez Pérez

Logroño, junio, 2016

Resumen
Español
En este proyecto se expondrán las distintas fases que han sido necesarias para desarrollar una
intranet para un colegio mediante el uso del CMS (sistema de gestión de contenidos) Drupal y
el ECM (gestión de contenido empresarial) Alfresco.

Para realizar el proyecto ha sido necesario investigar, crear y configurar diferentes

funcionalidades de Drupal y Alfresco. También ha sido necesario no solo estudiar y editar
códigos realizados por terceros sino también programar nuevo código utilizando tecnologías
como PHP, JQuery, AJAX, las APIs proporcionadas por Drupal y el plugin FullCalendar.

La finalidad de este proyecto es solucionar los problemas de gestión interna que tiene un
colegio. De esta manera el colegio podrá gestionar fácilmente un blog con noticias tanto
públicas como privadas, enviar avisos a los usuarios de la intranet, realizar reservas de las salas
disponibles en el colegio, gestionar eventos de diferentes magnitudes, realizar una gestión
completa de documentos propios y compartidos, tener accesible una zona de descargas con
documentos tanto públicos como privados y publicar quejas y sugerencias de forma anónima.

Inglés
In this project the different phases which have been necessary to carry an intranet out for a
school using the CMS (content management system) Drupal and the ECM (enterprise content
management) Alfresco will be explained.

To carry the project out has been necessary to investigate, create and configure different
functionalities of Drupal and Alfresco. It has also been necessary not only to study and edit
codes which have been done by third party but also to programme new code using
technologies such as PHP, JQuery, AJAX, the APIs which are provided by Drupal and the
FullCalendar plugin.

The aim of this project is to solve the problems of internal management which have a school.
In this way the school will can easily manage a blog with both public news and private news,
send notices to other intranet users, book available rooms at school, manage events of
different magnitudes, carry a complete management out of own documents and shared
documents, have accessible a download area with both public documents and private
documents and publish complaints and suggestions anonymously.

~1~
Índice
Plan de dirección de proyecto 3
Planificación del proyecto 4
Plan del alcance del proyecto 4
Objetivo producto 4
Estudio de alternativas 4
Definición del alcance del producto 5
EDT y diccionario 6
Planificación de las tareas 9
División y estimación de las tareas 9
Estructura de los entregables 10
Diagrama Gantt 12
Diagrama de hitos 13
Plan de gestión del proyecto 13
Gestión de calidad 13
Gestión de comunicación 14
Gestión de riesgos 14
Gestión de cambios 15
Análisis de requisitos 15
Análisis inicial 15
Definición de requisitos 16
Análisis de interfaces y navegabilidad 18
Casos de uso 20
Diseño 22
Mensajes privados 22
Buzón de quejas y sugerencias 22
Blog de noticias 23
Página personal de entrada 24
Integración Drupal con Alfresco 24
Gestión de salas 25
Gestión de eventos 26
Implementación 27
Problema con la integración entre Drupal y Alfresco 28
Problema con la vista de las noticias 28
Problema con la zona de descargas 29
Problema con el menú dinámico 33
Problema con el campo invitados internos 35
Problema con la repetición de eventos 36
Seguimiento y control 40
Tareas y desviaciones 40
Control de calidad 43
Control de cambios 43
Conclusión 47
Bibliografía 48

~2~
Plan de dirección de próyectó
Para abordar el proyecto es necesario realizar reuniones iniciales con el cliente para establecer
el objetivo del producto. Si el objetivo general está claro, habrá que especificar con el cliente
de forma detallada todos los requisitos que espera encontrar en el producto.

Para cumplir con éxito los requisitos se realizará un análisis previo y un estudio de alternativas
de todas las opciones que el mercado ofrece. Una vez que las herramientas estén
seleccionadas el alcance podrá ser definido y se podrá realizar la división en paquetes de
trabajo. Estos paquetes estarán representados en la EDT y en su diccionario.

Tras lo anterior, el plan de alcance del proyecto estará acabado y la planificación de las tareas
podrá comenzar. Las tareas serán divididas y estimadas en duración de horas. Esto dará lugar a
un cronograma representado mediante un diagrama Gantt donde se verán reflejadas las
dependencias entre las distintas tareas y el orden de importancia de las mismas. Dentro de
esta planificación se detallará la estructura de los entregables.

Si la planificación de las tareas está acabada, los planes de las diferentes gestiones serán
detallados. Estos estarán compuestos por la gestión de calidad, de comunicación, de riesgos y
de cambios. El resto de las gestiones no estarán recogidas ya que no son necesarias por la
pequeña dimensión del proyecto. Estos planes guiarán en la forma en la que habrá que actuar
durante el desarrollo del proyecto.

Se realizará un análisis más profundo que contendrá la definición de los requisitos, el análisis
de interfaces, de navegabilidad y los casos de uso antes de proseguir con la fase de ejecución
del proyecto. Esta fase implicará la realización de las distintas tareas siguiendo el orden de
importancia impuesto por el cliente y respetando los tiempos planificados.

Durante el desarrollo del proyecto se realizará el seguimiento y control del mismo donde el
alcance será controlado, se comprobará que los tiempos se cumplen como se había planificado
y que la calidad cumple con la exigida a la finalización de cada paquete de trabajo. A medida
que los cambios vayan ocurriendo serán gestionados.

Para mostrar el estado del producto al cliente y el estado del proyecto al tutor se realizarán
reuniones periódicas. Tras cada reunión se levantará un acta de la misma.

Cuando el proyecto finalice las tareas del cierre serán llevadas a cabo. Estas tareas estarán
compuestas por la confirmación de los requisitos, la aceptación final de producto por parte del
cliente, la recopilación de las conclusiones y la entrega del proyecto.

Para realizar el control de versiones del código fuente desarrollado se utilizará GitHub.

~3~
Planificación del próyectó
Plan del alcance del proyecto
Objetivo producto
Actualmente, un colegio desea una aplicación centralizada donde poder gestionar noticias,
avisos entre personas, salas, eventos, documentos o incluso publicar sugerencias. Por ello, el
proyecto tiene como objetivo realizar una intranet para el colegio donde gestionar fácilmente
un blog con noticias, enviar mensajes entre los usuarios de la intranet, reservar las salas del
colegio, gestionar eventos, gestionar documentos y publicar sugerencias.

Estudio de alternativas
Para realizar la intranet he decidido utilizar un CMS ya que proporciona multitud de ventajas
como por ejemplo, control total sobre el diseño y los contenidos web, permite múltiples
usuarios y roles, gran comunidad detrás de cada CMS, permite desarrollos escalables, buena
gestión del posicionamiento en buscadores y actualizaciones de seguridad frecuentes.

Para ello se han buscado los CMS más populares: Drupal, Joomla! o Wordpress. Todos ellos se
programan en PHP, ofrecen multitud de módulos/plugins también gratuitos, hay una gran
comunidad de desarrolladores detrás de ellos, el sistema gestor de base de datos por defecto
es MYSQL y pueden correr en un servidor apache. Las ventajas que posee Drupal respecto a los
otros son:

 Capaz de soportar un mayor número de visitas.

 Mayor flexibilidad en la creación de contenidos.
 Soporta gran cantidad de roles y permisos, los cuales son fácilmente configurables.
 Permite cambiar fácilmente de sistema gestor de base de datos.
 Posibilidad de integrar con otras aplicaciones a través de CMIS (Servicios de
interoperabilidad de gestión de contenidos).

La principal desventaja de Drupal es su alta curva de aprendizaje, pero como he estado

trabajando con ello durante las prácticas en la empresa no supone un problema a considerar.
Tras las anteriores consideraciones, se ha decidido utilizar Drupal para realizar la intranet ya
que permite cumplir los requisitos especificados.

A la hora de elegir Drupal existen dos versiones, la 7 y la 8. La versión 8 aporta diversas

mejoras como por ejemplo: mejor eficiencia en el navegador, accesibilidad mejorada,
beneficios en la seguridad o incorporación de HTML5. Pero como han liberado la versión 8
hace pocos meses, aún tiene bugs y la mayoría de módulos aún no han sido portados, además
tengo más experiencia con Drupal 7. Por ello, he decidido utilizar la versión 7.

Para la gestión documental consideraré los ECM actualmente más utilizados que son Alfresco y
Nuxeo. Ambos permiten trabajar con distintos sistemas gestores de bases de datos, ofrecen
multitud de módulos, permiten integrarse con Drupal y ambos ofrecen versiones gratuitas.

~4~
He decidido utilizar Alfresco ya que tengo experiencia con él porque lo he estado utilizando
durante las prácticas en la empresa.

Definición del alcance del producto

El proyecto tiene como objetivo realizar una intranet para un colegio donde diferenciar roles
para los distintos miembros del colegio. Entre esos roles se encontrarán los correspondientes
al director, sub-director, administración colegio, coordinador bachillerato, coordinador E.S.O,
coordinador primaria, profesor bachillerato, profesor E.S.O, profesor primaria, profesor
infantil, padre, alumno y administrador intranet. Cada uno de estos roles tendrá acceso a
partes limitadas de la intranet. Los privilegios asociados a cada uno de los roles podrán ser
editados en cualquier momento por el administrador de la intranet.

La intranet tendrá un blog de noticias donde cada noticia contendrá un título, una descripción
y como opcional se podrán añadir fotos y/o documentos. Cuando una noticia sea creada, se
podrá elegir los roles a los que se desea que sea visible. Únicamente los roles director, sub-
director, administración colegio y cualquiera de los coordinadores podrá publicar, modificar o
eliminar noticias.

La intranet permitirá el envío de mensajes privados entre los usuarios. Cuando un nuevo
mensaje sea enviado se mostrará una notificación al iniciar sesión a los usuarios
correspondientes. Los mensajes podrán ser enviados a un usuario específico, a varios usuarios
concretos o a los usuarios pertenecientes a un rol. Además, los usuarios podrán iniciar un flujo
de conversación al responder a los mensajes recibidos y bloquear a usuarios para no recibir
ningún mensaje suyo. Únicamente los roles director, sub-director, administración colegio y
cualquiera de los coordinadores y de los profesores podrá realizar el envío de mensajes.

Dentro de la intranet existirá un buzón de sugerencias anónimo donde cualquier usuario sin
importar el rol al que pertenezca puede redactar sugerencias. Todas esas sugerencias
quedarán reflejadas en una tabla.

Existirá una página personal de entrada para todos los usuarios donde se mostrarán sus
mensajes privados, las noticias recientes y los nuevos tweets publicados por el colegio.

Se podrá realizar la gestión de las salas del colegio, por lo que cuando un usuario que
pertenezca al rol director, sub-director o a cualquiera de los coordinadores podrá reservar una
sala, modificar o eliminar la reserva. Los campos obligatorios a rellenar son: la sala a reservar,
la fecha, el intervalo de horas y el motivo. Aunque opcionalmente, también se podrán
especificar invitados internos y externos a la intranet y registrar documentación. No estará
permitido reservar dos veces una sala con misma fecha y mismo intervalo horario.

Cuando las salas se reserven, la información sobre ello quedará registrada en un calendario
común para las reservas. Además, cuando una reserva sea creada, modificada o eliminada, si
tiene asociados invitados, se enviarán avisos automáticamente a los mismos.

En la intranet también se podrán gestionar eventos, los cuales podrán ser creados, editados o
eliminados por usuarios que pertenezcan al rol director, sub-director o a cualquiera de los
coordinadores.

~5~
Lo obligatorio a cumplimentar será el nombre del evento, el intervalo de fechas, el intervalo de
horas y si este evento pertenece o no a un grupo de eventos, pudiendo formar un gran evento.
Podrán existir varios eventos que coincidan en el intervalo de fechas y en el intervalo de horas.

Aparte de lo obligatorio a especificar, también se podrá reservar salas, especificar invitados,

registrar documentación, publicar información sobre el evento en distintas redes sociales y
repetir diaria o semanalmente los eventos.

Opcionalmente, en la reserva de una sala se puede elegir si crear un evento con la información
recogida de la reserva. Aunque, un evento podrá existir sin tener reservas de salas y una
reserva de sala podrá existir sin estar asociada a un evento.

Cuando un evento se cree, los datos del mismo quedarán registrados en un calendario común
para los eventos. Además, cuando un evento sea creado, modificado o eliminado se enviarán
correos de aviso automáticamente a los invitados del mismo, si los tiene. Los eventos podrán
ser filtrados según el grupo de eventos al que pertenecen y según un intervalo de fechas.

La intranet también permitirá la gestión documental a los usuarios con rol de director, sub-
director, administración colegio o cualquiera de los coordinadores y de los profesores.

Dentro de esta gestión documental se podrán crear carpetas, realizar control de versiones de
los documentos, ver las propiedades y eliminar documentos y carpetas. También se podrán
realizar distintas manipulaciones en los documentos que posean un formato PDF (combinar y
dividir documentos, insertar, extraer y eliminar páginas de documentos, insertar marcas de
agua y cifrar y descifrar los documentos). Además, se podrá utilizar Google Docs para crear y
editar el contenido de los documentos almacenados.

También se incluirá una zona de descargas con documentos públicos, a los cuales tendrán
acceso todos los usuarios independientemente del rol, y con documentos privados, visibles
únicamente a los roles especificados en cada documento de descarga. Aunque, los usuarios
que tengan rol de director, sub-director, administración colegio o cualquiera de los
coordinadores y de los profesores tienen privilegios para crear nuevos documentos en la zona
de descargas.

La información ofrecida en la intranet estará disponible en dos idiomas, inglés y español. La

disposición de la intranet se irá adaptando a los distintos dispositivos, es decir, la intranet será
responsive.

Existen varios requisitos no contemplados en el alcance debido a que no se van a realizar por
el límite de horas. Si a medida que avanzo con el proyecto preveo que voy a tener tiempo de
realizar más requisitos, se hablará con el cliente para priorizar y se aumentará el alcance.

Las tecnologías que utilizaré son PHP, jQuery, AJAX y JSON porque son las tecnologías
impuestas por las herramientas con las que he decidido trabajar en el proyecto.

EDT y diccionario
La división del proyecto en paquetes de trabajo y su representación en la EDT queda reflejada
mediante la figura 1, la cual se encuentra a continuación.

~6~
 Plan de
dirección de Plan del alcance
proyecto del proyecto
PG.1.1 PG.1.2.1
Planificación Planificación de
proyecto las tareas
PG.1.2 PG.1.2.2
Lecciones
Gestión Plan de gestión
aprendidas
PG.1 PG.1.2.3
PG.1.3
Seguimiento y
control
Reuniones
PG.1.4 cliente
Reuniones PG.1.5.1
PG.1.5 Reuniones tutor

Blog de noticias PG.1.5.2

PG.2.1
Mensajes
privados
PG.2.2
Gestor de
eventos
PG.2.3
Gestión
Proyecto TFG documental
PG PG.2.4
Personalización
Intranet
intranet
PG.2
PG.2.5
Página personal
de entrada
Análisis de PG.2.6
requisitos
Gestión de salas
PG.3
PG.2.7
Buzón de
sugerencias
PG.2.8
Traducción
PG.2.9

Drupal
Instalación PG.4.1
infraestructura
PG.4 Alfresco
PG.4.2

Figura 1. EDT

~7~
A través de la tabla 1 se realiza el diccionario de la EDT.

Código Titulo Descripción

PG.1.1 Plan de dirección Recoge la planificación general de cómo se va a ir desarrollando
de proyecto el proyecto.
PG.1.2.1 Plan del alcance Recoge el objetivo del producto, el estudio de alternativas, la
del proyecto definición del alcance del producto y la representación de la
EDT y su diccionario.
PG.1.2.2 Planificación de Recoge la división de los paquetes de trabajo en tareas, su
las tareas estimación en horas, el cronograma representado mediante un
diagrama Gantt, la estructura de los entregables y una tabla
con los hitos más importantes.
PG.1.2.3 Plan de gestión Recoge los siguientes planes de gestión: comunicaciones,
calidad, riesgos y cambios.
PG.1.3 Lecciones Recoge el aprendizaje obtenido a lo largo del proyecto.
aprendidas
PG.1.4 Seguimiento y Recoge el seguimiento del alcance, de las desviaciones de los
control tiempos, de la calidad y de cambios en el transcurso del
proyecto.
PG.1.5.1 Reuniones cliente Recoge las reuniones realizadas con el cliente en las cuales se
realizará un acta donde quedarán recogidos los acuerdos.
PG.1.5.2 Reuniones tutor Recoge las reuniones realizadas con el tutor en las cuales se
realizará un acta donde quedarán recogidos los acuerdos.
PG.2.1 Blog de noticias Recoge la realización de un blog con distintas noticias.
PG.2.2 Mensajes Recoge la configuración y personalización de distintos módulos
privados para permitir el envío de mensajes privados entre los usuarios.
PG.2.3 Gestión evento Recoge la realización de un módulo que permita gestionar un
evento.
PG.2.4 Gestión Recoge la configuración y personalización de distintos módulos
documental para poder gestionar los documentos del colegio.
PG.2.5 Personalización Recoge la configuración de la intranet para que sea responsive
intranet y distinga roles.
PG.2.6 Página personal Recoge la configuración y personalización de distintos módulos
de entrada para crear páginas personales de entrada diferentes para los
usuarios.
PG.2.7 Gestión de salas Recoge la realización de un módulo que permita realizar
reservas de las salas del colegio.
PG.2.8 Buzón de Recoge la configuración y personalización de distintos módulos
sugerencias para permitir la publicación de sugerencias anónimas por parte
de los usuarios.
PG.2.9 Traducción Recoge la configuración de la intranet para que esté preparada
para ser multilingüe y se muestre la información en varios
idiomas.
PG.3 Análisis de Recoge el análisis inicial necesario para especificar con mayor
requisitos certeza los requisitos, la definición de los requisitos, el análisis
de interfaces, de navegabilidad y los casos de uso.
PG.4.1 Drupal Recoge la instalación de toda la infraestructura necesaria para
el correcto funcionamiento de Drupal.
PG.4.2 Alfresco Recoge la instalación de toda la infraestructura necesaria para
el correcto funcionamiento de Alfresco.
Tabla 1. Diccionario de la EDT

~8~
Planificación de las tareas
División y estimación de las tareas
En las tablas 2 y 3 se indica la estimación de horas por tareas. He planificado realizar 5 horas
diarias de lunes a viernes, por lo que 5 horas estimadas corresponden a un día.

Tarea Estimación en horas

Plan de dirección de proyecto 2
Planificación proyecto 21
 Plan del alcance del proyecto 5
 Planificación tareas 12
 Plan de gestión 4
Lecciones aprendidas 4
Seguimiento y control 20
Reuniones 12
 Reuniones cliente 6
 Reuniones tutor 6
Blog de noticias 15
 Instalación y configuración módulos necesarios 14
 Pruebas 1
Mensajes privados 10
 Instalación y configuración módulos necesarios 9
 Pruebas 1
Gestión evento 70
 Diseño de la base de datos 6
 Creación de las tablas 2
 Programación módulo 60
 Pruebas 2
Gestión documental 30
 Instalación add-ons y configuración Alfresco 10
 Instalación y configuración módulos integración 10
 Configuración zona de descargas 8
 Pruebas 2
Personalización intranet 4
 Creación de roles 2
 Instalación tema responsive 1
 Pruebas 1
Traducción 10
 Preparar la intranet para las traducciones 2
 Realizar las traducciones en inglés y español 8
Página personal de entrada 10
 Instalación y configuración módulos necesarios 9
 Pruebas 1
Buzón de sugerencias 10
 Instalación y configuración módulos necesarios 9
 Pruebas 1
Tabla 2. Tareas y estimación (I)

~9~
Tarea Estimación en horas
Gestión de salas 60
 Diseño de la base de datos 7
 Creación de las tablas 3
 Programación módulo 48
 Pruebas 2
Instalación infraestructura 3
 Drupal 2
 Alfresco 1
Análisis de requisitos 19
 Análisis inicial 3
 Definición de requisitos 4
 Análisis de interfaces 7
 Análisis de navegabilidad 2
 Casos de uso 3
Horas totales 300
Tabla 3. Tareas y estimación (II)

Estructura de los entregables

 E01 Plan de dirección de proyecto
En el inicio del proyecto, se plasma en un entregable la planificación inicial y general
de cómo se va a ir desarrollando el proyecto.
 E02 Plan del alcance del proyecto
Este entregable es el resultado de plasmar el objetivo general del proyecto, el estudio
de alternativas donde se plasman las distintas herramientas más comunes en el
mercado, indicando las ventajas y diferencias entre ellas y las razones por las cuales se
ha elegido una u otra, la definición del alcance del producto y la división en tareas
junto con su representación en la EDT y su diccionario.
 E03 Planificación tareas
Este entregable es el resultado de plasmar la división en tareas, su estimación en
horas, un diagrama Gantt con las dependencias y las fechas en las que se realizarán
cada una de las tareas, el detalle del contenido de cada uno de los entregables y una
tabla con los hitos más importantes que tendrán lugar a lo largo del proyecto.
 E04 Plan de gestión
Este entregable es el resultado de plasmar los distintos planes de gestión:
comunicaciones, calidad, riesgos, cambios y adquisiciones. Todos los anteriores me
servirán para guiarme en las acciones a tomar durante el desarrollo del proyecto.
 E05 Lecciones aprendidas
Cuando el proyecto llegue a su fin se recogerán en este entregable distintas lecciones
aprendidas durante el transcurso del mismo. Su fin es aprender de los errores
cometidos y no volverlos a repetir en futuros proyectos.
 E06 Seguimiento y control
Este entregable es el resultado de plasmar el seguimiento realizado durante todo el
desarrollo del proyecto. Este contendrá la comparación entre los tiempos estimados y
los reales, haciendo hincapié en si se está cumpliendo la planificación o no y
explicando las desviaciones importantes surgidas.

~ 10 ~
 E07 Reuniones con el cliente
En este entregable se recogerán las actas de las reuniones realizadas con el cliente.
 E08 Reuniones con el tutor
En este entregable se recogerán las actas de las reuniones realizadas con el tutor.
 E09 Blog de noticias
Este entregable consta de la estructura del blog de noticias, es decir, la construcción y
configuración de vistas y contenidos que componen el contenido del blog de noticias.
 E10 Mensajes privados
Este entregable consta de la estructura de los mensajes privados, es decir, la
configuración de módulos que componen la funcionalidad de los mensajes privados.
 E11 Gestión evento
Este entregable incluye la estructura de la gestión de un evento, es decir, la
construcción y personalización de módulos y el diseño de la base de datos que
componen la funcionalidad para gestionar un evento.
 E12 Personalización intranet
Este entregable incluye lo referente a la personalización de la intranet, es decir, la
edición de la misma para diferenciar roles y la configuración del tema para que sea
responsive.
 E13 Traducción
Este entregable incluye lo referente a la traducción de la intranet, es decir, la
preparación de la misma para ser multilingüe y la traducción de los contenidos tanto
en inglés como en español.
 E14 Gestión documental
Este entregable consta de la estructura de la gestión documental, es decir, la
configuración de módulos, la integración con el ECM y la personalización de bloques
que componen la funcionalidad para gestionar documentos.
 E15 Página personal de entrada
Este entregable consta de la estructura de la página personal de entrada, es decir, la
configuración y personalización por usuario de distintos módulos que componen la
funcionalidad de la página personal.
 E16 Gestión de salas
En este entregable se incluye la estructura de la gestión de salas, es decir, la
construcción y personalización de módulos y el diseño de la base de datos que
componen la funcionalidad para gestionar las salas del colegio.
 E17 Buzón de sugerencias
Este entregable consta de la estructura del buzón de sugerencias, es decir, la
configuración de distintos módulos que componen la funcionalidad de un buzón de
sugerencias anónimo.
 E18 Drupal
Este entregable es el resultado de exportar la máquina virtual que contiene la
instalación de toda la infraestructura necesaria para que Drupal funcione.
 E19 Alfresco
Este entregable es el resultado de exportar la máquina virtual que contiene la
instalación de toda la infraestructura necesaria para que Alfresco funcione.

~ 11 ~
  E20 Análisis de requisitos
Este entregable es el resultado de plasmar el análisis inicial necesario para especificar
con mayor certeza los requisitos, el análisis de todos los requisitos detallados para que
no den lugar a confusiones con el cliente, imágenes de bocetos de diferentes
interfaces, de la navegabilidad y de los casos de uso.

Diagrama Gantt
La división de los paquetes de trabajo en tareas y la planificación de cuándo se va a realizar
cada una queda reflejado mediante el siguiente diagrama Gantt.

Figura 2. Diagrama de Gantt

~ 12 ~
Diagrama de hitos
En la tabla 4 se muestran las reuniones más importantes realizadas a lo largo del proyecto
tanto con el tutor como con el cliente.

Reunión Fecha
Reunión realizada con el tutor para iniciar el proyecto 28/01/2016
Reunión realizada con el tutor para finalizar el proyecto 13/05/2016
Reunión realizada con el cliente para la recogida de requisitos 02/02/2016
Reunión realizada con el cliente para la aceptación de los requisitos 03/02/2016
Reunión realizada con el cliente para la aceptación del producto 06/05/2016
Tabla 4. Diagrama de hitos

Plan de gestión del proyecto

Gestión de calidad
En la tabla 5 se muestra uno de los bocetos utilizados para gestionar la calidad del proyecto.
Estos pueden ser modificados en cualquier estado del proyecto, cuando esto ocurra quedará
plasmado en el informe de seguimiento y control.

A medida que las tareas finalicen se acudirá a la gestión de calidad para completar las tablas
aclarando si se ha cumplido o si es necesario realizar cambios, detallándolo en la gestión de
cambios.

El resto de bocetos pueden ser consultados en el anexo 1.

Fecha de revisión
¿Necesita una revisión posterior?
Observaciones globales
INTRANET
Requisito Cumplimiento Observaciones
¿Diferencia roles? SÍ/NO
¿Puede el administrador de la intranet editar SÍ/NO
los permisos de los roles?
¿Bilingüe? SÍ/NO
¿Responsive? SÍ/NO
¿Muestra un blog con noticias? SÍ/NO
¿Permite el envío de mensajes entre SÍ/NO
usuarios?
¿Posee una página personal de entrada para SÍ/NO
cada usuario?
¿Permite gestionar salas? SÍ/NO
¿Permite gestionar eventos? SÍ/NO
¿Permite la gestión documental? SÍ/NO
¿Permite publicar quejas y sugerencias SÍ/NO
anónimas?
Tabla 5. Tabla para la gestión de calidad de la intranet

~ 13 ~
Gestión de comunicación
En la tabla 6 se muestra cómo y en qué horarios se va a establecer la comunicación con el
cliente según si el objetivo de la comunicación es informar, pedir información o llegar a un
acuerdo. La tabla de gestión de comunicación con el tutor puede ser consultada en el anexo 2.

Interesado Informar Pedir información Llegar a un acuerdo

Cliente Asíncrono Asíncrono Síncrono
Hotmail, correo de Hotmail, correo de Reuniones
Hiberus Hiberus Lunes-jueves de
Lunes-viernes de Lunes-viernes de 9:00 a 14:00
8:00 a 20:00 8:00 a 20:00
Síncrono Síncrono
Reuniones Reuniones
Lunes-jueves de Lunes-jueves de
9:00 a 14:00 9:00 a 14:00
Tabla 6. Tabla de la gestión de comunicaciones

Gestión de riesgos
En la tabla 7 se recogen posibles riegos que pueden surgir durante el desarrollo del proyecto.
Los riesgos se encuentran categorizados según el tema con el que están relacionados. También
se indica la estrategia de prevención, la estrategia de minimización y el plan de contingencia.

El resto de las tablas de riesgos pueden ser consultadas en el anexo 3.

RIESGOS CON EL CLIENTE O TUTOR

Riesgo Estrategia de Estrategia de Plan de contingencia
prevención minimización
Cambio de Reunión exhaustiva Realizar un análisis de Realizar las acciones
requisitos con el cliente para requisitos flexible. recogidas en el plan de
establecer los gestión de cambios.
requisitos y sus
prioridades. Compartir
un documento con el
cliente donde se
encuentren los
requisitos detallados
para que no den lugar
a confusiones.
Baja del No se puede prevenir Varios empleados de la Establecer a otro
representante que no ocurra. misma empresa deben empleado de la misma
del cliente estar informados sobre empresa como nuevo
todo lo relativo al cliente.
proyecto.
Reuniones con el Realizar guiones para Pedir al cliente/tutor Realizar de nuevo otra
cliente/tutor la reunión. por correo que aclare reunión pero esta vez
desaprovechadas Ensayar las reuniones. los aspectos más prepararla
importantes para correctamente con
continuar. anterioridad.
Tabla 7. Tabla de gestión de riesgos con el cliente o tutor

~ 14 ~
Gestión de cambios
Durante el desarrollo del proyecto pueden ocurrir cambios, los cuales quedarán reflejados en
el informe de seguimiento y control. Cuando un cambio suceda deberá ser estudiado y tras ello
ser aprobado o rechazado, por lo que a continuación se detallará la forma en la que se decidirá
si un cambio es aprobado o rechazado.

Cuando el cambio sea pequeño y por lo tanto no implique editar la planificación, se aprobará,
se documentará en el informe de seguimiento y control, se notificará al cliente y se llevará a
cabo.

Cuando el cambio sea mayor será estudiado. Si este supone un gran cambio en el alcance y en
la planificación, se realizará una reunión con el cliente donde se decidirá de que requisito se
puede prescindir para poder abordar el cambio o si ese cambio es viable. Tras ello, el estudio
realizado y la decisión quedarán plasmados en el informe de seguimiento y se actualizarán
todos los documentos a los que el cambio influya.

Cuando un paquete de trabajo se dé por terminada, será necesario comprobar que cumple la
calidad, detallada en el apartado de gestión de calidad. Si no se cumple será, necesario
gestionar y detallar los cambios necesarios para alcanzarla.

Si durante el desarrollo del proyecto se producen desviaciones de más de 10 horas respecto a

la planificación inicial será necesario realizar ajustes en la planificación de las tareas y
dependiendo de la dimensión del cambio puede originar ajustes en el alcance, si esto ocurre se
abordará de la forma descrita anteriormente.

Analisis de requisitós
Análisis previo
Para recoger los requisitos con mayor certeza ha sido necesario realizar un análisis de las
opciones que ofrece el mercado. Por ello, cuando realicé la primera reunión con el cliente
donde establecimos unos requisitos iniciales, investigué si existían herramientas o módulos
con los que poder abordar los requisitos. Si no existían, busqué posibles alternativas con las
que cumplirlos de manera diferente y si aun así tampoco había alternativas debería programar
lo necesario a medida.

Por ejemplo, inicialmente el cliente me pidió poder realizar avisos entre usuarios. Busqué
opciones que me permitieran realizarlo pero no existía nada que cumpliera con los requisitos,
así que busque alternativas. Entre ellas encontré un módulo que me permitía enviar mensajes
entre usuarios a través de la intranet. Me pareció una buena opción que cumplía con todos los
requisitos pedidos por el cliente. Así que en la siguiente reunión con él, le propuse el cambio y
este aceptó.

~ 15 ~
Definición de requisitos
Funcionales

R1: Diferenciar roles para los usuarios de la intranet. Por lo que un usuario, dependiendo del
rol al que pertenezca, tendrá acceso a determinadas funciones de la intranet.
R1.1: Los roles a diferenciar son: director, sub-director, administración colegio,
coordinador bachillerato, coordinador E.S.O, coordinador primaria, profesor
bachillerato, profesor E.S.O, profesor primaria, profesor infantil, padre, alumno y
administrador intranet.
R1.2: Registro centralizado de los usuarios y su rol.
R1.3: La concesión y denegación de privilegios será dinámica, es decir, en cualquier
momento el administrador de la intranet podrá editar los privilegios concedidos
inicialmente.
R2: Mostrar un blog con diferentes noticias.
R2.1: Cada noticia contendrá un título, una descripción y como opcional se podrán
añadir fotos y/o documentos.
R2.2: La visibilidad de las noticias podrá ser seleccionada, es decir, una noticia podrá
ser vista por un usuario siempre y cuando pertenezca a un rol con privilegios para ello.
R2.2: Los roles director, sub-director, administración colegio y cualquiera de los
coordinadores tendrá permisos para publicar, editar y eliminar noticias.
R3: Permitir el envío de mensajes privados entre los usuarios dentro de la intranet.
R3.1: Un usuario puede enviar un mensaje a un usuario concreto.
R3.2: Un usuario puede enviar un mensaje a varios usuarios concretos.
R3.3: Un usuario puede enviar un mensaje a los usuarios pertenecientes a un rol.
R3.4: Cuando un usuario reciba nuevos mensajes privados, las notificaciones serán
mostradas a la entrada de la intranet informando sobre ello.
R3.5: Los usuarios podrán responder a un mensaje privado estableciendo un flujo de
conversación.
R3.6: Los roles director, sub-director, administración colegio, y cualquiera de los
coordinadores y de los profesores tendrá permisos para enviar mensajes.
R3.7: Un usuario con permisos puede bloquear la recepción de mensajes de varios
usuarios.
R4: Publicar sugerencias anónimas, es decir, cualquier usuario podrá escribir sugerencias y
estas quedarán reflejadas en una tabla.
R5: Crear un página personal de entrada para los usuarios donde se muestren sus mensajes
privados, las noticias recientes y los nuevos tweets publicados por el colegio.
R5.1: Permitir la personalización de la página personal de entrada dependiendo del
usuario.
R6: Permitir la gestión de salas, donde un usuario cuyo rol sea director, sub-director o
cualquiera de los coordinadores podrá reservar una sala, modificar o eliminar la reserva.
R6.1: Especificar obligatoriamente la sala a reservar, una fecha, hora de inicio y fin y un
motivo.
R6.2: Permitir especificar invitados. Estos invitados pueden ser usuarios concretos o los
usuarios de un rol.
R6.3: Permitir especificar invitados externos a la intranet.

~ 16 ~
 R6.4: Permitir registrar documentación.
R6.5: No podrá estar una misma sala, en una misma fecha y en unas mismas horas,
reservada dos veces.
R6.6: Cuando una sala sea reservada, los datos de la reserva quedarán registrados en
un calendario común.
R6.7: Cuando una reserva de sala sea creada, modificada o eliminada, si tiene
asociados invitados, se enviarán avisos automáticamente a los mismos.
R7: Permitir la gestión de eventos, donde un usuario cuyo rol sea director, sub-director o
cualquiera de los coordinadores podrá crear, modificar o eliminar un evento.
R7.1: Especificar obligatoriamente el nombre, la fecha de inicio y fin, la hora de inicio y
fin y si este evento pertenece o no a un grupo de eventos.
R7.2: Un evento podrá pertenecer a un grupo de eventos formando entre todos un
gran evento o formar él un pequeño evento.
R7.3: Opcionalmente permitir reservar salas.
R7.4: Opcionalmente permitir especificar invitados externos e internos a la intranet.
R7.5: Opcionalmente permitir registrar documentación.
R7.6: Opcionalmente permitir publicar información sobre el evento en distintas redes
sociales.
R7.7: Permitir la repetición de eventos diaria o semanalmente.
R7.8: Podrán existir varios eventos con mismas fechas y mismas horas.
R7.9: Opcionalmente permitir crear un evento con la información recogida de la
reserva de la sala.
R7.10: Podrá existir un evento sin salas reservadas y una reserva de una sala que no
está asociada a un evento.
R7.11: Cuando un evento sea creado, los datos del mismo quedarán registrados en un
calendario común.
R7.12: Cuando un evento sea creado, modificado o eliminado, si este tiene asociados
invitados, se enviarán avisos automáticamente a los mismos.
R7.13: Existirá la posibilidad de filtrar los eventos según diferentes criterios.
R7.13.1: Uno de los criterios para filtrar los eventos será el grupo de eventos al
que pertenecen.
R7.13.2: Otro de los criterios para filtrar eventos será la selección de un
intervalo de fechas.
R7.14: Permitir la gestión del pre evento, donde el usuario podrá añadir funcionalidad
adicional al evento correspondiente. Esto será opcional.
R7.14.1: Registrar documentación.
R7.14.2: Seleccionar invitados.
R7.14.3: Reservar las salas a utilizar.
R7.14.4: Especificar la fecha de inicio.
R7.15: Permitir la gestión del post evento, donde el usuario podrá añadir funcionalidad
adicional al evento correspondiente. Esto será opcional.
R7.15.1: Registrar documentación.
R7.15.1.1: Almacenar informes de seguimiento del evento que recojan
los problemas surgidos durante el desarrollo del evento y las acciones
llevadas a cabo.

~ 17 ~
 R7.15.1.2: Almacenar informes de evaluación del evento.
R7.15.2: Enviar por correo enlaces a formularios de satisfacción a los invitados
para conocer su opinión.
R7.15.3: Enviar correos de agradecimiento.
R7.15.4: Reservar las salas a utilizar.
R7.15.5: Seleccionar invitados.
R7.15.6: Especificar la fecha de finalización.
R8: Permitir la gestión de documentos a los usuarios con rol de director, sub-director,
administración colegio y cualquiera de los coordinadores y de los profesores.
R8.1: Los documentos con el formato PDF podrán ser manipulables.
R8.1.1: Permitir añadir un documento PDF a otro PDF generando uno nuevo.
R8.1.2: Dividir un documento especificando un intervalo o una página.
R8.1.3: Insertar en un documento una página concreta.
R8.1.4: Extraer páginas específicas de un documento.
R8.1.5: Eliminar páginas específicas de un documento.
R8.1.6: Incluir marcas de agua en un documento.
R8.1.7: Cifrado y descifrado documentos.
R8.2: Permitir utilizar Google Docs para crear y/o editar el contenido de los
documentos.
R8.3: Permitir crear carpetas.
R8.4: Existirá control de versiones de los documentos.
R8.5: Permitir ver propiedades de documentos y carpetas.
R8.6: Permitir eliminar carpetas y documentos.
R8.7: Incluir una zona de descargas para los documentos públicos, accesibles a todos
los usuarios independientemente del rol, y para los documentos privados, visibles
únicamente a los roles especificados en cada documento de descarga. Los usuarios con
rol de director, sub-director, administración colegio o cualquiera de los coordinadores
y de los profesores tiene privilegios para crear nuevos documentos en la zona de
descargas.
R9: Ofrecer la información de la intranet en al menos dos idiomas: castellano e inglés.
R10: Tener un tema responsive instalado, es decir, adaptar la apariencia de la intranet al
dispositivo que se esté utilizando para visualizarla.

No funcionales

R11: La construcción debe ir desarrollándose de manera incremental para ofrecer paquetes

que den valor al cliente.
R12: No pagar por ninguna licencia.
R13: Los entregables dados al cliente deben ser máquinas virtuales con Ubuntu Server 14.04
que contengan todo lo necesario para funcionar sin tener que realizar instalaciones.

Análisis de interfaces y navegabilidad

En los bocetos mostrados a continuación se representa el análisis de las interfaces de la
intranet y su navegabilidad mediante números. El resto de los bocetos pueden ser consultados
en el anexo 4.

~ 18 ~
1. En el siguiente boceto se muestra la interfaz que tendrá la gestión de salas, donde se
mostrará un calendario mensual que recoja la información de todas las reservas
realizadas. El usuario podrá cambiar la vista del calendario a semanal, diaria o anual.
Además podrá moverse por el calendario con los botones previo y siguiente. Cuando el
usuario seleccione una reserva concreta podrá, si tiene permisos, editarla o eliminarla.
La opción de reservar sala se mostrará a aquellos usuarios con permisos.

2. En el siguiente boceto se muestra la interfaz que tendrá la creación y edición de la

reserva de salas. Se mostrará un formulario donde el usuario deberá rellenar al menos
los campos obligatorios (señalados con ‘*’). La información que el usuario podrá
rellenar sobre la reserva es la sala, la fecha, la hora de inicio y fin, el motivo, especificar
los invitados, registrar documentación y seleccionar si crear como un evento.

~ 19 ~
Casos de uso
En la figura 3 y 4 se muestra el diagrama de los casos de uso y en la tabla 8 una breve
documentación de alguno de los casos de uso. Existen casos de uso como iniciar sesión que no
se encuentran contemplados ya que son dados por defecto por Drupal. El resto de las
documentaciones de los casos de uso pueden ser consultadas en el anexo 5.

Figura 3. Diagrama de casos de uso (I)

~ 20 ~
 Figura 4. Diagrama de casos de uso (II)

Nombre Traducir contenido

Actores Administrador intranet
Descripción El administrador de la intranet podrá editar las traducciones de los contenidos
de la intranet.
Nombre Leer noticia
Actores Público, alumno, padre, profesor infantil/primaria/E.S.O/bachillerato,
administración colegio, coordinador primaria/E.S.O/bachillerato, sub-director,
director y administrador intranet
Descripción El usuario podrá leer las noticias publicadas, tanto en su forma resumida como
en su forma detallada, a las cuales tenga privilegios.
Nombre Gestionar documentos
Actores Profesor infantil/primaria/E.S.O/bachillerato, administración colegio,
coordinador primaria/E.S.O/bachillerato, sub-director, director y administrador
intranet
Descripción El usuario podrá gestionar los documentos que se encuentren dentro de su
directorio, es decir aquellos documentos a los que tiene acceso.
Nombre Editar evento
Actores Coordinador primaria/E.S.O/bachillerato, sub-director, director y administrador
intranet
Descripción El usuario podrá editar un evento existente, siempre y cuando ese evento haya
sido creado por él.
Tabla 8. Documentación de los casos de uso

~ 21 ~
Disenó
Mensajes privados
Los mensajes privados estarán divididos en distintas funcionalidades.

La primera, el buzón de mensajes, que mostrará a todos los usuarios autenticados tres tablas,
una con los mensajes enviados, otra con los recibidos y la última con la unión de todos los
mensajes. Estas tablas contendrán breve información sobre los mensajes: el asunto, los
participantes, la cantidad de mensajes que componen la conversación y la última fecha de
actualización. El usuario podrá acceder al contenido de un mensaje pulsando sobre él.

La redacción y eliminación de mensajes serán otras de las funcionalidades. La primera

únicamente estará accesible a los usuarios que pertenezcan al rol de director, sub-director,
administración del colegio, a cualquiera de los coordinadores o a de los profesores y la
segunda estará accesible para todos los usuarios autenticados. Cuando un usuario redacte un
mensaje deberá rellenar obligatoriamente 3 campos: los destinatarios, el asunto y el
contenido.

Otra de las funcionalidades será la de poder realizar una selección múltiple de destinatarios
donde los usuarios deberán escribir los nombres de los usuarios o los nombres de los roles.
Además, los usuarios podrán crear un flujo de conversación respondiendo a los mensajes.

La última de las funcionalidades disponibles en los mensajes privados será la notificación a los
usuarios de nuevos mensajes recibidos. Esta notificación mostrará la cantidad de mensajes que
tiene sin leer.

Buzón de quejas y sugerencias

El buzón de quejas y sugerencias estará disponible para todos los roles y estará compuesto por
dos partes.

La primera será un formulario donde el usuario obligatoriamente deberá seleccionar si es una

queja o una sugerencia lo que quiere publicar, introducir un título e introducir el contenido.

Opcionalmente podrá introducir observaciones y/o incluir una imagen, la cual debe ser menor
de 2 MB y cuyo formato ser gif, jpg, jpeg o png.

La segunda parte será una tabla que contendrá la información de las quejas y sugerencias.
Entre esta información se encontrará la fecha de publicación, el tipo, el título, el contenido, las
observaciones (si las tiene), el enlace a la imagen (si la tiene) y dos posibles operaciones a
realizar sobre la publicación, editar y eliminar. Estas operaciones solo estarán disponibles para
aquel usuario que sea autor de la queja o sugerencia o para el administrador de la intranet.

Además la tabla se deberá paginar una vez que el número de quejas o sugerencias supere la
cantidad de 10. También, aparecerá un breve mensaje bajo la tabla indicando la cantidad de
publicaciones mostradas y el total de las mismas.

~ 22 ~
Diagrama de actividad ‘publicar queja o sugerencia’

Blog de noticias
En primer lugar, habrá un formulario donde el usuario, cuyo rol sea director, subdirector o
cualquiera de los coordinadores o profesores, deberá obligatoriamente introducir el título y el
contenido. Opcionalmente podrá incluir un resumen del contenido, introducir documentos de
su ordenador personal cuyo formato sea: txt, doc, odt, pdf, rtf, docx e incluir una imagen, la
cual debe ser menor de 2 MB y cuyo formato ser gif, jpg, jpeg o png.

~ 23 ~
En segundo lugar, se mostrará una página con todas las noticias de forma resumida. Esta
contenderá el título, el resumen del contenido, la imagen reducida de la notica (si la tiene) y
un enlace a la noticia completa. Los resultados de la página estarán paginados una vez que se
supere la cantidad de 5.

La tercera parte será una nueva página con toda la información de una noticia específica. Entre
esta información se encontrará el título, el contenido, la imagen (si la tiene), el documento
adjuntado (si lo tiene) y las operaciones a realizar, editar y eliminar. Estas operaciones solo
estarán disponibles para aquel usuario que sea autor de la noticia.

La visibilidad de cada una de las noticias será dinámica, es decir, el autor de la misma será el
encargado de especificar qué roles tienen acceso a visualizarla.

Página personal de entrada

En primer lugar en la página de inicio de Drupal se mostrarán en la parte central de la pantalla
los mensajes privados del usuario correspondiente, como se ha descrito en el diseño de los
mensajes privados.

En segundo lugar aparecerá un breve resumen de las noticias más recientes en la parte
izquierda de la pantalla, como se ha descrito en el diseño del blog de noticias.

Por otra parte se mostrarán todos los Tweets publicados por el colegio en la parte derecha de
la pantalla.

Integración Drupal con Alfresco

En Alfresco existirán tantos sitios y grupos de usuarios como roles haya creados en la intranet.
Cada uno de estos grupos de usuarios deberá estar asociado a su sitio correspondiente. Los
usuarios solo tendrán acceso a su repositorio personal y a los sitios que le corresponden, por lo
que el resto de carpetas estarán ocultas.

Los usuarios podrán acceder fácilmente a la manipulación de PDF y la utilización de Google

Docs desde cualquiera de los directorios en Alfresco.

Desde Drupal los usuarios tendrán acceso a sus directorios de Alfresco sin necesidad de tener
que autenticarse con Alfresco. Estos podrán moverse por el árbol de directorios pudiendo
realizar determinadas acciones sobre ellos y sobre los archivos. Estas acciones incluyen la
posibilidad de eliminar y crear tanto carpetas como ficheros.

Por último, en Drupal existirá una zona de descargas que incluirá todas las descargas
publicadas. La información mostrada de cada una de las descargas será el título, el documento
de descarga y las operaciones a realizar, editar y eliminar. Estas operaciones solo estarán
disponibles para aquel usuario que sea autor de la noticia. Los resultados de la página estarán
paginados una vez que se supere la cantidad de 5.

La visibilidad de cada una de las descargas será dinámica, es decir, el autor de la misma será el
encargado de especificar que roles tienen acceso a visualizarla.

~ 24 ~
Gestión de salas
Modelo E/R

(0,N) (1,1) (0,N) INVITA_ (0,N)

RESERVA
A_SALAS

SALA RESERVA_SALA INVITADO

id nombre nombre id

id inicio fin motivo autor

Diseño lógico

SALA
id nombre

RESERVA_SALA
id inicio fin motivo autor sala evento
CF: SALA CF: EVENTO

INVITADO
id correo

INVITA_A_SALAS
reserva invitado
CF: RESERVA_SALA CF: INVITADO

En primer lugar, habrá un formulario donde el usuario, cuyo rol sea director, subdirector o
cualquiera de los coordinadores, deberá obligatoriamente seleccionar la sala a reservar,
introducir una fecha y hora de inicio, una fecha y hora de fin y el motivo de la reserva.
Opcionalmente podrá registrar invitados, documentación y elegir si quiere crear o no un
evento con la información de la reserva.

Los invitados a una reserva de sala podrán registrarse de varias maneras. En la primera el
usuario deberá escribir los nombres de los usuarios de la intranet. En la segunda el usuario
podrá seleccionar todos los usuarios que pertenezcan a algún rol. Y por último, el usuario
podrá escribir los correos de invitados externos.

En segundo lugar, se mostrará un calendario mensual que recoja todas las reservas realizadas.
La vista de este calendario podrá ser modificada por día o por semana. La información
mostrada en el calendario de cada una de las reservas será el intervalo de tiempo, la sala
reservada y el motivo.

~ 25 ~
Desde la vista del calendario los usuarios podrán acceder a la creación y a la edición de una
reserva de sala. Las operaciones de edición y eliminación solo estarán disponibles para
aquellos usuarios que sean autor de la reserva. Si un usuario no autorizado trata de realizar las
operaciones, un mensaje de aviso le será mostrado.

En la edición se mostrará un formulario similar al de creación además de un enlace a la

eliminación de la misma donde se pedirá al usuario que confirme antes de eliminar
definitivamente.

Tanto en la creación como en la edición se comprobará que no se encuentra la sala solicitada

ya reservada en un mismo intervalo de fechas. Si existe coincidencia, la reserva no será creada
o editada y un mensaje de aviso será mostrado al usuario.

Además, de manera invisible al usuario cuando una reserva sea creada, editada o eliminada si
esta tiene asociados invitados internos se les enviarán mensajes privados a través de la
intranet y si tiene asociados invitados externos se les enviarán correos. El asunto del mensaje
será cuál de las acciones ha sido llevada a cabo y el contenido del mensaje será que sala ha
sido reservada, en que intervalo de fechas, porque motivo y si el evento tiene documentación
adjuntada se enviarán la correspondiente documentación.

Por último, las reservas mostradas en el calendario podrán ser filtradas cuando el usuario
seleccione que reservas de que sala desea que sean mostradas.

Gestión de eventos
Modelo E/R
fin_repetición
padre
PERTENECE
(0,N) repetición
E
hijo (0,1)
EVENTO
(0,N) autor
(0,N)
INVITA_A
_EVENTOS nombre

fin
id inicio
CREA
(0,N)
INVITADO
(0,1)
RESERVA_SALA

Diseño lógico

EVENTO
id inicio fin nombre autor repetición fin_ repetición pertenece
CF: EVENTO

~ 26 ~
INVITA_A_EVENTOS
evento invitado
CF: EVENTO CF: INVITADO

En primer lugar, habrá un formulario donde el usuario, cuyo rol sea director, subdirector o
cualquiera de los coordinadores, deberá obligatoriamente introducir un nombre para el
evento, una fecha y hora de inicio, una fecha y hora de fin y si este evento pertenece o no a un
grupo de eventos. Opcionalmente podrá registrar invitados, documentación, elegir si quiere
reservar salas asociadas a ese evento, si quiere publicar la información del evento en alguna
red social y si quiere que este evento se repita diariamente o semanalmente. Si el evento es
repetido el usuario obligatoriamente deberá elegir una fecha de fin de repetición.

Los invitados a un evento podrán registrarse de varias maneras. En la primera el usuario

deberá escribir los nombres de los usuarios de la intranet. En la segunda el usuario podrá
seleccionar todos los usuarios que pertenezcan a algún rol. Y por último, el usuario podrá
escribir los correos de invitados externos.

En segundo lugar, se mostrará un calendario mensual que recoja todos los eventos existentes.
La vista de este calendario podrá ser modificada por día o por semana. La información
mostrada en el calendario de cada uno de los eventos será el intervalo de tiempo y el nombre.

Desde la vista del calendario los usuarios podrán acceder a la creación y a la edición de un
evento. Las operaciones de edición y eliminación solo estarán disponibles para aquellos
usuarios que sean autor del evento. Si un usuario no autorizado trata de realizar las
operaciones, un mensaje de aviso le será mostrado.

En la edición se mostrará un formulario similar al de creación además de un enlace a la

eliminación del mismo donde se pedirá al usuario que confirme antes de eliminar
definitivamente.

Además, de manera invisible al usuario cuando un evento sea creado, editado o eliminado si
este tiene asociados invitados internos se les enviarán mensajes privados a través de la
intranet y si tiene asociados invitados externos se les enviarán correos. El asunto del mensaje
será cuál de las acciones ha sido llevada a cabo y el contenido del mensaje será el nombre del
evento, en que intervalo de fechas tiene lugar y si el evento tiene documentación adjuntada se
enviarán la correspondiente documentación.

Por último, los eventos mostrados en el calendario podrán ser filtrados cuando el usuario
seleccione porque evento y que intervalo de tiempo desea filtrar.

Ímplementación
A continuación se describen los problemas más destacables surgidos durante el desarrollo. El
resto del desarrollo de la implementación puede ser consultado en el anexo 6.

~ 27 ~
Problema con la integración entre Drupal y Alfresco
El módulo CMIS API que ofrece Drupal permite configurar por defecto una cuenta de Alfresco.
De esta manera todos los usuarios desde la intranet accederán al mismo repositorio de
documentos.

Para tratar de solventar esto fue necesario comprobar cómo funciona el código de CMIS API.
Una vez comprendidas las partes del código que ejecutaban la autenticación en Alfresco había
que obtener información de dónde se encontraba la contraseña en claro del usuario conectado
para poder transferirla de un módulo a otro.

En Drupal, el módulo que contiene el código para el login es user. Dentro de este, una vez
obtenida la contraseña, se almacena en una variable de sesión para poder obtenerla más
adelante por el otro módulo. La contraseña no puede ser guardada en claro en una variable de
sesión por lo que esta es encriptada antes de almacenarla.

Una vez almacenada la contraseña es recuperada y desencriptada de manera que ya se puede

realizar la autenticación en Alfresco de manera invisible al usuario.

Problema con la vista de las noticias

El problema surgido es que la vista por defecto de las noticias no era nada similar a la acordada
en los bocetos con el cliente. Drupal ofrece el módulo Views para la creación de vistas pero
realizándolo de esta manera surgían dos problemas, el primero era que los usuarios
visualizarían diferentes vistas para una misma noticia y el segundo era que el boceto de la
interfaz no era posible de realizar.

~ 28 ~
En Drupal, el tema que se encuentra instalado tiene una vista por defecto para todos los
contenidos independientemente del tipo. Por lo tanto, es necesario crear un nuevo fichero que
contenga la estructura para un tipo de contenido específico. Dentro del nuevo archivo node—
noticias.tpl.php se respeta la estructura utilizada en otras páginas de Drupal.

Por defecto, en las páginas se muestran unas pestañas al autor de la noticia donde puede
editar la noticia y el acceso.

En los bocetos del análisis de la interfaz se acordó que la edición y eliminación estarían
disponibles a través de botones en la parte inferior de cada noticia. Para eliminar estas
pestañas es necesario editar el archivo que contiene la estructura general de las páginas. Estas
pestañas solo serían eliminadas cuando la página mostrada fuese un contenido (nodo) del tipo
noticia.

Posteriormente, los botones de editar y eliminar en las noticias podían ser incluidos
directamente en la estructura de las noticias, controlando que estos se mostrasen únicamente
a los autores de la misma. Por ello, había que realizar modificaciones en el archivo node—
noticias.tpl.php añadiendo las siguientes líneas de código donde se comprueba si el autor del
nodo es el actual usuario conectado.

Problema con la zona de descargas

Para publicar en Drupal documentos almacenados en Alfresco es posible realizarlo de dos
formas. La primera, publicar un enlace al documento almacenado en Alfresco.

~ 29 ~
Pero, de esta forma los usuarios deben tener privilegios asociados a estos documentos en
Alfresco para poder acceder a ellos. Esto no es lo deseado porque el cliente solicitó poder
crear descargas públicas de manera que usuarios como los alumnos y los padres que no tiene
cuenta en Alfresco pudieran visualizar la descarga sin problemas.

La segunda opción consiste en obtener el documento de Alfresco y almacenarlo en el servidor

para que los usuarios pudiesen acceder a él sin necesidad de tener privilegios asociados. De
esta forma, es posible controlar la visibilidad de cada una de las descargas.

El primer paso a realizar es la creación de un nuevo tipo de contenido, llamado documentos, y

configuración de los distintos campos que formarán la descarga, estos serán el título de la
descarga y el documento de Alfresco a publicar.

Tras ello, es necesario crear un nuevo archivo node—documentos.tpl.php (como en la vista de

las noticias) para que la interfaz de la zona de descargas fuese como en los bocetos del análisis
de interfaces.

Drupal a través del módulo Views ofrece la posibilidad de generar una nueva página cuyo
contenido sea todas descargas existentes pero que a su vez este contenido sea dinámico según
las restricciones de visibilidad de cada una de las descargas. También posibilita la ordenación y
la paginación de los resultados.

Para obtener un documento de Alfresco, almacenarlo en el servidor y crear un contenido con

ese documento para poder editar y eliminar posteriormente, ha sido necesario programar un
módulo personalizado.

Primer paso, la creación del archivo .info, es decir, el archivo de texto que contendrá la
información de definición del módulo.

Segundo paso, la implementación del hook_menu de Drupal para definir cuáles serán las
respuestas a determinadas URL. Dentro de este método estarán especificadas las tres posibles
URL, para la creación, para la edición y para la eliminación.

~ 30 ~
Con el atributo ‘page callback’ se especifica la función que será llamada cuando el usuario
acceda a la URL, en este caso al usuario se le mostrará un formulario. El nombre de la función
que devuelve el formulario se especifica en el atributo ‘page arguments’. El número 2 que se
encuentra dentro de este atributo indica en qué posición de la URL se encontrará la variable
que indica el contenido a editar.

A través del atributo ‘file’ se determina en qué fichero se encuentra declarada la función. Con
el atributo ‘access arguments’ se determinan los permisos por los que se va regir para dar
acceso a los distintos roles. Con el último atributo se establece que no se creará un enlace en
el menú para esta URL.

Form API de Drupal ofrece la posibilidad de crear avanzados formularios desde código. En el
campo utilizado para seleccionar cuál de los archivos de Alfresco va a ser publicado se utiliza
uno de los JavaScript que el módulo CMIS API proporciona. A este JavaScript se le especifica
que la ventana emergente que genere sea una vista del repositorio raíz del usuario.

Una vez que el usuario selecciona el archivo, el JavaScript almacena en la variable title el
nombre del archivo y en la variable path el id del objeto del repositorio seleccionado para
poder recuperarlo posteriormente.

~ 31 ~
Después, cuando el usuario pulsa el botón de confirmar, se evalúa el código de
hook_form_submit donde un nuevo nodo del tipo documento es creado con la información
dada desde el formulario. Cuando el contenido del documento seleccionado haya sido
recuperado, se creará un nuevo fichero con este contenido en la carpeta pública del servidor.
Tras ello, si no ha ocurrido ningún problema durante la creación, el usuario es redirigido a la
página general de las descargas.

El formulario de edición es similar al de creación con la excepción de que hay un campo

adicional donde el usuario puede consultar cual es el documento que se encuentra asociado a
la descarga a editar.

Cuando un usuario confirma la edición de una descarga se comprueban que campos han sido
modificados. Para que el documento asociado a la descarga no se pierda cuando solo el título
es editado es necesario recuperar el documento y asociarlo de nuevo a la descarga.

Si el usuario no quiere editar el documento debe dejar el campo vacío. Así si el campo tiene
contenido el nuevo archivo es recuperado y almacenado como en el proceso de creación y
para que no queden documentos huérfanos el documento remplazado es eliminado.

~ 32 ~
En la eliminación de una descarga se muestra al usuario un mensaje de confirmación.

Si finalmente el usuario confirma la eliminación se elimina tanto el nodo como el fichero.

Tanto en la eliminación como en la edición se comprueba que el nodo recuperado sea del tipo
documentos y que el usuario que accede a él es realmente el autor del contenido. Si no
coincide con el autor, el usuario es redirigido a una página de acceso denegado. Y si el nodo
recuperado no es del tipo documentos el usuario es redirigido a la zona de descargas
mostrando un mensaje de aviso. Esto es realizado para evitar que a través de la URL un usuario
acceda a donde no corresponde.

Problema con el menú dinámico

La creación de un menú dinámico cuyos elementos sean accesos directos a los directorios más
importantes del repositorio de cada usuario solo es posible mediante la programación de un
módulo personalizado.

El módulo CMIS API proporciona varios métodos, en este caso los que son de ayuda son el
método que devuelve el repositorio raíz de Alfresco y el método que devuelve todos los hijos
de un repositorio determinado.

Los directorios que formarán el menú serán todos los sitios creados en Alfresco y el espacio
personal del usuario. Para ello, a través del identificador del directorio que contiene todos los
sitios podemos obtener la ruta y el título de los sitios existentes.

~ 33 ~
Inicialmente probé con la creación de los menús mediante el uso de hook_user_login donde
cada vez que un usuario inicie sesión en Drupal se creará el menú con los sitios a los cuales el
usuario tiene acceso y con su repositorio personal. El problema de utilizar este método es que
no se crea un menú únicamente para el usuario recién conectado sino que es creado para
todos los usuarios de la intranet. Por lo que un usuario puede ver que existe una carpeta a la
cual no tiene acceso, si este intenta acceder a ella la intranet le mostrará un error indicando
que no tiene permisos.

Drupal ofrece hook_menu y hook_permission que permiten solventar el anterior problema.

Mediante hook_menu se pueden crear menús una vez que el módulo es instalado, así que se
creará un menú con todos los sitios disponibles y después a través del atributo ‘access
arguments’, anteriormente explicado, y del método hook_permission se puede controlar la
visibilidad de los elementos del menú sin que interfiera un usuario con otro.

~ 34 ~
Problema con el campo invitados internos
Tanto en la reserva de una sala como en los eventos se pueden asociar invitados internos de la
intranet a través del nombre del usuario correspondiente. El cliente en este campo pidió si era
posible que el campo ofreciera resultados cada vez que el usuario escribiese una tecla y si este
elegía un resultado el campo se autocompletara.

FORM API de Drupal ofrece en los campos de tipo textfield la propiedad autocomplete_path. A
esta propiedad se le asocia la ruta en la que se encuentra el método AJAX que devuelve los
resultados deseados.

En este caso como dentro del campo pueden estar escritos varios nombres separados por
comas solo será necesario autocompletar el último nombre escrito por el usuario. El último
valor escrito será obtenido a través de los métodos drupal_explode_tags y array_pop.

Después, para devolver todos los nombres de usuarios que coincidan con el valor escrito es
necesario ejecutar una consulta a la base de datos y con los resultados obtenidos comprobar
que no se encuentran ya en el campo. Una vez que el usuario seleccione uno de los resultados
proporcionados la coma será automáticamente escrita.

Posteriormente, descubrí por casualidad que Drupal ofrece el módulo Chosen que permite
realizar lo anterior pero evitando tener que comprobar si el usuario introduce cosas erróneas.
Además la interfaz que proporciona es más amigable para el usuario.

~ 35 ~
Problema con la repetición de eventos
A través del formulario de creación de eventos el usuario podrá seleccionar si desea repetir o
no un evento, eligiendo si será repetido diariamente o semanalmente. Si el usuario selecciona
cualquiera de las repeticiones, un nuevo campo aparecerá para que especifique la fecha de fin
de la repetición.

Para mostrar en el calendario todos los eventos, FullCalendar ofrece la posibilidad de declarar
una función como fuente de datos del calendario. En esta función se recogen de la base de
datos los eventos requeridos y se devuelve la representación JSON de los datos necesarios
para formar eventos en FullCalendar.

Para la programación repetida de eventos, FullCalendar proporciona la propiedad dow que

contiene los días de la semana en los que el evento es repetido. Esta permite generar
visualmente en el calendario tanto eventos diarios como semanales. A través de esta opción
solo es necesario almacenar en la base de datos el evento original, cuál es la frecuencia de
repetición y cuál es la fecha de final de repetición.

Esta opción tiene carencias. La primera es que es necesario jugar con la visualización de los
eventos porque esta propiedad los repite de manera infinita e incluso por duplicado. Para ello,
es necesario crear inicialmente el evento original y después si este es repetitivo, crear un
evento con las mismas características y con la propiedad dow. Como estos eventos a mostrar
pueden estar filtrados hubo que comprobar que aunque el original no se encontrara dentro
del rango solicitado en el filtro, si alguna de sus repeticiones sí, estas debían ser mostradas.
También era necesario comprobar que si se filtraba por una fecha inicial, si esta fecha era
posterior a la del evento, este no fuese mostrado en el calendario.

~ 36 ~
Posteriormente en el JQuery donde se encuentra la construcción del calendario hubo que
editar la opción eventRender para mostrar únicamente los eventos que se encuentran dentro
del rango correspondiente y evitar repeticiones.

El principal problema de esta solución es que si un evento es repetido, no es posible editar una
repetición únicamente, es decir, si una repetición es editada, todas las demás también. Esto es
debido a que en la base de datos solo se encuentra almacenado el evento origen. Un evento
repetido tampoco podrá tener sus propios invitados sino que tendrá los mismos que el evento
original en todo momento.

La solución a estos problemas es la creación en la base de datos de tantos eventos como

repeticiones quisiera crear el usuario.

Todos los eventos serán almacenados en la misma tabla de la base de datos pero el campo de
la repetición variará en función de si el evento es original o es una repetición. Si el evento es
original se almacenará NULL si no hay repetición, D si la repetición es diaria o S si la repetición
es semanal. Si el evento es repetido, se almacenará el id del evento original y la repetición
correspondiente.

~ 37 ~
Cuando un usuario cree un nuevo evento este será insertado como original en la base de
datos. Si el evento va a ser repetitivo, a través de un bucle se van editando las fechas y si aún
no se ha llegado a la fecha de fin de repetición, se añade un nuevo evento en la base de datos.
Para comparar correctamente las fechas es necesario incluir horas, minutos y segundos a la
fecha de fin de repetición. Todos los identificadores de los eventos son almacenados en un
array para asociarles posteriormente los mismos invitados que al evento original.

Tras añadir todos los eventos que correspondan, se comprueba si al evento le han asociado
invitados, documentación o quieren publicar la información del evento en alguna red social.

A la hora de editar existen diferentes situaciones. Si el usuario quiere editar un evento que no
tiene repeticiones podrá actualizar todos los campos como en la creación. Si a la hora de
editarlo selecciona que a partir de ese momento el evento sea repetitivo, los nuevos eventos
correspondientes serán almacenados como en la creación de los eventos.

Por el contrario, si el usuario selecciona editar únicamente el evento original de una repetición
o editar la repetición de un evento, podrá actualizar todos los campos excepto el relacionado
con la repetición.

Por último, cuando el usuario selecciona en un evento original editar todos sus eventos
repetidos habrá que realizar diferentes acciones dependiendo de la decisión de repetición. Sea
cual sea la decisión tomada el evento original será editado con los nuevos datos.

Si selecciona que un evento repetitivo deje de serlo, todos los eventos que sean repeticiones
del original serán eliminados.

~ 38 ~
Si selecciona en la edición que se repita de igual forma, los eventos existentes en la base de
datos serán obtenidos y actualizados mientras que la nueva fecha de fin de repetición no sea
sobrepasada por la fecha de los eventos. Si ya no existen más eventos en la base de datos y la
fecha de fin de repetición aún no es sobrepasada, nuevos eventos con los datos
correspondientes serán creados. Cuando la fecha de repetición haya sido sobrepasada, si aún
quedan eventos repetitivos en la base de datos, estos serán eliminados.

Si no, si selecciona distinta repetición a la original, todos los eventos repetitivos serán
eliminados y nuevos eventos serán insertados como en la creación de los eventos.

En la eliminación de eventos también pueden ocurrir diferentes situaciones.

La primera es que el evento que el usuario desea eliminar no es repetitivo o que aunque lo sea
el usuario únicamente desea eliminar un evento diferente al original. En este caso el evento es
eliminado de la base de datos.

~ 39 ~
Todos los eventos son eliminados de la base de datos si el evento es repetitivo y el usuario
desea eliminar tanto el evento original como todos los eventos repetidos.

Por otra parte, si el usuario únicamente desea eliminar el evento origen, es necesario realizar
diversas modificaciones en los eventos asociados para evitar errores en asociaciones con
reservas de sala o entre eventos. Primero se comprobará que existan eventos repetidos a
parte del original. Si no es así el evento original será eliminado y no será necesario realizar más
acciones.

Por el contrario si sí que existen eventos repetidos, el evento original actualizará todos sus
datos, incluso los invitados, por los datos del siguiente evento repetido tras él. Cuando esto
haya sido realizado el evento repetido será eliminado.

Seguimientó y cóntról
Tareas y desviaciones
En las tablas 9 y 10 se presenta la comparación de los tiempos estimados y las horas reales
dedicadas a la realización de las distintas tareas. Existen tareas donde las horas empleadas han
sido 0 puesto que realizarlo ha supuesto un coste de tiempo en minutos.

~ 40 ~
Tarea Horas Horas reales
estimadas empleadas
Plan de dirección de proyecto 2 2
Planificación proyecto 21 23
 Plan del alcance del proyecto 5 5
 Planificación tareas 12 14
 Plan de gestión 4 4
Lecciones aprendidas 4 1
Seguimiento y control 20 12
Reuniones 12 10
 Reuniones cliente 6 5
 Reuniones tutor 6 5
Blog de noticias 15 15
 Instalación y configuración módulos necesarios 14 14
 Pruebas 1 1
Mensajes privados 10 7
 Instalación y configuración módulos necesarios 9 6
 Pruebas 1 1
Gestión evento 70 53
 Diseño de la base de datos 6 4
 Creación de las tablas 2 1
 Programación módulo 60 45
 Pruebas 2 3
Gestión documental 30 47
 Instalación add-ons y configuración Alfresco 10 4
 Instalación y configuración módulos integración 10 20
 Configuración zona de descargas 8 20
 Pruebas 2 3
Personalización intranet 4 5
 Creación de roles 2 0
 Instalación tema responsive 1 5
 Pruebas 1 0
Traducción 10 7
 Preparar la intranet para las traducciones 2 2
 Realizar las traducciones en inglés y español 8 5
Página personal de entrada 10 5
 Instalación y configuración módulos necesarios 9 5
 Pruebas 1 0
Buzón de sugerencias 10 7
 Instalación y configuración módulos necesarios 9 6
 Pruebas 1 1
Gestión de salas 60 85
 Diseño de la base de datos 7 5
 Creación de las tablas 3 1
 Programación módulo 48 75
 Pruebas 2 4
Tabla 9. Comparación de tiempos (I)

~ 41 ~
Tarea Estimación en Horas reales
horas empleadas
Instalación infraestructura 3 3
 Drupal 2 2
 Alfresco 1 1
Análisis de requisitos 19 25
 Análisis inicial 3 3
 Definición de requisitos 4 5
 Análisis de interfaces 7 12
 Análisis de navegabilidad 2 1
 Casos de uso 3 4
Horas totales 300 307
Tabla 10. Comparación de tiempos (II)

A lo largo del proyecto han ido surgiendo cambios o problemas que han derivado en
desviaciones de los tiempos planificados. Los motivos de estas desviaciones son los siguientes:

 Desviación en el seguimiento y control. El seguimiento y control se ha ido realizando a

medida que se avanzaba en el desarrollo del proyecto. Además no han existido
grandes cambios que hayan necesitado mucho tiempo para gestionarlos.
 Desviaciones en la gestión documental. Para poder utilizar el módulo CMIS API ha sido
necesario entender muchas partes del código pues la documentación de este módulo
es muy escasa. Además, inicialmente no se contempló la realización de un módulo
personalizado para crear un menú dinámico con accesos directos a directorios del
repositorio de Alfresco. Tampoco quedó contemplada la programación de un nuevo
módulo para crear la zona de descargas ya que Drupal ofrece un módulo que permite
crear vistas de determinadas partes de un repositorio pero cuando llegó la hora de
implementarlo este no cumplía con ninguna de las funcionalidades requeridas.
 Desviaciones en la gestión de salas. Se han necesitado varias horas de investigación al
ser el primer módulo complejo que programaba por completo para Drupal y al ser la
primera vez que el plugin FullCalendar era usado. Además a lo largo del desarrollo del
mismo han ocurrido conflictos entre la versión de JQuery que requería Drupal, la que
requería FullCalendar y la que requerían componentes del formulario como
TimePicker. También ha sido necesario investigar para encontrar la mejor forma de
compartir los documentos registrados en la reserva de una sala.
 Desviaciones en la gestión de eventos. La desviación de tiempo ha sido debida a que
parte de la programación ha sido reutilizada de la gestión de salas. Lo que más tiempo
ha requerido ha sido la integración con Facebook y Twitter y la programación de la
repetición de eventos.
 Desviaciones en la personalización intranet. Ha habido desfase de tiempo dentro de
esta tarea debido a que la creación de roles y usuarios a través de Drupal es muy
sencilla. También se han realizado otras personalizaciones a parte de la instalación del
tema responsive como la configuración del correo, la creación de un sitio virtual o el
cumplimiento con la regulación de cookies de la UE.

~ 42 ~
  Desviaciones en las lecciones aprendidas. La desviación se debe a una mala
planificación del tiempo. Las lecciones aprendidas se encuentran recogidas con las
conclusiones del proyecto, en las cuales no ha sido necesario emplear tanto tiempo.
 Desviaciones en la creación de la página personal de entrada. La desviación se debe a
una mala planificación del tiempo pues la realización ha sido más sencilla de lo
esperada.

Control de calidad
En la tabla 11 se ve reflejado el seguimiento de la calidad de la intranet. El resto tablas de
calidad completadas pueden ser consultados en el anexo 7.

Fecha de revisión 30/05/2016

¿Necesita una revisión posterior? No
Observaciones globales La intranet incluye todos los requisitos globales
correctamente
INTRANET
Requisito Cumplimiento Observaciones
¿Diferencia roles? SÍ
¿Puede el administrador de la SÍ
intranet editar los permisos de los
roles?
¿Bilingüe? SÍ
¿Responsive? SÍ
¿Muestra un blog con noticias? SÍ
¿Permite el envío de mensajes SÍ
entre usuarios?
¿Posee una página personal de SÍ La página personal de entrada puede
entrada para cada usuario? ser editada para cada uno de los roles
existentes en cualquier momento por el
administrador de la intranet.
¿Permite gestionar salas? SÍ
¿Permite gestionar eventos? SÍ
¿Permite la gestión documental? SÍ
¿Permite publicar quejas y SÍ
sugerencias anónimas?
Tabla 11. Control de calidad

Control de cambios
A continuación se describen los cambios ocurridos durante el desarrollo del proyecto y se
detallan las gestiones realizadas.

1. Cumplir con la regulación de cookies de la UE. Este requisito no se encontraba

contemplado inicialmente en el análisis de requisitos pues la directora del proyecto lo
dio por hecho ya que además Drupal ofrece varios módulos que permiten fácilmente
cumplir con la política de cookies.

~ 43 ~
 Su error fue no plasmarlo de forma escrita en la definición de requisitos. Tras hablar
del error sucedido con el cliente acordaron que este requisito se realizaría al comienzo
de la implementación en la personalización de la intranet.
2. Edición del buzón de sugerencias. El cliente mostró su interés por editar este buzón
incluyendo la posibilidad de publicar también quejas y de poder incluso incluir
imágenes. Como el buzón de sugerencias fue realizado mediante el uso de Webform,
incluir dos campos más al formulario y a la tabla de resultados no suponía un coste
significativo de tiempo.
Por lo tanto el requisito R4 sería editado por el siguiente:
o R4: Publicar quejas y sugerencias anónimas, es decir, cualquier usuario podrá
escribir quejas o sugerencias y estas quedarán reflejadas en una tabla.
 R4.1: Los usuarios seleccionarán si lo que quieren publicar es una
queja o una sugerencia.
 R4.2: Los campos que formarán la publicación serán obligatoriamente
el tipo de publicación (queja o sugerencia), el título y el contenido.
Opcionalmente también podrán incluirse observaciones y una imagen.
 R4.3: Las publicaciones podrán ser editadas y eliminadas por el autor
de la misma o por el administrador de la intranet.

La tabla de calidad también será actualizada por la siguiente:

Fecha de revisión
¿Necesita una revisión posterior?
Observaciones globales
BUZÓN DE QUEJAS Y SUGERENCIAS
Requisito Cumplimiento Observaciones
¿Permite redactar quejas o sugerencias anónimas? SÍ/NO
¿Se muestran todas las quejas y sugerencias en una tabla? SÍ/NO
¿Contiene obligatoriamente el tipo de publicación, el título y SÍ/NO
el contenido?
¿Permite incluir observaciones y una imagen? SÍ/NO
¿El autor de una publicación y el administrador de la SÍ/NO
intranet pueden editar y eliminar?
Tabla 12. Nueva tabla para la gestión de calidad del buzón de quejas y sugerencias

Los bocetos de la interfaz del buzón de sugerencias serán modificados por los
siguientes:

a) En el siguiente boceto se muestra la interfaz que tendrán el buzón de quejas y

sugerencias una vez que el usuario haya pulsado la opción de publicar o editar. En
esta aparecerá un formulario donde el usuario deberá rellenar al menos lo
obligatorio (señalado con ‘*’). La información que el usuario deberá rellenar es el
tipo de publicación, título y el contenido, opcionalmente podrá incluir
observaciones y una imagen.

~ 44 ~
 b) En el siguiente boceto se muestra la interfaz que tendrá la tabla del buzón de
quejas y sugerencias donde los usuarios podrán observar todas las quejas o
sugerencias publicadas, es decir, la fecha de la publicación, el título, el contenido,
observaciones si las tiene, imagen si la tiene, y dos operaciones, edición y
eliminación. Estas operaciones estarán visibles para el autor de la publicación o
para el administrador de la intranet.

3. Eliminar bloqueo de usuarios en mensajes privados. El cliente comentó que finalmente

no encontraba sentido a que los usuarios pudieran bloquear la recepción de mensajes
de determinados roles o usuarios. Este cambio fue aprobado e implementado ya que
no suponía más de unos minutos para desactivar esta funcionalidad del módulo
Privatemsg.

~ 45 ~
4. Plugin adicional a Alfresco. Durante la configuración de Alfresco la directora del
proyecto recordó que durante sus prácticas en la empresa había trabajado con un
add-on para Alfresco que permitía crear enlaces a documentos en otras carpetas, de
esta forma es posible tener un mismo documento en diferentes sitios pero una única
vez almacenado. Por ello preguntó al cliente si le interesaría tenerlo instalado en
Alfresco ya que si instalaba el add-on para la manipulación de PDF instalar algún plugin
más no requería utilizar más tiempo.
5. Creación y configuración de LDAP (Protocolo Ligero de Acceso a Directorios). Durante
la implementación de la integración de Drupal con Alfresco surgió el problema de
autenticarse en Alfresco de manera transparente al usuario. La directora del proyecto
se reunió con el cliente y hablaron de posibles alternativas, entre ellas se encontraba
la creación de un LDAP. Tanto Alfresco como Drupal permiten integrarse con él. Esta
posibilidad requería tiempo de estudio, implementación e integración. Finalmente
acordaron que una vez finalizados los requisitos iniciales si aún quedaba tiempo el
cambio sería abordado.
6. Cambio de posición de las redes sociales y de la interfaz de las noticias en la página de
inicio de los usuarios autenticados. Tanto el resumen de las noticias recientes en la
parte izquierda de la pantalla como la red social Twitter en la zona derecha ocupaban
demasiado y quitaban espacio a los mensajes privados. Por ello se le ofreció al cliente
una posible zona alternativa para las redes sociales y una forma de organizar las
noticias de manera que no quitasen espacio al buzón de mensajes. El cliente aceptó el
cambio.
7. Creación de filtro y fecha fin en la gestión de salas. El cliente solicitó añadir un
pequeño filtro en la gestión de salas donde poder seleccionar la sala por la que se
desea filtrar y además de la fecha inicial, incluir también fecha de finalización de la
reserva. El cambio fue aceptado y abordado ya que no requería mucho tiempo pues
únicamente eran unos pequeños cambios en el formulario y en la consulta realizada a
la base de datos para obtener las reservas que mostrar en el calendario.
8. Cambio en la interfaz de los botones por accesos en el menú. Durante una de las
reuniones con el cliente para realizar el seguimiento del producto se acordó que los
enlaces para crear un nuevo contenido (noticia, reserva, etc.) estuviesen mejor como
accesos en el menú en vez de como botones en la parte superior del contenido de la
página web.
9. Cambio en la interfaz del filtro de eventos. El cliente pidió si era posible que los
resultados tras filtrar los eventos se mostrasen en el calendario en vez de en una tabla
como se acordó en el análisis de interfaces. Este cambio fue aprobado e implementado
ya que mostrar los resultados en una tabla requería más tiempo que integrar el filtro
con el calendario ya realizado.
10. Creación de un menú dinámico en la gestión documental. El cliente solicito añadir
tantos accesos directos en el menú como sitios hay en el repositorio de Alfresco. Para
ello era necesario realizar un pequeño módulo personalizado. Como a esas alturas del
proyecto se estaba cumpliendo correctamente con los tiempos planificados la
directora del proyecto decidió aprobar y abordar el cambio.

~ 46 ~
Cónclusiónes
Los principales motivos para la realización de este proyecto como trabajo de fin de grado han
sido el aprendizaje y la experiencia obtenida durante el desarrollo de una intranet para un
colegio con un CMS complejo como es Drupal junto con una integración con un gestor de
documentos como Alfresco.

Es importante destacar la oportunidad para ampliar y adquirir conocimientos en distintas

herramientas y plugins como por ejemplo PHP, JQuery, phpMyAdmin o FullCalendar entre
otros.

Gracias al tutor de la empresa he aprendido una buena forma de estructurar los proyectos de
cara al mundo real cuando se utiliza control de versiones. Este conocimiento incluye cómo
dividir los proyectos en diversas ramas, cuándo y dónde realizar commits y merges o cómo
actuar si aparece un bug.

Durante la elaboración de este proyecto ha sido necesario realizar una planificación, un

análisis, un diseño, una implementación, un seguimiento y control y un cierre de un proyecto
más cercano a la realidad. Gracias a ello habilidades como una mejor capacidad para resolver
problemas de forma autónoma, una mayor facilidad para comunicarse con clientes o la mejora
a la hora de gestionar cambios han podido ser desarrolladas.

Además, a través del estudio de alternativas he podido saber qué herramientas actuales son
las más utilizadas en el mercado y qué ventajas ofrecen respecto a otras.

Una de las lecciones que más he aprendido en el proyecto gracias al tutor de la empresa ha
sido: “No reinventes la rueda. La rueda ya existe, úsala”.

En conclusión, el proyecto ha sido muy interesante y satisfactorio. Durante el desarrollo del

mismo me encontrado con dificultades que han supuesto desafíos que de una manera u otra
han podido resolverse. Gracias a ello he podido aumentar mi conocimiento en diversos
ámbitos. Por ello se puede concluir que el esfuerzo ha valido la pena y que los objetivos del
proyecto se han podido alcanzar con éxito.

~ 47 ~
Bibliógrafía
A continuación se listan varías páginas web utilizadas de referencia para el desarrollo del
trabajo de final de grado.

- Estudio de alternativas:
o www.hiberus.com/blog/comparativa-entre-gestores-de-contenidos-cms
o http://websitesetup.org/cms-comparison-wordpress-vs-joomla-drupal/
o http://makeawebsitehub.com/content-management-system-cms-comparison/
- Desarrollo en Drupal:
o www.drupal.org
o http://tutorial-drupal.com
o http://drupalalsur.org
o www.cursosdrupal.com
- Desarrollo del calendario de la gestión de salas y eventos:
o www.fullcalendar.io
- Integración gestor de contenidos:
o http://docs.alfresco.com
o https://forums.alfresco.com/es
- Desarrollo código PHP:
o https://secure.php.net/manual/es/index.php
- Consultas generales:
o www.desarrolloweb.com
o http://es.slideshare.net
o www.stackoverflow.com
o www.youtube.com
- Traducción:
o www.wordreference.com

~ 48 ~