Internal Message para Joomla Admon. Web y comercio electrónico en entornos de software libre

Transcripción

1 Internal Message para Joomla Autor: Consultor: Francisco Javier Noguera Otero Fecha de entrega: 06/06/2011

2 Copyright 2011 Se garantiza permiso para copiar, distribuir y modificar este documento según los términos de la GNU Free Documentation License,Version 1.3 o cualquiera posterior publicada por la Free Software Foundation, sin secciones invariantes ni textos de cubierta delantera o trasera. Se dispone de una copia de la licencia en el apartado GNU Free Documentation License de este documento. 2 de 60

3 Resumen El proyecto Internal Message consiste en el desarrollo de un sistema de mensajería interna que comunique de forma fiable y segura a los usuarios de cualquier sistema de gestión de contenidos Joomla. Este proyecto viene motivado por las necesidades del IES Clara del Rey que es un centro de formación profesional de Madrid donde se imparten ciclos formativos de las especialidades de Administración y Gestión, Comercio y Marketing e Informática y Comunicaciones. El gestor de contenidos Joomla facilita información del centro al exterior y también se utiliza como repositorio de documentos del profesorado. Internal Message debe aportar al gestor que todo el profesorado del centro esté interconectado, que la dirección pueda emitir comunicados a todo o parte del profesorado y, en resumen, que esta herramienta se convierta en el eje de comunicación del personal del centro. A pesar de que aparentemente existen multitud de extensiones para Joomla que implementan las características antes indicadas, un análisis concienzudo detecta que no cumplen, al menos en parte, las expectativas creadas, bien en su desarrollo técnico o bien en su carácter de software libre. Desde el punto de vista técnico los objetivos del proyecto se centran en aspectos tales como que sea de fácil administración, uso sencillo, confiable, con soporte para todo tipo de mensajes, que incorpore ficheros adjuntos a los mensajes, gestión de grupos de destinatarios, control del estado de lectura de un mensaje por parte de cada destinatario, y además debe estar perfectamente integrado tanto en el gestor Joomla como en la interfaz del centro. Dentro de la filosofía de la institución esta solución debe ser extrapolable a otras organizaciones y es por ello que desde un punto de vista económico la solución debe ser de bajo coste y, por supuesto, con licencias que permitan utilizarla libremente. 3 de 60

4 Índice de contenido Resumen Introducción Presentación Objetivos Estado del arte Estructura de la memoria del proyecto Estudio de viabilidad Alcance del proyecto Descripción general del sistema Sistemas de la institución afectados por el proyecto Unidades de la institución afectados por el proyecto Estudio de la situación actual Definición de requisitos del sistema Estudio de alternativas de solución Valoración de alternativas Comparativa de las alternativas Riesgos asociados a cada alternativa Previsión de los riesgos detectados Selección de la solución Análisis del sistema Definición del sistema Requisitos exactos del sistema Entorno tecnológico del sistema Normativas a aplicar en el sistema Identificación de usuarios del sistema Establecimiento de requisitos Definición de requisitos Casos de uso Definición de interfaces de usuario Perfiles de usuarios Principios generales de la interfaz de usuario Interfaces de usuario Especificación del plan de pruebas Pruebas unitarias Pruebas de integración Pruebas de sistema Pruebas de implantación y aceptación Distribución temporal Presupuesto Diseño Definición de los niveles de arquitectura Arquitectura conceptual Arquitectura lógica Especificación de estándares, normas de diseño y construcción Identificación de subsistemas Revisión de casos de uso Diagrama entidad-relación Elección de componentes y licencias Componentes y productos a utilizar Elección de licencia final para el producto desarrollado Especificaciones de desarrollo y pruebas de implantación Entorno tecnológico de desarrollo Restricciones técnicas y de seguridad Requisitos de implantación de 60

5 5 Desarrollo Identificación de extensiones a desarrollar Planificación de las actividades de desarrollo e integración del sistema Descripción del entorno de desarrollo Estructura de directorios Sistema de empaquetamiento Implantación Implantación del sistema y pruebas Acuerdo del nivel de servicios Aceptación del sistema Mantenimiento Conclusiones Bibliografía / webgrafía Anexo I. Estructura de almacenamiento Anexo II. Esquema de la base de datos de Joomla Anexo III. Instalación de Internal Message Anexo IV. GNU Free Documentation License de 60

6 1 Introducción 1.1 Presentación El proyecto Internal Message trata de dotar de un sistema de mensajería interna que comunique de forma fiable y segura a los usuarios del sistema de gestión de contenidos del IES Clara del Rey. El IES Clara del Rey ( es un centro de formación profesional de Madrid donde se imparten ciclos formativos de las especialidades de Administración y Gestión, Comercio y Marketing e Informática y Comunicaciones. El sistema gestor de contenidos es Joomla [1] con el que está implantado la extranet del centro. Este gestor por una parte ofrece información al exterior y por otra aloja los documentos institucionales y de uso interno. Los usuarios identificados en el sistema corresponden al personal de la institución, mayoritariamente profesorado del centro. 1.2 Objetivos Los objetivos del proyecto de implantación del sistema de mensajería son: Fácil administración y uso sencillo por parte de los usuarios finales. Inserción de cualquier tipo de mensajes. Control sobre la lectura de los mensajes enviados por parte de los destinatarios. Integración absoluta con el gestor de contenidos Joomla. Bajo coste 1.3 Estado del arte Existen diversas extensiones de Joomla que facilitan la mensajería interna entre usuarios del gestor. Curiosamente el propio Joomla dispone de un sistema de comunicación entre administradores. Sin embargo las características de todas las extensiones adolecen de puntos que en este proyecto resultan determinantes como su carácter gratuito, extensible y exportable. Desde un punto de vista funcional, el tipo de mensajes que habitualmente se envían los profesores de ciertas especialidades1 requiere que cualquier tipo de información pueda ser enviada, sin pérdida de 1 Especialmente el profesorado adscrito a la familia profesional de informática y comunicaciones. 6 de 60

7 información o modificaciones de esta. En este apartado la mayor parte de las extensiones dejan mucho que desear pues o bien descartan algunos tipos de información o bien no la deja insertar. Este es el caso de etiquetas HTML o distintos tipos de comillas. Para finalizar los sistemas de mensajería interna se entienden como sistemas con mensajes simples y en su mayor parte no contemplan la inserción de ficheros adjuntos al contenido lo que merma sus posibilidades. 1.4 Estructura de la memoria del proyecto La memoria se ha estructurado siguiendo las fases del proyecto, comenzando con una introducción a este, donde se presenta y realiza una descripción general de dicho proyecto, indicándose los principales objetivos a cubrir. Posteriormente en el estudio de su viabilidad, se establecen las opciones existentes, se adopta una solución final, y se introduce un análisis del proyecto a implantar. En la fase de análisis se describe el sistema indicando el entorno tecnológico de la solución, los estándares y normas consideradas, la comunicación con otros subsistemas y se identificarán los usuarios implicados. Ya en la etapa de diseño se define la base tecnológica y específicamente los modelos que definen el proyecto, haciendo hincapie en los casos de uso y la identificación de los actores participantes. Durante el desarrollo del proyecto, propiamente dicho, se identifica el modelo y la metodología a aplicar, las extensiones a desarrollar, la planificación a seguir y el entorno de desarrollo. Una vez desarrollado el producto final se pasa a la fase de implantación donde se explica el proceso de puesta en marcha del producto. Sucintamente, por la tipología del proyecto, se aborda la etapa de mantenimiento, bien sea este correctivo o evolutivo. Finalmente, la memoria incluye las conclusiones pertinentes consistente en un resumen de objetivos conseguidos y ampliaciones de mejora del producto realizado. 7 de 60

8 2 Estudio de viabilidad 2.1 Alcance del proyecto Descripción general del sistema El proyecto abarca la realización de un sistema de mensajería web integrado en el sistema gestor de contenidos (CMS2) Joomla [1] que es el utilizado por el IES Clara del Rey. Por tanto los principales objetivos del proyecto de implantación del sistema de mensajería son: Fácil administración y uso sencillo por parte de los usuarios finales. Inserción de cualquier tipo de mensajes con un editor wysiwyg 3. Incorporación de ficheros adjuntos a los mensajes. Envío de mensajes cuyos destinatarios puedan ser individuales, colectivos o grupos determinados. Control sobre la lectura de los mensajes enviados por parte de cada destinatario. Integración absoluta con el gestor de contenidos Joomla. Desde el punto de vista económico el sistema debe tener un coste lo más bajo posible. Desde el punto de vista técnico el proyecto viene marcado por las propias características del gestor de contenidos utilizado, Joomla, y por el uso en producción de servidores externos ya en funcionamiento. Desde el punto de vista legal, además de las condiciones propias del software libre -libertad total para copiar, estudiar y/o modificar el código fuente- deberá respetar las propias de la Ley de Protección de Datos Personales. Desde el punto de vista operativo es necesario que la velocidad de respuesta de la aplicación sea lo suficientemente rápida y que el interfaz de usuario sea extremadamente simple de utilizar Sistemas de la institución afectados por el proyecto El proyecto trata de implantar un sistema de mensajería integrado en el CMS utilizado por el IES Clara del Rey. El sistema utilizado hasta el momento es la mensajería del sistema de foros utilizado por la aplicación phpbb4 ( Sin embargo, y dado el grado de utilización actual, no se considera preciso 2 Content Management System o Sistema Gestor de Contenidos 3 WYSIWIG es el acrónimo de What You See Is What You Get (lo que ves es lo que obtienes) 4 phpbb es un sistema de foros con licencia GPL y desarrollado para entornos LAMP. 8 de 60

9 conservar los mensajes de dicho sistema Unidades de la institución afectados por el proyecto Una vez puesto en marcha, el proyecto, afectará a todos los departamentos y a todo el profesorado en tanto que será el sistema de comunicación principal dentro de la institución. 2.2 Estudio de la situación actual Actualmente la institución dispone de un sistema de comunicación basado en foros soportado por la herramienta phpbb que además soporta mensajería. Tras los resultados obtenidos en las encuestas de satisfacción de dicho sistema, siguiendo los protocolos establecidos en el plan de calidad, se ha determinado que los foros prácticamente no se utilizan y el sistema de mensajería, al ser un elemento accesorio de dicha herramienta, no cubre las necesidades planteadas. La interconexión de ambos productos (Joomla y phpbb) es realizada mediante una aplicación pasarela que identifica al usuario en ambos sistemas, pero su integración visual dista mucho de ser óptima. Hasta el momento la comunicación entre los diversos miembros de la organización se realizaba mediante documentos escritos (personales o tablones) y a través de la mensajería descrita, no teniendo valor vinculante la realizada por este último medio. Esto unido al bajo número de mensajes entre usuarios no hace necesario que se establezcan mecanismos de migración entre el sistema actual y el que se implante finalmente. La versión más avanzada de Joomla disponible en los servidores de producción y por tanto para la cual hay que desarrollar el sistema es la versión Definición de requisitos del sistema Requisitos técnicos (100) Uso en producción de servidores externos ajenos a la institución. (100) Integración absoluta con el gestor de contenidos Joomla 1.5. (80) Aplicación de los estándares de W3C. (80) Aplicación de las normativas de accesibilidad WAI-AA. (80) Acceso a la aplicación desde cualquier navegador. (50) Codificación simple de los mensajes. Requisitos operativos (100) Inserción de cualquier tipo de contenido en los mensajes con un editor wysiwyg. (100) Incorporación de ficheros adjuntos en los mensajes. (95) Destinatarios de los mensajes individuales o colectivos. 9 de 60

10 (70) Definición de grupos de destinatarios. (60) Respuesta a todos los destinatarios. (100) Aviso de mensajes no leídos dentro del sistema. (50) Aviso de mensajes no leídos al correo electrónico del usuario. (100) No permitir eliminar mensajes no leídos. (95) Uso sencillo por parte de los usuarios finales. (60) Administración de grupos globales. (50) Fácil administración del sistema. (85) Velocidad de respuesta rápida. (100) Sólo accesible para usuarios activos. Requisitos legales (100) Cumplimiento de la Ley de Protección de Datos Personales. (100) Licencia de software compatible con la de Joomla. Requisitos económicos (90) Coste mínimo. 2.4 Estudio de alternativas de solución Se estima la posibilidad de realizar un desarrollo propio o aprovechar alguna aplicación ya existente. Antes de decantarse por una u otra opción se va a proceder a elegir cual sería el componente más adecuado para reutilizar en nuestro proyecto. Los componentes disponibles se extraen de la página de extensiones de Joomla para proveer un sistema de mensajes privados [9], siendo los siguientes: uddeim Messaging CD Pure Messenger JIM JE Messenger Core Design User Message Full Scriba De estos CD Pure Messenger, JE Messenger, Core Design user Message Full y Scriba son desechados por su carácter comercial. JIM se desecha por no disponer de soporte nativo para la versión 1.5 de Joomla. Quedando únicamente los dos primeros: uddeim y Messaging. 10 de 60

11 2.5 Valoración de alternativas Las alternativas, por tanto, quedan reducidas a reutilizar uddeim o Messaging, o realizar un desarrollo propio Comparativa de las alternativas Fase 1 En primer lugar se van a comparar las dos aplicaciones existentes para este fin, a saber uddeim y Messaging. Características uddeim Messaging Última actualización 06/03/11 26/09/08 Versión Licencia GPLv2 o superior GPLv2 o superior Web Editor wysiwyg Muy limitado No funciona en Chromium No funciona en Google Chrome Muy limitado Control de lectura/borrado Permite borrar mensajes no leídos Permite borrar mensajes no leídos Ficheros adjuntos No (disponible un plugin de pago) No Destinatarios múltiples Sí No Grupos de destinatarios Sí No Aviso de mensajes no leídos Sí (mediante módulo) Sí (mediante módulo) Envío de de aviso Sí Sí Interfaz Adecuada pero mejorable Descuidada Mantenimiento No Mediante foro Selección de usuarios Sí Sí Sólo accesible activos para usuarios No No Nombres de usuario Sí Sí Nombre completos No Sí De la comparativa anterior queda descartado Messaging pues uddeim es más adaptable que el primero aunque el número de requisitos iniciales que no satisfechos es alto. Fase 2 Queda ahora determinar la opción de desarrollo propio o adaptación de uddeim a nuestro entorno. La viabilidad económica en ambas partes es la misma pues no hay costes asociados a licencias de software 11 de 60

12 ni otros. Únicamente cabe destacar que el coste del plugin para gestión de ficheros adjuntos es de 20. Las horas de desarrollo pueden ser similares en tanto que la opción de adaptar uddeim obliga a conocer esta aplicación y aplicar su modelo de desarrollo mientras que en el caso de desarrollo propio no se parte de esta limitación. Por otro lado, es filosofía de la institución que el software adaptado y/o desarrollado pueda ser utilizado en su conjunto y de cualquier modo por cualquiera otra entidad que lo precise Riesgos asociados a cada alternativa Adaptación de uddeim Difícil adaptación en tanto que la comunidad de desarrollo de uddeim no existe como tal y no se dispone de soporte por parte del desarrollador, únicamente acceso al código fuente. El primer elemento a cambiar es el editor actual por uno tipo wysiwyg que es prácticamente el núcleo de la aplicación. En su versión básica no soporta la función de adjuntar ficheros a los mensajes que habría que desarrollar. El desarrollo realizado no puede contribuir al propio producto uddeim al no existir una comunidad de desarrolladores. El desarrollo realizado puede no ajustarse a las nuevas versiones que se liberen del producto. No respetar los tiempos de entrega. Desarrollo propio Desconocimiento del modo de implantación del modelo vista-controlador realizado por Joomla. No respetar los tiempos de entrega Previsión de los riesgos detectados Adaptación de uddeim Establecer contactos directos con los desarrolladores de uddeim para colaboración o desarrollo por su parte. Establecer contactos directos con los desarrolladores de uddeim para incluir las mejoras en sus nuevas versiones. En caso de no llegar a acuerdos de colaboración/desarrollo/versionado se debería: Estudiar la metodología de desarrollo de uddeim Estudiar el modo de implantación del modelo vista-controlador propuesto por Joomla. Contratar personal/empresa especializado en desarrollo sobre Joomla con conocimientos de 12 de 60

13 uddeim. Desarrollo propio Estudio previo del modo de implantación del modelo vista-controlador propuesto por Joomla. Contratar personal/empresa especializado en desarrollo sobre Joomla. 2.6 Selección de la solución En la selección de la solución también se ha tenido en cuenta la independencia de la institución de terceros, además de la suma de curvas de aprendizaje que implica el conocer la aplicación a adaptar añadido al propio conocimiento del modelo de desarrollo de Joomla. De todo lo anterior y priorizando minimizar los riesgos se concluye afrontar un desarrollo propio que contemple todos los requisitos que se establezcan y que no imponga ninguna limitación de funcionalidad, crecimiento posterior y distribución del producto. El lenguaje de desarrollo debe ser PHP y se deberá seguir la metodología para implementación de extensiones de Joomla. 13 de 60

14 3 Análisis del sistema 3.1 Definición del sistema Requisitos exactos del sistema El sistema de mensajería debe cumplir los siguientes requisitos: Integración tecnológica con el gestor de contenidos Joomla 1.5. Aplicación de los estándares de W3C. Aplicación de las normativas de accesibilidad WAI-AA. Acceso a la aplicación desde cualquier navegador de última generación. Uso en entornos LAMP externos ajenos a la institución. Uso sencillo por parte de los usuarios finales. Interfaz integrada en Joomla. Menús y opciones simples y accesibles. Imagen unificada de la institución. Uso de editores wysiwyg. Fácil administración y mantenimiento del sistema. Establecimiento de usuarios del sistema. Definición de grupos de usuarios. Velocidad de respuesta rápida. Licencia menos restrictiva posible, por supuesto, de software libre Compatible con la licencia de Joomla. Si se integran otras aplicaciones, se seleccionarán las de licencia menos restrictiva. Entorno tecnológico del sistema Las características del entorno de producción, en el momento actual, son: Sistema operativo: Linux emdi el5 #1 SMP Wed Jun 23 10:52:51 EDT 2010 x86_64 Servidor web: Apache 2 Base de Datos: MySQL y cotejamiento utf8_general_ci Lenguaje de programación del lado servidor: PHP Sin embargo, al no disponer del control de las distintas versiones instaladas o futuras actualizaciones de los servidores de producción no podemos ceñirnos a esta arquitectura. 14 de 60

15 La única certeza es que los servidores de producción siempre van permita la instalación y ejecución de Joomla en su versión 1.5, por tanto estos son los requisitos tecnológicos a imponer se corresponden con los propios de esta versión de Joomla. Se muestra un extracto de los requisitos y recomendaciones realizadas para Joomla 1.5 [7]: Software Recomendado Mínimo Excepto PHP ,4.4.2,5.0.4 MySQL 4.1.X X+ aún no disponible Apache 2.X+ 1.3 Joomla 1.6 requiere PHP 5.2+ y MySQL por lo que en este momento no se podría instalar en producción. La versión desplegada de Joomla es la Stable [ Wojmamni Ama Mamni ] 05-November :00 GMT. Las características del entorno de desarrollo, dadas las circunstancias anteriores, no deberían ser significativas aunque se indiquen: Sistema operativo: MAX 6.0 Madrid_linuX( Linux max60-tcos-backharddi generic-pae #59-Ubuntu SMP Tue Mar 1 23:01:33 UTC 2011 i686 GNU/Linux Servidor web: Apache/ Base de Datos: MySQL y cotejamiento utf8_general_ci Lenguaje de programación del lado servidor: PHP Respecto a las herramientas de desarrollo se utilizará el entorno de desarrollo integrado Geany ( por su extremada sencillez y facilidad para manejar todo tipo de ficheros (php, html, css, ini, xml, ). La creación o modificación de iconos e imágenes se realizará con el programa de manipulación de imágenes Gimp ( La documentación se desarrollará fundamentalmente con la suite OpenOffice ( y el editor de diagramas Dia ( La documentación del código fuente será desarrollada con PhpDocumentor ( Los vídeos de presentación del ( La gestión del proyecto ( será proyecto mantenida se mediante realizarán el gestor con de gtk-recordmydesktop proyectos Planner Los navegadores básicos de desarrollo y pruebas serán Firefox ( y Chromium ( No debemos olvidar que una parte importante de los usuarios finales utiliza Internet Explorer ( Opera ( y/o Safari ( Se realizarán pruebas de funcionamiento en estos navegadores para sus últimas versiones. 15 de 60

16 3.1.3 Normativas a aplicar en el sistema Los desarrollos a realizar deben estar integrados en Joomla en todos sus aspectos. Por tanto nos ceñiremos a la metodología aplicada en el propio desarrollo de Joomla. Esta metodología está documentada a través del portal de desarrolladores, el portal del API 5 y de las páginas oficiales de documentación del proyecto Joomla [1][2][3][4]. Las aplicaciones añadidas a Joomla se dividen según sus características: componentes, módulos o plugins. En nuestro caso vamos a desarrollar un componente completo y un módulo para mejorar el interfaz de usuario. El desarrollo de componentes se basa en el modelo vista-controlador (MVC) que básicamente separa la lógica de negocio de la presentación de los datos. De modo breve, el modelo es la parte del componente a desarrollar que encapsula los datos de la aplicación, la vista es la parte que muestra e interactúa con el usuario y el controlador es el responsable de realizar las acciones previstas. Joomla, además, introduce el concepto de plantillas (template) para separar la gestión de información a visualizar de su propia presentación en la web Identificación de usuarios del sistema La definición de requisitos y aceptación de la solución final del sistema de mensajería será llevada a cabo por: El coordinador de tecnologías de la información y comunicación, que definirá requisitos y dará su aceptación en las cuestiones meramente tecnológicas. El director de la institución que identificará el resto de requisitos (económicos, funcionales, legales y operativos) así como será el receptor final del proyecto, previo visto bueno del coordinador citado anteriormente. Ambos, además, serán usuarios finales de la aplicación resultante. 5 Application Programming Interface o Interfaz de Programación de Aplicaciones. 16 de 60

17 3.2 Establecimiento de requisitos Definición de requisitos De las reuniones mantenidas con el director de la institución y el coordinador de tecnologías de la información y la comunicación se han extraído los siguientes requisitos: Nota: Los requisitos específicamente indicados por el coordinador de tecnologías de la información y la comunicación será marcados con (TIC). 1. Definición del requisito Grupos de destinatarios Se ha de permitir a cualquier usuario del sistema de mensajería crear grupos de destinatarios pudiendo añadir, modificar y eliminar a sus integrantes. Se ha de permitir que el usuario que ha creado un grupo lo borre o lo modifique. Se ha de permitir a los usuarios privilegiados, a determinar, definir grupos de destinatarios con las siguientes características: Sólo para miembros. Sólo los usuarios del propio grupo pueden enviar mensajes a este grupo. Privados. Sólo el usuario privilegiado puede utilizarlo. Los usuarios privilegiados deben determinar que usuarios de Joomla son excluidos del sistema de mensajería. Serán usuarios privilegiados aquellos que estén activos en el sistema de mensajería y tengan el rol de Super Administrador en Joomla. (TIC). 2. Definición del requisito Envío de mensajes Ha de permitir el envío de mensajes a uno o varios destinatarios. Los destinatarios pueden ser seleccionados individualmente o como grupo. Los destinatarios únicamente pueden ser los activos y admitidos en el sistema de mensajería. Se podrá incluir, al menos, un fichero adjunto. Los ficheros adjuntos pueden ser de cualquier tipo. El tamaño de los ficheros adjuntos estará limitado únicamente por las restricciones del servidor utilizado.(tic). El almacenamiento de los ficheros adjuntos se realizará una única vez en el caso de mensajes a varios destinatarios.(tic). El editor de mensajes debe ser de tipo wysiwyg. El editor de los mensajes debe permitir guardar y recuperar cualquier información que se haya escrito6. 6 Es típico que las aplicaciones web no permitan el uso de etiquetas html o que restrinjan algunos 17 de 60

18 El mensaje enviado se guardará en la bandeja de enviados. El mensaje enviado mostrará, además de los datos introducidos, la fecha de envío e indicará los usuarios que han o no leído el mensaje. Se podrán borrar mensajes enviados que hayan sido leídos por todos los destinatarios activos en el sistema de mensajería. Se podrán guardar mensajes enviados que hayan sido leídos por todos los destinatarios activos en el sistema de mensajería. Como apoyo al cumplimiento de la Ley de Protección de Datos Personales y dado que los datos no se alojan en la propia organización, el texto de los mensajes será codificado. (TIC). 3. Definición del requisito Recepción de mensajes Los mensajes recibidos se mostrarán inicialmente en la bandeja de recibidos. Los mensajes recibidos no leídos se marcarán de algún modo. Los mensajes recibidos no leídos no podrán ser borrados ni almacenados. En mensaje mostrará tanto el emisor como todos los destinatarios indicando los que han o no leído el mensaje. Se debe permitir marcar un mensaje como no leído. Se debe permitir contestar al emisor. Se debe permitir contestar al emisor y a todos los destinatarios Casos de uso Caso de uso del requisito Grupo de destinatarios Caso de Uso Grupo de destinatarios [GRUPOS] Actores Usuario, Privilegiado Tipo Referencias Precondición Postcondición Propósito Crear, modificar o eliminar grupos de destinatarios Resumen caracteres en la recogida de información desde formularios y específicamente desde campos de texto. 18 de 60

19 El usuario define un grupo de destinatarios de los mensajes. Puede modificar el nombre del grupo y la composición de integrantes. También puede eliminarlo. El grupo creado es únicamente de uso para el usuario. El usuario privilegiado además define si el grupo es únicamente para miembros y si es privado. Los grupos públicos son de uso para todos los usuarios. Curso normal (básico) 1.- El usuario consulta la lista de grupos 2.- Se muestran los grupos y la posibilidad de añadir nuevos 3.- El usuario selecciona el grupo a modificar 4.- Se muestra el nombre del grupo, sus integrantes y la posibilidad del borrar el grupo 5.- El usuario selecciona la acción 6.- Se realiza la acción y se pasa a 2 Cursos alternos 3a.- El usuario añade un nuevo grupo 4a.- Al usuario privilegiado se le muestra: únicamente para miembros / privado Otros datos Frecuencia esperada Muy baja Rendimiento Importancia Media Urgencia Media Estado Pendiente Estabilidad Alta Comentarios Diagrama del caso de uso 19 de 60

20 Caso de uso del requisito Envío de mensajes Caso de Uso Envío de mensajes [ENVIO] Actores Usuario Tipo Referencias GRUPOS, RECIBIR Precondición Postcondición El mensaje enviado se almacena en la bandeja de salida. El mensaje llega a la bandeja de entrada de cada uno de los destinatarios. Propósito Enviar mensajes a otros usuarios Resumen El usuario envía un mensaje a otros usuarios del sistema. El mensajes está constituido por un asunto, un texto y puede incluir un fichero adjunto. Los destinatarios pueden ser individual o colectivo. Si es colectivo pueden ser seleccionados individualmente o como grupo de destinatarios. Curso normal (básico) 1.- El usuario crea un nuevo mensaje 2.- Se muestran la información a rellenar 3.- El usuario envía el mensaje 4.- Se muestra el nombre del grupo, sus integrantes y la posibilidad del borrar el grupo 5.- El usuario selecciona la acción 6.- Se realiza la acción y se pasa a 2 Cursos alternos Otros datos Frecuencia esperada Alta Rendimiento Importancia Alta Urgencia Alta Estado Pendiente Estabilidad Alta Comentarios Los mensajes enviados se pueden 20 de 60

21 Diagrama del caso de uso Caso de uso del requisito Recepción de mensajes Caso de Uso Recepción de mensajes [RECIBIR] Actores Usuario Tipo Referencias ENVIAR Precondición Mensaje enviado por otro usuario Postcondición Propósito Leer los mensajes recibidos Resumen El usuario dispone de los mensajes recibidos en la bandeja de entrada. Puede leer los mensajes y borrarlos o guardarlos una vez recibidos. Curso normal (básico) 1.- El usuario consulta la bandeja de entrada 2.- Se muestran los mensajes distinguiendo los leídos de los no leídos 3.- El usuario selecciona el mensaje a leer 4.- Se muestra el emisor, destinatarios, fecha de emisión, asunto, texto, fichero adjunto y las posibles acciones a realizar: marcar como no leído, responder, responder a todos, guardar, borrar 5.- El usuario selecciona la acción 6.- Se realiza la acción y se pasa a 2 Cursos alternos 21 de 60

22 1a.- El usuario consulta la bandeja de mensajes guardados. Otros datos Frecuencia esperada Alta Rendimiento Importancia Alta Urgencia Alta Estado Pendiente Estabilidad Alta Comentarios Diagrama del caso de uso 3.3 Definición de interfaces de usuario Perfiles de usuarios Los usuarios de la mensajería no tienen un perfil técnico pero están acostumbrados al uso de aplicaciones 22 de 60

23 web y más concretamente a la utilización del gestor de contenidos. Los usuarios privilegiados de la mensajería, al ser coincidentes con los Super Administradores del gestor de contenidos, disponen además de los conocimientos técnicos precisos Principios generales de la interfaz de usuario La interfaz de usuario tendrá las siguientes características: El acceso a la aplicación se realizará mediante un navegador web. La edición se realizará mediante formularios web. El editor de mensajes será de tipo wysiwyg. Los mensajes de error se mostrarán en pantalla con indicación del tipo de error Interfaces de usuario El esquema general de la interfaz de usuario es la que sigue, aunque está sujeta a posteriores cambios en busca de la usabilidad del sistema. Este interfaz no es independiente pues tiene que estar integrado dentro del propio del gestor de contenidos Joomla. Las plantillas de presentación de Joomla típicamente se estructuran en dos o tres columnas. Una de ellas es más amplia para cobijar componentes mientras que las otras muestran otro tipo de información como puede ser la proveniente de módulos o menús. En el caso que nos ocupa según cada página concreta se puede decidir si se incluyen dos o tres columnas. La columna de la izquierda siempre es más estrecha. La otra parte puede dejarse completamente para albergar componentes o se puede dividir en dos. 23 de 60

24 Para poder desplegar todas las funcionalidades de Internal Message se necesita disponer de un espacio suficiente. Por ello se va a optar por no dividir la parte derecha. El interfaz de usuario, por tanto, quedaría incrustado tal y como se muestra en la siguiente pantalla. Otro elemento a incluir es una alarma visual de que se dispone de nuevos mensajes sin leer. Por sus características no necesita tanto espacio informativo y podría incorporarse como módulo siendo el modelo de interfaz. 24 de 60

25 Ahora vamos a definir el interfaz de usuario para cada caso de uso. Grupo de destinatarios Envío de mensajes 25 de 60

26 Recepción de mensajes 3.4 Especificación del plan de pruebas Pruebas unitarias Gestión de grupos de destinatarios 26 de 60

27 Por parte de un usuario privilegiado (Super administrador) Creación de un grupo privado. Creación de un grupo público. Resultado: Grupo público creado. Creación de un grupo público sólo para miembros. Resultado: Grupo privado creado. Resultado: Grupo para miembros creado. Habilitación/deshabilitación de usuarios del sistema de mensajería. Resultado: Usuarios deshabilitado no aparece en el sistema de mensajería. Por parte de un usuario no privilegiado Creación de un grupo. Modificación de un grupo. Resultado: Grupo creado. Resultado: Datos del grupo modificados. Eliminación de un grupo: Resultado: Grupo eliminado. Envío de mensajes Envío de un mensaje a un destinatario. Resultado: Mensaje enviado en la bandeja de salida. Mensaje recibido y marcado sin leer en la bandeja de entrada del destinatario. Envío de un mensaje a varios destinatarios. Resultado: Mensaje enviado en la bandeja de salida. Mensaje recibido y marcado sin leer en la bandeja de entrada de cada destinatario. Recepción de mensajes Lectura de un mensaje. Resultado: Lectura del mensaje y marcado como leído. Guardar un mensaje. Resultado: Mensaje pasa de la bandeja de recibidos a la de guardados. 27 de 60

28 Borrar un mensaje. Resultado: Mensaje desaparece. Marcar un mensaje leído como no leído Resultado: Mensaje marcado como no leído. Pruebas de integración Envío de mensajes Envío de un mensaje a un grupo de destinatarios Resultado: Mensaje enviado en la bandeja de salida. Mensaje recibido y marcado sin leer en la bandeja de entrada de cada destinatario. Pruebas de sistema Activar/desactivar un usuario del gestor de contenidos y comprobar que está activo/inactivo en el sistema de mensajería. Pruebas de implantación y aceptación Realizar todas las pruebas anteriores en el entorno de producción. 3.5 Distribución temporal El periodo establecido para el desarrollo completo se ha considerado desde el 15 de marzo hasta el 1 de junio. Ello representa 48 jornadas laborales reales a tenor de 4 horas diarias sumando un total de 192 horas. Al final de cada tarea indicada anteriormente se establecerá un hito de control que irá acompañado de la entrega de la documentación correspondiente a cada fase según el diagrama siguiente. 28 de 60

29 La duración de cada una de las fases viene establecida en función de las necesidades a cubrir. Se da gran importancia las fases de análisis y diseño, al considerar que si están perfectamente definidas y desarrolladas la fase de desarrollo y posteriores no se van a ver alteradas por errores de las fases previas. De todos modos, como una de las restricciones iniciales es adaptarse a las especificaciones de desarrollo de Joomla, se ha dejado un tiempo prudencial al desarrollo que permita asumir la curva de aprendizaje de dichas especificaciones. 3.6 Presupuesto Todas las herramientas empleadas son propias de software libre y tienen coste cero. Los servidores para implantar la solución son ajenos al centro proporcionados por la Consejería de 29 de 60

30 Educación de la Comunidad de Madrid y por tanto, también, de coste cero. Queda computar las horas del desarrollo (todas), estimadas en 192 horas. A una estimación de 60 /hora resultarían No obstante, al ser un desarrollo voluntario y fuera del horario laboral el coste real es nulo. Lo mismo cabe para el mantenimiento de la aplicación. Concepto Precio unitario Unidades Total DESARROLLO Coste de licencias de software 0, ,00 Coste de alojamiento web 0, ,00 Coste de horas desarrollo: análisis, diseño e implementación 60 /hora 192 horas Coste de mantenimiento 60 /hora 50 horas 3000 Total MANTENIMIENTO Coste de licencias de software 0, ,00 Coste de alojamiento web 0, ,00 60 /hora 50 horas 3000 Total 3000 Coste de mantenimiento 30 de 60

31 4 Diseño 4.1 Definición de los niveles de arquitectura Arquitectura conceptual Los componentes participantes en la arquitectura son: La base de datos del gestor de contenidos Joomla. El directorio de almacenamiento de archivos adjuntos. El gestor de contenidos Joomla. La aplicación Internal Message. Base de datos de Joomla Tareas a realizar Componentes con los que se relaciona Almacenar los datos del gestor de contenidos. Gestor de contenidos Joomla. Almacenar los datos de la aplicación Aplicación Internal Message. Internal Message. Proporcionar la información requerida. Gestor de contenidos Joomla Tareas a realizar Componentes con los que se relaciona Gestionar el contenido del sitio web. Gestionar los usuarios del gestor. Base de datos de Joomla. 31 de 60

32 Aplicación Internal Message Tareas a realizar Componentes con los que se relaciona Gestionar el envío y recepción de Gestor de contenidos Joomla. mensajes. Aplicación Internal Message. Arquitectura lógica En la arquitectura lógica se va a incorporar detalles de los interfaces de comunicación existentes entre los componentes indicados anteriormente: 4.2 Especificación de estándares, normas de diseño y construcción Para una correcta realización del proyecto es pertinente que todos los documentos elaborados y que previsiblemente serán revisados deban de atenerse a unas características y formatos coherentes. Por ello, y tras estudiar las distintas posibilidades de estándares y recomendaciones al uso, se llegan a las siguientes recomendaciones: Documentos de diseño Este documento será de consulta tanto para los desarrolladores como para cualquier afectado por el proyecto. Se acuerda trabajar con el formato OpenDocument mediante una plantilla que contemple las siguientes características: 32 de 60

33 De forma general la fuente a utilizar será Arial 10. Todas las páginas excepto la primera contendrán una cabecera de página con el título del proyecto. Todas las páginas excepto la primera contendrán un pié de página con el contador de páginas y total del documento. En la primera página se indicará el logotipo de la empresa y el titulo del proyecto en Arial 28. Las siguientes páginas incluirán el índice de contenidos. La siguiente página indicará el responsable de la documentación así como todos los autores especificando las modificaciones introducidas en el documento con su fecha correspondiente. Diagramas de diseño En general se utilizará la notación UML exceptuando el modelo entidad-relación que se visualizará como modelo de Chen, todo ello desarrollado mediante la herramienta DIA. Código fuente Las recomendaciones de estilo en el código fuente están establecidas por Joomla [5]. Vamos a citar las más importantes: Almacenamiento de los ficheros en formato ASCII, usando codificación UTF8 y fin de línea tipo UNIX. La indentación se realiza con tabuladores de 4 espacios de longitud. Los comentarios en línea debe seguir las convenciones de PHPDoc [6]. Las etiquetas de PHP deben ser completas <?php?>. Las constantes se deben escribir en mayúsculas con subrayado para separar las palabras. Las palabras claves de las sentencias SQL se deben escribir en mayúsculas mientras que el resto de identificadores se escribirán en minúsculas. Los nombres de controladores, modelos, vistas y añadidos vienen en parte determinados. Documentación técnica La documentación técnica se extraerá directamente mediante la herramienta PHPDoc. 4.3 Identificación de subsistemas Se puede dividir el sistema Internal Message en los siguientes subsistemas: El subsistema de configuración: pertenece al back-end de Joomla y define la configuración del aplicativo dentro de este. El subsistema de aplicación de usuario: se encarga de toda la operativa del aplicativo a nivel de 33 de 60

34 usuario. Este último subsistema se va a dividir para facilitar su comprensión. Subsistema de aplicación de usuario Se divide desde un punto de vista funcional en: El subsistema de gestión de grupos de destinatarios: define los grupos de destinatarios preasignados por un usuario. El subsistema de mensajes: gestiona el envío y recepción de mensajes entre usuarios Revisión de casos de uso Relativo al caso de uso Grupo de destinatarios Los casos de uso relacionados con alta, baja o modificaciones de los grupos de destinatarios precisan del uso de los subsistemas Grupos de destinatarios y Datos. La comunicación entre los subsistemas se realizará mediante sentencias SQL. 34 de 60

35 Relativo al caso de uso Envío de mensajes El caso de uso Envío de mensajes precisa la intervención de los subsistemas Usuario, Datos y Adjunto. La comunicación entre los subsistemas Usuario y Datos se realizará mediante sentencias SQL. La comunicación entre los subsistemas Usuario y Adjunto se realizará mediante llamadas al sistema de ficheros. Relativo al caso de uso Recepción de mensajes El caso de uso Recepción de mensajes precisa la intervención de los subsistemas Usuario, Datos y Adjunto. La comunicación entre los subsistemas Usuario y Datos se realizará mediante sentencias SQL. La comunicación entre los subsistemas Usuario y Adjunto se realizará mediante llamadas al sistema de ficheros Diagrama entidad-relación Tras definir los casos de uso es necesario establecer la estructura de la base de datos. La base de datos será de tipo relacional, utilizándose el gestor de base de datos MySQL que implementa por defecto Joomla. El diagrama entidad-relación que modela el sistema es el siguiente: 4.4 Elección de componentes y licencias Componentes y productos a utilizar Los componentes y productos que se van a integrar en el desarrollo son: 35 de 60

36 Producto Solución Licencia Base de datos MySQL GPL Lenguaje del lado servidor PHP PHP License Gestor de contenidos Joomla GPL Editor wysiwyg TinyMCE LGPL Imágenes descargadas CopyLeft Feel free to download the favicon that you would like to use Elección de licencia final para el producto desarrollado El producto final desarrollado debe disponer de una licencia lo menos restrictiva posible. Como el producto utiliza el desarrollo del gestor de contenidos de Joomla puede directamente utilizar dicha licencia. Por tanto se adopta como licencia del desarrollo final del producto la conocida como GNU Public License (GPL), versión 2 (de junio de 1991). 4.5 Especificaciones de desarrollo y pruebas de implantación Entorno tecnológico de desarrollo Aunque anteriormente ya se han indicado las herramientas a utilizar vamos a separar éstas en función de su utilidad: Aplicaciones de servidor7 Producto Solución Sistema operativo MAX (Madrid_linuX) Servidor web Apache Base de datos MySQL Lenguaje del lado servidor PHP Gestor de contenidos Joomla Aplicaciones de desarrollo 7 Durante la mayor parte del desarrollo el servidor se alojará en el mismo ordenador de desarrollo para evitar tiempos de espera en cargas y descargas. 36 de 60

37 Producto Solución Entorno integrado de desarrollo Geany Editor gráfico GIMP Planificador Planner Navegador Firefox Navegador Chromium Aplicaciones de documentación Producto Solución Editor gráfico GIMP Suite ofimática OpenOffice Editor de diagramas Dia Planificador Planner Documentador PHPDoc Restricciones técnicas y de seguridad Las restricciones técnicas vienen marcadas por las propias de Joomla 1.5 [7], ya reflejadas anteriormente en el Análisis dentro del apartado Entorno tecnológico del sistema que se resumen en: Software Recomendado Mínimo Excepto PHP ,4.4.2,5.0.4 MySQL 4.1.X X+ aún no disponible Apache 2.X+ 1.3 Respecto a la seguridad se deberá seguir la guía de seguridad para extensiones de Joomla [10], que señala entre otros puntos: seguridad contra accesos directos, seguridad contra inclusión de ficheros remotos, seguridad contra inyección de sentencias SQL, programación sin uso de register_globals, y chequeo de los privilegios de usuarios. Muchas extensiones de Joomla presentan vulnerabilidades que pueden servir de aviso para el desarrollo de nuestro propio producto [11]. Además de las anteriores, las propias especificaciones del producto a desarrollar indican la necesidad de utilizar algún tipo de codificación en los datos almacenados en la base de datos. Se decide utilizar la codificación MIME base de 60

38 4.6 Requisitos de implantación En tanto que el desarrollo tiene vocación de aplicación general extrapolable e instalable en cualquier gestor de contenidos Joomla 1.5, los requisitos de implantación referentes a necesidades de hardware, software, comunicaciones y rendimiento coinciden básicamente con las características mínimas de ejecución de Joomla ya indicadas en el punto anterior. La formación de los usuarios es un aspecto fundamental a la hora de implantar un nuevo sistema. La formación generalizada mediante un curso previo se descarta en tanto que el interfaz de usuario debe ser lo suficientemente sencillo para que cualquier usuario lo considere usable y además por que este tipo de formación no enfrenta a los usuarios con problemas reales. Otro motivo añadido para no utilizar este tipo de formación es que no resulta adecuada cuando el índice de rotación de personal es medio-alto, como es nuestro caso. Se opta, por tanto, por la generación de unos pequeños vídeos didácticos que muestren un uso básico de las herramientas para introducir su uso. En paralelo se dará apoyo in situ a los usuarios que sigan teniendo dificultades en el uso del sistema. En el remoto caso de que estos problemas de usabilidad se mantengan en el tiempo debería replantearse la interfaz de usuario. 38 de 60

39 5 Desarrollo El desarrollo va a ser realizado por una única persona. Esto incide favorablemente en los tiempos de desarrollo pues se reduce la curva de aprendizaje de la metodología a aplicar por todo el equipo y los tiempos de puesta en común del conocimiento. Sin embargo presenta otros aspectos perjudiciales en tanto que las soluciones a aportar no están contrastadas por otros expertos y ello puede hacer que obligue a retrocesos en el proceso de desarrollo. Aunque no se va a aplicar una metodología estricta, se van a seguir las pautas básicas de las metodologías ágiles y más concretamente de la metodología Scrum [17][DEE] con las siguientes adaptaciones: No va a haber una reunión diaria del equipo de desarrollo al ser un único desarrollador. El desarrollador ejercerá el rol de ScrumMaster. Cada una de los apartados en que se descompondrá el desarrollo no superará los seis días de desarrollo coincidiendo con un ciclo de trabajo o sprint. Al final de cada sprint se inspeccionará y adaptará el software desarrollado. Para ello el director de la organización (cliente del producto) verá el desarrollo en funcionamiento y podrá aportar sugerencias o identificar elementos inexactos. 5.1 Identificación de extensiones a desarrollar Según la estructura de extensiones de Joomla se necesita desarrollar un componente y un módulo. El componente com_internalmessage generará tanto el back-end como el front-end de la aplicación. El front-end estará activo cuando un usuario esté identificado en el gestor de contenidos. Este componente debe satisfacer todos los requisitos establecidos para la aplicación. El módulo mod_internalmessage permitirá emitir un mensaje cuando haya envíos sin leer. Este módulo será el último en ser desarrollado por su bajísima complejidad. 5.2 Planificación de las actividades de desarrollo e integración del sistema Se ha planificado el desarrollo según los subsistemas definidos. Además se ha añadido una fase de integración de subsistemas y, dado que Joomla precisa de la generación de paquetes para proceder a la instalación de componentes y módulos, otro periodo para crear los paquetes pertinentes. El siguiente diagrama muestra los tiempos aplicados a cada una de las tareas. 39 de 60

40 Los tiempos previstos no se han visto modificados en modo alguno, permaneciendo el tiempo de entrega invariable. De hecho se han realizado una par de ampliaciones una proveniente de las reuniones mantenidas con el director del centro al final de cada sprint y otra sugerida por el propio desarrollador. La primera de ellas consiste en incorporar un aviso mediante correo electrónico ante la llegada de un mensaje en Internal Message. La segunda consiste en que el sistema desarrollado sea plurilingüe, soportando en esta primera versión los idiomas inglés, castellano y catalán. 5.3 Descripción del entorno de desarrollo Producto Solución Versión Sistema operativo MAX (Madrid_linuX) 6.0 Servidor web Apache de 60

41 Producto Solución Versión Base de datos MySQL Lenguaje del lado servidor PHP Entorno integrado de desarrollo Geany 0.18 Editor gráfico GIMP 2.6 Suite ofimática OpenOffice 3.0 Editor de diagramas Dia Planificador Planner Navegador Firefox Navegador Chromium Gestor de contenidos Joomla A este entorno en local hay que incluir un servidor externo para demostraciones al que se accede a través de la dirección y que cuenta con datos de demostración para comprobar el funcionamiento del sistema. 5.4 Estructura de directorios En el desarrollo de componentes para Joomla hay que tener en cuenta como se realiza la distribución de los ficheros según los directorios, así como los nombres que deben tener cada una de las clases desarrolladas. De forma general la estructura de directorios desplegada es la que sigue: Directorio Contenido administrator/components Back-end de los componentes. administrator/components/com_internalmessage Back-end de nuestro componente. administrator/language Un directorio por cada idioma del back-end. Dentro, un fichero por cada componente. components Front-end de los componentes. components/com_internalmessage Front-end de nuestro componente. modules Módulos modules/mod_internalmessage Nuestro módulo language Un directorio por cada idioma del front-end. Dentro, un fichero por cada componente y módulo. Sin embargo la parte que nos interesa es la estructura del front-end del componente, que se atiene estrictamente al modelo vista-controlador. Fichero / Directorio Contenido <componente>.php Inicio del componente. 41 de 60

42 controller.php controllers/<componente>.php Controladores de la aplicación. media/css/index.css Hojas de estilo. media/images/* Imágenes utilizadas en la aplicación. models/<componente>.php Modelo de la aplicación. Dicha clase contiene todas las llamadas a la base de datos y al sistema de ficheros. views views/groups/view.html.php views/inbox/view.html.php views/new/view.html.php views/outbox/view.html.php views/saved/view.html.php views/show/view.html.php Vistas de la aplicación: gestión de grupos de destinatarios bandeja de entrada nuevo mensaje bandeja de salida mensajes guardados mostrar un mensaje views/*/tmpl/default.php Plantilla de cada una de las vistas 5.5 Sistema de empaquetamiento El sistema de empaquetamiento de un componente describe, mediante un fichero XML, el destino de cada uno de los ficheros fuente. Se compone de un fichero install.xml que además de datos básicos <name>internal Message</name> <creationdate>may 2010</creationDate> <author>amadeo Mora</author> <author >internalmessage@gmail.com</author > <authorurl> <copyright>copyright Info</copyright> <license>license Info</license> <version>11.05</version> define dos carpetas: site y admin correspondientes al front-end y al back-end respectivamente además incluye una sección para indicar los ficheros SQL que son necesarios ejecutar contra la base de datos al instalar o desinstalar el componente. Todos los ficheros del componente deben estar catalogados en el fichero XML. De lo contrario la instalación no sería posible. 42 de 60

43 6 Implantación El sistema desarrollado debe ponerse en producción. Para ello vamos a establecer los pasos a dar y las acciones a tomar con los agentes implicados. 6.1 Implantación del sistema y pruebas En el desarrollo del proyecto se han obtenido dos paquetes denominados com_internalmessage.tar.gz y mod_internalmessage.tar.gz. Dentro de la administración de Joomla debemos acceder al menú Extensiones y seleccionar la opción de Instalar/Desinstalar apareciendo una pantalla desde la cual podemos subir en el orden indicado ambos paquetes. El anexo Instalación de Internal Message desarrolla la instalación del componente. Posteriormente debemos configurar el componente instalado. Para ello accedemos al menú Componentes y seleccionamos la opción Internal Message. Pulsamos el botón Preferencias y podemos elegir el directorio donde se guardaran los ficheros adjuntos y si los usuarios van a obtener una notificación por correo electrónico de que ha llegado un mensaje a su cuenta. Guardamos esta configuración y sólo queda incorporar el componente a los menús y el módulo a alguna vista del gestor de contenidos. El tipo de ítem de menú a elegir debe ser Internal Message > Inbox que mostrará como primera pantalla la bandeja de entrada. Opcionalmente se puede instalar el módulo desarrollado. El proceso de instalación es similar al descrito anteriormente para el componente. Una vez instalados hay que asociarlo a alguna zona definida de la plantilla de Joomla. Típicamente se posicionará en la zona left o right. 6.2 Acuerdo del nivel de servicios Al ser un desarrollo de un producto final no se fija un nivel de servicios determinado. No obstante se va a acordar un mantenimiento de la aplicación durante un tiempo determinado. 6.3 Aceptación del sistema Durante el desarrollo se han ido realizando presentaciones del funcionamiento de los distintos subsistemas. Finalmente se ha realizado una demostración completa del producto final y se ha entregado toda la documentación del proyecto. 43 de 60

44 Una vez aceptado por el cliente se considera que el producto pasa a producción y comienza la fase de mantenimiento. 7 Mantenimiento Durante las pruebas realizadas en la integración de subsistemas y posteriormente en la integración con el gestor de contenidos de Joomla se han depurado algunas imperfecciones. Para la puesta en marcha se ha conseguido la no aparición de ningún error. De ello se deduce que el mantenimiento deberá ser considerado en todo caso de mejora de las funcionalidades incorporadas y por tanto debe considerarse evolutivo. Esto unido a que el desarrollador va a ser el encargado del mantenimiento va a facilitar las cuestiones relacionadas con la trasferencia de conocimiento. 8 Conclusiones El sistema Internal Message se ha desarrollado sin partir de ningún componente de software previo y con visos de ser ampliado en siguiente versiones. El desarrollo del sistema ha sido viable en los tiempos fijados, está integrado en el gestor de contenidos Joomla y es extrapolable a otros centros educativos o a cualquier organización que así lo precise. Todas las herramientas utilizadas para su desarrollo tienen licencias libres así como los objetos que incorpora. Finalmente y para satisfacer la posibilidad de que sea utilizado libremente se ha distribuido con una licencia GNU Public License versión 2. Aportará al mundo del software libre y específicamente a las aplicaciones para el gestor de contenidos de Joomla de un sistema de mensajería integrado, simple y fiable. Existe una alta satisfacción con el desarrollo del proyecto pues todos los objetivos iniciales se han cumplido e incluso se han añadido los siguientes: la posibilidad de enviar mensajes de correo electrónico a los usuarios avisándoles de que les ha llegado un mensaje en el sistema, plurilingüe, estando disponible ya la versión al inglés, catalán y castellano. Algunos de los objetivos iniciales no parecían fáciles de alcanzar como el uso de un editor visual, el almacenamiento de cualquier tipo de información y que además esta información se almacenase con algún tipo de encriptación. Sin embargo se han encadenado las decisiones y acciones para que la propia forma de almacenamiento haya permitido satisfacer el resto de requisitos. No obstante, se pueden desarrollar multitud de ampliaciones en función de las diversas necesidades. Algunas se nos antojan cercanas y factibles, como: 44 de 60

45 incorporar más de un fichero adjunto por mensaje, incluir etiquetas para poder clasificar los mensajes, realizar búsquedas por texto libre. Aunque no puede considerarse como una mejora, también cabe actualizar el producto desarrollado a la versión 1.6 de Joomla para poder utilizarla en nuevas instalaciones. A lo largo del desarrollo se han tomado decisiones que a la larga se podían haber simplificado, sin embargo la propia estructura del código, obligada por el modelo vista-controlador propuesto por Joomla, hace muy fácil que en posteriores versiones del proyecto se modifiquen sin implicar cambios en la presentación al usuario. Como ejemplo, si desde un primer momento se hubiera facilitado la posibilidad de incluir etiquetas a los mensajes no habría hecho falta establecer una carpeta de mensajes guardados. Únicamente dispondríamos de las bandejas de entrada y de salida, adoptándose una interfaz única para mostrar las bandejas de mensajes. En tanto que este sistema debe constatar el envío de comunicaciones, otra decisión que se hubiera tomado es no permitir eliminar mensajes. En la próxima versión se tendrá en cuenta. De todos modos y siendo crítico con el desarrollo se ha hecho patente la necesidad de disponer de un mayor tiempo para conocer en profundidad la metodología de desarrollo propuesta por Joomla. En conjunto, este proyecto me ha acercado, aún más, al software libre, la documentación libre y, por generalización, al conocimiento libre. Estoy ligado al uso, desarrollo y difusión del software libre, de forma directa, desde el año 1998 en que se puso en marcha una granja de ordenadores con Red Hat en el PNTIC 8 del Ministerio de Educación, donde ejercía como Jefe del Gabinete de Telemática, para dar acceso gratuito a Internet a todo el profesorado. Posteriormente desarrollé la plataforma de formación a distancia del profesorado ( de dicha institución con software libre que sigue actualmente formando anualmente a más de veinte mil profesores. Dicha plataforma se utiliza en varias comunidades autónomas y en algunos países iberoamericanos. En los últimos tiempos me incorporé al equipo de desarrollo de MAX (Madrid_linuX) ( para aportar mi experiencia en el mundo de la educación y en el desarrollo de software a una distribución educativa libre actualmente implantada en los centros educativos Comunidad de Madrid y con ligeras adaptaciones exporta a algunos países iberoamericanos. Además de mi trabajo cotidiano como profesor de informática en formación profesional, imparto docencia en el Máster de Tecnologías para la Educación y el Conocimiento de la UNED ( específicamente el módulo denominado Herramientas informáticas para la Educación: Linux y Software Libre. De todo lo anterior se puede deducir fácilmente que estoy volcado y confío plenamente en el software libre, no sólo en sus intrínsecas bondades como software sino en la magnífica base de conocimientos para los futuros profesionales en tecnologías y en su vocación de aglutinador de personas que desean y promueven una sociedad mejor y fundamentalmente libre. 8 Programa Nacional de Nuevas Tecnologías de la Información y la Comunicación. Posteriormente ha tenido distintos nombres y estructuras organizativas, a saber: Centro Nacional de Información y Comunicación Educativa (CNICE), Instituto Superior de Formación y Recursos en Red para el Profesorado y actualmente Instituto de Tecnologías Educativas (ITE). ( 45 de 60

46 9 Bibliografía / webgrafía Bibliografía [CAM] Camps R. y otros. Bases de datos. UOC [DEE] Deemer P. y otros. Información básica de Scrum. Scrum Training Institute Disponible en (Última revisión 7/5/2011). [GIB] Gibert, M. y Peña A. Ingeniería del Software en Entornos de Software Libre. UOC [LEB] Leblanc. J. Learning Joomla! Extension Development: Creating Modules, Components, and Plugins with PHP. Packt Publishing [OTE] Otero, A. Proyecto Web. UOC [RAH] Rahmel D. Professional Joomla!. Wrok/Wiley Webgrafía [1] Joomla: [2] API: [3] Desarrollo: [4] Documentación: [5] Estilo de codificación: [6] Estilo de comentarios: [7] Requerimientos técnicos: [8] Extensiones: [9] Extensiones de sistemas de mensajería personal: [10] Seguridad en el desarrollo de extensiones: [11] Vulnerabilidades de extensiones: [12] MySQL: [13] Documentación: [14] PHP: [15] Documentación: [16] Proyectos ágiles: [17] Scrum: [18] UML: 46 de 60

47 Anexo I. Estructura de almacenamiento Por razones de complejidad, velocidad en consultas y el uso del modo de almacenamiento MyISAM de MySQL que no soporta la integridad referencial, el modelo relacional resultante es el siguiente: La tabla #_users9 ya existe en Joomla y provee al componente del identificador de usuario, su nombre y correo electrónico. En la tabla siguiente se muestran los campos que son utilizados por la aplicación. #_users Atributo Significado id Identificador del usuario name Nombre completo del usuario username Nombre de usuario Correo electrónico del usuario block Usuario bloqueado gid Identificador de grupo El resto de campos que son susceptibles de ser consultados son accedidos mediante el API de Joomla. La tabla #_internalmessage_groups contiene los grupos de destinatarios: 9 En Joomla las tablas permiten introducir prefijos para separar distintas versiones u otros usos. Esto se indica mediante la notación #_. En el Anexo III se puede ver un esquema de tablas de Joomla. 47 de 60

48 #_internalmessage_groups Atributo Significado id Identificador del grupo id_owner Identificador del usuario propietario del grupo En el caso de grupos genéricos creados por administradores el valor será 0 name Nombre del grupo description Descripción del grupo (actualmente sin uso) members Lista separada por comas de los identificadores de usuario que conforman el grupo membersonly Grupo utilizable sólo para miembros del grupo public Grupo público La tabla #_internalmessage contiene los mensajes enviados: #_internalmessage Atributo Significado id Identificador del mensaje id_refered En el caso de mensaje multi-destinatario hará referencia al primer mensaje enviado id_from Identificador del emisor id_to Identificador del destinatario date Fecha y hora de envío del mensaje subject Asunto del mensaje text Texto del mensaje attachment_name Nombre del fichero adjunto attachment_size Tamaño en bytes del fichero adjunto readed Leído por el destinatario deleted_from Borrado por el emisor deleted_to Borrado por el destinatario saved_from Salvado por el emisor saved_to Salvado por el destinatario El almacenamiento físico de los ficheros adjuntos se realiza en un directorio a determinar en el proceso de configuración. El nombre de cada fichero es file_<id> siendo id el identificador del mensaje. En el caso de mensajes multidestinatario el fichero coincidirá con file_<id_refered> siendo id_refered el identificador del mensaje enviado al primer destinatario. 48 de 60

49 Anexo II. Esquema de la base de datos de Joomla. Fuente: 49 de 60

50 Anexo III. Instalación de Internal Message Instalación del componente Accedemos a administración de Joomla: Seleccionamos la opción Extensiones > Instalar/Desinstalar 50 de 60

51 Elegimos el paquete que contiene el componente y pinchamos en Subir Archivo & Instalar. Ya está instalado. Ahora accedemos a Componentes > Internal Message. 51 de 60

52 Aparece la pantalla de configuración de Internal Message y pulsamos el icono Preferencias. Configuramos el componente y pinchamos en Guardar. En este momento ya está funcionando Internal Message! Ahora hay que integrarlo en los menús del gestor de contenidos. Seleccionamos el menú donde queremos integrar Internal Message. 52 de 60

53 Indicamos que queremos crear una nueva entrada de menú. Debemos indicar el tipo de componente asociado al menú. En nuestro caso seleccionamos Internal Message. Dentro de Internal Message podemos elegir nuestra primera pantalla. Parece adecuado comenzar viendo la bandeja de entrada. Indicamos el resto de características de la entrada de menú. En nuestro caso en el menú de Inicio, para usuarios registrados y guardamos. 53 de 60

54 Ya está creada la entrada de menú. Entramos en el front-end del gestor de contenidos y desplegamos el menú de Inicio. Sólo queda seleccionar el menú de mensajería y ya aparece funcionando Internal Message. 54 de 60