Aunque Reclutech se desarrolló a partir de la encuesta de requisitos planteada por representantes de Effectus Software en base a la suya propia. API; AWS; Caso de prueba; Panel Administrativo; desarrollo ágil; editor de código; Software de efectos; Evaluación; marcos ágiles; IDE; Invitación;.
Introducción
- Estructura del documento
- Presentación del equipo
- Descripción del cliente
- Elección del Proyecto
- Objetivos
- Académicos
- Del equipo
- Del producto
- Del proceso
Meta El equipo acordó como primera meta académica adoptar el proyecto de grado para completar la carrera y lograr el título. Objetivo El equipo intentó aplicar los conocimientos adquiridos a lo largo de la competición, combinarlos y lograr un resultado nivelado.
Problema y solución
- Contexto
- Problema
- Interesados
- Desafíos del proyecto
- Solución propuesta
- Usuarios del sistema
- Componentes de la solución
- Entidades de la solución
- Operaciones del Dashboard Administrativo
- Operaciones web de candidatos
Juan Pablo es uno de los tres representantes de la empresa cliente con quienes interactuó el equipo. Al entregar la solución, usted será el principal responsable de liderar el mantenimiento de la plataforma realizado por el equipo de desarrollo de Effectus Software.
Marco metodológico
Características del proyecto
Características del equipo
Principales decisiones
- Etapas del proyecto
- Roles
- Ciclo de vida
- Scrum
- Reglamento interno
También se redactaron acuerdos iniciales como el acuerdo de alcance con el cliente y el reglamento interno del equipo. Como segunda decisión marco, se asignaron los roles que se consideraron más adecuados a las características del proyecto y de acuerdo con los intereses de cada miembro del equipo.
Ingeniería de requerimientos
- Relevamiento y análisis inicial
- Análisis de plataformas similares
- Entrevistas con el cliente
- Identificación de actores y abstracciones iniciales
- Especificación y validación
- Escenarios de uso principales
- Story Map
- Prototipos y wireframes
- Historias de usuario
- Acuerdo de alcance
- Milestones acordadas
- Listado de requerimientos
- Entregables acordados
- Firma del acuerdo de alcance
- Evolución de requerimientos durante el proyecto
- Mecanismo de validación y obtención de feedback
- Pruebas de aceptación
El sistema debe permitir a los usuarios administrativos crear y ver casos de prueba para un problema algorítmico. El sistema permitirá a los usuarios administradores crear una evaluación para enviarla a un candidato.
Tecnologías utilizadas
- Lenguaje de programación
- Librerías y entorno de ejecución
- Frontend
- Backend
- Servicios
- Hosting
- Almacenamiento
- Ambiente de desarrollo
- Integración y despliegue continuo (CI/CD)
70 React [7] se utilizó como biblioteca base para crear aplicaciones web utilizando su estructura de componentes reutilizables. Se utilizó la biblioteca Material UI [8] para que los estilos de los componentes implementados fueran profesionales y visualmente atractivos.
Arquitectura y desarrollo
Descripción general
Load Balancer: Es el componente responsable de responder a las solicitudes HTTP (Protocolo de transferencia de hipertexto) de los clientes web y distribuirlas a diferentes instancias del servidor API. Servidor API: Es un servicio back-end que se encarga de satisfacer las necesidades de dos clientes web que llegan en forma de solicitudes HTTP a través de un balanceador de carga.
Desafíos de arquitectura
- Ejecutar código de terceros
- Garantizar la integridad de los resultados
- Autenticación passwordless para candidato
- Ciclo de vida de una invitación
- Vigencia de una invitación
- No perder el progreso durante una evaluación
- Privacidad entre organizaciones
- Setup de herramientas para despliegue automatizado
Para reducir la probabilidad de que un usuario malintencionado cambie los resultados de su evaluación, se decidió cifrar el resultado en la aplicación web antes de enviarlo al servidor. De todas formas, a partir de la posibilidad de contar con un usuario en la organización Effectus Software dentro de la plataforma AWS y la capacitación del equipo en torno a la documentación disponible en dicha plataforma, la aplicación se implementó sin mayores inconvenientes.
Atributos de calidad
- Modificabilidad
- Testeabilidad
- Seguridad
- Disponibilidad
- Performance
Entre las acciones específicas tomadas por el equipo se encuentra la decisión de utilizar la arquitectura en capas en el backend, descrita en la sección anterior, ya que permite probar cada capa en función de las entradas y salidas esperadas. Una vez más, la decisión arquitectónica de ejecutar código de terceros en la aplicación web favoreció el rendimiento del sistema porque.
Modelo de datos
Finalmente, el rendimiento también se tuvo en cuenta al evaluar diferentes opciones de ejecución de código de terceros durante la fase de prueba de concepto, donde se utilizó la herramienta jMeter [35] para realizar la medición antes mencionada. Los detalles de la prueba mencionada y sus resultados se pueden encontrar en el Anexo 16 - Prueba de concepto para la ejecución de código de terceros.
Análisis de decisiones tecnológicas
- Editor de texto en el navegador
- Ejecución de código sin bloquear la UI
- Encriptar datos desde el frontend
- Tablero para visualizar datos
- Lenguaje Markdown
Si bien se acordó que los algoritmos debían resolverse utilizando un tiempo de ejecución finito configurable de unos pocos segundos, el objetivo en este sentido era que el candidato pudiera seguir usando la aplicación o escribir su solución mientras esperaba que finalizara la ejecución de la misma. para terminar. código o validación de casos de prueba del sistema. Debido a que la ejecución de código de terceros se realiza en el front-end, el equipo tuvo que buscar alternativas para garantizar la integridad de los resultados generados allí.
Gestión de calidad
Objetivos de calidad
En particular, se fijó el objetivo de entregar el backend con un porcentaje de cobertura de código mayor o igual al 95%.
Plan de calidad
111 Investigación: se desarrolló un plan de capacitación para involucrarse y aprender sobre las tecnologías a utilizar en el proyecto. En particular, la tecnología clave en el plan de formación fue React ya que el equipo no tenía conocimientos previos y era necesario superar la curva de aprendizaje para construir un producto de calidad.
Atributos de calidad
- Mantenibilidad
- Usabilidad
Finalmente, el equipo escribió pruebas con alta cobertura de código, con el objetivo de brindar confianza al realizar cambios en el sistema y detectar posibles regresiones. Un ejemplo de esto ocurre en particular cuando un usuario candidato está a punto de enviar su solución a una evaluación, y antes de hacerlo, el sistema solicita confirmación y le avisa que no hay vuelta atrás si continúa.
Aseguramiento de la calidad
- Estándares
- Pruebas
- Revisiones
- Validaciones
- Gestión de incidentes
Métricas de calidad
- Objetivos y resultados
Las actas de estas reuniones se encuentran en el Anexo 8 – Actas de reuniones de validación. Una correcta gestión de incidencias es fundamental para garantizar la calidad de un producto.
Gestión de la configuración
- Identificación de los elementos de configuración
- Elección de herramientas
- Desarrollo de software
- Documentación
- Organización del repositorio
- Código fuente
- Documentación
- Control de cambios
- Desarrollo de software
- Documentación
- Gestión de versiones
- Desarrollo de software
- Documentación
Versionado de productos de software enfocados al uso de las ramas master y de desarrollo, definiéndose una nueva versión del sistema como la que se produce cuando se realizan cambios en la rama master. A continuación, en la imagen de la carpeta Documentación, vemos el documento final junto con la carpeta de copia de seguridad.
Gestión del proyecto
Cronograma e hitos
Como mecanismo para validar incrementos y obtener retroalimentación, el equipo realizó pruebas de aceptación con el cliente. En la adaptación de Scrum que implementó el equipo, estas reuniones con el cliente sustituyeron a los Sprint Reviews dada la similitud en el objetivo entre ambos. Sin embargo, el equipo enfrentó el desafío de garantizar la integridad de los resultados de una evaluación.
Para resolver este desafío, el equipo decidió incluir un estado asociado para cada invitación en el modelo de datos. Para ayudar a garantizar la calidad del producto, el equipo consideró de suma importancia realizar pruebas en el sistema en construcción. Por ello, el equipo planificó esta iniciativa con el objetivo de identificar posibles errores y mejoras en el sistema construido hasta el momento.
Plan de capacitación
Anexo 29 – Plan de Capacitación contiene el detalle de las plataformas y herramientas utilizadas para la capacitación e incluye el plan y los objetivos definidos en el mismo.
Gestión de la comunicación
152 actas en la fase de análisis y solicitudes en el Anexo 4 - Actas de reuniones de solicitudes. Para lograrlo, el equipo envió un mensaje de Slack todos los miércoles con el estado actual del proyecto y los próximos pasos en un corto período de tiempo.
Adaptación de Scrum
A modo de revisión del sprint y para validar lo hecho con el cliente, el equipo realizó reuniones de presentación y validación cada dos o tres sprints. Este artefacto fue muy útil para el equipo y un ejemplo de ello fue la reunión donde discutieron el problema de estimación.
Gestión de entregables
Además, cabe recordar que se acordó que las funcionalidades a incluir serían opcionales, tanto las del acuerdo de alcance inicial como las priorizadas junto con el cliente a raíz del feedback obtenido del MVP. Luego, considerando la velocidad estimada del equipo de aproximadamente 25 puntos de historia por sprint y la cantidad de sprints restantes, se informó al cliente sobre el pronóstico de lo que pretendían construir.
Gestión de las tareas
Cuando una tarea llega a esta columna, el código escrito para resolver dicha funcionalidad fue revisado por un colega distinto al que la implementó, y luego se probó la funcionalidad en la rama donde se implementó. En esta última columna del flujo se encuentran las tareas completadas dentro del sprint, luego de haber sido integradas en la rama de desarrollo y así desplegadas en el entorno de prueba.
Métricas de desarrollo
165 Como puedes ver en el gráfico, el equipo comenzó con una velocidad ligeramente baja en comparación con los últimos sprints. Con esta métrica, el equipo obtuvo una representación visual de la cantidad de puntos de la historia completados por la cantidad total de horas dedicadas a las tareas de desarrollo y prueba del proyecto.
Dedicación horaria
- Horas por semana
- Horas por área
- Retrabajo
- Gestión y coordinación
En este caso, el objetivo era dedicar no más del 15% del total de horas a la gestión y coordinación del equipo para maximizar el aprovechamiento de las reuniones de equipo y hacerlas lo más efectivas posible. Finalmente finaliza con una tendencia alcista, que se justifica con el cierre del proyecto.
Gestión de riesgos
- Identificación
- Magnitud
- Estrategias, planes de contingencia y respuesta
- Evolución
Gestión del proyecto: Estos fueron los riesgos que afectaron el normal desarrollo de las distintas etapas del proyecto. A continuación se muestra una evolución de los cinco riesgos que creemos fueron los más importantes durante el proyecto.
Conclusiones y lecciones aprendidas
Conclusiones del proyecto
- Objetivos
- Entregables acordados
Evidencia: Ir al Anexo 36 – Carta de Cumplimiento del cliente donde se registra el cumplimiento. También nos complace poder comentar que el cliente registra su acuerdo en el Anexo 36 – Carta de conformidad del cliente.
Lecciones aprendidas
Durante la fase de análisis y encuesta sólo se mantuvieron dos reuniones personales con el cliente. Finalmente cabe destacar el trato y buena relación que hemos mantenido con el grupo de clientes durante todo este proceso.
Conclusiones del equipo
Se cree que esto aumentó la capacidad de producción del equipo y también resultó en un cliente satisfecho, quien expresa su acuerdo con el equipo y el proyecto en la carta del Apéndice 36: Carta de cumplimiento del cliente. 185 En cuanto al equipo, estamos contentos con el proceso ejecutado, el producto construido y la excelente relación mantenida no solo entre nosotros, sino también con el cliente y el docente.
Glosario
MVP: La primera versión de un producto que incluye los requisitos necesarios para la primera versión funcional implementada en un entorno de prueba. Retrospectiva - Post Mortem: Análisis retrospectivo al final de un proyecto o proceso de desarrollo.
Në dispozicion: https://medium.com/automation-with- batista/improve-the-code-quality-of-your-automated-tests-with-code-.
Principales pantallas del sistema
Reglamento interno
Análisis de plataformas similares
Actas de reuniones de requerimientos
Wireframes del sistema
Historias de usuario
Acuerdo de alcance
Actas de reuniones de validación
Análisis de frameworks CSS
Code Mirror vs Monaco Editor
Resumen sobre elección de JavaScript
Comparativa de Hosting
Comparativa SQL vs NoSQL
Documento previo a reunión con referente en arquitectura
Notas resultado de la reunión con referente de arquitectura
Prueba de concepto para ejecución de código de terceros
Prueba de concepto Code Mirror
Análisis de seguridad y confianza de resultados
Plan de calidad
Análisis de usabilidad de otros sistemas
Estándares de código
Estándares de Git
Plan de pruebas con usuarios beta
Encuestas de usabilidad con usuarios beta
Reunión con referente de calidad
Resultados de las revisiones ORT
Plan de gestión de incidentes
Encuestas de satisfacción del cliente
Plan de capacitación
Evidencia de actualizaciones semanales
Resultados de retrospectiva
Plan de riesgos
Evolución de riesgos
Encuestas de satisfacción del equipo
Investigación para modificabilidad
Carta de conformidad del cliente
