FanHunter: Aplicación web para la creación de fichas … · juegos de rol de mesa la creación de...
Transcript of FanHunter: Aplicación web para la creación de fichas … · juegos de rol de mesa la creación de...
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.1 Replanificación ............................................................................................................ 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.1 Replanificación ............................................................................................................ 34
5.2 Desarrollo del sprint .................................................................................................... 34
5.3 Objetivos alcanzados ................................................................................................... 34
6 Sprint 4 ................................................................................................................................ 35
6.1 Replanificación ............................................................................................................ 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.1 Replanificación ............................................................................................................ 41
7.2 Tercer prototipo .......................................................................................................... 41
7.2.1 Diseño .................................................................................................................. 41
7.2.2 Evaluación ........................................................................................................... 43
8 Sprint 6 ................................................................................................................................ 45
8.1 Replanificación ............................................................................................................ 45
8.2 Dificultades encontradas ............................................................................................. 45
8.3 Objetivos alcanzados ................................................................................................... 45
9 Sprint 7 ................................................................................................................................ 46
9.1 Replanificación ............................................................................................................ 46
9.2 Dificultades encontradas ............................................................................................. 46
9.3 Objetivos alcanzados ................................................................................................... 46
III
10 Sprint 8 ............................................................................................................................ 47
10.1 Replanificación ............................................................................................................ 47
10.2 Lógica de negocio ........................................................................................................ 47
10.2.1 Requisitos ............................................................................................................ 47
10.2.2 Diseño .................................................................................................................. 48
10.3 Objetivos alcanzados ................................................................................................... 49
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.
[Extraído del manual de juego de FanHunter]
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.
[Extraído del manual de juego de FanHunter]
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.
[Extraído del manual de juego de FanHunter]
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.
[Extraído del manual de juego de FanHunter]
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.
[Extraído del manual de juego de FanHunter]
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.
[Extraído del manual de juego de FanHunter]
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.
[Extraído del manual de juego de FanHunter]
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.
[Extraído del manual de juego de FanHunter]
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.
[Extraído del manual de juego de FanHunter]
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.
[Extraído del manual de juego de FanHunter]
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
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
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
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
7. Control de acceso
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
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 (1)
3. Cambios básicos en la arquitectura. Reforma del servidor y creación del cliente web (2)
4. Incluir descripciones de coñas, taras y poderes en el formulario
5. Mejora de los tiempos de respuesta. A veces es de varios segundos
6. Autorrellenado de campos a medida que el usuario va proporcionando datos
7. Información del saldo de puntos disponible
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
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 (1)
3. Cambios básicos en la arquitectura. Reforma del servidor y creación del cliente web (2)
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)
7. Implementación de la nueva interfaz (2)
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
Experiencia con juegos de rol de mesa
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
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 (1)
3. Cambios básicos en la arquitectura. Reforma del servidor y creación del cliente web (2)
4. Rediseño de la interfaz y evaluación de usabilidad (1)
5. Rediseño de la interfaz y evaluación de usabilidad (2)
6. Implementación de la nueva interfaz (1)
7. Implementación de la nueva interfaz (2)
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
Experiencia con juegos de rol de mesa
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.
44
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
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 (1)
3. Cambios básicos en la arquitectura. Reforma del servidor y creación del cliente web (2)
4. Rediseño de la interfaz y evaluación de usabilidad (1)
5. Rediseño de la interfaz y evaluación de usabilidad (2)
6. Implementación de la nueva interfaz (1)
7. Implementación de la nueva interfaz (2)
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
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 (1)
3. Cambios básicos en la arquitectura. Reforma del servidor y creación del cliente web (2)
4. Rediseño de la interfaz y evaluación de usabilidad (1)
5. Rediseño de la interfaz y evaluación de usabilidad (2)
6. Implementación de la nueva interfaz (1)
7. Implementación de la nueva interfaz (2)
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
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 (1)
3. Cambios básicos en la arquitectura. Reforma del servidor y creación del cliente web (2)
4. Rediseño de la interfaz y evaluación de usabilidad (1)
5. Rediseño de la interfaz y evaluación de usabilidad (2)
6. Implementación de la nueva interfaz (1)
7. Implementación de la nueva interfaz (2)
8. Implementación de la nueva interfaz (3)
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.
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
2. Control de acceso
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/
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
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
70
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.
Ilustración 19: Modelo de datos (prototipo 4)
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
Ilustración 22: Modelo de datos (prototipo 4)
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
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.