Principales atributos de calidad

6.4.1. Seguridad

La seguridad es un aspecto importante para el proyecto, ya que si bien no se manipulan datos extremadamente sensibles, si se manipula informaci´on de clientes como nombre, direcci´on, tel´efono, entre otros, para lo cual se necesita tener cierto nivel de seguridad. Para ello, se tomaron algunas decisiones, las cuales se detallan a continuaci´on.

Por un lado, la comunicaci´on de los dos sitios web con laAPI se realiza a trav´es del protocolo seguro HTTPS (HyperText Transfer Protocol Secure). Como se co- ment´o anteriormente, en el ambiente de producci´on se utilizaron dominios del cliente, por lo que se obtuvieron y configuraron los certificados SSL(Secure Sockets Layer) necesarios.

Estos dominios son la ´unica puerta de entrada al backend del sistema ya que se configur´o que toda la comunicaci´on entre los componentes del backend (servidor y base de datos), se realice mediante una red de alcance privado. Para ello, se cre´o y configur´o un VPC (Virtual Private Cloud), que es una red virtual privada en la nube en AWS. En esta VPC se agregaron las instancias de los servidores y de la base de datos, configurando solo la comunicaci´on entre los componentes de esa red privada, limitando el acceso por fuera.

Por su parte, se utilizaron las t´acticas de seguridad de autenticaci´on y autori- zaci´on de usuarios mediante tokens encriptados, JWT (JSON Web Token). Este m´etodo de autenticaci´on se utiliz´o tanto para administrar los tokens de los funcio- narios de la plataforma de gesti´on, y tambi´en para saber los datos que son p´ublicos y pueden ser enviados a la web de usuarios.

Para poder operar sobre la plataforma de gesti´on, los funcionarios deben primero iniciar sesi´on en la misma para que puedan obtener el tokens y de esa forma sean autenticados y autorizados. Sin embargo, hay informaci´on la cual es consumida por la web de usuarios que no es necesario tener un token para poder obtenerla.

6.4.2. Usabilidad

Como se coment´o anteriormente, se utiliz´o el enfoque de Dise˜no Centrado en el Usuario para dise˜nar las soluciones. A su vez, se siguieron los lineamientos de dise˜no asociados a las heur´ısticas de Nielsen y diferentes patrones de dise˜no. Todas estas pruebas y detalles se especifican m´as adelante en el cap´ıtulo deUsabilidad.

6.4.3. Disponibilidad

Si bien algunas funcionalidades de los sistemas tienen integraciones y depen- dencias con terceros, como es la integraci´on conMercado Libre, la gran parte de las funcionalidades no requieren estas integraciones, lo que permitir´a manejar y mejorar la disponibilidad de los sistemas. Por su parte, se decidi´o realizar el despliegue en AWS, el cu´al provee una alta disponibilidad que ayudar´a a favorecer a este atributo de calidad.

6.4.4. Mantenibilidad

Como fue previamente mencionado en los desaf´ıos de la arquitectura, la man-

definieron est´andares de codificaci´on, de lo cuales se hablar´a m´as adelante en el cap´ıtulo 9.Gesti´on de Calidad. A su vez, se hizo fuerte hincapi´e en respetar los li- neamientos del libro Clean Code y los principios SOLID.

De forma de asegurar que se respetaran dichas decisiones y lineamientos, se im- plementaron pol´ıticas de revisi´on de c´odigo cruzada, en la cu´al el c´odigo debe ser revisado por un miembro del equipo, que no haya implementado dicho c´odigo a re- visar.

Asimismo, se utilizaron las herramientasEsLint yPrettier. Las mismas escanean el c´odigo est´atico y verifican que se cumplan las reglas configuradas, en el caso que no se cumplan dichas reglas se notifica el error.

Para esto, se configur´o la librer´ıa Husky, la cu´al brinda la posibilidad de ejecutar las validaciones de c´odigo antes de realizar un commit. En el caso que no se cumpla alguna de ellas, no se permite realizar el mismo. A continuaci´on se despliega una captura de pantalla de como se muestran los errores conHusky y como se bloquea elcommit.

Figura 6.4: Error capturado en el pre-commit

6.4.5. Portabilidad

El dise˜nar aplicaciones web como soluci´on, permite poder acceder a los mis- mos desde cualquier dispositivo y cualquier navegador. As´ı mismo para ayudar a la portabilidad, ambos sitios web son responsivos, para que de esta forma se adapten f´acilmente al tama˜no de cualquier pantalla.

Adem´as se verific´o que estas aplicaciones se ejecuten correctamente en diferentes navegadores y en diferentes dispositivos.

A continuaci´on se muestra un ejemplo de como la aplicaci´on web de los usuarios, se adapta correctamente para diferentes tama˜nos:

Figura 6.5: Web para usuarios desde computadora

Figura 6.6: Web para usuarios desde celular

6.4.6. Testeabilidad

Para favorecer la mantenibilidad y modificabilidad de los sistemas, los mismos deben ser f´aciles de probar. Para esto, el equipo decidi´o implementar diferentes tipos de pruebas en los diferentes sistemas. En el cap´ıtulo 9. Plan de calidad, se entra en detalle las diferentes actividades de pruebas realizadas.

Por otro lado, como se coment´o anteriormente se utilizaron diferentes ambientes para poder ir realizando pruebas en cada uno de ellos. Es importante que los tres ambientes sean lo m´as parecidos posible para evitar distintos comportamientos en cada uno de ellos.

Adem´as, se utiliz´o el patr´on de dise˜no de capas, Layer pattern, el cual facilita la testeabiliad, ya que el mismo permite probar cada capa por separado.

Por otro lado, se automatiz´o con Github Actions el proceso de ejecuci´on de pruebas unitarias del backend. De todo este proceso se adentra m´as en detalle en el cap´ıtulo 9. Plan de calidad.