concerns - Mappo1562/GRUPO21-2025-PROYINF GitHub Wiki
1-. Flexibilidad del sistema para soportar múltiples plantillas personalizables.
Este concern impacta en la calidad a modo de:
- Modificabilidad agregar nuevas plantillas sin alterar el programa base.
- Usabilidad los usuarios podran crear y modificar las plantillas sin conocimientos técnicos.
- Reusabilidad se podrán volver a utilizar las plantillas.
En lo que a arquitectura respecta, se tendrá que implementar una funcionalidad, donde se pueda gestionar todo lo respectivo a las plantillas.
En cuanto a si nuestro diseño aborda los requisitos derivados del concern, la respuesta es que no. Nuestro diseño no posee ninguna funcionalidad correspondiente al soporte de múltiples plantillas personalizables. Para poder implementar lo anterior es necesario agregar plantillas editables a la BBDD. Esto se puede realizar agregando un modulo de gestión de plantillas en el backend. Igualmente se puede implementar un editor visual en el frontend de nuestra plataforma web para que así los usuarios puedan ir configurando y modificando sus plantillas.
Los trade-offs y los riesgos asociados corresponden a los siguientes:
- Complejidad en el desarrollo vs. facilidad de uso
En contra: Al implementar un editor visual, la complejidad del desarrollo aumenta considerablemente. El esfuerzo de desarrollo se incrementará y se necesitaran más pruebas para garantizar que el funcionamiento del editor sea correcto.
A favor: En contraparte, los usuarios finales podrán diseñar y editar plantillas de forma sencilla e intuitiva.
- Riesgos asociados
Al generar un editor de plantillas, este puede crear una sobrecarga en la CPU de quien lo utiliza. En momentos de alta demanda el sistema podría degradar tiempos de respuesta o incluso caer.
2-. Capacidad de controlar los accesos a partir de distintos roles.
Este concern impacta en la calidad a modo de:
- Seguridad solo le dará acceso a las personas con el rol correspondiente.
- Integridad solo las personas con una cuenta y con un rol podrán acceder a su parte del software.
- Flexibilidad si se quiere agregar un rol distinto, no es necesario hacer un cambio muy grande.
En lo que a arquitectura respecta, se implementó una funcionalidad donde se puede gestionar todo lo respectivo a los roles y vistas que se tendrán dependiendo de el rol de la cuenta, también se implementó un login para verificar que cierto usuario realmente tiene su rol correspondiente
En cuanto a si nuestro diseño aborda los requisitos derivados del concern, la respuesta es que si. Nuestra plataforma da acceso a las personas dependiendo de su rol mediante el log in de la aplicación. Una vez se ingrese, se mostrará una vista de acuerdo al rol designado. Igualmente, la plataforma le da acceso a ciertas funcionalidades dependiendo del rol asignado a la persona, cumpliendo con una integridad en la aplicación. También, si se quiere agregar un rol diferente, eso se puede lograr mediante la vista de "admin". No es necesario realizar un cambio en el backend sino que desde el frontend es posible.
Los trade-offs y los riesgos asociados corresponden a los siguientes:
- Verificación de permisos para roles vs. rendimiento por cada petición
Por cada petición que llega para los roles, esta se tiene que verificar en la BBDD para revisar la vista y los permisos correspondientes al rol.
En contra: Existe latencia por cada petición. Si son muchas, puede existir tiempo de respuesta tardío.
A favor: Existe seguridad e integridad en la plataforma al revisar que le corresponde a cada rol.
- Riesgos asociados
El riesgo asociado es justamente la degradación del rendimiento ante alta concurrencia. Si en un momento dado existe mucho volumen de gente, se puede generar una sobrecarga y aumentar drásticamente los tiempos de respuesta.
3-. Integración con fuentes de datos confiables.
Este concern impacta en la calidad a modo de:
- Confiabilidad ya que se trabajara con datos revisados y específicos.
- Correcto, ayuda a que los boletines no tengan errores a causa de una mala fuente.
- Mantenibilidad si se quiere agregar otra fuente, el cambio no debe ser tan grande.
En lo que a arquitectura respecta, se tendrá que implementar una manera de validar los datos, con cierta tolerancia a fallos e integridad de los datos
En cuanto a si nuestro diseño aborda los requisitos derivados del concern, la respuesta es que no. Nuestro diseño no posee ninguna funcionalidad correspondiente a la integración con fuentes de datos confiables. Para poder implementar lo anterior podemos crear un servicio que conecte a fuentes confiables y nuevas mediante API REST o BBDD remotas. A partir de ahí podemos recibir data en bruto para luego ir depurando la misma.
Los trade-offs y los riesgos asociados corresponden a los siguientes:
- Complejidad de implementación vs. flexibilidad para nuevas fuentes
En contra: Se incrementa notablemente la complejidad del desarrollo y diseño. Se tendrían que definir interfaces y lógicas de validaciones genéricas y específicas para cada conector.
A favor: Se fomenta la mantenibilidad. Cada vez que se quiera conectar una fuente nueva, basta con crear un nuevo conector.
- Riesgos asociados
Un riesgo asociado es que, si una API o servidor remoto se cae durante un tiempo prolongado, la plataforma se quedaría sin datos de fuentes confiables si es que no existen fuentes suficientes para suplir las caídas.