Análisis - Ejemplos

Como se puede entender, es bastante complicado presentar el propio proceso de pensamiento en un escrito. No solo porque la acción de pensar sea algo íntimo o interno, sino porque una vez que intentas transcribir el proceso, en realidad ya lo has llevado a cabo. Es decir, que cualquier cosa que escriba aquí, tendrá que ser la revisión que yo pueda hacer sobre lo que ya he pensado o sobre cómo creo que lo he hecho.

En cualquier caso, creo que puede ser interesante, aunque no representen el proceso real de pensar, por lo menos ver algunos ejemplos de en qué consiste el análisis de los problemas y qué es lo que buscamos extraer. Como mínimo, podremos ver parte del resultado del análisis y hacernos una mínima idea de cómo se llega a algo parecido. Normalmente, además, esto que sigue iría acompañado de diversos diagramas -o garabatos- que representarían mis pensamientos según van ocurriendo.

Voy a plantearme 3 ejemplos. Creo que es buena idea que sean ejemplos suficientemente familiares como para que no tenga que, además, explicar qué son. Si no fuera así, seguramente en esa descripción ya estaría incluyendo buena parte de la labor de análisis, intencionadamente o no. A pesar de eso, voy a elegir también uno que no sea tan familiar.

Ejemplo 1: El Juego de la Oca

Espero que todos conozcáis este juego clásico. Si no fuera así, en Wikipedia hay una breve descripción general que debería ser suficiente. También tiene su propia entrada en Boardgame Geek que tiene más fotos, aunque no es necesario consultar nada ahí.

Una forma de hacer el análisis es simplemente tomar la descripción que tengamos y resaltar las palabras o frases que sean más relevantes. Otra es simplemente ir contándonos a nosotros mismos esta descripción e ir anotando.

La Oca es un juego de varios jugadores. Cada uno tiene una ficha y un dado. Se colocan todas las fichas al inicio del tablero. Por turnos, cada jugador va lanzando el dado y moviendo su ficha tantas casillas como indique. Algunas casillas tienen reglas especiales que te pueden llevar, por ejemplo "de oca a oca" o "de puente a puente", hacer que tires de nuevo o que pierdas uno o más turnos. El juego termina cuando uno de los jugadores llega a la casilla central.

Así en un primer vistazo podemos sacar esas ideas. Hay jugadores, fichas, dados, tablero, casillas, reglas especiales, el mecanismo de ir jugando por turnos y el objetivo de llegar a la última casilla. Pero podemos simplificar un poco algunas cosas. Por ejemplo, podríamos pensar en si importa que cada jugador tenga un dado o si usan todos el mismo. En realidad da igual que sea de una forma o de otra. Así que ni siquiera necesitamos pensar que sea de una u otra manera. Simplemente podemos decir que da igual, que hay una forma de lanzar el dado y es irrelevante si hay varios dados o no.

Hay temas que podemos pensar de diferentes formas. Hablando esto con otra persona, me decía que para ella la ficha era lo mismo que el jugador. O por lo menos que lo representaba. No importa mucho que en este análisis lleguemos a una forma concreta de representar el problema. Lo realmente importante es que lleguemos a una forma que nos sirva a nosotros para comprender.

También es interesante ver que, en esta visión general, no nos importan demasiado qué implican las "casillas especiales". Simplemente sabemos que hay algunas casillas que pueden tener ciertas reglas, pero a este nivel de detalle, qué haga cada regla concreta no nos importa.

Después de tener esta visión general, entonces ya sí podríamos centrarnos en otras perspectivas de más detalle. Por ejemplo, podemos analizar el tema de las casillas especiales, y no especiales. Centrándonos en eso, podríamos por ejemplo pensar en que hay diferentes tipos de casillas. Algunas afectan a la posición de tu ficha (te llevan a otra casilla), otras afectan al turno (te eliminan del juego un número de turnos), otras -por ejemplo el pozo o el laberinto- puede que afecten al turno pero eliminando al jugador hasta que ocurra otra cosa.

Quizá podríamos profundizar un poco más en el análisis, pero es un juego suficientemente simple y probablemente no necesitamos más. Tampoco hay que quedarse atascados pensando todos los mínimos detalles.

Ejemplo 2: Kiosko de información / plano

También espero que esto sea suficientemente familiar. Se trata simplemente de una pantalla interactiva típica como la que podemos encontrar, por ejemplo, en un gran centro comercial, un aeropuerto o en un centro de eventos, que nos permite consultar los servicios y establecimientos disponibles, ver su localización en un mapa y, quizá, cómo llegar. Hay muy diversas formas, pero para hacernos una idea general, he encontrado este video de un kiosko de este tipo en el aeropuerto de Changi (Singapur) que enseña un uso típico.

Aquí hay pocas mecánicas y pocos detalles. Tenemos una serie de destinos y alguna forma de elegir uno. Una vez elegido, habrá alguna visualización de la información de ese destino. Y en el fondo poco más. A vista de pájaro o en el nivel de menos detalle, esto es todo lo que tiene: Destinos, selección y visualización.

Es interesante ver como hay claramente dos partes distintas: Una es la "forma de elegir" un destino. Otra es la "forma de visualizarlo". Son completamente independientes. Es cierto que en el sistema completo, una de las partes nos lleva a la otra (vamos, que primero seleccionamos y entonces visualizamos), pero ambas partes funcionan por separado.

Esto nos permite analizar cada parte por separado, con su propio nivel de detalle.

Nota: podemos plantear ambas partes de formas muy diferentes. Dependerá de el caso concreto que nos estemos planteando. En lo que sigue yo voy a presentar un par de opciones para cada parte. No quiere decir que cualquier sistema tenga ambas; son solo ejemplos de cómo podría ser.

La selección de destino

Una forma que puede tener el subsistema de selección de destino es una lista de todos los destinos. Podemos tener, por ejemplo, una lista con diferentes grupos (restaurantes, tiendas, servicios...) y en cada uno de ellos, diferentes destinos. De modo que ya estamos identificando: grupos y destinos.

Otra forma que podría tener nuestro kiosko es por ejemplo parecida a la del aeropuerto del video. Nosotros no seleccionamos destino directamente, sino que utilizamos un código de vuelo o de nuestra tarjeta de embarque. Quizá lo podríamos introducir con un teclado. Y entonces es el sistema el que de alguna forma tiene que relacionar esos códigos con los destinos.

La visualización

La visualización es totalmente independiente de cómo hayamos seleccionado el destino. Aquí ya solo existe un destino concreto, que dentro de este subsistema pasa a ser el destino.

En esta parte del problema vemos que lo que necesitaremos es solo: dada la información de un destino, presentarla. De nuevo, esta presentación puede tener muchas formas. Podríamos de forma muy básica, simplemente explicarla con un texto de tipo "vaya por el pasillo tal, gire a la derecha en cual, siga hasta...". O podemos -lo más habitual- dibujarla en un mapa.

Algo que podemos intuir que existe en cualquier caso es que un destino se va a componer de varias informaciones: el nombre (y quizá información general) del destino, su localización, el camino para llegar hasta él desde nuestro kiosko.

Como digo, en un caso real, qué formas tengan en concreto ambas partes será algo que dependerá de nuestro problema. Pero a veces no. A veces el problema solo define que tiene que haber "alguna forma" de buscar un destino y "alguna forma" de ver la información. En ese caso definir cómo son esas formas será precisamente la solución que debemos plantear. Aquí es dónde se ve que puede ser fácil caer en ese error que comentábamos de involuntariamente meter una solución específica dentro de la descripción del problema.

Igualmente, este es uno de esos problemas en los que es importante conocer su dimensionamiento. ¿Cuántos destinos (tiendas, puertas de embarque, restaurantes...) vamos a tener que manejar aproximadamente? ¿Cómo es de grande el espacio del mapa? ¿Cuántos kioskos vamos a querer instalar? Todos estos detalles deben formar parte del análisis.

Ejemplo 3: Mastermind

Este es otro juego. Es más probable que no resulte familiar ya que no fue tan popular como el Juego de la Oca u otros, pero creo que es un caso sencillo con algún detalle interesante. Wikipedia también tiene una descripción general y este otro enlace (en inglés) tiene algunos recuerdos y detalles más. Por si acaso, tengo también aquí una descripción un poco más detallada de Mastermind.

¿Qué cosas pensaría yo para comprender el juego de Mastermind y lo que supondría implementarlo? En principio está claro que hay un sistema de turnos y que hay fichas y combinaciones. Quizá no importan Tanto las fichas cuanto las combinaciones, así que en una vista general me quedo con las combinaciones. También hay una clave y, de algún modo, hay un proceso de evaluación, es decir, hay un cierto cálculo que se hace para exponer cuánto de acertada es una cierta combinación respecto a la clave en juego. Este cálculo produce algo que podemos llamar pista, por ejemplo.

De hecho, si pensamos esto un poco más, podríamos -desde cierta perspectiva- decir que el papel de uno de los jugadores se limita a elegir la clave al principio del juego y aplicar ese proceso de evaluación en cada jugada. Lo interesante de esto es que analizar cómo es un problema -en este caso el juego Mastermind- nos puede llevar a descubrir que hay cosas que asumimos por su apariencia -que ambos jugadores participan a lo largo del juego- pero que en realidad puede que no sean exactamente así -por ejemplo, uno de los jugadores no necesita "jugar", su participación es puramente mecánica-.

También es interesante hacer un análisis así porque podemos ver cosas como que, si queremos implementar todo el juego, realmente tenemos partes bastante claras y separadas: El almacenamiento de la clave, un medio de introducción de combinaciones (intentos de adivinar), el proceso de cálculo de las pistas, y la presentación del "tablero" para visualizar las combinaciones usadas y las pistas recibidas.

Ejercicio

Este es un buen momento para que realices tu propio ejercicio de análisis. Puedes analizar el problema de tu proyecto, de ese que quieres hacer.

Si lo prefieres, como ejercicio, puedes hacer algún otro más sencillo. Los juegos, como los que he elegido yo, son problemas con detalles interesantes pero a la vez con una complejidad que suele ser bastante asequible. El parchís, 3 en raya o 4 en raya, ajedrez, backgammon, Scrabble/Intelect... son buenas opciones en general. Evita coger, por lo menos como primer ejercicio, un juego excesivamente complejo, pero si quieres también puede ser bueno intentar analizar -incluso aunque no sea de forma completa- alguno como puede ser el Cluedo, Monopoly, Diplomacy, La Fuga de Colditz u otros de ese estilo.

Otra opción es escoger alguna aplicación sencilla que ya conozcas, una agenda, una lista de tareas, un gestor de colecciones de cómics o libros... Algo con mayor o menor complejidad que uses en tu ordenador o en tu móvil con cierta frecuencia. La dificultad de hacer el ejercicio sobre una aplicación así, es que es muy fácil terminar haciendo análisis no del problema original, sino de una solución particular a ese problema (la solución que hicieron los que crearon esa aplicación, claro). Así que si optas por esto, lo mejor es que solo tomes la idea y evites fijarte en cómo hace las cosas esa aplicación en concreto. Pero ya te aviso que no es fácil.

Nota: Me gustaría, y quizá lo haga en algún momento, incluir aquí algún ejemplo más complejo. Me atrae la idea de hacer un análisis general de un juego como el Monopoly o Espías y Confidentes. Veremos.