Universidad de Deusto Ingeniería en Informática Análisis, diseño e implementación de una arquitectura de tres capas para GNU Mailman Alvaro Uría Avellanal Director: Pablo Garaizar Sagarminaga Enero de 2007
Resumen GNU Mailman es un software para la gestión de listas de correo electrónico, cuya principal distinción con el resto de gestores de listas es la interfaz web para la administración de las mismas, fácil de usar y traducida a múltiples idiomas. Actualmente, todo el texto y etiquetas HTML de las páginas web del proyecto se encuentra incrustado en el propio código fuente de la aplicación, con lo que hace difícil el cambio de apariencia o, en definitiva, la personalización de cada sitio que utiliza GNU Mailman. El presente Proyecto Fin de Carrera propone un nuevo diseño del módulo que ejecuta dicha interfaz web con la intención de separar el contenido (texto y código HTML) del continente (la capa de negocio que relaciona el soporte CGI del núcleo con la interfaz), y así hacer trivial el cambio de imagen de los sitios web. Descriptores GNU Mailman, Listas de distribución, Correo electrónico, Interfaz web, Python iii
Índice general Índice general 1. Resumen del proyecto 1 2. Introducción 3 3. Definición del proyecto 5 3.1. Objetivos del proyecto.............................. 5 3.2. Alcance del proyecto............................... 6 4. Descripción de la realización 7 4.1. Método de desarrollo............................... 7 4.2. Tareas principales................................ 8 4.3. Hojas de tareas.................................. 10 5. Organización, Equipo 15 5.1. Esquema organizativo.............................. 15 6. Condiciones de ejecución 17 6.1. Entorno de trabajo................................ 17 6.2. Gestión de cambios, modificaciones e incidencias............... 17 7. 19 7.1. Estimaciones de cargas de trabajo....................... 19 7.2. Reparto de las cargas por perfiles........................ 20 7.3. Plan de trabajo.................................. 21 8. Presupuesto 27 Acrónimos 29 Bibliografía (Libros y artículos) 31 Bibliografía (Otras fuentes documentales) 33 v
Índice de figuras Índice de figuras 7.1. Reparto de cargas de trabajo.......................... 22 7.2. Diagrama de Gantt de la fase de documentación............... 23 7.3. Diagrama de Gantt de la fase de análisis y diseño............... 23 7.4. Diagrama de Gantt de la fase de implementación............... 23 7.5. Diagrama de Gantt de la fase de pruebas................... 23 7.6. Diagrama de Gantt de la fase de implantación................. 23 7.7. Diagrama de Gantt general........................... 25 vii
Índice de tablas Índice de tablas 4.1. Tarea 1: Elaboración de documentos...................... 11 4.2. Tarea 2: Análisis de requisitos.......................... 11 4.3. Tarea 3: Diseño del proyecto........................... 12 4.4. Tarea 4: Implementación del sistema final................... 12 4.5. Tarea 5: Implantación de la aplicación..................... 13 7.1. Carga de trabajo de Alvaro Uría........................ 20 7.2. Vacaciones de Alvaro Uría............................ 21 ix
1 Resumen del proyecto CAPÍTULO 1 Resumen del proyecto El correo electrónico es uno de los servicios de comunicación más utilizados en el mundo. Desde que fuera creado allá por los años 60 en las universidades estadounidenses, ha ido creciendo su uso en lugar del correo ordinario y otros, debido en parte a su bajo coste y rapidez envío y recibo de mensajes de cualquier parte del planeta en pocos segundos, además de la posibilidad de incluir archivos como los antiguos paquetes en dichos mensajes. Por otro lado, las listas de correo son un uso especial del correo electrónico que permite la distribución masiva de información entre múltiples usuarios de Internet en simultáneo. En una lista de correo se escribe un mensaje a la dirección de la lista (ej.: lista@deusto.es) y le llega masivamente a todas las personas inscritas en la lista. Dependiendo de cómo esté configurada la lista de correo, el usuario podrá o no tener la posibilidad de enviar mensajes. Muchas organizaciones utilizan cada vez más esta herramienta para mantener informadas a las personas principalmente con noticias, publicidad e información de interés. Para no caer en prácticas de publicidad no solicitada, los correos se envían previa inscripción del destinatario, dándole la oportunidad de cancelar la misma cuando guste. En los inicios de este sistema de comunicación, los usuarios que querían suscribirse debían enviar un mensaje a una dirección de correo distinta a la que identifica a la lista que procesaba dicha suscripción y avisaba del resultado al usuario. Con el tiempo, y con el avance de la Web, nacieron otras formas de proceso de suscripción que comunicaban al usuario a través de una página de Internet con un sencillo formulario para identificar la dirección de correo que recibiría los mensajes. Dichas tecnologías Web siguen avanzando, y con ello la necesidad de mejorar los antiguos sistemas, que cada vez más reciben una gran demanda para su uso, debiéndose ajustar a la imagen corporativa que dichos clientes tienen en Internet, además de ampliar sus cualidades para la cada vez más diversa demanda. En el caso concreto de la universidad, las listas de distribución componen un lugar de comunicación con áreas temáticas muy diferentes: listas de clase, comunicación entre 1
1 Resumen del proyecto personal docente y/o no docente, grupos de interés... Es conveniente, en aras de una mayor claridad, separar las distintas áreas temáticas, resaltar algunas listas en concreto, etc. En definitiva, personalizar la interfaz web del gestor de listas, con el fin de adaptarse a las necesidades cambiantes. Por otro lado, actualmente, cada suscripción a cada una de las listas que gestione un sitio web se administra, en su mayoría, de manera independiente. Es decir, un usuario suscrito con dos o más cuentas diferentes es reflejado en el sistema como personas distintas e independientes. A su vez, dicho usuario debe recordar con qué cuenta se inscribió a una determinada lista, y salvo petición de recordatorio, gestionar múltiples claves de acceso distintas. Con este proyecto se pretende eliminar estos problemas creando la figura de usuario registrado que centralice toda la información sobre ese usuario. Se estima que la finalización del proyecto sea para las fechas de mediados o finales de marzo de 2007, no superando un presupuesto de 6.000 e. 2
2 Introducción CAPÍTULO 2 Introducción Este documento tiene como objetivo presentar una propuesta de proyecto de ingeniería del software sobre el gestor de listas de correo GNU Mailman, con el fin de mejorar la interfaz web del mismo. Se van a detallar tanto los objetivos que se pretenden alcanzar como las fases, actividades y recursos que serán necesarios para su completo funcionamiento. El propósito principal del proyecto es superar los problemas de gestión de los usuarios y mejorar la interacción de los mismos con la aplicación, utilizando, para ello, los nuevos enfoques de desarrollo web existentes actualmente. A continuación se describen cada una de las partes que componen este documento: Resumen para la dirección: Este apartado está dirigido exclusivamente a la dirección ejecutiva del Servicio Informático de la Universidad; en él se describen tanto la situación actual como los beneficios de la implantación. Se señalan los objetivos del sistema, destacando las estimaciones de costes y tiempo necesarias. Visión general del sistema: En esta sección se detallarán las funciones que más tarde se implantarán en el sistema, así como las que se quedan fuera de él, delimitando claramente el alcance del proyecto. Método de Desarrollo: En este bloque se describe cómo va a ser la realización del proyecto y en qué fases va a realizarse, junto a las normas que se seguirán durante todo el proceso. Productos y criterios de terminación: A lo largo del proyecto se precisarán revisiones y aprobaciones para los productos intermedios así como criterios de finalización del proyecto completo: qué requisitos deben cumplirse, en qué período, etc. Tareas principales: En cada una de las etapas del proyecto se muestran las responsabilidades adjudicadas a cada miembro del equipo de desarrollo. Se enumeran 3
2 Introducción los responsables de los departamentos involucrados así como los encargados de los módulos a quien se podrá pedir explicaciones en caso de fallo. Estimaciones de presupuestos y tiempo: Se incluyen las estimaciones de los recursos, tanto materiales como humanos, que van a ser necesarios para la finalización del proyecto. 4
3 Definición del proyecto CAPÍTULO 3 Definición del proyecto 3.1 Objetivos del proyecto Las funciones de la aplicación variarán dependiendo del rol del usuario. Éstos pueden ser: usuario no registrado o usuario registrado. En el caso del usuario registrado, éste puede ser, además: usuario, moderador o administrador de alguna lista. Por otro lado, existe también la figura de administrador del gestor de listas. En el caso de un usuario no registrado, éste puede recorrer la zona pública del sitio Web, visitar los archivos públicos de las listas que los tengan disponibles y registrarse en el sitio Web. En el caso de un usuario registrado, éste tendrá, por defecto, permisos de usuario, que le da opción de suscribirse a cualquiera de las listas de correo disponibles. Además, podrá controlar desde un panel personalizado el estado de su cuenta y suscripciones, pudiendo darse de baja o modificar dicha configuración. Los dos siguientes niveles de usuario registrado corresponden al moderador y administrador de una lista. Dicho usuario puede ser moderador o administrador de múltiples listas. La función del moderador es controlar los mensajes que se envían a la lista que modera, pudiendo retener mensajes a la espera de decidir si permitir los envíos al resto de usuarios suscritos, o bien rechazarlos. Por contra, el administrador de la lista, además de poder llevar a cabo las funciones de moderador, es el encargado de la configuración de la misma. Dicha configuración se encuentra bien definida en la aplicación actual y no se modificará. Por último, y no menos importante, el administrador del gestor de listas es el encargado del buen funcionamiento de todo el sitio Web, teniendo acceso a todas las opciones que presenta. 5
3 Definición del proyecto 3.2 Alcance del proyecto 3.2.1 Descripción del perímetro funcional del proyecto Actualmente, la aplicación GNU Mailman es utilizada por un vasto número de entidades, a su vez muy diversas las unas de las otras. Por nombrar algunos ejemplos, dicha aplicación se utiliza en la mayoría de universidades estadounidenses y españolas, con el fin de comunicar a profesores y personal universitario entre sí, y con sus alumnos. A su vez, este gestor de listas es ampliamente utilizado en la comunidad de usuarios y desarrolladores de software libre, siendo la aplicación en sí igualmente libre. Por último, algunas empresas, como Apple Computers, la utilizan, aunque modificada personalmente para guardar la imagen corporativa de su sitio web, para mantenerse cercanos a sus usuarios (y expertos). El presente proyecto que se quiere llevar a cabo haría más sencilla la gestión de los usuarios que utilizan la aplicación, y facilitaría el trabajo a sus administradores. Se quiere hacer especial énfasis en la claridad y ordenación de la información que se presenta, además de permitir el uso de una misma aplicación para distintos fines, que pueden requerir imágenes corporativas diferentes. 6
4 Descripción de la realización CAPÍTULO 4 Descripción de la realización 4.1 Método de desarrollo En aras de una división en partes menos complejas, se han detallado varias fases que pueden llevarse a cabo, en algunos casos, de manera no secuencial. 4.1.1 Documentación Esta fase engloba la investigación que se llevará a cabo sobre la materia, leyendo y estudiando documentación técnica que servirá para entender la filosofía de funcionamiento de la tecnología a utilizar, y que facilitará la toma de decisiones en este campo. 4.1.2 Diseño Durante la fase de documentación, se empieza a realizar un esbozo del modelo que se quiere construir, además de perfilar prototipos básicos. En esta fase se define inicialmente un diseño global del sistema, el cual necesitará de la aprobación del director de proyecto, para continuar con el diseño detallado de cada una de las capas que formarán el proyecto a implementar. 4.1.3 Implementación En esta fase se procede a codificar cada una de las partes que forman el diseño global del sistema en el lenguaje de programación seleccionado. 4.1.4 Pruebas Durante esta fase se lleva a cabo la comprobación de los posibles errores, para lo cual se ha de realizar un proceso de pruebas del sistema general, que consiste en evaluar los posibles errores que tenga para poder resolverlos antes de su puesta en marcha. 7
4 Descripción de la realización En esta fase podrán ocurrir solapamientos con las dos fases anteriores, para ir corrigiendo los posibles fallos o mejoras controladas. 4.1.5 Implantación y mantenimiento Por último, se procede a la instalación de la aplicación completa en una máquina con servicio web y de correo, especialmente configurados para la correcta ejecución de la misma. En esta sección se van a relacionar las responsabilidades del equipo del proyecto y de los departamentos usuarios. Debe quedar claro que la empresa que realiza el desarrollo pone todos los medios técnicos y humanos para la realización del proyecto. Es decir, el personal de dicha empresa trabajará en sus propias instalaciones. A pesar de llevar a cabo un proyecto reutilizable por cualquier particular u organización, este proyecto se realiza en base a la petición de un cliente. 4.2 Tareas principales En esta sección se van a relacionar las responsabilidades del equipo del proyecto y de los departamentos usuarios. Debe quedar claro que la empresa que realiza el desarrollo pone todos los medios técnicos y humanos para la realización del proyecto. Es decir, el personal de dicha empresa trabajará en sus propias instalaciones. A pesar de llevar a cabo un proyecto reutilizable por cualquier particular u organización, este proyecto se realiza en base a la petición de un cliente. 4.2.1 Informe de requisitos del sistema Entrevista con el cliente. Uno de los analistas se encarga de anotar detalladamente cada uno de los aspectos que tienen relación con la aplicación solicitada. Documento de requisitos. Una vez detalladas todas las ideas que abarca el cliente, un analista se encargará de plasmar dichas ideas, de forma ordenada, en un documento de requisitos. Para ello se seguirán las normas establecidas por la ingeniería del software. 4.2.2 Informe de diseño preliminar Revisión del proyecto inicial. Se observará, por medio de una reunión con el cliente, si el proyecto cumple con sus expectativas, mostrando el documento de requisitos y debatiendo si todo está en orden o si se deben realizar cambios. Establecimiento de unos planes de trabajo. Se organizaran juntas con los diferentes jefes de departamento para establecer unos planes de trabajo para la realización de la aplicación. Diseño de una prototipo de la aplicación. Se realizará un prototipo para mostrárselo al cliente y obtener su aprobación para poder continuar con la fase de diseño del proyecto. 4.2.3 Informe de diseño detallado Estructuración de la aplicación. Se establecerá una serie de criterios de organización para conocer las funciones de cada equipo y evitar solapamientos inoportunos. 8
4.2 Tareas principales Seguimiento del proceso de diseño. Se supervisará el proceso de diseño por medio de reuniones con los empleados encargados de esta área de trabajo. Además, todos los departamentos que colaboran en el proyecto tendrán acceso a un servicio compartido donde podrán ir apuntando información sobre las tareas pendientes (y posteriormente actualizarlas como terminadas ), e ir añadiendo documentación o noticias sobre sus progresos. Realización de informes. Se realizarán informes de situación con datos proporcionados por el seguimiento de los empleados a través de las reuniones y las estadísticas y resúmenes del servicio compartido facilitado. 4.2.4 Especificaciones de codificación Análisis de codificaciones. Durante esta tarea se discutirán las distintas codificaciones propuestas con el fin de buscar la más óptima. Esto es, aquella que no provoque conflictos ante situaciones comunes o no. Realización del informe de codificación. en que se codificará la aplicación. Se realizará un informe detallado de la forma 4.2.5 Programas Reunión con el director de proyecto. Se describirán los logros conseguidos y se presentarán las ideas que se piensan desarrollar a continuación. 4.2.6 Programación y Pruebas de Unidad Supervisión de los grupos de trabajo. Al igual que en la fase de diseño, los programadores tendrán acceso al mismo servicio compartido, donde irán anotando el progreso de las tareas que les son asignadas, e irán actualizando el repositorio (o almacén compartido) con el código de la aplicación, que podrá ser analizado en base a la relación programador cambio (o actualización). Reuniones periódicas. de programación. Donde se aclararán las dudas que tengan los integrantes del grupo 4.2.7 Plan de pruebas del sistema Pruebas de Integración o del sistema general. Realización de pruebas por parte del equipo técnico para tratar de evaluar el alcance de los posibles errores y poder solucionarlos antes de la entrega de la aplicación. 4.2.8 Plan de implantación del sistema Instalación de la plataforma técnica. Se llevará a cabo la instalación de los componentes hardware y software del sistema, que constituirán parte de la plataforma técnica en la que se ejecutará el servidor. Instalación, configuración y verificación del fun- Implantación de la aplicación general. cionamiento de la aplicación. 9
4 Descripción de la realización 4.2.9 Manuales de usuario Redacción de un manual, que explique de forma clara y precisa cada una de las funciones que tendrá la aplicación, de tal forma que el usuario no precise ayuda de nadie más para realizar sus servicios. 4.2.10 Manuales de operador Redacción de un manual, para facilitarle la administración de la aplicación, de manera que el administrador sea capaz de llevar a cabo el control del programa sin la ayuda de agentes externos. 4.2.11 Plan de mantenimiento Se realizará una documentación precisa para posibles futuros mantenimientos del sistema. 4.3 Hojas de tareas El proyecto se compone de las siguientes tareas, ya descritas anteriormente: 4.1, 4.2, 4.3, 4.4 y 4.5. 10
4.3 Hojas de tareas Nombre: Elaboración de documentos Fecha: 24 de Octubre de 2006 HOJA DE TAREAS Identificación de Tarea: 1 Duración 5 días Esfuerzo: Descripción Documentación de los objetivos del proyecto. 5 Tareas previas: ninguna Criterios de terminación: Recursos: Finalización del documento de objetivos. Alvaro Uría Nivel de conocimientos y notas: Documentación del proyecto, versiones anteriores Dirección de proyectos Tabla 4.1: Tarea 1: Elaboración de documentos Nombre: Análisis de los requisitos Fecha: 20 de Noviembre de 2006 Identificación de Tarea: 2 HOJA DE TAREAS Descripción Documentación de los requisitos del sistema y establecimiento de los límites iniciales del mismo. Criterios de terminación: Finalización del documento de requisitos Nivel de conocimientos y notas: Análisis de requisitos y dirección de proyectos Duración 15 días Esfuerzo: 5 Tareas previas: ninguna Recursos: Alvaro Uría Documento de objetivos Tabla 4.2: Tarea 2: Análisis de requisitos 11
4 Descripción de la realización Nombre: Diseño Fecha: 18 de Diciembre de 2006 Identificación de Tarea: 3 HOJA DE TAREAS Descripción Diseño de la arquitectura software y hardware Duración 14 días Esfuerzo: 6.5 Tareas previas: Ánalisis de requisitos Criterios de terminación: Recursos: Finalización del diseño de la aplicación Alvaro Uría Diseño detallado del núcleo del sistema Documento de objetivos, prototipos, documento de requisitos Nivel de conocimientos y notas: Diseño de software. Tecnologías web. Tabla 4.3: Tarea 3: Diseño del proyecto Nombre: Implementación del sistema final Fecha: 14 de Febrero de 2007 Identificación de Tarea: 4 HOJA DE TAREAS Descripción Definición de los requisitos finales del sistema, congelación de las especificaciones del sistema y despliegue y testeo del sistema final Criterios de terminación: Finalización del prototipo final. Documentación actualizada. Nivel de conocimientos y notas: Desarrollo de software. Conocimientos detallados de tecnologías web. Duración 20 días Esfuerzo: 4 Tareas previas: Incremento de desarrollo del proyecto Evaluación del prototipo Recursos: Alvaro Uría Prototipo Tabla 4.4: Tarea 4: Implementación del sistema final 12
4.3 Hojas de tareas Nombre: Implantación de la aplicación Fecha: 19 de Marzo de 2007 Identificación de Tarea: 5 Descripción Preparar el sistema final entregable HOJA DE TAREAS Criterios de terminación: Comprobación del sistema final y documentación. Nivel de conocimientos y notas: Administración de sistemas (Servidor Web, Servidor de correo) Duración 1 día Esfuerzo: 4 Tareas previas: Implementación del sistema final Recursos: Alvaro Uría Documento de objetivos, Documento de requisitos, diseño del proyecto, prototipo final Tabla 4.5: Tarea 5: Implantación de la aplicación 13
5 Organización, Equipo CAPÍTULO 5 Organización, Equipo 5.1 Esquema organizativo Por tratarse de un proyecto académico, el responsable final de cada decisión tomada a lo largo del proyecto será Alvaro Uría Avellanal. Sin embargo, en cada una de las decisiones serán partícipes el director del proyecto, Pablo Garaizar Sagarminaga, así como la comunidad de desarrolladores del gestor de listas GNU Mailman. Se harán reuniones quincenales con el director de proyecto para evaluar su situación y fijar hitos y metas. 15
6 Condiciones de ejecución CAPÍTULO 6 Condiciones de ejecución 6.1 Entorno de trabajo 6.1.1 Lugar de trabajo El lugar de trabajo será un despacho en casa del responsable. 6.1.2 Calendario El proyecto tendrá una duración de 5 meses: desde noviembre de 2006 a marzo de 2007. 6.1.3 Horario El horario definido para el avance del proyecto será: Lunes a viernes 19:30 22:30 Sábados 11:30 14:30 17:00 18:30 6.1.4 Medios logísticos y materiales Para este proyecto se va a contar con dos ordenadores que se utilizarán para el trabajo cotidiano, y se dispondrá de dos servicios compartidos como control del desarrollo del proyecto. 6.2 Gestión de cambios, modificaciones e incidencias Por seguir un modelo de desarrollo de software ágil llamado Programación extrema[7], es posible encontrar fallos de diseño más rápidamente y corregirlos sin una gran dificultad. Los cambios realizados en el proyecto que tengan un origen interior, deberán ser evaluados y cuantificado su alcance estructural por parte del director de proyecto. Una vez 17
6 Condiciones de ejecución aprobado o rechazado, se generará un documento para mantener informado del rumbo del proyecto a todo el equipo. Las solicitudes externas realizadas a petición del cliente para cumplimiento de una nueva necesidad no incluída en los requerimientos iniciales del proyecto deben regularse de la siguiente manera: 1. El cliente notifica el cambio detalladamente al administrador de usuarios. 2. El director de proyecto evalua junto al equipo de desarrolladores la viabilidad del cambio, indicando la repercusión estructural y los costes que generarán los cambios introducidos. 3. Redacción de una propuesta para el cliente, resaltando los costes económicos y de tiempos. 4. El cliente notifica la aprobación o rechazo de la propuesta. 5. De ser aprobada, se modifica el plan de trabajo inicial y el presupuesto según lo acordado. 6. Por último, se elabora un documento escrito donde quede reflejado el cambio, la repercusión, las áreas y las tareas afectadas, así como las personas implicadas. Dicho documento se distribuirá al resto del equipo. 18
7 CAPÍTULO 7 7.1 Estimaciones de cargas de trabajo 1.1 Elaboración documentos 2006-10-24-2006-10-30; asignado a Alvaro Uría 1.2 Documentación 2006-10-31-2006-11-17; asignado a Alvaro Uría Estudio de documentación 2.1 Análisis 2006-11-20-2006-12-15; asignado a Alvaro Uría Análisis de la aplicación 2.2 Diseño prototipo 2006-12-18-2006-12-21; asignado a Alvaro Uría Diseño preliminar 2.3 Diseño 2007-01-09-2007-02-13; asignado a Alvaro Uría Diseño detallado 3.1 Implementación 2007-02-14-2007-03-13; asignado a Alvaro Uría Implementación 4.1 Pruebas 2007-03-14-2007-03-16; asignado a Alvaro Uría Pruebas de la aplicación 19
7 5.1 Implantación 2007-03-19-2007-03-19; asignado a Alvaro Uría Implantación de la aplicación 7.1.1 Revisión de hitos 1 Fase Documentación 2006-11-17 2 Fase Diseño 2007-02-13 3 Fase Implementación 2007-03-13 4 Fase Pruebas 2007-03-16 5 Fase Implantación 2007-03-19 7.2 Reparto de las cargas por perfiles 7.2.1 Alvaro Uría Comienzo Fin Días Tarea 2006-10-24 2006-10-30 5 1.1 Elaboración documentos 2006-10-31 2006-11-17 13 1.2 Documentación 2006-11-20 2006-12-15 15 2.1 Análisis 2006-12-18 2006-12-21 4 2.2 Diseño prototipo 2007-01-09 2007-02-13 10 2.3 Diseño 2007-02-14 2007-03-13 20 3.1 Implementación 2007-03-14 2007-03-16 3 4.1 Pruebas 2007-03-19 2007-03-19 1 5.1 Implantación Total: 71 días planificados. Tabla 7.1: Carga de trabajo de Alvaro Uría Dependencias (2006-10-31 2006-11-17) Documentación (2006-10-24 2006-10-30) Elaboración documentos (2006-11-20 2006-12-15) Análisis (2006-10-31 2006-11-17) Documentación (2006-12-18 2006-12-21) Diseño prototipo (2006-11-20 2006-12-15) Análisis (2007-01-09 2007-02-13) Diseño 20
7.3 Plan de trabajo (2006-12-18 2006-12-21) Diseño prototipo (2007-02-14 2007-03-13) Implementación (2007-01-09 2007-02-13) Diseño (2007-03-14 2007-03-16) Pruebas (2007-02-14 2007-03-13) Implementación (2007-03-19 2007-03-19) Implantación (2007-03-14 2007-03-16) Pruebas Vacaciones Comienzo Fin Días 2006-11-01 2006-11-01 1 2006-12-06 2006-12-12 5 2006-12-22 2007-01-08 12 2007-01-22 2007-02-12 16 Tabla 7.2: Vacaciones de Alvaro Uría 7.2.2 temporal La figura 7.1 muestra la planificación temporal del proyecto. 7.3 Plan de trabajo 7.3.1 Documentación La figura 7.2 muestra el plan de trabajo para la fase de documentación. 7.3.2 Análisis y Diseño La figura 7.3 muestra el plan de trabajo para la fase de análisis y diseño del proyecto. 7.3.3 Implementación La figura 7.4 muestra el plan de trabajo para la fase de implementación del sistema. 7.3.4 Pruebas La figura 7.5 muestra el plan de trabajo para la fase de pruebas. 7.3.5 Implantación La figura 7.6 muesra el plan de trabajo para la fase de implantación del sistema desarrollado. 21
7 22 Figura 7.1: Reparto de cargas de trabajo
7.3 Plan de trabajo Figura 7.2: Diagrama de Gantt de la fase de documentación Figura 7.3: Diagrama de Gantt de la fase de análisis y diseño Figura 7.4: Diagrama de Gantt de la fase de implementación Figura 7.5: Diagrama de Gantt de la fase de pruebas Figura 7.6: Diagrama de Gantt de la fase de implantación 23
7 7.3.6 Conjunto de fases El conjunto de fases mostradas en los apartados anteriores pueden verse, de una manera global, en la figura 7.7. 24
7.3 Plan de trabajo Figura 7.7: Diagrama de Gantt general 25
8 Presupuesto CAPÍTULO 8 Presupuesto Presupuesto económico tanto de los medios logísticos y materiales como de las cargas de trabajo. PERFIL CARGA (en meses) PRECIO (e/mes) IMPORTE (e) Responsable total 5 580 2.900 Director de Proyecto 10 300 Mantenimiento 10 90 Material informático 5 2.400 Total 5.690 La forma de pago será mediante transferencia a 30 días de la fecha de factura. 27
Acrónimos Acrónimos GNU GPL HTML WWW GNU is Not Unix GNU General Public License Hypertext Markup Language World Wide Web 29
Bibliografía (Libros y artículos) Bibliografía (Libros y artículos) [1] Barredo A. y Castillo C. Gestión y planificación de proyectos. Publicaciones UD, 2006. [2] Friedl J. Mastering Regular Expressions. O Reilly & Associates, Inc., 1997. [3] Lutz M. Programming Python (2nd Edition). O Reilly & Associates, Inc., 2001. [4] Lutz M. Python: Pocket Reference. O Reilly & Associates, Inc., 2002. [5] Viega J., Warsaw B. y Manheimer K. Mailman: The GNU Mailing List Manager. 12th Systems Administration Conference (LISA 98), 1998. http://www.usenix.org/ publications/library/proceedings/lisa98/viega.html (2006). [6] Marín A. y Márquez G. NetInvent. Master s thesis, Universidad de Deusto (Ingeniería en Informática), Septiembre 2003. 31
Bibliografía (Otras fuentes documentales) Bibliografía (Otras fuentes documentales) [7] Extreme Programming [online]. URL: http://www.extremeprogramming.org/. [8] GNU General Public License [online]. 1991. URL: http://www.fsf.org/copyleft/ gpl.html. [9] Mailman Documentation [online]. URL: http://list.org/docs.html. [10] Cheetah: The Python-Powered Template Engine [online]. URL: http://www. cheetahtemplate.org/. 33
Índice alfabético Índice alfabético correo electrónico, 1 dirección, 1 lista de correo, 1 suscripción, 1 lista de correo, 5 roles de usuario, 5 mensajes, 1 hardware, 9 Internet, 1 Web, 1, 5 prototipos, 7 repositorio, 9 servidor, 9 software, 9 software libre comunidad, 6, 15 35