fanhunter: aplicación web para la creación de fichas de personaje

Omar Barco Prado

María Vico Pascual Martínez-Losa

Facultad de Ciencias, Estudios Agroalimentarios e Informática

Grado en Ingeniería Informática

2013-2014

Título

Director/es

Facultad

Titulación

Departamento

TRABAJO FIN DE GRADO

Curso Académico

FanHunter: Aplicación web para la creación de fichas depersonaje

Autor/es

© El autor© Universidad de La Rioja, Servicio de Publicaciones, 2014

publicaciones.unirioja.esE-mail: [email protected]

FanHunter: Aplicación web para la creación de fichas de personaje, trabajo finde grado

de Omar Barco Prado, dirigido por María Vico Pascual Martínez-Losa (publicado por laUniversidad de La Rioja), se difunde bajo una Licencia

Creative Commons Reconocimiento-NoComercial-SinObraDerivada 3.0 Unported. Permisos que vayan más allá de lo cubierto por esta licencia pueden solicitarse a los

titulares del copyright.

Facultad

Facultad de Ciencias, Estudios Agroalimentarios e Informática

Titulación

Grado en Ingeniería Informática

Título

FanHunter: Aplicación web para la creación de fichas de personaje

Autor/es

Omar Barco Prado

Tutor/es

María Vico Pascual Martínez Losa

Departamento

Matemáticas y Computación

Curso académico

2013 / 2014

I

Memoria Trabajo Fin de Grado

Índice

1 Introducción .......................................................................................................................... 2

1.1 Motivación y antecedentes ........................................................................................... 2

1.2 Juegos de rol de mesa ................................................................................................... 2

1.2.1 Descripción ............................................................................................................ 2

1.2.2 Mecánica ............................................................................................................... 3

1.2.3 Fichas de personaje ............................................................................................... 3

1.3 FanHunter...................................................................................................................... 4

1.3.1 Ambientación ........................................................................................................ 4

1.3.2 Elementos de una ficha de FanHunter .................................................................. 5

1.3.3 Mecánica de juego en FanHunter ....................................................................... 11

1.3.4 Ejemplo de creación de ficha .............................................................................. 12

2 Sprint 0: Estudio previo ....................................................................................................... 16

2.1 Punto de partida: prototipo anterior .......................................................................... 16

2.1.1 Interfaz ................................................................................................................ 16

2.1.2 Análisis: Relaciones entre entidades ................................................................... 17

2.1.3 Diseño: Estructura de clases ............................................................................... 17

2.1.4 Arquitectura ........................................................................................................ 19

2.1.5 Estructura de ficheros y directorios .................................................................... 20

2.2 Requisitos informales .................................................................................................. 21

2.3 Objetivos principales ................................................................................................... 21

2.4 Metodología y alcance del trabajo .............................................................................. 22

2.5 Planificación ................................................................................................................ 22

2.6 Entorno de desarrollo. DevOps ................................................................................... 23

3 Sprint 1: Entorno de desarrollo ........................................................................................... 24

3.1 Replanificación ............................................................................................................ 24

3.2 Arquitectura del entorno ............................................................................................ 24

3.3 Automatización ........................................................................................................... 26

4 Sprint 2 ................................................................................................................................ 27


4.2 Decisiones de diseño ................................................................................................... 27

II

4.2.1 Desactivación de Cross Site Request Forgery (CRSF) .......................................... 27

4.2.2 Distribución del cliente web ................................................................................ 27

4.2.3 API/Esquema de navegación ............................................................................... 28

4.3 Cambios en la arquitectura ......................................................................................... 30

4.3.1 Pila de tecnologías ............................................................................................... 30

4.3.2 Directorios ........................................................................................................... 30

4.4 Objetivos alcanzados ................................................................................................... 33

5 Sprint 3 ................................................................................................................................ 34


5.2 Desarrollo del sprint .................................................................................................... 34


6 Sprint 4 ................................................................................................................................ 35


6.2 Evaluaciones de usabilidad ......................................................................................... 35

6.3 Evaluación heurística ................................................................................................... 36

6.3.1 Evaluación cuantitativa ....................................................................................... 36

6.3.2 Evaluación cualitativa .......................................................................................... 36

6.4 Prototipos en papel ..................................................................................................... 37

6.4.1 Objetivos del diseño ............................................................................................ 37

6.4.2 Primer prototipo ................................................................................................. 37

6.4.3 Segundo prototipo .............................................................................................. 39

7 Sprint 5 ................................................................................................................................ 41


7.2 Tercer prototipo .......................................................................................................... 41

7.2.1 Diseño .................................................................................................................. 41

7.2.2 Evaluación ........................................................................................................... 43

8 Sprint 6 ................................................................................................................................ 45


8.2 Dificultades encontradas ............................................................................................. 45


9 Sprint 7 ................................................................................................................................ 46


9.2 Dificultades encontradas ............................................................................................. 46


III

10 Sprint 8 ............................................................................................................................ 47


10.2 Lógica de negocio ........................................................................................................ 47

10.2.1 Requisitos ............................................................................................................ 47

10.2.2 Diseño .................................................................................................................. 48


11 Gestión del tiempo .......................................................................................................... 50

12 Trabajo futuro ................................................................................................................. 51

13 Conclusiones.................................................................................................................... 53

14 Anexo 1: Versiones de la aplicación ................................................................................ 54

15 Anexo 2: SPA ................................................................................................................... 55

16 Anexo 3: Juego FanHunter. Manual ................................................................................ 56

17 Anexo 4: Estructura de una aplicación Ruby on Rails ..................................................... 57

17.1 Esquema ...................................................................................................................... 57

17.2 Migraciones ................................................................................................................. 57

17.3 Fichero de Semillas ...................................................................................................... 58

17.4 Entidades de negocio. ActiveRecord ........................................................................... 59

17.5 Inflector ....................................................................................................................... 59

17.6 Controlador ................................................................................................................. 59

17.7 Dispatcher ................................................................................................................... 60

17.8 Vista ............................................................................................................................. 60

18 Anexo 5: Estilo arquitectónico REST ................................................................................ 62

19 Anexo 6: Arquitectura SOA ............................................................................................. 63

20 Anexo 7: DevOps ............................................................................................................. 64

21 Anexo 8: Herramientas de desarrollo ............................................................................. 65

21.1 Descripciones .............................................................................................................. 65

21.2 Decisiones ................................................................................................................... 65

22 Anexo 9: Agradecimientos .............................................................................................. 68

23 Anexo 10: Maqueta de la interfaz ................................................................................... 69

24 Anexo 11: Historia del código heredado ......................................................................... 71

24.1 Contexto ...................................................................................................................... 71

24.1.1 Proceso de creación de ficha ............................................................................... 71

24.2 Primer prototipo ......................................................................................................... 71

24.3 Segundo prototipo ...................................................................................................... 74

IV

24.4 Tercer prototipo .......................................................................................................... 76

24.5 Cuarto prototipo ......................................................................................................... 77

24.6 Resumen ...................................................................................................................... 80

24.7 Funcionalidades/mejoras por implementar................................................................ 80

25 Anexo 12: Evaluaciones de usabilidad ............................................................................ 82

26 Bibliografía ...................................................................................................................... 83

27 Glosario ........................................................................................................................... 84

1

Resumen

El proyecto consiste en la mejora de un sistema software que ayuda a los jugadores de

FanHunter a crear fichas de personaje. FanHunter es un juego de rol de mesa. En todos los

juegos de rol de mesa la creación de fichas de personaje es un proceso que hay que realizar

antes de empezar a jugar.

El proyecto parte de una aplicación web que existía con anterioridad y realiza mejoras sobre la

misma, la mayor parte de ellas centradas en la capa de interfaz.

Abstract

The project improves a legacy software system designed to help FanHunter players to create

character sheets. FanHunter is a tabletop role-playing game. In all tabletop role-playing game

the creation of character sheets is a process that have to be done before the players can start

playing.

The project starts from a previous existing webapp and makes some improvements on it. Most

of those improvements are focused on the interface layer.

2

1 Introducción El sistema software mejorado en el presente TFG proporciona asistencia en un juego de rol de

mesa. En este capítulo se explican las motivaciones para elegir el TFG, se introducen los

conceptos básicos de juegos de rol y se explican algunas particularidades de los mismos.

También se resume la evolución del sistema software anterior al comienzo del TFG.

1.1 Motivación y antecedentes La motivación para elegir el tema del TFG es la afición a los juegos de rol. Juego

periódicamente a FanHunter con mis amigos y me he percatado de que podía mejorar el

proceso de juego usando la tecnología.

La libertad para elegir la tecnología a usar también ha jugado un papel importante en la

motivación. Tanto Ruby on Rails como Angular.js son tecnologías que me parecen muy

interesantes y quería profundizar en ellas.

El TFG no parte de cero sino que retoma un proyecto que había sido empezado unos meses

antes. Este desarrollo previo se realizó conforme a un estilo ágil de trabajo, realizando varias

iteraciones en el desarrollo. El detalle de este desarrollo previo está descrito en el Anexo 11:

Historia del código heredado.

1.2 Juegos de rol de mesa

1.2.1 Descripción

Los juegos de rol de mesa son una forma de entretenimiento en la que los jugadores

interpretan un personaje de manera similar a la que un actor interpreta el suyo. A diferencia

de las interpretaciones del cine o el teatro, los jugadores de un juego de rol no tienen un guión

definido. Son ellos quienes deciden qué es lo que hace y dice su personaje.

Los grupos de juego suelen ser reducidos (3 – 6 personas). Los jugadores se reúnen

(normalmente de manera física) y forman un grupo de personajes que se debe de enfrentar a

algún tipo de reto o aventura. Existe un jugador especial denominado director del juego que se

encarga de preparar la aventura. Por la naturaleza de su rol posee mucha información

privilegiada sobre el entorno. El jugador que toma el rol de director del juego puede variar de

una aventura a otra pero no es normal que cambie durante el transcurso de una.

Normalmente los jugadores cooperan para lograr un objetivo común marcado por la aventura.

Cada juego de rol describe una ambientación diferente en la que pueden crearse múltiples

aventuras. Por ejemplo, Dungeons & Dragons (D&D) es un juego de rol que proporciona una

ambientación de fantasía medieval. Una aventura típica en D&D podría ser rescatar a una

princesa que ha sido secuestrada por un dragón o liberar a la ciudad de una invasión de

trasgos. El juego describe la ambientación, el director de juego es el que crea las historias

concretas que ocurren en ella. Existen muchísimos juegos de rol, cada uno con su propia

ambientación. Hay juegos ambientados en mundos de ciencia-ficción (Future, Apocalypse, Star

Wars,…), en mundos de terror (Vampiro, La llamada de Cthulhu, Changeling,…), juegos de

humor (Paranoia, FanHunter, Mundodisco,…),…

3

El comportamiento del entorno que se encuentran los personajes está controlado por el

director del juego. Asimismo el director del juego se encarga de interpretar a todos los

personajes no asignados a ningún otro jugador y describir a los jugadores lo que ven y sienten

sus personajes.

Es muy común que los personajes que han sobrevivido a una aventura participen también en

las siguientes. Lo normal en estos casos es que el personaje mejore o evolucione ganando

puntos de experiencia que se pueden invertir en mejorar sus características y/o habilidades.

La mayoría de los juegos de rol tienen un sistema de clases o arquetipos. Este sistema divide a

los personajes en grandes grupos o categorías que definen algunos de sus rasgos. Por ejemplo,

en Dungeons & Dragons las clases son Bardo, Clérigo, Monje, Ladrón, Bárbaro y Mago. El

jugador elige una de estas clases durante la creación del personaje. Un Bardo tendrá más

habilidades de relación social, un Ladrón destacará en el arte del sigilo, un Mago tendrá más

facilidades para lanzar conjuros y hechizos y un Bárbaro será formidable en el combate.

1.2.2 Mecánica

Los jugadores pueden declarar que sus personajes ejecutan cualquier acción que entre dentro

de lo plausible para el mundo de ficción en el que se encuentran.

A veces la acción que quieren realizar es trivial (abrir la puerta, contestar al teléfono, leer un

manuscrito). Desde el punto de vista de la mecánica del juego estas acciones se realizan de

manera automática.

En otras ocasiones las acciones no son triviales y es necesario un proceso para determinar si el

personaje logra lo que se propone (saltar de un coche en marcha a otro, convencer al jurado

de su inocencia, acertar un disparo al enemigo,…). En estos casos se realiza una tirada de

dados. Se lanzan varios dados y dependiendo del resultado se determina si el personaje logra o

no lo que intentaba.

1.2.3 Fichas de personaje

Antes de empezar a jugar cada jugador debe de crear una ficha. En dicha ficha se describe

cómo es el personaje, qué le motiva, qué habilidades posee y qué debilidades le aquejan. Estos

datos tienen efecto en la mecánica del juego modificando los dados usados en las tiradas.

Las normas de cada juego de rol regulan el formato de la ficha de personaje así como las

restricciones a seguir para rellenarla. Lo normal es que el jugador rellene la ficha atendiendo a

las normas del juego y después se la presente al director del juego para que la revise y

apruebe. El director del juego siempre tiene la última palabra sobre la validez de la misma,

reservándose el derecho a vetar algún aspecto de la misma (incluso si es válido conforme a las

normas del juego) y a hacer la vista gorda sobre el incumplimiento de alguna de las normas.

4

1.3 FanHunter

1.3.1 Ambientación

FanHunter es un juego de rol de humor basado en los cómics homónimos de Cels Piñol. Los

personajes que habitan en su mundo se denominan narizones. Al director de juego en

FanHunter se le denomina “Animador”. El mundo del juego se ambienta en un futuro cercano

en el que un hombre llamado Alejo Cuervo ha dado un golpe de estado en la mayor parte de

los estados de Europa y se ha convertido en un dictador. Nada más subir al poder Alejo

prohíbe todo tipo de juegos y subcultura (cine, libros, música, juegos de rol, videojuegos,…).

Los jugadores interpretan a narizones que no están conformes con esta prohibición y

participan de alguna manera en aventuras que suponen una lucha contra este dictador. Existe

un cuerpo militar creado por Alejo expresamente para exterminar a estos rebeldes. Los

miembros de esta fuerza represiva se llaman FanHunters.

Puede que haya dos o tres personas en todo el mundo que aún no sepan que

FanHunter, el juego de rol, está basado en los fanzines de Cels Piñol. A ellas va dirigida

esta parrafada. Cels edita fanzines desde 1988 con gran éxito de público y crítica.

Todos ellos están, en mayor o menor medida, ambientados en el mundo de FanHunter,

un mundo de narizones que armados hasta las cejas combaten la tiranía despótica de

un malvado usurpador (ésta no es más que la primera de una serie de frases pedantes

llenas de polisílabos que medran agazapados a lo largo del texto con el fin de convertir

su lectura en una pesadilla agónica).

Y tú, en el papel de uno de esos energúmenos, pelearás en mil batallas, volarás más

rápido que la luz, vivirás aventuras intensas y positivas y disfrutarás como un enano en

el túnel de los espejos (éste no es más que el primero de una serie de chistes sobre

enanos que... bueno, mejor lo dejamos correr). Así que ponte las alpargatas, descuelga

el teléfono y prepárate para ser testigo del mayor acontecimiento habido jamás en la

industria de los juegos desde la invención del mus. Pero, ¿qué hace falta para jugar a

FH? Pues lo primero de todo, necesitas crear tu propio narizón.

[Extraído del manual de juego de FanHunter]

5

1.3.2 Elementos de una ficha de FanHunter Ilustración 1: Ficha de personaje (Frontal)

6

Ilustración 2: Ficha de personaje (Trasera)

7

Una ficha de personaje de FanHunter está formada por atributos, habilidades, habilidades

opcionales, poderes, coñas, taras, equipo, dinero, contactos y un arquetipo.

1.3.2.1 Arquetipo

El arquetipo en FanHunter tiene un papel similar a los sistemas de clases de otros juegos. El

arquetipo determinará límites y algunos valores por defecto en el resto de los elementos.

Algunos de los arquetipos de FanHunter son Rebelde, Súper, Taxista, Negociador, Mostruo,…

Además, el arquetipo determina la cantidad de puntos que el personaje se puede gastar en

atributos y habilidades así como los puntos libres de que dispone. Los puntos libres se pueden

utilizar para comprar poderes, coñas, habilidades y atributos.

Rebelde

Aquellos valientes narizones que luchan contra el poder establecido del Papa Alejo y

cuya existencia se hace más y más dura a medida que la censura aumenta y van siendo

exterminados por los fanhunters. Miembros de la resistencia, dibujantes de cómics y

rolemasters conforman el grueso de esta categoría.

Ejemplos: Luke Skywalker, Curro Jiménez o Belit.

Dispone de 20 puntos en atributos, 16 en habilidades y 8 puntos libres.

Como equipo empieza con un Kevlar y un casco militar.

Además, el rebelde puede elegir entre una de las siguientes fantabulosas opciones:

Vehículo ligero.

3000 Md en efectivo.

Tesoro subcultural de unos 5000 Md de valor.

Uno de los contactos que adquiera en la creación de la ficha pasa a ser aliado.


1.3.2.2 Atributos

Los atributos son un grupo de 8 elementos cada uno de los cuales tiene asociado un valor

numérico, dos habilidades y un conjunto de habilidades opcionales. Los atributos son

“Combate”, “Disparo”, “Músculos”, “Reflejos”, “Neuronas”, “Carisma”, “Agallas” y “Empatía”.

Los cuatro primeros pertenecen al grupo de los atributos físicos, los cuatro últimos al de los

atributos mentales. Salvo excepciones lo normal es que las reglas obliguen a elegir valores

comprendidos entre 1 y 5 para todos los atributos.

Combate: Capacidad de repartir mamporros. Alguien con combate 5 es capaz de

hacerse un collar con los dientes de Terminator. Alguien con combate 1 no es que sea

torpe, es que no tiene brazos.

8

Disparo: Capacidad para usar todo tipo de armas de proyectiles. Alguien con disparo 5

puede matar las pulgas de su perro a balazos sin darle al chucho. Alguien con disparo 1

podría perder un ojo al cambiar de canal.

Músculos: Define la fuerza física y lo cachas que está el narizón. Alguien con músculos

5 puede poner en órbita al contrincante de un mamporro. Alguien con músculos 1

necesita ayuda para cortar el pan en rebanadas.

Reflejos: Mide la agilidad, la rapidez y la destreza del narizón. Alguien con reflejos 5 es

capaz de atrapar moscas con palillos chinos. Si alguien con reflejos 1 intenta atrapar

moscas con palillos es probable que acabe saltándose un ojo.

Neuronas: Cultura general y capacidad de raciocinio del narizón. Alguien con neuronas

5 puede descubrir al asesino sin conocer a los sospechosos. Alguien con neuronas 1

forma parte del reino vegetal.

Agallas: El valor y la personalidad del tipo en cuestión. Alguien con agallas 5 seguiría

tocando el piano aunque los misiles nucleares llovieran sobre la ciudad. Alguien con

agallas 1 tendría pesadillas tras ver "Dumbo".

Carisma: Capacidad de influir en los demás despertándoles simpatía y buen rollo.

Alguien con carisma 5 convencería al jurado de que el asesinato con tortura y

mutilación es una forma de comportamiento social aceptable. Alguien con carisma 1 ha

de salir de casa con un saco en la cabeza para no ser apedreado por los niños.

Empatía: Capacidad de percibir sensaciones del mundo que nos rodea. Alguien con

empatía 5 es capaz de reconocer a una persona por el olor de sus pies. Alguien con

empatía 1 debe dejar un rastro de miguitas de pan para no perderse cuando va al

lavabo de su casa.


Salvo cambio en las reglas del manual, esta relación de atributos es común a todas las fichas.

1.3.2.3 Habilidades y habilidades opcionales

Las habilidades son campos asociados a los atributos. Por ejemplo, el atributo “Combate”

tiene asociadas las habilidades fijas “Artes marciales” y “Defensa”. Las habilidades tienen un

valor numérico que guarda relación con el valor del atributo.

El atributo también tiene un grupo de habilidades opcionales. Las habilidades opcionales no

tienen una etiqueta individual, sí disponen de un nombre colectivo. Por ejemplo, todas las

habilidades opcionales de “Combate” pertenecen al grupo “maestría”. El número de

habilidades opcionales no está predeterminado. Cada habilidad opcional dispone de un campo

de texto llamado “especialidad” y un valor numérico. El valor numérico guarda relación con el

atributo. La especialidad tiene significado a efectos del juego.

9

Habilidades de combate:

Artes marciales: Mortífero estilo de combate que cuando es utilizado resta al contrario

-1D en defensa por cada punto de diferencia. Además, el nivel de artes marciales se

suma al calcular la pupa que se causa. Para más información, ver el capítulo de tortas.

Defensa: Permite intentar bloquear los golpes del contrario en combate cuerpo a

cuerpo. Todo esto se explica con más detalle en el capítulo de tortas.

Maestría: Experiencia en el manejo de un tipo de armas de combate que debe ser

elegido de antemano. Algunos ejemplos son: espadas, garrotes, porras. Esta habilidad

debe comprarse por separado para cada tipo de arma en la que uno quiera

especializarse y su funcionamiento se explica en el capítulo de tortas.


1.3.2.4 Poderes

Los poderes son cualidades sobrenaturales de un narizón que le permiten realizar acciones

imposibles para un ser humano normal. Cada poder está ligado a un atributo. Cada poder tiene

asociado un coste y un nivel. El coste lo determina el manual de juego. El nivel de poder se

determina en base al atributo asociado. Por ejemplo, si un narizón con Combate 5 compra el

poder Armadura tendrá que pagar 6 puntos libres y obtendrá el poder a nivel 5. Cuanto mayor

es el nivel de poder más potentes son sus efectos.

Table 1: Poderes asociados a atributos físicos

Combate Disparo Músculos Reflejos

Toque (6) Rayo (4) Resistencia (4) Supermovimiento(4) Armadura (6) Multirrayo (10) Inmunidad (10) Trepamuros (4) Absorción (6) Visión de Rayos X (4) Regeneración (6) Borrosidad (4) Golpe Letal (4) Control (6/8) Replicación (6) Celeridad (8)

Onda de Choque (6) Potencia (10) Agilidad (4) Table 2: Poderes asociados a atributos mentales

Neuronas Carisma Agallas Empatía

Invisibilidad (8) Control mental (6) Teleport (6) Sonar Radar (4) Campo de fuerza (4)

Telepatía (4) Teleport X (8) Telekinesis (6)

Curación (4) Ilusión (4) Multiformidad (4) Detección (4) Oscuridad (6) Maldición (6) Incorporeidad (6) Precognición (6) Invocación (8) Presencia (8) Control Tiempo (10) Control Suerte (4) Anulación (10) Control Memoria

(10)

Armadura (6 puntos)

Tienes una protección natural en la piel equivalente a tu nivel de armadura

multiplicado por 3. Es por naturaleza imposible de ignorar, excepto por daños que

especifiquen concretamente que la ignoran.


10

1.3.2.5 Taras

Las taras representan desventajas del personaje. Por cada tara que se incorpora en una ficha el

personaje adquiere puntos libres que puede invertir en mejorar otros aspectos de la ficha.

Las taras son cosas horribles que caracterizan a tu personaje (está traumatizado

porque de pequeño le pegaban en la escuela, tiene una cicatriz enorme, es más gafe

que los hermanos Dalton,...). Por cada una que le pongas a tu personaje obtendrás los

puntos libres indicados para gastártelos en lo que tú quieras.

[…]

Exceso de velocidad (2)

Cuando conduzcas e intentes frenar, tienes que superar un chequeo a 18 de Agallas. Si

fallas, no frenas.


1.3.2.6 Coñas

Las coñas son ventajas innatas del narizón que se compran con puntos libres en el momento

de crear la ficha.

Hay una serie de habilidades especiales muy chulas que los jugadores pueden (o no)

escoger y que denominamos coñas. Son una especie de ventajas innatas bastante

poderosas, por lo que el animador debe controlar su uso, aplicando chequeos de

elevada dificultad si lo cree necesario, para evitar que le hundan la partida.

[…]

Empatía animal (1)

Permite hablar con todo tipo de criaturas, se deben efectuar tiradas de carisma para

evitar que el bicho pase de ti o salga huyendo.

Insomne (1)

No necesitas dormir.


1.3.2.7 Otros elementos

El equipo es el conjunto de objetos materiales que lleva el personaje consigo. Incluye

armadura, armas, munición, explosivos, determinados tipos de ropa, gadgets tecnológicos,

vehículos,… No existe una lista cerrada de ítems que se pueden comprar. No obstante, hay

algunos objetos que aparecen con mucha frecuencia en la equipación de los personajes.

Los contactos son conocidos del personaje que le pueden proveer con productos o servicios

que normalmente no están a la venta. Pertenecen a una lista cerrada.

11

1.3.3 Mecánica de juego en FanHunter

En FanHunter las acciones no triviales se resuelven tirando dados de 6 caras. Cuando un

personaje desea realizar una acción su jugador debe de lanzar una cantidad variable de dados

que suele depender del nivel de atributo, nivel de habilidad o nivel de poder del personaje.

Para determinar si el personaje logra o no su cometido se suma el resultado obtenido en los

dados lanzados y se compara el resultado con la dificultad de la acción.

Cuando la acción que se intenta realizar recibe la oposición de otro personaje se produce una

competición. En ese caso ambos personajes realizan una tirada de dados y se compara el

resultado de ambas para determinar quién se sale con la suya.

El valor de los dados no corresponde exactamente con el número que éste muestra al lanzarlo.

Cuando el resultado es 2, 3, 4 ó 5 el dado cuenta de la manera esperable. Cuando el resultado

es un 1 se le otorga como valor 0. Cuando el resultado es un 6 se suman los 6 puntos y se

vuelve a tirar. La repetición de un 6 se rige por los mismos principios que un dado normal. Esto

significa que es teóricamente posible realizar una tirada infinita con un solo dado a base de

sacar 6 indefinidamente.

Ejemplo

Cumshet se encuentra a las puertas de Radio Televisión Dick, la nueva televisión pública

construida por Alejo Cuervo sobre la antigua Radio Televisión Española y convertida en

instrumento de propaganda del régimen. Ha llegado allí junto a su grupo de compañeros

porque la resistencia les ha enviado en una misión para sabotear la emisión del NO-DIO, el

programa informativo de Alejo.

Cuando los intrépidos narizones se acercan a la entrada el guardia de seguridad les increpa.

Guardia: ¿Quiénes sois y qué hacéis aquí?

Cumshet: Somos los técnicos. Hemos venido en un viaje urgente arreglar los

problemas técnicos de la emisión.

G: No sé de qué me estás hablando.

C: ¿Pero es que no te enteras de nada? La emisión lleva 20 minutos parada.

G: Déjame que compruebe eso. Tendré que hacer unas llamadas pero no creo que

tarde más de 30 minutos en comprobarlo.

C: ¿¡30 minutos!? ¿Pero tú sabes lo que estás diciendo? Ya van a rodar cabezas por

estos 20 minutos que llevan sin emitir. Si quieres comprobarlo, tú mismo. No es a mí al

que van a echar a la calle cuando se enteren de que nos has tenido aquí parados.

G: Ummmmmh….

Cumshet está intentando convencer al guardia de que le conviene dejarles pasar. El director

del juego decide que es oportuno realizar una competición de la habilidad Comecocos de

Cumshet contra el atributo Neuronas del guardia. Cumshet tiene Comecocos 5 y el guardia

tiene neuronas 2.

Cumshet lanza 5 dados. En sus caras se ven los siguientes resultados: 1, 1, 3, 4, 6. Los unos no

cuentan. 3 + 4 + 6 = 13. De momento Cumshet tiene un 13 y repite el 6. Obtiene un 2 con el

nuevo dado. En total 13 + 2 = 15.

12

El director del juego lanza 2 dados por las neuronas del guardia. Obtiene un 4 y un 2. 4 +2 = 6.

Cumshet ha superado al guardia y además por 9 puntos de ventaja. El guardia está convencido

de que no le conviene arriesgarse a retrasar la reparación de la emisión y les deja pasar.

1.3.4 Ejemplo de creación de ficha

José es un jugador nuevo en el mundo de FanHunter. Quiere hacerse una ficha de personaje

para participar en la que será su primera partida. Como no está muy familiarizado con las

normas del juego, le pide consejo al Animador. Éste le dice que empiece por imaginarse cómo

es su personaje. Qué le motiva, cómo ha acabado luchando contra Alejo.

José se lo piensa un rato y se le ocurre que su personaje sea Edward Cumshet, un ancianito

que se dedicaba a hablar sobre ciencia en la televisión pública hasta que Alejo dio el golpe de

estado y retiró su programa de la parrilla por considerarlo peligroso. Cumshet es un tipo con

un cierto carisma y muy culto.

Ahora que José tiene el concepto de personaje, le toca elegir arquetipo. El animador le sugiere

que utilice el Rebelde, que es uno de los más simples.

Rebelde

Aquellos valientes narizones […]

Dispone de 20 puntos en atributos, 16 en habilidades y 8 puntos libres.


A continuación José tiene que invertir los puntos de atributo que vienen con el arquetipo. En el

caso del rebelde son 20 puntos. Tiene que asignar valores entre 1 y 5 a todos y cada uno de los

atributos. De acuerdo con su descripción del personaje, José los distribuye de la siguiente

manera.

Combate: 1 Disparo: 1 Músculos: 2 Reflejos: 2 Neuronas: 4 Carisma: 4 Agallas: 3 Empatía: 3

A continuación hay que elegir las habilidades de Cumshet. Las habilidades de un Rebelde

tienen valores comprendidos entre 0 y 5. El animador le dice a José que algunas habilidades

obtienen puntos gratis de manera automática en función del valor de sus atributos. Cada

atributo tiene una de habilidad que aumenta de esta manera.

Combate -> Defensa Disparo -> arrojar Músculos -> atletismo Reflejos -> sigilo Neuronas -> Investigar Carisma -> comecocos Agallas -> callejear Empatía -> observar

La habilidad en cuestión obtiene tantos puntos como haya en el atributo divididos entre dos y

redondeados hacia abajo. Por ejemplo, Cumshet tiene Agallas 3 que dividido entre dos y

redondeado hacia abajo produce 1 punto gratis de callejear. En el caso de Cumshet esto se

traduce en las siguientes habilidades gratuitas:

13

Defensa: 1 / 2 = 0 Arrojar: 1 / 2 = 0 Atletismo: 2 / 2 = 1 Sigilo: 2 / 2 = 1 Investigar: 4 / 2 = 2 Comecocos: 4 / 2 = 2 Callejear: 3 / 2 = 1 Observar: 3 / 2 = 1

Ahora José tiene que gastar los 16 puntos de habilidad que tiene su arquetipo en mejorar sus

habilidades. José decide gastar 5 puntos en un idioma. Idioma es la habilidad opcional de

Carisma. José le asigna a Cumshet 5 puntos en el idioma “Inglés”. Se descuenta 5 puntos de

habilidad y escribe el idioma al final del atributo Carisma. José piensa que Cumshet es muy

convincente y debería de tener Comecocos 5. Puesto que Cumshet ya tiene Comecocos 2 (por

tener Carisma 4) sólo tiene que gastar 3 puntos de habilidad.

A Cumshet le quedan 8 puntos de habilidad (ha gastado 5 en un Idioma y 3 en comecocos). Se

gasta los 8 restantes en subir farolear e investigar a nivel 5.

José ya ha invertido todos los puntos de atributo y de habilidad así que se pone con los puntos

libres, de los cuales tiene 8. Los puntos libres se pueden gastar en casi cualquier cosa. Se

pueden usar para comprar puntos de atributo, puntos de habilidad, poderes y coñas. Las taras

no cuestan puntos libres, los proporcionan. Un punto de atributo cuesta 4 puntos libres, uno

de habilidad cuesta 1 punto libre y las coñas y los poderes tienen cada uno/a su precio.

A José le gusta el poder Presencia.

Presencia (8)

El narizón tiene una poderosa presencia y nadie es capaz de llevarle la contraria. Para

intentar atacar al narizón se debe hacer una competición entre las agallas y el nivel de

poder siempre que se le quiera atacar. Si no, no se puede realizar ninguna acción

ofensiva directamente contra él.


José decide pagar los 8 puntos libres que cuesta el poder presencia. El poder empezará a nivel

5 puesto que Presencia es un poder asociado al atributo Carisma y Cumshet tiene Carisma 5. A

Cumshet ya no le quedan puntos libres.

No obstante, José sigue ojeando las taras y las coñas para ver si hay alguna que le parezca

apropiada para el personaje. Se encuentra con la coña Enciclopedia Viviente, que le viene

como anillo al dedo a su personaje.

Enciclopedia viviente (6)

Cuando quieras saber algo, puedes intentar saberlo sacando un chequeo de Neuronas

de dificultad variable. Además tienes lo que viene a ser cultura general.


Decide ponérsela a Cumshet. Enciclopedia Viviente cuesta 6 puntos. ¡Eso significa que a ahora

Cumshet le faltan 6 puntos para ser una ficha válida! José entiende que es poco probable que

el director del juego le acepte la ficha en estas condiciones. Por esta razón empieza a mirar las

taras disponibles para ver si encuentra alguna con la que pueda pagar esos 6 puntos.

14

José ve una tara que le encaja bastante bien a Cumshet.

Enfermizo (4)

Cuando quiera el animador, te pondrás enfermo, a menos que superes un chequeo a 18

de Músculos. Tienes un penalizador en dados a todas tus acciones, variable según diga

el animador. Puede ser curado con Medicina, o superando chequeos de Músculos.


Todo el proceso de creación de la ficha se ha realizado durante el mismo día de la partida. En

teoría ya deberían de haber empezado a jugar pero están esperando a que José termine de

hacerse la ficha. José va a hablar con el director de juego para pedirle consejo sobre qué otras

taras ponerle a su personaje para que termine de cuadrar. El animador tiene ganas de empezar

ya la partida y le dice que no pasa nada porque le falten dos puntos, que le admite la ficha

igualmente. También deberían de elegir los contactos y el equipo con el que va a empezar

Cumshet pero deciden dejarlo para más adelante.

15

Ilustración 3: Ficha de Cumshet

16

2 Sprint 0: Estudio previo

2.1 Punto de partida: prototipo anterior El proyecto nació del deseo de aprender sobre el framework Ruby on Rails aplicándolo a la

construcción de un sistema software real. El código que luego se tomaría como base en el

Trabajo Fin de Grado fue escrito durante el verano de 2013. En este proyecto previo se adoptó

un estilo ágil de trabajo, realizando varias iteraciones en el desarrollo. La historia del desarrollo

se relata con más detalle en el Anexo 11: Historia del código heredado.

2.1.1 Interfaz

La interfaz de la anterior aplicación sólo constaba de dos páginas que están reflejadas en la

Ilustración 4: Listado de fichas y la Ilustración 5: Formulario añadir. En la Ilustración 5:

Formulario añadir se puede ver que los arquetipos, coñas, taras y poderes se eligen en menús

desplegables mientras que el resto de los campos los eligen manualmente los jugadores.

Ilustración 4: Listado de fichas

Ilustración 5: Formulario añadir

17

2.1.2 Análisis: Relaciones entre entidades

Las entidades presentes en una ficha de personaje son numerosas y tienen una serie de

relaciones entre sí. En muchas ocasiones los elementos de una ficha se eligen de una lista

cerrada determinada por el manual de juego. Las listas de las que se eligen son comunes a

todos los narizones, los elementos elegidos son los que cambian de un narizón a otro.

Los elementos comunes a todos los narizones son:

Listado de arquetipos a elegibles.

Listado de poderes elegibles.

Listado de taras elegibles.

Listado de coñas elegibles.

Listado de contactos disponibles.

Listado de contactos elegibles.

Relación de nombres de atributos.

Relación de nombres de las dos habilidades fijas de cada poder.

Nombre del conjunto de las habilidades opcionales.

Los elementos que cambian para cada narizón son:

Arquetipo elegido.

Poderes elegidos.

Taras elegidas.

Coñas elegidas.

Valor numérico de los atributos.

Valor numérico de las habilidades fijas.

Relación de habilidades opcionales incluyendo especialidad y valor numérico.

Nombre.

Jugador.

Contactos elegidos.

Listado ítems de equipo comprado.

2.1.3 Diseño: Estructura de clases

La estructura de clases del código fuente replica las relaciones del juego. La Ilustración 6:

Modelo de datos representa dicha estructura de clases.

Cada narizón está asociado con un arquetipo, 8 atributos y una cantidad indefinida de poderes,

taras y coñas. Cada atributo tiene asociadas dos habilidades y una cantidad indefinida de

habilidades opcionales.

Por cada una de las entidades que se pueden elegir de una lista cerrada se ha creado una

entidad que representa dicha lista o catálogo. Para diferenciarlas de la entidad opcional se les

ha puesto el sufijo “_de_catalogo”. Entre estas nuevas entidades se encuentran

“coña_de_catalogo”, “tara_de_catalogo” y “poder_de_catalogo”.

18

El mismo patrón de los catálogos se aplica a los atributos, las habilidades y las habilidades

opcionales. La razón es mejorar la consistencia de los datos. No cualquier habilidad / habilidad

opcional puede estar asociada a cualquier atributo. Y no cualquier combinación de atributos

puede ser válida para una ficha. De hecho las normas del juego exigen que cada ficha tenga 8

atributos concretos y cada uno de esos atributos tenga 2 habilidades concretas. También

obligan a que todas las habilidades opcionales de cada atributo pertenezcan a una categoría

concreta que depende del atributo.

Ilustración 6: Modelo de datos

Estas relaciones están sujetas a las normas del juego pero pueden cambiar a lo largo del

tiempo. Por ejemplo, poco antes de la liberación de este prototipo la habilidad opcional de

Músculos era “montar”. Una ficha podía tener “montar caballo”, “montar elefante”, “montar

lagartija”,… En el momento de liberar el prototipo los jugadores decidieron cambiar la

habilidad opcional de músculos por “supervivencia”. A partir de ese momento las fichas podían

contar con “supervivencia jungla”, “supervivencia desierto”, “supervivencia burocracia

administrativa”,… El patrón de catálogos aplicado a atributos, habilidades y habilidades

19

opcionales permite que la aplicación se adapte a este tipo de cambios sin cambiar el código

fuente, cambiando los catálogos de la base de datos.

2.1.4 Arquitectura

El código heredado está desarrollado sobre Ruby on Rails. Rails es un framework MVC para

aplicaciones web escrito en Ruby. Una gran parte de la estructura del código viene

condicionada por dicho framework (ver Anexo 4: Estructura de una aplicación Ruby on Rails).

El sistema heredado realiza todo el procesamiento en el lado del servidor. Componentes:

Vista de alto nivel (cliente-servidor): El servidor genera las páginas web con los datos

pertinentes y las manda al cliente. El cliente pide más páginas o manda los formularios

de vuelta rellenos. Las URIs están definidas según un estilo arquitectónico REST (ver

Anexo 5: Estilo arquitectónico REST).

Vista de nivel medio (servidor):

o Capa de controlador. Recibe del backend los objetos de negocio con los datos,

los incrusta en plantillas y los manda al navegador. Recibe del usuario los

formularios, los transforma en objetos y delega en la capa de lógica de negocio

su tratamiento.

o Capa de vista. Define las plantillas html usadas para mostrar la información al

usuario. Estas plantillas son modulares: cada entidad de negocio tiene una

plantilla asociada. Las vistas que muestran varias entidades se generan

mediante la composición de plantillas.

o Capa de modelo. Define el esquema de la base de datos y los datos iniciales de

la misma. También define objetos de negocio basados en las tablas de la base

de datos. Dichos objetos saben cómo manejar su relación con la base de datos.

20

2.1.5 Estructura de ficheros y directorios Ilustración 7: Estructura de directorios heredada

Leyenda:

Cuadro simple: Directorio

Cuadro con barras verticales a los lados: fichero

El fichero Gemfile contiene la declaración de las dependencias de la aplicación.

El directorio db/migrate contiene los ficheros de migración encargados de controlar los

cambios en el esquema de la base de datos.

El directorio app/views contiene las plantillas html a mostrar a los usuarios.

App/views/narizones contiene las plantillas principales de la aplicación. Las plantillas

auxiliares de cada entidad de negocio se guardan en su propio subdirectorio

(app/views/atributo, app/views/habilidad,…).

El fichero app/controllers/narizones_controller.rb contiene el controlador de la

aplicación.

21

El directorio app/models contiene las entidades de negocio de la aplicación (atributo.rb,

habilidad.rb, narizon.rb, …).

Existen otros directorios que han sido omitidos por simplicidad.

2.2 Requisitos informales Durante el tiempo que el prototipo ha estado funcionando se ha ido recibiendo feedback de

los usuarios y se ha elaborado una lista de requisitos y mejoras:

Incluir descripciones de coñas, taras y poderes en el formulario

Mejora de los tiempos de respuesta. A veces es de varios segundos

Autorrellenado de campos a medida que el usuario va proporcionando datos

Información del saldo de puntos disponible

Control de acceso

Formulario de cambio de los valores para los poderes, coñas y taras

Generar la ficha en pdf

Dados para realizar tiradas

Tienda para el equipamiento de los personajes

Sistema de gestión de puntos de experiencia

2.3 Objetivos principales Los objetivos principales que generan un hito al terminar son los siguientes:

1. Reingeniería

2. Mejora de la experiencia de usuario

3. Ampliación de funcionalidades

El primer objetivo a lograr es la reestructuración (reingeniería) de la aplicación web. Esto es

necesario para obtener una arquitectura acorde a los cánones modernos de la web (ver Anexo

6: Arquitectura SOA). Además, la reingeniería de la aplicación web facilita mucho (y en algunos

casos, posibilita) la consecución de los otros dos objetivos.

Actualmente la aplicación posee una arquitectura que delega todo el procesamiento en el

servidor. No hay prácticamente ningún comportamiento dinámico en el cliente. La reingeniería

consistirá en convertir la aplicación web en una aplicación SPA (ver Anexo 2: SPA). Esto implica

un cambio en la arquitectura de la aplicación, delegando toda o casi toda la capa de

presentación en el cliente web.

El objetivo de mejora de la experiencia de uso surge de las siguientes sugerencias de los

usuarios:

Incluir descripciones de coñas, taras y poderes en el formulario

Mejora de los tiempos de respuesta. A veces es de varios segundos

Autorrellenado de campos a medida que el usuario va proporcionando datos

Información del saldo de puntos disponible

El objetivo de ampliación de las funcionalidades de la aplicación nace del resto de las

peticiones de los usuarios:

22

Control de acceso

Formulario de cambio de los valores para los poderes, coñas y taras

Generar la ficha en pdf

Dados para realizar tiradas

Tienda para el equipamiento de los personajes

Sistema de gestión de puntos de experiencia

2.4 Metodología y alcance del trabajo Se utilizará un estilo de trabajo ágil. Se planificarán sprints de dos semanas. Se revisará la

planificación tras cada sprint. Cuando se termine el tiempo asignado al proyecto se cerrará el

último sprint. Esto implica que el alcance no está determinado rígidamente desde el principio,

variará dependiendo de las funcionalidades que se logren alcanzar en cada sprint.

El alcance mínimo aceptable será la conversión de la aplicación en un sistema SPA. Algunas de

las nuevas funcionalidades a añadir quedarán dentro del trabajo realizado y otras no,

dependiendo de la prioridad que tengan y del trabajo que finalmente se logre realizar en los

sprints.

2.5 Planificación El tiempo disponible para el proyecto son 300 horas. Realizando 20 horas de trabajo

semanales, el proyecto debería de estar finalizado en 15 semanas. A razón de dos semanas por

sprint, se dispone de 7 sprints y una semana. Se planificarán los 7 sprints y se dejará la semana

final como colchón para compensar retrasos e imprevistos.

Sprints planificados:

0. Estudio previo

1. Elección y despliegue del entorno de desarrollo / producción

2. Cambios básicos en la arquitectura. Reforma del servidor y creación del cliente web

3. Incluir descripciones de coñas, taras y poderes en el formulario

4. Mejora de los tiempos de respuesta. A veces es de varios segundos

5. Autorrellenado de campos a medida que el usuario va proporcionando datos

6. Información del saldo de puntos disponible

Los sprints 0, 1 y 2 no pueden variar su orden puesto que están relacionados con la

reingeniería y está debe de terminarse antes de empezar con el resto de las mejoras.

Los sprints del 3 al 6 pueden intercambiar el orden entre sí, están relacionados con la mejora

de la experiencia de usuario.

Si se llegara al sprint 7 se consideraría que ha terminado el proceso de mejora de experiencia

de usuario y se están añadiendo funcionalidades extra. Si al final sobra tiempo, se decidirá

sobre la marcha qué funcionalidades añadir.

El proyecto empieza el 4 de Febrero de 2014 y se espera que haya terminado para el 20 de

Mayo de 2014.

23

2.6 Entorno de desarrollo. DevOps Durante el desarrollo del proyecto se seguirán algunos principios de la filosofía DevOps (ver

Anexo 7: DevOps). Se preparará un entorno que automatice en la medida de lo posible la

entrega de las nuevas versiones del software. Dicha preparación se realizará durante el sprint

1. El entorno constará de los siguientes elementos:

1. Cliente de desarrollo (local)

2. Máquina de desarrollo en remoto (cloud, IaaS)

3. Máquina de producción (cloud, PaaS)

4. Repositorio de control de versiones (cloud, SaaS)

Las herramientas usadas y las razones para estructurar así el entorno se describen con más

detalle en la sección Sprint 1: Entorno de desarrollo.

24

3 Sprint 1: Entorno de desarrollo

3.1 Replanificación Estaba planificado que el anterior sprint costase 40 horas a realizar en 2 semanas. Se ha

realizado en 15 horas durante la primera semana. El proyecto va una semana por delante de lo

planificado.

Con la planificación inicial el último sprint se quedaba corto, realmente era medio sprint. Le

añadiremos la semana extra ahorrada en el sprint 0 para que se convierta en un sprint común.

Sprints:

0. Estudio previo







7. Control de acceso

3.2 Arquitectura del entorno El entorno de desarrollo tendrá los siguientes elementos:

1. Cliente de desarrollo (local)

2. Máquina de desarrollo en remoto (cloud, IaaS)

3. Máquina de producción (cloud, PaaS)

4. Repositorio de control de versiones (cloud, SaaS)

Ilustración 8: Entorno de desarrollo genérico

25

Ventajas del entorno

La arquitectura del entorno de desarrollo no ha sido elegida al azar. Se ha diseñado buscando

una serie de ventajas

Desarrollo en cloud. Las herramientas instaladas en la máquina local serán las mínimas

imprescindibles para conectar al servidor de desarrollo.

o Sólo hay que montar un entorno de desarrollo aunque se desarrolle desde

múltiples dispositivos.

o No hay problemas de sincronización de código entre distintos dispositivos.

o No hay problemas de diferencias de configuración entre distintos dispositivos

(en una máquina funciona pero en otra no).

Uso de control de versiones.

Uso de servidor de producción.

o Los cambios se publican a medida que se van realizando.

o El código empieza a dar servicio lo antes posible.

o Feedback de los usuarios.

Entorno elegido

Para cada uno de los elementos descritos existen varias soluciones en el mercado. En el Anexo

8: Herramientas de desarrollo se describen las alternativas, explicando los puntos fuertes y

desventajas de cada una. También se detallan las decisiones tomadas y las razones de las

mismas.

1. Cliente SSH. Cygwin. Ventajas: interfaz cómoda y muy completo en funcionalidades.

2. Máquina de desarrollo. Digital Ocean. Ventajas: Barato, rápido (SSD). Diseñado para

desarrolladores de software.

3. Máquina de producción. Heroku. Ventajas: Barato, simple de usar. El código heredado

ya estaba alojado en una instancia de heroku.

4. Control de versiones. Bitbucket. Ventajas: Barato, simple. El código heredado ya se

encontraba en Bitbucket.

26

Ilustración 9: Entorno de desarrollo elegido

3.3 Automatización Se automatizarán todos los procesos posibles siguiendo la filosofía DevOps. En nuestro caso

esto incluye:

Creación y puesta a punto de la máquina de desarrollo.

o Instalación de Rails

o Instalación y configuración del IDE / editor de texto

Conexión de la máquina de desarrollo con la máquina de producción.

o Creación/intercambio de certificados SSH

o Instalación de herramientas Heroku para el paso a producción

El uso de la terminal es clave en estas automatizaciones. Toda tarea que se realice a través de

una terminal de comandos es automatizada de manera trivial. El código fuente del script que

realiza estas tareas tiene el mismo tratamiento que el código de la aplicación. También debe

ser de calidad, estar incluido en un sistema de control de versiones y evolucionar a lo largo del

tiempo.

En resumen:

Se hará un uso intensivo del cloud computing.

Se integrará paso a producción en el ciclo de vida del sprint (DevOps).

Se automatizarán los procesos del ciclo de desarrollo (DevOps).

El entorno de desarrollo será independiente del dispositivo que se esté usando.

27

4 Sprint 2

4.1 Replanificación El anterior sprint se terminó con una semana de antelación, costando 16 horas de trabajo. El

sprint 2 podría haber empezado una semana antes de lo previsto. Por razones ajenas al

proyecto no se ha podido avanzar trabajo en dicha semana. El sprint 2 finalmente ha

empezado cuando estaba previsto que lo hiciera.

Sprints:

0. Estudio previo








4.2 Decisiones de diseño Se han tomado una serie de decisiones respecto a la arquitectura que tendrá el sistema. El

principio fundamental en el que se han basado estas decisiones ha sido mantener la

independencia entre el cliente web y el servidor.

4.2.1 Desactivación de Cross Site Request Forgery (CRSF)

Hasta ahora el sistema no ha manejado la autenticación de los usuarios. Los usuarios tenían

otras prioridades en el desarrollo de las funcionalidades. Está planificado que en el futuro se

implemente un sistema de autenticación.

Por defecto Rails incorpora todo un sistema de protección contra ataques CSRF (ver Glosario).

Este sistema para prevenir los ataques CSRF complica el desarrollo de la aplicación. Cuando

llegue el momento de implementar la autenticación se estudiarán las medidas de seguridad a

implantar. Ése será el momento de volver a activar la protección contra CSRF.

4.2.2 Distribución del cliente web

Existen dos formas de distribuir el cliente web. La primera consiste en montar un servidor

nuevo sólo para este propósito. La segunda es realizar dicha distribución desde el mismo

servicio que alberga el backend.

La primera opción implica tener un segundo servidor y obligar a los usuarios a utilizar una URL

nueva para acceder al servicio. La segunda opción ahorra costes en infraestructura y molestias

a los usuarios. También implica que el código de ambos sistemas ha de estar en el mismo

repositorio.

Se decide utilizar el mismo servidor para mantener bajos los costes de infraestructura.

28

4.2.3 API/Esquema de navegación

Interfaz heredada

La interfaz ofrecida por la aplicación heredada sólo maneja una entidad de negocio que

representa la ficha de personaje. En el universo ficticio de FanHunter dichos personajes se

denominan narizones.

La interfaz de la aplicación heredada gira en torno a las operaciones CRUD aplicadas a los

narizones.

Método HTTP URL / URI / Recurso Significado

URIs naturales del servicio

GET /narizones Muestra todas las fichas

GET /narizones /:id Muestra una ficha concreta

POST /narizones Crea una nueva ficha

PUT /narizones /:id Cambia una ficha

DELETE /narizones /:id Borra una ficha

URIs exclusivamente necesarias para la navegación web

GET /narizones /:id/edit Formulario HTML para editar una ficha

GET /narizones /new Formulario HTML para añadir una ficha

Hasta ahora el servidor respondía a estas peticiones. Nuevo flujo de navegación de las URIs:

Leyenda:

Rectángulo rosado: URL ciega (no genera HTML)

Rectángulo verde: URL con layout

Flecha unidireccional: flujo de un solo sentido

Flecha bidireccional: flujo de doble sentido

Flecha roja: flujo en caso de error

29

Interfaz del nuevo sistema

La nueva arquitectura se basa en una doble interfaz. Por una parte tenemos la interfaz entre el

navegador y el cliente web. Por otra parte tenemos la interfaz entre el cliente web y el servicio

web (backend).

La interfaz ofrecida por el cliente web al navegador emulará las URLs con layout del sistema

heredado. Los usuarios no tendrían que notar el cambio. Sus marcadores, favoritos y URL’s

guardadas seguirán funcionando.

La interfaz ofrecida por el servicio web implementará las URIs naturales del servicio. La interfaz

del servicio web no tiene el concepto de flujo de navegación.

Método HTTP URL / URI / Recurso Significado

GET /narizones Muestra todas las fichas

GET /narizones /:id Muestra una ficha concreta

POST /narizones Crea una nueva ficha

PUT /narizones /:id Cambia una ficha

DELETE /narizones /:id Borra una ficha

POST /prototipos Comprueba la validez de los datos de una ficha

A los métodos naturales del servicio se ha añadido un método POST /prototipos. Este

método resuelve el problema de la validez de los datos.

En el futuro se irán añadiendo más URIs conforme se vaya necesitando acceso a más entidades

/ funcionalidades. Por ejemplo, el requisito de mostrar información sobre coñas, poderes y

taras podría ser soportado por el servidor mediante URIs del estilo GET /conas, GET

/taras, GET /poderes.

En el sistema heredado siempre que se crea o actualiza una ficha de personaje se realiza una

comprobación de la validez de los datos. Si hay algún error, se redirige al usuario a la página de

creación/edición. Con el nuevo sistema el usuario recibe feedback continuo conforme rellena

los datos en la aplicación. Es necesario que el backend ofrezca al cliente web un método que

valide una ficha a medio rellenar.

30

En resumen:

De momento no se contempla la implantación de seguridad / autenticación.

El cliente web se distribuirá desde el mismo servidor en el que reside el backend. Sólo

estarán conectados por un fichero de configuración.

El sistema heredado tenía un solo API para la navegación y la ejecución de acciones.

El nuevo sistema tendrá un API para el flujo de navegación y otro para el backend.

4.3 Cambios en la arquitectura

4.3.1 Pila de tecnologías

4.3.2 Directorios

Los cambios realizados en arquitectura han tenido su reflejo en la estructura de directorios. Se

ha eliminado la capa de vista del servidor y se ha creado un cliente que incluye modelo,

controlador y nuevas vistas. En la Ilustración 10: Ficheros eliminados podemos ver los ficheros

que sobraban en el servidor marcados en rojo. El detalle de este sistema de ficheros se explica

en el Anexo 4: Estructura de una aplicación Ruby on Rails.

31

Ilustración 10: Ficheros eliminados

En la Ilustración 11: Ficheros añadidos se muestran los ficheros y directorios que han sido

creados en la iteración.

32

Ilustración 11: Ficheros añadidos

El directorio public es parte del framework Rails. Es el lugar donde se aloja el contenido

estático. Desde el punto de vista de la aplicación todo lo que esté en dicho directorio es como

una caja negra. Si un cliente o navegador le pide el contenido lo sirve tal cual.

Las plantillas del cliente angular.js (archivos .html) se encuentran en el directorio public.

Los ficheros JavaScript escritos durante el sprint están en public/js. El fichero config.js

contiene los parámetros de la aplicación que pueden variar durante el despliegue de la misma

(por ejemplo, la ip/url del servidor). El fichero fh.js contiene el código angular.js (modelo

y controlador).

El directorio public/js/lib contiene los ficheros JavaScript escritos por terceros. Aquí se

encuentra angular.js junto con sus dependencias. Lo mismo ocurre con bootstrap.js y

sus dependencias.

El directorio public/css contiene los ficheros css. En principio no ha sido necesario escribir

ningún fichero css así que el directorio sólo contiene los css del framework bootstrap.

33

4.4 Objetivos alcanzados Durante este sprint no se ha logrado terminar la creación del cliente angular.js. Ha habido más

problemas de los esperados en la integración del modelo de datos del cliente con el del

servidor. La aplicación maneja en un mismo formulario una decena de entidades anidadas.

Intercambiar estas entidades ha generado complicaciones y obliga a replantear el diseño de la

aplicación.

Aspectos implementados

Reforma del servidor. Acepta / genera JSON en vez de HTML.

Adaptación de las plantillas al estilo de angular.js.

Creación de sistema de navegación entre plantillas en angular.js.

Controlador angular.js que recupera los datos del servidor y los inyecta en la plantilla.

Controlador angular.js que envía al servidor la petición de borrado de datos.

Aspectos por implementar

Modelo de datos. Envío de datos nuevos / actualizados en una estructura reconocible

por el servidor.

34

5 Sprint 3

5.1 Replanificación El sprint 2 consumió 37 horas de trabajo. El anterior sprint se dejó una parte de la

funcionalidad por implementar. Se alarga la implementación de la funcionalidad al sprint 3. De

momento queda eliminado el último sprint.

Sprints:

0. Estudio previo


2. Cambios básicos en la arquitectura. Reforma del servidor y creación del cliente web (1)






8. Control de acceso (excluido del alcance)

5.2 Desarrollo del sprint Durante este sprint se han seguido desarrollando los cambios en la arquitectura. Dado que ha

sido una continuación de lo explicado en el anterior sprint, no hay mucho más que explicar.

5.3 Objetivos alcanzados Al final del sprint se ha logrado cambiar la arquitectura.

Tras desplegar la nueva versión de la aplicación los usuarios han manifestado que el tiempo de

respuesta ha mejorado notablemente. Ya no les supone un problema. Esto es lógico puesto

que el problema en el tiempo de respuesta venía dado por la composición de fragmentos de

plantillas en el servidor. La mejora de los tiempos de respuesta ha sido un beneficio colateral

del cambio de arquitectura.

35

6 Sprint 4

6.1 Replanificación El sprint 3 costó 35 horas de trabajo que es aproximadamente lo que estaba planificado.

Ya se han realizado cambios básicos en la infraestructura. El Sprint de mejora de tiempos de

respuesta ya no es necesario (ver sprint 3: Objetivos alcanzados). Para compensar este

beneficio se reintroduce el punto que se eliminó en el sprint 3 (control de acceso).

Las tres siguientes características a implementar (Incluir descripciones de coñas, taras y

poderes en el formulario, Autorrellenado de campos e Información del saldo de puntos

disponible) están directamente relacionadas con la experiencia de usuario y la manera de

asistir el proceso de rellenado de la ficha. Se decide realizar un rediseño de toda la interfaz

aplicando técnicas de evaluación de usabilidad e implementar las características como parte

del rediseño.

Sprints:

0. Estudio previo




4. Rediseño de la interfaz y evaluación de usabilidad

5. Mejora de los tiempos de respuesta. A veces es de varios segundos (beneficio colateral

del cambio de arquitectura).

6. Implementación de la nueva interfaz (1)


8. Control de acceso (re incluido en el alcance)

6.2 Evaluaciones de usabilidad Durante este sprint se intenta realizar tantas iteraciones en el refinamiento de la interfaz como

sea posible. Todos los procesos a realizar requieren la implicación de terceros. Se planifican los

diferentes procesos en función del coste que tiene reunir a las personas necesarias.

En primer lugar se realiza una evaluación heurística de la interfaz existente (ver Ilustración 5:

Formulario añadir del Sprint 0: Estudio previo). Para ello se recurre a alumnos de GII que están

cursando la asignatura sobre interfaces de usuario. Después se realizan evaluaciones mediante

la técnica de hablar en voz alta con usuarios que no conocen FanHunter pero sí tienen

conocimientos de Ingeniería Informática y usabilidad. Por último se intenta citar a los usuarios

reales de la aplicación aunque reunirlos no es tarea fácil. Algunos viven fuera de la ciudad y

otros suelen estar muy ocupados. Tras un proceso de negociación se logra citar a la mayoría de

los usuarios para el día 13 de Abril aprovechando que durante la semana santa algunos

usuarios vuelven a Logroño.

36

6.3 Evaluación heurística 3 expertos en usabilidad (alumnos de GII) realizan una evaluación heurística.

Perfil de los evaluadores

Conocimientos de Ingeniería Software

Conocimientos básicos de Usabilidad

Experiencia con juegos de rol de mesa

Sin experiencia previa con FanHunter

La evaluación consta de dos partes. La primera es cuantitativa y se basa en la puntuación de

una serie de ítems en una escala de puntos variable. La segunda es un informe cualitativo en el

que se describen en lenguaje natural las observaciones de los expertos.

Para acceder a las evaluaciones heurísticas, ver el Anexo 12: Evaluaciones de usabilidad.

6.3.1 Evaluación cuantitativa

La evaluación por ítems la realiza cada experto de manera individual. Para cada ítem de la

evaluación se establece una puntuación máxima (5 puntos, 10 puntos, 7 puntos,…) y el

evaluador asigna una puntuación entre 0 (el ítem no se cumple en absoluto) y la puntuación

máxima (el ítem se cumple completamente) al sistema software.

Estos ítems están agrupados en categorías (ej. claridad de propósito y objetivos, Visibilidad y

orientación inmediata,…). Para cada categoría se realiza un cálculo del nivel de conformidad

del sistema evaluado en base a la agregación de los ítems.

Se toman en cuenta las categorías peor puntuadas para prestarles especial atención en el

diseño de los prototipos en papel. Cada evaluador realizó unas puntuaciones diferentes pero

había varias categorías que parecían estar peor puntuadas en las tres evaluaciones.

1. Eficacia en los mensajes de error

2. Documentación de ayuda

3. Prevención de errores gracias a un diseño adecuado

4. Claridad de propósito y objetivos

5. Adecuación al mundo, los objetivos mentales del usuario y la lógica de la información

6.3.2 Evaluación cualitativa

Después de realizar la evaluación cuantitativa de manera individual los expertos se reúnen y

realizan una evaluación cualitativa combinando sus impresiones. Esta evaluación es un

documento de texto corto (2 – 3 páginas) en la que los expertos hablan sobre los principales

problemas que han encontrado en la interfaz y dan algunas sugerencias para mejorarlo.

Problemas

Es necesario conocer a fondo el juego para ser capaz de crear un personaje

La documentación es larga y difícil de comprender

La aplicación no rellena por defecto los valores conocidos

No se comprueba la validez de los datos introducidos

37

Interfaz demasiado recargada, demasiados datos en pantalla a la vez

Interfaz sosa, aburrida

Sugerencias

Dividir el proceso de creación de ficha en varios pasos

Incluir ayudas a lo largo de toda la interfaz

Validar datos y dar feedback al usuario sobre los errores que pueda estar cometiendo

6.4 Prototipos en papel

6.4.1 Objetivos del diseño

Se utiliza la información obtenida en la evaluación heurística para establecer unos principios u

objetivos que guíen el nuevo diseño de la aplicación.

Principios

Minimalismo

Informatividad

Facilidad de aprendizaje

Experiencia positiva

El minimalismo persigue reducir la cantidad de información que se le presenta al usuario en

cada momento. La interfaz actual está muy recargada (toda la información está en el mismo

formulario). Se busca realizar una interfaz en la que al usuario sólo se le muestre la mínima

cantidad de información relevante en cada momento.

La informatividad consiste en darle al usuario la información que necesite para realizar su

tarea. En la interfaz actual apenas se da información sobre el significado de los campos a

efectos del juego o sobre la corrección de los mismos. La interfaz debe de dar información

suficiente como para que un usuario novel en el juego de rol pueda crear la ficha sin

problemas y sabiendo en cada momento qué le falta o sobra a su ficha para ser correcta.

La facilidad de aprendizaje implica que los elementos de la interfaz se comporten como el

usuario espera y estén siempre a mano, así como minimizar la cantidad de dudas que le surgen

la primera vez que utiliza el sistema.

La experiencia positiva persigue que los usuarios se sientan a gusto utilizando la aplicación.

Cuando un usuario entra en la aplicación debe de sentir el deseo de seguir utilizándola por el

mero placer que ello le produce.

Para acceder a los prototipos en papel, ver el Anexo 12: Evaluaciones de usabilidad.

6.4.2 Primer prototipo

6.4.2.1 Diseño

El prototipo consiste en una serie de formularios que asisten al usuario en la generación de las

distintas partes de la ficha. Se ha optado por un sistema lineal. El prototipo pide una pequeña

porción de información, ayuda al usuario a introducirla y después pasa a la siguiente porción

38

de información. Para simplificar la tarea en cada momento sólo se permite al usuario modificar

los datos que se muestran y pasar a la siguiente pantalla. Esta fragmentación de la tarea en

varios pasos mejora el minimalismo.

Se introducen cuadros de texto con ayudas dinámicas para mejorar la informatividad. Siempre

hay un recuento de puntos (de atributo, de habilidad o libres según sea pertinente) visible en

pantalla. En cada pantalla del prototipo hay un espacio reservado para describir los

componentes en uso. Si el usuario selecciona un atributo, habilidad, poder, coña o tara el

sistema le muestra un cuadro con la descripción de dicho elemento según el manual de juego.

Se introduce paginación en la pantalla principal (listado de personajes) para mejorar el

minimalismo. Así se evita que el usuario tenga que realizar un scroll indefinido en caso de que

haya muchas fichas y quiera ver una en concreto.

6.4.2.2 Evaluación

El primer prototipo se evalúa con Juan Francisco Díez-Leglise y Ramón María Carnero, alumno

y exalumno de GII respectivamente. Durante la evaluación se utiliza la técnica de pensar en voz

alta.

Se realizan grabaciones sonoras de las evaluaciones realizadas con Ramón.

Perfil de los evaluadores

Conocimientos de Ingeniería Software

Conocimientos básicos de Usabilidad


Sin experiencia previa con FanHunter

Conclusiones

La navegación lineal que sólo permite ir hacia adelante resulta molesta. Los usuarios

sienten que no pueden controlar el flujo de la aplicación. Si se equivocan en algo y lo

quieren cambiar se ven obligados a dar un montón de pasos.

Agradecen los mensajes de ayuda pero a veces se vuelven un poco cargantes. Les

gustaría que fueran algo más discretos.

Sienten que la interfaz sigue siendo bastante sosa. Echan en falta alguna ilustración,

algo que les haga pasárselo bien rellenando la ficha.

El autorrellenado de las habilidades gratuitas es confuso. No entienden la norma que

les da habilidades gratis y cuando ven que algunas habilidades empiezan por encima

de 0 se extrañan.

La selección de poderes, taras y coñas se les hace muy agobiante. En la misma pantalla

tienen decenas de ellos entre los que elegir.

El uso de líneas discontinuas para indicar “aquí se puede añadir una nueva entidad”

(poder, tara, coña, habilidad opcional) les resulta confuso. Preferirían tener un botón

con el símbolo ‘+’.

39

El listado de fichas podría mejorarse agrupando de alguna manera las fichas en función

de las aventuras que van a jugar (si un jugador va a participar en una aventura, es

común que le interesen las fichas del resto de los participantes).

6.4.3 Segundo prototipo

6.4.3.1 Diseño

El segundo prototipo se basa en navegación por pestañas estableciendo secciones separadas

para elegir el arquetipo, los atributos y habilidades, los poderes, las taras y las coñas. De esta

manera se mantiene el minimalismo sin tener los problemas de navegabilidad / vuelta atrás

que había en el prototipo 1.

También se introduce el concepto de tarjeta que experimenta con la posibilidad de ampliar la

representación de las taras, coñas y poderes. En vez de limitarla al nombre y precio del

elemento se plantea crear una pequeña tarjeta que incluya también una imagen

representativa. Esta idea persigue el principio de experiencia positiva, intentando reducir la

sensación de “interfaz sosa” que tenían los usuarios en el prototipo 1.

En la pantalla principal con el listado de personajes se muestran los personajes agrupados por

aventuras para comprobar qué acogida tiene esta idea entre los usuarios.

En la pantalla de atributos y habilidades, de manera inicial se muestran sólo los atributos. Las

habilidades asociadas están ocultas en forma de desplegable bajo los atributos para mantener

el minimalismo.

Para solucionar el problema de las habilidades gratuitas se cambia la manera de auto

rellenarlas. En lugar de mostrar la habilidad con el valor ya rellenado se muestra un ‘+1’ o un

‘+2’ a lado de la misma según corresponda. Además se incluye una flecha que une el atributo

con el mensaje ‘+1/2’ para intentar dejar claro de dónde viene el valor.

Al añadir nuevas habilidades opcionales se sustituye el uso de líneas discontinuas por el

símbolo ‘+’.

Se introduce una función de autoguardado. Cada vez que el usuario cambia un elemento se

muestra un mensaje “guardando…”.

Se utilizan las reglas de negocio para agrupar las coñas, taras y poderes en categorías. Por

ejemplo, los poderes se agrupan en función del atributo que tienen asociado y se destacan

aquellos que probablemente interesarán al jugador en función de la puntuación que hayan

asignado a su atributo. Las taras se agrupan en función de su valor en puntos y las coñas en

función de si el personaje puede o no pagarlas. De esta manera se intenta mejorar el

minimalismo.

Se experimenta con varias formas de mostrar las taras, coñas y poderes que han sido

incluidos en la ficha de personaje. En la sección de poderes cuando se añade un poder a la

ficha éste se muestra como una tarjeta de texto. En la sección de taras se muestra la tarjeta

con el nombre, valor y descripción siempre que se pincha en un ítem, se añada o no a la ficha.

Si además se añade a la ficha, se muestra una tira horizontal con el nombre de la tara y su

40

valor. En la sección de coñas cuando se añade un ítem se muestra una tarjeta con el nombre,

descripción y coste del ítem y además se añade una ilustración.

6.4.3.2 Evaluación

El segundo prototipo se evalúa con Juan Francisco Díez-Leglise y Ramón María Carnero, igual

que el primero. Durante la evaluación se vuelve a utilizar la técnica de pensar en voz alta.

Conclusiones

Los usuarios manifiestan que el uso de pestañas les parece una gran mejora. De hecho

consideran que es la mejora más significativa introducida en el prototipo.

Les gusta el uso de tarjetas, especialmente la usada en la sección de coñas con

ilustración.

Les gusta la idea del autoguardado pero a veces les resulta molesto que se auto guarde

con tanta frecuencia.

Les parece que la selección de poderes, taras y coñas ha mejorado algo en lo

agobiante que era pero sigue teniendo demasiada información visible en pantalla.

Les gusta que en “poderes” el sistema proporcione sugerencias sobre qué poderes

elegir.

Echan en falta tener toda la información sobre la ficha a la vista siempre. Las pestañas

les gustan para añadir elementos a la ficha pero echan en falta poder ver los datos

básicos de la misma (nivel de los atributos así como poderes, taras y coñas elegidas)

sin tener que cambiar de pantalla.

En las colecciones de las que hay que elegir (arquetipo, poderes, coñas y taras) echan

en falta tener un buscador. Eso les ayudaría mucho a hacer la ficha más rápido en caso

de que tuvieran claro lo que quieren elegir.

Parece que les gusta la idea de que las fichas estén agrupadas por aventuras.

41

7 Sprint 5

7.1 Replanificación El sprint 4 costó 36 horas de trabajo que es aproximadamente lo que estaba planificado.

Durante las evaluaciones de usabilidad surgieron nuevas ideas sobre cómo mejorar la interfaz

que justifican un tercer y último prototipo antes de empezar la implementación. Además hasta

ahora no se ha tenido la posibilidad de probar los prototipos con los usuarios reales, se espera

que eso cambie en la evaluación del tercer prototipo.

Dado que al final se dedicará un sprint extra a la evaluación de usabilidad, el control de acceso

vuelve a quedar fuera del alcance.

Sprints:

0. Estudio previo




4. Rediseño de la interfaz y evaluación de usabilidad (1)




8. Control de acceso (excluido en el alcance)

7.2 Tercer prototipo Para acceder al tercer prototipo, ver el Anexo 12: Evaluaciones de usabilidad.

7.2.1 Diseño

En este prototipo se incluyen varias mejoras para intentar subsanar los problemas que

encontraron los usuarios en el segundo prototipo. Las más importantes son:

Uso de carrusel para elegir elementos de una colección

o http://getbootstrap.com/javascript/#carousel

Introducción de un mini-resumen con la información básica de la ficha en un lateral

Introducción de una barra de navegación en la parte superior de la pantalla

La barra de navegación se utiliza para tener siempre accesibles las distintas secciones de la

aplicación. En el tercer prototipo estas secciones son la portada, las aventuras, las fichas, FAQ y

el login. Además se reserva un trozo de la barra de navegación para mostrar la principal acción

en cada contexto (añadir ficha en la sección fichas, añadir aventura en la sección aventuras,

inscribirse en una aventura en los detalles de una aventura, guardar ficha en los detalles de

una ficha,…). Se hace necesaria en el momento en el que se introduce la gestión de aventuras.

Dicha gestión se introduce en vista de la buena acogida que tuvo en el segundo prototipo la

agrupación de las fichas por aventuras.

El mini-resumen es un pequeño cuadro de información que aparece en el lateral izquierdo de

la pantalla de detalle de ficha. Este mini-resumen muestra el nombre y arquetipo elegidos, el

42

valor de los atributos y una miniatura por cada tara, poder o coña que tenga el personaje. Es

visible en todas las pestañas del proceso de creación de ficha. Con esto se pretende arreglar

las quejas de los usuarios sobre tener que cambiar de pestaña para volver a ver los datos de su

personaje. El mini-resumen también incluye un recuento de los puntos disponibles (puntos de

atributo, puntos de habilidad y puntos libres).

También se ha añadido una pestaña de vista previa que muestra todos los datos detallados de

la ficha para ver si les gusta más o menos que el mini-resumen.

Se ha introducido una portada. Durante la evaluación heurística inicial uno de los problemas

detectados fue la falta de claridad respecto al propósito. Los usuarios no sabían muy bien para

qué servía la página. En la portada se les da la bienvenida y se enumeran las principales

funciones de la aplicación. La mayor parte de la portada está ocupada por una imagen para

mitigar la sensación de la que interfaz es “sosa” y hacer sentir a los jugadores en un entorno

amigable.

Se ha cambiado el auto guardado. Ahora sólo se muestra el mensaje “guardando…” cuando el

usuario cambia de pestaña.

Se han introducido símbolos de interrogante (‘?’) a lo largo de toda la interfaz. Estos símbolos

son una forma de introducir ayuda sin colapsar el espacio de la pantalla y la atención de los

usuarios. Cuando un usuario pincha en un símbolo de ayuda se muestra una pequeña ventana

emergente con un breve texto de ayuda contextual. Al final del cuadro de ayuda se muestra un

enlace a la FAQ pertinente para que el usuario pueda ampliar más la información si lo desea.

Uno de los problemas que tenían los usuarios era la ingente cantidad de poderes, taras y

coñas que se mostraban al mismo tiempo por pantalla para poder elegir una de ellas. Este

problema queda parcialmente resuelto con el carrusel. Ahora todas las taras, coñas, poderes

y/o arquetipos conviven con los demás ítems de su categoría en un mismo carrusel. Esto ayuda

a crear una interfaz limpia pero no elimina del todo el problema, sólo lo mueve de sitio. Antes

el problema era que se mostraban muchos elementos por pantalla. Ahora el problema es que

los usuarios tienen que moverse muchas posiciones a lo largo del carrusel para llegar al ítem

que buscan. Para solventar esto se han incluido categorías en las taras, coñas y poderes y un

buscador. Cuando el usuario pincha en una categoría el contenido del carrusel cambia para

mostrar sólo el de dicha categoría. Por ejemplo, los poderes tienen como categoría su atributo

asociado. En la selección de poderes el usuario tiene un listado con los 8 atributos. Si pincha en

un atributo el contenido del carrusel se actualiza para mostrar los poderes asociados al mismo.

De esta manera sólo se muestra 4 – 5 poderes en el carrusel en cada momento. Las taras y las

coñas se agrupan de manera similar mediante su valor y su coste. Además se ha incluido un

buscador para los jugadores que tienen muy claro que ítem que quieren. Cuando escriben un

poder, coña o tara en el buscador el carrusel pasa a contener el resultado de la búsqueda.

Ahora el listado de fichas ya no es una tabla con múltiples datos textuales de la ficha. En lugar

de eso las fichas se muestran como un mosaico de fotos. Esto implica que uno de los campos

en la creación de personaje es una imagen. Esta imagen se manda a la aplicación mediante el

uso de “drag & drop”. Es decir, arrastrando una imagen del sistema de archivos sobre una

zona de la interfaz.

43

7.2.2 Evaluación

En la evaluación del tercer prototipo se vuelve a contar con la inestimable ayuda de Juan

Francisco Díez-Leglise y Ramón María Carnero. Además, para esta evaluación de usabilidad se

logra reunir a los usuarios reales de la aplicación. A todos ellos se les aplica la técnica de

pensar en voz alta.

En esta ocasión se numeran las páginas de la interfaz en papel y durante la sesión de

evaluación se anuncia en voz alta el número de cada hoja conforme aparece. Esto tiene como

objetivo facilitar el posterior análisis de las grabaciones.

Perfil de los nuevos evaluadores

Conocimiento de Ingeniería Software variable (algunos tienen un conocimiento básico,

otro no tienen)

Sin conocimientos de Usabilidad


Expertos en FanHunter

Conclusiones

En general les gusta mucho la interfaz. El uso de carrusel y del mini-resumen les ha

parecido una mejora sustancial respecto a la anterior interfaz.

A los usuarios les gusta la idea de tener una sección de FAQ. Varios de ellos entran en

ella aunque no forme parte de la tarea que se les ha encomendado.

Tener las acciones a realizar en la barra superior de navegación resulta confuso para

los usuarios.

Les confunde que los atributos empiecen replegados. A algunos les cuesta bastante

darse cuenta de que hay que pincharlos para desplegar las habilidades. En general

dicen estarían más a gusto si las habilidades estuvieran siempre visibles.

Prácticamente todos los usuarios expertos entienden a la primera el significado del

‘+1’ ó ‘+2’ al lado de las habilidades gratuitas.

La existencia de un botón “guardar ficha” resulta confusa existiendo autoguardado.

Prefieren un botón “volver”.

En la pantalla 4 (detalle de aventura) les extraña no poder pinchar sobre ninguno de

los elementos. Uno de los usuarios esperaba poder comunicarse con otros jugadores a

través del mensaje de aviso.

Algunos entienden enseguida el funcionamiento de los cuadros “drag & drop” para

insertar imágenes. Otros se quedan un poco confusos al verlo. Con mayor o menor

dificultad parece que todos terminan entendiéndolo.

En general parece que a los jugadores expertos les ha gustado más seleccionar

poderes, taras y coñas utilizando el buscador que navegando por las categorías.

A algunos usuarios les ha confundido que no aparezca el carrusel hasta que pinchan en

una categoría o utilizan el buscador.

Los jugadores expertos se percatan de que si se eligieran muchos poderes, taras y

coñas en la misma ficha podría haber problemas de espacio en el mini-resumen.

45

8 Sprint 6

8.1 Replanificación El sprint 5 costó 53 horas de trabajo realizadas en dos semanas. De ellas, 30 fueron dedicadas

a trabajar en la experiencia de usuario. Las 23 horas restantes se dedicaron a mejorar la

memoria del proyecto y maquetar prototipos interactivos. La memoria del proyecto necesitaba

profundizar en la explicación de la naturaleza de los juegos de rol y del funcionamiento de

FanHunter. Los prototipos interactivos sirven para mostrar el funcionamiento y evolución de

los prototipos en papel.

El sprint 6 se dedica a maquetar el HTML necesario para la nueva interfaz.

Sprints:

0. Estudio previo








8.2 Dificultades encontradas La maquetación del HTML y el CSS realizada en este sprint termina costando algo más de lo

esperado. Se pretendía haber terminado rápidamente con el layout y haber realizado una

parte de la programación JavaScript antes de terminar el sprint. Una parte importante del

retraso ha estado relacionado con el elemento carrusel, que es un elemento es relativamente

complejo.

8.3 Objetivos alcanzados Durante este sprint se logra implementar toda la maqueta con el HTML y los estilos CSS

necesarios para determinar la estética de la aplicación (ver Anexo 10: Maqueta de la interfaz).

Queda para el siguiente sprint implementar el código JavaScript que enlace todos los

elementos.

Al final del sprint sobran algunas horas que se dedican realizar autoformación en las

características avanzadas de JavaScript (ver Bibliografía). Esto incluye programación funcional,

metaprogramación y Programación Orientada a Objetos basada en prototipos (sin clases).

46

9 Sprint 7

9.1 Replanificación El sprint 6 consumió 38 horas de trabajo. De ellas, 30 fueron dedicadas a implementar la

maqueta HTML. Las 8 horas restantes se dedicaron a autoformación (lectura de Secrets Of The

JavaScript Ninja).

El sprint 6 se dedica a escribir el código JavaScript necesario para hacer funcionar la aplicación.

En la implementación se utiliza lo aprendido en la autoformación para hacer un código DRY

(ver Glosario).

Sprints:

0. Estudio previo








9.2 Dificultades encontradas Durante este sprint se han encontrado varios retos que han hecho más costosa la

implementación

Poca experiencia con el uso de programación funcional

Conocimiento básico de angular.js

Escritura de código elegante y mantenible

9.3 Objetivos alcanzados La implementación ha sido más lenta de lo esperado por la razones explicadas en el apartado

anterior. Durante este Sprint se logra implementar una gran parte de la funcionalidad

necesaria para que se puedan crear fichas de manera básica. Para el próximo sprint quedará

terminar de hacer funcionar la interfaz y si da tiempo agregar algunas reglas de negocio.

47

10 Sprint 8

10.1 Replanificación El sprint 7 consumió 34 horas de trabajo. De ellas, 32 fueron dedicadas a implementar el

código JavaScript del cliente en angularjs. El cliente aún no ha sido terminado y aún quedan

unas 36 horas antes de agotar el tiempo del proyecto.

Se alarga el proyecto un sprint más para terminar de programar el cliente.

Sprints:

0. Estudio previo









10.2 Lógica de negocio Como parte del diseño de la interfaz es necesario dar información a los usuarios sobre cuántos

puntos han gastado y cuántos les quedan por gastar. Esto implica implementar la lógica de

negocio que rige el recuento de puntos.

10.2.1 Requisitos

La lógica de negocio tiene que tener en cuenta las siguientes normas:

Existen diferentes tipos de puntos. Los más comunes son puntos de atributo, puntos

de habilidad y puntos libres.

En principio cada elemento (atributo, habilidad, habilidad opcional, poder o coña) se

paga con el tipo de punto más específico posible.

Todo puede ser pagado con puntos libres. Si no quedan puntos del tipo apropiado para

pagar un elemento, se usarán puntos libres.

Un atributo se puede pagar con un punto de atributo o con 4 puntos libres.

Una habilidad o habilidad opcional se puede pagar con un punto de habilidad o con 1

punto libre.

Los poderes y coñas se pagan siempre con puntos libres, el precio depende de qué

poder o coña sean.

Las taras aportan puntos libres que se pueden utilizar para comprar otros elementos,

la cantidad de puntos que aporta depende de la tara.

Existen otros puntos más específicos. Por ejemplo, puntos que sólo se pueden gastar

en un atributo de Carisma o puntos que se intercambian por un poder o coña

específico. Normalmente estos puntos especiales están asociados a un arquetipo

concreto.

48

Si la ficha está utilizando más puntos de los que dispone, se considera que debe

puntos libres. El sistema debe de notificar cuántos puntos libres extra serían

necesarios para pagar todo lo que incluye la ficha.

Algunos arquetipos tienen reglas de pago diferentes. Por ejemplo, el arquetipo “super”

sólo tiene que pagar la mitad de puntos cuando compra un poder.

10.2.2 Diseño Ilustración 12: Lógica de negocio

La lógica de negocio gira en torno a tres conceptos: Saldo, Punto e Intento. El Saldo

representa la capacidad para adquirir elementos (atributos, habilidades, coñas, poderes,…). El

Punto representa un elemento que debe de ser pagado.

Los Saldos se agrupan en el Monedero, los Puntos en la Factura y los Intentos en el

Cobrador. El método de más alto nivel de todo el diseño es “pagar()”, método del Narizón.

Cuando se invoca el método pagar() el Narizon recorre todos sus elementos (atributos,

habildades,…) y les pide que informen sobre cuáles son los Puntos que deben de pagarse para

que estos elementos estén legalmente en la ficha. Esto lo hace a través del método privado

“generar_factura()”. A continuación pregunta al Arquetipo de qué Saldos dispone

sirviéndose del método privado “generar_monedero()”. En este punto el sistema ya sabe

qué puntos se han de pagar y de qué saldos se dispone. El siguiente problema es emparejarlos.

49

El Intento representa una asociación entre un Saldo y un Punto. Un Saldo podrá utilizarse

para pagar un Punto determinado cuando haya un Intento que los asocie. Por ejemplo, el

Intento que tenga como tipo de saldo “SaldoDeAtributo” y como tipo de punto

“PuntoDeAtributo” buscará todos los saldos de punto de atributo del monedero y los

utilizará para pagar tantos puntos de atributo como sea posible. De esto se encarga el método

“realizar_cobro()”

El Cobrador tiene una relación con todos los Intentos aceptables por el sistema. De alguna

manera es una representación de algo nivel de las reglas que rigen qué puntos pueden ser

pagados por qué saldos. En ese sentido es el corazón de la lógica de negocio. Cuando se invoca

su método “pagar(monedero, factura)” el Cobrador recorre todos los Intentos e invoca

su método realizar_cobro().

A veces un Punto tiene que cambiar de naturaleza para poder ser pagado. Por ejemplo, si no

hay un punto de atributo y cuatro saldos de punto libre (y se han agotado los saldos de

atributo) el sistema debería de pagar el punto con los saldos de punto libre. Para realizar esta

operación se destruye el punto de atributo y se añaden 4 puntos libres al Monedero. De esta

manera, cuando se llegue al intento que tiene como tipo de saldo “SaldoDePuntoLibre” y

como tipo de punto “PuntoLibre” se podrá realizar el pago. Este intento no tiene la

necesidad de conocer cuál era el origen inicial de estos 4 puntos libres.

Al proceso que convierte los puntos de un tipo (que no se han podido pagar) en puntos de otro

tipo (con la esperanza de que así puedan ser pagados) se le denomina descomponer. Todas las

clases que heredan de “Punto” implementan el método “descomponer()”. El atributo

“ultima_oportunidad” del Intento regula cuándo se debe de descomponer un Punto.

10.3 Objetivos alcanzados Durante este Sprint se termina de implementar la funcionalidad necesaria para que se puedan

crear fichas de manera básica. También se logra implementar una versión muy básica de las

reglas de negocio. La aplicación realiza un recuento básico de los puntos que le quedan al

narizón por gastar.

Si bien no todas las reglas de negocio y elementos de la interfaz funcionan, la mayor parte de

la infraestructura necesaria ya está en marcha. El trabajo que queda por realizar sólo tiene que

seguir el camino marcado por el código fuente existente.

Hay un bug conocido que por el momento no sale rentable arreglar. Está relacionado con los

apartados “poderes”, “taras” y “coñas”. En todas estas pestañas hay varios botones y un

carrusel. Los botones deben de servir para cambiar el subconjunto de los poderes, taras o

coñas que se muestran en el carrusel. A veces, cuando se pulsa un botón el carrusel

desaparece. Esto parece ser un bug de una de las librerías usadas para generar el carrusel.

http://stackoverflow.com/questions/23682324/angularjs-ui-bootstrap-carousel-component-

not-updating-with-the-model-change

Se revisarán periódicamente las actualizaciones de la librería para comprobar si arreglan el

bug.

http://stackoverflow.com/questions/23682324/angularjs-ui-bootstrap-carousel-component-not-updating-with-the-model-change

http://stackoverflow.com/questions/23682324/angularjs-ui-bootstrap-carousel-component-not-updating-with-the-model-change

50

11 Gestión del tiempo El proyecto comenzó el 4 de Febrero de 2014 y terminó el 8 de Mayo de 2014. El reparto de

horas entre los sprints se muestra en la siguiente tabla:

Horas

sprint 0 15

sprint 1 16

sprint 2 37

sprint 3 35

sprint 4 36

sprint 5 53

sprint 6 38

sprint 7 34

sprint 8 37

Total 301

La Ilustración 13: Reparto del tiempo muestra el reparto de las 301 horas, segmentado por

tareas.

Ilustración 13: Reparto del tiempo

51

12 Trabajo futuro Cuando se diseñó el prototipo de interfaz en papel se incluyeron muchas características. De

todas ellas sólo se ha logrado implementar un subconjunto básico, lo imprescindible para

poder crear fichas de personaje. La mayor parte de las características que faltan por

implementar quedaron reflejadas en el tercer prototipo de interfaz en papel.

Para un futuro quedan los siguientes puntos por mejorar

1. Generar la ficha en PDF


3. Gestión de aventuras

4. Bugfix: problemas al cambiar el contenido del carrusel

5. Seguir implementando reglas de negocio (mensajes de ayuda)

6. Mejorar el comportamiento del sistema en casos de concurrencia

7. Añadir un subsistema de gasto de puntos de experiencia

8. Añadir un subsistema de compra de ítems (equipación de los personajes)

9. Añadir imágenes que representen las taras, coñas, poderes y arquetipos.

10. Permitir a los usuarios subir a la aplicación una foto que represente a su personaje.

11. Añadir descripciones de las taras, coñas, poderes y arquetipos.

12. Añadir ayuda contextual sobre los conceptos del juego.

13. Añadir iconos para los atributos.

Los puntos están ordenados por importancia. El primer punto (y el más importante) a resolver

es la generación de fichas en pdf. Al fin y al cabo, el objetivo último de la aplicación es que los

jugadores generen una ficha en papel que posteriormente puedan utilizar en la mesa de juego.

Se han investigado varias opciones para generar pdfs:

JavaScript

HTML

Ruby

En JavaScript la herramienta más usada con diferencia es jsPDF. Esta herramienta trabaja a

muy bajo nivel: permite diseñar prácticamente cualquier pdf pero requiere mucha

programación imperativa.

http://mrrio.github.io/jsPDF/

Respecto a HTML, el trabajo es bastante más liviano. Existen muchos servicios web que

generan pdfs a partir de URLs, utilizando el HTML como layout. El problema de estos sistemas

es que no dan ninguna flexibilidad sobre cómo se genera el pdf: es un calco de la web.

http://html2pdf.fr/es

En Ruby hay varias librerías que permiten generar pdfs. Prawn es una de las más populares.

Todas estas herramientas tienen un problema similar al que existe en JavaScript: el trabajo es

muy de bajo nivel, con programación imperativa.

http://prawnpdf.org/api-docs/

http://mrrio.github.io/jsPDF/

http://html2pdf.fr/es

http://prawnpdf.org/api-docs/

52

A la vista del estado de la tecnología, la tarea de generar fichas de personaje en pdf se divide

en dos fases. La primera fase consiste en generar un layout HTML que presente la ficha en un

formato adecuado para ser impreso y utilizar herramientas tipo HTML a PDF para generar el

documento.

En una segunda fase se utilizará una herramienta JavaScript o Ruby (probablemente se use

jsPDF) para generar exactamente el pdf que los usuarios quieren y esperan. Esta segunda fase

requerirá mucho más tiempo y será menos prioritaria.

El segundo punto a implementar en un futuro sería el control de acceso. Una vez que se

programe el control de acceso, el menú “Fichas” de la barra superior dará acceso a dos

submenús (ver y editar). Cuando el usuario pinche en “ver” le aparecerán todas las fichas y si

selecciona una de ellas podrá revisarla pero no modificarla. Cuando pinche en “editar” le

aparecerán sólo sus fichas y cuando seleccione una de ellas podrá modificarla.

El tercer punto a implementar sería la gestión de aventuras, que se implementaría tal y como

se muestra en el tercer prototipo de interfaz. Para acceder al tercer prototipo, ver el Anexo 12:

Evaluaciones de usabilidad.

53

13 Conclusiones El desarrollo del sistema se ha apoyado en el servicio que ya existía y ha renovado toda la capa

de la interfaz. Durante el desarrollo se ha utilizado una de las tecnologías más recientes en su

campo (angular.js) y se ha puesto mucho empeño en realizar un trabajo de calidad. Además,

se ha utilizado el paradigma de programación funcional en JavaScript. Se han utilizado técnicas

DevOps para automatizar las tareas relacionadas con la liberación al público de las diferentes

versiones. También se ha realizado un proceso de evaluación de usabilidad al que se le ha

dedicado una parte importante del proyecto. Se ha adoptado un estilo de desarrollo ágil

dividiendo el trabajo en sprints de dos semanas al final de cada cual se realiza una

replanificación.

En general el desarrollo no se ha separado demasiado de la marcha esperada. En las primeras

iteraciones se ha ganado tiempo frente a lo previsto: tanto escritura de la documentación

como la preparación del entorno de desarrollo se han realizado de manera eficiente. Durante

las siguientes iteraciones el ritmo ha sido ligeramente más lento de lo esperado. Esto se debe

a intentar realizar un código de calidad sin tener un conocimiento especialmente profundo

de las tecnologías. En varias ocasiones el desarrollo se ha visto retrasado por el empeño en

diseñar y codificar el sistema de una manera muy elegante, invirtiendo mucho esfuerzo en

evitar repeticiones de código. También se ha dedicado algo más de tiempo de lo esperado en

las evaluaciones de usabilidad en papel. A la vista del diseño resultante parece que ha

merecido la pena.

Durante todo el proceso de desarrollo ha habido una profunda pasión como elemento

motivador. Esta pasión se debe tanto al gusto por la tecnología en la que se estaba

profundizando como al tema del proyecto en sí mismo.

Las tecnologías utilizadas son de muy alto nivel. Tanto en el cliente como en el servidor se han

utilizado frameworks relativamente modernos y sofisticados (Ruby on Rails, Angular.js).

Utilizar frameworks suele tener una ventaja: te hacen una parte del trabajo. Al mismo tiempo,

suele tener una desventaja: si te sales del camino marcado por el framework, la

implementación se vuelve mucho más costosa.

Durante el desarrollo se han vivido las ventajas y desventajas. Respecto a las desventajas, en

algunas ocasiones ha sido necesario realizar pequeños cambios en el diseño de la aplicación

para que encajase con el framework. Respecto a las ventajas, la velocidad de desarrollo ha

sido mucho más rápida de lo que habría sido con otros frameworks o sin usar frameworks. La

mayor parte del código fuente escrito se centra en aspectos del dominio de la aplicación; el

código necesario para gestionar la propia tecnología es mínimo.

El balance que se obtiene al poner en la balanza los aspectos positivos y negativos es muy

satisfactorio, el ahorro derivado del uso de los frameworks ha sido superior a los problemas

que han generado.

54

14 Anexo 1: Versiones de la aplicación URL repositorio: bitbucket.org/obprado/fanhunterrails

Tipo de repositorio: GIT

Commits

Primer prototipo

Hash: e8030afd6d50b94e226d401d07dd63d57fc99de1

URI:

https://bitbucket.org/obprado/fanhunterrails/commits/e8030afd6d50b94e226d401d0

7dd63d57fc99de1

Segundo prototipo

Hash: 0127c65f01f97603ac80b0ccefeaf3c9729e7be3

URI:

https://bitbucket.org/obprado/fanhunterrails/commits/0127c65f01f97603ac80b0ccef

eaf3c9729e7be3

Tercer prototipo

Hash: c1c3d145ba2a6ad715b7c2e347c52a83cd07cf5c

URI:

https://bitbucket.org/obprado/fanhunterrails/commits/c1c3d145ba2a6ad715b7c2e34

7c52a83cd07cf5c

Cuarto prototipo

Hash: eb3053c4a6593a66bbffcf52f7fe92f97ca6a64a

URI:

https://bitbucket.org/obprado/fanhunterrails/commits/eb3053c4a6593a66bbffcf52f7f

e92f97ca6a64a

Quinto prototipo (tras el sprint 3)

Hash: 6d038d7be6fccac388e096026562c89d1fae911d

URI:

https://bitbucket.org/obprado/fanhunterrails/commits/6d038d7be6fccac388e096026

562c89d1fae911d

Sexto prototipo (tras el sprint 8)

Hash: 4af30abe8c4e0ba0b683f758b5400a870d4eeb82

URI:

https://bitbucket.org/obprado/fanhunterrails/commits/4af30abe8c4e0ba0b683f758b

5400a870d4eeb82

https://bitbucket.org/obprado/fanhunterrails/commits/6d038d7be6fccac388e096026562c89d1fae911d

https://bitbucket.org/obprado/fanhunterrails/commits/6d038d7be6fccac388e096026562c89d1fae911d

55

15 Anexo 2: SPA SPA ó Single Page Application es un estilo de diseño de aplicaciones web. En una aplicación

web SPA la página web que se envía al navegador contiene una funcionalidad equivalente a la

de un cliente nativo. Este cliente suele implementar un patrón MVC que se encarga de

gestionar toda la capa de presentación. Se comunica con el servidor utilizando tecnologías

estándar de representación de datos de la web (JSON, XML, AJAX). Las aplicaciones web SPA

hacen un uso intensivo de JavaScript en el lado del cliente. Se caracterizan por dar una

experiencia de uso mucho mejor que los anteriores sistemas basados en la generación de

páginas web en el servidor.

56

16 Anexo 3: Juego FanHunter. Manual El juego de rol FanHunter se rige por las normas descritas en el manual homónimo que se

adjunta en un fichero externo. Eso significa que las reglas de negocio están descritas en el

manual. En cierta manera el manual realiza las funciones de Documento de Requisitos

Software.

Para entender las funcionalidades básicas del software legado es necesario consultar los

apartados Creación de narizones (páginas 7 – 12) y Arquetipos (páginas 13 – 20). En menor

medida puede ser útil leer la primera página de las secciones poderes (página 21), taras

(página 49) y coñas (página 41).

Para un futuro se contempla la implementación de la compra de equipo y del uso de los

puntos de experiencia. Estas reglas de negocio están explicadas en las secciones ¡Vamos de

compras! (página 91) y Experiencia (páginas 98 – 99).

57

17 Anexo 4: Estructura de una aplicación Ruby on Rails

17.1 Esquema Base de datos

o Migraciones

o Fichero de semillas

Modelo

o Entidades de negocio. ActiveRecord

o Inflector

Presentación

o Controlador. ActionController

o Vista. Plantillas haml

o Dispatcher routes.rb

17.2 Migraciones Las migraciones representan cambios en la estructura de la base de datos. Son ficheros con

código ruby que utilizan un DSL (Domain Specific Language, lenguaje específico de dominio)

para describir los cambios en el esquema de la base de datos.

El enfoque tradicional para realizar estos cambios en la mayoría de los sistemas es el uso de

ficheros SQL que contienen el estado de la base de datos. Las migraciones proporcionan dos

ventajas fundamentales sobre estos ficheros SQL: abstracción y automatización.

La abstracción se refiere a la capacidad de los ficheros de migración para generar cambios en

el esquema independientemente del SGBD-R utilizado. El DSL de las migraciones es traducido

en tiempo de ejecución al dialecto SQL del motor que se está utilizando.

La automatización se refiere a la facilidad para reproducir los cambios en diferentes entornos.

La forma tradicional de trabajar con el esquema de la base de datos suele pasar por la edición

manual del esquema durante la fase de desarrollo. Cuando llega el momento de realizar el

despliegue del software, se reproducen los cambios de manera manual en el entorno de

producción. Las migraciones automatizan este proceso. Una migración describe una serie de

cambios respecto a un esquema dado. Estos cambios son reproducibles y automatizables.

Ejemplo

1ª Iteración: Creación de la clase persona

Versión tradicional:

Se crea en la base de datos la tabla persona con las columnas nombre y edad.

CREATE TABLE persona

(nombre varchar(50),

edad integer );

58

Versión Rails:

Class CreatePersona < ActiveRecord::Migration

def change

create_table 'personas' do |table|

table.string 'nombre'

table.string 'edad'

end

end

end

2ª Iteración: Email

Versión tradicional:

CREATE TABLE persona

(nombre varchar(50),

edad integer,

email varchar(50));

Versión Rails:

Class addEmail < ActiveRecord::Migration

def change

add_column :persona, :email, :string

end

end

Vemos que en la segunda iteración la migración sólo contiene los cambios asociados a la

iteración. El script SQL sin embargo contiene toda la información relativa al estado de la base

de datos en cada momento. En la migración es más fácil saber qué ha cambiado en la iteración.

Lo más interesante de las migraciones es que el historial de versiones del estado de la base de

datos queda reflejado como el conjunto de los ficheros de migración. La aplicación de las

migraciones es Idempontente.

En resumen

Las migraciones utilizan un DSL para definir la estructura de la base de datos.

El DSL está abstraído del SGBD-R utilizado en la aplicación.

La aplicación de migraciones es Idempotente.

17.3 Fichero de Semillas En muchas ocasiones es necesario poblar la base de datos con valores iniciales determinados

por las normas del negocio. Para automatizar este proceso existe el fichero de semillas,

seeds.rb.

Ejemplo

Persona.create(nombre: 'German', edad: 17, email: '[email protected]')

Persona.create(nombre: 'Elise', edad: 34, email: '[email protected]')

Persona.create(nombre: 'Richard', edad: 22, email: '[email protected]')

59

17.4 Entidades de negocio. ActiveRecord Las entidades de negocio en Rails implementan el patrón ActiveRecord. Dicho patrón consiste

en incluir en la misma clase la entidad de negocio y las funcionalidades necesarias para

gestionar su relación con la base de datos.

En Rails prácticamente todo el código que realiza estas funciones se genera en tiempo de

ejecución. Lo único que tiene que hacer el programador es declarar sus entidades de negocio

como subclases de ActiveRecord::Base.

Ejemplo

class Persona < ActiveRecord::Base

end

En el momento en el que se hereda de ActiveRecord::Base se genera una asociación entre

la clase Persona y la tabla personas. Se generarán de manera automática métodos getters y

setters para las propiedades nombre, edad e email. Se generarán automáticamente métodos

create(), save(), find() y destroy() entre otros. Estos métodos son capaces de

interactuar con la base de datos para realizar operaciones CRUD.

Para que funcione la asociación entre la clase Persona y la tabla personas se utiliza el principio

convenion over configuration. Existe un componente de Rails llamado Inflector que se encarga

de realizar inferencias.

17.5 Inflector El inflector es un componente de Rails encargado de realizar transformaciones en cadenas de

caracteres y entidades similares. Algunos ejemplos de sus funcionalidades:

Pasar a plural: 'person'.pluralize => 'people'

Convertir en clase: 'persona_mayor'.classify => 'PersonaMayor'

Formato personas: 'cuenta_bancaria'.humanize => 'Cuenta bancaria'

Convertir a tabla: 'CuentaBancaria'.tableize => 'cuentas_bancarias'

En la sección “Entidades de negocio. ActiveRecord” hemos creado una entidad de negocio.

Dicha entidad recurre al Inflector para encontrar la tabla de la base de datos que le

corresponde. Todo esto ocurre de manera transparente al programador.

17.6 Controlador Los controladores son subclases de ActionController::Base. Definen métodos que son

invocados cuando el servidor recibe peticiones web. La asociación entre las peticiones web y

los métodos del controlador las define el dispatcher, routes.rb.

Ejemplo

class PersonasController < ActionController::Base

def index

@personas = Persona.all

end

60

def create

@persona = Persona.create params[:persona]

redirect_to personas_path

end

…

end

17.7 Dispatcher El dispatcher es el componente encargado de asociar las peticiones con los controladores. Para

realizar esta asociación se basa en la URL y el verbo HTTP de la petición. Su configuración se

realiza en el fichero routes.rb.

Está diseñado para facilitar la implementación de una interfaz REST (ver Anexo 5: Estilo

arquitectónico REST).

Ejemplo

DemoApp::Application.routes.draw do

resources :personas

end

Mediante mecanismos de convenion over configuration este ejemplo generaría las siguientes

rutas:

Método HTTP URL / URI / Recurso Método Significado

URIs propias del servicio

GET /personas Index Muestra todas las personas

GET /personas/:id Show Muestra una persona concreta

POST /personas create Crea una nueva persona

PUT /personas/:id update Cambia una persona

DELETE /personas/:id destroy Borra una persona

URIs exclusivamente necesarias para la navegación web

GET /personas/:id/:edit edit Formulario HTML para editar una persona

GET /personas/new new Formulario HTML para añadir una persona

17.8 Vista La vista en Ruby on Rails es en esencia un sistema de plantillas, como es costumbre en los

frameworks de desarrollo web. Hay dos sistemas de plantillas ampliamente usados en Rails:

erb y haml.

Erb tiene una sintaxis muy similar a la de la mayor parte de sistemas de plantillas clásicos. La

mayor parte de la plantilla es html y en algunos puntos se incluyen etiquetas con código ruby.

Haml tiene una notación mucho más compacta que elimina las marcas de final y reduce las

etiquetas a la mínima expresión. Esta notación obliga a usar el tabulado del código manera

semántica: se sabe qué etiquetas están anidadas dentro de otras en base a su tabulación.

61

Ejemplo

Erb Haml <section class=”container”>

<h1><%= post.title %></h1>

<h2><%= post.subtitle %></h2>

<div class=”content”>

<%= post.content %>

</div>

</section>

%section.container

%h1= post.title

%h2= post.subtitle

.content

= post.content

62

18 Anexo 5: Estilo arquitectónico REST El estilo arquitectónico REST (REpresentational State Transfer) es una forma de diseñar

interfaces para servicios web. Fue descrito por primera vez por Roy Fielding en su tesis

doctoral en el año 2000.

Su tesis propone cambiar las interfaces web basadas en llamadas remotas (RPC) por interfaces

basadas en recursos. En las interfaces basadas en llamadas remotas las diferentes

funcionalidades expuestas por un servicio se definen como un conjunto de métodos.

Ejemplo

getTodasLasPersonas()

getPersona(id)

newPersona(persona)

updatePersona(persona)

deletePersona(id)

En las interfaces basadas en recursos los métodos a usar están definidos por un estándar y la

interfaz del servicio consiste en una colección de recursos. A cada uno de estos recursos se le

asocia uno o varios de los métodos fijados de antemano por el estándar.

Ejemplo

Método HTTP URL / URI / Recurso Equivalente estilo RPC

GET /personas getTodasLasPersonas()

GET /personas/:id getPersona(id)

POST /personas newPersona(persona)

PUT /personas/:id updatePersona(persona)

DELETE /personas/:id deletePersona(id)

63

19 Anexo 6: Arquitectura SOA SOA (Service Oriented Architecture; Arquitectura Orientada a Servicios) es una arquitectura

diseñada para proporcionar un alto nivel de modularidad entre los componentes de un

sistema distribuido. Se ha popularizado con la proliferación de servicios web que son los que

normalmente la aplican.

En una arquitectura SOA un sistema software se compone de multitud de pequeños servicios

que interaccionan mediante interfaces estándares de la web. Esto la diferencia de los sistemas

cliente-servidor clásicos en los que el servidor solía ser un sistema monolítico. Los servicios en

los que se descompone el sistema pueden estar construidos con tecnologías completamente

diferentes. Además estos servicios son independientes y fáciles de sustituir y coordinar por

servicios de terceros.

Esta ventaja de modularidad que proporciona SOA se paga con un mayor coste en la definición

de interfaces. Por lo tanto, la rentabilidad del uso de una arquitectura SOA depende de

manera directa del coste (tanto operacional como en desarrollo) del uso de interfaces web. En

los últimos años las herramientas para construir interfaces web se han hecho cada vez más

eficientes tanto a nivel operacional como a nivel de desarrollo. Esto ha sido crucial en la

popularización de SOA.

Se denomina estilo arquitectónico a los criterios de diseño utilizados a la hora de definir

dichas interfaces. En entornos SOA los más comunes son RPC y REST. REST suele ser

considerado como un estilo de diseño más ligero. Es el más reciente de los dos y ha ganado

mucha popularidad en los últimos años.

El formato de intercambio de datos también ha cambiado a lo largo del tiempo. Los formatos

más comunes de intercambio de datos entre servicios son XML y JSON. JSON suele ser

considerado más ligero y ha ganado mucha popularidad en los últimos años.

En resumen

SOA es una arquitectura modular para sistemas distribuidos.

Un sistema SOA está formado por servicios que interaccionan mediante interfaces web

La principal pega de SOA es el coste de la definición de las interfaces web.

En los últimos años está ganando fuerza la tendencia a utilizar REST y JSON.

64

20 Anexo 7: DevOps DevOps (Developers & Operations) es una metodología de trabajo para desarrolladores

software que trata de integrar y automatizar su trabajo con la administración de sistemas.

Cuando un desarrollador termina de implementar un cambio en el software tiene que

contactar con el departamento de sistemas para ponerlo en funcionamiento. Este proceso

tiene un coste. En algunos casos el coste puede ser de horas o incluso días de trabajo.

Durante los últimos años la frecuencia con la que se incluyen cambios en un sistema software

se ha incrementado drásticamente.

Década Frecuencia con la que se ponen cambios en funcionamiento

80’ Años

90’ Meses

00’ Semanas

Actualidad Días. A veces varias al día.

Esta vertiginosa frecuencia en el despliegue de cambios en el software es especialmente

acusada en desarrollos ágiles. La velocidad en los cambios exige que su coste sea lo menor

posible. Si se realizan varios depliegues al día no es operativo tardar varias horas en realizar un

despliegue.

DevOps engloba el conjunto de herramientas tecnológicas, procesos y cultura de trabajo

necesarios para automatizar el proceso. Existen muchas herramientas para alcanzar estos

objetivos. La más básica suele ser escribir scripts para la Shell de Unix que automaticen el

trabajo. En los últimos años han aparecido otras herramientas más sofisticadas como Chef o

Puppet.

En resumen

La frecuencia de despliegue de servicios se ha disparado en los últimos años.

DevOps trata de integrar y automatizar el trabajo de desarrollo y sistemas.

DevOps no sólo trata sobre herramientas, también sobre los procesos y la cultura de la

organización.

65

21 Anexo 8: Herramientas de desarrollo

21.1 Descripciones Amazon EC2: Amazon posee un amplio catálogo de servicios en la nube. EC2 o Elastic Cloud

Computing es el nombre del servicio básico de alquiler de máquinas. Las instancias micro son

las más baratas (la primera es gratuita) y menos potentes de toda la gama. Su oferta pertenece

a la categoría IaaS.

Heroku: Servicio para el despliegue de aplicaciones web. Facilita la infraestructura para

servidores de producción. También proporciona herramientas que facilitan enormemente el

paso de desarrollo a producción. Muchos de sus esfuerzos enfocan en facilitar la escalabilidad.

Pertenece a la categoría PaaS.

Engine Yard: Servicio para el desarrollo y despliegue de aplicaciones web. Ofrece una

infraestructura para el desarrollo de aplicaciones sobre ruby on rails. Es uno de los servicios

más completos y complejos de su categoría. Pertenece a la categoría PaaS.

Codio: IDE en formato de aplicación web. Tiene las ventajas propias de las aplicaciones web

(multiplataforma, sincronización automática del código). Actualmente su principal debilidad es

el desarrollo en el lado del servidor. El sistema no incluye servidor sobre el que probar el

código. Existe la posibilidad de conectar la aplicación a un servidor de terceros, pero no es

trivial. Pertenece a la categoría SaaS.

GitHub: Uno de los sistemas de control de versiones más conocidos. Soporta toda la

funcionalidad esperable. Pertenece a la categoría SaaS.

Bitbucket: Ídem a GitHub.

Digital Ocean: Proveedor de cloud especializado en proporcionar servidores para

desarrolladores que quieran tener su entorno de desarrollo en la nube. Estos servidores se

llaman Droplets. Pertenece a la categoría PaaS.

21.2 Decisiones

Cliente de desarrollo

Cliente SSH (Cygwin, putty)

o Uso exclusivo por terminal de comandos

o Simplicidad en la conexión con el backend de desarrollo

Navegador + Aplicación web Codio

o Interfaz web para la edición de código

o Requiere un servidor de desarrollo externo. Complejidad en la integración con

el mismo.

La decisión implica poner en la balanza la complejidad de integrar codio con el servidor y la

inconveniencia de editar el código fuente por línea de comandos. El desarrollador ya tiene

experiencia editando el código fuente por línea de comandos.

Se elige la conexión directa al servidor de desarrollo por SSH.

66

Máquina de desarrollo

Instancia micro de Amazon EC2

o Gratuita

o Instalación Ubuntu automatizada

Instancia de Amazon EC2 gestionada por Engine Yard

o Integración desarrollo-producción

o Herramientas específicas para ruby

o Caro ($40 / mes)

Instancia de Digital Ocean

o Barata ($5 / mes)

o Instalación Ubuntu automatizada

o Disco SSD (alta velocidad en operaciones de disco)

La opción de usar Engine Yard queda descartada por precio. Además, la mayor parte de las

herramientas que proporciona no son necesarias en un entorno tan básico como el que se está

manejando aquí. Sería matar moscas a cañonazos.

Amazon EC2 y Digital Ocean ofrecen servicios casi idénticos. Amazon desempata ofreciendo

una instancia micro gratis. Durante el proceso de contratación ha habido problemas

administrativos con Amazon.

El servicio elegido es Digital Ocean.

Entorno de producción

Heroku

o Gratuita

o Orientado a servidores de producción rails

o Ofrece herramientas que facilitan el paso a producción

Engine Yard

o Integración total desarrollo-producción

o Caro ($40 / mes)

o Completo y complejo

Por razones similares a las alegadas en el anterior apartado, Engine Yard no es una buena

opción para esta situación.

Se usará Heroku como servidor de producción.

Servidor de control de versiones

GitHub

Bitbucket

Ambos servicios son muy similares. Hay pequeñas diferencias en sus modelos de precios. En

nuestro caso ambos servicios podrían usarse gratis. Lo único que desempata la decisión es que

el código heredado está alojado en Bitbucket. Si eligiéramos GitHub tendríamos que mudarlo.

67

Se usará Bitbucket como servicio de control de versiones.

68

22 Anexo 9: Agradecimientos A Ramón María Carnero, Francisco José Díez Leglise, Juan Daniel García Irazu, Antonio José

Amor Blanco, Álvaro Molia Romera, Alberto Yoldi Chicapar, Borja y Richard Elvira López-

Echazarreta por participar en las evaluaciones de las interfaces en papel.

A Alvaro García León, David Monforte Ruiz y Eduardo Ruiz Uruñuela por realizar la evaluación

heurística.

A María Vico por su ayuda en todo el TFG.

69

23 Anexo 10: Maqueta de la interfaz

71

24 Anexo 11: Historia del código heredado El proyecto nació del deseo de aprender sobre el framework Ruby on Rails aplicándolo a la

construcción de un sistema software real. El código que luego se tomaría como base en el

Trabajo Fin de Grado fue escrito durante el verano de 2013. Se adoptó un estilo ágil de trabajo,

realizando varias iteraciones en el desarrollo.

24.1 Contexto El proyecto consiste en la realización de un sistema que asista la creación de fichas de

personaje para FanHunter, un juego de rol de mesa (ver 1.2 Juegos de rol de mesa).

Desde el punto de vista técnico la creación de una ficha de personaje implica rellenar los

campos de un formulario. Los valores que pueden tomar dichos campos siguen unas reglas

definidas por el juego.

Tradicionalmente las fichas se han rellenado en papel y la revisión de los valores que toman los

distintos campos se ha realizado manualmente. Esto implica que para rellenar una ficha de

personaje era necesario reunir físicamente al director de juego con el jugador. Varios meses

antes del comienzo del proyecto se creó una aplicación web que asistía a los usuarios en la

creación de la ficha.

24.1.1 Proceso de creación de ficha

El sistema cambió el proceso de trabajo. Sirvió para que los jugadores pudieran realizar un

borrador de la ficha online. El director del juego revisa el borrador de la ficha a través de la

aplicación web. Si se aprueba la ficha de personaje, se pasa a papel. Si se rechaza, se realizan

las modificaciones oportunas y se vuelve a pedir al director del juego que revise la ficha.

Ilustración 14: Proceso de creación de ficha

Este sistema se tomará como base para el proyecto. En primer lugar se pretende mejorar el

sistema existente en aspectos no funcionales. Esto incluye tanto las propiedades técnicas

internas como la experiencia que se proporciona a los usuarios. Una vez realizadas estas

mejoras se plantea la posibilidad de añadir más funcionalidades.

24.2 Primer prototipo La primera versión de la aplicación se desarrolló en menos de una semana (15 – 20 horas). El

objetivo del prototipo era implementar la funcionalidad mínima para poder dar servicio. La

razón de liberar el producto en este estado era obtener feedback lo antes posible para

averiguar si realmente existía por parte de los usuarios interés en usar la aplicación. En caso de

72

que hubiera interés en la aplicación, el feedback se utilizaría para saber qué prioridades tenían

los usuarios respecto a las mejoras y cambios a introducir en el sistema.

Ilustración 15: Listado de personajes (prototipo 1)

Ilustración 16: Formulario añadir (prototipo 1)

73

Ilustración 17: Modelo de datos del prototipo 1

El prototipo era desechable. La interfaz era muy pobre y tenía erratas. El modelo era

demasiado simple para poder responder implementar una lógica de negocio rica en futuras

iteraciones. Aun así, cumplió su función.

74

24.3 Segundo prototipo A pesar de sus carencias, el primer prototipo fue un éxito. Los usuarios empezaron a utilizarlo y

a pedir mejoras. En este punto se hace necesario realizar una refactorización muy seria que

implica reescribir muchas partes del sistema.

La mayor parte de los esfuerzos se centran en refactorizar el modelo de datos. Es necesario

que los atributos, habilidades y habilidades opcionales sean entidades de primera clase.

También es necesario modelar la relación entre la ficha y estas nuevas entidades. Esta

refactorización tiene dos ventajas. La primera es que mejora la mantenibilidad del código

reduciendo duplicidades. La segunda es que facilita la introducción de reglas de negocio

basadas en la relación entre estas entidades.

A petición de los usuarios, se cambia el aspecto del formulario para que se asemeje más al de

la ficha de personaje en papel.

El listado de personajes se mantiene igual.

Ilustración 18: Modelo de datos (prototipo 2)

En el segundo modelo se incluyen entidades separadas para los atributos, habilidades y

habilidades opcionales. Existe una restricción que determina qué habilidades y habilidades

opcionales corresponden a cada atributo. Por ejemplo, el atributo Combate siempre debe de

tener asociadas las habilidades Artes Marciales y Defensa y sus habilidades opcionales deben

de ser todas Maestrías. Artes Marciales y Defensa tienen un valor numérico. Puede no haber

ninguna maestría o haber un número indefinido de ellas. Cada una tiene una especialidad

(Maestría espada, Maestría garrote, Maestría desarmado,…) además de un valor numérico que

representa el nivel de la habilidad.

75

Esta restricción no viene dada de forma natural por el modelo así que se incluye en el proceso

de creación de nuevas entidades Ficha. Cuando se instancia una nueva ficha de personaje el

constructor se encarga de hilar todos estos elementos.

76

24.4 Tercer prototipo Conforme el sistema va mejorando los usuarios van aumentando sus peticiones. En este punto

ya tienen muchas peticiones sobre qué mejoras debería de incluir la aplicación en el futuro.

Con la colaboración de los usuarios se ordenan las mejoras en función de lo importantes que

son para ellos. En este punto los usuarios quieren ampliar la funcionalidad de la aplicación

incluyendo la posibilidad de introducir coñas, taras y poderes en las fichas de personaje.

El listado de personajes se mantiene igual.


En este punto no se introduce ninguna restricción sobre el valor que pueden tener los poderes,

las taras o las coñas. El usuario introduce una cadena de texto que representa lo que quiere. La

validación de los datos se produce más tarde cuando el director del juego revisa la ficha.

77

24.5 Cuarto prototipo En la creación / edición de fichas se sustituyen varios cuadros de texto por menús

desplegables. En concreto, aquellos campos que ahora se eligen de una lista cerrada

(arquetipo, coñas, taras y poderes).

Esto implica un nuevo cambio en el modelo de datos de la aplicación. Por cada una de las

entidades que se pueden elegir de una lista cerrada se ha creado una entidad que representa

dicha lista o catálogo. Para diferenciarlas de la entidad opcional se les ha puesto el sufijo

“_de_catalogo”. Entre estas nuevas entidades se encuentran “coña_de_catalogo”,

“tara_de_catalogo” y “poder_de_catalogo”.

El mismo patrón de los catálogos se aplica a los atributos, las habilidades y las habilidades

opcionales. En este caso la razón no es tener las entidades en cuadros desplegables sino

mejorar la consistencia de los datos. No cualquier habilidad / habilidad opcional puede estar

asociada a cualquier atributo. Y no cualquier combinación de atributos puede ser válida para

una ficha. De hecho las normas del juego exigen que cada ficha tenga 8 atributos concretos y

cada uno de esos atributos tenga 2 habilidades concretas. También obligan a que todas las

habilidades opcionales pertenezcan a una categoría concreta que depende del atributo.

Estas relaciones están sujetas a las normas del juego pero pueden cambiar a lo largo del

tiempo. Por ejemplo, poco antes de la liberación de este prototipo la habilidad opcional de

Músculos era “montar”. Una ficha podía tener “montar caballo”, “montar elefante”, “montar

lagartija”,… En el momento de liberar el prototipo los jugadores decidieron cambiar la

habilidad opcional de músculos por “supervivencia”. A partir de ese momento las fichas podían

contar con “supervivencia jungla”, “supervivencia desierto”, “supervivencia burocracia

administrativa”,… El patrón de catálogos aplicado a atributos, habilidades y habilidades

opcionales permite que la aplicación se adapte a este tipo de cambios sin cambiar el código

fuente, cambiando los catálogos de la base de datos.

Se realizan mejoras visuales en la pantalla de listado de fichas.

A petición de los usuarios, se incluye la funcionalidad de editar y eliminar fichas.

Ilustración 20: Listado de fichas (prototipo 4)

78

Ilustración 21: Formulario añadir (prototipo 4)

79


80

24.6 Resumen Creación, edición, revisión y eliminación de fichas de personaje. Campos incluidos:

o Nombre del personaje

o Nombre del Jugador

o Arquetipo

o Atributos

o Habilidades

o Habilidades opcionales

o Poderes

o Coñas

o Taras

El arquetipo se elige de una lista cerrada

Los poderes, coñas y taras se eligen de una lista cerrada

Rediseño del formulario de creación de personaje para que se emule al formulario en

papel

24.7 Funcionalidades/mejoras por implementar Durante el tiempo de vida de la aplicación los usuarios han detectado varios aspectos por

mejorar.

Les gustaría tener disponible información del manual de juego mientras rellenan la ficha. El

diseño actual de la aplicación da por sentado que el usuario conoce el juego y sabe qué valores

quiere poner en cada lugar de la ficha. Les gustaría que de alguna manera la aplicación

explicase el significado de los elementos que aparecen en pantalla. Esto es especialmente

importante en los campos coñas, taras y poderes. Los detalles sobre el significado de estos

elementos en el juego a veces se escapan incluso a los jugadores avanzados.

El tiempo de respuesta es un problema para algunos usuarios. Actualmente el sistema tarda

entre 1 y 3 segundos en mostrar una ficha de personaje.

Los usuarios desean que el sistema rellene de manera automática algunos campos. Algunos de

los valores de la ficha van quedando determinados por las decisiones del jugador (por ejemplo,

por el arquetipo elegido). A los jugadores les gustaría que la aplicación detectara esta situación

y rellenara los campos automáticamente.

Los usuarios también desean que el sistema les muestre continuamente información sobre el

número de puntos que tienen disponibles para gastar en su personaje. Esta información

cambia a medida que el usuario va introduciendo datos.

Los usuarios desean tener control de acceso en un futuro. Esto permitiría tanto aumentar la

seguridad (evitando que alguien modifique fichas ajenas) como simplificar el uso de la

aplicación (mostrando sólo las fichas relevantes en cada momento). Consideran que este

punto tiene una prioridad baja.

81

Los usuarios desean poder cambiar algunas de las reglas de la aplicación. En concreto, les

gustaría poder cambiar el valor / coste de las taras, coñas y poderes.

A los usuarios les gustaría poder generar un pdf con la ficha. En dicho pdf se mostraría la ficha

tal y como se ve la versión en papel (ver Ilustración 1: Ficha de personaje (Frontal)) pero con

los valores de la ficha sobreimpresos.

El dinero inicial del que disponen los personajes es un dato que obtiene tirando dados.

Actualmente esta parte de la creación de la ficha se realiza reuniendo físicamente al jugador y

al director del juego. Les gustaría tener una funcionalidad que simule los dados y un campo

dinero para almacenar el resultado.

El dinero que obtienen inicialmente los personajes se puede utilizar para comprar diversos

objetos. A los jugadores les gustaría tener una funcionalidad de tienda en la que se pudiera

gastar el dinero obteniendo a cambio objetos que queden guardados junto al resto de la

información de la ficha.

Tras resolver exitosamente una aventura, las fichas de personaje reciben puntos de

experiencia que pueden invertir en obtener mejoras. A los usuarios les gustaría tener un

sistema para gestionar el uso de estos puntos.

En resumen:

Mejora de la experiencia de uso

o Incluir descripciones de coñas, taras y poderes en el formulario

o Mejora de los tiempos de respuesta. A veces es de varios segundos

o Autorrellenado de campos a medida que el usuario va proporcionando datos

o Información del saldo de puntos disponible

Ampliación de funcionalidades

o Control de acceso

o Formulario de cambio de los valores para los poderes, coñas y taras

o Generar la ficha en pdf

o Dados para realizar tiradas

o Tienda para el equipamiento de los personajes

o Sistema de gestión de puntos de experiencia

82

25 Anexo 12: Evaluaciones de usabilidad Durante las evaluaciones de usabilidad se generaron varios documentos que se adjuntan en

ficheros externos a la memoria.

Prototipos de interfaz en papel en PDF => /anexos/usabilidad/prototipos papel

Grabaciones sonoras de las evaluaciones => /anexos/usabilidad/entrevistas

Evaluaciones heurísticas => /anexos/usabilidad/heurísticas

Los prototipos de interfaz en papel digitalizados en PDF sirven para recrear el funcionamiento

del prototipo en papel. El PDF es interactivo: En cada página de la interfaz en papel tiene

resaltado el botón que hay que pulsar para avanzar en la tarea que se propone a los usuarios.

Durante algunas de las evaluaciones se grabó la voz de los usuarios para poder realizar un

análisis exhaustivo a posteriori. No todas las evaluaciones de usabilidad pudieron ser

registradas.

83

26 Bibliografía JavaScript

Secrets Of The JavaScript Ninja. John Resig, Bear Bibeault. Manning, 2013.

Juegos de rol

http://es.wikipedia.org/wiki/Juego_de_rol

Single Page Application

http://en.wikipedia.org/wiki/Single-page_application

Ruby on Rails

https://www.edx.org/course/uc-berkeleyx/uc-berkeleyx-cs169-1x-software-service-1136

http://en.wikipedia.org/wiki/Active_record_pattern

http://api.rubyonrails.org/classes/ActiveSupport/Inflector.html

REST

http://en.wikipedia.org/wiki/Representational_state_transfer

http://rest.elkstein.org/

SOA

http://en.wikipedia.org/wiki/Service-oriented_architecture

DevOps

http://en.wikipedia.org/wiki/DevOps

http://www.slideshare.net/therobot/que-demonios-es-eso-de-devops-y-porquedebera-

interesarme

http://www.getchef.com/

http://puppetlabs.com/

Fundamentos de programación

Apuntes de la titulación

http://es.wikipedia.org/wiki/Juego_de_rol

http://en.wikipedia.org/wiki/Single-page_application

https://www.edx.org/course/uc-berkeleyx/uc-berkeleyx-cs169-1x-software-service-1136

http://en.wikipedia.org/wiki/Active_record_pattern

http://api.rubyonrails.org/classes/ActiveSupport/Inflector.html

http://en.wikipedia.org/wiki/Representational_state_transfer

http://rest.elkstein.org/

http://en.wikipedia.org/wiki/Service-oriented_architecture

http://en.wikipedia.org/wiki/DevOps

http://www.slideshare.net/therobot/que-demonios-es-eso-de-devops-y-porquedebera-interesarme

http://www.slideshare.net/therobot/que-demonios-es-eso-de-devops-y-porquedebera-interesarme

http://www.getchef.com/

http://puppetlabs.com/

84

27 Glosario Convention over configuration: Principio de diseño software que pretende dar un

comportamiento por defecto a los aspectos comunes del desarrollo. Las herramientas que

soportan esta filosofía proveen mecanismos para cambiar el comportamiento en los casos

atípicos.

CRUD: Create, Read, Update y Delete. Conjunto de operaciones básicas de aplicables a un dato

y sobre una base de datos.

CSRF: Cross Site Request Forgery. Vulnerabilidad de seguridad particular de las aplicaciones

web. Esta vulnerabilidad se apoya en la confianza que el servidor tiene en el usuario. El ataque

asociado a la vulnerabilidad se basa en lograr que el usuario realice una petición al servicio sin

saberlo. Uno de los métodos más simples consiste en ofrecer al usuario un enlace al servicio

web legítimo. El acceso a dicho enlace por parte del usuario desencadena la ejecución de una

operación en el servidor sin el conocimiento del usuario.

DRY: Don’t Repeat Yourself. No te repitas. Principio de desarrollo software según el cual es

conveniente evitar el código repetido.

DSL: Domain Specific Language. Lenguaje específico de dominio. Lenguaje de programación

diseñado para una tarea o ámbito concreto, en contraposición al concepto de lenguaje de

propósito general. Algunos ejemplos de DSL son HTML, SQL, CSS, WSDL, SOAP, haml o los

ficheros de migraciones de rails.

FAQ: Frequently Asked Questions. Preguntas frecuentes. Sección de ayuda en la que se

enumeran las preguntas que suelen hacer los usuarios seguidas de su respuesta.

IaaS: Infraestructure as a Service. Servicio cloud en el que se proporciona al cliente una

infraestructura básica: hardware ó hardware + sistema operativo.

Idempotente: Es una cualidad de las operaciones. Una operación se dice idempotente si el

resultado que produce es siempre el mismo independientemente de cuántas veces se aplique.

Ejemplo de operación idempotente: asignar el valor 57 a un campo. Ejemplo de operación NO

idempotente: asignar a un campo su valor actual más 1.

MVC: Modelo Vista Controlador. Patrón de diseño para implementar interfaces de usuario.

Divide la capa de presentación o interfaz en los tres componentes que le dan nombre. La vista

es la representación gráfica de la información. Con frecuencia se implementa mediante

plantillas. El controlador se encarga de asociar las acciones del usuario con la funcionalidad

ofrecida por la lógica de negocio. El modelo se encarga de almacenar la representación de las

entidades de negocio. Con frecuencia se implementa un mecanismo de notificación-

suscripción entre el modelo y la vista.

ORM: Object/Relation Mapping. Herramienta de desarrollo software cuya finalidad es facilitar

la persistencia de objetos en bases de datos relacionales.

PaaS: Platform as a Service. Servicio cloud en el que se proporciona al cliente la infraestructura

necesaria para ejecutar aplicaciones: Contenedor de servlets, servidor PHP, servidor Rails,…

85

RPC: Estilo arquitectónico para el diseño de interfaces en los sistemas distribuidos. Las

interfaces RPC exponen un método por cada operación que se puede realizar sobre el servicio

que las implementa.

SaaS: Software as a Service. Servicio cloud en el que se proporciona al cliente un sistema

software de usuario final: correo electrónico, blog, wiki, almacenamiento de archivos,…

Script Shell: Script diseñado para ser interpretado por una shell. Consiste en la acumulación de

comandos Shell comunes. Al ser ejecutado desencadena la ejecución de todos los comandos

que contiene. Es una forma simple de automatización de tareas.

Script: Programa escrito para ser interpretado por otro programa, en contraposición a los

programas compilados que son interpretados por el procesador del ordenador.

SGBD-R: Sistema Gestor de Bases de Datos Relacional. Es el software encargado de gestionar

bases de datos conforme a los principios de las bases de datos relacionales.

Shell: Intérprete de commandos. Es una herramienta utilizada en sistemas operativos para

introducir órdenes en entornos no gráficos.

Sprint: Cada una de las iteraciones que se realizan en el transcurso de un desarrollo ágil. Estas

iteraciones duran entre 1 y 4 semanas.

SQL: Standard Query Language. Lenguaje diseñado para realizar consultas a bases de datos

relacionales. Con frecuencia cada SGBD-R funciona con su propio dialecto de SQL.

URI: Uniform Resource Identifier. Cadena de caracteres que identifica a un recurso en internet.

Es un concepto más amplio que el de URL, al que sustituye. Una URI no necesariamente

devuelve el recurso representado cuando es accedida. Lo que caracteriza inequívocamente

una URI es su naturaleza de identificador universal. No debe de haber dos URIs iguales en todo

internet. Tampoco debería de haber dos URIs para un mismo recurso.

URL: Uniform Resource Locator. Cadena de caracteres utilizada para localizar recursos en

internet. Accediendo a una URL debe de ser posible recuperar el recurso que representa.

fanhunter: aplicación web para la creación de fichas de personaje

Documents