Todos los entregables del proyecto ABCJobs se relacionan en esta página. Cada vínculo redirige al respectivo entregable. En caso de tener problemas con el acceso, por favor comunicarse con alguno de los integrantes.

• Alonso Daniel Cantú Trejo [email protected]
• Camilo Andres Gálvez Vidal [email protected]
• Diego Fernando Eslava Lozano [email protected]
• Luis Miguel Guzmán Pérez [email protected]

• Definición del problema
  • Objetivos del proyecto
  • Criterios de evaluación de los objetivos
  • Alcance de la solución
  • Suposiciones
  • Restricciones
  • Factores generales de riesgo
  • Interesados
  • Hitos principales
• Solución propuesta
  • Objetivos de Negocio
• Restricciones de Negocio
• Restricciones de Tecnología
• Requisitos de Calidad
  • Identificación Atributos
  • Especificación de Escenarios
  • Requisitos de calidad con prioridad
• Arquitectura
  • Vistas y Modelos
  • Estilos
  • Tácticas
  • Patrones
  • Definición de frameworks y ambientes
  • Diseño del experimento
  • Resultados

El reclutamiento de personal para las empresas muchas veces puede ser un proceso lento e ineficiente, que puede dejar excelentes candidatos fuera del foco de atención de las empresas contratantes, por lo que se propone una plataforma móvil y web que funcione como puente entre empresas y aspirantes, agilizando y simplificando las búsquedas, evaluaciones y contrataciones. A través de esa plataforma, las empresas pueden gestionar todo el ciclo de contratación, desde la búsqueda, hasta la selección de los candidatos ideales para cubrir sus necesidades de personal, al tiempo que permite a los solicitantes mostrar sus habilidades y conectarse con las empresas interesadas.

1. Desarrollar un sistema de registro para personas y empresas.
2. Implementar una funcionalidad para que las empresas puedan crear proyectos y buscar candidatos.
3. Implementar una funcionalidad de registro de resultados de pruebas técnicas y evaluación de desempeño.
4. Asegurar que las funcionalidades de consulta de entrevistas programadas y resultados estén disponibles y sean eficientes.
5. Garantizar los atributos de calidad escalabilidad, disponibilidad, confidencialidad, integridad, facilidad de modificación en al menos un requisito.

1. La funcionalidad de registro debe pasar el 80% de las pruebas unitarias y de integración establecidas por el equipo de desarrollo.
2. Las pruebas de carga deben demostrar que la funcionalidad soporta al menos 100 registros de proyectos y 100 búsquedas simultáneas sin fallos.
3. La funcionalidad debe soportar el registro de al menos 10 pruebas técnicas en la base de datos.
4. Las consultas de base de datos relacionadas con entrevistas y resultados no deben tardar más de 3 segundo, comprobado mediante pruebas de rendimiento.
5. Durante las revisiones de código, no deben identificarse vulnerabilidades críticas en base a los atributos de calidad implementados.

• Permitir el registro y acceso de una persona y de una empresa.
• Permitir el registro de personas como aspirantes.
• Permitir el registro de empresas y la creación de proyectos por parte de estas.
• Las empresas pueden buscar candidatos basándose en criterios técnicos personales.
• Las empresas pueden registrar los resultados de las pruebas técnicas realizadas a un candidato.
• Las empresas pueden seleccionar a un candidato y asignarlo a un equipo de trabajo.
• Las empresas pueden evaluar el desempeño de un candidato seleccionado.
• Tanto empresas como candidatos pueden consultar entrevistas programadas y sus resultados.

• Permitir el registro y acceso de una persona.
• Permitir el registro de personas como aspirantes.
• Las empresas o los candidatos pueden registrar los resultados de las pruebas técnicas.
• Las empresas pueden seleccionar a un candidato y asignarlo a un equipo de trabajo.
• Las empresas pueden evaluar el desempeño de un candidato seleccionado.
• Los candidatos pueden consultar entrevistas programadas y sus resultados.

• Las sesiones de capacitación para las empresas o candidatos sobre el uso de la plataforma no están incluídas.
• No se incluye un soporte técnico continuo tras la finalización del proyecto.
• No se incluye la migración de datos desde otros sistemas o plataformas.
• La plataforma no se integrará con sistemas o API’s de terceros, como sistemas de gestión recursos humanos o de proyectos.
• La aplicación requerirá conexión a internet para todas ejecutar sus funcionalidades y conectarse.
• El sistema se desarrollará en un solo idioma, sin traducciones a otros idiomas.

• Se cuenta con un equipo de desarrolladores y diseñadores adecuadamente capacitados para las tecnologías y herramientas seleccionadas.
• Todas las herramientas, tecnologías y plataformas necesarias para el desarrollo estarán disponibles durante todo el proyecto
• La infraestructura cloud seleccionada brindará atributos de calidad como escalabilidad, disponibilidad, confidencialidad, integridad y facilidad de modificación. - La empresa ABC siendo el stakeholder tiene un entendimiento claro y compartido sobre el alcance, objetivos y criterios de evaluación del proyecto.
• La carga de trabajo y las tareas están distribuidas de manera equilibrada entre los miembros del equipo.
• Las versiones móvil y web tendrán una experiencia de usuario coherente y será intuitiva para los usuarios finales.

• El proyecto tiene una duración total de 16 semanas, con una semana de receso del 2 al 9 de octubre de 2023.
• Todo el backend y frontend (portal web) deben estar desplegados en la nube.
• Las funcionalidades detalladas en los objetivos (registro de personas y empresas, creación de proyectos, búsqueda de candidatos, entre otros) son inamovibles y deben ser implementadas.
• Deben implementarse tácticas que favorezcan al menos un requisito para cada atributo de calidad (escalabilidad, disponibilidad, confidencialidad, integridad, y facilidad de modificación).
• Las pruebas y criterios de aceptación deben ser evaluados y probados por el equipo de desarrollo.
• La disponibilidad y habilidades de los recursos humanos es una restricción. Es importante Es asegurarse de que los miembros del equipo tenga las competencias requeridas para cumplir la entrega del proyecto. - Las funcionalidades establecidaspara ambas plataformas deben ser compatibles entre sí

Factor de Riesgo	Consecuencias	Dueño del Plan de Respuesta
Cambios en los requisitos	Puede llevar a retrasos, incremento en los costos y confusión en el equipo.	Líder del Proyecto
Dificultades técnicas o tecnológicas	Afectaría la calidad del producto, podría causar retrasos y posiblemente incrementar los costos.	Equipo de desarrollo
Retraso en las entregas de los desarrolladores	Puede desencadenar un efecto dominó en las dependencias del proyecto y retrasar la entrega final.	Equipo de desarrollo
No cumplir con los atributos de calidad establecidos	Podría comprometer la aceptación del producto por parte del cliente o usuario final.	Equipo de desarrollo
Falta de disponibilidad o habilidades de recursos clave	Esto podría retrasar el proyecto y también afectar la calidad del producto.	Líder del Proyecto
Conflictos dentro del equipo	Podría reducir la moral y la productividad del equipo.	Líder del Proyecto
Inconsistencias en la sincronización entre las versiones web y móvil	Podría llevar a una mala experiencia del usuario y a revisiones adicionales.	Equipo de desarrollo
Problemas con el proveedor de la nube	Podría causar tiempos de inactividad, pérdida de datos o costos inesperados.	Equipo de desarrollo
Infravalorar la complejidad de alguna funcionalidad	Podría llevar a una subestimación del tiempo y los recursos necesarios.	Equipo de desarrollo

1. Aspirantes a un empleo.
2. Empresas contratantes.
3. Equipo de desarrollo.
4. Empresa ABC.
5. Proveedores nube.
6. Competidores en el sector de reclutamiento.
7. Instituciones educativas (búsqueda de pasantes).
8. Socios comerciales.
9. Medios de comunicación.
10. Accionistas de la empresa.

1. Inicio del Proyecto: 8 de agosto de 2023.
2. Fase de Diseño Finalizado: 30 de septiembre de 2023 (semana 8).
3. Receso: 2 al 9 de octubre de 2023.
4. Desarrollo del Sprint 1: 09 de octubre de 2023 hasta 22 de octubre de 2023.
5. Desarrollo del Sprint 2: 23 de octubre de 2023 hasta 5 de noviembre de 2023.
6. Desarrollo del Sprint 3: 06 de octubre de 2023 hasta 26 de noviembre de 2023.
7. Retroalimentación: 27 de noviembre de 2023 hasta 02 diciembre del 2023.
8. Cierre del Proyecto: 02 de diciembre de 2023.

Objetivo de negocio #1
Descripción	Aumentar la presencia de ABC Jobs en más países
Tiempo de cumplimiento	En los próximos 5 años
Mejora esperada del negocio	Aumento de la presencia global, puesto que actualmente tienen clientes de 8 países (principalmente de USA y Europa)
Cómo puede afectar la arquitectura	Existirá un mayor número de usuarios en simultáneo, por lo tanto, el sistema debe ser adaptable a situaciones de alta demanda. Las locaciones geográficas aumentarán la dificultad de despliegue. Además, el rendimiento de la solución puede disminuir si se introduce latencia por la locación. Las regulaciones legales respecto del manejo de información pueden variar en cada país o zona geográfica, estas deben ser tenidas en cuenta. El atributo de seguridad puede verse afectado debido a los estándares y/o regulaciones de seguridad locales

---

Objetivo de negocio #2
Descripción	Convertirse en uno de los 5 proveedores de recursos más importantes en Latinoamérica
Tiempo de cumplimiento	En los próximos 5 años
Mejora esperada del negocio	Aumento de la reputación de ABC Jobs
Cómo puede afectar la arquitectura	Apuntar a un mercado hasta el momento desconocido puede afectar la usabilidad, esto debido a que los usuarios pueden esperar interactuar de una manera distinta Si bien en Latinoamérica se habla principalmente español, se deben tener en cuenta países como Brasil en donde su lengua nativa es el portugués. La solución debe considerar factores como la internacionalización. La selección del proveedor de nube está atada a la disponibilidad del servicio en la región.

---

Objetivo de negocio #3
Descripción	Tener una base de datos de más de 30.000 talentos tecnológicos (recursos técnicos)
Tiempo de cumplimiento	En los próximos 2 años
Mejora esperada del negocio	Aumentar la base de datos de talento técnico disponible. Actualmente, cuentan con una base de datos cercana a 1.000 profesionales.
Cómo puede afectar la arquitectura	Pasar de 1.000 a 30.000 talentos tecnológicos requiere decisiones de arquitectura que favorezcan la escalabilidad y el rendimiento de la solución. El aumento del número de usuarios implica mejorar los mecanismos de autenticación y autorización.

---

Objetivo de negocio #4
Descripción	Tener una base de datos de más de 500 empresas a nivel mundial
Tiempo de cumplimiento	En los próximos 2 años
Mejora esperada del negocio	Aumentar la base de datos de empresas demandantes de los servicios de ABC Jobs
Cómo puede afectar la arquitectura	Si bien el número de empresas no es alarmante, la cantidad de proyectos gestionados dentro de la plataforma si puede aumentar exponencialmente, el acceso a estos recursos va a demandar un mayor rendimiento por parte del sistema. El sistema debe ser altamente adaptable/modificable, puesto que esas 500 empresas seguramente operan de manera distinta y van a desear funcionalidades distintas que se adapten a sus procesos.

Restricción de negocio #1
Descripción	El sistema debe ser adaptable a las regulaciones locales
Usuario que expresa la restricción	Directora contratación
Justificación para esta restricción	La expansión de la ABCJobs implica el correcto manejo de múltiples monedas, tasas de cambio, idiomas, regulaciones laborales y contractuales.
Cómo puede afectar la arquitectura	La internacionalización de la plataforma presupone crear la respectiva lógica de esta componente, así como sus respectivos archivos de idioma El manejo de distintas monedas podría implicar la interoperabilidad con una API de un tercero que ya cuente con las funcionalidades solicitadas

---

Restricción de negocio #2
Descripción	El nuevo software de ABC Jobs debe ser capaz de integrarse con los sistemas y plataformas tecnológicas actuales sin causar interrupciones en los servicios existentes
Usuario que expresa la restricción	Líder del Departamento de TI de ABC Jobs
Justificación para esta restricción	ABC Jobs ya ha realizado inversiones significativas en sus sistemas y tecnologías actuales por lo rediseñar o reemplazar estos sistemas conlleva un costo adicional significativo y puede interrumpir las operaciones diarias. Además, los datos existentes en estos sistemas son esenciales para las operaciones de la empresa.
Cómo puede afectar la arquitectura	Esta restricción puede dictar la adopción de patrones de diseño específicos o tecnologías que favorezcan la integración. La arquitectura puede necesitar interfaces bien definidas y puntos de integración. Además, puede ser necesario adoptar estándares de comunicación o protocolos específicos para garantizar la compatibilidad con los sistemas existentes.

---

Restricción de negocio #3
Descripción	El sistema debe integrar la información del sistema de búsqueda y selección de candidatos, el sistema contable, y el sistema contractual
Usuario que expresa la restricción	Director General ABCJobs
Justificación para esta restricción	Actualmente, ABCJobs opera con tres aplicaciones distintas y la interoperabilidad entre estos es nula, por lo tanto, es propenso a errores humanos
Cómo puede afectar la arquitectura	La interoperabilidad entre los 3 sistemas debe ser tratada como ciudadano de primer mundo, de lo contrario se podría crear una solución similar que no cumpla con las expectativas de ABCJobs Tres sistemas harán consultas y mutaciones de información, por lo tanto, la escalabilidad y el rendimiento de la solución deben ser tenidas en cuenta

Restricción de negocio #4
Descripción	El sistema ABC Jobs debe completarse dentro de un plazo específico, determinado por 3 Sprints en 8 semanas.
Usuario que expresa la restricción	Director del Proyecto
Justificación para esta restricción	ABC Jobs tiene objetivos y fechas claros que deben cumplirse para mantener su posición en el mercado y satisfacer las expectativas de los stakeholders. Retrasos en el desarrollo pueden incurrir en costos adicionales y oportunidades de mercado perdidas.
Cómo puede afectar la arquitectura	El tiempo limitado puede llevar a decisiones arquitectónicas que prioricen la velocidad de desarrollo sobre otros factores, como la optimización del rendimiento o la flexibilidad a largo plazo. Puede ser necesario adoptar frameworks o herramientas que aceleren el desarrollo, incluso si no son ideales en otros contextos. La arquitectura puede evolucionar de manera iterativa, incorporando características esenciales primero y dejando características secundarias o mejoras para fases posteriores.

Restricción de tecnología #1
Descripción	Todos los componentes de la plataforma debe estar desplegados en la nube
Usuario que expresa la restricción	Director de tecnología e infraestructura
Justificación para esta restricción	La plataforma debe estar disponible a nivel mundial
Cómo puede afectar la arquitectura	La selección de la empresa proveedora de servicios en la nube está anclada a la disponibilidad que esta tenga en las regiones de interés de expansión para ABCJobs Las tecnologías seleccionadas deben ser compatibles con la plataforma en la nube seleccionada El esfuerzo de despliegue debe ser tenido en cuenta

---

Restricción de tecnología #2
Descripción	El equipo de trabajo debe estar conformado por máximo 4 talentos en tecnología
Usuario que expresa la restricción	Departamento de tecnología e infraestructura
Justificación para esta restricción	Decisión basada en el presupuesto disponible de ABC Jobs
Cómo puede afectar la arquitectura	La creación de una plataforma de escala global presupone un reto para un equipo tan pequeño, dada la cantidad de tareas a realizar La alta variabilidad de las tecnologías a utilizar implica una selección correcta del equipo de desarrollo, puesto que esto afectará indirectamente la mantenibilidad del código generado

---

Restricción de tecnología #3
Descripción	Se debe contar con una plataforma web y una aplicación móvil
Usuario que expresa la restricción	Departamento de tecnología e infraestructura
Justificación para esta restricción	Establecido dentro de las necesidades contractuales
Cómo puede afectar la arquitectura	El desarrollo de dos aplicaciones que se integren adecuadamente puede afectar la interoperabilidad, además de afectar el rendimiento del equipo al tener que dividir tareas de dos aplicaciones distintas La facilidad de modificación de la plataforma depende directamente del código generado para cada una de las plataformas La facilidad de probar el sistema, y la creación de las respectivas pruebas supone una mayor demanda de tiempo y conocimiento de distintas tecnologías, nuevamente afectando la facilidad de modificación

ID	LATENCY #001	Versión	V.1
Fuente	Estímulo	Artefacto	Ambiente
Departamento de recursos humanos	El aspirante envía la respuesta a una pregunta de la prueba técnica o psicológica	Sistema de gestión del aspirante	Operación normal
Respuesta		Medida de la respuesta
El nivel de adaptación es ajustado y se calcula la siguiente pregunta con base en el nuevo nivel de adaptación		En menos de 0.5 segundos

---

ID	LATENCY #002	Versión	V.1
Fuente	Estímulo	Artefacto	Ambiente
Departamento de recursos humanos	El aspirante envía la respuesta a una pregunta	Sistema de gestión del aspirante	Operación normal
Respuesta		Medida de la respuesta
La pregunta es evaluada y su resultado debe ser reportado		En menos de 0.3 segundos

---

ID	SCALABILITY #003	Versión	V.1
Fuente	Estímulo	Artefacto	Ambiente
Departamento de recursos humanos	El aspirante ingresa al sistema para realizar y enviar una prueba	Sistema de gestión del aspirante	Operación normal
Respuesta		Medida de la respuesta
El portal de pruebas accesible		Mínimo 30 usuarios

---

ID	SCALABILITY #004	Versión	V.1
Fuente	Estímulo	Artefacto	Ambiente
Departamento de recursos humanos	El aspirante ingresa al sistema para realizar y enviar una prueba	Sistema de gestión del aspirante	Operación con alto tráfico
Respuesta		Medida de la respuesta
El portal de pruebas accesible		Hasta 100 usuarios

---

ID	AVAILABILITY #005	Versión	V.3
Fuente	Estímulo	Artefacto	Ambiente
Departamento de recursos humanos	Un aspirante ingresa desde cualquier parte del mundo	Sistema de gestión del aspirante	Operación normal
Respuesta		Medida de la respuesta
El portal de pruebas se encuentra en línea, es accesible y funcional con todas las características ofrecidas en cualquier momento		El componente de monitoreo (healthcheck) debe detectar y notificar en caso de falla en menos de 5000ms

---

ID	MAINTANABILITY #006	Versión	V.3
Fuente	Estímulo	Artefacto	Ambiente
Usuario administrador	El administrador desea agregar un nuevo tipo de prueba al sistema	Sistema de pruebas	Durante operaciones normales, con acceso administrativo
Respuesta		Medida de la respuesta
El sistema permite al usuario administrador agregar el nuevo tipo de prueba modificando el lenguaje de programación a utilizar mediante una variable de entorno y reiniciando la aplicación. La prueba debe quedar disponible para ser utilizada en el sistema.		En menos de 1 hora

---

ID	LATENCY #007	Versión	V.1
Fuente	Estímulo	Artefacto	Ambiente
Aspirante	Un aspirante envía las respuestas de una prueba	Sistema de gestión del aspirante	Operación normal
Respuesta		Medida de la respuesta
El sistema registra las respuestas de la prueba presentada por el aspirante		En menos de 500ms

---

ID	SECURITY #008	Versión	V.1
Fuente	Estímulo	Artefacto	Ambiente
Atacante	Un atacante intenta acceder a información de los aspirantes	Sistema de gestión del aspirante	Operación normal
Respuesta		Medida de la respuesta
El sistema identifica y bloquea el intento de acceso no autorizado. Devuelve un 401 al cliente.		100% de datos protegidos / total de intentos de acceso

---

ID	SECURITY #009	Versión	V.1
Fuente	Estímulo	Artefacto	Ambiente
Empleado de ABC Jobs	Intenta alterar el resultado de una prueba presentada por un aspirante	Sistema de gestión del aspirante	Operación normal
Respuesta		Medida de la respuesta
El resultado de la prueba permanece sin cambios.		100% de datos conservados / total de intentos de acceso

---

ID	SCALABILITY #010	Versión	V.1
Fuente	Estímulo	Artefacto	Ambiente
Aspirantes	Enviar una prueba técnica o psicológica finalizada	Sistema de gestión del aspirante	Operación normal
Respuesta		Medida de la respuesta
Las respuestas son procesadas y guardadas correctamente		De 15 a 30 solicitudes por segundo hasta por 60 minutos.

---

ID	SCALABILITY #011	Versión	V.1
Fuente	Estímulo	Artefacto	Ambiente
Aspirantes	Enviar una prueba técnica o psicológica finalizada	Sistema de gestión del aspirante	Operación normal
Respuesta		Medida de la respuesta
Las respuestas son procesadas y guardadas correctamente		30 pruebas guardadas/minuto

---

ID	AVAILABILITY #012	Versión	V.1
Fuente	Estímulo	Artefacto	Ambiente
Departamento de recursos humanos	Un aspirante ingresa desde cualquier parte del mundo	Sistema de gestión del aspirante	Operación normal
Respuesta		Medida de la respuesta
El portal de registro del aspirante se encuentra en línea, es accesible y funcional con todas las características ofrecidas en cualquier momento		El componente de monitoreo (healthcheck) debe detectar y notificar en caso de falla en menos de 5000ms

---

ID	SECURITY #013	Versión	V.1
Fuente	Estímulo	Artefacto	Ambiente
Una empresa	Intenta acceder a información de un proyecto de otra empresa	Sistema de gestión de empresas	Operación normal
Respuesta		Medida de la respuesta
El sistema identifica y bloquea el intento de acceso no autorizado. Devuelve un 403 al cliente.		100% de datos protegidos / total de intentos de acceso

---

ID	SECURITY #014	Versión	V.1
Fuente	Estímulo	Artefacto	Ambiente
Empleado de ABC Jobs	Intenta alterar el precio de una oferta publicada por una empresa	Sistema de gestión de empresas	Operación normal
Respuesta		Medida de la respuesta
El precio de la oferta publicada permanece sin cambios.		100% de datos conservados / total de intentos de acceso

---

ID	MAINTANABILITY #015	Versión	V.1
Fuente	Estímulo	Artefacto	Ambiente
Usuario administrador	El administrador desea agregar una etiqueta a cada campo de formulario que indique claramente si es requerido o no	Aplicación Frontend Web	Durante operaciones normales
Respuesta		Medida de la respuesta
Todos los campos de los formularios de creación de aspirates, empresas, proyectos, entrevistas, etc., incluyen un indicador de si el campo es requerido o no		En menos de 12 horas

• Requisitos
  • Latencia
    • #001
    • #002
    • #003
    • #004
    • #007
  • Disponibilidad
    • #005
    • #012
  • Facilidad de modificación
    • #006
    • #015
  • Seguridad
    • #008
    • #009
    • #013
    • #014
  • Escalabilidad
    • #010
    • #011

• #001
• #002
• #003
• #004
• #007
• #005
• #012
• #008
• #009
• #013
• #014
• #010
• #011
• #006
• #015

En el siguiente diagrama se resaltan los componentes a los que se aplica una táctica o un patrón, y se resalta en morado el flujo de comunicación que estará involucrado en el experimento a realizar. En rojo se resalta el componente monitor introducido, en azul el detalle de la fachada implementada en el API Gateway, en verde, el estilo N-niveles, en naranja, la extracción del componente Evaluator, en lila, el componente API Gateway que se asociará al patrón Abierto-Cerrado y en celeste, el componente DB que se le asociará el patrón Singleton. El análisis y razonamiento de estos cambios se encuentra más abajo en este documento.

Se puede evidenciar en color rojo que el componente monitor va a ser desplegado en su propio contenedor, la lógica detalla de por qué se llevará a cabo de esta forma, se encuentra más abajo en el documento.

En este estilo, la aplicación se divide en varios niveles, cada una con una responsabilidad específica: 'Nivel de Presentación', 'Nivel de Acceso y Autorización', 'Nivel de Lógica de Negocio' y 'Nivel de Persistencia de Datos'. Cada nivel sólo puede interactuar con el nivel inmediatamente inferior, y se comunican a través de interfaces bien definidas. Esta restricción ayuda a mantener la separación de responsabilidades y hace que el sistema sea más modular, promoviendo una alta cohesión y un bajo acoplamiento, que consecuentemente favorece la latencia en el sistema. El 'Nivel de Presentación' se encarga de la interfaz de usuario, el 'Nivel de Acceso y Autorización' se encarga de permitir o rechazar las solicitudes de acuerdo a los permisos y accesos definidos, el 'Nivel de Lógica de Negocio' contiene las reglas de negocio de la aplicación, y el 'Nivel de Persistencia de Datos' se encarga de almacenar y recuperar los datos.

Decidimos implementar el componente candidate management para dar una prioridad a los eventos recibidos por parte de cierto tipo de usuarios en el sistema, esto con la finalidad de tratar aquellos de mayor importancia primero para poder garantizar el tiempo de respuesta.

El objetivo principal de este componente es aportar al cumplimiento de los ASR relacionados con latencia, en este caso:

Como aspirante, cuando presento una prueba, dado que el sistema opera normalmente, quiero que la siguiente pregunta (adaptada) sea devuelta en menos de 0.5 segundos

Al implementar el componente evaluator además de llevar a cabo la evaluación de las pruebas de un candidato, se asignará un tiempo máximo de ejecución para responder a un evento recibido de forma que otros eventos puedan ser atendidos.

El objetivo principal de este componente es aportar al cumplimiento de los ASR relacionados con latencia, en este caso:

Como aspirante, cuando presento una prueba, dado que el sistema opera normalmente, quiero que la retroalimentación de la pregunta sea devuelta en menos de 0.3 segundos

Se implementó el componente DB con la finalidad de poder crear múltiples nodos para el mismo componente para no sufrir una degradación en el sistema en el caso de que múltiples eventos estén buscando tener acceso a determinada información del sistema.

El objetivo principal de este componente es aportar al cumplimiento de los ASR relacionados con latencia, en este caso:

Como administrador del sistema, cuando múltiples usuarios están enviando una prueba, dado que el sistema opera con alto tráfico, quiero el sistema soporte hasta 100 usuarios.

Dado que el punto inicial de la aplicación es el middleware de autenticación y que todas las solicitudes pasarán por este punto, decidimos implementar el * monitoring* para verificar el estado general de la aplicación en cualquier momento, aportándonos también la facilidad de introducir al sistema la detección de fallas, la congestión del sistema o incluso ataques de denegación de servicios, que aunque no está dentro de los ASR priorizados en nuestro diseño queremos tenerlo en cuenta dentro de la solución.

El objetivo principal de este componente es aportar a la mitigación o cumplimiento de los ASR relacionados con disponibilidad, en este caso:

• Como administrador del sistema, cuando quiero saber el estado del sistema, dado que el sistema opera normalmente, quiero recibir una alerta en caso de que el componente de monitoreo detecte una falla en un tiempo no mayor a 10 segundos, teniendo en cuenta que el componente de monitoreo estará verificando el estado del sistema de autenticación en un intervalo de 5 segundos.

Se implementa el patrón de single responsability al extraer la funcionalidad de evaluar pruebas del componente Candidate Management y asignar esa responsabilidad al componente Evaluator, el cual será el encargado de realizar las validaciones a las pruebas asignadas a un usuario. Por último, el componente Candidate Management tiene como una de sus responsabilidad principales el llevar a cabo la priorización de eventos recibidos para poder cumplir con la latencia esperada.

Se utiliza el patron de diseño facade para proveer una interfaz unica (API Gateway) que sirve como intermediador para la comunicación con los subsistemas de autenticación, lógica de negocio y persistencia. En este caso, se crearon tres 'Routers': 'CandidateRouter', 'ProjectRouter' y 'CompanyRouter', que se encargan de administrar los diferentes componentes del sistema relacionados con los candidatos, los proyectos y las compañías, respectivamente. Esto se llevó a cabo debido a que se busca introducir un único punto de entrada al sistema mediante el cual los clientes se van a comunicar con los subsistemas mediante diferentes peticiones realizadas exclusivamente al API Gateway. El patrón Facade sirve como punto de protección a los subsistemas o componentes al reducir el numero de objetos con los cuales el cliente tiene que lidiar, por lo cual facilita la interacción con el sistema. Por último promueve un bajo acoplamiento entre el subsistema y los clientes que realizan las peticiones, promoviendo de esta forma una baja latencia en el sistema.

El patrón de abierto y cerrado se utilizó al implementar el API Gateway, esto debido a que los componentes de la lógica de negocio puede ser cambiados por nuevas implementaciones o pueden llegar a ser a ser reemplazados por nuevos componentes en el dado caso de que la lógica de negocio así lo requiera. Sin embargo la funcionalidad expuesta a los clientes no cambia debido a que las API no se modifican, cumpliendo de esta forma que el componente esté abierto a las extensiones pero cerrado a las modificaciones.

Se utiliza el patrón de singleton para mantener un solo componente de DB asociado a un solo nodo de ejecución para poder garantizar la consistencia y coherencia de los datos del sistema, si el sistema necesita escalar para poder evitar una degradación en los tiempos de respuesta, el patrón seguirá siendo de vital importancia debido a que se mantendrá una única instancia por nodo de ejecución. Este patrón también es utilizado en el componente Monitor, debido a que se mantiene una sola instancia del componente que puede ser replicada a multiples nodos de ejecución en caso de que se necesite un escalamiento en el sistema y de esta forma aumentar el atributo de observabilidad para poder monitorear algún otro componente.

La selección de las siguientes herramientas fue basada en la experiencia de los integrantes del grupo, los cuales desarrollan principalmente en el ecosistema JavaScript. Esto nos permitirá disminuir el tiempo invertido en aprender y/o dominar las tecnologías a utilizar, consecuentemente la velocidad del equipo será congruente con lo planteado durante la etapa inicial del proyecto.

• Se define el framework para pruebas: Jest (unitarias), JMeter (pruebas de carga) y Cypress (Integración)
• Se define el framework para el componente web, alineado con test e internacionalización: React (Next.js-Frontend) - Express(Node.js-Backend)
• Se define el framework para el componente móvil, alineado con test e internacionalización: React Native
• Se define el ambiente cloud para backend, herramientas para test: Amazon Web Services. Para la base de datos se utilizará específicamente el servicio RDS con un motor PostgreSQL.

Titulo del experimento	Latencia en múltiples zonas geográficas
Propósito del experimento	Validar la latencia máxima esperada (300ms) definida en la historia de arquitectura ABC-31, relacionada con la retroalimentación de la respuesta a una pregunta presentada. Para ejecutar el experimento se desplegará la solución en una única zona AWS definida en Estados Unidos, y se ejecutarán las pruebas desde 3 locaciones geográficas distintas (Colombia, Chile y México). Las pruebas a ejecutar son las siguientes: - 1 usuario envía una respuesta a una pregunta desde Colombia. - 1 usuario envía una respuesta a una pregunta desde México. - 1 usuario envía una respuesta a una pregunta desde Chile.
Resultados esperados	Independientemente de la zona geográfica desde donde se generen las peticiones, y su distancia a la zona de despliegue, dado que usamos los patrones fachada (API Gateway), responsabilidad única (Evaluator) y a su vez utilizamos el estilo N-Niveles para los diferentes módulos con el fin de reducir el acoplamiento, se espera que la latencia sea menor a 300ms.
Recursos requeridos	AWS Free Tier (RDS, EC2, ECR), Postman, JMeter, Express (Node.js), JsonWebToken (JWT)
Elementos de arquitectura involucrados	Vista funcional, modelo de componentes. Componentes involucrados en el flujo de evaluador: API Gateway, Authorizer (Authentication and Authorization), Candidate Management, Evaluator, y Database (DB)
Esfuerzo estimado	56 horas. 16 horas para el planteamiento (Semanas 4 y 5) y diseño del experimento. 40 horas para el desarrollo, ejecución y análisis de los resultados (Semanas 6 y 7). (3.5h/semanales/miembro) para un equipo de 4 miembros.

Item	Descripción
Punto de sensibilidad	La comunicación entre el componente Candidate Management, el componente Evaluator y la base de datos debido a la cantidad de consultas que se deben realizar para obtener la validación de la respuesta enviada por el aspirante. La ejecución del algoritmo de evaluación respecto de las consultas a base datos en búsqueda de la respuesta correcta a la pregunta enviada por el aspirante
Historia de arquitectura asociada	ABC-31: Como aspirante, cuando presento una prueba, dado que el sistema opera normalmente, quiero que la retroalimentación de la pregunta sea devuelta en menos de 0.3 segundos
Nivel de incertidumbre	Muy bajo Bajo Medio ➡️Alto Muy alto

Estilo

Análisis (Atributos de calidad que favorece y desfavorece)

N-Niveles

Favorece la alta cohesión, el bajo acoplamiento y la facilidad de modificación, delegando responsabilidades definidas a cada módulo, por ejemplo el nivel de presentación solo es accesible por el cliente y a su vez éste nivel solo puede acceder al API expuesta por el Gateway. Adicionalmente la seguridad limita el acceso de los niveles superiores a los niveles inferiores. A su vez, al modularizar los niveles, los componentes pueden ser reutilizados en distintas partes de la aplicación o incluso en otros proyectos. Atributos de calidad como la latencia se ven desfavorecidos puesto que la velocidad de las operaciones mediante interfaces definidas entre los niveles puede disminuir. El rendimiento del sistema puede verse afectado debido a que se introducen interfaces de comunicación adicionales.

Táctica	Descripción
Detección de fallas - Monitor	Se utilizará la táctica de monitoreo para hacer una observación constante y registrar métricas respecto del sistema de autenticación como punto de entrada general de la aplicación. Esto permitirá detectar fallas tempranas de disponibilidad de la misma.
Acceso a los recursos - Dar prioridad a los eventos	Se utilizará la táctica de dar prioridad a eventos al identificar el tipo de usuario respondiendo una de las pruebas para poder asignar una prioridad con base al atributo seleccionado como prioritario.
Acceso a los recursos - Limitar tiempo de ejecución	Se utilizará la táctica de limitar el tiempo de ejecución en el componente Evaluator para poder asignar un tiempo determinado para el response de los eventos.
Incremento de recursos - Mantener múltiples copias de la información	Se utilizará la táctica de mantener múltiples copias de la información en el caso de que se identifique que el sistema está siendo degradado debido por el componente DB.

Táctica	Descripción
Single Responsability	Se implementa el patrón de single responsability al extraer la funcionalidad de evaluar pruebas del componente Candidate Management y asignar esa responsabilidad al componente Evaluator, el cual será el encargado de realizar las validaciones a las pruebas asignadas a un usuario. Por último, el componente Candidate Management tiene como una de sus responsabilidad principales el llevar a cabo la priorización de eventos recibidos para poder cumplir con la latencia esperada.
Facade	Se utiliza el patron de diseño facade para proveer una interfaz unica (API Gateway) que sirve como intermediador para la comunicación con los subsistemas de autenticación, lógica de negocio y persistencia. En este caso, se crearon tres 'Routers': 'CandidateRouter', 'ProjectRouter' y 'CompanyRouter', que se encargan de administrar los diferentes componentes del sistema relacionados con los candidatos, los proyectos y las compañías, respectivamente. Esto se llevó a cabo debido a que se busca introducir un único punto de entrada al sistema mediante el cual los clientes se van a comunicar con los subsistemas mediante diferentes peticiones realizadas exclusivamente al API Gateway. El patrón Facade sirve como punto de protección a los subsistemas o componentes al reducir el número de objetos con los cuales el cliente tiene que lidiar, por lo cual facilita la interacción con el sistema. Por último promueve un bajo acoplamiento entre el subsistema y los clientes que realizan las peticiones, promoviendo de esta forma una baja latencia en el sistema.
Abierto y Cerrado	El patrón de abierto y cerrado se utilizó al implementar el API Gateway, esto debido a que los componentes de la lógica de negocio puede ser cambiados por nuevas implementaciones o pueden llegar a ser a ser reemplazados por nuevos componentes en el dado caso de que la lógica de negocio así lo requiera. Sin embargo la funcionalidad expuesta a los clientes no cambia debido a que las API no se modifican, cumpliendo de esta forma que el componente esté abierto a las extensiones pero cerrado a las modificaciones.
Singleton	Se utiliza el patrón de singleton para mantener un solo componente de DB asociado a un solo nodo de ejecución para poder garantizar la consistencia y coherencia de los datos del sistema, si el sistema necesita escalar para poder evitar una degradación en los tiempos de respuesta, el patrón seguirá siendo de vital importancia debido a que se mantendrá una única instancia por nodo de ejecución. Este patrón también es utilizado en el componente Monitor, debido a que se mantiene una sola instancia del componente que puede ser replicada a multiples nodos de ejecución en caso de que se necesite un escalamiento en el sistema y de esta forma aumentar el atributo de observabilidad para poder monitorear algún otro componente.

Componente	Propósito y comportamiento esperado	Tecnologia asociada
API Gateway	Recibir de manera centralizada y servir como unico punto de entrada para las peticiones originadas por los clientes. Se espera que no tenga cambios en su comportamiento puesto que es un componente mediador, en contraste a los componentes que resuelven la problematica del sistema.	Express (JavaScript)
Authorizer (Authentication and Authorization)	Autenticar y autorizar las peticiones realizadas por parte del cliente, actuando como un middleware previo al acceso a la logica de negocio. Se espera que introduzca una latencia insignificante por el uso del algoritmo de validacion del token enviado por el cliente.	Express (JavaScript) and JWT
Candidate Management	Valida el perfil del usuario y determina si tiene pruebas disponibles a ser evaluadas y posteriormente envia al componente evaluador en caso de ser necesario. Se espera que las consultas que realice a la base de datos sean de un grado de complejidad bajo e introduzca la menor cantidad de latencia posible.	Express (JavaScript)
Evaluator	Realizar consultas a la base de datos para contrastar las respuestas de las pruebas enviadas por los aspirante. Adicionalmente, asignar un puntaje basado en la dificultad de la pregunta, ponderando y retornando el resultado de la prueba. Se espera que este componente sea el que aumenta en mayor medida la latencia, dada la complejidad de la consulta y el tiempo de ejecucion del algoritmo de evaluacion.	Express (JavaScript)
Database (DB)	Recibir consultas por parte del nivel de logica de negocio y retornar la informacion con base en la consulta realizada. Se espera que en base al diseno de la consulta introduzca o no una cantidad considerable o minima de latencia.	PostgreSQL (AWS RDS)

Conector	Comportamiento deseado en el experimento	Tecnología asociada
API (Gateway)	Recibir las peticiones enviadas por parte del cliente a través de internet a endpoints públicamente expuestos. Se desea que el API esté disponible en todas las zonas geográficas desde donde se ejecutarán las pruebas.	Express (Node.js), AWS
Middleware (Auth Systems)	Recibir las peticiones desde el API Gateway y validar, autenticar y/o autorizar los datos de identidad del client para permitir o denegar el acceso a los recursos ofrecidos por el nivel de lógica de negocio	Express (Node.js), Docker containers, AWS (EC2)
Candidate API	Recibir la carga paga del token validado por el middleware de autenticación y perfilar el usuario y los datos enviados para determinar si se debe enviar la información al componente Evaluator.	Express (Node.js), Docker containers, AWS (EC2)
Database Services	Recibir las consultas emitidas por parte de los componentes Candidate API y Evaluator, para recuperar información relacionada con las pruebas y/o respuestas presentadas por los aspirantes.	AWS (RDS)

Tecnología	Justificación
Express (Node.js)	Framework del ecosistema JavaScript para desarrollar los distintos módulos y/o componentes involucrados en el experimento
JWT	Librería para generación y validación de sesiones (autenticación y autorización), que además permite la inclusión de una carga paga con insumo para las peticiones. Ofrece una capa de seguridad al cifrar los datos del usuario que se intenta autenticar.
AWS (RDS, ECR, EC2)	Ecosistema de servicios de Amazon que permite crear por demanda y hacer uso de infraestructura como servicio, para desplegar aplicaciones en la nube.
Docker Containers	Tecnología de contenerización de aplicaciones, manteniendo un ambiente de ejecución consistente y portable entre máquinas físicas con configuraciones variadas.
Postman y JMeter	Herramientas para probar servicios o APIs que no disponen de una interfaz gráfica. JMeter usada principalmente para pruebas de carga, y Postman para crear colecciones de peticiones HTTP, ejecutarlas, documentarlas, etc.

Integrante	Tareas a realizar	Esfuerzo estimado
Alonso Daniel Cantu Trejo	Realizar la implementación del microservicio de autenticación Preparar y ejecutar las pruebas en JMeter	5 horas/semana, un total de 10 horas distribuidas en semanas 6 y 7
Camilo Andres Galvez Vidal	Crear el evaluador con el respectivo algoritmo Crear colección de pruebas en Postman	5 horas/semana, un total de 10 horas distribuidas en semanas 6 y 7
Diego Fernando Eslava Lozano	Realizar la implementación del microservicio de candidate management Generar los datos para alimentar el banco de preguntas y respuestas en base de datos	5 horas/semana, un total de 10 horas distribuidas en semanas 6 y 7
Luis Miguel Guzman Perez	Desplegar la infraestructura requerida en AWS Contenerizar los microservicios	5 horas/semana, un total de 10 horas distribuidas en semanas 6 y 7

El experimento consistió en medir el tiempo de respuesta promedio a una evaluación desde México, Colombia y Chile, buscando que la latencia sea inferior a 300ms desde cualquiera de las ubicaciones.

La primera prueba desde México dio como resultado un tiempo de 94ms de respuesta.

La segunda prueba desde México dio como resultado un tiempo de 174ms de respuesta.

La tercera prueba desde México dio como resultado un tiempo de 100ms de respuesta.

Las pruebas desde México tomaron un promedio de 122ms.

La primera prueba desde Colombia dio como resultado un tiempo de 209ms de respuesta.

La segunda prueba desde Colombia dio como resultado un tiempo de 203ms de respuesta.

La tercera prueba desde Colombia dio como resultado un tiempo de 103ms de respuesta.

Las pruebas desde Colombia tomaron un promedio de 171ms.

La primera prueba desde Chile dio como resultado un tiempo de 410ms de respuesta.

La segunda prueba desde Chile dio como resultado un tiempo de 366ms de respuesta.

La tercera prueba desde Chile dio como resultado un tiempo de 175ms de respuesta.

Las pruebas desde Chile tomaron un promedio de 317ms.

La hipótesis propuesta de tener una latencia inferior a 300ms desde cualquier ubicación donde se hiciera el requerimiento NO se cumplió desde Chile pero si se cumplió desde México y Colombia, por lo cual se deberán de tomar acciones para reducir la latencia desde Chile, algunas de las opciones para la reducción de la latencia son:

1. Utilizar hashes (índices) en la base de datos para poder tener un tiempo de búsqueda de la información más rápido.
2. Desplegar instancias de AWS más cercanas a Chile para agilizar su consulta ( se propone Brasil como ubicación más cercana).

Por lo tanto, los estilos, tácticas y patrones propuestos en la arquitectura de la aplicación pueden ser considerados efectivos, puesto que la latencia no excede en gran proporción los 300ms propuestos, a pesar de que la zona de despliegue y la zona más lejana de la solicitud están distanciadas por aproximadamente 8.500 Km (Chile - EUA).