1. Introducción y objetivos
DeDe es un proyecto para la asignatura de Arquitectura de Software de la Universidad de Oviedo. Esta versión será desarrollada por los miembros del equipo es1c que son:
-
Héctor Martín Gutierrez
-
Laura Vigil Laruelo
-
Ivan Valle Soto
-
Álvaro López Fueyo
DeDe es un sistema de venta online descentralizado que respeta la privacidad de los clientes.
1.1. Resumen de requisitos
La aplicación se ejecutará en el servidor, y la información del usuario se almacenará en su pod. Para obtener información de otros usuarios, la aplicación consultará sus correspondientes pods. Todos estos requisitos son compatibles con el proyecto SOLID, ya que la información de los usuarios no se almacena de forma centralizada.
En la aplicación web los usuarios podrán comprar, el sistema calculará los costes de envío consultando la dirección deseada del usuario en su pod y calculando los costes de acuerdo a la distancia del centro de distribución a dicha dirección.
Los usuarios podrán tanto confirmar la compra desde su carrito, como ver su historico de pedidos realizados.
1.1.1. Requisitos técnicos
Para la ejecución del proyecto se compila y ejecuta restapi y webapp. El despligue será realizado en Heroku.
Se controlará el correcto funcionamiento mediante los siguientes tipos de pruebas:
-
Pruebas unitarias
-
Pruebas de aceptación
-
Pruebas de carga (Incluidas en el ANEXO IV)
-
Pruebas de usabilidad. (Incluidas en el ANEXO I)
1.2. Objetivos de calidad
| Objetivo de calidad | Motivación |
|---|---|
Usabilidad |
La aplicación debería de poder ser usada por cualquier tipo de usuario independientemente de su nivel. Para llevar a cabo este objetivo se ha realizado un estudio con una muestra de 15 personas comprendiendo un amplio rango de edad. Los resultados obtenidos, así como la prueba realizada se pueden apreciar en el ANEXO I de esta documetación. |
Privacidad |
La gestión de información es descentralizada. En la aplicación no se guarda ningún dato que pueda comprometer al usuario. Sino que, todos los datos relativos a estos, se encuentran en un POD (Personal Online Data) |
Seguridad |
La aplicación no debería de tener ninguna vulnerabilidad. Esto se demuestra gracias a la integración con SonarCloud. |
Portabilidad |
Que la aplicación pueda adaptarse de forma correcta a distintos dispositivos. Nuestra aplicación se encuentra desarrollada principalmente para verse de forma correcta en ordenadores, pero tambien, tal y como se puede apreciar en el ANEXO II, se encuentra adaptada a dispositivos móviles. |
1.3. Stakeholders
| Rol | Expectativas |
|---|---|
Profesores del curso |
Implementar y mostrar un proyecto que refleje lo explicado en clase. |
Clientes |
Sea intuitiva y fácil de utilizar independientemente del nivel, además de que sus datos se encuentren almacenados de forma segura. |
Administrador |
Encargado de solucionar los futuros problemas que vayan surgiendo en la aplicación. |
2. Restricciones de Arquitectura
2.1. Restricciones técnicas
Restriccion |
Description |
React |
Debemos usar el framework React para desarrollo del front-end de la aplicacion |
Typescript |
Es el lenguaje de programacion principal de la aplicacion |
SOLID |
Debemos seguir el principio SOLID de descentralizacion de los datos de los clientes |
Node.js |
Entorno para la manejar la comunicacion entre el back-end y el front-end de la aplicacion |
Git/Github |
El software de control de versiones de este proyecto |
2.2. Restricciones organizativas
Restriccion |
Descripcion |
Revisiones |
Tendremos diversas presentaciones y revisiones del proyecto, hasta la entrega final |
Equipo |
El equipo cuenta con un maximo de 5 miembros |
Reuniones continuas |
El equipo esta obligado a realizar reuniones periodicas sobre el proyecto |
Fechas límites |
Respetar las fechas indicadas por el profesor para la entrega de los diferentes versiones de la aplicación |
Presentación |
Hay que realizar una presentación con una demo del proyecto una vez finalizado. |
2.3. Convenios
Convenciones |
Descripcion |
Arc42 |
La plantilla que usaremos para la documentacion es el modelo Arc42 |
Git-Flow |
Usamos el patrón git-flow trabajando en la rama develop principalmente, además de rama hotfix para solucionar problemas rápidos. |
Anexos |
Determinadas partes de la documentación que entren dentro del modelo Arc42, se pondrán en ANEXOS, ya que pueden aportar información para entender mejor el proyecto. |
3. Alcance y contexto del sistema
Esta aplicacion consiste en una tienda online de venta de videojuegos fisicos, por lo tanto tendremos que manejar tanto datos de usuarios como los propios productos. Por la naturalidad del concepto de tienda, se manejaran datos de productos como son el nombre, descripción del producto, precio, stock y el coste asociado al envío de todos estos productos al cliente. Sobre los datos de los usuarios trabajamos de acuerdo al principio SOLID, es decir tenemos descentralizados los datos de los usuarios en PODs. Cada usuario tiene su propio POD realizando todas las gestiones con ellos mediante el provedor de PODs Inrupt. Un usuario que no tenga un POD no podrá realizar una compra en nuestra tienda, lo único que podrá hacer es visualizar los productos.
3.1. Contexto empresarial
Veremos con este diagrama cual va a ser el contexto de la aplicacion y los PODs.
3.2. Contexto tecnico
Nuestra tienda DeDe se adecua a los principios SOLID de descentralizacion de datos personales mediante el almacenamiento de los mismos en PODs independientes para cada usuario, nuestro proovedor de PODs es Inrupt. El front-end se encuentra desarrollado mediante el framework React implementando componentes ya desarrolladas, o bien, creados por nosotros mismos, ademas el lenguaje para el desarrollo de las diversas funcionalidades de las pantallas es TypeScript. Por la parte del back-end, nuestro SGDB es Mongo.db y mediante Node.js express realizamos todas las transacciones a la base de datos, donde almacenamos los datos de los productos. La mayoria de peticiones se realiza mediante el protocolo web HTTP. Para calcular los costes de los envíos hacemos uso de una API externa muy popular, Geocoding.
A continuación, se muestra un diagrama para ilustrar los componentes de la aplicación que se encuentran afectados por cada tecnología.
4. Estrategia de Solución
4.1. Decisiones Técnicas
Para el desarrollo del proyecto se han tomado las siguientes decisiones:
| Nombre de la tecnológia | Objetivo |
|---|---|
TypeScript |
Lenguaje principal del proyecto |
React |
Biblioteca que facilitará el desarrollo de la interfaz gráfica |
MongoDB |
Base de datos que permitirá guardar los datos de los usuarios,centros de distribución y diferentes productos |
Github |
Herramienta de control de versiones que mejora el trabajo en equipo |
SOLID |
Especificación que permite a las personas almacenar sus datos de forma segura en almacenes de datos descentralizados llamados Pods. |
Heroku |
Utilizaremos Heroku para desplegar nuestra aplicación, de este modo no habrá preocupación por la infraestructura. |
Geocoding |
Consumiremos una API externa para calcular el precio de los envios. |
4.2. Decisiones sobre la descomposición de alto nivel del sistema
Se ha decidido utilizar el patrón arquitectónico MVC para desarrollar la aplicación
4.3. Decisiones para lograr objetivos de calidad
Para lograr cumplir con los diversos objetivos de calidad hemos realizado las siguientes acciones:
-
Privacidad: Para asegurar la mejor privacidad a los usuarios se usan los PODs de SOLID,los cuáles nos permiten almacenar los datos de usuario en un formato interoperable, y brindarles controles de autorización.
-
Usabilidad: Para mejorar este objetivo nuestras interfaces son lo más fluidas, simples e intuitivas posibles, ayudandonos siempre de metáforas como por ejemplo el icono de la casa para marcar el inicio o el de un carro para el carrito del cliente.
-
Eficiencia: Como el uso de los Pods de SOLID ralentiza la aplicación, solo será necesario tener iniciado el POD de usuario en otra ventana e introducirlo en el login, la aplicación no lo pedirá nunca más.
-
Testeabilidad: Se han realizado diferentes tipos de test para comprobar la robustez del proyecto, entre los que destacamos test unitarios, de usabilidad y test de carga.
4.4. Decisiones para la organización
-
Reuniones Durante la semana se ha planificado una reunión presencial, en la que se han expuesto los puntos ha realizar antes de la siguiente, además se han tratado los problemas u obstaculos encontrados, todo esto ha quedado reflejado a través de actas, disponibles en nuestra wiki, formando un total de más de 18 reuniones. Cuando ha surgido algun problema durante la realización del proyecto se ha podido planificar reuniones online a través de Discord.
-
Github Para poder realizar un buen control de versiones del proyecto se ha utilizado Github, donde se crearon diferentes ramas:
-
Master: producto final.
-
Develop: rama en la que se encuentra el producto en desarrollo.
-
Nombre del miembro: dentro de develop cada miembro tiene una rama en la que pueden trabajar.
-
Hotfix: rama para hacer cambios rápidos a la rama principal sin tener que pasar por otras de más bajo nivel. Esta rama se ha dividido en hotfix a secas para cambios de proyecto, hotfixDocu para cambios en documentación y hotfixTest para solucionar problemas de testing.
-
Backend: en esta rama se trabaja todo el código del Backend de manera conjunta. Añadiendo en la parte final del proyecto la rama backendFinal a partir de la release v1.0.0.
-
Nombre/documentacion: aquí cada miembro del equipo subió las partes de la documentación que fue desarrollando al principio, donde se planteo un esbozo de lo que finalmente sería la aplicación
-
Todo lo realizado en el proyecto, tanto problemas como distintas aportaciones se han recogido a modo de issues en el repositorio de github del proyecto. Cada issue ha sido asignada a distintos miembros del equipo y cerrada por otros. Añadiendo distintas etiquetas que hacen referencia a la parte del proyecto correspondiente.
Por otro lado, los miembros del equipo han realizado pull request antes de mergear con otra rama, estos han sido aceptados por compañeros revisando el código antes de que realizar el merge. Salvo para casos en los que la rama a mergear era una simple actualización.
5. Vista de construccion
5.1. Nivel 1: Vista general del sistema
En este diagrama podemos observar los principales agentes de la aplicacion, entraremos en detalle de los mismos mas adelante. La tienda DeDe ofrecera varios servicios al cliente algunos de los cuales implicaran manejar con datos convencionales (realizar un pedido, mostrar el catalogo de la tienda) o con los datos descentralziados de los clientes(PODs) como identificacion o registro.
Nombre |
Responsabilidad |
DeDe |
Es la aplicacion en si, esta contenida en ella todas las funcionalidades y servicios necesarios. |
5.2. Nivel 2
Mostrar las dos partes principales que componen la aplicacion DeDe
Nombre |
Responsabilidad |
Capa de servicio |
Tambien conocida como front-end en ingles, es la interfaz de la aplicacion, la cara visible hacia el usuario. |
Capa de datos |
Tambien conocida como back-end en ingles, corresponde a las operaciones de tratamiento de datos de la aplicacion (registro, log-in). |
5.3. Nivel 3
La principal motivación perseguida es la de, descomponer las dos partes principales vistas en el nivel anterior con detalle respecto a operaciones concretas de los usuarios y las acciones de acceso datos que estas conllevan, tanto a POD como a la BBDD.
Nombre |
Responsabilidad |
Catalogo |
Mostrar el catalogo de productos a los usuarios |
Ver perfil |
Mostrar informacion del usuario relativa a su historico de pedidos. |
Comprar |
Los clientes podran comprar juegos |
6. Vista en tiempo de ejecución
Los siguientes casos de secuencias explican algunos de los escenarios que se pueden dar lugar en DeDe
6.1. Login de Usuario
6.2. Registro de usuarios
6.3. Vista del carrito con productos del usuario no identificado
6.4. Vista del carrito con productos del usuario con datos POD correctos
6.5. Vista del carrito con productos del usuario con datos POD incorrectos
6.6. Compra de los productos
7. Vista de implementación
7.1. Algunas consideraciones
-
Nuestra aplicación funcionará desde cualquier ordenador a través del navegador. De esta forma los requisitos necesarios para ejecutarla se ven reducidos, haciendo la aplicación más accesible para personas con equipos menos potentes. Se puede visualizar en el ANEXO III.
-
Se recomienda el uso de los navegadores clásicos, como son Google Chrome y Firefox. Otros navegadores como Safari, Edge u Opera, también pueden ser utilizados aunque en determinadas circustancias podrían dar algún tipo de problema debido a sus restricciones de seguridad.
-
La dirección de envío se obtiene desde el POD de cliente, por lo que no es necesario tener la ubicación del navegador activada.
-
Los datos del cliente siempre se mantendrán por separado en un POD, siguiendo los principios SOLID. De esta forma, dejamos claro que los datos de clientes y productos se encuentran separados y que no se tiene acceso a los datos de clientes.
-
La aplicación se podrá visualizar también desde el navegador de un dispositivo móvil, para ello simplemente bastará con meter la dirección url donde se encuentre alojada la tienda. Se recomienda el uso de las aplicaciones de navegador móvil mencionadas anteriormente. Se puede ver en el ANEXO II
7.2. Infraestructura técnica
7.2.1. Despliegue
A la hora de desplegar el proyecto se dan dos opciones, desplegarlo de manera local o mediante un servicio de hosting web.
Tipo de hosting |
Características |
Local |
Se puede lanzar la aplicación mediante un servidor local en el propio ordenador, esto es una opción para los usuarios más técnicos con algun conocimiento previo. |
En servidor web |
Servicio que sirve para alojar la aplicación en un servidor remoto, pudiendo hacer accesible la aplicación para el resto de personas. Existen multitud de servicios de hosting que cuentan con soporte técnico. Se ha utilizado para el despliegue Heroku, de esta forma no es necesario preocuparse por la infraestructura, soportando además múltiples lenguajes de programación. Esto lo realiza mediante el uso de contenedores Linux llamados dynos. |
7.3. Motivación
Nuestra filosofía para desarrollar esta aplicación se basa en no utilizar para nada los datos de los usuarios, puesto que no tenemos ningún interes en estos. Creemos en el código abierto y en los principios SOLID de desarrollo de software, donde cada usuario es el dueño de sus datos. La técnica utilizada durante el desarrollo es ponerse desde la vista de usuario haciendo la aplicación lo más accesible posible.
8. Conceptos transversales
8.1. Conceptos de dominio
| Rol | Explicación |
|---|---|
Usuario |
Representa un usuario de la aplicación, toda su información se guardará en un POD. |
Posición de envío para el usuario |
Se conoce la posición de envío para el usuario gracias al POD. Se puede calcular un precio diferente dependiendo de la distancia al centro de distribución. |
Productos |
Lista de productos disponibles con toda la información relevante como precio, descripción y una imagen ilustrativa del producto. |
8.1.1. Conceptos de experiencia de usuario
La aplicación está desarrollada para que el usuario pueda interaccionar con ella de manera sencilla, no es necesario que tenga conocimientos previos, pero como es lógico si ya se encuentra familiarizado con plataformas de compra electrónica como Steam u Origin, siempre le será más sencillo.
El usuario podrá identificarse haciendo clic en la parte derecha del panel introduciendo su POD, o bien acceder a crear un POD en la página de inrupt donde se le redirige si su POD no es válido o no se encuentra con inrupt iniciado. La única forma de compra y acceso a la aplicación es la de usuario propietario de un POD con inrupt iniciado, nos tomamos muy enserio la privacidad y creemos que esta es la mejor manera de interacción con nuestro sistema.
8.1.2. Conceptos de seguridad y protección
En líneas generales, nuestra aplicación es segura. Hemos utilizado los principios SOLID, esto es que, los datos de los usuarios serán almacenados de forma segura en almacenes de datos llamados PODS. Los PODS (Personal online data stores) pueden contener cualquier tipo de información, en nuestro caso contiene email que será el usuario, password, nombre, apellido, teléfono, país, provincia, ciudad, código postal, calle, número, piso y letra del piso. El acceso a los datos de los PODS se puede restringir y controlar de manera segura, eligiendo las reglas de acceso determinadas.
Se ha prestado especial atención en fortificar la base de datos, ya que muchos de los ataques conocidos se centran en esta parte de las aplicaciones, separando los PODS de usuarios de la propia base de datos de la aplicación.
8.1.3. Arquitectura y patrones de diseño
Una de las decisones más importantes a la hora de desarrollar una aplicación es pensar en el diseño, uno de los referentes que hemos tenido en cuenta es el libro de Erich Gamma, Design Patterns. En esta obra se explican algunos de los principios más populares para el desarrollo de software mantenible y de calidad. Además tambien hemos consultado multitud de artículos donde se explican tecnicas para un buen desarrollo y un bajo acoplamientro, con esto hemos decidido aplicar varias cosas:
-
Modularidad: esto es que la aplicación se encuentra compuesta por varios componentes, que juntandose hacen una aplicación funcional. Si uno de los componentes cambia, el resto no se verá afectado.
-
Fachada: haciendo referencia al patrón de diseño arquitectónico, hacemos la separación e interacción necesaria con SOLID para que todo funcione y se mantenga un minimo acoplamiento.
-
MVC (Modelo vista controlador): para poder gestionar las vistas en el frontend con las peticiones en el backend.
8.1.4. "Bajo el capó" conceptos de desarrollo
La aplicación cuenta con un frontend y un backend perfectamente comunicados. La parte del frontend es la que ve el usuario y a la que tendrá acceso, aquí se incluyen todos los menus, botones y vistas de la aplicación.
Tanto la lógica de la aplicación como la base de datos forman parte del backend, el frontend hará peticiones al backend y todo esta sincronizado para que así ocurra. Como ya se menciono anteriormente, los datos de usuario son guardados en un POD, separandose de la base de datos de productos de la aplicación para seguir los principios SOLID y aumentar la seguridad.
8.1.5. Conceptos operativos
Las operaciones básicas que se pueden realizar desde la aplicación con el rol de usuario son:
-
Autenticación de usuario: Hace referencia a identificarse en la aplicación como usuario registrado mediante su POD.
-
Compra de producto: El usuario podrá adquirir los productos que considere, como si se tratase de un comercio fisico.
-
Operaciones en carrito: Hace referencia a operaciones de añadir o eliminar productos dentro del carrito.
-
Filtrar por categorias: Una función que consiste en que el usuario pueda ver de manera más concreta determinado tipo de productos.
-
Filtrar por nombre: Una función que consiste en que el usuario pueda buscar un producto por su nombre.
Es importante destacar que el filtro por nombre funciona sobre el filtro de las categorías, es decir, si en primer lugar filtramos por ejemplo por la categoría aventura y luego aplicamos el filtro por nombre. La aplicación nos devolverá los resultados para ese nombre dentro de la categoría del filtro.
En el siguiente diagrama se puede apreciar de forma gráfica las operaciones que puede realizar el usuario explicadas anteriormente:
9. Decisiones de diseño
En este documento se recoge de manera continuada las distintas decisiones de diseño que se han tomando en el desarrollo del proyecto. Se describe a modo de tabla formada por cinco columnas:
-Orden: se trata del orden de aplicación.
-Sección: Se explicará a la sección que pertenece la decisión. P.e: Base de datos.
-Decisión: La decisión tomada respecto a la sección. P.e: Para la sección Base de datos, la decisión es utilizar MongoDB.
-Ventajas: Refleja las ventajas de utilizar la tecnología reflejada en decisión.
-Inconvenientes: Dificultades tanto de miembros del equipo como de la propia tecnología.
Orden |
Sección |
Decisión |
Ventajas |
Inconvenientes |
1 |
Base de datos |
Utilizar MongoDB como base de datos para almacenar la información de la tienda |
Versatilidad NoSQL, buena implementación con TypeScript |
Ningún miembro del equipo lo ha utilizado antes, pueden surgir problemas técnicos |
2 |
Lenguaje de programación |
Utilizar TypeScript como lenguaje principal en el desarrollo de la aplicación |
Escalabilidad del código, fácil testeo |
Desconocimiento técnico sobre el lenguaje, lol que podría hacer que se generase deuda de código y deuda de diseño. |
3 |
Librerias |
Utilizar React y Material UI para las interfaces de usuario |
Es de código abierto, mucha documentación en la web |
No cuenta con documentación oficial ni con estandar de desarrollo. |
4 |
Despliegue |
Utilizar Heroku para el despliegue |
No hay que preocuparse por la infraestructura, soporte de muchos lenguajes de programación |
Desconocimiento técnico, nadie del grupo lo ha utilizado nunca. |
5 |
Test |
Utilizar test para probar Backend y Frontend |
Probar el código de manera automatizada |
Si se diseñan mal puede dar lugar a deuda de prueba. |
6 |
Test |
Utilizar Codecov para comprobar porcentaje de test |
Obtendremos el porcentaje exacto de partes del código que se encuentran testadas |
Puede llevar tiempo aprender a implementarlo en el proyecto. |
7 |
Documentación |
Utilizar Arc42 para la documentación |
Es un estandár ya probado |
Su complejidad puede provocar deuda de documentación. |
8 |
APIs |
Consumir Geocoding como API externa para calcular el precio de envío de los productos. |
Poder calcular costes de envío |
Hay que aprender a consumir la API. |
9 |
Test |
Utilizar Gatling par test de carga |
Comprobamos con distintos niveles de carga de usuario el funcionamiento de la aplicación |
Nadie sabe usar previamente Gatling. |
10. Requerimientos de calidad
10.1. Árbol de calidad
10.2. Escenarios de calidad
Tabla con nuestros objetivos de calidad, los escenarios y las prioridades:
| Objetivos de calidad | Escenarios | Prioridad | Dificultad |
|---|---|---|---|
Usabilidad |
La aplicación debería de poder ser usada por cualquier tipo de usuario independientemente de su nivel, para probar esto utilizaremos test con personas ajenas al proyecto. Los resultado obtenidos se pueden visualizar en ANEXO I. |
Alta |
Alta |
Privacidad |
La gestión de información es descentralizada. El usuario no se debe de preocupar acerca de sus datos ya que solo se le pedirá su email y contraseña, el resto de datos van almacenados en un POD externo y seguro. Sin un POD correcto es imposible comprar en la aplicación. |
Alta |
Media |
Seguridad |
La aplicación debe de ser extremadamente segura para que nada referido a la información personal de los usarios pueda ser filtrada. Para ello, todos los datos de usuarios será metidos en un POD en lugar de en la propia aplicación, complementando al objetivo de privacidad. |
Alta |
Alta |
Portabilidad |
Que la aplicación pueda adaptarse de forma correcta a distintos dispositivos, la aplicación se verá de manera correcta en el navegador de un pc y de un smartphone. Ver ANEXOS II Y III. |
Media |
Media |
Testeabilidad |
Que la aplicación haya sido probada y se sepa de forma segura que no va a romper por ningún sitio. Para ello se alcanzará más de un 80% de cobertura de test unitarios, además de test de usabilidad y de carga sobre el despliegue. |
Alta |
Media |
Modificabilidad |
En caso de tener que añadir algún mejora, es facil de modificar y no influye en el resto de partes del proyecto gracias al bajo acoplamiento con el que se encuentra programada. |
Baja |
Alta |
11. Riesgos y Deudas Técnicas
11.1. Tabla de riesgos
| Prioridad | Riesgo | Explicación | Solución |
|---|---|---|---|
1 |
SOLID |
Nadie del equipo ha utilizado SOLID, por lo que todos carecemos de conocimiento sobre este framework. |
Leer más artículos relacionados con este tema o verse alguna guía. |
2 |
React |
Nadie tiene experiencia con REACT, aunque todos los miembros del equipo ya conocen JavaScript |
Adaptar el conocimiento de JavaScript a TypeScript. |
3 |
MongoDB |
Nunca hemos trabajado con esta base de datos en concreto pero todos los miembros ya han utilizado una no relacional. |
Comprender su funcionamiento mirando documentación al respecto |
4 |
GitHub |
Aunque todo el equipo trabaja bien con GitHub falta soltura a la hora de realizar ciertas acciones. |
Esto no supone un gran inconveniente, se resolverá a medida que nos vayan saliendo los problemas. |
5 |
Heroku |
Nunca nadie del equipo ha realizado ningún despliegue con Heroku. |
Los miembros del equipo se apoyarán en la documentación oficial donde se encuentra explicado. |
11.2. Tabla deuda técnica
| Riesgo | Explicación | Solución |
|---|---|---|
Conflictos en gitHub |
A la hora de mergear puede dar fallos |
Hacer una reunión para solucionarlo |
Robustez |
Al tener poca experencia en trabajar en este tipo de proyectos en grupo puede darse la situación de que el código no quede robusto |
Tener mucha comunicación |
Retardo al hacer login |
Al cargar los datos del POD de inrupt.net se provoca cierto retardo |
Tener una buena conexión cableada |
Retardo al cargar imágenes |
Al cargar los datos de imagenes del drive del proyecto se provoca cierto retardo |
Tener una buena conexión cableada |
12. Glosario
| Termino | Definición |
|---|---|
Discord |
Servicio de mensajería instantánea freeware de chat de voz VolP, video y chat por texto |
SOLID |
Proyecto desarrollado por Tim Berners-Lee que busca descentralizar los datos de los usuarios del resto de datos de la aplicacion almacenandolos en POD |
Pod |
Almacenamiento personal de datos alojado en un servidor elegido por el usuario. |
Github |
Plataforma de desarrollo colaborativo para alojar proyectos utilizando el sistema de versiones Git. |
MongoDB |
Sistema de base de datos NoSQL, orientado a documentos y de código abierto |
REACT |
Biblioteca Javascript de código abierto diseñada para crear interfaces de usuario con el objetivo de facilitar el desarrollo de aplicaciones en una sola página |
Whitebox |
En diagramas, un componente que nos muestra los componentes que tiene en su interior. |
Blackbox |
En digaramas, un componente opaco que no nos permite ver las partes que tiene en el interior. |
Inrupt |
Empresa colaboradora con el proyecto SOLID de Tim Berners-Lee ofrece un servicio de provedor de PODs, su url es Inrupt.net |
Material-UI |
Libreria de componentes para React con multiples estilos. |
HTTP |
Protocolo de transferencia de hipertexto, es el protocolo usado para las comunicaciones entre maquinas en la web |
Videojuego |
Juego electrónico que se visualiza en una pantalla de un televisor, ordenador o otro dispositivo electronico |
Heroku |
Es un Paas(Platform as a Service) que nos permite desplegar nuestras aplicaciones sin preocupaciones por la infraestructura. |
Geocoding |
Es una API muy utilizada para dar servicios de direcciones físicas. |
Anexos
En este apartado se recogen varios anexos para enriquecer el entendimiento de determinadas partes de la documentación.
1. Anexo I
En este anexo se recoge el cuestionario utilizado para medir la usabilidad de la aplicación. Se ha elaborado un cuestionario con 10 preguntas, algunas con respuesta corta, otras de opción multiple y tambien se han incluido una para valorar en escala likert.
El cuestionario se planteo mediante google forms, con una muestra de 15 personas de diferentes edades y con distinto nivel técnico.
Las respuestas obtenidas a este cuestionario han sido las siguientes:
Respecto a la edad, podemos observar que el grupo predominante es el de más de 50 años, seguido por el de entre 10 y 20. Esto es debido a que el cuestionario se ha realizado a familiares cercanos en su mayoría como por ejemplo madres, padres, hermanos o primos. De igual forma se puede apreciar como hay gente en todos los grupos de edad en la muestra.
Una de los grandes problemas en la aplicación ha sido al utilizar el login, el 66,7% afirma que ha tenido problemas al realizarlo, es decir casí 7 de cada 10. Tan solo el 33,3% ha podido loguearse sin problemas, posiblemente personas con conocimiento más técnico. Junto a esta pregunta se daba la opción en la siguiente de explicar estos problemas.
Las opiniones más repetidas al respecto tienen que ver con "no entender muy bien el tema de los POD" o que "eso no se usa en otras plataformas estilo Amazon". Utilizar los POD y SOLID es uno de los requisitos del trabajo y por ello lo hemos utilizado.
Se ha realizado una pregunta cerrada con tres opciones de respuesta respecto a la navegación por la tienda. El resultado obtenido ha sido que el 80% afirma que la navegación es clara e intuitiva. Para esto hemos utilizado la metáfora del carrito y también la metáfora de la casa para llevar al inicio. Tan solo el 20% de los encuestados hace hincapié en que de alguna manera la navegación de la aplicación en alguna ocasión puede llevar a confusión.
A pesar de ser algo muy subjetivo, quisimos que los entrevistados valorasen la estética de la aplicación, con el fin de establecer campos de mejora. Se estableció una escala del 1 al 10, en la que 1 es una estética muy pobre y 10 es una estética sobresaliente. Los resultados obtenidos han sido por encima de 6 puntos siempre, incluso en algún caso alcanzando el 10. La moda ha sido de 9 sobre 10, lo que denota que la estética de la aplicación, en lineas generales ha sido atractiva para los encuestados.
En los casos en los que les era imposible el acceso debido al POD, se les enseñó como entrar con un POD propio y se les pidio que realizasen una compra. En el cuestionario tambien se les pidio si podían evaluar este proceso de compra reguntandoles si les había resultado sencillo. El 93,3% afirmaba que fue sencillo realizar la compra.
Se realizó una pregunta sobre el filtro por categorías, donde el 100% afirma que han podido utilizar bien el filtro sin ninguna complicación.
Para finalizar el cuestionario se les animo a escribir unas palabras sobre lo que les había parecido la aplicación a modo de observaciones. La mayoría afirman que la aplicación es bonita y que se puede comprar en ella sin problemas, el unico problema que se repite es el de entender el uso de los POD y de porqué su uso es tan útil.
2. Anexo II
En este anexo se recoge algunas imagenes de como se ve la aplicación en un smartphone.
En primer lugar de como se muestra el catálogo de juegos, completamente funcional haciendo scroll.
En segundo lugar, el carrito con sus productos añadidos y el precio a pagar por la ubicación del POD.
En tercer lugar, un juego al detalle, donde se muestra su descripción, precio y posibilidad de compra.
Por último tambien se muestra la pantalla de login, que redirige a inrupt.net para posteriomente una vez identificado, volver a la aplicación de manera automática.
3. Anexo III
En este anexo se recoge la vista de la aplicación desde el ordenador a modo complementarío.
El login en la aplicación se realiza mediante el login de inrupt.net que, una vez iniciada la sesión, nos lleva a la ventana de cliente.
El home de la aplicación cuenta con todo el catálogo de juegos.
Los juegos se pueden filtrar por distintas categorías.
Además, tambien se puede realizar busquedas por nombre sobre el propio filtro y de manera bidireccional. Según se van completando letras del nombre, van saliendo resultados.
Se cuenta con una ventana de detalle, en la que cada juego cuenta con una descripción, una imagen y el precio del juego.
Cada usuario puede consultar su histórico de pedidos, que cuenta con la fecha, el email y la cantidad como datos adicionales al juego.
Se cuenta con un carrito donde se pueden añadir y eliminar productos, además de que nos da un precio de envío dependiendo del lugar donde tengamos nuestra dirección de POD.
4. Anexo IV
En este apartado se incluirán los aspectos relativos a las pruebas de carga.
Hemos realizado pruebas de carga sobre el ultimo despliege de la aplicacion a fin de conocer los limites de carga de trabajo que puede manejar y los tiempos de respuesta de la aplicación para diversas acciones de los usuarios. La herramienta utilizada para medir esto es Gatling. A continuacion, mostramos los informes de los resultados obtenidos.
Acceso simultaneo de 100 usuarios a la web
Acceso simultaneo de 1000 usuario a la web
LogIn de 50 usuarios en 60 segundos
LogIn de 10 usuarios/segundo durante 60 segundos
LogIn de 100 usuarios/segundo durante 60 segundos
Acceden a un juego 5 usuarios/segundo durante 60 segundos
Acceden a un juego 30 usuarios/segundo durante 60 segundos
Añaden 3 juegos al carrito 5 usuarios/segundo durante 60 segundos
Añaden 3 juegos al carrito 30 usuarios/segundo durante 60 segundos
Comprar un juego 5 usuario/segundo durante 60 segundos
Comprar un juego 30 usuario/segundo durante 60 segundos
5. Anexo V
En este apartado se incluirán los aspectos de mejora del proyecto establecidos en la reunión previa a la última release. Estos aspectos surgen del análisis de los cuestionarios realizados y de la opinión de los desarrolladores del proyecto.
-
Cambiar el servicio externo de las imagenes para evitar el cuello de botella que se genera en determinadas ocasiones.
-
Sería interesante añadir el rol de administrador también a la parte de front, ya que en el back end si que esta disponible.
-
Tambien estaría bien cambiar datos del POD desde DeDe, para por ejemplo, modificar la dirección de envío.
-
La optimización para dispositivos móviles podría ser mejorable.
-
El redimensionado de las imagenes tambien se podría mejorar para que se adapten sin cortes.
-
Enviar un correo al usuario con los datos del pedido. Esto se trato de realizar pero por problemas de compatibilidad no fue posible.
Los miembros del grupo opinan que, en lineas generales con mayor tiempo para investigar sobre estos aspectos, podrían haberse llevado a cabo.
About arc42
arc42, the Template for documentation of software and system architecture.
By Dr. Gernot Starke, Dr. Peter Hruschka and contributors.
Template Revision: 7.0 EN (based on asciidoc), January 2017
© We acknowledge that this document uses material from the arc 42 architecture template, http://www.arc42.de. Created by Dr. Peter Hruschka & Dr. Gernot Starke.