Universidad ORT Uruguay
Facultad de Ingenier´ıa
Mazo de naipes virtual
Entregado como requisito para la obtenci´on del t´ıtulo de Ingeniero en Sistemas
Math´ıas Abraham - 220556 Alan Monjard´ın - 214105
Bruno Pintos - 214108
Tutor: Luis Barragu´e
2022
Declaraci ´on de autor´ıa
Nosotros, Math´ıas Abraham, Alan Monjard´ın y Bruno Pintos, declaramos que el trabajo que se presenta en esa obra es de nuestra propia mano. Podemos asegurar que:
La obra fue producida en su totalidad mientras realiz´abamos el proyecto final de carrera de Ingenier´ıa en Sistemas;
Cuando hemos consultado el trabajo publicado por otros, lo hemos atribuido con claridad;
Cuando hemos citado obras de otros, hemos indicado las fuentes. Con excepci´on de estas citas, la obra es enteramente nuestra;
En la obra, hemos acusado recibo de las ayudas recibidas;
Cuando la obra se basa en trabajo realizado conjuntamente con otros, hemos explicado claramente qu´e fue contribuido por otros, y qu´e fue contribuido por nosotros;
Ninguna parte de este trabajo ha sido publicada previamente a su entrega, ex- cepto donde se han realizado las aclaraciones correspondientes.
Math´ıas Abraham 17 de marzo de 2022
Alan Monjard´ın 17 de marzo de 2022
Bruno Pintos 17 de marzo de 2022
Agradecimientos
En primer lugar, nos gustar´ıa agradecer a nuestro tutor durante el proyecto, Luis Barragu´e. Cada uno de sus aportes y consejos fue esencial para el ´exito del proyecto, y su nivel de involucramiento en el mismo otorg´o en todo momento tranquilidad al equipo para llevar adelante el trabajo.
Luego, nos gustar´ıa agradecer a cada uno de los miembros de la Software Factory de la universidad que se tomaron el tiempo de ayudar al equipo en cada una de las instancias en las que se lo necesit´o. Particularmente, entendemos necesario agrade- cer a Amalia ´Alvarez, Gast´on Mousqu´es y ´Alvaro Ortas, quienes entregaron al equipo feedback muy valioso en cada una de las revisiones y en el caso de los primeros dos tambi´en en las reuniones de consultor´ıa realizadas con ellos.
En tercer lugar, queremos agradecer a Gabriel Lambach y Daniel Amoroso, quie- nes proporcionaron la idea que dio lugar al proyecto y actuaron como clientes durante el transcurso del mismo. Su nivel de inter´es y predisposici´on durante todo el proyecto fue clave para poder llevarlo adelante en un ambiente positivo y colaborativo.
Nos gustar´ıa tambi´en agradecer a Luis Calabria, quien se dispuso a realizar una reuni´on con el equipo en la que ofreci´o sugerencias que fueron claves para reestruc- turar el proyecto en su momento m´as complicado.
A su vez, queremos agradecer a cada uno de los integrantes del grupo de prueba que proporcion´o feedback extremadamente ´util para la mejora constante de la soluci´on y a los compa˜neros de trabajo y conocidos que la probaron en sus distintas etapas y entregaron opiniones honestas que permitieron pulirla a´un m´as.
Por ´ultimo, nos gustar´ıa agradecer a nuestros familiares y amigos que otorgaron apoyo durante todo el transcurso del proyecto, ofreciendo consejos muy valiosos y ayudando a mantener la motivaci´on alta en un proceso tan largo y estresante. Sin este soporte, hubiera sido muy dif´ıcil superar algunos de los momentos dif´ıciles vividos.
A todos ellos, muchas gracias.
Abstract
La realizaci´on de reuniones para jugar a las cartas es algo que ha mantenido una enorme popularidad a trav´es del tiempo, no solo a nivel regional sino que mundial. Es muy frecuente que las personas participen de este tipo de juegos, ya sea de manera espont´anea o en reuniones realizadas espec´ıficamente con este prop´osito. Pese al aspecto central que tienen los naipes en reuniones como estas, en la mayor´ıa de los casos su atractivo gira en torno al aspecto social que ofrecen, siendo una instancia ideal para que un grupo de familiares o amigos pueda interactuar en un entorno que mezcla lo competitivo con lo divertido y casual.
Si bien este tipo de actividades ha sostenido una gran relevancia a trav´es de los a˜nos, la pandemia ha sido clave para mostrar una enorme falencia que existe ac- tualmente con ellas: no pueden ser realizadas de manera remota manteniendo los aspectos que las hacen atractivas para sus participantes. Aunque existen algunas so- luciones que permiten realizar estas reuniones a personas que no se encuentran en el mismo lugar f´ısico, el enfoque de las mismas difiere considerablemente de lo que bus- can en la mayor´ıa de los casos los participantes, teniendo una orientaci´on competitiva en la que el aspecto social y de relacionamiento entre los jugadores es inexistente.
Al identificar esta enorme limitaci´on, Gabriel Lambach y Daniel Amoroso se unieron a trav´es del CIE y presentaron la idea a la universidad para generar una soluci´on que permita simular la realizaci´on de las reuniones de manera remota manteniendo su atractivo para todos sus participantes que buscan una atm´osfera positiva y social.
Esta fue la idea que dio lugar al proyecto final de carrera del equipo, en el que se busc´o trabajar sobre ella para validar su utilidad y generar un producto m´ınimo viable que pueda continuar siendo desarrollado por los clientes tras la entrega final.
Desde el comienzo del proyecto, se estableci´o el objetivo de experimentar sobre la idea inicial y refinarla a partir de la investigaci´on realizada y el feedback recibido.
Siguiendo esta filosof´ıa de experimentaci´on, se llev´o a cabo el proyecto y se obtuvo una soluci´on que ofrece una experiencia que se entiende cumple los objetivos, vali- dando la idea inicial de los clientes y permiti´endoles continuar trabajando en ella para eventualmente comercializarla.
Palabras clave
Cartas; Naipes; Reuniones remotas; Videollamadas; Simulaci´on; Phaser; Socket.IO;
Videojuego; Ciclo de vida evolutivo; Experimentaci´on; Producto M´ınimo Viable
Glosario
API: Conjunto de definiciones y protocolos que se usa para dise˜nar e integrar el software de las aplicaciones [1].
Arquitectura basada en eventos: Modelo de arquitectura de software que sirve para dise˜nar aplicaciones en la que la captura, comunicaci´on, procesamiento y permanencia de los eventos son la estructura central de la soluci´on [2].
Asincronismo: Concepto de que m´as de una cosa ocurre al mismo tiempo, o m´ultiples cosas relacionadas ocurren sin esperar a que la previa se haya com- pletado [3].
Back-end: Parte del software que procesa la entrada desde el front-end [4].
Backlog: Acumulaci´on de trabajo incompleto, asuntos que necesitan ser trata- dos o tareas que necesitan ser realizadas [5].
Canvas: Elemento HTML que permite la creaci´on de gr´aficos y animaciones de forma din´amica por medio de scripts [6].
Ciclo de vida evolutivo: Ciclo de vida en el que se realizan fases de requeri- mientos en todas las iteraciones dada su naturaleza din´amica [7].
Comunicaci ´on en tiempo real (RTC): Cualquier comunicaci´on en vivo que ocu- rra sin demoras en la transmisi´on [8].
Commit: Comando de Git que guarda todos los cambios hechos en el repositorio local [9].
Concurrencia: Habilidad de distintas partes de un programa, algoritmo, o pro- blema de ser ejecutado en desorden o en orden parcial, sin afectar el resultado final [10].
Conga: Juego de naipes de la familia del Gin Rummy, aunque se juega con baraja espa˜nola [11].
Drag-and-drop: T´ecnica que facilita la interacci´on del usuario con un programa o aplicaci´on de manera intuitiva para llevar elementos de un lugar a otro [12].
Entorno de ejecuci ´on: Estado de m´aquina virtual que suministra servicios para los procesos de un programa de computadora que se est´a ejecutando [13].
Escalabilidad: Capacidad de un negocio o sistema de crecer en magnitud [14].
Escoba del 15: Juego de cartas de 2 a 5 jugadores que se juega con baraja espa˜nola [15].
Equipo de desarrollo: Rol asignado por Scrum a aquellas personas que reali- zan el trabajo que permite obtener incrementos sobre el producto y cumplir los objetivos del proyecto [16].
Front-end: Parte del software que interact´ua con los usuarios [4].
Git: Sistema de control de versiones [17].
GitHub: Herramienta para gestionar el acceso a repositorios Git [18].
Historia de usuario: T´ecnica informal de especificaci´on de requerimientos que busca redactarlos desde el punto de vista de los usuarios [19].
HTML (HTML5): Lenguaje de marcado para la elaboraci´on de p´aginas web [20].
Incremento: Conjunto de mejoras al producto que lo acercan a los objetivos establecidos [21].
JavaScript: Lenguaje de programaci´on interpretado, orientado a objetos, basado en prototipos, imperativo, d´ebilmente tipado y din´amico [22].
Lenguaje de programaci ´on: Lenguaje con reglas gramaticales bien definidas que le proporciona a una persona la capacidad de escribir una serie de instruc- ciones o secuencias de ´ordenes en forma de algoritmos con el fin de controlar el comportamiento f´ısico o l´ogico de un sistema inform´atico, de manera que se puedan obtener diversos datos o ejecutar determinadas tareas [23].
Lenguaje descripting: Lenguajes de programaci´on que se pueden utilizar para satisfacer r´apidamente las exigencias m´as comunes [24].
Lenguaje de marcado: Forma de codificar un documento que, junto con el texto, incorpora etiquetas o marcas que contienen informaci´on adicional acerca de la estructura del texto o su presentaci´on [25].
Librer´ıa: Colecci´on de paquetes. Su prop´osito es ofrecer un conjunto de fun- cionalidades listas para usar sin preocuparse por los paquetes posteriores. Es lo que se incluye cuando se desea agregar alguna funcionalidad al c´odigo. No impone ning´un estilo de codificaci´on [26].
Manipulaci ´on directa: Estilo de interacci´on en el que se representan los objetos en pantalla y se permite a los usuarios interactuar directamente con ellos como lo har´ıan en el mundo f´ısico [27].
Mantenibilidad: Grado de efectividad y eficiencia con el que un producto o sis- tema puede ser modificado por aquellas personas encargadas de mantenerlo [28].
Metodolog´ıa ´agil: Enfoque para el desarrollo de software que busca distribuir de forma permanente sistemas en funcionamiento dise˜nados con iteraciones r´api- das [29].
Modelo mental: Visi´on del problema que el usuario tiene en su cabeza cuando interact´ua con la soluci´on, producto del conocimiento previo sobre el dominio de la tarea, de la interacci´on con otras soluciones y de la experiencia acumulada en la interacci´on con la soluci´on [30].
Modificabilidad: Capacidad del software de admitir cambios que pueden ser necesarios tanto por un cambio de requerimientos como por la detecci´on de un error que debe ser corregido [31].
Motor de videojuegos: Serie de rutinas de programaci´on que permiten el di- se˜no, la creaci´on y el funcionamiento de un videojuego [32].
Muestra: En el contexto del ‘truco uruguayo’, refiere a la ´ultima carta que se saca del mazo tras repartir las tres cartas a cada jugador. Esta carta determina el palo de las cinco cartas m´as valiosas de la mano [33].
Paquete: Colecci´on de m´odulos de software. Re´une una serie de m´odulos que tienen, en general, el mismo prop´osito funcional, facilitando la inclusi´on de todos los m´odulos relacionados a la vez [26].
Peer-to-peer: M´etodo de intercambio de archivos entre dos o m´as usuarios que establece una conexi´on directa entre ordenadores, sin necesidad de un servicio intermedio, utilizando el protocolo de Internet [34].
Performance: Capacidad de un sistema inform´atico de otorgar respuestas en tiempos menores [35].
Poker: Juego de apuestas en que los jugadores, con todas o parte de sus cartas ocultas, hacen apuestas sobre una puja inicial, recayendo la suma total de las apuestas en el jugador o jugadores con la mejor combinaci´on de cartas [36].
Portabilidad: Caracter´ıstica que posee un software para ejecutarse en diferen- tes plataformas [37].
Product backlog: Lista ordenada de todos los requerimientos a implementar para mejorar el producto [38].
Product owner: Rol asignado por Scrum a aquella persona que entrega feed- back al equipo de desarrollo sobre el producto, permitiendo definir los requeri- mientos a implementar y sus prioridades [39].
Producto m´ınimo viable (MVP): Versi´on m´ınima de un nuevo producto que in- cluye las caracter´ısticas b´asicas para satisfacer las necesidades de los clientes y permite recolectar la mayor cantidad de informaci´on posible [40].
Release plan: Conjunto de historias de usuario (normalmente ´epicas) agrupadas por releases o versiones del producto que se ponen a disposici´on de los usuarios incrementando el valor para estos respecto de la anterior [41].
Renderizar: Acci´on en la que el ordenador dibuja, pinta o representa algo en la pantalla [42].
Scrum: Marco de trabajo que busca ayudar a los equipos a generar soluciones a trav´es de procesos ´agiles [43].
Scrummaster: Rol asignado por Scrum a aquella persona que le entrega asis- tencia al equipo de desarrollo para la aplicaci´on del marco de trabajo [44].
Software Development Kit (SDK): Conjunto de herramientas software que sir- ven para crear aplicaciones mediante un compilador, un depurador (debugger) o un framework [45].
Sistema de gesti ´on de paquetes: Colecci´on de herramientas que sirven para automatizar el proceso de instalaci´on, actualizaci´on, configuraci´on y eliminaci´on de paquetes de software [46].
Sprint backlog: Conjunto de requerimientos a implementar en una iteraci´on, buscando cumplir los objetivos establecidos para ella [47].
Sprint planning: Ceremonia en la que se planifica el trabajo a realizar en la siguiente iteraci´on [48].
Sprint retrospective: Ceremonia en la que el equipo discute maneras de me- jorar y aumentar su productividad a partir de lo realizado en la ´ultima iteraci´on [49].
Sprint review: Ceremonia en la que se revisa los avances generados en la ´ultima iteraci´on sobre el producto, concluyendo sobre ellos y permitiendo definir los caminos a seguir [50].
Tablero kanban: Herramienta ´agil de gesti´on de proyectos dise˜nada para ayudar a visualizar el trabajo, limitar el trabajo en curso y maximizar la eficiencia [51].
Truco: Juego de naipes con baraja espa˜nola originario de la Comunidad Valen- ciana y muy difundido en Espa˜na, Am´erica del Sur e Italia donde el objetivo es llegar a un n´umero de puntos previamente acordado [33].
Tute: Juego de naipes muy popular en Espa˜na con variantes muy jugadas en Argentina y Uruguay. Tiene varias modalidades y se puede jugar entre dos, tres o cuatro jugadores [52].
Usabilidad: Facilidad con que las personas pueden utilizar una herramienta par- ticular con el fin de alcanzar un objetivo concreto [53].
WebGL: API de JavaScript para renderizar gr´aficos 2D y 3D interactivos dentro de cualquier navegador web compatible sin el uso de complementos [54].
´Indice general
1 Introducci ´on 19
1.1 Estructura del documento . . . 19
1.2 Presentaci´on del equipo . . . 21
1.3 Elecci´on del proyecto . . . 22
1.4 Objetivos del equipo . . . 23
1.5 Descripci´on de los clientes . . . 24
1.6 Objetivos de los clientes . . . 26
2 Descripci ´on del problema 27 2.1 Contexto . . . 27
2.2 Usuarios y necesidades . . . 29
2.3 Soluciones existentes . . . 32
2.4 Principales interesados . . . 36
3 Descripci ´on de la soluci ´on 39 3.1 Descripci´on funcional . . . 39
3.2 Especificaci´on de requerimientos . . . 44
3.2.1 Requerimientos funcionales . . . 44
3.2.2 Requerimientos no funcionales . . . 50
3.2.3 Restricciones . . . 54
3.3 Pilares de la soluci´on . . . 54
3.3.1 Libertad de la experiencia . . . 55
3.3.2 Emulaci´on de la experiencia real . . . 56
3.3.3 Universalidad . . . 57
4 Ingenier´ıa de requerimientos 59 4.1 T´ecnicas de relevamiento . . . 59
4.1.1 Investigaci´on de deseabilidad . . . 59
4.1.2 Reuniones de definici´on con clientes . . . 60
4.1.3 Prototipos realizados . . . 61
4.1.4 Sprint reviews . . . 63
4.1.5 Entrevistas y segunda encuesta . . . 64
4.2 T´ecnicas de especificaci´on . . . 66
4.2.1 Requerimientos funcionales . . . 66
4.2.2 Requerimientos no funcionales y restricciones . . . 68
4.3 T´ecnicas de estimaci´on . . . 68
4.4 Criterios de priorizaci´on . . . 70
4.5 Validaciones . . . 71
5 Proceso y gesti ´on de proyecto 74 5.1 Etapas del proyecto . . . 74
5.1.1 Etapa de investigaci´on . . . 75
5.1.2 Etapa de desarrollo . . . 79
5.1.3 Etapa de documentaci´on . . . 80
5.2 Marco metodol´ogico . . . 81
5.2.1 Adaptaci´on de Scrum . . . 81
5.2.2 Ciclo de vida . . . 82
5.2.3 Artefactos . . . 84
5.2.4 Ceremonias . . . 88
5.2.5 Roles . . . 93
5.3 Roles dentro del equipo de desarrollo . . . 95
5.4 Gesti´on de riesgos . . . 97
5.4.1 Identificaci´on . . . 98
5.4.2 An´alisis cualitativo . . . 98
5.4.3 Plan de respuesta . . . 100
5.5 Principales hitos del proyecto . . . 101
5.6 Evaluaci´on del proceso . . . 104
5.6.1 Burndown charts . . . 104
5.6.2 Velocidad . . . 105
5.6.3 Esfuerzo invertido . . . 106
6 Gesti ´on de calidad 109 6.1 Importancia . . . 109
6.2 Objetivos . . . 110
6.2.1 Producto . . . 110
6.2.2 Proceso . . . 110
6.3 Plan de calidad . . . 111
6.4 Plan de aseguramiento de calidad . . . 111
6.4.1 Est´andares, pr´acticas y convenciones . . . 111
6.4.2 Revisiones . . . 114
6.4.3 Verificaciones . . . 116
6.4.4 Validaciones . . . 120
6.4.5 M´etricas . . . 121
6.4.6 Gesti´on de incidentes . . . 123
6.4.7 Reuni´on con experta . . . 125
7 Arquitectura 126 7.1 Importancia . . . 126
7.2 Definici´on y seguimiento . . . 127
7.2.1 Definici´on inicial . . . 128
7.2.2 Reuni´on con experto . . . 129
7.2.3 Revisiones . . . 131
7.3 Descripci´on general . . . 131
7.4 Vistas de m´odulos . . . 133
7.4.1 Back-end . . . 133
7.4.2 Front-end . . . 136
7.5 Vistas de componentes y conectores . . . 138
7.5.1 Diagrama de componentes y conectores . . . 138
7.5.2 Diagrama de secuencia . . . 139
7.5.3 Cat´alogo de elementos . . . 142
7.6 Vistas de despliegue . . . 144
7.7 Videollamadas . . . 146
7.8 Librer´ıa propia . . . 149
8 Tecnolog´ıas utilizadas 151 8.1 Proceso de elecci´on . . . 151
8.2 Elecciones realizadas . . . 152
8.2.1 Cliente . . . 152
8.2.2 Librer´ıas centrales . . . 152
8.2.3 Servidor . . . 153
8.2.4 Base de datos . . . 153
8.2.5 Hosting . . . 154
9 Interacci ´on y usabilidad 157 9.1 Importancia . . . 157
9.1.1 Simulaci´on . . . 157
9.1.2 P´ublico objetivo . . . 158
9.1.3 Naturaleza casual . . . 158
9.2 Medidas tomadas . . . 159
9.2.1 Pruebas y feedback . . . 159
9.2.2 Heur´ısticas de Nielsen . . . 160
9.2.3 Satisfacci´on de usuarios . . . 161
9.2.4 Modelo mental . . . 163
9.2.5 Manipulaci´on directa . . . 165
10 Gesti ´on de la configuraci ´on 166 10.1 Identificaci´on de elementos . . . 166
10.1.1 Elementos de software . . . 166
10.1.2 Elementos de documentaci´on . . . 167
10.2 Herramientas utilizadas . . . 167
10.3 Repositorios utilizados . . . 169
10.3.1 Establecimiento . . . 169
10.3.2 Organizaci´on . . . 170
10.4 Control de versiones . . . 174
10.5 Seguimiento de los cambios . . . 175
10.5.1 Commits . . . 175
10.5.2 Pull requests . . . 176
10.6 Pol´ıtica de respaldos . . . 177
11 Conclusiones y lecciones aprendidas 179 11.1 Conclusiones generales . . . 179
11.2 Lecciones aprendidas . . . 181
11.3 Pasos a seguir . . . 183
12 Referencias bibliogr´aficas 186 13 Anexos 203 13.1 Versiones de la soluci´on . . . 203
13.1.1 Versi´on 1 . . . 203
13.1.2 Versi´on 2 . . . 204
13.1.3 Versi´on 3 . . . 205
13.1.4 Versi´on 4 . . . 206
13.1.5 Versi´on 5 . . . 207
13.1.6 Versi´on 6 . . . 208
13.1.7 Versi´on 7 . . . 208
13.1.8 Versi´on 8 . . . 209
13.1.9 Versi´on 9 . . . 209
13.2 Encuestas realizadas . . . 210
13.2.1 Primera encuesta . . . 210
13.2.2 Segunda encuesta . . . 214
13.2.3 Notas de entrevistas . . . 217
13.3 Cambios realizados al product backlog . . . 219
13.3.1 Cambios detectados a partir de prototipos . . . 219
13.3.2 Cambios detectados a partir de feedback . . . 222
13.3.3 Requerimientos descartados . . . 230
13.4 Aplicaci´on de heur´ısticas de Nielsen . . . 232
13.5 Gesti´on de riesgos . . . 238
13.6 Proceso de elecci´on de tecnolog´ıas . . . 246
13.7 Funcionamiento de WebRTC . . . 256
13.8 Herramientas de apoyo y comunicaci´on . . . 258
13.9 Minutas . . . 265
13.10 Revisiones . . . 303
13.10.1 Revisi´on 1 . . . 303
13.10.2 Revisi´on 2 . . . 304
13.10.3 Revisi´on 3 . . . 305
13.11 Oportunidades de mejora . . . 307
13.12 Detalles de implementaci´on . . . 317
13.12.1 Eventos . . . 317
13.12.2 Dise˜no l´ıquido . . . 326
13.12.3 Mutua exclusi´on . . . 326
13.12.4 Datos almacenados . . . 327
13.13 Gesti´on original de pruebas unitarias . . . 330
1. Introducci ´on
En este cap´ıtulo, se realiza una presentaci´on del equipo, los clientes y el proyecto.
Se plantean los objetivos de cada una de las partes durante el transcurso del proyecto y se describen brevemente las expectativas con las que comenz´o cada una de ellas.
Se detalla a su vez la estructura del documento con un breve resumen del contenido de cada uno de los cap´ıtulos.
1.1. Estructura del documento
A continuaci´on, se describe de manera resumida el contenido de cada uno de los cap´ıtulos del documento.
Descripci ´on del problema: describe el contexto por el cu´al la soluci´on generada es necesaria, identificando a las personas que se ven afectadas por el problema, investigando sus necesidades y explicando el proceso seguido para entender los objetivos de la soluci´on. Incluye tambi´en un an´alisis del mercado que estudia las diferentes soluciones actualmente disponibles.
Descripci ´on de la soluci ´on: detalla y describe profundamente la soluci´on obte- nida desde el punto de vista funcional. A su vez, lista los requerimientos funcio- nales, no funcionales y restricciones de la soluci´on.
Ingenier´ıa de requerimientos: describe el proceso seguido por el equipo para la definici´on y actualizaci´on de los requerimientos de la soluci´on, detallando las t´ecnicas utilizadas para relevarlos, especificarlos, priorizarlos y validarlos.
Proceso y gesti ´on de proyecto: define y detalla el proceso seguido por el equi- po durante el transcurso del proyecto. Describe y justifica el marco metodol´ogico utilizado, detallando sus etapas, ceremonias, artefactos y roles. Incluye a su vez el proceso de gesti´on de riesgos realizado, con las metodolog´ıas utilizadas para identificarlos, evaluarlos y mitigarlos. Por ´ultimo, documenta los principales hitos del proyecto e incluye una evaluaci´on del proceso.
Gesti ´on de calidad: describe los diferentes objetivos de calidad establecidos, tanto para el producto como para el proceso. Detalla tambi´en la planificaci´on de calidad para el proceso, las actividades de aseguramiento y control de calidad y las conclusiones a las que se lleg´o en cuanto a la calidad de los resultados obtenidos mediante la utilizaci´on de m´etricas.
Arquitectura: detalla y justifica las principales decisiones tomadas en cuanto a la arquitectura del sistema. Incluye diferentes vistas que representan la arqui- tectura obtenida y comunican las medidas tomadas para el cumplimiento de los principales objetivos del producto respecto a los atributos de calidad.
Tecnolog´ıas utilizadas: detalla el proceso de decisi´on respecto a las distintas tecnolog´ıas utilizadas, justificando su elecci´on, y describiendo las caracter´ısticas de cada una de ellas.
Interacci ´on y usabilidad: describe las distintas t´ecnicas utilizadas para el ase- guramiento de una interacci´on de calidad entre los usuarios y la soluci´on, cum- pliendo con el nivel de usabilidad esperado.
Gesti ´on de la configuraci ´on: describe todas las t´ecnicas utilizadas para la ges- ti´on de la configuraci´on de cada uno de los elementos identificados durante el transcurso del proyecto, detallando las pautas seguidas por el equipo para cada uno de ellos con sus debidas justificaciones.
Conclusiones y lecciones aprendidas: incluye una recapitulaci´on de los re- sultados del proyecto, listando los diferentes aspectos en los que este brind´o aprendizaje a los integrantes del equipo y detallando c´omo se entiende que de- be continuar.
1.2. Presentaci ´on del equipo
El equipo de desarrollo fue integrado por tres estudiantes de Ingenier´ıa en Siste- mas en la Universidad ORT. Los miembros del equipo se conoc´ıan desde antes de comenzar a cursar la carrera y ya hab´ıan participado en m´ultiples proyectos juntos durante la misma. Esto se consider´o como una gran ventaja, al existir un grado de confianza y una facilidad de comunicaci´on de enorme utilidad para que el proyecto se pudiera realizar con mayor comodidad y seguridad.
A pesar del alto grado de conocimiento entre los integrantes del equipo, ninguno de ellos ten´ıa experiencia en proyectos de una magnitud similar a la de este. Esto llev´o a la transici´on de una curva de aprendizaje en las primeras instancias del proyecto en la que se busc´o mitigar los riesgos relativos a la inexperiencia a trav´es de distintas t´ecnicas detalladas en las diferentes secciones de este documento.
Los integrantes del equipo de desarrollo fueron:
Math´ıas Abraham: programador en una empresa de videojuegos uruguaya.
Alan Monjard´ın: desarrollador en una empresa uruguaya dedicada a los juegos de apuesta.
Bruno Pintos: desarrollador full-stack en una software factory uruguaya.
A su vez, el equipo cont´o con Luis Barragu´e como tutor, a quien el equipo ya co- noc´ıa al haber coincidido en m´ultiples instancias durante la carrera. Los aportes de Luis fueron de enorme valor durante el transcurso de todo el proyecto.
Para los integrantes del equipo de desarrollo, el proyecto signific´o uno de los ´ulti- mos pasos para culminar la carrera y obtener el t´ıtulo de Ingeniero en Sistemas des- pu´es de m´as de cinco a˜nos de esfuerzo.
1.3. Elecci ´on del proyecto
El equipo consider´o m´ultiples proyectos antes de decidirse finalmente por el simu- lador de naipes virtuales.
En primer lugar, se consideraron diferentes opciones para emprendimientos, ma- nej´andose diferentes ideas que fueron sugeridas y evaluadas. A su vez, se discutieron las diferentes alternativas publicadas por la universidad y se consider´o tambi´en una opci´on de desarrollo para la empresa donde trabaja uno de los integrantes del equipo.
La idea elegida, sin embargo, siempre estuvo primera en la consideraci´on desde su publicaci´on por parte de la universidad. Los dos principales aspectos que captaron la atenci´on del equipo a elegir esta idea fueron las distintas tecnolog´ıas a utilizar para desarrollar el producto y la tem´atica del mismo.
El aspecto tecnol´ogico del proyecto fue muy importante para el equipo. Al incluir la posibilidad de utilizar tecnolog´ıas orientadas al desarrollo de videojuegos, el manejo de m´ultiples jugadores de manera simult´anea y el streaming de audio y video a trav´es de la red, se consider´o como una gran oportunidad de conocer nuevas tecnolog´ıas y profundizar el conocimiento de otras.
A su vez, la tem´atica del proyecto fue un aspecto importante para su elecci´on.
Aunque se consideraron m´ultiples proyectos interesantes desde el punto de vista tec- nol´ogico, ninguno de ellos trataba sobre un contexto tan interesante y cercano para los integrantes del equipo como el elegido. El hecho de que la soluci´on sea algo que podr´ıa ser usado por los miembros del equipo o por sus familiares y amigos tambi´en llev´o a entender el potencial de la soluci´on e incentiv´o a elegir el proyecto.
Sumado a todo esto, se consider´o como un incentivo adicional la necesidad real que existe de una soluci´on de este tipo, que ha sido magnificada por la pandemia, pero que se entiende tiene un potencial que va m´as all´a de ella.
Por ´ultimo, se realiz´o una reuni´on con los clientes el 17 de marzo de 2021 en la que se habl´o sobre los detalles y expectativas del proyecto. En ella, el equipo se sinti´o muy c´omodo y termin´o de convencerse sobre la elecci´on del mismo.
Figura 1.1: Captura de la primera reuni´on realizada con los clientes, el 17 de marzo de 2021.
1.4. Objetivos del equipo
A continuaci´on, se describen los principales objetivos establecidos por el equipo de desarrollo para el proyecto. El cumplimiento de estos es analizado en la secci´on 11.1.
El primer objetivo establecido fue satisfacer las expectativas de los clientes, si- guiendo un proceso que cumpliera lo esperado y entregando un producto que los conformara. Al tratarse de una de las principales metas del equipo, se aplicaron m´ulti- ples t´ecnicas en las distintas etapas del proyecto para asegurar su cumplimiento. Se defini´o un proceso basado en el feedback que permiti´o relevar constantemente los cambios necesarios y obtener retroalimentaci´on frecuente para adaptar lo realizado a lo deseado por los clientes. Se busc´o facilitar e incentivar la comunicaci´on con ellos a trav´es de v´ıas ´agiles para el intercambio que permitieron asegurar que todas las partes compartieran la misma visi´on para el proyecto.
Se esperaba que el producto entregado a los clientes les demostrara el potencial de la idea y les fuera ´util para seguir con el proyecto en el futuro. A pesar de no tratarse de un producto a ser inmediatamente puesto en producci´on, se estableci´o como objetivo cumplir con todos los est´andares de calidad esperables para un producto de este tipo, permitiendo que pueda ser f´acilmente continuado y eventualmente comercializado.
Otra de las importantes metas establecidas por el equipo para el proyecto fue el aprendizaje. Al tratarse de la primera instancia de esta naturaleza de la que los inte- grantes del equipo formaron parte y de una de las ´ultimas instancias de la carrera que
culmina un proceso de varios a˜nos, se esperaba poder aplicar los distintos conceptos aprendidos durante la misma. Se entendi´o en todo momento que el proyecto presen- taba una gran oportunidad para poner en pr´actica varios conceptos con los que se hab´ıa convivido a un nivel m´as te´orico.
Por otro lado, tambi´en se vio al proyecto como una gran oportunidad de aprender nuevas tecnolog´ıas y profundizar el entendimiento de aquellas con las que ya se ten´ıa experiencia. Las tecnolog´ıas que se pod´ıan utilizar ofrec´ıan un enorme potencial de aprendizaje que los integrantes del equipo esperaban utilizar para expandir su conoci- miento.
A su vez, se estableci´o como objetivo el cumplimiento del nivel de profesionalidad esperado por parte de un equipo en este tipo de proyecto. Esto fue tenido en cuen- ta para el cumplimiento de plazos, la comunicaci´on con los distintos interesados y la calidad de los artefactos generados. Este objetivo fue considerado especialmente importante teniendo en cuenta la inexperiencia con la que el equipo entr´o al proyecto.
Por ´ultimo, pero no menos importante, el equipo esperaba poder realizar un pro- yecto que apuntara a la excelencia acad´emica. En este sentido, se busc´o trabajar para obtener una calificaci´on cercana a la perfecta, cumpliendo las expectativas de todos los involucrados en la universidad y las impuestas por el propio equipo.
1.5. Descripci ´on de los clientes
El proyecto fue presentado por la empresa SimDesign [55], y surgi´o de la uni´on de dos partes separadas que coincidieron en la idea de buscar implementar un simulador de este tipo. Ambas partes entendieron que se trata de un sector donde existe gran potencial para crecimiento dada la escasa disponibilidad de soluciones similares.
SimDesign es una empresa dedicada principalmente a la realizaci´on de soluciones utilizando realidad virtual. La empresa ha formado parte de proyectos utilizando esta tecnolog´ıa para realizar videojuegos, simuladores y soluciones orientadas al dise˜no y la arquitectura. Pese a tratarse de la especialidad de la empresa, el proyecto presen- tado no utiliza realidad virtual. El punto de contacto entre el trabajo que suele realizar SimDesign y el proyecto que presentaron a la universidad es la simulaci´on.
Los clientes que formaron parte del proyecto fueron dos: Gabriel Lambach y Daniel Amoroso.
Gabriel es uno de los fundadores de SimDesign y trabaja en la Universidad ORT.
Tiene un considerable conocimiento t´ecnico sobre la realizaci´on de simuladores y una gran cantidad de contactos en la industria de los videojuegos. Esto fue de gran utilidad en las distintas etapas del proyecto, ya que pudo proveer al equipo f´acil acceso a personas con vasta experiencia en el ´area correspondiente a los distintos problemas que se fueron encontrando y orientar de mejor manera la b´usqueda de las soluciones.
A su vez, Gabriel ya hab´ıa formado parte de m´ultiples proyectos de final de ca- rrera desde el rol de cliente, lo que facilit´o considerablemente su entendimiento de ciertos aspectos como los plazos y sirvi´o para ajustar las expectativas que ten´ıa para el proyecto.
Adem´as de su experiencia en el ´area y con los proyectos acad´emicos, Gabriel ya hab´ıa formado parte de un equipo que busc´o realizar un proyecto con los mismos ob- jetivos que este. El proyecto en cuesti´on fue realizado junto a un grupo de voluntarios de una manera m´as informal y termin´o siendo abandonado por los otros integrantes poco tiempo despu´es de su comienzo dadas distintas razones personales. A´un as´ı, esto significaba que Gabriel ya ten´ıa un nivel de conocimiento relativamente alto de la soluci´on buscada, habiendo podido experimentar con ciertos aspectos b´asicos del pro- ducto y encontrarse con ciertos problemas que pudieron ser conocidos de antemano por el equipo.
Sus conocimientos t´ecnicos, su experiencia con la idea y su involucramiento en el proyecto daban a entender desde un principio que Gabriel era el principal interesado del proyecto, buscando formar parte de la toma de decisiones tecnol´ogicas y funcio- nales del producto.
Por otro lado, Daniel no proviene del ´area del desarrollo o de la simulaci´on, sino que trabajaba en el ´area de marketing y comercio exterior. Tiene mucho menor cono- cimiento t´ecnico, por lo que su aporte proven´ıa principalmente desde el punto de vista funcional, compartiendo su visi´on sobre el producto y ofreciendo feedback sobre los aspectos m´as importantes a considerar. En este sentido, una de las principales venta- jas que ofreci´o la presencia de Daniel al equipo fue su experiencia sobre el dominio de la soluci´on, siendo un miembro activo de distintos grupos de juego y habiendo experi- mentado con varias de las soluciones similares que existen en el mercado. Todo esto llev´o a que Daniel se convirtiera en un cliente perfecto desde el punto de vista de la empat´ıa con los usuarios. Su presencia fue clave para entender las necesidades y ex- pectativas que estos tienen y para la concepci´on del grupo de prueba con potenciales usuarios.
Daniel y Gabriel se unieron para formar parte de este proyecto a trav´es del CIE [56] cuando ambos presentaron ideas similares que terminaron convirti´endose en la que dio lugar a ´el. Al no conocerse m´as all´a de algunas reuniones que realizaron previo al comienzo del proyecto para la discusi´on de la idea, se cre´ıa inicialmente que pod´ıan existir breves diferencias en sus visiones de algunos aspectos puntuales de la soluci´on final. Sin embargo, se fue encontrando a medida que se interactu´o con ellos que ninguno de los dos entr´o al proyecto con una idea completamente definida, estando abiertos a la discusi´on y la exploraci´on a partir de la idea inicial.
1.6. Objetivos de los clientes
A medida que se avanz´o en el proyecto y se realizaron m´as reuniones con los clientes, se logr´o entender que su objetivo no era recibir un producto completamente funcional y listo para ser comercializado apenas les fuera entregado. El enfoque de los clientes resid´ıa en la exploraci´on de los requerimientos funcionales y la realizaci´on de pruebas con distintos usuarios. En este sentido, los clientes fueron claros en que esperaban que cada una de las funcionalidades pudiera ser implementada desde el punto de vista funcional lo antes posible para poder experimentar con cada una de ellas, haciendo pruebas con potenciales usuarios que sirvieran para perfeccionar el producto desde el punto de vista de la usabilidad.
Los clientes quer´ıan tener de manera peri´odica distintas versiones jugables que pudieran ser utilizadas para la obtenci´on de feedback a partir de la experimentaci´on.
Su objetivo era que estas permitieran refinar constantemente la soluci´on, obteniendo un producto m´as adecuado a las necesidades de los usuarios y cercano a la versi´on que eventualmente ser´a liberada al mercado.
Pese a la priorizaci´on de la experimentaci´on, los clientes igualmente esperaban que se les entregara un producto en buenas condiciones y que cumpliera con todo lo hablado en las distintas reuniones a partir del alcance definido inicialmente. Ellos entienden que existe un espacio en el mercado para una soluci´on de este tipo, por lo que consideran que el potencial del proyecto es considerable y desean eventualmente poder aprovecharlo. Teniendo esto en cuenta, esperaban que la soluci´on cumpliera con ciertos est´andares que permitieran continuar su desarrollo y comercializarla en el futuro.
2. Descripci ´on del problema
En este cap´ıtulo, se presenta el problema a partir del cual surgi´o el proyecto y que la soluci´on busca resolver, describiendo su contexto, el perfil de sus potenciales usuarios y las soluciones similares que exist´ıan en el mercado al momento de comenzar el proyecto. Se realiza tambi´en un breve an´alisis de las principales partes interesadas que se identificaron para el proyecto.
2.1. Contexto
El problema a partir del cual surgi´o la idea y que la soluci´on busca resolver resi- de en la dificultad que se encuentra para participar de encuentros l´udicos centrados alrededor de juegos de cartas de manera remota de una forma tal que la experiencia resulte a los jugadores similar a la obtenida en una reuni´on presencial.
La participaci´on en juegos de cartas es algo extremadamente frecuente, tanto en la regi´on como a nivel global. El mercado de juegos de cartas ha estado en un creci- miento constante en los ´ultimos a˜nos, y las proyecciones indican que este crecimiento no se detendr´a.
Figura 2.1: An´alisis y proyecci´on de la evoluci´on del mercado de los juegos de mesa y cartas en Estados Unidos. Tomado del sitio Grand View Research [57].
El aumento y desarrollo del mercado de juegos de cartas es global, pudiendo ser visto en las distintas regiones un constante crecimiento y proyecciones que indican que este se mantendr´a durante los pr´oximos a˜nos.
Figura 2.2: An´alisis y proyecci´on de la evoluci´on del mercado de los juegos de cartas, discriminado por regi´on. Tomado del sitio Cognitive Market Research [58].
Pese a tratarse de una actividad tan relevante y universal, no existen actualmente maneras de participar en encuentros de este tipo que mantengan la esencia social de los mismos sin que los participantes se encuentren f´ısicamente en el mismo lugar y tengan un mazo de cartas disponible. Como se menciona en la secci´on 2.3, exis- ten algunos productos y servicios que ofrecen la posibilidad de realizar este tipo de actividades, pero la experiencia que proveen es dr´asticamente diferente a la original, estando principalmente centradas en el juego cuando el enfoque de los participantes usualmente no es este.
A este crecimiento del mercado que se viene prediciendo desde antes de la pande- mia, se le suma un pico de inter´es que se dio durante el comienzo de la crisis sanitaria.
Figura 2.3: An´alisis de la popularidad de la b´usqueda del t´ermino ‘play cards online’.
Elaborado en el sitio Google Trends [59].
La pandemia llev´o a una enorme cantidad de personas que disfrutaban de la acti- vidad de manera presencial a buscar alternativas que permitieran replicarla de forma remota. A partir del comienzo de la pandemia, una enorme cantidad de personas comenzaron a utilizar de manera frecuente soluciones orientadas a la emulaci´on de reuniones presenciales de manera remota. A modo de ejemplo, Zoom [60] gener´o 2600 millones de d´olares de ingresos en 2020, un aumento interanual del 317 % que sigui´o aumentando en el 2021 [61]
Pese a este enorme impulso que la pandemia otorg´o al sector, es importante que se entienda que estas soluciones no son exclusivas a ese contexto. Son muchas las situaciones en las que se puede optar por este tipo de reuniones por encima de las presenciales, por ejemplo por cuestiones de comodidad, falta de tiempo, distancia f´ısi- ca entre los participantes o falta de personas con las que jugar [62].
2.2. Usuarios y necesidades
Uno de los aspectos m´as importantes sobre el problema es que afecta a un ran- go extremadamente amplio de personas. Al tratarse de una actividad realizada de manera mayoritariamente casual, es esencial entender que se tiene un grupo de po- tenciales usuarios muy extenso y heterog´eneo. Teniendo esto en cuenta, se entiende que se pueden deducir m´ultiples elementos relevantes, principalmente desde el pun- to de la usabilidad. Esta caracter´ıstica del tipo de usuarios refuerza la necesidad de una soluci´on orientada a una experiencia de uso sencilla, sin elementos complejos y favoreciendo una curva de aprendizaje en la que no se deba invertir muchas horas de juego para poder participar. La importancia de este atributo de calidad y las medidas tomadas para satisfacerlo son descritas en el cap´ıtulo 9.
La heterogeneidad del grupo de potenciales usuarios es muy clara, siendo la par- ticipaci´on en este tipo de actividades bastante indiferente a aspectos como el sexo de los jugadores y transformando la actividad en un fen´omeno universal.
Figura 2.4: An´alisis y comparaci´on del disfrute de los juegos de cartas, discriminado por el sexo de los participantes. Tomado del sitio Statista [63].
Una de las caracter´ısticas para las que se entiende que es especialmente impor- tante considerar la heterogeneidad del grupo de potenciales usuarios es la edad. Aun- que lo cre´ıdo habitualmente es que estas actividades son disfrutadas principalmente por personas mayores, se encontr´o que la participaci´on es universal, siendo disfrutada por todos los grupos etarios de una manera similar. Esto no niega que las personas mayores sean las que m´as frecuentemente participan de ellas, pero remarca que no es un atributo excluyente para el disfrute de la actividad.
Figura 2.5: An´alisis y comparaci´on del disfrute de los juegos de cartas, discriminado por la edad de los participantes. Tomado del sitio Statista [64].
Un aspecto importante que se puede concluir a partir de esto es que se tiene un grupo de usuarios con niveles muy distintos de conocimiento tecnol´ogico, pudiendo haber usuarios que dominan muy f´acilmente el uso de la tecnolog´ıa y otros que tienen enormes dificultades para realizar tareas sencillas. Esto nuevamente apunta a una soluci´on universal y que permita disfrutar de la experiencia independientemente de la afinidad que se tenga con la tecnolog´ıa.
Otro aspecto importante a considerar, teniendo en cuenta la heterogeneidad men- cionada anteriormente, es la universalidad que la soluci´on debe tener desde el punto de vista tecnol´ogico. Al tener un grupo de potenciales usuarios compuesto por perso- nas tan diferentes, se entiende que es esencial que la soluci´on les permita participar desde la mayor cantidad de dispositivos posibles, pudiendo ser utilizada desde compu- tadoras, celulares y tablets de manera indistinta e incluso en los distintos navegadores soportados por cada uno de estos dispositivos. La navegaci´on de las personas cada vez est´a m´as ser centrada en plataformas m´oviles, especialmente en todo lo que re- fiere al ocio y entretenimiento [65], por lo que es importante considerar tanto desktop como mobile para cubrir la enorme variedad de usuarios disponible. Esto fue tenido en cuenta al definir los requerimientos no funcionales de la soluci´on, detallados en la secci´on 3.2.2.
Pese a que, como se mencion´o en la secci´on 2.1, el problema existe a nivel mun- dial, el plan de los clientes apunt´o desde un principio a que el enfoque sea a nivel regional para luego poder expandirse si los resultados lo permiten. Particularmente, los clientes insistieron en centrarse en el mercado nacional durante el transcurso del proyecto, entendiendo que ser´ıa lo m´as ´util para facilitar las actividades de empat´ıa, la realizaci´on de pruebas y la eventual comercializaci´on de la soluci´on. De esta forma, pese a que se busc´o realizar una soluci´on capaz de adaptarse a cualquier juego, los que fueron especialmente considerados fueron el ‘truco’ [33] y la ‘conga’ [11] al ser los m´as habitualmente jugados en Uruguay.
2.3. Soluciones existentes
Los clientes dejaron claro desde las primeras instancias del proyecto que una de las mayores fortalezas de la idea era la inexistencia de una soluci´on establecida que buscara satisfacer exactamente las mismas necesidades. A pesar de que existen cien- tos de sitios web y aplicaciones orientados alrededor de los juegos de cartas, ninguno de ellos lo hace con el mismo enfoque que la soluci´on generada.
La manera en la cual la soluci´on se diferencia de la enorme mayor´ıa de productos similares disponibles en el mercado ronda en torno a la libertad de juego que se le busca ofrecer a los usuarios. A modo de ejemplo, se listan a continuaci´on algunos de los productos m´as reconocidos a nivel mundial o regional que caen en esta categor´ıa.
PokerStars [66]: producto reconocido a nivel mundial orientado al ‘poker’ com- petitivo, en la mayor´ıa de los casos apostando y compitiendo por dinero real.
Ludoteka [67]: producto relativamente popular en la regi´on que fue mencionado y recomendado por uno de los clientes. Ofrece la posibilidad de jugar una consi- derable cantidad de juegos populares a nivel regional como la ‘escoba del 15’ o el ‘tute’.
Truco Uruguayo [68]: producto reconocido a nivel nacional utilizado para jugar al ‘truco’.
Conga [69]: producto relativamente popular en la regi´on utilizado para jugar a la
‘conga’.
Como se puede ver, las cuatro soluciones presentadas ofrecen a sus jugadores
´unicamente la posibilidad de participar de partidas de ciertos juegos espec´ıficos. Este es el caso con la mayor parte de soluciones disponibles a nivel mundial, que se basan
´unicamente en uno o un peque˜no grupo de juegos y limitan a los jugadores a las reglas impuestas por ellos.
Esta es una de las principales diferencias que la soluci´on generada presenta en comparaci´on a todas las dem´as, pues busca ofrecer a los usuarios una experiencia mucho m´as abierta y sin l´ımites tan estrictos. La naturaleza libre de un mazo de nai- pes sobre una mesa que la soluci´on busca emular es algo que escapa a lo que las soluciones anteriores ofrecen. De esta manera, se espera poder ofrecer una experien- cia que emule la presencialidad de una forma mucho m´as fiel que las dem´as, donde los usuarios pueden comportarse de manera libre y fomentando la comunicaci´on co- mo ocurrir´ıa en una mesa real. En este sentido, las otras soluciones mencionadas son considerablemente m´as fr´ıas, estando orientadas al juego en s´ı en lugar de a la inter- acci´on entre los jugadores. Esto se alinea con los dos primeros pilares definidos para la soluci´on, descritos en las secciones 3.3.1 y 3.3.2.
Se encontraron algunas soluciones relativamente populares que buscan ofrecer una experiencia libre con un mazo de cartas, pero estas proveen ´unicamente un mazo del que se pueden sacar cartas para usar en instancias presenciales como trucos de magia o sorteos, por lo que nuevamente el enfoque es completamente distinto. Uno de los ejemplos m´as relevantes de esto que se encontraron fue la aplicaci´on Deck of Cards [70].
Tras realizar una investigaci´on m´as profunda, ampliando los par´ametros de b´usque- da para considerar aplicaciones no tan reconocidas, se encontraron algunas solucio- nes que se acercan m´as al enfoque que busca la soluci´on de este proyecto. Dos casos muy claros de estas son Just Cards [71] y Deck of Cards [72]. Estas aplicaciones se caracterizan por ofrecer una experiencia que busca ser m´as libre que las habituales, pudiendo jugar a cualquier juego que se desee, pero siguen sin alcanzar el nivel de libertad disponible en una mesa presencial, teniendo restricciones como que se debe repartir la misma cantidad de cartas a todos los jugadores o que se tienen rondas. A su vez, tampoco presentan un ´enfasis tan grande en el aspecto social de las reuniones que se quiere enfatizar en la soluci´on de este proyecto.
Figura 2.6: Aplicaci´on Just Cards. La interacci´on difiere considerablemente de la presencial y presenta algunas restricciones.
Por ´ultimo, se encontr´o una soluci´on que se diferencia considerablemente de las dem´as y que puede utilizarse con un enfoque similar a la de este proyecto, llamada Tabletop Simulator [73]. Esta es una soluci´on extremadamente popular que tiene un nivel de complejidad considerablemente mayor, permitiendo que los jugadores creen sus propios templates de juegos sobre una mesa (siendo algunos de los ejemplos t´ıpicos juegos de cartas o ajedrez) para luego jugarlos con otras personas en l´ınea.
Aunque este producto t´ecnicamente puede cumplir la funci´on que busca satisfacer la soluci´on de este proyecto, se entiende que el p´ublico objetivo es diferente. Tabletop Simulator ofrece una experiencia mucho m´as compleja y que excede el nivel de detalle que la mayor´ıa de personas que ´unicamente quieren jugar a las cartas con sus amigos est´an buscando. Se entiende que este juego requiere un nivel de entendimiento de la tecnolog´ıa mucho mayor y que apunta ´unicamente a una porci´on de los jugadores que cumplen esas caracter´ısticas. A su vez, el juego es pago y puede ser ´unicamente utilizado en una computadora a trav´es de Steam [74], lo que refuerza el concepto de que apunta a un p´ublico mucho m´as espec´ıfico.
Figura 2.7: Ejemplo de uso de Tabletop Simulator. La experiencia ofrecida es considerablemente m´as compleja y profunda, con una variedad de opciones y customizaciones demasiado grande para usuarios sin conocimiento tecnol´ogico.
La investigaci´on y consideraci´on de todas estas soluciones fue importante por dos motivos principales: cumplir con el nivel de diferenciaci´on que esperaban los clien- tes y respetar los aspectos b´asicos y esperables que los jugadores de este tipo de soluciones suelen esperar.
El primero de estos aspectos fue mencionado anteriormente, y consiste b´asica- mente en que esta diferenciaci´on es lo que los clientes consideran que hace viable el proyecto y le da potencial de tener eventualmente ´exito en el mercado. Dada la enorme importancia que esto tiene para los clientes, fue tenido en cuenta a la hora de definir los objetivos y requerimientos del producto, asegurando en todo momento el ´enfasis en la diferenciaci´on mencionada. Esto puede ser visto claramente en los tres pilares definidos para el producto (secci´on 3.3), pues dos de ellos (la libertad de juego y la emulaci´on cercana de la experiencia presencial) presentan un importante contraste con las otras soluciones.
Por otro lado, los clientes solicitaron que se utilice ciertos elementos de los pro- ductos existentes (particularmente Ludoteka), como base e inspiraci´on para ciertos aspectos claves de la soluci´on y su interfaz. Pese a la diferenciaci´on mencionada ante- riormente, los clientes hicieron ´enfasis en que es importante mantener en cierto grado el feeling general de las soluciones de este tipo, que suele ser en la mayor´ıa de los casos muy similar. Este deseo de los clientes se debe principalmente a la facilidad de adopci´on de la soluci´on que se espera que los usuarios de otras soluciones puedan tener con la resultante, y es descrito en detalle en la secci´on 9.2.4. Esto fue clave para
la definici´on a alto nivel del tipo de interfaz utilizado y se defini´o temprano, pudiendo ser visto en los primeros prototipos realizados.
Figura 2.8: Interfaz del sitio Ludoteka.
La interfaz de la soluci´on generada tiene puntos en com´un con la de Ludoteka, siendo simple, disponiendo a los jugadores en los bordes de la pantalla y a la zona de juego en el medio. Estas pautas, junto a algunos mecanismos de interacci´on con las cartas y de notificaci´on de eventos a los usuarios fueron incorporadas a la soluci´on.
2.4. Principales interesados
En esta secci´on se incluye un listado de las partes interesadas en el proyecto iden- tificadas. Este incluye todos los stakeholders que se ven afectados de alguna forma por los resultados del proyecto, ya sea desde el punto de vista del producto resultante, de la parte acad´emica o de ambos. Se describe brevemente tambi´en el conjunto de necesidades que tiene cada uno de estos grupos.
Equipo de desarrollo
• Descripci ´on: el equipo compuesto por Math´ıas, Alan y Bruno es evidente- mente una de las partes con mayor nivel de inter´es en el proyecto.
• Necesidades: cumplir con las expectativas de los clientes para el proyecto y con el producto final, cumplir con las expectativas de la universidad en la
parte acad´emica, aprender a formar parte en proyectos de este tipo. Los objetivos y necesidades del equipo son descritos con mayor detalle en la secci´on 1.4.
Tutor
• Descripci ´on: Luis tiene un gran nivel de inter´es en el proyecto, habiendo participado en ´el de forma activa desde su comienzo.
• Necesidades: ayudar al equipo a cumplir con las expectativas de los distin- tos interesados en el proyecto, principalmente de la universidad.
Clientes
• Descripci ´on: al tratarse de los precursores del proyecto, presentando la idea, participando activamente en reuniones y otorgando feedback cons- tantemente, Gabriel y Daniel presentan un enorme inter´es en el proyecto.
• Necesidades: validar su idea inicial, refinando los detalles de la misma, y obtener un producto que cumpla con sus expectativas y pueda eventual- mente ser comercializado. Los objetivos y necesidades de los clientes son descritos en mayor detalle en la secci´on 1.6.
Universidad ORT
• Descripci ´on: al haberse realizado el proyecto en un ´ambito acad´emico, siendo el proyecto final de carrera de los tres miembros del equipo, la Uni- versidad ORT es una parte interesada de gran importancia.
• Necesidades: las autoridades de la universidad esperan que el equipo cum- pla con las expectativas para un proyecto de este tipo, demostrando todo lo aprendido durante la carrera.
Jugadores de cartas
• Descripci ´on: los jugadores de cartas, al ser los potenciales usuarios de la soluci´on generada a partir del proyecto, pueden verse afectados por el producto resultante.
• Necesidades: encontrar una soluci´on que cumpla con sus necesidades y les permita formar parte de reuniones para jugar a las cartas de forma re- mota de una manera que los satisfaga. Las caracter´ısticas y necesidades de los usuarios son descritas con mayor detalle en la secci´on 2.2.
Competencia
• Descripci ´on: pese a que no existen demasiadas soluciones con la misma orientaci´on que la generada a partir del proyecto, aquellas que tienen puntos de contacto con ella se ver´ıan afectadas por la aparici´on de un producto que satisfaga de mejor manera a los usuarios y que eventualmente podr´ıa qui- tarles clientes. Estas soluciones son descritas detalladamente en la secci´on 2.3.
• Necesidades: evidentemente las empresas dedicadas a soluciones de este tipo no quieren ver nuevas alternativas en el mercado que podr´ıan quitarles clientes y por lo tanto disminuir sus ganancias. En el eventual caso en el que la soluci´on comenzara a ganar popularidad, estas empresas podr´ıan incluso tomar ideas de ella para incorporar a sus productos.
3. Descripci ´on de la soluci ´on
En esta secci´on se realiza una descripci´on detallada de la soluci´on generada, ex- plicando su funcionamiento, listando cada uno de sus requerimientos y delineando los tres pilares sobre los cuales se sostiene.
3.1. Descripci ´on funcional
El principal objetivo de la soluci´on es permitir a las personas jugar a las cartas con otros de una manera que mantenga la esencia de la experiencia presencial. Para esto,
´unicamente deben ingresar al link correspondiente desde su dispositivo y navegador deseados y dar comienzo a su participaci´on.
La soluci´on tiene un sistema de mesas en el que los jugadores pueden crearlas o unirse a ellas para participar ´unicamente con quienes desean jugar. Para comenzar a formar parte de la experiencia, se puede acceder desde el men´u principal a cualquiera de los tres mecanismos definidos:
Crear una mesa, seleccionando todos los par´ametros y configuraciones corres- pondientes.
Figura 3.1: Pantallas correspondientes a la creaci´on y configuraci´on de una mesa.
Unirse a una mesa, utilizando el c´odigo alfanum´erico que los usuarios dentro de la mesa pueden observar en la esquina superior derecha de la pantalla.
Figura 3.2: Pantalla que permite unirse a una mesa utilizando un c´odigo alfanum´erico.
Unirse a una mesa p´ublica utilizando el buscador.
Figura 3.3: Pantalla que permite ver y unirse a las mesas p´ublicas disponibles.
Una vez que se ingresa a la partida deseada se puede observar un layout en forma de mesa, con una distribuci´on dependiente de la m´axima cantidad de jugadores que pueden ingresar a ella y una gran cantidad de opciones que permiten realizar las distintas acciones descritas a continuaci´on.
Figura 3.4: Ejemplo de una mesa reci´en creada con dos jugadores.
Al ser creada, la mesa comienza ´unicamente con el mazo, y cada participante puede repartir cartas al jugador que desee utilizando el bot´on disponible debajo de su avatar o c´amara. Cuando se le reparten cartas a un jugador, estas pasan a su mano, donde ´unicamente ese jugador puede verlas y manipularlas. Se tiene tambi´en una opci´on para tirar cartas directamente desde el mazo a la mesa, sin la necesidad de que pase por la mano de alguno de los jugadores.
Para manipular las cartas, se utiliza un sistema de drag and drop. Tanto aquellas cartas que se encuentran en la mano de un jugador como aquellas que se encuentran en la mesa pueden ser arrastradas para realizar distintas acciones con ellas. De esta forma, las cartas pueden ser reposicionadas, tiradas a la mesa, recogidas o entre- gadas a la mano de otro jugador f´acilmente. Este comportamiento fue redise˜nado en m´ultiples ocasiones en la b´usqueda del mecanismo m´as similar a la experiencia real que mantuviera un alto nivel de usabilidad en un entorno remoto, sin volverse tedioso o dif´ıcil de entender.
El mazo se encuentra ordenado por defecto. Cada vez que se desea barajarlo se puede seleccionar el bot´on correspondiente, tras lo cual se emula esta acci´on de una forma similar a la real, utilizando el Algoritmo de Durstenfeld [75]. Tras esto, el orden de las cartas en el mazo se cambia y se puede proceder a jugar con la usual incertidumbre que caracteriza a este tipo de juegos.
Al hacer click/tap sobre una carta visible al jugador, se pasa a tenerla seleccionada, lo que es indicado a trav´es del borde rojo que la rodea. Al tener una carta de la mesa seleccionada, se puede utilizar la opci´on disponible para fijarla o desfijarla en la mesa, siendo esto indicado por un peque˜no tri´angulo azul en su esquina superior derecha e impactando su comportamiento al ser recogidas como se describe a continuaci´on.
Las cartas que est´an sobre la mesa pueden ser recogidas al mazo realizando do- ble click/tap sobre el mismo. El mecanismo seguido para determinar qu´e cartas son recogidas al realizar esta acci´on es el siguiente:
Si hay cartas no fijadas en la mesa, estas son recogidas al mazo.
Si no hay cartas no fijadas en la mesa, pero hay cartas fijadas sobre la misma, estas son recogidas al mazo.
Si no hay ninguna carta sobre la mesa, se recogen al mazo las cartas que tienen los jugadores en sus manos.
El mecanismo de fijar cartas es importante teniendo en cuenta que existen juegos en los que se desea recoger ´unicamente ciertas cartas de la mesa, manteniendo otras en su posici´on actual. Un claro ejemplo de esto es cuando se juega al ‘truco’ y se tiene la ‘muestra’ sobre la mesa, que no debe ser recogida junto a las otras cartas en cada mano.
Figura 3.5: Ejemplo de una mesa con dos jugadores jugando al ‘truco’. En este caso la
‘muestra’ es el 2 de basto, estando fijada sobre la mesa.
Si se realiza doble click/tap sobre una carta visible al jugador, esta se puede voltear para ocultarla o revelarla.
Para mostrar a un jugador cu´antas cartas hay actualmente en el mazo y cu´antas cartas tiene cada uno de los dem´as jugadores en su mano, se utilizan n´umeros que indican estas cantidades en el lugar correspondiente y que son actualizados en cada instancia en la que es necesario hacerlo. Aunque esto claramente difiere de la ex- periencia presencial, debi´o ser realizado para optimizar el espacio disponible, siendo muy dif´ıcil mostrar la cantidad de cartas visualmente en pantallas peque˜nas y en- tendi´endose que la alternativa elegida facilita el r´apido entendimiento de la situaci´on actual.
En la parte derecha de la pantalla se tiene una secci´on en la que se puede anotar y observar el puntaje. Aqu´ı los jugadores pueden escribir y luego seleccionar la opci´on de actualizar para que los dem´as vean los cambios realizados, siendo esta una manera clara y sencilla de llevar el puntaje de la partida.
Por debajo del puntaje se tiene el chat de texto, en el cual los jugadores pueden escribir y enviar mensajes que pueden ser le´ıdos por todos los participantes de la mesa. Se incluye tambi´en en este los mensajes del sistema, que son notificaciones de
todas las acciones realizadas por los jugadores en la mesa y que sirven como historial para no perder rastro de lo ocurrido. Pese a su utilidad, se tiene una opci´on en la esquina superior derecha de la secci´on que permite desactivarlos.
La soluci´on incluye algunas peque˜nas animaciones que buscan mostrar a los ju- gadores lo que ocurre de una manera f´acil de entender y natural. Por ejemplo, cuando a un jugador se le reparte una carta del mazo, todos pueden observar como esta se mueve desde el mazo hasta la mano del jugador correspondiente, teniendo en cuenta al realizar esta animaci´on si la carta se debe mostrar boca arriba o boca abajo a ca- da jugador para no revelar informaci´on que no deber´ıa ser conocida. De una manera similar, se incluye un sonido que indica cuando el mazo fue barajado.
Un aspecto que es muy importante para el funcionamiento de las mesas es el rol de administrador o anfitri´on de la mesa, inicialmente asignado a la persona que la cre´o. Cada vez que el administrador abandona la mesa, el rol se pasa al jugador que haya ingresado hace m´as tiempo.
El anfitri´on tiene acceso a una funcionalidad que permite expulsar a los jugadores, quit´andolos de la mesa y envi´andolos al men´u principal. A su vez, el anfitri´on puede modificar las posiciones de los jugadores en la mesa, pudiendo utilizar los botones disponibles alrededor de ella para mover a un jugador o hacer que dos de ellos inter- cambien posiciones. (Ver Figura 3.5)
Al ingresar a una mesa y otorgar al navegador los permisos necesarios, un jugador ingresa autom´aticamente al chat de audio y video junto al resto de los integrantes de la misma. De esta forma, los participantes pueden comunicarse durante la partida, fomentando la interacci´on entre ellos y acercando el aspecto social de la experiencia al vivido en reuniones presenciales. Se incluyen tambi´en opciones para que un jugador pueda silenciar su micr´ofono o apagar su c´amara temporalmente si as´ı lo desea.
3.2. Especificaci ´on de requerimientos
En esta secci´on se listan y describen de manera resumida todos los requerimientos identificados e implementados para la soluci´on. Los procesos y mecanismos utilizados para el relevamiento, estimaci´on, priorizaci´on, especificaci´on y validaci´on de estos re- querimientos son detallados en el cap´ıtulo 4.
3.2.1. Requerimientos funcionales
RF1: Crear mesa
• Prioridad: Muy alta
• Descripci ´on: El sistema debe permitir a los jugadores crear una mesa in- gresando un nombre, descripci´on, m´aximo de jugadores y privacidad para la misma y un apodo para el jugador dentro de la mesa. Una vez creada, el jugador debe ingresar autom´aticamente a ella como anfitri´on.
RF2: Unirse a mesa
• Prioridad: Muy alta
• Descripci ´on: El sistema debe permitir a los jugadores unirse a mesas usan- do el c´odigo alfanum´erico que las identifica y un apodo para utilizar dentro de la mesa. Al unirse a la mesa, el jugador debe poder observar a todos los dem´as jugadores y todos los dem´as jugadores deben poder observarlo.
RF3: Mesas p ´ublicas
• Prioridad: Baja
• Descripci ´on: El sistema debe permitir a los jugadores ver una lista de todas las mesas p´ublicas del sistema a las que pueden ingresar. Al seleccionarse una mesa de la lista, el jugador debe ser llevado a la pantalla de unirse a una mesa con el c´odigo de la mesa seleccionada ingresado como valor por defecto.
RF4: Configurar mazo
• Prioridad: Media
• Descripci ´on: Durante el proceso de creaci´on de mesa, el sistema debe permitir a los jugadores realizar ciertas configuraciones sobre la misma.
Se debe poder elegir si se quieren quitar ciertas cartas del mazo (ochos, nueves y/o comodines) y si se quiere que las cartas sean repartidas de manera visible u oculta.
RF5: Barajar mazo
• Prioridad: Alta
• Descripci ´on: El sistema debe permitir a los jugadores dentro de una mesa seleccionar una opci´on para alterar el orden de las cartas que se encuentran en el mazo.
RF6: Repartir carta a jugador
• Prioridad: Muy alta
• Descripci ´on: El sistema debe permitir a los jugadores dentro de una mesa repartir una carta a un cierto jugador de la misma. Esta acci´on debe ser mostrada a todos los jugadores y el n´umero de cartas en el mazo y en la mano del jugador deben ser actualizados.
RF7: Seleccionar carta
• Prioridad: Media
• Descripci ´on: El sistema debe permitir a los jugadores dentro de una mesa hacer click/tap sobre una carta que se encuentre sobre ella o en la mano del jugador para que esta pase a estar seleccionada, lo que debe ser mostrado
´unicamente a ´el mediante la inclusi´on de un borde alrededor de la carta.
RF8: Tirar carta de la mano a la mesa
• Prioridad: Muy alta
• Descripci ´on: El sistema debe permitir a los jugadores dentro de una mesa tirar una de las cartas que tiene en su mano a la mesa mediante la acci´on de arrastrado de la misma. La carta tirada debe pasar a ser visible para todos los jugadores.
RF9: Recoger cartas al mazo
• Prioridad: Alta
• Descripci ´on: El sistema debe permitir a los jugadores dentro de una mesa recoger todas las cartas al mazo haciendo doble click/tap sobre el mismo. Si hay cartas no fijadas en la mesa, estas deben ser levantadas. En caso con- trario, se deben levantar las cartas fijadas de la mesa, y si no hay cartas en la mesa se deben levantar las cartas de las manos de todos los jugadores.
RF10: Recoger carta de la mesa a la mano
• Prioridad: Alta
• Descripci ´on: El sistema debe permitir a los jugadores dentro de una mesa arrastrar una carta de la mesa hasta su mano y que esta pase a formar parte de ella, pasando a ser invisible para los otros jugadores.
RF11: Voltear carta
• Prioridad: Alta
• Descripci ´on: El sistema debe permitir a los jugadores dentro de una mesa hacer doble click/tap sobre una carta que se encuentra sobre ella o en su mano para voltearla.
RF12: Fijar/desfijar carta
• Prioridad: Alta
• Descripci ´on: El sistema debe permitir a los jugadores dentro de una mesa seleccionar una opci´on que fija o desfija la carta seleccionada, siempre y cuando esta se encuentre sobre la mesa. Esta opci´on afecta el comporta- miento obtenido cuando las cartas son recogidas al mazo.
RF13:Chat de texto
• Prioridad: Alta
• Descripci ´on: El sistema debe permitir a los jugadores dentro de una mesa escribir y leer mensajes de texto con los dem´as participantes de la misma, pudiendo observar qui´en envi´o cada uno de ellos. El chat tambi´en debe incluir mensajes de sistema, que indican el acontecimiento de las distintas acciones y qui´en las realiz´o.
