¿Cuáles serían los requisitos de software para desarrollar un software de cubo de rubik?

Eli respondió esto bastante bien, pero quería mirarlo como si alguien viniera a mí y me pidiera que lo desarrollara. Requisitos es un término bastante amplio.

Primero, ¿cuál es el objetivo del software? ¿Es un juego donde presenta cubos aleatorios y tienes que resolverlo o es un buscador de soluciones basado en ingresar un cubo real que tienes en la mano, o ambos?

Segundo, para qué plataforma es; web, windows, ios, android? Eso se inclinará hacia elegir un lenguaje de desarrollo.

A continuación, abordaría cómo se ve la interfaz de usuario. ¿Un cubo 3D que gira a lo largo de dos (básicamente) ejes? O una representación 2D de los seis lados. Si es lo primero, ¿cómo desea rotar cada plano (hacer clic y mover, por ejemplo)? Si es esto último, ¿cómo se transmite lo que es qué al humano?

Esas dos preguntas probablemente se bloquearían en un idioma, los algoritmos son factibles en casi cualquier idioma. En el mundo real, estás viendo las habilidades de programación tuyas o de tu equipo.

Si este es un juego, necesitarías un temporizador, cuenta atrás o cuenta atrás o ambos. ¿Quieres grabar esos tiempos o mantener un top 10? ¿Puede el usuario guardar una solución en progreso y cómo la almacena?

¿Qué tipo de sistema utilizará para realizar un seguimiento de las 54 cajas y su rotación? Si se trata de un “solucionador”, investigaría los algoritmos existentes, ya que trato de evitar reinventar la rueda y solo mejorarla. Y sí, lo haría desde el principio, ya que es importante saberlo.

Entonces, realmente no respondí la pregunta, pero pregunté un montón. En mi humilde opinión, este es un elemento clave en la búsqueda de requisitos para un proyecto. En realidad, cada uno de los elementos principales se ramifica aún más, con más preguntas y, por lo tanto, respuestas. Al final del proceso, extrae la lista de requisitos. Desea intentar que la solución propuesta sea lo más cercana posible, pero, por supuesto, en el mundo ‘real’ su kilometraje puede variar 🙂

Los requisitos son simplemente una lista de las cosas que desea que haga la aplicación.

En las metodologías tradicionales de desarrollo de software, los requisitos se capturan como casos de uso que detallan paso a paso lo que hace la aplicación en respuesta a todas las diferentes acciones posibles de los actores externos.

En un entorno ágil, los requisitos se capturan como historias de usuarios, que son la forma más sencilla de comprender lo que necesitamos que haga el software. El detalle del comportamiento exacto (como un caso de uso o de otra forma) se realiza solo cuando la característica se compromete a una iteración (sprint en el lenguaje Scrum), ya que no queremos perder tiempo en una característica que puede no terminar siendo implementada .

Entonces, por ejemplo, para su aplicación de cubo de Rubik, sus historias de usuario de nivel superior podrían ser:

  1. Como usuario, quiero que el software del cubo de Rubik modele la funcionalidad de un cubo de Rubik real para poder jugar con el cubo como lo haría con uno real.
  2. Como usuario, quiero que el software del cubo de Rubik me muestre cómo resolver un cubo de Rubik dado.

La función 1 podría ampliarse para describir la forma en que se modela el cubo:

1.a Como usuario, quiero que el cubo de Rubik se muestre como un modelo tridimensional que se pueda manipular libremente en todos los ejes para poder manipularlo con el mouse y el teclado.

Descripción detallada de las operaciones del mouse y el teclado utilizadas para rotar la cámara y las secciones del cubo.

1.b Como usuario, quiero poder guardar y cargar mi cubo Rubik para no tener que resolverlo de una vez.

Descripción detallada de la operación de guardar / cargar y el formato de archivo utilizado.

etcétera etcétera.

Los requisitos documentan casi por completo la GUI prevista. Más allá de los requisitos de visualización y entrada / configuración de datos, los requisitos se reducen para mostrar la secuencia de operaciones legales que resuelven el rompecabezas.

El algoritmo para resolver el rompecabezas está bien documentado y pertenece a la documentación de diseño.

Hace unos años pasé un tiempo con el equipo de Lego Robotics con mis hijos. Al investigar el tema, me topé con un blog en el que alguien implementó precisamente eso: software que resolvió los acertijos de cubo de Rubik, en el kit de robótica Lego, ¡junto con manipuladores que rotaron el cubo y movieron piezas! Búscalo.

Sus requisitos estarían girando (juego de palabras) alrededor del reconocimiento de patrones y algoritmos activados por patrones específicos.