ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA INFORMÁTICA INGENIERÍA TÉCNICA EN INFORMÁTICA DE GESTIÓN SWEETTER 3.0: MEJORANDO LA COMUNICACIÓN

Transcripción

1 ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA INFORMÁTICA INGENIERÍA TÉCNICA EN INFORMÁTICA DE GESTIÓN SWEETTER 3.0: MEJORANDO LA COMUNICACIÓN EN GRUPOS DE INVESTIGACIÓN Realizado por Luis Manuel García Conde Christian López Espínola Dirigido por José Ra Portillo Fernández Departamento Matemática Aplicada I Sevilla, Septiembre 2009

2

3 A mis padres y hermanos. Porque todo llega al que sabe esperar. Luis Manuel García Conde. A mi familia y a aquellos que miran al cielo y no ven dónde está el límite. Christian López Espínola

4

5 Índice Índice... 5 Motivación y objetivos... 7 Introducción Análisis de antecedentes y aportación realizada Historia de Sweetter Estudio de mercado Metodología de trabajo Recursos tecnológicos utilizados Análisis temporal y de costes de desarrollo Análisis de Requisitos Diseño e Implementación Arquitectura Puntos de extensión Pruebas Guía de usuario Guía para administradores Guía para desarrolladores de extensiones Contribuciones Trabajo futuro Conclusiones Bibliografía... 56

6

7 Motivación y objetivos MOTIVACIÓN En la actualidad, cada vez las organizaciones se vuelven más complejas, y por tanto las comunicaciones en éstas se vuelven más difíciles. Existe una clara necesidad de mejorar y agilizar los procesos de comunicación internos en los distintos grupos de trabajo, tanto comunicación horizontal, a compañeros y colaboradores, como vertical, a superiores y subalternos. Esta complejidad se acentúa especialmente en grupos de investigación, dada la dispersión geográfica, cultural y horaria de los miembros. Pero un excesivo volumen de información puede causar descontrol o requerir demasiado tiempo para realmente ser efectivo. En primer lugar el correo electrónico, y después los foros, intentaron paliar este problema. El correo electrónico tiene el problema de que fácilmente nos desborda debido a que en su diseño no se tuvo en cuenta la clasificación de la información. Los clientes de correo se enfrentan a este problema, pero esto hace que cada clasificación se realice de una manera personal. El problema de la superfluidad en los mensajes se mantiene. En cuanto a los foros, sí se encargan de la clasificación de la información, pero es una clasificación demasiado jerárquica, donde unas entradas tienen más relevancia que otras en función de su temporalidad, no su importancia. Además sigue sin abordar el problema de la extensión de los mensajes. En este contexto aparece el microblogging, mensajería asíncrona y mediante paquetes de un tamaño limitado (aproximadamente un SMS), obligando a los usuarios a ser muy concisos, reduciendo el tiempo de atención necesario para estar al tanto de aquello que nos interesa.

8 La diversidad de roles dentro del personal de una organización provoca que la relevancia de la información no sea definida, sino que variará según el rol de cada individuo. Por ello se requiere un modelo de suscripciones que permita al usuario decidir qué información le resulta interesante, ya sea por el tema tratado o por el emisor de la información. La dispersidad geográfica de los miembros y la utilización de distintas herramientas por parte de éstos hace necesario que esta información deba ser ubicua, y sea accesible desde distintas herramientas y dispositivos. Como se verá en el apartado Análisis de antecedentes y aportación realizada :: Estudio de mercado, existen herramientas cuya intención es facilitar la comunicación interna a través del microblogging en organizaciones, pero ninguna de éstas es libre. Y aquellas que son libres carecen de ciertas características que permitan su uso en organizaciones, tal como veremos en Análisis de antecedentes y aportación realizada. Para abordar este problema, Sweetter pretende proporcionar un mecanismo sencillo a través del cual comunicar ideas de una manera rápida y simple. Su interfaz web nos permite dotar a los usuarios de un entorno familiar, y proporcionar APIs nos permite que la comunidad desarrolle distintas herramientas cliente para todo tipo de entornos, tales como los distintos escritorios o dispositivos móviles, facilitando que cada usuario tenga libertad de elección para comunicarse de la manera que le resulte más cómoda y efectiva, a la vez que facilitando la ubicuidad de los datos, proporcionando una mayor independencia de la plataforma elegida. Según Dion Hinchcliffe, gurú de la innovación empresarial, "si desea utilizar la herramienta correcta para su trabajo, es probable que necesite una plataforma de microblogging especializada". Sweetter3 pretende ser esa plataforma, a través de una arquitectura simple pero fácilmente extensible.

9 OBJETIVOS Cómo veremos en el apartado Análisis de antecedentes :: Aportaciones de Sweetter3, Sweetter 3 no es un proyecto nuevo, sino que parte de un proyecto que ya tiene más de dos años de vida. No obstante, el desarrollo actual, principalmente realizado por Daniel García Moreno (danigm) y Christian López (uno de los autores de este proyecto), no tuvo en cuenta las posibles necesidades futuras de un proyecto de este calibre, tales como la necesidad de grupos que compartan intereses o una mejor categorización y búsqueda de la información. La arquitectura existente no permite la extensión de Sweetter para cubrir otras necesidades, y la escasa modularidad del código fuente dificulta la inclusión de nuevas funcionalidades o la introducción de nuevos desarrolladores. Es por ello que no sólo debemos contemplar nuestros objetivos personales en la realización de nuestro Proyecto, sino que debemos tener en cuenta los objetivos mismos del software y de la comunidad que ya hay alrededor de éste. A continuación vamos a listar los objetivos del software, y por último nuestros objetivos personales con la realización de éste. Objetivos para Sweetter Dotar a Sweetter de nuevas características durante la realización del Proyecto Fin de Carrera, y proporcionar la infraestructura para que puedan desarrollarse nuevas funcionalidades en el futuro. Estas nuevas características están orientadas a la utilización del microblogging de manera interna en diversas organizaciones, tales como grupos de investigación. Expandir la comunidad de usuarios de sweetter.net. Sweetter, además de distribuirse bajo una licencia de software libre, provee el servicio de manera gratuita en la URL sweetter.net. No obstante, dada la dificultad existente para proporcionar nuevas opciones y funcionalidades, el servicio ofrecido no se ha modificado durante el

10 último año, haciendo que el interés de los usuarios del sistema disminuya paulatinamente. Expandir la comunidad de desarrolladores de Sweetter. El proyecto ha despertado gran interés en distintos desarrolladores de software, y muchos se han ofrecido a través de las listas de correo del proyecto para aportar nuevas funcionalidades al código existente. No obstante, la curva de aprendizaje de la base de código de Sweetter aumenta el tiempo necesario para que un nuevo desarrollador se familiarice con él, lo que ha producido que muchos de estos potenciales desarrolladores cesen en su empeño de colaborar. Objetivos personales Aplicar los conocimientos que hemos adquirido durante el estudio de nuestra Titulación. Principalmente, nuestro interés se centra en la gestión de proyectos y el desarrollo de software. Complementar nuestra formación a través de la participación en un proyecto de software libre. La participación en un proyecto de software libre provee conocimientos que consideramos que no se contemplan en los planes de estudio actuales de nuestra titulación. Sentimos la necesidad de complementar nuestra formación mediante la creación, participación y liderazgo en una comunidad de software libre. Obtener la titulación de Ingeniero Técnico en Informática de Gestión. Los dos autores de este Proyecto tenemos pendiente exclusivamente esta asignatura, por lo que obtendremos el título una vez este proyecto sea considerado apto por el Tribunal de evaluación correspondiente.

11 Objetivos tecnológicos Aplicar y ampliar nuestros conocimientos en arquitectura de sistemas, proveyendo a Sweetter 3 de una arquitectura escalable y extensible. Aplicar y ampliar nuestros conocimientos en el lenguaje de programación Python. Aplicar y ampliar nuestros conocimientos en frameworks de desarrollo web, añadiendo Django a los que ya conocemos.

12 Introducción En la actualidad, se puede considerar el flujo y almacenamiento de información como un tema fundamental para el buen funcionamiento de un equipo de trabajo, ya sea un grupo de investigación, un equipo de desarrollo o un departamento de una empresa. Poder intercambiar información de una forma rápida y sencilla, así como la posibilidad de revisarla en un futuro, dotan al grupo de una mayor agilidad a la hora de desenvolverse en su labor. Con la popularización de Internet y la agilidad que proporciona para intercambiar documentos, los faxes, las circulares o similares han perdido utilidad en favor del correo electrónico. Pero ahora tenemos otros problemas, al escribir un tendemos a extendernos demasiado, cuando seguramente sería más productivo describir la información en pocas palabras y mantener un contacto más ágil para responder a las posibles dudas que vayan surgiendo. Dicha tendencia a dar excesivos datos, o creer que se comprenderá mejor una explicación extremadamente formal produce que no siempre se afronte la tarea de escribir estos correos con la mejor de las disposiciones, pues nos puede resultar un trabajo tedioso y podemos llegar a ir relegando las solicitudes de nuestros compañeros mientras nos sea posible. Nuestra propuesta para mejorar el flujo de conocimientos entre los miembros de un equipo, sea del tipo que sea, se basa en el microblogging. Éste deriva del auge del fenómeno blog, palpable si se observan los datos de asistencia de eventos como EventoBlog 1, celebrándose anualmente desde 2005, y con más de mil asistentes en su edición de 2008 y con las mil doscientas preinscripciones para la edición de 2009 completadas en apenas siete horas. O de la celebración de otros Congresos como UniCienBlog, organizado por la Universidad de Sevilla en nuestra Escuela en 2006 tratando la influencia de los blogs en 1

13 la educación. En un principio, el uso de blogs para compartir la información nos presenta la ventaja de un aspecto más atractivo, una forma de conseguir la persistencia de las ideas expuestas, así como de difundirlas entre los integrantes del grupo. Pero los blogs tradicionales tienen aún uno de los problemas de los documentos técnicos y del correo electrónico: tenemos espacio teóricamente ilimitado para exponer un tema. Además, el sistema tradicional de publicar un post principal y añadir comentarios posteriores puede hacer tedioso el encontrar la información concreta que buscamos si ésta estaba en un comentario que no conseguimos localizar. El disponer de un gran espacio para explicar una idea puede llevar a extenderse en demasía, enterrando la información relevante que estemos buscando en un futuro. Bajo esos preceptos, nace el microblogging. El microblogging limita el espacio disponible para el usuario, obligando a que los mensajes sean cortos, consiguiendo que se haga un esfuerzo por condensar la información y eliminar cualquier tipo de dato prescindible. Se consigue que el usuario se centre en la información importante, que no pierda tiempo en redactar un informe detallado si puede explicarlo en una frase. Al ser un sistema de mensajes concisos, la sensación en el usuario es de fluidez y sencillez, además de mostrar la información de una manera más amena dada la evasión de la estricta formalidad. En cuanto a la organización de la información, al poder visualizar por separado los mensajes de un usuario y sus respuestas, que todas éstas sean de primer nivel, organizar grupos o incluso subscribirnos a los mensajes de un usuario o grupo concreto nos es más fácil organizar la información o incluso recibir datos que puedan resultarnos de interés sin buscarlos específicamente. Si la década de los 90 se conoce como la Era de la Información, la década actual debe conocerse como la Era de la Información Concisa, Concreta e Instantánea.

14 Análisis de antecedentes y aportación realizada La necesidad de mejorar la comunicación interna y externa de una organización no es algo nuevo. Durante los últimos años, las organizaciones han implantado distintos medios para facilitar el flujo de información y su acceso a los miembros de ésta. En primer lugar, vamos a analizar algunas alternativas de la era pre-microblogging, y después nos centraremos en analizar herramientas de microblogging. ANTECEDENTES AL MICROBLOGGING Listas de correo Una plataforma habitual en las organizaciones es el uso de listas de correo. Las listas de correo suelen abordar una única temática, y por tanto los usuarios interesados en ésta se suscriben a ella. Entre sus inconvenientes podemos ver que la sobrecarga de correos pueden agobiar al usuario, e inundar su bandeja de correo de información que no le resulta útil en ese momento. Además, si usamos el correo corporativo de la organización, esta información estará replicada en cada buzón, produciendo más costes en almacenamiento y copias de seguridad. Las herramientas más populares en este campo son Mailman, o servicios online como Usenet, News o Google Groups. Foros Esta plataforma permite la comunicación en hilos de conversación, y almacena la información en un nodo central, agrupada por temáticas e hilo. Entre sus inconvenientes podemos ver como la información relevante se puede hacer invisible en la jerarquía.

15 Las herramientas más populares en este campo son PHPBB y Xoops, entre otros. Mensajería instantánea Una de las plataformas más utilizadas en las organizaciones son herramientas de mensajería instantánea. Estas herramientas permiten la comunicación de manera inmediata, pero entre sus inconvenientes está el hecho de que son intrusivas, puesto que el usuario receptor de un mensaje ve interrumpido su trabajo, produciendo cambios de contexto que afectan a la productividad. Además, por norma general estos mensajes son persona a persona, de modo que la información intercambiada no es almacenada ni indexada para su posterior utilización por otros miembros de la organización. Las herramientas más populares en este campo son Microsoft Office Communicator, IRC, mensajería Jabber, e/pop entre otros. Wikis Una plataforma en auge actualmente, ya que permite la edición colaborativa de documentos. No obstante, su edición no es simultánea, y está más orientada a generación de documentos que a la gestión de flujos de información o gestión de la conversación. APORTACIONES DEL MICROBLOGGING El microblogging intenta paliar algunos de los inconvenientes de las plataformas anteriores. Respecto a las listas de correo, el microblogging nos permite tener la información de manera centralizada. Además, una de las ventajas de las listas de correo es que el usuario se suscribe a las temáticas que le interese. Mediante las suscripciones a usuarios y/o grupos, nuestra plataforma mantiene esa importante característica.

16 Respecto a los foros, la información en sistemas de microblogging puede o no tener estructura jerárquica, pero siempre es mucho más horizontal. Respecto a la mensajería instantánea, al existir diferentes formas de acceder a la información (web, propia mensajería instantánea, aplicaciones de escritorio...) el usuario decide cuánto de intrusivo quiere que sea el sistema, mientras que en la mensajería instantánea esta opción no está disponible. Habrá usuarios que tengan la necesidad de dar respuesta rápida, pero habrá otros usuarios que prefieran reservar un espacio de tiempo para consultar la información, evitando interrupciones. Respecto a los wikis, el microblogging obliga a ser más conciso, por lo que en aquellas situaciones dónde no se requiera la elaboración de un documento formal siempre será un método de comunicación más efectivo. APORTACIONES DE SWEETTER3 Si bien Sweetter2 apareció como el primer software de microblogging libre, realmente aportaba poco en el campo de microblogging como red social orientada a ocio. Su desarrollo tuvo como motivador fundamental el hecho de que la licencia del código fuera abierta, no ninguna innovación importante en cuanto a funcionalidad. Sin embargo, en los últimos años han aparecido diversas plataformas de microblogging libres, pero ninguna está realmente orientada a organizaciones con un objetivo común. Ese es el objetivo que guía el desarrollo de Sweetter3. Según Dion Hinchcliffe, la introducción del microblogging en el contexto empresarial obliga a que las plataformas deban someterse al mundo de reglas y políticas que invade la empresa. Dion Hinchcliffe agrupa las características que debe tener un sistema de microblogging para una organización en siete áreas:

17 Búsqueda y análisis. El hecho de utilizar el microblogging como una vía de comunicación dentro de una organización hace necesario el poder localizar la información necesaria en un momento dado de una manera rápida, además de poder estudiar cómo se desarrolla esa información o cómo evoluciona, y analizar las colaboraciones y sus características para poder potenciar las relaciones fructíferas y ver la necesidad de creación de nuevas relaciones. En Sweetter3 se pretende desarrollar un plugin de analíticas, basándose en el uso de etiquetas y otros indicadores para relacionar y analizar esta información Identidad / Single Sign-On. En las organizaciones suele existir un sistema de gestión de identidad que permita la gestión de identidad y acceso a recursos de la organización. Sweetter3 permite la integración con sistemas de estas características como LDAP a través de plugins, y permite su extensión para otros gestores de identidad. Soporte para portales web. El sistema debe permitir la integración en portales. Sweetter3, a través de su API, hace que esto sea posible de manera muy sencilla. Almacenamiento de datos e integración con gestores de contenido. Sweetter3 permite localizar la información de manera rápida a través de sus índices de búsqueda y la etiquetación de los contenidos. No obstante la integración con gestores de contenidos no se va a abordar aún. Posibilidad de hosting. Las políticas de muchas organizaciones obligan a ser ellos mismos quienes gestionen sus datos, por lo que el uso de SaaS 2 no es una opción para ellos. El hecho de que Sweetter3 sea libre permite que aquellas organizaciones que lo requieran pueden alojar su propio servicio. No obstante, el proveer Sweetter3 como servicio para organizaciones es un modelo de negocio que actualmente 2 Software as a Service, Software como Servicio

18 estamos estudiando los autores de este proyecto y algunos colaboradores. Acceso y grupos multinivel. La sensibilidad de cierta información hace que se requiera un preciso control de permisos y grupos. Sweetter3 actualmente aborda este problema de manera parcial, con la introducción de grupos y permisos, pero en el futuro se pretende extender este sistema para ofrecer una mayor granularidad y control de los flujos de información. Publicación selectiva multicanal. Bastante ligado al punto anterior, no sólo se requiere el control de quién puede acceder a la información, sino que en algunos casos es de interés la difusión de esta en otras plataformas, ya sea el portal web de la organización, redes sociales externas u otros medios. Mediante la combinación de etiquetas, grupos y permisos, Sweetter3 permite realizar esta integración. Dentro de estas siete áreas, cada organización tendrá unas políticas y reglas que sus miembros deban cumplir. Por tanto, todos estos aspectos deben ser fácilmente configurables.

19 Historia de Sweetter CONCEPCIÓN La idea de Sweetter nació en un viaje del grupo de usuarios de GNU de la Universidad de Sevilla (Sugus) al X Congreso Nacional de Hispalinux en Cáceres en En este viaje se empezó a gestar el código de Sweetter, e incluso se adquirió el dominio Sweetter.net para su implantación. Todo comenzó por los comentarios sobre un gag televisivo de Enjuto Mojamuto en el que se nombraba a Twitter, una plataforma de microblogging que estaba empezando a captar masa social. Al ver que Twitter no se trataba de una herramienta libre, y no existía ninguna en desarrollo, no hizo falta demasiado tiempo para que se empezase a desarrollar una versión propia. Del nombre de la asociación, Sugus, y Twitter se derivó el nombre de Sweetter. DESARROLLO El desarrollo se comenzó en PHP durante los descansos entre las distintas charlas del Congreso, pero debido a la precariedad del código escrito en un par de ratos, se detuvo el proyecto. Meses más tarde se retomó la idea, pero esta vez como excusa para aprender a usar Python y, más concretamente, se optó por utilizar el framework para aplicaciones web TurboGears. Para la gestión del proyecto se decantaron por Launchpad y Bazaar. Tras implantar el sistema, éste se ha ido mejorando y se han ido uniendo colaboradores al equipo inicial, surgidos de entre los mismos usuarios de Sweetter 2.0. La comunidad de usuario de Sweetter empezó a crecer, llegando a aparecer menciones a él en distintos medios, tales como el periódico El Mundo e informativos de televisión. Hoy en día es una comunidad activa, pero su notoriedad está empezando a caer, de ahí el hecho de volver a empezar con otra concepción y con la experiencia de los errores del pasado.

20 EVOLUCIÓN Con el paso del tiempo, el código de Sweetter 2.0 se ha ido volviendo más y más difícil de mantener, por lo que se decidió un cambio de framework. Se estudiaron los siguientes frameworks: Django: Django es el framework más famoso dentro del amplio mundo de los frameworks de desarrollo web en python. Dispone de una gran comunidad, buena documentación y un desarrollo constante. Webpy Web.py es un framework simple pero a la vez sencillo. Es muy fácil de aprender, pero carece de funcionalidad predefinida y por tanto de potencia. Turbogears 2.0 La versión 2.0 del framework utilizado en Sweetter 2.0. Este framework es en realidad la unión de diferentes herramientas python. Es muy configurable. Esta flexibilidad hace que le falte cohesión. De entre estos, se tomó partido por Django.

21 Estudio de mercado Para la captura de requisitos para Sweetter y la evaluación de la competencia, se han elegido distintos proyectos de microblogging y se han evaluado. SOCIALTEXT SIGNALS 3 SocialText Signals es parte de un aplicativo mayor para la gestión del conocimiento, SocialText. El componente de microblogging permite escribir mensajes y leer mensajes de otros usuarios. Proporciona actualizaciones por RSS e incluye una aplicación de escritorio para realizar estas operaciones. No se conocen otras características más avanzadas ya que es un producto comercial que no hemos podido evaluar personalmente, sino atendiendo a la descripción de su web. WORDPRESS P2 4 Wordpress P2 es una plantilla para el popular software de blogs Wordpress que imita a un sitio de microblogging. No limita el tamaño de los mensajes, pero provee toda la funcionalidad y los plugins de Wordpress. Permite etiquetar entradas con tags, actualización automática y comentarios en hilos. Tiene ciertos problemas de usabilidad, como por ejemplo la imposibilidad de editar los tags en la propia vista principal, sino que hay que ir al panel de administración general. Es software libre

22 APACHE ESME 5 Sistema de microblogging en la incubadora de la fundación Apache. Parece que no ha llegado a lanzar un sistema básico aún, y su desarrollo parece estar parado. Es software libre. STATUSNET 6 Anteriormente conocido como Laconica, StatusNet es el sistema libre de microblogging más popular. Posee soporte de grupos y etiquetado de entradas y usuarios, además de pasarelas con otras plataformas y un sistema de federación para comunicarte con otros servidores. Tiene un sistema de plugins, pero tras nuestra evaluación no hemos visto como añadir funcionalidad, sino sólo cómo modificar la interfaz web. Es software libre. CONCLUSIÓN Nuestra ventaja competitiva respecto a estas plataformas debe ser la facilidad de instalación, de adaptación mediante plugins y una mayor usabilidad de la aplicación. La posibilidad cercana y real de tener una gran base de plugins desarrollados por la comunidad nos permitiría convertir Sweetter en la plataforma de microblogging libre para organizaciones más popular

23 Metodología de trabajo Para el desarrollo de Sweetter3, la metodología a utilizar ha sido Scrum. Scrum es una metodología de desarrollo que se basa en la creación de historias de usuario que definen los requisitos del sistema no desde el punto de vista del desarrollo, sino de las interacciones del usuario con la herramienta. Estas historias de usuario se descomponen en las distintas tareas que permiten tener la funcionalidad completa de dicha historia. Estas tareas se incluyen en un repositorio, al que se conoce como Product Backlog. Scrum propone la creación de ciclos de desarrollo iterativos, y durante un periodo de tiempo que se recomienda que dure una o dos semanas y se conoce como Sprint, se desarrollan una o varias historias de usuario, con el objetivo de que al final de un Sprint exista un producto funcional con un subconjunto de las funcionalidades planificadas para el proyecto completo. Por tanto, durante la planificación se ordenan las historias de usuario por prioridad decreciente, se eligen las de la cima de esta pila, y las tareas asociadas a estas historias pasan del Product Backlog al repositorio de tareas del Sprint, conocido como Sprint Backlog. Una vez tenemos definido el Sprint Backlog, se procede a estimar el tiempo requerido para cada una de estas tareas. Se contabiliza el tiempo disponible en el Sprint actual, y se asumen todas aquellas que estén dentro del rango disponible. Para la estimación de las distintas tareas hemos utilizado la técnica conocida como Planning Poker. En esta técnica, todo el equipo se reúne y cada miembro estima por separado cada tarea. Después se hace una puesta en común, donde cada miembro "muestra su carta", se descartan la estimación más alta y la más baja y se realiza la media del resto de

24 puntuaciones. Si la distancia entre la más alta y la más baja es grande, los miembros que hicieron dichas estimaciones exponen los motivos que les ha llevado a hacer estas estimaciones, ya que puede haber ocurrido que algún detalle se haya pasado por alto al resto de los miembros del equipo. En nuestro caso, al ser sólo dos miembros, obviamente no se ha descartado ninguna estimación. El equipo después acuerda un factor de multiplicación, ya que la tarea de estimar es muy compleja. Si se tiene mucha familiaridad con el desarrollo en cuestión o desarrollos similares, este factor será 1 o un valor muy cercano, ya que las estimaciones serán bastante precisas. Si por el contrario es un desarrollo del que se desconocen muchos factores, ya sea tecnológico o de los requisitos, este valor crece. Durante el desarrollo del Sprint, de manera diaria se realiza un Stand Up, una reunión de todos los miembros en la que cada uno expone qué ha hecho durante la sesión anterior, qué va a hacer durante la próxima sesión, y que problemas ha encontrado o espera encontrarse. Esta reunión debe ser breve, por lo que se recomienda que se realice con todos los miembros de pie, de ahí su nombre. En nuestro caso, esta reunión se ha realizado por Skype, por los motivos que pueden verse en la sección Recursos tecnológicos utilizados. Una vez terminado un Sprint, todo el equipo se reúne y se realiza una demostración del producto. Dado que las historias de usuario del Sprint completan un subconjunto de la funcionalidad, al finalizar cada Sprint esto es posible. De este modo, todos los miembros del equipo conocen con exactitud el estado del proyecto, y si están cumpliendo los objetivos marcados. Después de esta demostración, se realiza una Retrospectiva en la cual se analiza cómo ha funcionado el Sprint, con motivo de intentar no repetir los errores del pasado, y corregirlos a tiempo. Una vez se ha analizado el Sprint, se procede a fijar el factor de multiplicación del Planning Poker teniendo en cuenta cómo ha funcionado el valor actual.

25 Recursos tecnológicos utilizados Para la elaboración de este Proyecto Fin de Carrera se han utilizado tecnologías de gestión y comunicación poco usuales en el desarrollo de un proyecto de estas características. Especialmente interesante es el apartado de documentación y colaboración. La escritura de esta Memoria se ha redactado utilizando un wiki 7, de carácter público, que modo que cualquiera pueda ver en cualquier momento el estado del proyecto. Este hecho ha permitido una continua evaluación por parte del tutor, y tener una página para cada capítulo permite que los autores hayamos podido editar simultáneamente el contenido de la memoria. La herramienta utilizada ha sido Trac, una herramienta simple de gestión de proyectos que además posibilita la creación de páginas wiki. Para la coordinación entre los autores y con el propio tutor, se han usado herramientas de mensajería instantánea como GTalk/Jabber, Windows Live Messenger, y el propio Sweetter. No obstante, esto no ha sido suficiente. Un wiki nos permite la edición de distintos capítulos (páginas) simultáneamente, pero no nos permite redactar simultáneamente un mismo capítulo (página). La mensajería instantánea nos permite comunicarnos mediante texto, pero la comunicación textual carece de ciertas características que nos proporciona la comunicación verbal. Según el psicólogo Albert Mehrabian, sólo el 7% de la información se atribuye a las palabras, mientras que el 38% se atribuye a la voz (entonación, proyección, resonancia, tono, etc). El 55% restante se atribuye al Lenguaje Corporal (1). 7 Un wiki es una base de datos de páginas que pueden editarse de manera colaborativa usando un navegador web

26 Es por ello que se ha recurrido a sesiones de trabajo con herramientas como Skype y Gobby. Skype es una herramienta de mensajería instantánea que destaca por su gran calidad en llamadas sobre Internet. Esto nos permite acelerar la comunicación en algunos instantes en que es imprescindible, tales como la coordinación de la redacción de un capítulo. Además, en ciertos momentos se ha requerido la edición simultánea de un documento, por lo que se ha utilizado Gobby. Gobby es un editor libre colaborativo de escritorio que permite la edición simultánea de documentos mediante la transmisión de diferencias por internet. Debido a nuestra situación laboral, hemos tenido que desarrollar parte de la memoria del proyecto sin disponer de las herramientas que podíamos tener instaladas en nuestros equipos personales. Así pues, durante los descansos en nuestras oficinas hemos usado Sweetter 2.0 para consultarnos datos o enviarnos información. El uso de estas tecnologías ha permitido a los autores trabajar de manera deslocalizada en la realización de la Memoria del Proyecto.

27 Análisis temporal y de costes de desarrollo DIA TIEMPO TIEMPO TOTAL PARTICIPANTES DESCRIPCION 15-jul 120 min 240 min CLE; LGC Definición índice pfc 16-jul 75 min 150 min CLE; JRP Jabber Meeting: Revision indice y correciones 17-jul 75 min 150 min CLE; LGC Motivación y objetivos: Motivacion 01- ago 17- ago 18- ago 180 min 180 min CLE Motivación y objetivos: Objetivos 120 min 120 min CLE Metodología: Recursos tecnológicos 90 min 180 min CLE;LGC Varios 960 min 1920 min CLE; LGC 24- ago 25- ago 25- ago 25- ago 31- ago 180 min 180 min CLE 90 min 180 min CLE;LGC Reunión Sprint 1 y planificación sprint 2 Estudio de mercado, guías de adiminstrador y de desarrollador Postear un mensaje. Listar mensajes. Usuarios y perfiles Reunión Sprint 2 y planificación sprint min 180 min LGC Registrar un nuevo usuario 60 min 60 min LGC Login básico de usuarios 180 min 180 min CLE 01-sep 120 min 240 min CLE;LGC 01-sep 240 min 240 min CLE 02-sep 100 min 200 min CLE;LGC Introducción Plantilla básica. Tag para formatear un post. Integración gravatar. Reunión Sprint 3 y planificación sprint 4 Evaluación e implementación básica del sistema de plugins. 04-sep 180 min 360 min CLE;LGC Análisis de requisitos 04-sep 120 min 120 min LGC Historia 04-sep 300 min 300 min CLE 04-sep 240 min 480 min CLE ;LGC Antecedentes, Historia, Metodología Sistema de plugin, plugin de perfil/login. Arquitectura.

28 05-sep 180 min 360 min CLE;LGC Reunión Sprint 4 y planificación sprint 5 06-sep 120 min 120 min LGC Guía de usuario 06-sep 240 min 480 min CLE;LGC Diseño y Arquitectura 07-sep 180 min 360 min CLE; LGC Plugin karma. 07-sep 240 min 240 min LGC Plugin following/followers 08-sep 240 min 480 min CLE;LGC Reunión Sprint 5 y planificación sprint 6 08-sep 60 min 60 min CLE Parseo de mensajes 08-sep 120 min 120 min LGC Sistema de votos y karma 08-sep 90 min 90 min CLE Css y estilos visuales 08-sep 120 min 120 min LGC Guia de usuarios 08-sep 120 min 240 min 08-sep 320 min 640 min CLE;LGC CLE;LGC Futuro, aportaciones y conclusiones Reunión Sprint 6 y maquetación de la documentación

29 Análisis de Requisitos REQUISITOS DE INFORMACIÓN El sistema deberá almacenar los usuarios, grupos y sus respectivos mensajes en algún tipo de base de datos. REQUISITOS FUNCIONALES Sistéma básico El sistema deberá poder gestionar usuarios: Se debe proporcionar un interfaz para el registro de usuarios, poder recuperar sus datos, modificarlos y dar de baja a usuarios. El sistema deberá poder gestionar grupos: Se debe suministrar un interfaz para la creación de grupos, la obtención de sus datos, su modificación y baja. También se debe proporcionar un sistema de gestión de pertenencia a grupos, así como posibles roles dentro de estos. El sistema deberá poder gestionar mensajes: Se debe ofrecer una forma de publicar nuevos mensajes, recuperar los mensajes existentes según diversos filtros (fecha, usuario, grupo...), así como modificarlos para corregir datos o borrarlos. El sistema deberá dar soporte a un sistema de plugins: Se debe implementar un sistema de extensión del núcleo principal a base de plugins. El sistema deberá ser configurable: Ya sea mediante un archivo de configuración externo o una tabla en la base de datos, el sistema debe ser configurable para adaptarse a los diversos entornos a los que está dirigido y a sus respectivas

30 circunstancias y necesidades. Se debe poder configurar por ejemplo la activación o desactivación de grupos, el número de mensajes por página, la activación o desactivación de plugins, etc. El sistema dará la opción de almacenar perfiles para usuarios: Estos perfiles se encargarán de almacenar la información menos relevante del usuario. Localización, avatar... El sistema deberá gestionar un método de subscripción o seguimiento a grupos o usuarios por parte de otros grupos o usuarios: Los usuarios podrán tener una lista de otros usuarios o grupos de los que se consideran "seguidores". Esto implica que consideran sus mensajes como relevantes y se mostrarán cuando se busquen los mensajes y respuestas del "seguidor", aunque no sean respuestas directas a mensajes suyos. Sistema de plugins Plugin de parseo de mensajes: Se deben identificar URLs, tags de respuesta a otros usuarios, emoticonos, y demás en el cuerpo de un mensaje. Estos se almacenan como texto plano en el sistema, pero se mostrarán como el elemento HTML correspondiente ya sean enlaces internos o externos o imágenes. Plugin de Karma: Otorga a los usuarios una puntuación basada en el número de mensajes publicados y eliminados, y modificable por posibles votos positivos o negativos por parte de otros usuario. Plugin de integración con sistemas externos: Proporciona a los usuarios formas alternativas de acceso al sistema o de publicación simultánea de mensajes en distintos medios. Se ofrece una API pública para usar el sistema desde el exterior, así

31 como se ofrece el envío de mensajes a otros medios mediante sus APIs respectivas.

32 Diseño e Implementación Para la elaboración del proyecto, tras analizar varios frameworks web en Python, nos decantamos por Django. La causa principal de esta elección es la facilidad que proporciona Django en el desarrollo web, ya mediante su arquitectura MVC permite separar fácilmente la lógica (controlador), el diseño gráfico (la vista) y las entidades (el modelo de datos). Además, incluye gran cantidad de funciones auxiliares para facilitar el desarrollo de funcionalidades comunes en cualquier aplicación web (gestión de usuarios, gestión de permisos, generación de RSS, uso de plantillas...). Django se rige por una arquitectura MVC (Modelo-Vista- Controlador), aunque se distingue en la vista de MVC los datos que se presentan (lo que ellos llaman vista) y la manera de mostrarlo, la plantilla. Por ello, ellos denominan a su arquitectura MTV (Model- Template-View, Modelo-Plantilla-Vista). El controlador en este caso sería el propio framework mismo. Django además distingue el concepto de sitio web, de aplicación Django. Un sitio Django es un conjunto de aplicaciones Django, por lo que proporciona un esquema que permite desarrollar estas aplicaciones de manera independiente, y un sitio Django es la agrupación de aplicaciones y configuración que se publica en un servidor. Por ejemplo, el portal web del Departamento sería un sitio Django, mientras que el sistema de encuestas que utiliza sería una aplicación Django. Obviamente, la arquitectura del framework determina nuestra arquitectura en Sweetter. Sweetter por tanto sigue una arquitectura MVT, e introduce una serie de puntos de extensión para que los plugins puedan añadir funcionalidad al sistema básico. Estos plugins no serán más que aplicaciones Django con unas características especiales que

33 permiten a otra aplicación modificar el aspecto (plantilla), funcionalidad (vistas, páginas) y el modelo (los datos a almacenar) de nuestra aplicación base. Hemos querido mantener la aplicación base de Sweetter lo más simple posible, y proporcionar todo el resto de funcionalidad en base a plugins de Sweetter. De este modo, Sweetter más que una aplicación se convierte en un framework de desarrollo de sitios de microblogging.

34 Arquitectura Uno de los requisitos principales de Sweetter es que debe ser totalmente personalizable. Por tanto, se ha optado por un sistema básico, que sólo gestiona la creación y el listado de mensajes, y la definición de un sistema de puntos de extensión dónde plugins satélite extienden la funcionalidad básica. Podemos verlo más claramente en el siguiente diagrama: Como hemos indicado en la introducción del capítulo, el core de Sweetter se rige por una arquitectura MTV, impuesta por Django.

35 Lo ilustramos con el siguiente diagrama: En esta arquitectura, el controlador decide qué vista requiere el usuario, la vista decide qué información se quiere mostrar y la plantilla la presenta. En nuestro caso además, la vista se encargará de llamar a la lógica de cada plugin, y la plantilla también se encargará de proporcionar los huecos para mostrar la información.

36 Puntos de extensión Los puntos de extensión que se han definido son: Sidebar: La barra lateral mostrará contenido proporcionado por los plugins. Por ejemplo, el cuadro del perfil de usuario o la lista de seguidores se muestran utilizando un plugin que aprovecha este punto de extensión. Tools: Herramientas que se pueden utilizar con una entrada concreta. De este modo se puede pre procesar o pos procesar cualquier dato, añadiendo lógica de aplicación. Por ejemplo, la creación de notificaciones por mensajería instantánea se aprovecharía de este punto de extensión. Parsers: Los parseadores reciben una entrada concreta, y pueden modificarla antes de que sea presentada al usuario. Por ejemplo, un plugin que convierta emoticonos en imágenes, o que modifique los enlaces para poder registrar las visitas de éstos.

37 Pruebas Se han realizado tres tipos de pruebas: pruebas de usuario, pruebas unitarias y pruebas de regresión. Las pruebas de usuario se han realizado de forma manual, utilizando toda la funcionalidad disponible y comprobando su correcto funcionamiento. Pero dado el coste de tiempo necesario para realizar estas pruebas, se ha optado también por la automatización de pruebas unitarias. Las pruebas unitarias permiten testear los componentes de manera independiente, mediante código, de manera que es fácil automatizar su ejecución y comprobar que no se han introducido errores. Para la realización de las pruebas unitarias, Python provee dos modos, cada uno de ellos pensado para una situación concreta. Por un lado, tenemos las pruebas con el módulo unittest. Estas pruebas se definen como en otros lenguajes, mediante la creación de módulos que se encargan de lanzar un conjunto de pruebas sobre la aplicación, comprobando que se ejecutan las instrucciones adecuadas y que los resultados parciales son los que corresponden. Pero por otro lado, tenemos las pruebas con el módulo doctest. Esta es una característica que no se encuentra en otros lenguajes, y permite que la propia documentación del código simule una sesión interactiva de Python, de modo que estas pruebas tienen un doble propósito: documentar el uso de nuestros componentes y asegurar que funcionen del modo adecuado. En cuanto a las pruebas de regresión, éstas nos permiten detectar que no se introduce de nuevo un error del pasado. Cada vez que se encuentra un bug o error, se crea una prueba que reproduzca dicho error. Posteriormente, se arregla el propio error, y el test debe

38 pasar si se ha arreglado correctamente. En el futuro, si volvemos a introducir el mismo problema, lo localizaremos de manera instantánea.

39 Guía de usuario En esta sección explicaremos como llevar a cabo las acciones más habituales para los usuarios de Sweetter 3.0. REGISTRO Antes de poder empezar a publicar mensajes debemos completar el registro como usuario del sistema, para ello pulsamos el enlace "Register" bajo el logo de la web. Después simplemente deberemos elegir un nombre de usuario y un password, y ya estaremos registrados en el sistema. LOGIN Para poder empezar a postear mensajes con nuestro usuario recién creado, sencillamente rellenamos nuestro usuario y clave en el cuadro de login y pulsamos Login. Esto nos marcará como conectados en el sistema, dándonos acceso a la publicación de mensajes, al sistema de votaciones, etc. y permitiéndonos gestionar nuestra pertenencia a grupos o seguir a otros usuarios.

40 PUBLICACIÓN DE MENSAJES Al estar logueado, en la página inicial veremos un formulario donde podremos introducir el texto de nuestro mensaje, con un máximo de caracteres definidos en la configuración de Sweetter 3.0. Debajo del marco de texto, encontramos el boton Post para publicar el mensaje. Si lo que deseamos es responder a un mensaje de otro usuario, de login sweetero por ejemplo, solo deberemos incluir en nuestro mensaje su nick precedido por una arroba (@sweetero en nuestro caso). En el caso de responder a un grupo, usaremos dos arrobas (@@grupo) y también podemos marcar mensajes con hashtags usando la almohadilla (#algoritmia, por ejemplo). Estos hashtags podrán utilizarse en plugins externos para realizar estadísticas sobre el tipo de temas más tratados por los usuarios, o para realizar búsquedas por tags. VOTAR MENSAJES Para dar nuestro voto positivo a un mensaje, pulsaremos el botón que aparece en la esquina superior derecha, y en caso de querer dar un voto negativo, usaremos el botón. Estos votos afectan al sistema de karma, subiendo o bajando la puntuación de un usuario. REVISIÓN DE MENSAJES DE UN USUARIO O GRUPO Para ver los mensajes de un usuario o grupo y las respuestas a estos, podemos o bien pulsar su nombre en cualquiera de sus mensajes, en la imagen de nuestro cuadro de seguidores/ seguidos o acceder a la URL

41 GRUPOS Trataremos aquí todo lo necesario para manejarnos con el sistema básico de grupos. LISTADO DE GRUPOS Antes de unirnos o crear un grupo nuevo, debemos revisar el listado de grupos existentes. A este listado accedemos con el enlace situado bajo nuestra lista de grupos en el cuadro de información de usuario. CREACIÓN DE GRUPOS Pasaremos al formulario de creación de grupos mediante el enlace "Create new group". Ahí, introduciremos el nombre del grupo, subiremos una imagen para representarlo y seleccionaremos los usuarios iniciales. Tras esto pulsaremos aceptar y el grupo estará ya creado.

42 UNIRSE A UN GRUPO Para unirnos a un grupo, podremos o bien ir a su perfil y allí pulsar el enlace "Join". DARSE DE BAJA DE UN GRUPO Para darnos de baja en un grupo, accederemos a su perfil y pulsaremos el enlace "Leave". SEGUIMIENTO Para darnos de alta como seguidores de un usuario o grupo, usaremos el botón que aparece bajo los botones para votar, o el enlace "Follow" que podemos encontrar en su perfil. Para dejar de seguirlo, utilizaremos el enlace "Unfollow" que aparecen tanto en sus mensajes como en su perfil. Los usuarios que nos siguen o a los que seguimos aparecerán al final de nuestra barra lateral de usuario.

43 SISTEMA DE KARMA Uno de los plugins que vienen con Sweetter 3.0 es el que se encarga del sistema de karma. El karma en Sweetter 3.0 es una medida de los relevantes o abundantes que son los mensajes de un usuario. Esto es así por la forma en la que se calcula. Al postear un nuevo mensaje se sube el karma del usuario según se haya configurado. Lo contrario sucede al borrar un mensaje, para evitar que un usuario pueda subir su karma artificialmente creando y borrando un mensaje de forma continua. Los votos (negativos o positivos) recibidos por parte de otros usuarios también influyen, subiendo los positivos y bajando los negativos. Además, todos los días se produce una normalización del karma global, con el fin de poner de mostrar también la actividad reciente del usuario. Con este ajuste, los usuarios inactivos verán recortado su karma al mínimo en no demasiado tiempo, mientras los usuarios más regulares lo mantendrán al mismo nivel fácilmente. También recibimos puntos de karma por obtener nuevos seguidores, mientras que los perdemos si estos se dan de baja. A pesar de que Sweetter 3.0 está pensado para propiciar un flujo rápido y continuo de información y mensajes, no es un chat. Para intentar evitar este comportamiento, se penaliza también en el karma el que se publiquen varios mensajes en un espacio muy corto de tiempo. Podemos ver nuestra puntuación de karma en la barra de usuario o en cada uno de nuestros mensajes.

44 Guía para administradores Una de las cosas que hemos querido simplificar en el desarrollo de Sweetter es su instalación. Hemos pretendido que sea muy sencilla, y de una manera estándar con cualquier otra aplicación Django, para que cualquier administrador que ya se haya enfrentado al despliegue de alguna web desarrollada en Django no tenga más quebraderos de cabeza. Se da por hecho que el administrador tiene instalado en su sistema una máquina GNU/Linux con Apache 2.X y mod_python, PostgreSQL, Python 2.6, Django 1.1, y PIL. Por tanto, suponiendo que la instalación se realiza utilizando Ubuntu, Apache y PostgreSQL, los pasos a seguir son: 1. Incluir sweetter en la ruta donde Python busca sus librerías. Por defecto $PYTHON_HOME/lib/site-packages. 2. Incluir todos los plugins que se vayan a instalar en dicha ruta. 3. Modificar la configuración del sitio web de Apache (/etc/apache2/sites-available/default) para añadir nuestra aplicación: 1. <Location "/"> 2. SetHandler python-program 3. PythonHandler django.core.handlers.modpython 4. SetEnv DJANGO_SETTINGS_MODULE sweetter.settings 5. PythonDebug On 6. </Location> 4. Editar el archivo settings.py de Sweetter.

45 Modificar la variable ADMINS con nuestros datos de correo. Si alguna aplicación provoca un error, automáticamente recibiremos un correo para evitar que el usuario tenga que notificarlo. Modificar los datos de acceso a nuestra base de datos: DATABASE_ENGINE, DATABASE_NAME, DATABASE_USER, DA TABASE_PASSWORD, DATABASE_HOST y DATABASE_PORT. En TEMPLATE_DIRS deberán estas todas las plantillas. Por defecto se proporcionan unas con Sweetter, pero si queremos modificar el estilo deberemos copiarlas y modificarlas, y apuntar a ellas en esta variable. Hay que tener en cuenta que también se deben incluir las plantillas de los plugins. En INSTALLED_APPS añadir Sweetter ('sweetter.ublogging'), y todos sus plugins (por ejemplo, 'sweetter.contrib.groups'). Definir en INSTALLED_PLUGINS todos los componentes que utilizan los puntos de extensión de Sweetter. Por ejemplo, 'sweetter.contrib.groups.groupsplugin.group'. Nótese que actualmente el orden es relevante con respecto al orden en el que se muestran los plugins en la interfaz web, por ejemplo en la barra lateral. 5. Editar el archivo urls.py y añadir el enlace a las URLs de los plugins. Cada plugin definirá en un archivo urls.py las rutas de las vistas que añade al sistema. Por ejemplo, para incluir las URLs del plugin de grupos, usaremos 1. urlpatterns += patterns('', 2. (r'^groups/$', include('sweetter.contrib.groups.urls')), 3. ) 6. En el directorio donde esté Sweetter, ejecutar manage.py syncdb. Esto crea la estructura de la base de datos de Sweetter,

46 incluyendo las tablas que requieran los pluginsinstalados. Si instalamos nuevos plugins en un sistema en producción, debemos recordar volver a sincronizar la base de datos.

47 Guía para desarrolladores de extensiones Para crear un nuevo módulo de Sweetter, debemos crear una nueva aplicación Django. Para ello podemos utilizar el asistente que Django nos proporciona. Nos vamos a la raíz del código de Sweetter y ejecutamos manage.py startapp nombre_de_mi_plugin Esto nos crea la carpeta nombre_de_mi_plugin con la estructura básica de cualquier proyecto Django. Esto nos permite crear páginas, acceder a la base de datos de Sweetter, etcétera. Si además queremos que pueda utilizar los puntos de extensión de Sweetter, debemos crear una clase con dichos puntos de extensión. A continuación vamos a analizar dichos puntos de extensión. Para incluir contenido en la barra lateral, debemos crear una función llamada sidebar, con el siguiente prototipo: def sidebar(self, context) La variable context es un diccionario que, entre otros, contiene la variable user con los datos del usuario conectado, y request, con los datos de la petición. Para saber más sobre a qué podemos acceder, es muy útil la introspección de Python, que queda fuera del alcance de este documento. Aunque como ejemplo, podemos indicar que dir(context.dicts) nos dirá que variables se encuentran dentro del contexto.

48 Esta función debe devolver una cadena que contendrá el HTML que se incrustará en la página. Por lo general, tendrá la siguiente estructura: def sidebar(self, context): if context['user'] and not context['user'].is_authenticated(): return '' else: # obtener los datos que se quieran mostrar return render_to_string('mi_template.html', { # diccionarios de datos que quiero mostrar, y que la plantilla renderizará }, context_instance=context) Para incluir una herramienta en cada entrada, debemos crear una función llamada tools, con el siguiente prototipo: def tools(self, context, post) La variable context es igual que en el caso anterior. La variable post es un objeto de tipo sweetter.ublogging.models.post, que contiene el id de la entrada, el texto (text) de la entrada y la fecha de publicación pub_date. Por lo general, nuestra función creará un elemento accionable en la página, tal como un botón o enlace, que se encargará de llamar a una vista proporcionada por nuestro plugin. Para modificar el texto de las entradas que se visualiza, debemos crear una función llamada parse, con el siguiente prototipo: def parse(self, value) El único parámetro que recibe esta función es value, que contiene el texto en forma de cadena que queremos tratar. Este punto de extensión está pensado exclusivamente para dar formato a los mensajes que se muestran, y salvo escasa excepciones no debería tener ninguna clase de efecto en los datos. En caso de que no queramos realizar ninguna modificación, deberemos tener esta función de la siguiente forma: def parse(self, value) return value

49 Estos son actualmente todos los puntos de extensión disponibles. En función de las necesidades que Sweetter y sus extensiones tengan en el futuro, estamos convencidos de que el número de puntos de extensión aumentará.

50 Contribuciones El hecho de que Sweetter se conciba desde sus inicios como un proyecto de software libre, hace necesario incluir este capítulo independientemente de los agradecimientos. Hay que indicar que la idea base del que partió el desarrollo de Sweetter, y la idea de Sweetter 3.0, es de Daniel García Moreno y Eduardo Robles Elvira, junto a Christian López, uno de los autores de este proyecto. En el desarrollo de Sweetter 3.0 hay que tener en cuenta también la inestimable ayuda de distintas personas que o bien por sus críticas a Sweetter 2.0 o por su contribución directa a Sweetter 3.0 han ayudado a que el proyecto mejore respecto a su desarrollo e idea iniciales. Si bien no hay contribuciones de código de participantes externos, si hay que tener en cuenta estas aportaciones. Daniel García Moreno ha participado junto a Christian López en el diseño del sistema de plugins que se ha implementado en Sweetter 3.0. Alex Lillo ha contribuido con un análisis heurístico de usabilidad de Sweetter 2.0, que se adjunta como anexo de este proyecto. Este análisis nos ha permitido evitar los errores del pasado, a la vez que aprender conceptos que no se tratan en el programa de Ingeniería Técnica en Informática de Gestión. Francisco J. Seva ha participado con ideas, aportación de referencias y revisión de la documentación para desarrolladores que incluye esta memoria. Yonmacklein, conocido autor de las parodias El Señor de los Lerus y otras de la web e-alcala.com, ha participado con imágenes y el cartel publicitario que se adjunta en los anexos.

51 A todos ellos, nuestro agradecimiento. Estas colaboraciones reafirman nuestra idea de que el software libre es una vía de desarrollo productiva, efectiva y donde prima la colaboración.

52 Trabajo futuro El desarrollo de Sweetter 3.0 no ha llegado a su fin. En todo momento, se ha concebido un proyecto de gran escala, y que verá sus beneficios reales a medio plazo con la incorporación de más usuarios y desarrolladores de la comunidad. Nuestro objetivo fundamental tras la presentación de este proyecto es incorporar al equipo de desarrollo a aquellos desarrolladores que han mostrado su interés, ya bien con Sweetter 2.0, o durante la concepción y desarrollo inicial de Sweetter 3.0. Por tanto, nuestra primera labor será la de dar soporte a éstos, a través de la mejora de la documentación y de la atención en listas de correo. Las líneas de trabajo más inminentes son: Ubicuidad e independencia de los datos. Queremos dar total libertad a los usuarios de decidir dónde alojan sus datos. Para ello, queremos integrar Sweetter 3.0 en lo que se ha llamado OpenMicroBlogging 8, una federación y protocolo que permita que unos servidores compartan datos con otros, sea cual sea el software utilizado. Además, como efecto colateral de esta incorporación, todas aquellas herramientas que soporten estos protocolos, incluyendo herramientas para escritorio o dispositivos móviles, permitirían utilizar nuestra plataforma. Esta acción no se ha llevado a cabo durante el desarrollo de este proyecto por la inmadurez en la cual aún se encuentra esta iniciativa, aunque tenemos grandes esperanzas en que saldrá adelante. 8

53 Integración con mensajería instantánea/fring/otros. Para permitir la facilidad de acceso al usuario, queremos poder integrarnos con distintas herramientas, tales como Fring, una herramienta muy popular de mensajería multiplataforma. De hecho, cuando la versión de Sweetter vigente era la 2.0, ya nuestro tutor JoseRa Portillo propuso esta integración como Proyecto Fin de Carrera. Análisis social para Gestión del Conocimiento La idea de introducir esta herramienta en organizaciones hace necesario introducir utilería que permita analizar y extraer información del sistema. Se pretende introducir técnicas de la Minería de Datos para analizar, razonar y explotar los datos del sistema y sus relaciones.

54 Conclusiones Las sensaciones que tenemos en la entrega de este Proyecto Fin de Carrera son muy positivas. Nuestro objetivo principal para Sweetter era vitalizar su desarrollo. Esta nueva versión supone una arquitectura mucho más definida, y un código más organizado y limpio. Varios desarrolladores ya han mostrado su interés por la herramienta, y la arquitectura actual y la mejora de la documentación van a hacer esta curva de aprendizaje mucho más suave. Por otro lado, no sólo queríamos mejorar lo ya existente, sino introducir nuevas funcionalidades. La más visible de estas nuevas funcionalidades es el sistema de grupos, que permite mejorar la comunicación entre usuarios con intereses afines, pero la que más ilusión nos causa es el sistema de extensiones que nos permite poder seguir desarrollando la herramienta y explorando sus posibilidades sin afectar a los sitios ya en producción. En cuanto a sweetter.net, el servicio de microblogging que explotamos, se ha conseguido que en la comunidad se haya despertado un nuevo interés y una gran expectativa por la nueva versión. Varios artistas se han ofrecido para colaborar en el diseño de campañas de captación de usuarios. Sirva de ejemplo el cartel que se encuentra en el anexo. Además se pretende conseguir la adopción de Sweetter en distintas organizaciones, teniendo ya prevista su implantación en grupos de Investigación del Departamento de Matemática Aplicada I de la Universidad de Sevilla. Esperamos poder aumentar la adopción de Sweetter en organizaciones, y que el número de proveedores de servicios de microblogging que utilicen Sweetter aumente.

55 En cuanto a nuestros objetivos personales, hemos aplicado nuestros conocimientos de Ingeniería del Software y Desarrollo Web, en el ámbito de un proyecto de Software Libre. Consideramos que el nivel de conocimiento de la plataforma Django que hemos adquirido es muy alto, ya que para el desarrollo de la arquitectura de extensiones ha sido necesario explorar las entrañas de este framework, logrando cierta familiaridad con su código. El proceso de desarrollo nos ha permitido explorar nuevas metodologías de trabajo, y nuevas herramientas que nos permitan colaborar en el contexto de nuestra vida laboral, ya sea de manera presencial o de manera telemática. Y, en definitiva, consideramos que este Proyecto sirve de prueba de nuestros conocimientos, y esperamos que el Tribunal lo considere de la misma forma, permitiéndonos obtener el título de Ingenieros Técnicos en Informática de Gestión.

56 Bibliografía 1. Regla de Mehrabian. Wikipedia. [En línea] [Citado el: 17 de Agosto de 2009.] e_mehrabian. 2. Hinchcliffe, Dion. Twitter on your intranet: 17 microblogging tools for business. ZDNET.com. [En línea] 1 de Junio de [Citado el: 17 de Agosto de 2009.] 3. Pilgrim, Mark. Dive Into Python. s.l. : 4. Kniberg, Henrik. Scrum and XP from the Trenches. s.l. : Lulu.com Djangoproject.com. Documentación oficial de Django. [En línea]

57 ANEXO I: Estudio de usabilidad: Análisis Heurístico de Sweetter 2.0, por Alex Lillo

58 Análisis Heurístico por Alex Lillo Diseño de la información El titular "Welcome to the Sweetter 2.0 index" es redundante, ya que se identifica que estamos en la home, y que estamos en Sweetter por el logo enorme que hay arriba. No hay una jerarquía visual clara, esto es, los diferentes contenidos no están asociados visualmente entre sí, por lo que en determinadas situaciones cuesta ver cuando empieza y acaba cada uno. Por ejemplo "forgot password" está más cerca de a la explicación de qué es swetter que del botón de registro.

59 Diseño de la información En la portada aparece en la parte inferior Page 0", cuando ya sabemos que estamos en la home. No sería necesario indicarlo. Además tiene el mismo formato que el botón para ir a una página anterior, cuando únicamente es texto. No debería utilizarse el mismo recurso gráfico para elementos diferentes (texto plano y botones). Aspecto gráfico Cada uno de los updates muestra un terrón de azúcar. Si bien esto parece ser una metáfora / juego de palabras con Sweetter, esta imagen repetida no aporta valor, pudiendo obtener el mismo resultado mediante una frase o claim.

60 Lenguaje A lo largo de la página se mezclan los idiomas, estando algunas partes en inglés y otras en castellano (index, about, buscar, por ejemplo). Excepto casos concretos en los que la palabra inglesa es la aceptada mayoritariamente, únicamente deberíamos tener un idioma. Control y retroalimentación Existen dos tipos de botones, siendo uno de ellos no muy claro. Sería recomendable que todos los botones sean iguales y se comporten de la misma forma, así el usuario podría verlos con facilidad y no perder tiempo en aprender la interfaz. La flecha de "responder" únicamente aparece cuando pasamos la mano encima de un update, mezclada además con el terrón. Esto puede hacer que pase desapercibida.

61 Ayudas Conceptos como el karma no están casi explicados, y su funcionamiento es confuso para aquel que llega por primera vez a la página. La única ayuda disponible está en "about", lo que parece únicamente información del proyecto. Se echa en falta una página de explicación donde expliquen las peculiaridades del sistema.?