Requisitos no funcionales - rBaku/Proyecto-LogisticaGlobal.com GitHub Wiki

El proyecto tiene en consideración una variedad de requisitos en específico 9 que son No Funcionales, estos son difíciles de considerar, testear y asegurar que se cumplen, pero dentro de lo desarrollado, esto fue lo realizado (a la hora de las pruebas, revisar detalle de la documentación de pruebas):

1. Usabilidad: Se consideró crear un Frontend amigable con los usuarios y que se entendiera fácilmente que realizaba cada aspecto del sistema. Se mantiene el uso de botones para una misma función, se omite información que no es importante para cada rol y que no está considerada en sus actividades. Para realizar pruebas se necesitaría realizar pruebas de usuario.

2. Rendimiento: Algo importante en cada sistema que planea mejorar la eficiencia en las empresas es la velocidad en que funciona distintos aspectos del sistema, considerando siempre el volumen de datos y la complejidad de cada función. No se han realizado pruebas, pues se necesitaría llenar de datos el sistema y es más fácil probarlo cuando ya se está usando el sistema.

3. Seguridad: Es esencial considerar la seguridad de los datos cuando se maneja información sensible de la empresa y los usuarios del sistema (datos de trabajadores), por ello el sistema considero tener un hash de las contraseñas para aumentar la seguridad del acceso al sistema y se consideraron pruebas como intentar ejecutar comandos SQL en el inicio de sesión.

4. Confiabilidad: Un sistema no es muy funcional si no se considera que se puede confiar en los datos guardados y modificados por parte de los usuarios, el sistema tiene en consideración esto y verifica que cada cambio en la base de datos sea realizado correctamente, además, se considera que el sistema guarda un historial de cambios realizados por los usuarios.

5. Disponibilidad: Depende del sistema, pero en general se requiere que el sistema esté funcionando correctamente mientra se realizan las funciones de la empresa, no se han realizado pruebas para revisar la disponibilidad del sistema, pero dado que el Backend esta en la nube, depende principalmente del correcto funcionamiento de Azure.

6. Escalabilidad: Un sistema siempre puede ser modificado a futuro, pues con el tiempo aumenta la carga sobre la base de datos y el movimiento de la información dentro del sistema. Se tuvo en consideración durante el desarrollo, pero al igual que el rendimiento, no se ha probado grandes volúmenes de datos en el sistema.

7. Mantenibilidad: El sistema puede cambiar a futuro, ya sea para arreglar errores o para modificar funciones, pues la empresa o su entorno cambian con el tiempo y estos se deben aclimatar. En el desarrollo se tuvo consideración los comentarios en funciones, variables y bloques de códigos, mantener un orden en carpetas y códigos. Además, se modifico la wiki del repositorio para agregar información y detalles en escrito de funciones y procesos del sistema.

8. Compatibilidad: Muchas veces, los sistemas no solo se utilizaran con parámetros promedio de tamaño y sistema, se pueden usar en una variedad de dispositivos, tamaños de pantalla, diferentes navegadores o sistemas. Se han considerado pruebas en relación al tamaño de la página y se probó su funcionamiento en navegadores populares como Chrome o Firefox.

9. Tecnología: Todos los sistemas tienen un Stack tecnológico, que puede variar entre sistema y depende de lo que se quiere crear. El sistema tiene un Stack de tecnologías PERN, usa base de datos Azure y herramientas de automatización, para más detalles acceder a la página de wiki que detalla esto. Además, se ha agregado en la documentación las herramientas utilizadas en el proceso de desarrollo por parte del equipo.