Introducción a la fase de diseño[editar]

A continuación detallamos los documentos de entrada y de salida generados durante esta fase.

Documentos de entrada[editar]

Visión y misión de la corporación[editar]

Para cumplir nuestra misión, podemos dividir el trabajo a realizar en dos partes: realizar un backend y un frontend (web). Ya que el cliente desea desarrollar la página web e integrar el servicio en una aplicación Android de creación de contenido interactivo, Mokap.

Planes y políticas sobre los servicios[editar]

Queremos disponer de varios escenarios en la web, algunos no necesitarán permiso (login) para interactuar con ellos (recorrer y descargar los recursos existentes).
El uso de la API, necesitará una clave privada, para asegurar que tenemos el control.
La subida de recursos tiene que estar vigilada por la propia web, así aseguraremos que los recursos tienen la calidad mínima establecida.
Se desarrollarán recursos de alta calidad para poder mostrarlos y dar una primera impresión mejor. A parte dispondremos de recursos de dominio público extraídos de openclipart.org.

Información financiera y presupuestos[editar]

Ya que no vamos a invertir nuestro dinero en el servicio, necesitamos incluir recursos libres en la base de datos, mientras aún no tengamos contenido generado por los usuarios. El cliente aporta el alojamiento de la página web. Una de las razones por las que se decidió usar Google como alojamiento del backend fue porque es gratis mientras no se supere una cuota preestablecida.
Los integrantes de Mokap (desarrolladores y demás participantes) invertirán el tiempo necesario o disponible.

Solicitudes de cambios de diseño[editar]

No procede.

Sistema de gestión del conocimiento sobre el servicio[editar]

Conversaciones por Telegram, gestión de tareas en Trello y documentos en Google Drive.

Documentos de salida[editar]

A su vez, el diseño del servicio genera como "salidas" una serie de documentos entregables que resultan de utilidad en otras fases, por ejemplo:

Actualizaciones al portfolio de servicios[editar]

Decidimos no permitir por ahora la subida de recursos por falta de control de la estructura del contenido que pueda subir el usuario. Para mantener la calidad de los recursos del repositorio al principio.
Basándonos en el portfolio de servicios de la fase anterior, en cada reunión se priorizan los servicios a ofrecer. Ya que no estamos familiarizados con la herramienta (Drupal) es necesario que los encargados se informen e instruyan. Después de tener algunos conocimientos básicos, podemos dar mayor prioridad a alguna funcionalidad sencilla pero importante, para aprender a manejar el entorno de Drupal. A continuación podemos centrarnos en los servicios más importantes.

Paquetes de diseño de servicio (con detalles de utilidad, garantía, especificaciones, planes, etc.)[editar]

Iteración 1: Para acceder a la API utilizamos peticiones http de tipo GET y POST. Las peticiones GET sirven para obtener información sobre los recursos, y reciben como parámetro una query, que indica la información que se quiere obtener en esa petición, y pueden recibir también un cursor para búsquedas paginadas. Las peticiones POST sirven para subir recursos comprimidos en formato zip a la base de datos, y el zip debe respetar una estructura estricta. Por esa razón, como he mencionado antes, la subida de recursos está desactivada hasta que se pueda permitir mayor libertad al usuario para subir cosas. Ambos tipos de peticiones reciben un parámetro k. Éste es la clave privada, si no se indica o no es correcta se muestra un error, así protegemos la seguridad de nuestros recursos.
Definimos una estructura para los documentos JSON, que son los que contienen toda la información relevante de un recurso, como su nombre, descripción, etiquetas...
Iteración 2: Hicimos una segunda iteración en esta fase, cambiando la estructura de los documentos JSON para corregir unos pequeños problemas que tuvimos en la visualización de las imágenes de los recursos.
Interfaz del usuario: Realizamos una serie de mockups para decidir cómo y dónde deben aparecer los servicios que vamos a ofrecer en nuestra página. Los mockups fueron pensados separadamente por los miembros del grupo, y posteriormente puestos en común. El conjunto de mockups finales utilizados puede encontrarse en la carpeta: 6 Mockups UI.

Políticas de seguridad de la información[editar]

Política para la API: para hacer uso de nuestra API se necesita una clave privada proporcionada por nosotros. Esta clave debe estar lo más oculta posible para que los usuarios de la página web o de Android no la conozcan.

Informes financieros[editar]

Alternativas entre Google y Amazon, precio hosting (al final nos lo dio el cliente).

Logros según los indicadores propuestos[editar]

En esta fase hemos realizado mockups para siete pantallas distintas de nuestra página. Tras una primera versión, los pusimos en común en una reunión, y realizamos algunos cambios para obtener la versión definitiva.
Incluimos una definición formal del modelo a utilizar y la definición de la estructura de los documentos JSON, que almacenan la información de los recursos. Puede encontrarse en la carpeta: 4 Definición formal del modelo.