Entornos y metodologías
Last updated
Was this helpful?
Last updated
Was this helpful?
El desarrollo del módulo de catalogación colaborativa estuvo ceñido a los lineamientos ya establecidos dentro del metabuscador desarrollado en la Comisión de la Verdad, en tanto, en su momento, fue uno de los módulos funcionales de esta herramienta. En este sentido, hereda la arquitectura y las tecnologías usadas por el motor de búsqueda o metabuscador. Tenemos entonces los siguientes entornos:
Para el FRONTEND:
ReactJS; versión 16.13.1
Bootstrap; versión 4.4.1
Material-UI; versión 4.11.4
Template Metronic (al cierre de esta documentación, aún se utiliza el template; sin embargo, por no ser de uso libre, posiblemente sea retirado del desarrollo en la versión final).
Para el BACKEND:
MongoDB; versión 5.0.3
API RESTful que gestiona la data a través de NestJS (versión 7.1.5), escrito sobre el lenguaje de programación TypeScript (versión 4.2)
Para profundizar en la infraestructura utilizada por el aplicativo, se recomienda visualizar el siguiente documento:
Para profundizar en la instalación y la configuración del módulo de catalogación colaborativa, la Comisión de la Verdad pone a disposición el siguiente archivo:
Programación Sprint Scrum:
Historias de usuario
Definición de tableros y actividades (sprints)
Planeación y seguimientos
GitLab: se utiliza GitLab como herramienta para el control de versionamiento del proyecto.
GitFlow: flujo de trabajo a través de ramas (branchs) que, de manera descentralizada, permite a varias personas trabajar en un mismo proyecto.
De acuerdo con la experiencia del equipo desarrollador, GitFlow, por sí solo, no es suficiente para evitar conflictos y/o borramiento de código dentro de un proyecto. Es necesario recurrir a los Merge request, con el fin de que una sola persona sea la encargada de identificar los conflictos y hacer las fusiones dentro de la rama principal.
Programación Scrum: se recomienda trabajar bajo la metodología de programación Sprint Scrum, dado que es una metodología que permite la articulación fácil y rápida de modelos simples y funcionales, los cuales pueden ir evolucionando con el feedback y las necesidades del cliente.
Bajo esta metodología estaremos en función de un desarrollo iterativo o incremental, el cual consiste en dividir el trabajo en pequeñas partes o bloques temporales (sprint). Al final de cada etapa se entrega una funcionalidad completa. Para estructurar la evolución se recomienda crear el Mínimo Producto Viable (Minimum Viable Product, MVP): producto con suficientes características para satisfacer a los clientes y proporcionar retroalimentación para el desarrollo futuro.
MVP: herramienta que permite aprender mientras se desarrolla. Gracias a la iteración, el producto evoluciona y se reduce el tiempo para la validación de nuevas ideas.
Estandarizar código: definir unas reglas de trabajo; es decir, estandarizar la manera en que se van a crear y llamar las funciones, los métodos, las variables, los atributos, etc. La normalización del código es fundamental para el mantenimiento óptimo del desarrollo.
Comentar el código: es una buena práctica comentar el código a fin de que se convierta en un texto legible, autoexplicativo y facilite las modificaciones y el mantenimiento.
Interacción con usuarios: es una buena práctica tener entrevistas previas con los usuarios del sistema; dichos encuentros permiten entender los requerimientos puntuales y las funcionalidades concretas sobre las que debe basarse el desarrollo. Además, se recomienda encontrar un lenguaje común entre lo técnico del sistema y el requerimiento del usuario, a fin de no generar reprocesos y lograr comunicar fácilmente las funcionalidades del sistema.
Con (versión 3) se generan algunos script para la corrección de datos.
Se consumen API de para el manejo de información geográfica.
Arquitectura orientada a servicios: se continúa con la arquitectura implementada en el de la Comisión de la Verdad, en función de tener una identidad misional, y con el fin de reutilizar elementos ya existentes. Esta arquitectura permite ahorrar tiempos de desarrollo en tanto la estructura de datos, las distintas ETL y los diferentes procesos que resguardan la información en un mismo lugar, ya están definidos.
El software se encuentra dividido en dos niveles: el backend y el frontend. A nivel de backend, cada módulo administra una colección. Por ejemplo, el módulo resource administra la colección resource. Dentro de este módulo existen varias funcionalidades vitales del software. Por ejemplo, en resource.service.tsse gestiona parte del código que tiene que ver con los fondos y con los records; es decir, es el encargado de gestionar fondos (cuál es el fondo del recurso) y records (cuáles son los archivos asociados al recurso). Adicionalmente, es el módulo donde se gestiona la edición y la eliminación masiva de recursos; esto hace que sea un módulo robusto y complejo. La gestión de listas y la gestión de formularios, se llevan a cabo en el módulo de catalogación. A nivel de frontend, existe el componenteformfieldbootstrap.js dentro del cual se administra el código que arma los campos de los formularios (es el componente maestro de los formularios); en este sentido, cada que haya un formulario, se gestiona desde este componente, de allí que también sea uno de los más robustos.