SISTEMA DE MICROBLOGGING PARA LA UJAtauja.ujaen.es/bitstream/10953.1/6706/1/Memoria.pdf · Miguel...

Escu

ela

Polit

écnic

a S

upe

rior

de

Jaén

UNIVERSIDAD DE JAÉN Escuela Politécnica Superior de Jaén

Trabajo Fin de Grado

SISTEMA DE

MICROBLOGGING PARA LA

UJA

Alumno: Miguel Ángel Fernández Carrillo Tutor: Prof. D. Arturo Montejo Ráez Dpto: Informática

Febrero, 2016

Miguel Ángel Fernández Carrillo Sistema de microblogging para la UJA

2 Escuela Politécnica Superior de Jaén

Universidad de Jaén

Escuela Politécnica Superior de Jaén

Departamento de Informática

Dr. D. Arturo Montejo Ráez, tutor del Trabajo Fin de Grado titulado: Sistema de

microblogging para la UJA, que presenta Miguel Ángel Fernández Carrillo, autoriza

su presentación para defensa y evaluación en la Escuela Politécnica Superior de

Jaén.

Jaén, febrero de 2016

El alumno: Los tutores:

D. Miguel Ángel Fernández Carrillo Dr. D. Arturo Montejo Ráez



Índice

1. INTRODUCCIÓN ........................................................................................................... 7

1.1. PROPÓSITO Y MOTIVACIÓN ............................................................................... 8

1.2. OBJETIVOS ........................................................................................................... 9

1.3. METODOLOGÍA DE DESARROLLO ....................................................................10

1.4. SITUACIÓN ACTUAL ...........................................................................................11

1.5. ESTRUCTURA DEL DOCUMENTO .....................................................................12

2. TECNOLOGÍAS EMPLEADAS ......................................................................................15

2.1. FRONTEND ..........................................................................................................15

2.1.1. HTML5 ..............................................................................................................15

2.1.2. CSS3 ................................................................................................................16

2.1.3. JAVASCRIPT ....................................................................................................16

2.2. OTRAS HERRAMIENTAS FRONTEND ................................................................17

2.2.1. JQUERY ...........................................................................................................17

2.2.2. AJAX .................................................................................................................17

2.3. FORMATOS PARA INTERCAMBIAR INFORMACIÓN .........................................18

2.3.1. XML ..................................................................................................................18

2.3.2. JSON ................................................................................................................19

2.4. BACKEND ............................................................................................................20

2.4.1. RUBY ................................................................................................................20

2.4.2. RAILS ...............................................................................................................21

2.4.3. NODEJS ...........................................................................................................21

2.5. BASES DE DATOS ...............................................................................................22

2.5.1. MYSQL .............................................................................................................22

2.5.2. POSTGRESQL .................................................................................................22

2.6. OTRAS HERRAMIENTAS ....................................................................................22

2.6.1. GIT ....................................................................................................................22

3. PLANIFICACIÓN ...........................................................................................................23

3.1. ESTIMACIÓN TEMPORAL ...................................................................................23

3.1.1. PLANIFICACIÓN INICIAL .................................................................................25

3.1.1.1. DIAGRAMAS DE GANTT ..............................................................................27

3.1.2. PLANIFICACIÓN FINAL ....................................................................................28



3.1.2.1. DIAGRAMAS DE GANTT ..............................................................................30

3.1.3. COCOMO .........................................................................................................31

3.1.3.1. ESTIMACIÓN MEDIANTE EL MODELO BASICO DE COCOMO ..................31

3.1.3.2. ESTIMACIÓN MEDIANTE EL MODELO INTERMEDIO DE COCOMO .........33

3.2. PRESUPUESTO ...................................................................................................34

3.2.1. COSTES DE PERSONAL .................................................................................34

3.2.2. COSTES DE MATERIAL ...................................................................................35

3.2.3. RESUMEN DE COSTES ...................................................................................36

3.3. REQUISITOS INICIALES (PRODUCT BACKLOG) ...............................................37

4. METODO DE TRABAJO ...............................................................................................39

4.1. SPRINT 1..............................................................................................................43

4.1.1. PLANIFICACIÓN DEL SPRINT .........................................................................43

4.1.2. DISEÑO ............................................................................................................45

4.1.3. IMPLEMENTACIÓN ..........................................................................................52

4.1.4. PRUEBAS .........................................................................................................58

4.2. SPRINT 2..............................................................................................................59


4.2.2. DISEÑO ............................................................................................................61

4.2.3. IMPLEMENTACIÓN ..........................................................................................65

4.2.4. PRUEBAS .........................................................................................................67

4.3. SPRINT 3..............................................................................................................68


4.3.2. DISEÑO ............................................................................................................70

4.3.3. IMPLEMENTACIÓN ..........................................................................................73

4.3.4. PRUEBAS .........................................................................................................74

4.4. SPRINT 4..............................................................................................................75


4.4.2. DISEÑO ............................................................................................................77

4.4.3. IMPLEMENTACIÓN ..........................................................................................82

4.4.4. PRUEBAS .........................................................................................................84

4.5. SPRINT 5..............................................................................................................85


4.5.2. DISEÑO ............................................................................................................87

4.5.3. IMPLEMENTACIÓN ..........................................................................................90

4.5.4. PRUEBAS .........................................................................................................92

5. DESPLIEGE ..................................................................................................................95



5.1. ANÁLISIS DE LOS SISTEMAS PAAS ..................................................................95

6. CONCLUSIONES..........................................................................................................97

6.1. PROPUESTAS PARA EL FUTURO ......................................................................97

7. ANEXO A: MANUAL DE USUARIO ..............................................................................99

7.1. ACCESO A LA APLICACIÓN WEB .......................................................................99

7.2. REGISTRO ......................................................................................................... 100

7.3. PANTALLA PRINCIPAL (HOME) ........................................................................ 100

7.4. MODIFICAR PERFIL .......................................................................................... 101

7.5. ELIMINAR PERFIL ............................................................................................. 102

7.6. CERRAR SESIÓN .............................................................................................. 102

7.7. ESCRIBIR MENSAJES ....................................................................................... 103

7.8. RESPONDER/DIFUNDIR/ELIMINAR MENSAJES .............................................. 103

7.9. SEGUIR A USUARIOS ....................................................................................... 104

7.10. DEJAR DE SEGUIR A USUARIOS ..................................................................... 104

7.11. CREAR GRUPOS ............................................................................................... 105

7.12. MODIFICAR GRUPOS ....................................................................................... 106

7.13. ELIMINAR GRUPOS .......................................................................................... 106

7.14. SUSCRIBIRSE A GRUPOS ................................................................................ 107

7.15. DARSE DE BAJA DE GRUPOS ......................................................................... 107

7.16. GESTIONAR MIEMBROS DE UN GRUPO ......................................................... 108

8. ANEXO B: MANUAL DE INSTALACIÓN ..................................................................... 109

8.1. CONTENIDO DEL CD ........................................................................................ 109

8.2. INSTALACIÓN EN LOCAL ................................................................................. 110

8.3. INSTALACIÓN EN EL PAAS DE HEROKU ........................................................ 111

9. REFERENCIAS Y BIBLIOGRAFÍA .............................................................................. 113



1. INTRODUCCIÓN

El presente documento constituye la memoria de mi trabajo final de grado en la

titulación de Ingeniería Informática, en la cual se presenta el proyecto desarrollado y

donde se expone la motivación para realizar este TFG, los objetivos del mismo, y

detallar las características técnicas para entender el funcionamiento de la aplicación

y como se ha realizado.

Antes de empezar, me gustaría definir el concepto de microblog, si buscamos

su definición en la Wikipedia, nos dice lo siguiente (Gorigori, 2015):

Un sistema microblogging, también conocido como nanoblogging, es un

servicio que permite a sus usuarios enviar y publicar mensajes breves, generalmente

solo de texto.

Esta definición es muy amplia, y abarca a una gran variedad de servicios. Para

algunos, el microblog hace referencia en mayor parte a las redes sociales, pero si

nos centramos en esta definición, puede también referirse a los SMS de los móviles.

Para aclarar un poco más el concepto, vamos a mostrar algunas de las

características más destacables de estos sistemas:

Ágil: Nos permite comunicar información de manera inmediata entre los

usuarios.

Sencillo: Para publicar una nueva entrada tan solo debemos de rellenar

una caja de texto y darle a enviar.

Concreto: Los sistemas microblogging cuentan con una limitación de

caracteres, normalmente entre los 140-160, por lo que nos obliga a decir

todo en par de líneas.

El concepto de microblog se popularizó de la mano de la red social Twitter,

pionero y más popular servidor de microblogging, tras el éxito de Twitter, han surgido

muchos sistemas diferentes de microblog, en los que no solo comparten texto, sino

que están incluyendo imágenes y videos. Por ello, se están asentando las bases

para construir un sistema estándar y abierto.



1.1. PROPÓSITO Y MOTIVACIÓN

El propósito de este proyecto consiste en diseñar y desarrollar un sistema

microblogging para la Universidad de Jaén. Así pues, se desea realizar un microblog

al estilo de la red social Twitter, para que alumnos y profesores puedan comunicarse

de forma inmediata.

La iniciativa para realizar este proyecto surge de Arturo Montejo Ráez, que me

ofreció la posibilidad de realizar este trabajo final de grado. De este modo, los

miembros que conforman este proyecto son los siguientes:

Arturo Montejo Ráez. Tutor del TFG.

Miguel Ángel Fernández Carrillo. Autor del TFG.

Debemos de tener en cuenta que este proyecto será usado por todos los

miembros de la comunidad educativa de la Universidad de Jaén, por lo que uno de

los aspectos más importantes que debemos de cuidar, es el diseño de las interfaces,

para ello debemos de diseñar una interfaz sencilla y usable, para que pueda ser

usada con facilidad por todos los usuarios.

Otra de las metas que nos proponemos a realizar este TFG consiste en realizar

interfaces de usuarios con diseño responsive, esto principalmente a lo que se

refiere, es que la aplicación se deberá de ajustar a todas las pantallas de los

dispositivos en donde se pruebe, así de este modo, la aplicación podrá ser accesible

por un teléfono móvil, tableta u ordenador.

Además, aprovechando la flexibilidad de Ruby on Rails, se pretende realizar

una API REST, para que toda la información que se obtenga durante este proyecto,

pueda ser consumida de manera pública, por otros medios o servicios.

La importancia de este proyecto viene destacada por los últimos años, donde

estamos viendo el avance de las redes sociales, y la aparición de otras muchas

sobre temas más específicos. Si alguien quiere compartir videos lo hacen en

Youtube, si quieren compartir fotografías usan Instagram, o si quieren buscar un

empleo utilizan Linkedin.



1.2. OBJETIVOS

El objetivo principal de este proyecto es proporcionar a la Universidad de Jaén

de un sistema microblog propio, que permita a alumnos y profesores comunicarse de

forma rápida y sencilla.

Para alcanzar la meta principal, se va a definir una serie de objetivos que

debemos de ir completando para completar el proyecto, a continuación, se definen

estos objetivos:

1. El primer objetivo de un sistema microblog, tiene que ser que como mínimo

posea las capacidades para el envío y recepción de notificaciones.

2. Teniendo en cuenta las restricciones del proyecto, otro objetivo debe ser que

las interfaces de usuario se ajusten a las pantallas de los dispositivos, a esto

se le llama diseño responsive.

3. Debemos de considerar que la aplicación será usada por una gran diversidad

de usuarios, por lo que se deberá de diseñar la aplicación para que estos

usuarios puedan utilizar el sistema de forma intuitiva, sin necesidad de

entrenamiento y sin requerir conocimiento alguno sobre otros sistemas.

4. La principal diferencia con otras redes sociales parecidas, consiste en la

posibilidad de difundir información a un grupo de personas, no obstante,

también deberá incluir la difusión a través de la red de contactos.

5. Las agrupaciones en grupos nos permitirán organizar los mensajes en

relación a temas específicos, de asignaturas, titulaciones, centros… para

facilitarle al usuario encontrar dicha información. (Grupos de interés o listas

de usuarios).

Además de estos objetivos principales debemos destacar otro tipo de objetivos

como pueden ser:

6. Se debe de realizar una etapa de formación en las tecnologías y

metodologías que se van a usar en el proyecto.

7. Se deberá de aplicar los fundamentos de interacción persona-ordenador,

junto con los fundamentos de ingeniería del software.



1.3. METODOLOGÍA DE DESARROLLO

En esta sección se describen las fases que se han seguido para la realización

de este proyecto. Antes de iniciar el proyecto, se realizó una fase de formación

sobre algunas de las tecnologías y herramientas que se han usado y que el autor de

este proyecto no conocía de antes.

Al iniciar el proyecto se decidió seguir una metodología ágil de trabajo, la

metodología que se eligió fue SCRUM. Estas metodologías nos permiten desarrollar

el software de una manera iterativa e incremental.

En la primera etapa del proyecto, se realiza una planificación del proyecto,

en donde resulta importante estudiar las fechas en las que se realizará el resto de

tareas y conocer el presupuesto que conlleva realizar el proyecto en el tiempo

estimado. Este estudio nos indicará si es viable realizar el proyecto.

Tras comprobar su viabilidad, debemos de obtener la máxima información

posible sobre lo que se espera que debe de realizar el sistema final. Para ello se

analiza otros sistemas parecidos, se recogen requerimientos y se establecen los

objetivos finales.

Tras analizar y comprender el problema, es importante diseñar el cómo debe

de hacerse, para ello se describe historias de usuarios y se diseña casos de

usos. Durante esta fase es donde se modela una solución a nuestro problema.

La última fase del desarrollo consiste en pasar las soluciones planteadas en el

diseño a código. Esta es la fase de implementación, en la que siguiendo la

metodología ágil se va incrementado las funcionalidades del proyecto. También es

importante realizar una fase de pruebas para comprobar que todos los requisitos

han sido implementados correctamente.

Se puede considerar una fase extra, que abarca todo el proceso, es la fase de

documentación, en la cual, se recopila los documentos necesarios y se documenta

todo el proceso que se ha seguido.



1.4. SITUACIÓN ACTUAL

Si Analizamos los servicios de mensajería con los que cuenta la Universidad de

Jaén, observamos que tienen características muy similares al nuevo servicio que

vamos a implementar.

La Universidad de Jaén empezó a mandar notificaciones a través de los

servicios de correo electrónico y servicios de mensajería de texto a móviles (SMS),

así de este modo, si un profesor/a publicaba las notas, o quería avisar a sus

alumnos que no había clase, mandaba un SMS grupal. Hace unos años, estos

servicios se actualizaron dando paso a las nuevas tecnologías, y en la actualidad

cuenta con servicios de WhatsApp, Telegram y Hangout. (Estos servicios lo puede

configurar los alumnos desde la zona de la Universidad Virtual).

Figura 1.1. Avisos personales de docencia virtual.

Estos servicios, aunque cumplen con su labor de transmitir información,

cuentan con la limitación de que los alumnos solo pueden recibir información, y no

pueden transmitirla.

Para dar una solución a este problema, surge la necesidad de realizar este

proyecto, para crear un servicio con un flujo de información en ambas direcciones,

permitiendo a alumnos y profesores estar comunicados.



1.5. ESTRUCTURA DEL DOCUMENTO

El presente documento está divido en siete capítulos más dos anexos. A

continuación, se ofrece un resumen de cada uno de ellos:

El primer capítulo, pretende introducir al lector en el proyecto. Se muestra las

ideas básicas, motivaciones y los objetivos que se desean alcanzar.

Durante el segundo capítulo, pasamos a mostrar las tecnologías que se han

usado durante la fase de desarrollo, así como también se indica en que partes del

proyecto han sido utilizadas.

En el tercer capítulo, se realiza la planificación del proyecto. Se incluye la

estimación temporal, que establece las fechas en las que se realizarán las tareas, y

además, calcularemos el presupuesto de costes del personal y de material necesario

para realizar el proyecto en las fechas propuestas.

El cuarto capítulo es el más amplio, y en él se describe el método de trabajo

que hemos seguido y donde se explica todas las fases del proceso SCRUM. La

primera fase es la de análisis, donde debemos de definir con precisión las

funcionalidades de nuestra aplicación, para ello se define los requisitos de software.

La siguiente fase consiste en el diseño de la aplicación, que, en definitiva,

consiste en explicar en cómo se debe de realizar las funcionalidades anteriormente

descritas, para ello se utilizan casos de uso e historias de usuarios. También se

realiza el diseño de la base de datos, para organizar la manera en la que vamos a

almacenar nuestra información.

Tras definir el análisis y diseño, es el turno de la fase de implementación, que

debe de adecuarse a las etapas anteriores para cumplir con los objetivos

propuestos.

Después de terminar con la implementación, se definen las pruebas que se

debe de realizar para confirmar que el software desarrollado funciona correctamente

y cumple los objetivos propuestos.



Tras haber terminado con la fase de desarrollo, en el capítulo quinto, se va a

realizar un estudio de las diferentes plataformas de hosting donde publicaremos

nuestra aplicación final.

Para terminar en el capítulo sexto, se exponen las conclusiones que se han

sacado de todo el proceso y se describen algunas propuestas para mejorar la

aplicación en el futuro.

El capítulo séptimo, es el último capítulo y muestra la bibliografía, que incluye

referencias de internet y libros utilizados.



2. TECNOLOGÍAS EMPLEADAS

Este capítulo lo vamos a dedicar a analizar las tecnologías que se han usado

durante este proyecto, y a explicar en qué partes nos han sido de utilidad.

Antes de empezar hablando de las tecnologías vamos a separarlas en dos

grupos, un primer grupo donde se encuentra las tecnologías de la parte cliente, o

también denominada frontend, y otro grupo que recoge las tecnologías de la parte

del servidor, conocida también como backend. Esta separación del sistema es un

tipo de abstracción que ayuda a mantener las diferentes partes del sistema

separadas.

2.1. FRONTEND

De la parte del frontend encontramos todas las tecnologías que interactúan con

el usuario y son las responsables de recoger los datos de entrada que introduce el

usuario, los procesa siguiendo las especificaciones que requiere el backend y se lo

manda al servidor. Dentro del frontend podemos encontrar tecnologías como HTML,

CSS o JavaScript.

2.1.1. HTML5

HTML5 (HyperText Markup Language) es la quinta revisión importante del

lenguaje básico de la World Wide Web, HTML. Esta tecnología es

tan importante que se encuentra en todas las páginas web de

Internet (Jarould, HTML5, 2015).

No debemos de confundir HTML con un lenguaje de

programación, HTML lo que nos permite es poder maquetar o estructurar el

contenido de nuestros sitios web.

Existen múltiples estándares HTML (HTML 4.01, XHTML 1.0, HTML 5, …), por

ello es importante indicar al principio del documento que versión debe utilizar el

navegador, ya que cada una de ellas tienen distintas reglas.

HTML5, trata de una versión de HTML con nuevos elementos, atributos y

comportamientos. Algunos ejemplos de estos elementos son <header>, <footer> o

<section>, que, aunque técnicamente son parecidas a los elementos <div>, las



nuevas etiquetas tienen más carga semántica. Además, contiene un conjunto más

amplio de tecnologías que permite a los sitios Web y a las aplicaciones ser más

diversas y con mayor alcance. Algunos ejemplos son <audio> o <video>.

2.1.2. CSS3

CSS es un lenguaje de hojas de estilos (“Cascading Style Sheets”), fue creado

para controlar el aspecto y presentación de los documentos estructurados escritos

en HTML o XML. Mediante CSS podemos separar los contenidos de su

presentación, por lo que es imprescindible para la creación de páginas web

complejas (Eguiluz, Introducción a CSS, 2015).

En su última revisión con CSS3, pretende ampliar la versión CSS2.1. Trae muchas

de las novedades esperadas, como esquinas redondeadas, sombras, gradientes,

animaciones, cajas flexibles…

CSS3 se complementa con HTML5, de este modo al crear una página web,

primero se utiliza HTML para marcar y estructurar los elementos:

párrafo, título, tablas, lista, etc. Y tras crear los elementos se

utiliza CSS para definir el aspecto de cada elemento: color,

tamaño, etc.

2.1.3. JAVASCRIPT

A diferencia de las otras tecnologías vistas anteriormente, JavaScript si es un

lenguaje de programación, y es utilizado principalmente para la creación de páginas

web dinámicas, es decir aquellas webs, que necesiten incorporar efectos como

aparecer y desaparecer un texto, animaciones, ventanas con mensajes de avisos o

acciones que se activen tras pulsar un botón (Eguiluz, Introducción a JavaScript,

2015).

JavaScript es un lenguaje de programación interpretado,

dialecto del estándar ECMAScript. Se define como orientado a

objetos, basados en prototipos, imperativo, débilmente tipado y

dinámico.



Un error muy común es confundirlo con Java, que, a pesar de tener nombres

parecidos, no mantienen ninguna relación.

2.2. OTRAS HERRAMIENTAS FRONTEND

2.2.1. JQUERY

jQuery no es una tecnología como tal, pero se ha decidido incluir en este

apartado puesto que jQuery es una librería de JavaScript que nos permite simplificar

la manera de interactuar con los documentos HTML, manipular el árbol DOM,

manejar eventos, desarrollar animaciones y agregar interacción con la técnica

AJAX a páginas web (Alvarez, 2012).

jQuery está formado por un conjunto de

funciones y métodos escritos en JavaScript.

Estas funciones la podemos encontrar en un

único fichero, que podemos descargar desde su

sitio web oficial www.jquery.com (jQuery, 2015), y posteriormente podemos incluir

en nuestros proyectos con la etiqueta <script>. jQuery nos ofrece una completa API,

fácil de usar, cuya característica principal es que nos permite cambiar el contenido

de una página web sin necesidad de recargarla, mediante la manipulación del DOM

y peticiones AJAX.

jQuery tiene la gran ventaja de ofrecer soporte para los navegadores antiguos,

anteriormente se tendría que detectar el navegador y adaptarlo para cada uno de

ellos.

2.2.2. AJAX

AJAX, acrónimo de Asynchronus JavaScript And XML, es una técnica de

desarrollo web, empleada para crear aplicaciones

interactivas.

Esta técnica es muy importante, consiste en

que mientras se está ejecutando una aplicación en

el cliente, es decir en el navegador del usuario, se puede realizar una comunicación

asíncrona con el servidor en segundo plano. De este modo nos permite realizar

http://www.jquery.com/



cambios en la página web, sin necesidad de recargarla por completo, es por ello que

mejora la interactividad, velocidad y usabilidad de la web.

Ajax nos permite sustituir las tradicionales peticiones HTTP al servidor por

peticiones JavaScript que se realizan al

elemento encargado de Ajax.

Podemos verlo más claro con la

siguiente ilustración:

Si las peticiones son simples y no

requieren de la intervención del servidor las

respuestas son inmediatas, si por el contrario

se necesita de una respuesta del servidor,

esta se realiza de forma asíncrona mediante

Ajax.

2.3. FORMATOS PARA INTERCAMBIAR INFORMACIÓN

En esta sección se describen los formatos utilizados para intercambiar

información con la API REST.

2.3.1. XML

Al igual que HTML, XML es un lenguaje de marcas desarrollado por el World

Wide Web, que debe su nombre del inglés, eXtensible Markup Languaje. Este

lenguaje define una serie de normas para codificar la información, que hacen que

sea legible para un ser humano y un ordenador (andrearrs, 2014). XML se utiliza

principalmente para transmitir información en servicios web, API REST y para

archivos de configuración. A continuación, se muestra un ejemplo de cómo se

mostraría la información con XML:

<user> <id type="integer">2</id>

<email>[email protected]</email> <username>mafc0004</username>

<name>Miguel Ángel</name> <level type="integer">0</level>

</user>



2.3.2. JSON

Junto con XML, JSON es un formato para el intercambio de datos, y estándar

abierto, pero que a diferencia de XML que, si soportaba Unicode, JSON utiliza texto

plano para codificar la información en la forma de “atributo: valor”. Su nombre

proviene del inglés JavaScript Object Notation, y aunque en sus inicios fuese

considerado una parte de JavaScript, siempre ha sido independiente del lenguaje de

programación.

JSON nació como una alternativa a XML, y su simplicidad ha dado lugar a la

generalización de su uso.

Una de las ventajas de JSON frente a XML como

formato de intercambio de datos, es que es mucho más

sencillo escribir un analizador sintáctico de JSON. En

JavaScript, un texto JSON se puede analizar fácilmente

usando la función eval(), lo cual ha sido fundamental

para que JSON haya sido aceptado por parte de la

comunidad de desarrolladores AJAX.

A continuación, mostramos el mismo ejemplo que pusimos con xml, pero

mostrando ahora en JSON:

[{"id":2,"email":"[email protected]",

"username":"mafc0004","name":"Miguel Ángel",

"level":0}]



2.4. BACKEND

En el backend tenemos las tecnologías del lado del servidor, estas son las

tecnologías encargadas de la lógica de nuestra aplicación, es decir, donde se

localizan las condiciones de control, ciclos, estructuras de datos, etc. En el backend

podemos encontrar más tecnologías que del lado servidor, algunas de ellas son

PHP, .NET, Python, Ruby, etc. Para esta aplicación hemos decidido usar Ruby,

debido a que es un lenguaje enfocado a la simplicidad y a la productividad.

2.4.1. RUBY

Es un lenguaje de programación interpretado, reflexivo y orientado a objetos.

Combina una sintaxis inspirada en Python y Perl, además su implementación oficial

es distribuida como software libre.

A continuación, vamos a definir algunas de las

características más importantes de este lenguaje:

DRY (del inglés, “Don´t Repeat Yourself”): Sugiere que repetir el mismo

código una y otra vez es una mala práctica.

Convención sobre configuración: Ruby hace algunas suposiciones

sobre lo que quieres hacer y como deseas hacerlo, en lugar de solicitar

que especifiques cada cosa a través de ficheros de configuración.

Active Record: Es un ORM (Object-Relational mapping) y como dice su

nombre, nos permiten hacer consultas a la base de datos a través de

objetos. Los ORM nos proporciona muchas ventajas, la principal ventaja

es que nos desligamos de tener que escribir código SQL, y pasamos a

escribir una sintaxis propia del lenguaje que es más amigable. Para ello

se crean modelos de datos en Ruby, y estos modelos al heredar de

Active Record, les proporciona métodos adicionales para la inserción,

modificación, búsqueda y borrado de los datos.



2.4.2. RAILS

Rails es un framework de Ruby para el desarrollo de aplicaciones web. El

motivo de seleccionar este framework frente a otros es que están organizados en

niveles, y en su nivel superior esta Rails, que contiene todas las características de

los frameworks de los niveles inferiores. Además, podemos contar con todas las

características que tiene Ruby. Rails nos permite escribir menos código realizando

más que muchos otros lenguajes y frameworks.

Es un software dogmático, por lo que asume que existe una forma “mejor” de

hacer las cosas, y está diseñado para fomentar esta forma, por lo que si usamos el

“modo rails” incrementaremos la productividad, y sin embargo usamos viejos hábitos

de otros lenguajes, se puede tener una experiencia menos agradable.

Uno de los aspectos más importantes de Rails es la seguridad, nos permite

limitar las páginas o acciones disponibles, determinar permisos sobre los datos y

filtrar el contenido según el usuarios, rol o contexto. Además de ello nos provee

herramientas para la protección de ataques de XSS (Cross-site scripting) y de

inyección SQL.

2.4.3. NODEJS

NodeJS no es un lenguaje de programación como tal, sino que es un entorno

en tiempo de ejecución, sus ventajas son que es multiplataforma y de código abierto.

Esta herramienta es muy útil para el proyecto, ya que nos va a permitir una

comunicación en “tiempo real” con el servidor.

El funcionamiento es muy sencillo, desde la

parte cliente de nuestra aplicación, es decir desde el

navegador vamos a generar nuevos datos, estos

datos lanzarán un evento que guardará los datos en

una base de datos temporal, en el ejemplo se usa

Redis.



Mediante una gestión de colas, se van atendiendo las notificaciones recibidas y

son mandadas a Node/socket.IO, que serán los encargados de actualizar el

navegador de los clientes.

2.5. BASES DE DATOS

Aunque en un principio hemos diferenciado dos grupos, el frontend y el

backend, realmente existe un tercer grupo, y es el que comunica ambos. Este grupo

lo forman las bases de datos, que almacenan toda la información de nuestra

aplicación. Las bases de datos también la podemos encontrar de dos tipos, las

clásicas/relacionales, que nos permiten combinar diferentes tablas para extraer la

información relacionada y el otro tipo son las bases de datos noSQL, que nos

permite distribuir grandes cantidades de información.

2.5.1. MYSQL

Durante la fase de desarrollo, en la maquina local,

se ha instalado MySQL, un sistema de gestión de bases

de datos relacionales, multihilo y multiusuario

2.5.2. POSTGRESQL

Postgresql es un sistema de gestión de bases datos objetos-relacional,

distribuido bajo la licencia BSD y de código libre, considerado como el sistema de

gestión de bases de datos de código abierto más potente del mercado.

Postgresql utiliza un modelo cliente/servidor y usa multiprocesos a diferencia de

MySQL que usaba multihilos, para garantizar la estabilidad del sistema.

Esta base de datos se ha utilizado para la puesta en producción de la

aplicación.

2.6. OTRAS HERRAMIENTAS

2.6.1. GIT

Git es un software de control de versiones, pensando en la eficiencia y

confiabilidad del mantenimiento de versiones de aplicaciones cuando éstas tienen un

gran número de archivos de código fuente.



3. PLANIFICACIÓN

Durante este capítulo se presentará una fase importante en el desarrollo del

proyecto, en ella realizaremos un estudio detallado de las fechas en las que se va a

realizar las tareas, junto con el análisis de los recursos necesarios para poder

completar todas las tareas. Finalmente se realizará el presupuesto final del proyecto

(Martínez, 2014).

3.1. ESTIMACIÓN TEMPORAL

Para realizar una buena estimación debemos de empezar por la planificación

de las tareas y el tiempo que nos va a llevar a realizar dichas tareas, por lo tanto, la

estimación temporal podemos definirla como un conjunto de procesos que nos

aseguran el correcto desarrollo de las tareas, dentro de los plazos que hemos

establecidos, y para ello nos proporcionan herramientas para su control y

seguimiento.

Los principales procesos son:

Identificación de tareas: Lo primero que debemos de hacer al planificar

el proyecto es identificar y documentar las principales tareas que deben

de realizarse para alcanzar los objetivos establecidos.

Estimación de la duración de las tareas: Para cada tarea identificada,

deberemos de realizar una estimación de unidades temporales para

completar su finalización.

Secuenciación de actividades: Después de identificar todas las tareas

y el tiempo estimado en el que se pueden completar, pasamos a la inter-

relación de las tareas.

Establecimiento del calendario: Consiste en definir las fechas de inicio

y fin de cada una de las tareas. Debemos de tener un especial cuidado a

definir fechas realistas, porque podríamos correr el riesgo de no terminar

el proyecto en las fechas establecidas.

Control del calendario: Es una herramienta de control, la cual realiza

un seguimiento de las tareas, y realiza ajustes si es necesario ante

posibles cambios.



El proyecto inicialmente tenía una fecha de inicio para febrero del 2015 y con

una fecha de finalización para junio de 2015, compatibilizándolo de este modo con

las asignaturas del segundo cuatrimestre, por lo que su duración inicial era de cuatro

meses. Pero debido al poco tiempo que podía dedicarle al proyecto, se tomó la

decisión de iniciarlo tras acabar con todas las asignaturas, para así poder dedicarle

una carga horaria mayor al proyecto.

De este modo, tenemos dos estimaciones, una estimación inicial, que se

realizó antes de empezar con el proyecto, y otra estimación tras retomar el

proyecto después del parón (estimación final del proyecto).



3.1.1. PLANIFICACIÓN INICIAL

Siguiendo con los procesos en la estimación, se empieza con la identificación

de las tareas. A continuación, se mostrará las tareas que se han identificado y la

duración estimada para cada tarea:

Figura 3.1. Identificación y secuenciación de las tareas iniciales



En la Figura 3.1, podemos observar que la etapa de la documentación se

extiende a lo largo del proyecto, y que por tanto se realiza en paralelo con el resto de

las tareas, también hay otras que inician en el mismo día, esto es debido a que

algunas tareas se pueden realizan de forma simultánea.

Los motivos por lo que esta planificación falló fueron los siguientes:

No se tiene en cuenta el proceso SCRUM, y se estima siguiendo una

metodología tradicional.

Debido al punto anterior, cada etapa del desarrollo, se realiza después

de acabar con la anterior, y no todas a la vez en pequeños incrementos

como hace SCRUM.

No se tiene ningún prototipo hasta la terminación del proyecto por

completo.

Se han identificado tareas erróneas.

En definitiva, por esta mala planificación, se decidió pausar el proyecto durante

unos meses y retomarlo tras acabar con las asignaturas.

3.1.1.1. DIAGRAMAS DE GANTT

Los diagramas de Gantt son una herramienta utilizada para la planificación y programación de tareas a lo largo de un periodo

de tiempo. Permite realizar el seguimiento y control del progreso de cada una de las etapas del proyecto. A continuación, se

muestra la planificación inicial:

Figura 3.2. Diagrama de Gantt inicial

Como se puede observar en la Figura 3.2. se obtiene una estimación inicial de 4 meses.

3.1.2. PLANIFICACIÓN FINAL

Tras el parón realizado, en septiembre del 2015 volvemos a retomar el

proyecto y a planificarlo de nuevo. En esta planificación se añade nuevas tareas y se

actualizan otras, junto con su duración. También tenemos en cuenta el proceso

scrum y la organización de las tareas en Sprints

A continuación, mostramos como queda las nuevas tareas y su duración

Figura 3.3. Identificación y secuenciación de las tareas finales



Observando la figura 3.3, podemos ver que esta vez sí se ha planificado

teniendo en cuenta la duración de los sprint, por ello tenemos 5 Sprints con una

duración de 20 días que equivale a 4 semanas de 5 días laborables.

Cada Sprint vemos que está compuesto de otras subtareas, que son el

análisis, diseño, implementación, y las pruebas. Estas tareas tienen un orden de

precedencia, y la primera que se debe de hacer es el análisis, ya que contiene todas

las tareas relacionadas con la identificación de los requisitos e historias de usuarios,

la siguiente tarea es el diseño, en donde debemos de modelar la solución para

nuestra aplicación, en esta fase se realizan los casos de uso y sus diagramas.

Tras las anteriores tareas, podemos realizar en paralelo la fase de

implementación y la fase de pruebas, que abarcan tareas como la creación del

Modelo-Vista-Controlador, o como el desarrollo de pruebas de unidad para validar

que el software desarrollado soluciona los problemas planteados en el análisis.

Si comparamos con la planificación inicial, vemos una tarea que se desarrolla a

lo largo de todo el proceso, es la documentación del proyecto con una duración de

112 días.

3.1.2.1. DIAGRAMAS DE GANTT

A continuación, se muestra el diagrama de Gantt final para poder realizar el seguimiento y control del proceso de las tareas

del proyecto.

Figura 3.4. Diagrama de Gantt final

3.1.3. COCOMO

COCOMO (del inglés COnstructive COst MOdel) es un modelo matemático

utilizado para la estimación de costos. Contiene a su vez tres submodelos, en el

que cada uno ofrece un nivel de detalle y aproximación, cada vez mayor a medida

que avanza el proceso de software.

3.1.3.1. ESTIMACIÓN MEDIANTE EL MODELO BASICO DE COCOMO

El modelo básico de COCOMO consiste en una herramienta que nos ayuda

para evaluar de forma inicial el esfuerzo necesario para llevar a cabo el proyecto, se

basa en una estimación del número de miles de líneas de código (KLDC), y se aplica

en base a tres entornos de desarrollo:

Modo de desarrollo A B C

Orgánico 3,2 1,05 0,38

Empotrado 3,0 1,12 0,35

Semi-libre 2,8 1,20 0,32 Tabla 3.1. Modos de desarrollo de COCOMO

Formulas:

Esfuerzo nominal (PM) = A x (KLDC)B

Tiempo de desarrollo (TD) = 2,5 x PM c

Nº personas = Esfuerzo / Tiempo de desarrollo

El modo orgánico se aplica a los entornos sin presiones en el tiempo y donde

los programadores son experimentados. El modelo empotrado, se aplica en

entornos con fuertes restricciones, ya sean relacionadas con la funcionalidad y/o

técnicas. El modo semi-libre es el modo que hemos seleccionado para este

proyecto, puesto que es un modo intermedio entre el orgánico y el empotrado.

Para poder realizar los cálculos necesitamos conocer el número de líneas de

código que tiene nuestro proyecto, para ello hemos usado el software llamado cloc,

en su última versión 1.64, que permite conocer las líneas de código de todos los

ficheros que incluye la aplicación. Así pues, lo único que necesitamos es ejecutar

este programa y pasarle como argumento la ruta del proyecto, los resultados

obtenidos se muestran a continuación.



Figura 3.5. Cálculo del número de líneas de código

Como vemos en la figura 3.5, el número de líneas de código escritas en la

aplicación asciende a un total de cinco mil quinientas sesenta y dos líneas de

código

Por tanto, usando el modelo básico para estimar el esfuerzo necesario para el

desarrollo de un proyecto de 5500 líneas de código en modo semi-libre se tiene lo

siguiente:

PM = 2,8 x 5,51,2 = 21,66 personas

Con un tiempo de desarrollo de:

TD=2,5 * 21,660,32 = 6,69 meses

Conociendo el esfuerzo que es necesario para completar el proyecto, y el

tiempo que se estima para desarrollar el proyecto, podemos estimar las personas

que necesitaremos para cada mes de desarrollo:

Nº Personas = 21,66 / 6,69 = 3,24 personas al mes para realizar el proyecto

en 6,69 meses.



3.1.3.2. ESTIMACIÓN MEDIANTE EL MODELO INTERMEDIO DE COCOMO

Una vez que tengamos los elementos del sistema, podemos estimar el tiempo

con este método, que consiste en aplicar correcciones al esfuerzo obtenido

anteriormente, aplicando factores de ajustes que vienen dados por la siguiente tabla:

Figura 3.6. Factores de ajustes para el modelo intermedio

Los factores que vamos a utilizar son:

Fiabilidad: Alto (1,15)

Tiempo de respuesta: Alto (1,07)

Capacidad de análisis: Alto (0,86)

Experiencia en el lenguaje: Bajo (1,07)

Restricciones de tiempo de desarrollo: Alto (1,04)

PM = 21,66 x 1,15 x 1,07 x 0,86 x 1,07 x 1,04 = 25,51 personas

TD=2,5 * 25,510,32 = 7,0 meses

Nº Personas = 25,51 / 7,00 = 3,64 personas al mes para realizar el proyecto

en 6,23 meses



3.2. PRESUPUESTO

Para poder realizar este proyecto vamos a necesitar recursos humanos y

materiales, estos últimos los vamos diferenciar en recursos software y recursos

hardware. Así mismo, en este apartado se va a realizar los cálculos matemáticos

para la obtención de los costes para realizar las tareas junto con el coste del material

necesario para su elaboración.

3.2.1. COSTES DE PERSONAL

Empezamos por calcular el precio que debemos de pagar al equipo de

desarrollo, para ello, si tenemos en cuenta los resultados obtenidos del esfuerzo

mediante el método de COCOMO intermedio, el cual se estima en 25,51 personas, y

un sueldo medio de 1500€, se obtiene lo siguiente:

Recursos humanos = 25,51 personas x 1500€ = 38.280€

Sin embargo, estos datos no se ajustan a la realidad puesto que todo el

proceso de desarrollo lo va a realizar una única persona, que además asumirá los

roles de analista, programador y jefe de proyecto.

Además, para el cálculo se ha utilizado un sueldo medio, por ello para obtener

cifras más exactas del salario, vamos a consultar el documento “XIII CONVENIO

COLECTIVO DE ÁMBITO ESTATAL PARA LOS CENTROS DE EDUCACIÓN

UNIVERSITARIA E INVESTIGACIÓN”, que realiza el Ministerio de empleo y

seguridad social. De este documento accedemos a las tablas salariales 2015, grupo

III, de personal no docente y extraemos el campo de titulado de grado medio.

Salario para titulado de grado medio = 1.386,53€ x 4 meses = 5.546,12€

Como podemos ver, estos resultados están muy lejos de parecerse a los

estimados mediante el modelo COCOMO, añadir además que el salario establecido,

está basado en jornadas laborales de 8 horas diarias.



3.2.2. COSTES DE MATERIAL

En esta sección se expone el resto de recursos que vamos a necesitar. Estos

recursos se refieren al material informático y herramientas que se han utilizado para

el desarrollo del proyecto.

Concepto

Coste

Periodo de amortización

(Meses)

Uso del producto (Meses)

Coste amortizado

Macbook pro retina 13’’ 1449€ 48 4 120,75€

Iphone 5s 509€ 48 4 42,41€

Ipad mini 2 289€ 48 4 24,08€

Total 187,24€ Tabla 3.2. Materiales utilizados y coste

El macbook pro ha sido el equipo hardware donde se ha implementado la

aplicación, y cómo podemos observar en la tabla 2.3. tiene un coste de 1449€ sin

embargo, la amortización de este equipo tras 4 meses de uso y una vida útil de 4

años, es de 120,75€.

El iphone y el ipad han sido utilizados para probar que el diseño responsive

funciona correctamente, tras amortizarlos durante 4 meses de uso, se obtiene un

coste de 42,41€ para el iphone y 24,08€ para el ipad.

Si realizamos la suma total del costo de hardware es de 187,24€.

Concepto

Coste

Periodo de amortización

(Meses)

Uso del producto (Meses)

Coste amortizado

Sublime Text 70€ 72 4 3,89€

Google Chrome 0€ 72 4 0€

Mozilla Firefox 0€ 72 4 0€

Microsoft Edge 0€ 72 4 0€

Safari 0€ 72 4 0€

Visual Paradigm Community Edition

0€ 72 4 0€

Office 365 Personal 84€ 72 4 4,48€

Total 8,37€ Tabla 3.3. Software utilizado para el desarrollo



Sublime Text ha sido la herramienta software con la que hemos implementado

el código de la aplicación, está valorada en 70€.

Para probar que la aplicación funciona correctamente y se visualiza bien, se ha

probado en los distintos navegadores más populares, entre ellos, Google Chrome,

Mozilla Firefox, Microsoft Edge y Safari. El coste de estos navegadores es de 0€.

Por otro lado, tenemos Visual Paradigm, que es el software utilizado para

realizar los diagramas de Ingeniería de Software, el coste es de 0€ debido a que

estamos usando la licencia que nos ofrece el departamento de informática.

Para finalizar, se ha utilizado el office 365 para realizar la documentación del

proyecto, cuyo coste es de 84€ por una licencia de 1 año, pero que tras amortizarlo

se queda en un total de 28€.

3.2.3. RESUMEN DE COSTES

En este apartado se muestra el coste total del proyecto sumando el coste del

personal y el coste del material:

Concepto Importe

Recursos humanos 5.546,12€

Costes de materiales 195,65€

TOTAL 5.741,77€ Tabla 3.4. Presupuesto final

Tras sumar los costes de personal y materiales, se obtiene un coste final de 5.741,77€



3.3. REQUISITOS INICIALES (PRODUCT BACKLOG)

En la metodología de Scrum se suele hacer dos estimaciones, pero no de la

forma tradicional con estimaciones basadas en horas o días de trabajo.

La primera estimación se hace a grosso modo dando puntos en la que

partiendo de la lista inicial de requisitos a desarrollar estimamos el esfuerzo o la

dificultad que nos supondrá realizar cada uno de los requisitos del proyecto. Este

esfuerzo lo mediremos, en puntos.

Identificador Historias de usuarios Estimación

HU-01 Como usuario invitado, quiero crear una cuenta para poder acceder a la aplicación.

2

HU-02 Como usuario registrado, quiero eliminar mis datos. para darme de baja de la aplicación.

0

HU-03 Como usuario registrado, quiero modificar mis datos del perfil por otros nuevos.

1

HU-04 Como usuario registrado, quiero iniciar sesión para usar la aplicación.

2

HU-05 Como usuario registrado, quiero buscar perfiles de otros usuarios para estar en contacto e informado de sus novedades.

3

HU-06 Como usuario registrado, quiero crear un nuevo mensaje para mostrarlo en la aplicación.

2

HU-07 Como lector, quiero ver una lista de los mensajes del timeline ordenados por su fecha de creación para poder leerlo de forma más ordenada.

3

HU-08 Como autor de un mensaje, quiero borrar mis mensajes para que no se muestren en la aplicación.

0

HU-09 Como usuario registrado, quiero difundir los mensajes de otros usuarios para que más usuarios puedan leerlo.

2

HU-10 Como usuario registrado, quiero responder a mensajes de otros usuarios.

2

HU-11 Como usuario registrado, quiero seguir a otros usuarios para estar en contacto.

2



HU-12 Como seguidor, quiero ver los mensajes de los usuarios a los que sigo en el timeline.

3

HU-13 Como usuario registrado, quiero ver un resumen de las estadísticas de los usuarios.

1

HU-14 Como usuario, quiero ver los usuarios que siguen a otro usuario.

1

HU-15 Como usuario, quiero ver los usuarios que sigue otro usuario

1

HU-16 Como usuario registrado, quiero dejar de seguir a un usuario para dejar de recibir sus mensajes.

0

HU-17 Como usuario registrado, quiero crear un nuevo grupo para poder organizar los mensajes de una misma temática.

2

HU-18 Como propietario de un grupo, quiero modificar el grupo para cambiarle las propiedades.

1

HU-19 Como propietario de un grupo, quiero eliminar un grupo.

0

HU-20 Como usuario registrado, quiero buscar grupos por su nombre o etiqueta.

3

HU-21 Como usuario registrado, quiero ver un listado donde se muestren todos los grupos.

1

HU-22 Como propietario de un grupo, quiero añadir miembros.

2

HU-23 Como propietario de un grupo, quiero eliminar miembros.

0

HU-24 Como usuario registrado, quiero subscribirme a un grupo.

2

HU-25 Como miembro de un grupo, quiero cancelar la subscripción para dejar de recibir novedades de este grupo.

0

TOTAL 36

Tabla 3.5. Historias de usuarios seleccionadas para el sprint 1.

Obtenemos un total de 36 puntos de historia, y considerando una velocidad

estimada de 7 puntos, nos da un total de 5 iteraciones (36/7 = 5,1), aunque

podemos considerar 6 iteraciones con un margen para resolver algún problema o

añadir más funcionalidades.



4. METODO DE TRABAJO

Para gestionar el desarrollo de software se ha utilizado una metodología ágil

llamada SCRUM. SCRUM es un framework o conjunto de buenas prácticas para la

gestión de proyectos. SCRUM se basa en entregas parciales y regulares del

producto final, comenzando por aquellas funcionalidades más importantes para el

cliente (Lara, 2015).

Con SCRUM podemos realizar un proceso iterativo e incremental, basado en

Sprints. Sus principales características son:

Adoptar una estrategia de desarrollo incremental, en lugar de la

planificación y ejecución completa del producto.

Basar la calidad del resultado más en el conocimiento tácito de las

personas en equipos auto-organizados, que en la calidad de los

procesos empleados.

Solapamiento de las diferentes fases del desarrollo, en lugar de realizar

una tras otra en un ciclo secuencial o de cascada.

SCRUM define 3 roles principales:

Dueño del producto (Product Owner): Representa al cliente y lo que

éste necesita. Se encarga de definir los requisitos que espera obtener

del producto final. Este rol lo ocupa el tutor del proyecto, Arturo Montejo

Ráez representado a la Universidad de Jaén.

Scrum Master: Director del proyecto, se encarga de supervisar todo el

trabajo y asegurarse que el trabajo del equipo vaya bien. También se

encarga de resolver cualquier obstáculo que pueda haber en el proceso.

Este rol lo ocupa Arturo Montejo Ráez.

Team developer: Son los miembros del equipo, formado por analistas,

diseñadores y programadores y tienen la responsabilidad de entregar el

producto. En este caso este rol lo ocupa en exclusividad Miguel Ángel

Fernández Carrillo.



En cada Sprint se lleva a cabo una serie de eventos:

Reunión de planificación (Sprint Planning): Consiste en una reunión

entre el dueño del producto y el equipo de desarrollo, en donde el cliente

selecciona los requisitos del Product Backlog que requieren mayor

prioridad. El equipo de desarrollo evalúa el tiempo que le llevará realizar

las tareas, y determina que requisitos son viables. Esto se recoge en el

Sprint Backlog.

Ejecución del sprint: Cada semana, durante cada sprint el scrum

master supervisa el trabajo del equipo para eliminar posibles obstáculos

y guiándolos por el camino correcto. Dentro de estas reuniones se

realizan otras reuniones a diario entre el equipo de desarrollo, en

donde se preguntan: ¿Qué hiciste ayer?, ¿Qué tienes planeado hacer

hoy?, ¿Qué problemas has encontrado? Estas reuniones se realizan

para que los miembros del equipo se apoyen entre sí.

Revisión del sprint: El acabar el Sprint se le muestra al cliente todos

los requisitos conseguidos durante dicho Sprint. El cliente puede realizar

adaptaciones o cambios sobre el proyecto. De la misma forma, el equipo

de desarrollo expone los problemas que han encontrado en el proceso.

Figura 4.1. Ciclo de vida de un Sprint.



En la Figura 4.1, podemos observar los documentos que se desarrollan durante

el ciclo de vida del sprint. A continuación, se muestra una descripción de cada

documento (Martel, 2014):

Pila del producto (Product Backlog): Es simplemente una lista de

tareas a realizar. Se especifican a alto nivel cada una de las

funcionalidades que deberá de tener el producto final. Esta lista la debe

de definir y priorizar la persona que conoce las necesidades del producto

(Dueño del producto).

Pila del Sprint (Sprint backlog): Es una sublista de la anterior, donde

el dueño del producto, selecciona aquellas tareas que el equipo de

desarrollo puede hacer durante las próximas semanas (Sprint). Para

este tiempo se deberá de tener terminadas las tareas y probadas

Panel de tareas: Consiste en hacer una tabla dividida en tres

categorías: tareas por hacer, tareas haciéndose y tareas terminadas.

De esta forma, al iniciar el sprint todas las tareas estarán en la primera

columna, y al pasar a la columna segunda, indicará al scrum master que

tareas están haciendo el equipo de desarrollo. Por ultimo al terminar la

tarea, debe de pasar a la tercera columna de finalizada.

Figura 4.2. Fases que se realizan en cada sprint.



Analizando los aspectos más importantes de SCRUM, se pueden definir los

principales beneficios que nos ofrece esta metodología:

Flexibilidad a cambios. Gran capacidad de reacción ante los

cambiantes requerimientos generados por las necesidades del cliente o

la evolución del mercado. El marco de trabajo está diseñado para

adecuarse a las nuevas exigencias que implican proyectos complejos.

Reducción del Time to Market. El cliente puede empezar a utilizar las

características más importantes del proyecto antes de que esté

completamente terminado

Mayor calidad del software. El trabajo metódico y la necesidad de

obtener una versión de trabajo funcional después de cada iteración,

ayuda a la obtención de un software de alta calidad.

Mayor productividad. Se logra, entre otras razones, debido a la

eliminación de la burocracia y la motivación del equipo proporcionado

por el hecho de que pueden estructurarse de manera autónoma.

Maximiza el retorno de la inversión (ROI). Creación de software

solamente con las prestaciones que contribuyen a un mayor valor de

negocio gracias a la priorización por retorno de inversión.

Predicciones de tiempos. A través de este marco de trabajo se conoce

la velocidad media del equipo por sprint, con lo que es posible estimar

de manera fácil cuando se podrá hacer uso de una determinada

funcionalidad que todavía está en el Backlog.

Reducción de riesgos. El hecho de llevar a cabo las funcionalidades de

mayor valor en primer lugar y de saber la velocidad a la que el equipo

avanza en el proyecto, permite despejar riesgos efectivamente de

manera anticipada.



4.1. SPRINT 1

Llamaremos sprint al periodo de tiempo en el cual se realiza un incremento de

la funcionalidad de la aplicación final. Este periodo de tiempo suele ir de 2 a 4

semanas. En cada sprint se realiza una serie de etapas o subprocesos:

Planificación: Donde se seleccionan las tareas que se van a realizar durante

el sprint.

Diseño: Etapa en donde describimos con el máximo detalle el cómo se van

realizar las tareas.

Desarrollo: Es la etapa en donde se realizan las tareas.

Pruebas: Donde debemos de comprobar que las funcionalidades se cumplen

correctamente y debemos de mostrarlas al cliente.

4.1.1. PLANIFICACIÓN DEL SPRINT

Durante la reunión para planificar la iteración el equipo de desarrollo va

seleccionado objetivos de la pila del producto (historias de usuarios) que

pasarán a la pila del sprint (Sprint Backlog) para ir descomponiéndolas en tareas.

Se selecciona tantos objetivos como se piensa que se va a tener terminado durante

el sprint y la velocidad nos permitirá comprobar si se están seleccionado pocos o

muchos objetivos.

A continuación, se muestra las historias de usuario:


HU - 01 Como usuario invitado, quiero crear una cuenta para poder acceder a la aplicación.

2

HU - 02 Como usuario registrado, quiero eliminar mis datos. para darme de baja de la aplicación.

0

HU - 03 Como usuario registrado, quiero modificar mis datos del perfil por otros nuevos.

1

HU - 04 Como usuario registrado, quiero iniciar sesión para usar la aplicación.

2

HU - 05 Como usuario registrado, quiero buscar perfiles de otros usuarios para estar en contacto e informado de sus novedades.

3




De las historias de usuarios que hemos seleccionado para este sprint podemos

extraer las siguientes tareas:

Historia de usuario

Identificador de la tarea

Descripción de la tarea

HU - 01 T - 01 Crear modelo ‘Users’.

HU - 01 T - 02 Habilitar rutas para acceder al registro.

HU - 01 T - 03 Crear controlador ‘Users_controller’.

HU - 01 T - 04 Realizar un formulario de registro.

HU - 01 T - 05 Realizar validaciones en el formulario.

HU - 01 T - 06 Comprobar que se puede crear usuarios.

HU – 02 T - 07 Formulario de Baja.

HU - 03 T - 08 Realizar formulario modificación.

HU - 03 T – 09 Realizar validaciones en el formulario.

HU - 03 T - 10 Comprobar que se han modificado los datos

HU - 04 T – 11 Realizar controlador para las sesiones.

HU - 04 T – 12 Hacer formulario para iniciar sesión.

HU - 04 T - 13 Comprobar que los usuarios pueden entrar en la aplicación.

HU - 05 T - 14 Crear JSON usuarios.

HU - 05 T – 15 Añadir acción “Search” en el controlador.

HU - 05 T - 16 Formulario para buscar a los usuarios.

Tabla 4.2. Tareas para desarrollar durante el sprint 1.



4.1.2. DISEÑO

La fase de diseño consiste en definir el producto con el máximo nivel de

detalles posibles para que el programador pueda en la siguiente fase realizar un

software de calidad y ajustado a los requisitos.

Para la parte de modelado de diagramas se va a utilizar el software Visual

Paradigm, que se trata de una herramienta muy completa, y que además cuenta

con la licencia académica de la Universidad de Jaén. Y para la parte de diseño de

interfaces, se va a utilizar inicialmente lápiz y papel para la definición de

wireframe, y posteriormente se pasará a Sketch 3.

En primer lugar, se definen los modelos de caso de uso. Estos modelos nos

permiten describir los pasos que se deberá de seguir para llevar a cabo algún

proceso. A los usuarios o entidades que participan en los casos de uso se le

denomina actores y a la secuencia de interacciones que se da entre el sistema y

sus actores se le denomina casos de uso.

A continuación, se describen los casos de uso que han sido identificados para

esta iteración, junto con el flujo de la información para cumplir el objetivo del caso de

uso. Tras los modelos de casos de uso, se incluye el diagrama de dichos modelos.



CREAR NUEVO USUARIO: Para la creación de usuarios, debemos de rellenar

un formulario sencillo, este formulario tan solo consta de cuatro campos de texto

para no estresar demasiado al usuario. El primer campo corresponde al nick del

usuario, el segundo campo es el nombre, el tercero el correo electrónico y el último

campo para la contraseña. Además de ello, se incluye un botón para enviar el

formulario. El formulario deberá de realizar validaciones en tiempo real, que

mostrará los campos que están erróneos y no nos dejará enviar el formulario.

Identificador: CU 01

Nombre: Crear Cuenta

Descripción: Proceso para dar de alta un nuevo usuario.

Actor: Usuario invitado

Precondiciones: N/A

Escenario básico:

1. Introducir datos del usuario. 2. El sistema comprobará la validez de los datos. 3. Crear cuenta.

Escenario Alternativo:

2.A – ¿Datos válidos? 2.A.1 – Si, ir al paso 3. 2.A.2 – No, mostrar errores al usuario y volver al paso 1.

Postcondiciones: La cuenta de usuario se ha creado correctamente Tabla 4.3. Caso de uso CU-01.

A continuación, se muestra el diagrama de casos de uso:

Figura 4.3. Diagrama de caso de uso CU-01.



MODIFICACIÓN DE USUARIO: Para cambiar o actualizar los datos de un

usuario, tendremos que acceder desde el perfil de usuario. Una vez en el perfil, se

mostrará un formulario con todos los datos del usuario. En este formulario podemos

cambiar la foto del avatar, mediante un elemento de tipo File, también podemos

añadir la información para otros campos que no se incluían en el formulario de

registro, como son los apellidos y la biografía. Para guardar la biografía se utiliza un

elemento TextArea. Otros de los elementos que podemos encontrar son los mismo

que ya habíamos mostrado en el formulario del registro, que, en este formulario,

podemos modificar o actualizar, como son el usuario, el nombre, correo electrónico o

la contraseña.


Nombre: Modificar datos personales

Descripción: Los usuarios tendrán la opción de modificar sus datos de perfil.

Precondiciones: El usuario debe de poseer una cuenta en la aplicación.

Escenario básico:

1. Introducir datos del usuario. 2. El sistema comprobará la validez de los datos. 3. Actualizar usuario.

Escenario Alternativo

Postcondiciones: Los datos son modificados Tabla 4.4. Caso de uso CU-02.





ELIMINAR USUARIO: Para dar de baja una cuenta, es necesario que la cuenta

exista con anterioridad. Si deseamos eliminar la cuenta, debemos acceder al perfil

del usuario como en el punto anterior, justo después del formulario para modificar los

datos, nos encontramos una sección más pequeña formada por un mensaje y un

botón en rojo. El mensaje nos indicará que para eliminar la cuenta debemos de

pulsar el botón, y si pulsamos el botón, nos volverán a preguntar de si estamos

seguros, le marcamos que sí, y nos eliminará cuenta del sistema. La eliminación de

la cuenta, conlleva además borrar todos los mensajes y relaciones del usuario.

Con la cuenta eliminada, ya no tendríamos acceso a la aplicación y si

quisiéramos volver, tendríamos que hacer nuevamente otra cuenta.


Nombre: Baja usuario

Descripción: Los usuarios podrán cancelar sus cuentas en el sistema.

Precondiciones: El usuario deberá de tener una cuenta registrada.

Escenario básico:

1. Abrir perfil de usuario. 2. Pulsar en “Cancelar cuenta” 3. Si confirmamos, se borrará la cuenta

Escenario alternativo

4. Si pulsamos en rechazar se cancela la operación y volvemos al paso 1.

Postcondiciones: El sistema borra los datos del usuario Tabla 4.5. Caso de uso CU-03.





INICIAR SESIÓN: Solo podrán iniciar sesión los usuarios que tengan una

cuenta creada en la aplicación. Para iniciar sesión debemos de rellenar un formulario

muy sencillo, compuesto por tan solo dos campos de texto. Para el primer elemento

del formulario se ha decido que sea el correo electrónico, aunque en un futuro puede

cambiarse por el nick del usuario. El segundo elemento del formulario corresponde a

la contraseña. Por último, tendremos un botón para mandar este formulario al

servidor y comprobar la autenticación de los datos.


Nombre: Iniciar sesión

Descripción: Un usuario inicia sesión en el sistema.

Precondiciones: El usuario deberá de tener una cuenta registrada.

Escenario básico:

1. Introducir correo electrónico. 2. Comprobar correo. 3. Introducir contraseña. 4. Comprobar contraseña. 5. Iniciar sesión


2.A – ¿Correo válido? 2.A.1 – Si, ir al paso 3. 2.A.2 – No, mostrar errores al usuario y volver al paso 1. 4.A – ¿Contraseña válida? 4.A.1 – Si, ir al paso 5. 4.A.2 – No, mostrar errores al usuario y volver al paso 3.

Postcondiciones: El usuario accede al sistema Tabla 4.6. Caso de uso CU-04.





BUSCAR USUARIOS: Cualquier usuario puede entrar a otros perfiles de los

usuarios del sistema, para entrar en otro perfil, lo podemos hacer pulsando sobre el

autor de un mensaje, o si conocemos su nombre o nick, escribiéndolo en el

buscador.


Nombre: Buscar perfiles de usuarios

Descripción: Los usuarios pueden leer los perfiles de otros usuarios del sistema.

Precondiciones: El usuario tiene que existir.

Escenario básico:

1. Ingresar a la aplicación. 2. Introducir su nombre o nick en el buscador. 3. Si existe, mostrar su perfil.


3. Si no existe, volver al paso 2.

Postcondiciones: Se muestra los datos del perfil del usuario. Tabla 4.7. Caso de uso CU-05.





En segundo lugar, tras haber definido los casos de uso, vamos a definir como

deseamos guardar esta información, para ello creamos un modelo para la entidad de

Usuarios, que deberá de tener los siguientes atributos:

Nick (Varchar): Cadena de texto de longitud máxima de 20 caracteres. o No puede ser nulo. o Debe de ser único.

Nombre (Varchar): Cadena de texto de longitud máxima de 80 caracteres.

o No puede ser nulo.

Correo electrónico (Varchar): Cadena de texto de longitud máxima de 80 caracteres.

o No puede ser nulo. o Debe de ser único en el sistema.

Contraseña (Varchar)

o Debe estar protegida frente a posibles robos.

o Debe de tener una longitud igual o mayor a 8 caracteres.

Biografía (Text): Texto con longitud máximo de 255 caracteres.

Apellidos (Varchar): Cadena de texto con longitud máxima de 100

caracteres.

Nivel (TinyInt): Atributo usado para representar los permisos de los

usuarios (1-Admin / 2-Usuario), por defecto se crea sin permisos.

Avatar (Varchar): Cadena de texto con longitud de 255 caracteres para

representar el link del avatar.

Figura 4.8. Entidad usuarios.



4.1.3. IMPLEMENTACIÓN

Antes de empezar con el desarrollo, debemos recordar que Ruby on Rails

utiliza un patrón Modelo-Vista-Controlador (MVC).

Los tres roles son:

Modelo: Representa la información con la que el sistema trabaja, por

tanto, es la que gestiona todos los accesos a dicha información, tanto a

consultas como a actualizaciones. Se comunica con la vista para pasarle

la información que se requiere en cada momento. Las peticiones para

acceso o manipulación llegan a modelo a través del controlador.

Vista: Representa a las clases que permiten una interacción con la

aplicación, es decir, se trata de la interfaz gráfica. Requiere de la

información del modelo para representar la información y notifica al

controlador de las acciones que realiza el usuario.

Controlador: Representa a las clases que responde a los eventos del

usuario, y realiza peticiones al modelo para solicitar la información

requerida. También puede comunicarse con la vista si se solicita un

cambio en la forma de representar la información, por tanto, se puede

decir que el controlador es un intermediario entre la vista y el modelo.

Figura 4.9. Modelo Vista Controlador.



CREAR NUEVO USUARIO: Lo primero que vamos a necesitar para poder

guardar los datos de los usuarios es un modelo, de este modo creamos el modelo

“Usuario”. En el modelo debemos añadir validaciones para el nick, nombre, correo

electrónico y contraseña, así evitaremos que se guarden datos erróneos en la base

de datos.

Como ya habíamos visto en el punto anterior, para crear un nuevo usuario

debemos de rellenar un formulario, esto lo podemos hacer con los elementos de

HTML5, sin embargo, vamos a usar los helpers de Ruby on Rails para realizarlo más

rápido.

Cuando tengamos el formulario creado, aun no tendríamos acceso, nos

quedaría habilitar la ruta “/register” y añadir las acciones en el “Users_controller”. Así

cuando el usuario acceda a /register, el controlador le responderá con el formulario

de registro.

En Ruby on Rails existe una gema denominada “Devise”, que nos ayudará

con el manejo de usuarios. La selección de esta gema frente a otras, es

principalmente por estar destinada a entornos de producción y por la seguridad que

aporta a las sesiones de usuarios y a sus claves de acceso.

A continuación, se muestra cómo quedaría:

Figura 4.10. Vista de registros con errores. Figura 4.11. Vista de registro sin errores.



MODIFICAR USUARIO: La modificación de usuarios se realizará nuevamente

con un formulario, este formulario deberá ser más amplio que el formulario del

registro, incluyendo nuevos campos, como la selección de un nuevo avatar, o los

campos para añadir los apellidos y la biografía. El resto de campos estarán rellenos,

aunque podemos actualizar su valor. Para cambiar la contraseña, debemos

introducir la contraseña actual y la nueva contraseña.

Para poder acceder a este formulario, vamos a necesitar habilitar nuevas rutas

de acceso. Como el formulario lo encontramos en el perfil del usuario, vamos a

habilitar la ruta de “/profile”.

Por ultimo debemos añadir las acciones al controlador para que cuando un

usuario haga una petición a la ruta “/profile” nos responda con la vista del formulario.

AL rellenar el formulario y pulsar sobre actualizar, se llamará de vuelta al controlador

que mediante una acción “UPDATE” actualizará los campos de la base de datos.

Nos podemos ayudar de los helpers de Ruby on Rails que en este caso

utilizando “current_user” nos redirige al usuario que tiene la sesión iniciada.

Figura 4.12. Vista para modificar un usuario.



BAJA DE USUARIO: La eliminación de un usuario, consiste en un único botón

rojo acompañado de un mensaje de texto, que nos indicará que la acción es

peligrosa y debemos de tener cuidado.

Figura 4.13. Vista para dar de baja la cuenta.

Si lo que queremos es eliminar la cuenta, debemos pulsar sobre el botón

“Eliminar”, y para evitar accidentes y darle sin querer, se ha incluido un segundo

mensaje de alerta, si no deseamos borrar la cuenta, podríamos volver a atrás, sin

problemas y si aceptamos, se realizará una llamada al controlador a la acción de

“DELETE”, y procederá a borrar los registros de la base de datos.

Figura 4.14. Confirmación de baja de usuario.

Esta acción es irreversible, si damos de baja un usuario se borra

completamente todos los datos, por lo que, si se desearía regresar, tendríamos que

crear la cuenta desde el inicio.

En este caso no necesitaremos añadir nuevas rutas de acceso, ya que como

indicamos en la fase de diseño, la baja del usuario va a ir tras el formulario de

modificación del usuario.



INICIAR SESIÓN: Para entrar en la aplicación, es necesario que tengamos una

cuenta de usuario. Para iniciar la sesión, debemos de rellenar un formulario muy

sencillo, introduciendo el correo electrónico y la contraseña con la nos creamos la

cuenta, el sistema nos validará y nos dará acceso.

Sin embargo, para poder acceder a la vista, tendremos que habilitar otra ruta

nueva para “/login”, tras ello, hay que indicarle al controlador que todas las

peticiones que nos lleguen por esta ruta, nos responda con el formulario de inicio de

sesión.

Al utilizar la gema de rails “Devise” no nos tenemos que preocupar por

gestionar las sesiones ni proporcionar seguridad a la contraseña, ya que la gema lo

hace todo.

Figura 4.15. Vista para iniciar sesión.

Como podemos ver en la Figura 4.15, hemos incluido un link para registrarse y

otro link para en el caso que olvidemos la contraseña.



BUSCAR USUARIOS: Antes de empezar, vamos a necesitar una librería

adicional de JavaScript llamada “TypeaHead.js”, esta librería le dará una apariencia

más parecida a Twitter.

Empezamos habilitando la ruta para consultar los usuarios, y esta vez en el

controlador vamos a responder con formato. json, tendremos por un lado /users.json

que mostrará todos los usuarios y /users/:id, que podrá responder en HTML o en

JSON mostrando la información del usuario.

El buscador estará formado por un formulario, que, al enviar el formulario,

realizará una petición a /search, por lo tanto, tendremos que crear otro controlador

que deberá de comprobar el valor recibido por la caja de texto con los nicks de

usuarios y los nombres que estarán alojados en el JSON.

Figura 4.16. Buscador de usuarios.

Los resultados obtenidos deberán ser mostrados mediante AJAX en el

buscador y el usuario deberá seleccionar un resultado. Al hacer clic sobre un

resultado, nos llevará al perfil de dicho usuario.

Figura 4.17. Resultados de la búsqueda por nombre.

Si existen demasiadas coincidencias, se mostrarán solo los cinco primeros

resultados.



4.1.4. PRUEBAS

Esta fase es la más importante de cada sprint, nos ayudará a verificar el

funcionamiento parcial del sistema y nos ayudará a identificar errores. Para realizar

las pruebas vamos a realizar test de unidad mediante una gema de rails llamada

“Mini-test”.

TEST#CREAR_USUARIO: Para pasar este test se debe poder guardar un

usuario introduciendo todos los campos (nick, nombre, email y password), si falta

algún campo, el test no se va a superar.

Para comprobar que un usuario se ha creado con los datos correctamente

podemos realizar varios test para cada dato del usuario, test para comprobar que los

datos no son nulos, y test para comprobar que tienen la longitud adecuada.

Sin embargo, como todas las restricciones están definidas en el modelo

“Users”, solo debemos de comprobar si un usuario es válido o no.

TEST#VALIDACION: Para superar este test el usuario que le pasemos, deberá

ser un usuario válido, esto es que debe de cumplir con las restricciones del modelo.

TEST#ELIMINAR_USUARIO: Este test se supera si al pasarle un usuario nos

permite destruirlo.

A continuación, se muestra el resultado de las pruebas:

Figura 4.18. Resultados de los test del usuario.

Como vemos en la Figura 4.18 se han ejecutado diez pruebas y las diez han

sido superadas.



4.2. SPRINT 2

Este Sprint inicia el día 5 de octubre del 2015 y se estima que termine el día 30

de octubre del 2015, teniendo así una duración de 4 semanas. El sprint inicia con la

planificación, en donde seleccionamos nuevos objetivos para este sprint, luego le

sigue la fase en donde diseñamos la solución al problema y por último se desarrolla

y se comprueba que todo funciona correctamente.


Para este sprint podríamos haber seguido completando los objetivos de los

usuarios, sin embargo, se decide seleccionar historias de usuarios relacionadas con

una nueva entidad, estas son:


HU-06 Como usuario registrado, quiero crear un nuevo mensaje para mostrarlo en la aplicación.

2

HU-07 Como lector, quiero ver una lista de los mensajes del timeline ordenados por su fecha de creación para poder leerlo de forma más ordenada.

3

HU-08 Como autor de un mensaje, quiero borrar mis mensajes para que no se muestren en la aplicación.

0

HU-09 Como usuario registrado, quiero difundir los mensajes de otros usuarios para que más usuarios puedan leerlo.

2

HU-10 Como usuario registrado, quiero responder a mensajes de otros usuarios

2

Tabla 4.8. Historias de usuarios seleccionadas para el sprint 2

Como se puede ver en la Tabla 2.3 si sumamos los puntos de historia de este

sprint nos da un total de 9 puntos, y si miramos la estimación que hacíamos en

capítulo 3, veíamos que deberíamos de llevar una velocidad de 6 puntos, por lo

tanto, en este se consigue estar por encima de la velocidad estimada.



De las historias de usuarios que hemos seleccionado para este sprint, hemos

podido extraer las siguientes tareas:

Historia de usuario



HU - 06 T - 01 Crear modelo ‘Posts’.

HU - 06 T – 02 Establecer la relación entre usuarios y mensajes.

HU - 06 T – 03 Crear controlador ‘Posts_controller’.

HU - 06 T – 04 Realizar las vistas para crear mensajes.

HU - 06 T – 05 Añadir un contador de caracteres a la vista de los mensajes.

HU - 06 T – 06 Comprobar que los mensajes se han creado.

HU – 07 T – 07 Crear una función “timeline” para listar los mensajes del usuario.

HU – 07 T - 08 Ordenar los mensajes por la fecha de creación.

HU – 08 T - 10 Crear una acción para eliminar mensajes.

HU – 08 T – 11 Comprobar que los mensajes son borrados.

HU – 09 T - 12 Crear una función para clonar mensajes.

HU - 09 T - 13 Añadir al mensaje clonado el usuario que lo difunde.

HU - 10 T -14 Crear vistas para responder a los mensajes.

HU - 10 T -14 Añadir destinatario en la respuesta del mensaje.

HU - 10 T -15 Comprobar que se han creado las respuestas.

Tabla 4.9. Tareas de desarrollo para el sprint 2.



4.2.2. DISEÑO

CREAR MENSAJE: En primer lugar, vamos a necesitar de una acción del

usuario para mostrar la vista de creación de mensajes. Esta acción consiste en un

pulsar un botón que deberá estar visible en todas las vistas de la aplicación, por ello

el mejor sitio para el botón, es en el Header.

Otra decisión de diseño, es que la vista para crear mensaje, sea en forma de

modal, al estilo twitter. El modal deberá estar formado por un TextArea como

elemento principal para introducir el texto del mensaje y una etiqueta de texto que

muestre el número de caracteres de dicho mensaje representando un contador, así

si superamos el límite de 140 caracteres, el contador pasará a tener un color rojo

para avisar al usuario que no puede ser enviado el mensaje.


Nombre: Crear mensaje

Descripción: Los usuarios pueden añadir nuevos mensajes

Precondiciones: El usuario tiene que estar autenticado en el sistema.

Escenario básico:

1. Escribir el texto del mensaje. 2. El sistema comprueba la validez del mensaje. 3. Enviar


2.A – ¿Mensaje válido? 2.A.1 – Si, ir al paso 3. 2.A.2 – No, volver al paso 1.

Postcondiciones: Se manda el mensaje al sistema. Tabla 4.10. Caso de uso CU-06.

A continuación, se muestra el diagrama de caso de uso asociado a la Tabla

4.10.




LISTAR MENSAJES: El listado de mensajes es la vista principal de la

aplicación, actualmente se recoge en forma de línea de tiempo los mensajes que

tengamos escritos, aunque esta función más adelante nos mostrará los mensajes de

otros usuarios y los mensajes de grupos.

El listado deberá estar ordenado cronológicamente en orden descendente, de

este modo en la parte superior tenemos los mensajes más recientes, y en la parte

inferior los mensajes con más antigüedad.

Cada mensaje de la lista estará compuesto por el propio contenido, el autor del

mensaje, la fecha de creación y las acciones que podemos realizar sobre dicho

mensaje:

DIFUNDIR MENSAJE: Esta acción consiste en crear una copia idéntica del

mensaje original y añadirle un nuevo usuario (el usuario que lo comparte). Para

difundir el mensaje, deberemos de seleccionar un mensaje y pulsar la acción de

“Difundir”.

El mensaje resultante deberá incluir tanto el nombre del autor original como el

nombre de la persona que colabora con su difusión.


Nombre: Difundir mensaje entre usuarios.

Descripción: Un usuario podrá colaborar, difundiendo mensajes para que puedan llegar a más usuarios.

Precondiciones: El autor del mensaje no puede difundir su propio mensaje.

Escenario básico: 1. El sistema comprueba que hay mensajes. 2. Mostrar mensajes. 3. Leer mensajes. 4. Seleccionar un mensaje. 5. Difundir


1.A – ¿Hay mensajes? 1.A.1 – Si, Ir al paso 2 1.A.2 – No, cancelar operación.

Postcondiciones: El mensaje se difunde entre los usuarios.

Tabla 4.11. Caso de uso CU-07.



RESPONDER MENSAJE: Esta acción se muestra a todos los usuarios, así de

este modo, cualquier usuario podrá responder a un mensaje, para hacerlo deberá de

seleccionar un mensaje, pulsar sobre la acción “Responder” y escribir la respuesta.

La respuesta deberá incluir a la persona que estamos respondiendo.


Nombre: Responder a los mensajes de usuarios

Descripción: Un usuario puede responder al mensaje de otro usuario

Precondiciones: N/A

Escenario básico: 1. El sistema comprueba que hay mensajes. 2. Mostrar mensajes. 3. Leer mensajes. 4. Seleccionar un mensaje. 5. Responder.



Postcondiciones: Se crea un nuevo mensaje con la respuesta al usuario.


ELIMINAR MENSAJE: La acción de eliminar solo se mostrará a los usuarios

que sean propietarios del mensaje. Si un usuario desea borrar un mensaje, deberá

pulsar sobre la acción “Eliminar” y se borrará su contenido de la aplicación.


Nombre: Eliminar un mensaje de la lista.

Descripción: El autor del mensaje puede borrar sus mensajes.

Precondiciones: El usuario debe ser autor del mensaje.

Escenario básico: 1. El sistema comprueba que hay mensajes. 2. Mostrar mensajes. 3. Leer mensajes. 4. Seleccionar un mensaje. 5. Eliminar.



Postcondiciones: Se borra el mensaje por completo del sistema Tabla 4.13. Caso de uso CU-09.

A continuación, se muestra el diagrama de caso de uso.




En segundo lugar, se pasa al diseño de la base datos, para este sprint será

necesario añadir una nueva entidad a la base de datos, esta será la entidad

‘Mensajes’, que tendrá los siguientes campos:

Id_Post (Integer): Llave primaria de la tabla Mensajes.

Content (Varchar): Cadena de texto con longitud máxima de 144

caracteres.

User_id (Integer): Llave foránea a la tabla de Usuarios.

Created_at (DateTime): Representa la fecha de creación del mensaje.

Figura 4.21. Relación entre las tablas usuarios y mensajes.

Como podemos ver ya hemos relacionado los usuarios con los mensajes

mediante una relación de 1 a muchos, por la que un usuario puede escribir muchos

mensajes.




CREAR MENSAJE: Como se había indicado en el diseño, vamos a necesitar

de una acción para abrir la vista para crear mensajes, así pues, pasamos a crear un

botón en HTML5 que sea la acción principal de la aplicación.

Figura 4.22. Botón para añadir un nuevo mensaje.

Antes de seguir, como estamos trabajando con los mensajes, y aun no existe

ninguna tabla en la base de datos para almacenar los mensajes, debemos de crear

el modelo “Post” y las migraciones. Al modelo debemos incluirle las validaciones de

datos, junto con una función que permita analizar el contenido del mensaje.

Después de tener el modelo, nos quedaría por crear el controlador

“Post_controller” para que podamos responder a las acciones “NEW” y “CREATE”,

además tenemos que habilitar las rutas para que los usuarios puedan entrar.

Ahora ya, cuando pulsemos el botón, se abrirá por AJAX la vista modal para

crear un nuevo mensaje. La vista está formada por un TextArea para escribir el

contenido del mensaje y un botón para enviar el mensaje y otro para cancelar la

operación. Al pulsar enviar lo recibe el controlador que le añade el autor del

mensaje, y este será el usuario que tiene la sesión iniciada.

Figura 4.23. Vista del formulario para crear un nuevo mensaje.



MOSTRAR LISTADO DE MENSAJES: En la navegación de la aplicación se ha

creado una opción “Inicio”, para que desde cualquier parte de la aplicación en la que

estemos, al pulsar sobre “Inicio” nos llevará al timeline del usuario. Para que sea

accesible esta ruta, debemos de añadir la acción “Index” al controlador de

“Post_controller”.

El timeline, como se explicó en puntos anteriores, consiste en un listado de

mensajes ordenados por la fecha de creación. Cada mensaje de la lista tiene un

elemento <img> para mostrar el avatar del usuario, el propio contenido del mensaje,

el nick del usuario que lo ha creado y la fecha de creación.

Figura 4.24. Vista de la lista de mensajes.

Como vemos en la Figura 4.24. hemos creado un Helper que analiza el texto

del contenido del mensaje y comprueba si se ha citado a un usuario o a un grupo.

Esto se consigue buscando las palabras precedidas de ‘@’ y ‘#’.

RESPONDER MENSAJE: Para responder al mensaje, necesitamos un link que

nos lleve a la ruta habilitada ‘/posts/:id/reply’, esta petición será atendida por el

controlador que creará un nuevo mensaje, pero además deberá de añadirle el

nombre del usuario al que queremos responder.

Figura 4.25. Vista del formulario para responder un mensaje.



DIFUNDIR MENSAJE: Esta acción funciona de manera similar a la de

responder el mensaje, con la diferencia que el link de la vista nos llevara a la

siguiente ruta ‘/posts/:id/clone’. Al ser llamada por un usuario, el controlador recibirá

la petición, que clonará el mensaje y le añadirá el campo del usuario que ha

compartido el mensaje.

BORRAR MENSAJE: Inicialmente debemos de comprobar que el mensaje

seleccionado pertenece a la persona que lo está leyendo, si es el caso, se muestra

la acción de borrar. Sin embargo, para que sea accesible por el usuario hay que

añadir la acción “DELETE” en el controlador.

4.2.4. PRUEBAS

Para poder avanzar al siguiente sprint, debemos de realizar antes las pruebas

de unidad, que nos servirá para comprobar que las fases anteriores están correctas

o para identificar algún error.

TEST#CREAR_MENSAJE: Este test lo superamos si nos permite crear y

guardar en la base de datos un nuevo mensaje.

TEST#ELIMINAR_MENSAJE: Este test nos permite comprobar si un mensaje

puede ser eliminado por su autor.

TEST#VALIDACIÓN_CONTENIDO: Para superar este test los mensajes no

deberán de superar los 140 caracteres.

Figura 4.26. Resultados de los test.



4.3. SPRINT 3

Si miramos la planificación del capítulo 3 este sprint tenía una fecha de inicio

estimada para el día 2 de noviembre del 2015, y una fecha de finalización para el 27

de noviembre del mismo año. Este sprint como los anteriores está compuesto por

cuatro fases, inicia con la planificación para seleccionar nuevos objetivos, luego le

sigue la fase para diseñar una solución al problema y por último están las fases de

desarrollo y pruebas, para verificar el cumplimiento de los objetivos.


Observando las historias de usuario que quedan en la pila del producto, vemos

que aún nos quedan algunas historias relacionadas con algunas de las entidades

que ya hemos creado en las iteraciones pasadas. Por tanto, hemos seleccionado las

siguientes historias de usuarios para este sprint.


HU-11 Como usuario registrado, quiero seguir a otros usuarios.

2

HU-12 Como seguidor, quiero ver los mensajes de los usuarios a los que sigo en el timeline.

2

HU-13 Como usuario registrado, quiero ver un resumen de las estadísticas de los usuarios.

2

HU-14 Como usuario, quiero ver los usuarios que siguen a otro usuario.

1

HU-15 Como usuario, quiero ver los usuarios que sigue otro usuario.

1

HU-16 Como usuario registrado, quiero dejar de seguir a un usuario para dejar de recibir sus mensajes.

0

Tabla 4.14. Historias de usuario seleccionadas para el sprint 3.

Como podemos en la Tabla 4.14, si sumamos todos los puntos de historia de

usuarios, nos da un total de 8 puntos, que se ajusta a la velocidad estimada en el

capítulo 3.



De las cuales hemos podido extraer las siguientes tareas:

Historia de usuario



HU – 11 T – 01 Crear un modelo ‘Relationships’.

HU - 11 T - 02 Crear una relación de muchos usuarios a muchos usuarios.

HU – 11 T - 03 Crear controlador ‘Relationships_controller’.

HU – 11 T – 04 Añadir acción ‘NEW’ y ‘CREATE’ en el controlador.

HU - 11 T - 05 Añadir la vista para añadir seguidores.

HU - 11 T – 05 Comprobar que se establece la relación de seguidores.

HU – 12 T – 06 Buscar a todos los usuarios que seguimos.

HU – 12 T – 07 Buscar todos los mensajes de cada usuario que seguimos.

HU – 13 T – 08 Crear una vista para mostrar estadísticas del usuario.

HU – 14 T – 09 Añadir acción “Followers” en el controlador.

HU – 14 T – 10 Crear vista de “Followers”.

HU – 15 T – 11 Añadir acción “Following” en el controlador.

HU – 15 T – 12 Crear vista “Following”

HU - 16 T – 13 Añadir acciones ‘DESTROY’ y ‘DELETE’ al controlador.

HU - 16 T – 14 Realizar una vista para dejar de seguir usuarios.

HU – 16 T – 15 Comprobar que se elimina la relación.

Tabla 4.15. Tareas a realizar durante el sprint 3.



4.3.2. DISEÑO

SEGUIR USUARIOS: Si un usuario, llamémosle “Seguidor” quiere seguir a otro

usuario, llamémosle “Seguido”, el usuario “Seguidor” debe de entrar al perfil del

usuario “Seguido” y pulsar sobre “Seguir”. Esta relación implica que el “Usuario

seguidor” sigue al “Usuario seguido”, pero no al contrario.


Nombre: Seguir usuario

Descripción: Un usuario “Seguidor” crea una relación de seguimiento con el usuario “Seguido”.

Precondiciones: No se puede seguirse a sí mismo. No se puede seguir a la misma persona varias veces.

Escenario básico: 1. Buscar usuario. 2. El sistema comprueba que existe el usuario. 3. Seguir


2.A ¿Existe el usuario? 2.A.1 Si, ir al paso 3. 2.A.2 No, cancelar operación y salir.

Postcondiciones: Se establece la relación de seguimiento entre ambos usuarios.


DEJAR DE SEGUIR USUARIOS: Para dejar de seguir a un usuario al quien ya

seguimos, el proceso es similar al de seguir usuarios. El usuario “Seguidor” debe

entrar al perfil del usuario “Seguido” y pulsar sobre la acción “Dejar de seguir”, de

este modo se rompe la relación entre ambos usuarios.


Nombre: Dejar de seguir usuario

Descripción: Un usuario crea una relación de seguimiento con el usuario 2.

Precondiciones: Debe de existir una relación entre los usuarios.

Escenario básico: 1. Buscar usuario. 2. El sistema comprueba que existe el usuario. 3. Dejar de seguir


2.A ¿Existe el usuario? 2.A.1 Si, ir al paso 3. 2.A.2 No, cancelar operación y salir.

Postcondiciones: Se rompe la relación entre ambos usuarios.




A continuación, se muestra el diagrama de caso de uso, asociado a las Tablas

4.16 y 4.17.


VER MAS MENSAJES EN EL TIMELINE: Ahora cuando seguimos a otro

usuario, todos sus mensajes, pasarán a estar visibles desde nuestro timeline,

anteriormente para ver los mensajes de otro usuario, había que entrar directamente

a su perfil.

ESTADISTICAS DEL USUARIO: Cuando entramos a un perfil de un usuario,

se mostrará algunas estadisticas destacables del usuario, como el número de

mensajes que lleva escritos el usuario, el número de seguidores que tiene, y el

número de usuarios a los que sigue.

MOSTRAR FOLLOWERS: La vista para mostrar los seguidores consiste en

una lista de usuarios, para mostrar la lista, debemos pulsar sobre la acción de

“Followers” en las estadísticas del usuario.

MOSTRAR FOLLOWINGS: Esta vista es muy parecida a la anterior, con la

diferencia que ahora se muestran a los usuarios que estamos siguiendo.



En segundo lugar, debemos de diseñar la base de datos, empezamos

definiendo las relaciones, por las que un usuario puede seguir a muchos usuarios,

pero muchos usuarios pueden ser seguido también por muchos usuarios, por tanto,

estamos ante una relación de MUCHOS A MUCHOS. Estas relaciones no son

recomendables y debemos evitarlas creando tablas intermedias, pasando a tener

relaciones de UNO A MUCHOS.

Figura 4.28. Diseño de la base de datos en relación a los following.

Figura 4.29. Diseño de la base de datos en relación a los followers.




SEGUIR USUARIOS: Para poder guardar las relaciones entre usuarios vamos

a necesitar de un nuevo modelo “Relationships”. Se utilizará un parcial

“_FOLLOW_FORM” con un botón para “Seguir” al usuario. Este parcial se tiene que

mostrar dentro del perfil del usuario. Pero para que el botón funcione correctamente,

debemos de añadir la acción de “CREATE” dentro del controlador

“Relationships_controller”.

Figura 4.30. Vista para seguir a un usuario.

DEJAR DE SEGUIR USUARIOS: Para deshacer la relación entre usuarios, se

va a crear otro parcial llamado “_UNFOLLOW_FORM”, que funcionará de la misma

manera el parcial “_FOLLOW_FORM”, pero con la diferencia principal que el botón

de este llamará a la acción “DELETE” del controlador.

Figura 4.31. Vista para dejar de seguir a un usuario.



VER MAS MENSAJES EN EL TIMELINE: Esto se logra buscando a todos los

usuarios que seguimos y obteniendo todos sus mensajes. Se agrupan en una sola

lista los mensajes propios y los de los usuarios a los que seguimos, y se vuelve a

ordenador por fecha. El resultado final es mostrado en el timeline.

ESTADISTICAS DE USUARIOS: Dentro de las estadísticas podemos obtener

un resumen del usuario. El primer contandor nos indica el número de mensajes que

ha escrito ese usuario, luego tenemos otros dos contandores que nos indica el

número de seguidores y los usuarios a los sigue. Si pulsamos sobre cualquiera de

ellos nos llevará a otra vista para mostrarnos más información.

4.3.4. PRUEBAS

Dentro de las pruebas de unidad debemos de comprobar principalmente que se

llegan a crear la relaciones entre dos usuarios y que posteriormente puede

eliminarse esa relación:

TEST#CREAR_RELACIÓN: Este test se supera, si nos permite crear

una nueva relación y salvarla.

TEST#SEGUIRSE: Este test nos permite verificar que un usuario no

puede seguirse a sí mismo.

TEST#ELIMINAR_RELACIÓN: Este test lo superamos si pasándole una

relación existente la borra de la base de datos.


Como vemos en la Figura 4.32, se han ejecutado 3 test unitarios, y todos ellos

han superado las pruebas.



4.4. SPRINT 4

Este Sprint inicia el día 30 de noviembre del 2015 y se estima que termine el

día 25 de diciembre del 2015, teniendo así una duración de 4 semanas. Este sprint

como los anteriores inicia con la planificación, para seleccionar nuevos objetivos,

luego le sigue la fase para diseñar la solución al problema y por último se desarrolla

y se comprueba que todo funciona correctamente.


En este punto del proyecto ya quedan menos objetivos, y como aún hay

historias de usuarios independientes del resto, vamos a seleccionar aquellas que

podemos realizar, estas son:


HU-17 Como usuario registrado, quiero crear un nuevo grupo para poder organizar los mensajes de una misma temática.

2

HU-18 Como propietario de un grupo, quiero modificar el grupo para cambiarle las propiedades.

1

HU-19 Como propietario de un grupo, quiero eliminar un grupo.

0

HU-20 Como usuario registrado, quiero ver un listado donde se muestren todos los grupos.

1

HU-21 Como usuario registrado, quiero buscar grupos por su nombre o etiqueta.

3

Tabla 4.18. Historias de usuario seleccionadas para el sprint 4

Observando la Tabla 4.18, vemos una velocidad de 7 puntos de historia, y la

estimación estaba en 5 puntos.



De la Tabla 4.3. podemos extraer las siguientes tareas:

Historia de usuario



HU-17 T - 01 Crear modelo “Group” y sus migraciones.

HU-17 T – 02 Crear un controlador “Group_controller” y responder a las peticiones “NEW” y “CREATE”

HU-17 T – 03 Hacer la vista para crear un nuevo grupo.

HU-17 T – 04 Realizar validaciones del grupo

HU-17 T - 05 Comprobar que un grupo se han creado correctamente.

HU-18 T – 06 Hacer la vista para mostrar el listado de grupos.

HU-18 T – 07 Añadir la acción “INDEX” al controlador

HU-19 T - 08 Hacer vista para la modificación del grupo.

HU-19 T - 09 Añadir acciones de “UPDATE” en el controlador de grupos para responder al usuario

HU-19 T - 10 Comprobar que los datos han sido modificados.

HU-20 T – 11 Hacer la vista para eliminar un grupo.

HU-20 T – 12 Añadir la acción de “DESTROY” al controlador.

HU-20 T - 13 Comprobar que ha borrado completamente el grupo.

HU-21 T – 14 Crear JSON de grupos.

HU-21 T – 15 Añadir acción “Search” en el controlador

HU-21 T - 16 Formulario para buscar grupos.




4.4.2. DISEÑO

CREAR GRUPO: El formulario para crear un nuevo grupo, contiene tres

campos. El nombre del grupo y la etiqueta son obligatorios, mientras que la

descripción es un campo opcional.


Nombre: Crear nuevo grupo

Descripción: Los usuarios podrán crear un nuevo grupo.

Precondiciones: N/A

Escenario básico: 1 Introducir nombre del grupo.

2 Comprobar si el nombre es válido

3 Introducir etiqueta del grupo.

4 Comprobar si la etiqueta es válida.

5 Introducir datos opcionales.

6 Crear grupo.


2.A ¿Nombre válido?

2.A.1 Sí, ir a paso 3.

2.A.2 No, volver al paso 1.

4.A ¿Etiqueta válida?

4.A.1 Si, ir al paso 5.

4.A.2 No, volver al paso 3.

5.A ¿Introducida descripción?

5.A.1 Si, ¿Descripción correcta?

5.A.1.1 Si, ir a paso 6.

5.A.1.2 No, ir al paso 6.

5.A.2 No, ir al paso 6.

Postcondiciones: Se crea un nuevo grupo. Tabla 4.20. Caso de uso CU-12.

A continuación, se muestra el diagrama de casos de uso asociado a la Tabla 4.20.




MODIFICAR GRUPOS: El formulario para editar un grupo tiene los mismos

campos que el formulario de creación.


Nombre: Modificar datos de grupo

Descripción: Permite modificar los datos de los grupos

Precondiciones: Hay que ser propietario del grupo.

Escenario básico:

1 Introducir datos opcionales.

2 Actualizar grupo.


1.A ¿Cambiar nombre?

1.A.1 Si, ¿Nombre válido?

1.A.1.1 Si, ir al paso 1. B

1.A.1.2 No, volver al paso 1. A

1.A.2 No, ir al paso 1. B

1.B ¿Cambiar etiqueta?

1.B.1 Si, ¿Etiqueta válida?

1.B.1.1 Si, ir al paso 1.C

1.B.1.2 No, volver al paso 1. B

1.B.2 No, ir al paso 1.C

1.C ¿Cambiar descripción?

1.C.1 Si, ¿Descripción valida?

1.C.1.1 Si, ir al paso 2.

1.C.1.2 No, volver al paso 1.C

1.C.2 No, ir al paso 2.

Postcondiciones: Los datos del grupo se actualizan. Tabla 4.21. Caso de uso CU-13.





ELIMINAR GRUPOS: Solo podrá eliminar un grupo el usuario propietario de

dicho grupo. Para eliminarlo, debemos de entrar dentro del grupo, y abrir el menú de

configuración (botón en forma de engranaje), de las opciones del menú, pulsar sobre

“ELIMINAR GRUPO”.


Nombre: Eliminar grupo


Precondiciones: Hay que ser el propietario del grupo.

Escenario básico:

1. Entrar en la pantalla de grupos. 2. Comprobar que existen grupos. 3. Buscar el grupo que se desea eliminar. 4. Comprobar que el usuario es el propietario del

grupo. 5. Eliminar.


2.A – ¿Hay grupos? 2.A.1 – Si, ir al paso 3. 2.A.2 – No, cancelar y salir. 4.A – ¿El usuario es propietario del grupo? 4.A.1 – Si, ir al paso 5. 4.A.2 – No, cancelar y salir.

Postcondiciones: Los datos del grupo se actualizan. Tabla 4.22. Caso de uso CU-14.





MOSTRAR LISTA DE GRUPOS: En esta vista se muestra un listado con todos

los grupos. Cada grupo deberá de mostrar un nombre que lo identifique, una breve

descripción y debe de estar acompaño por un botón que permita suscribirse o darse

de baja del grupo.

ACCEDER A UN GRUPO: En primer lugar, para acceder a cualquier grupo,

hay que ser miembro. Para poder entrar dentro del grupo, podemos hacerlo de

varias formas, desde el menú de grupos pulsando sobre la etiqueta de un mensaje,

o si sabemos el nombre o la etiqueta, podemos escribirlo en el buscador.


Nombre: Acceder a un grupo

Descripción: Los usuarios pueden leer los perfiles de otros usuarios del sistema.

Precondiciones: Debe de existir el grupo.

Escenario básico:

1. Introducir datos. 2. El sistema comprueba los datos. 3. Entrar al perfil.


2.A ¿Datos válidos? 2.A.1 Si, ir al paso 3. 2.A.2 No, cancelar operación y salir.

Postcondiciones: Se muestra los datos del perfil del usuario. Tabla 4.23. Caso de uso CU-15.





Lo siguiente es realizar el diseño de la base de datos, como estamos antes una

nueva instancia, pasamos a crear una tabla “Groups”, esta tabla tendrá los

siguientes atributos:

Id_group (integer): Llave primaria de la tabla de grupos.

User_admin (integer): Llave foránea a la tabla usuarios.

Nombre (varchar): Cadena de texto con una longitud de 100 caracteres.

o No puede ser nulo

o No puede estar repetido

Hashtag (varchar): Cadena de texto con una longitud máxima de 50

caracteres.

o No puede ser nulo.

o No puede estar repetido.

Description (Text): Longitud máxima 255 caracteres.

Created_at (datetime): Representa la fecha de creación de un grupo.

Update_at (datetime): Representa la fecha de actualización de un

grupo.

La tabla de grupos además la podemos relacionar con los mensajes, un

mensaje se puede publicar en muchos grupos, y un grupo contiene a muchos

mensajes, por lo tanto, tenemos otra relación de MUCHOS A MUCHOS. Para evitar

la relación se crea una tabla intermedia “TAGS” y pasando a tener relaciones de

UNO A MUCHOS.

Figura 4.37. Diseño de la base de datos.




CREAR GRUPOS: Para guardar la información de los grupos vamos a

necesitar de un nuevo modelo de datos, que llamaremos “Group”, dentro del modelo

se deberá llevar a cabo las validaciones oportunas evitar tener información errónea.

También hay que crear un nuevo controlador, al cual llamaremos

“Group_controller”, que gestionará las respuestas a las peticiones del usuario.

Empezamos respondiendo a las peticiones de “New” y “Create”

Por último, hay que realizar la vista, la cual se mostrará con un modal. El

formulario lo compone dos cajas de texto para introducir el nombre del grupo y la

etiqueta y un tercer campo del tipo TextArea para la descripción del grupo.

Figura 4.38. Vista del formulario para crear un nuevo grupo.

MODIFICAR GRUPOS: La vista para modificar un grupo consiste nuevamente

en un formulario con los mismos campos que el formulario de creación, es decir,

podemos cambiar el nombre, la etiqueta o incluso la descripción del grupo, siempre

y cuando los nuevos datos sean válidos.

Para abrir este formulario, deberemos de estar dentro del grupo, pulsar en el

menú de configuración y pulsar en “Editar grupo”. Sin embargo, para que la vista sea

accesible por los usuarios, hay que habilitar nuevas rutas y añadir al controlador

acciones de “EDIT” y “UPDATE”.



ELIMINAR GRUPOS: Esta vista solo se muestra al propietario del grupo. Para

eliminar un grupo, debemos de entrar al grupo, abrir el menú de configuración y

pulsar en “Eliminar grupo”, tal y como se muestra en la Figura 4.39. Para que

funcione la acción de eliminar, hay que añadir al controlador la función de “DELETE”.

Figura 4.39. Vista del menú de configuración de un grupo.

BUSCADOR DE GRUPOS: Como ya hemos desarrollado un buscador para los

usuarios, solo tenemos que modificarlos para que también realice búsquedas de

grupos.

Lo primero y más importante, es que para que podamos listar los grupos,

debemos de tenerlo en un JSON, de esta forma, cuando un usuario meta un nombre

o la etiqueta de un grupo en el buscador, se pasa la petición al controlador que

buscará las coincidencias entre los los grupos del JSON y el valor del buscador. Los

resultados obtenidos deberán ser mostrados mediante AJAX en el buscador y el

usuario deberá seleccionar un resultado.

Figura 4.40. Buscador de grupos.



4.4.4. PRUEBAS

Empezamos con las pruebas de unidad, en este sprint hay que verificar que un

usuario puede crear, modificar y eliminar grupos, además el propietario del grupo

podrá añadir o eliminar miembros.

TEST#CREAR_GRUPO: Este test nos permite comprobar que se puede

crear grupos sin que ocurra ningún error. Para ello, hay que introducir todos

los campos obligatorios.

TEST#EDITAR_DATOS: Para superar este test, debemos cambiar los datos

de un grupo, y comprobar que los datos se modifican correctamente.

TEST#ELIMINAR_GRUPO: Este test, debe de comprobar que, al eliminar un

grupo, sus datos se borran del sistema.

Para no tener información errónea en la base de datos, vamos a necesitar

validar los datos, lo podemos hacer de dos formas, la primera, es mediante un test

general de validación: TEST#VALIDAR_GRUPO, el problema de este test es que si

falla no sabemos en qué punto ha fallado, por eso hemos realizado otros test:

TEST#NOMBRE_NO_NULO: Con este test evitamos guardar un grupo sin

nombre.

TEST#LONGITUD_NOMBRE: Evitar nombres demasiados grandes.

TEST#ETIQUETA_NO_NULA: Evitar guardar grupos sin etiquetas

TEST#LONGITUD_ETIQUETA: Nos garantiza que la etiqueta del grupo no

supera el máximo de caracteres permitidos.

TEST#DESCRIPCIÓN_VALIDA: Aunque la descripción es optativa, debemos

garantizar que no supera los 255 caracteres.


Como vemos en la figura 2.4. de los 7 test, los 7 se han completado correctamente.



4.5. SPRINT 5

Con el Sprint 5 finaliza el proceso de desarrollo, y se estimó en el capítulo 3,

que iba a empezar el día 28 de diciembre del 2015 y que el día 22 de enero sería la

fecha en la que estaría terminado el proyecto, volviendo a tener unas 4 semanas

para terminar esta iteración.

Como en todas las anteriores iteraciones, este sprint lo iniciamos con una fase

de planificación en la vamos a seleccionar las ultimas historias de usuario, luego s

diseñará la solución al problema, y para terminar se pasa la fase de desarrollo y

pruebas para comprobar que todo lo anterior se ha realizado correctamente.


Realmente en este sprint no existe una planificación como en los anteriores

Sprints, esto se debe a que, ya que no tenemos historias de usuarios para decidir, y

por lo tanto hay que seleccionar las últimas que nos quedan:


HU-22 Como usuario registrado, quiero subscribirme a un grupo.

2

HU-23 Como usuario, quiero ver los miembros de un grupo. 1

HU-24 Como miembro de un grupo, quiero ver los mensajes del grupo en el timeline personal.

2

HU-25 Como miembro de un grupo, quiero cancelar la subscripción para dejar de recibir novedades de este grupo.

0

HU-26 Como propietario de un grupo, quiero añadir miembros al grupo.

2

HU-27 Como propietario de un grupo, quiero eliminar miembros del grupo.

0


Como vemos la velocidad baja a tan solo 6 puntos, lo que es entendible, ya

que no nos quedan más historias de usuario por realizar.



Como podemos ver en la Tabla 2.3. se ha añadido nuevas historias de usuario,

que en un principio no se contemplaban. Estas nuevas historias de usuario, surgen

de una reunión con el tutor, y en la que se decide que las suscripciones de usuarios

a un grupo deben de hacerse de forma automática.

Con las nuevas historias de usuario, un usuario puede suscribirse a un grupo

de forma manual, aunque también puede ser un profesor o administrador, que lo de

alta a dicho grupo.

De la tabla 2.3. podemos extraer las siguientes tareas:

Historia de usuario



HU-22 T - 01 Crear modelo “Memberships”.

HU-22 T - 02 Crear controlador “Memberships_controller”.

HU-22 T - 03 Hacer el formulario de suscripción.

HU-22 T - 04 Comprobar que un usuario se puede suscribir a un grupo.

HU-23 T - 05 Hacer la vista para ver los miembros de un grupo.

HU-23 T - 06 Actualizar la función del timeline.

HU-25 T - 07 Hacer el formulario para darse de baja.

HU-25 T - 08 Comprobar que un usuario se puede dar de baja.

HU-26 T - 09 Vista para añadir miembros al grupo.

HU-26 T - 10 Comprobar que el propietario de un grupo puede añadir miembros.

HU-27 T - 11 Vista para eliminar miembros del grupo.

HU-27 T - 12 Comprobar que el propietario de un grupo puede eliminar miembros.




4.5.2. DISEÑO

SUSCRIPCIÓN: En primer lugar, debemos de acceder a la lista de grupos, se

busca un grupo, y junto al nombre de dicho grupo, se mostrará la acción para

suscribirse.


Nombre: Suscribirse a grupos

Descripción: Proceso para suscribirse a un grupo.

Precondiciones: N/A

Escenario básico:

1. El sistema muestra el listado de grupos. 2. Seleccionar un grupo. 3. Suscribirse


1.A ¿Hay grupos? 1.A.1 Si, Ir al paso 2 1.A.2 No, cancelar y salir.

Postcondiciones: El usuario es miembro del grupo. Tabla 4.26. Caso de uso CU-16.

BAJA DE UN GRUPO: Se proceso es similar al de suscribirse a un grupo, se

accede en un primer lugar al listado con todos los grupos, y buscamos un grupo, en

un lateral del nombre del grupo, se mostraeá la acción para darse de baja.


Nombre: Baja de un grupo

Descripción: Proceso para darse de baja de un grupo.

Precondiciones: Hay que estar suscrito al grupo.

Escenario básico:

1. El sistema muestra el listado de grupos. 2. Seleccionar un grupo. 3. Darse de baja


1.A ¿Hay grupos? 1.A.1 Si, Ir al paso 2 1.A.2 No, cancelar y salir.

Postcondiciones: El usuario dejará de ser miembro del grupo. Tabla 4.27. Caso de uso CU-17.

MENSAJES DEL GRUPOS EN EL TIMELINE: Como ya hicimos con los

usuarios en el sprint 3, hay que buscar todos los grupos que estamos suscritos y

seleccionar todos los mensajes, que se añadirán a la lista de los mensajes de los

seguidores y los mensajes propios.



VER MIEMBROS DEL GRUPO: Para poder ver que usuarios son miembros

del grupo, necesiamente hay que ser miembro de ese grupo. Cuando pasemos a ser

miembro de un grupo, podemos acceder dentro del propio grupo y en la información

resumen del grupo, se muestra la cantidad de miembros que tiene tiene el grupo, si

pulsamos sobre el número, se nos mostrará otra vista con más detalles de los

miembros.

AÑADIR MIEMBRO: Esta acción solo la puede realizar el propietario del grupo.

En la vista para añadir miembros, para que nos sea más sencillo encontrar usuarios,

tenemos un buscador de usuarios, más abajo se nos muestra un listado con los

usuarios que coincide con la búsqueda, en el caso que exista más de 5

coincidencias, se listará de 5 en 5, mediante paginación.


Nombre: Gestionar miembros

Descripción: Proceso para la gestión de un grupo.

Precondiciones: Ser propietario del grupo.

Escenario básico:

1. Buscar un usuario. 2. Comprobar usuario. 3. Añadir


2.A ¿El usuario existe? 2.A.1 Si, Ir al paso 3 2.A.2 No, cancelar y salir.

Postcondiciones: Hay un miembro más en el grupo Tabla 4.28. Caso de uso CU-18.

ELIMINAR MIEMBRO: El proceso para echar un usuario de un grupo, es

similar al proceso de añadir un usuario, salvo que junto al listado de usuarios el

botón que se muestra es el de “Eliminar usuario”.


Nombre: Gestionar miembros


Precondiciones: Ser propietario del grupo.

Escenario básico:

1. Buscar un usuario. 2. Comprobar usuario. 3. Eliminar


2.A ¿El usuario existe? 2.A.1 Si, Ir al paso 3 2.A.2 No, cancelar y salir.

Postcondiciones: Hay un miembro menos en el grupo. Tabla 4.29. Caso de uso CU-19.



En segundo lugar, pasamos al diseño de la base de datos, y como según el

diseño un usuario puede suscribirse a muchos grupos, y además un grupo tiene a

muchos usuarios, vamos a necesitar de una tabla intermedia que evite la relación de

MUCHOS A MUCHOS, llamaremos a esta tabla “Memberships”, que estará formada

por los siguientes atributos:

Id_memberships (integer): Llave primaria para identificar la suscripción.

Id_user (integer): Llave foránea, que hace referencia a la tabla de

usuarios.

Id_group (integer): Llave foránea, que hace referencia a la tabla de

grupos.

Created_at (datetime): Representa la fecha de creación de una

suscripción.

Update_at (datetime): Representa la fecha de actualización de una

suscripción.

Figura 4.42. Diseño de la base de datos.

Aparte de la relación de muchos a muchos, podemos observar otra relación, y

es que un grupo, debe de tener un propietario, esta es una relación de UNO A

MUCHOS, por la que cualquier usuario puede ser propietario de muchos grupos.




SUSCRIPCIÓN: Para almacenar la información de las suscripciones hay que

crear un nuevo modelo “Memberships” como tabla intermedia entre usuarios y

grupos, en segundo lugar, tenemos que realizar un controlador para que responda a

las peticiones para crear una nueva suscripción.

La vista para suscribirse consiste en una vista parcial “_SUSCRIBE.html.erb”

formada por un único botón, que, al pulsarlo, se comunicará con el controlador para

crear un nuevo registro en la base de datos.

DARSE DE BAJA: En el controlador debemos de añadir las acciones para que

pueda responder a las peticiones de “DELETE”, y en cuanto a la vista es similar a la

vista de suscribirse, consiste en otra vista parcial “_UNSUSCRIBE.html.erb”,

formada por un botón, pero con el texto para darse de baja. Al pulsar el botón se

comunicará con el controlador y borrará los registros en la base de datos.

Cuando nos suscribimos a un grupo, se habilita el grupo y se nos autoriza el

acceso, y al darse de baja perdemos el acceso al grupo (Figura 4.43).

Figura 4.43. Vista con el listado de los grupos.



AÑADIR MIEMBROS: La gestión de los miembros de un grupo, es una tarea

que le corresponde exclusivamente al propietario del grupo. En la vista para

gestionar a los miembros encontramos en primer lugar un buscador para encontrar

usuarios, este buscador utiliza JavaScript y AJAX para actualizar la lista que se

encuentra más abajo.

Figura 4.44. Buscador para gestionar los miembros de un grupo.

En la lista se muestran los usuarios que coinciden con el resultado de la

búsqueda, si hubiera más de cinco resultados, se listan los usuarios de 5 en 5

mediante páginas (página 1, página 2, etc.)

Figura 4.45. Vista de la lista de usuario desde la gestión de grupos.

MIEMBROS DEL GRUPO: Esta vista muestra todos los usuarios de un grupo,

recibimos una lista de usuarios por parámetro, y la recorremos para mostrar los

datos de cada usuario. Los usuarios se agrupan en columnas.

AÑADIR LOS MENSAJES DE GRUPOS AL TIMELINE: Como ya hicimos en

la iteración 3, tenemos que unir los mensajes del actual timeline, con los mensajes

de los grupos a los que estamos suscritos.



4.5.4. PRUEBAS

Para la última fase del sprint, pasamos a la definición y ejecución de las

pruebas de unidad.

Debemos de probar principalmente que funciona correctamente los

mecanismos para suscribirse y darse de baja de los grupos, además los usuarios

con los permisos adecuados, podrán añadir o eliminar miembros.

TEST#SUSCRIPCIÓN: Con este test comprobamos que cualquier

usuario se puede suscribir a un grupo y que sus datos se salvan en la

base de datos.

TEST#GESTIÓN_DE_MIEMBROS: Con este test se garantiza que solo

los propietarios de grupos podrán añadir o eliminar usuarios.

TEST#AUTORIZACIÓN: Hay que comprobar que solo los usuarios que

están suscritos a los grupos pueden leer los mensajes.

TEST#BAJA DEL GRUPO: Nos permite comprobar que se puede

romper una relación con el grupo, y sus registros serán borrados de la

base de datos.

Como este es el último sprint vamos a ejecutar todos los test para comprobar

que todo se ha hecho de manera correcta.


Como vemos en la Figura 4.46. todas las pruebas se pasan con éxito



El Burndown char o gráfico de trabajo pendiente sirve para saber el tiempo

que falta para completar el trabajo y ver si acabaremos el proyecto a tiempo. Nos

muestra la velocidad a la que se van completando los objetivos.

El eje X, representa el tiempo en días de duración del sprint, y en el eje Y la

cantidad de trabajo que nos comprometemos con el cliente durante un sprint.

Figura 4.47. Gráfica Burndown.

Como podemos ver en la Figura 4.47. en todas las iteraciones se ha cumplido

el con el trabajo estimado, e incluso se ha realizado algunos puntos de historias

más. Este hecho es debido a que en las primeras iteraciones que se han realizado

tareas más sencillas, y eso no daba libertad para avanzar más rápido.

La velocidad ha ido subiendo durante los dos primeros Sprints y a partir de la

tercera cae ligeramente, puesto que va quedando menos tareas para finalizar y son

tareas más complejas.



Finalmente, el diseño final de la base de datos queda de la siguiente manera:

Figura 4.48. Base de datos final.

R1: Consiste en una relación de 1/N, por la que un usuario puede seguir a

uno o varios usuarios a través de relaciones.

R2: Consiste en una relación de 1/N, por la que un usuario puede ser seguido

por uno o varios usuarios.

R3: Relación de 1/N, en la que un usuario puede tener muchas suscripciones.

R4: Relación de 1/1, por la que usuario es el propietario de un grupo.

R5: Relación de 1/N, en la que un usuario puede escribir uno o varios

mensajes.

R6: Relación de 1/N, por la que un usuario puede difundir uno o más

mensajes.

R7: Relación de 1/N, en la que un mensaje puede ser difundido en una o más

ocasiones.

R8: Relación de 1/N, en la que un mensaje puede ser publicado en uno o más

grupos.

R9: Relación 1/N, por la que un grupo puede tener uno o más miembros.

R10: Relación de 1/N, en la que a través de un grupo podemos identificar

todos los mensajes del grupo.



5. DESPLIEGE

En este capítulo vamos a seleccionar una plataforma para subir nuestra

aplicación y mantenerla online. Para poder seleccionar una, se realiza un estudio de

las diferentes Platform as a Service (PaaS) que podemos encontrar en la actualidad.

5.1. ANÁLISIS DE LOS SISTEMAS PAAS

AWS: Amazon web services (AWS) es un conjunto de servicios orientados al

cloud computing, siendo los más conocidos S3 y EC2. El primero de ellos Simple

Storage Service (S3), es un servicio de almacenamiento remoto que permite a los

desarrolladores almacenar información ilimitada y poder consultarla cuando lo

deseen. Elastic Cloud Computing (EC2), nos permite crear máquinas virtuales de

manera sencilla para que podamos montar cualquier estructura en la nube sin

necesidad de utilizar ningún servicio físico. Estos servicios son ofrecidos a través de

Amazon.com. Está considerada pionera en este campo y compite actualmente con

otros servicios que veremos a continuación.

AZURE: Microsoft Azure (anteriormente llamado Windows Azure y Azure

Services Platform) es una plataforma ofrecida como servicio y alojada en los Data

Centers de Microsoft. Windows Azure es una plataforma general que tiene diferentes

servicios para aplicaciones, desde servicios que alojan aplicaciones en algunos de

los centros de procesamiento de datos de Microsoft (Cloud Computing) hasta

servicios de comunicación segura.

Dentro de la plataforma, el servicio de Windows Azure es el encargado de

proporcionar el alojamiento de las aplicaciones y el almacenamiento no relacional.

Dichas aplicaciones deben de funcionar sobre Windows Server 2008 R2 y pueden

estar desarrolladas en .NET, PHP, C++, Ruby, Java.

GOOGLE APP ENGINE: Es un servicio de alojamiento web que presta google

de manera gratuita hasta determinadas cuotas. Este servicio nos permite ejecutar

nuestras aplicaciones sobre la infraestructura de google. Las cuentas gratuitas

tienen un limite de 500 megabyte de almacenamiento y un ancho de banda y CPU

para cinco millones de visitas mensuales. Los lenguajes que acepta son: Python,

Java, GO y PHP.



OPENSHIFT: Producto de computación en la nube, desarrollado por Red Hat.

Lo que hace interesante este servicio es que es de código abierto y lo podemos

encontrar en GitHub bajo el nombre de “OpenShift Origin”. Los usuarios pueden

desplegar sus aplicaciones utilizando Git.

HEROKU: Heroku, es una de las primeras plataformas de computación en la

nube, fue desarrollada con el objetivo de soportar solamente el lenguaje de

programación Ruby, pero posteriormente se ha extendido el soporte a Java,

Node.JS, Scala, Clojure, PHP y Python. La base sobre la que está la plataforma es

un sistema operativo con Debian.

Finalmente se ha decido utilizar Heroku por su simplicidad y facilidad para subir

nuestra aplicación, además de poder usarlo de manera gratuita. En el Anexo B, se

explica el proceso de instalación en Heroku.



6. CONCLUSIONES

En este capítulo, se exponen las conclusiones que se han obtenido tras

finalizar el proyecto:

En primer lugar, la experiencia de haber desarrollado un proyecto con

unas tecnologías que no había usado anteriormente, y el haber

aprendido a cómo gestionar y dirigir un proyecto con la metodología de

SCRUM.

En segundo lugar, una gran satisfacción personal al ver que se han

cumplido los objetivos que se pusieron en el inicio del proyecto, y ver

que este proyecto podrá ser usado por compañeros y profesores de la

Universidad de Jaén.

En cuanto a las dificultades que han surgido en este proyecto han sido pocas,

principalmente ha sido el tiempo, ya que era necesario dedicar una parte del tiempo

en aprender una nueva tecnología y una mala planificación inicial causo el retraso

del proyecto durante algunos meses.

6.1. PROPUESTAS PARA EL FUTURO

Durante el desarrollo de este proyecto, han surgido algunas ideas para mejorar

la aplicación en las siguientes versiones, a continuación, se listan algunas de ellas:

Una de las cosas en la que se ha trabajado en esta versión, pero no se

ha implementado por tiempo, es la posibilidad de añadir sockets a la

aplicación, para que el envío y recepción de mensajes sea en tiempo

real.

Otra línea de trabajo futuro, puede ser el desarrollar aplicaciones

nativas para IOS y Android ayudándose de la API creada en este

proyecto.

También cabe la posibilidad de colaborar con el proyecto, traduciendo la

aplicación a otros idiomas, en esto puede participar cualquier miembro

de la comunidad universitaria, ya que no requiere de conocimientos

técnicos.



7. ANEXO A: MANUAL DE USUARIO

Mediante este anexo se pretende explicar el funcionamiento de la aplicación

web.

7.1. ACCESO A LA APLICACIÓN WEB

La demo del proyecto está alojada en la PaaS de Heroku. Para acceder a la

aplicación debemos acceder desde la siguiente url:

http://microblog-uja.herokuapp.com/

Figura 7.1. Pantalla con el formulario para iniciar sesión.

Cuando un usuario entra en la aplicación, el sistema nos redirigirá

automáticamente a la pantalla para Iniciar Sesión (Figura 7.1). En esta pantalla

tenemos dos opciones, la primera es realizar un registro si es la primera vez que

entramos a la aplicación, o bien, iniciar sesión introduciendo el correo electrónico y

la contraseña si ya contamos con una cuenta creada anteriormente.

Si iniciamos sesión, el sistema verifica los permisos y nos redirige a la pantalla

principal

http://microblog-uja.herokuapp.com/



7.2. REGISTRO

Para que un usuario pueda tener acceso al resto de la aplicación es necesario

registrarse. En la parte central de la pantalla de registro se nos muestra el formulario

que hay que rellenar para darnos de alta en la aplicación.

Figura 7.2. Pantalla con el formulario para registrarse.

Al crear la cuenta, se nos redirige automáticamente a la pantalla principal de la

aplicación.

7.3. PANTALLA PRINCIPAL (HOME)

La pantalla está dividida en tres categorías principales, dos categorías en el

lateral izquierdo y otra categoría en la parte central. Por el lateral izquierdo, tenemos

información de nuestra cuenta a modo de resumen (número de mensajes,

seguidores, y usuarios a los que sigue). La otra categoría en el lateral, es un listado

con los grupos que está suscriptos el usuario. En la parte central de la pantalla se

nos muestra una línea del tiempo, en la que se muestra los mensajes de los

usuarios.

Figura 7.3. Pantalla principal de la aplicación.



7.4. MODIFICAR PERFIL

Para modificar los datos de una cuenta tenemos que entrar al perfil del usuario,

y para ello tenemos dos opciones, la primera solo se muestra desde la pantalla

principal, en la sección en donde se muestra la información del usuario. Dentro de

esta sección tenemos que abrir el menú de configuración (icono del engranaje) y

pulsar sobre “Editar cuenta”. La segunda opción está visible en todas las pantallas

de la aplicación, ya que se incluye en el Header. Consiste en un menú de usuario,

que, al abrirlo, se nos mostrará la opción para ir a nuestra cuenta (Figura 7.4).

Figura 7.4. Editar perfil desde el menú de usuario.

La pantalla para editar la cuenta, está compuesta por dos secciones, en el

lateral izquierdo se encuentra el propio formulario para editar los datos, y en la zona

central todos los mensajes que ha escrito el usuario (Figura 7.5).

Figura 7.5. Formulario para editar usuario.



7.5. ELIMINAR PERFIL

En la pantalla del perfil del usuario, tenemos una tercera sección que se

muestra en la parte inferior izquierda, justo cuando termina la sección de editar la

cuenta. Esta sección es muy simple, tan solo muestra un botón rojo que solo se

deberá pulsar cuando se quiere eliminar el perfil. Al pulsar el botón se mostrará un

mensaje de alerta y pulsaremos en el botón de aceptar (Figura 7.6). Tras borrar la

cuenta el sistema nos sacará de la aplicación y ya no tendremos autorización para

entrar.

Figura 7.6. Darse de baja desde el perfil de usuario.

7.6. CERRAR SESIÓN

Para cerrar la sesión abrimos el menú de usuario y seleccionamos la opción de

“Salir”.

Figura 7.7. Cerrar la sesión desde el menú de usuario.



7.7. ESCRIBIR MENSAJES

Para escribir un mensaje, debemos de pulsar el botón “Nuevo Mensaje” que

se encuentra en la parte superior de la pantalla, en la sección del Header, al pulsar

el botón se nos abrirá un modal para escribir el contenido del mensaje (Figura 7.8).

Cuando terminemos de escribirlo, pulsamos el botón de “Enviar” y se publicará el

mensaje en la aplicación.

Figura 7.8. Publicar un nuevo mensaje.

7.8. RESPONDER/DIFUNDIR/ELIMINAR MENSAJES

En la sección en donde se muestra la línea del tiempo con los mensajes,

podemos realizar varias acciones. Todos los usuarios pueden responder a un

mensaje, pulsando en “Responder” o bien, pueden darle mayor difusión pulsando

sobre “Difundir”. También se puede eliminar un mensaje pulsando en “Eliminar”

(Figura 7.9).

Figura 7.9. Acciones en los mensajes.



7.9. SEGUIR A USUARIOS

Para seguir a otro usuario, debemos de entrar en su perfil, y en la sección en

donde se muestra la información del usuario, tenemos que pulsar sobre el botón que

pone “Seguir” (Figura 7.10).

Figura 7.10. Seguir a otros usuarios desde el perfil del usuario.

7.10. DEJAR DE SEGUIR A USUARIOS

Para dejar de seguir a otro usuario, debemos de entrar en su perfil, y en la

sección en donde se muestra la información del usuario, hay que pulsar sobre el

botón rojo que pone “Dejar de seguir” (Figura 7.11).

Figura 7.11. Dejar de seguir usuarios desde el perfil del usuario.



7.11. CREAR GRUPOS

Para crear un nuevo grupo, debemos de entrar a la pantalla de grupos. En esta

pantalla se nos muestra en la parte central un listado con todos los grupos de la

aplicación. Si queremos crear un nuevo grupo, en la parte superior de esta sección,

debemos de pulsar sobre el botón verde “Nuevo Grupo” (Figura 7.12).

Figura 7.12. Pantalla para crear un nuevo grupo.

Al pulsar sobre el botón para crear un nuevo grupo, se abre un modal con un

formulario que debemos de rellenar con los datos del grupo. Al terminar con el

formulario debemos de pulsar en “Enviar”.

Figura 7.13. Formulario de creación de grupos.



7.12. MODIFICAR GRUPOS

Para modificar los datos del grupo, el propietario tiene que entrar al grupo y

desde el menú de configuración, pulsar en “Editar grupo” (Figura 7.14). Cuando

pulsemos se mostrará un modal con el formulario para editar el grupo. Al acabar la

edición, pulsamos sobre “Enviar”.

Figura 7.14. Formulario para editar un grupo.

7.13. ELIMINAR GRUPOS

Para eliminar un grupo, el propietario deberá de abrir el menú de configuración

y pulsar sobre “Eliminar grupo”.

Figura 7.15. Eliminar un grupo desde el menú de configuración.



7.14. SUSCRIBIRSE A GRUPOS

Para suscribirse a un grupo, debemos de entrar en la pantalla de grupos, y en

el listado que se nos muestra en la parte central, seleccionar el grupo y pulsar el

botón de “Suscribirse”.

Figura 7.16. Suscribirse a un grupo.

7.15. DARSE DE BAJA DE GRUPOS

Para darse de baja de un grupo, hay que entrar en la pantalla de grupos, y

pulsar sobre el botón rojo “Darse de baja” del grupo al que queremos darnos de

baja.

Figura 7.17. Darse de baja de un grupo.



7.16. GESTIONAR MIEMBROS DE UN GRUPO

Para gestionar miembros de un grupo, el propietario deberá de pulsar en

“Gestión de miembros” del menú de configuración, de este modo entramos en la

pantalla para gestionar a los miembros de un grupo.

Figura 7.18. Gestionar miembros del menú de configuración.

En la pantalla para la gestión de miembros se nos muestra un listado con todos

los usuarios de la aplicación, junto con un buscador y unos índices de páginas en la

parte inferior (Figura 7.19). Para añadir/eliminar un nuevo usuario, debemos de

buscarlo ya sea mediante el buscador, escribiendo su usuario, o bien buscando

entre las páginas de usuarios. Cuando encontremos al usuario, debemos de pulsar

el botón de “Suscribirse” o “Darse de baja” que se mostrará junto al nombre.

Figura 7.19. Pantalla para la gestión de miembros.



8. ANEXO B: MANUAL DE INSTALACIÓN

En este anexo se procede a explicar el contenido del CD que viene adjunto con

el proyecto. Además, se va a detallar los pasos necesarios para su instalación en

una máquina en local y cómo realizar el despliegue para publicarlo en Heroku.

8.1. CONTENIDO DEL CD

Dentro del CD vamos a encontrar lo siguiente:

Directorio “Documentación”

o Memoria.pdf

o Base de datos: Directorio que incluye los esquemas de la base

de datos.

o Diagramas de casos de uso: Este directorio incluye los

diagramas de caso de uso.

o Pantallas: Incluye todas las pantallas mostradas en la

documentación.

Directorio “Microblogging”: Es el directorio de la aplicación web, dentro

se encuentra todos los directorios y ficheros que genera rails.

o app/: Contiene los controllers, models, views, helpers y assets de

la aplicación.

o config/

initializers

locales

routes.rb

o db/: Contiene el esquema actual de la base de datos, así como

las migraciones de la base de datos.

o public/: Contiene los archivos estáticos y assets compilados.

o test/: Directorio donde se almacenan las pruebas unitarias,

fixtures y otras pruebas

o tmp/: Archivos temporales (cache, archivos de sesión, etc.)

o vendor/: Directorio para incluir el código de terceros.



8.2. INSTALACIÓN EN LOCAL

Para poder iniciar la aplicación en una maquina local vamos a necesitar instalar

Ruby, junto con la gema de Rails. Para la instalación de Ruby, los usuarios de Unix

lo pueden descargar mediante un gestor de paquetes y los usuarios de Windows

pueden bajarse un instalador desde el siguiente enlace:

http://railsinstaller.org/en

Con Ruby instalado, nos dirigimos a la carpeta de “Microblogging”, y

ejecutamos un “bundle install” para instalar todas las dependencias que necesita la

aplicación, entre las que se incluye Rails (Figura 8.1). Este proceso puede tardar

varios minutos en donde se descargará todas las dependencias del proyecto.

Figura 8.1. Descargando dependencias de la aplicación.

Por último, solo nos queda lanzar el servidor, para ello escribimos “rails s” y

opcionalmente podemos pasarle el argumento –b para indicarle la dirección IP en

donde queremos crear el servidor (Figura 8.2).

Figura 8.2. Iniciando servidor de rails en local.

Con esto ya está el servidor activo, sin embargo, vamos a necesitar de una

base de datos, para este proceso vamos a usar MySQL, y para cargar el esquema

http://railsinstaller.org/en



en la base de datos, tan solo debemos de escribir “rake db:drop db:create

db:migrate”, que realmente lo que hace, es asegurase que las tablas están

eliminadas, luego vuelve a crear las tablas e inserta los datos (Figura 8.3).

Figura 8.3. Reseteando la base de datos.

8.3. INSTALACIÓN EN EL PAAS DE HEROKU

Para facilitar el despliegue del proyecto, se va a utilizar Heroku como PaaS,

una potente plataforma de despliegue continuo. Para usar Heroku, vamos a

necesitar crearnos una cuenta, que podemos hacerla desde su página web oficial:

https://www.heroku.com

Con la cuenta ya creada, al iniciar sesión se nos mostrará el Dasdboard, en

donde podemos crear una nueva aplicación e incluso leer las guías de iniciación de

algunas tecnologías (Figura 8.4).

Figura 8.4. Dasdboard Heroku

https://www.heroku.com/



Al crear una aplicación, nos pedirá el nombre y la región en la que vamos a

publicarla (Figura 8.5)

Figura 8.5. Pantalla de creación de una aplicación en Heroku.

Para poder acceder a esta aplicación desde nuestra maquina, podemos

acceder desde la terminal o bajando la herramienta “Heroku toolbelt”:

https://toolbelt.heroku.com/

Por último, nos quedará configurar el repositorio de git, para que al hacer el

push, se suba a nuestra aplicación de heroku.

Figura 8.6. Configuración del repositorio para Heroku.

https://toolbelt.heroku.com/



9. REFERENCIAS Y BIBLIOGRAFÍA

Alvarez, M. A. (19 de Septiembre de 2012). Manual de jQuery. Recuperado el 25 de

Septiembre de 2015, de Desarrolloweb:

http://www.desarrolloweb.com/manuales/manual-jquery.html

andrearrs. (29 de Mayo de 2014). XML JSON YAML: Formatos para intercambiar

información. Recuperado el 15 de Noviembre de 2015, de hipertextual:

http://hipertextual.com/archivo/2014/05/xml-json-yaml/

Anónimo. (7 de octubre de 2015). Amazon Web Services. Recuperado el 10 de Diciembre

de 2015, de Wikipedia: https://es.wikipedia.org/wiki/Amazon_Web_Services

Dmolanor. (10 de Septiembre de 2015). Hoja de estilos en cascada. Recuperado el 3 de

Octubre de 2015, de Wikipedia:

https://es.wikipedia.org/wiki/Hoja_de_estilos_en_cascada

Eguiluz, J. (2015). Introducción a CSS. Recuperado el 3 de Octubre de 2015, de LibrosWeb:

https://librosweb.es/libro/css/

Eguiluz, J. (11 de Septiembre de 2015). Introducción a JavaScript. Recuperado el 3 de

Octubre de 2015, de LibrosWeb: http://librosweb.es/libro/javascript/

Gorigori. (2015). Microblogging. Recuperado el 27 de Septiembre de 2015, de Wikipedia:

https://es.wikipedia.org/wiki/Microblogging

Jarould. (2015). HTML. Recuperado el 24 de Septiembre de 2015, de Wikipedia:

https://es.wikipedia.org/wiki/HTML

Jarould. (17 de Septiembre de 2015). HTML5. Recuperado el 24 de Septiembre de 2015, de

Wikipedia: https://es.wikipedia.org/wiki/HTML5

JosueMolina. (1 de Septiembre de 2015). HTML5. Recuperado el 24 de Septiembre de

2015, de Mozilla Developer Network:

https://developer.mozilla.org/es/docs/HTML/HTML5

jQuery. (2015). jQuery. Recuperado el 22 de Septiembre de 2015, de jQuery:

https://jquery.com/

Lara, W. (31 de Julio de 2015). Cómo funciona la metodología de trabajo Scrum.

Recuperado el 23 de Octubre de 2015, de Platzi: https://platzi.com/blog/guia-scrum/

Martel, A. (2014). Gestión práctica de proyectos con Scrum: Desarrollo de software ágil para

el Scrum Master. Recuperado el 5 de Noviembre de 2015

Martínez, L. (2014). Gestión y Control de Proyectos. Jaén. Recuperado el 17 de Octubre de

2015, de Gestión y Control de Proyectos: Gestión y Control de Proyectos



Matiia. (2015). JavaScript. Recuperado el 3 de Octubre de 2015, de Wikipedia:

https://es.wikipedia.org/wiki/JavaScript

Photographer, T. (17 de Agosto de 2015). jQuery. Recuperado el 10 de Octubre de 2015, de

Wikipedia: https://es.wikipedia.org/wiki/JQuery

SISTEMA DE MICROBLOGGING PARA LA UJAtauja.ujaen.es/bitstream/10953.1/6706/1/Memoria.pdf · Miguel...

Documents

Transcript of SISTEMA DE MICROBLOGGING PARA LA UJAtauja.ujaen.es/bitstream/10953.1/6706/1/Memoria.pdf · Miguel...